Publishing WebM videos on YouTube

259 views
Skip to first unread message

Danny Piccirillo

unread,
Jun 22, 2010, 4:00:52 AM6/22/10
to WebM Discussion
The WebM FAQ states that "all videos that are 720p or larger uploaded
to YouTube after May 19th will be be encoded in WebM as part of its
HTML5 experiment" but what about other videos? Does this mean that
*only* those videos will be available in WebM? What if the original
video (under 720p) was uploaded in WebM? Perhaps if nobody knows then
someone with a YouTube account they could test this.

Also, this is probably something that only someone from Google/YouTube
could answer, but there's this Top Ten list of YouTube wishlist
features (see #10):
http://blog.thesilentnumber.me/2010/06/10-killer-improvements-youtube-needs.html
http://www.google.com/support/forum/p/youtube/thread?tid=3177f94981a8ec05

#10 is to display WebM by default. Any idea when this might happen?
I've heard that in the mean time an option will be made available to
video publishers on YouTube to display their videos in WebM instead of
requiring the user to opt-in to the HTML5 beta, but again, does
anybody know when that might be?

Lou Quillio

unread,
Jun 22, 2010, 10:45:11 PM6/22/10
to Danny Piccirillo, WebM Discussion
On Tue, Jun 22, 2010 at 4:00 AM, Danny Piccirillo
<danny.pi...@ubuntu.com> wrote:
> The WebM FAQ states that "all videos that are 720p or larger uploaded
> to YouTube after May 19th will be be encoded in WebM as part of its
> HTML5 experiment" but what about other videos? Does this mean that [snip]

> Also, this is probably something that only someone from Google/YouTube

> could answer [snip]

Hi Danny,

You're correct that only YouTube folks can address the pace and
breadth of YT WebM deployment. I encourage you to post your inquiries
on the YT lists. We'd all like to see the quickest possible adoption,
but user experience is critical and paramount. YouTube -- and all
similar providers -- manage these topics on behalf of their users.

Best,

LQ


--
Lou Quillio
Tech Writer
WebMProject.org
+1 518.285.0003   <= Mobile (gV)
+1 518.881.4256   <= Office

Kevin Carle

unread,
Jun 23, 2010, 2:56:23 AM6/23/10
to Danny Piccirillo, WebM Discussion
Right now we're transcoding videos whose source resolution is at least 1280x720 into WebM. The outputs will be a "360p" and a "720p" WebM encoding in addition to all the normal YouTube formats. We will be rerunning many popular videos into WebM regardless of source resolution, and eventually we'll expand this (transcoding resources are the issue for now). 

We do use WebM over h264 in the Chrome HTML5 player when available, although we may reconsider this for 720p, as many people have been having issues with 720p playback versus h264. If so, I'll add a URL arg to "force" WebM in the html5 player, since that seems useful.

This all depends on browser --- if you're using Firefox or Opera in HTML5, you only get WebM transcodes of course. The h264/WebM logic is just for Chrome.

You can "force" HTML5 in the URL as well by adding "html5=True".


If the video is playing back using WebM, there will be a "WebM" logo next to the HTML5 logo in the control bar.

Other than with links, there is no way for the uploader to control what the user gets (tough anyways, due to browser/tech restrictions, and some users report HTML5 playback failure even on supported browsers). But if the intent is to highlight/showcase some videos, using the link approach should work. 

So basically, if the video is in WebM, html5=True is all that's needed right now, it will always choose WebM over h264 when it thinks the browser can do WebM. If that changes, we'll update the /html5 page and add another URL arg to make WebM have priority for Chrome. 

-Kevin



--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.


nandan amar

unread,
Jun 23, 2010, 7:23:00 AM6/23/10
to Kevin Carle, Danny Piccirillo, WebM Discussion
Hello Kevin Carle
I uploaded a .webm video
http://www.youtube.com/watch?v=gn1blnL0MYI to YouTube but I am getting it as normal video file and I can play it in normal browswe.

So is there some special way to upload webm video or it is not supported till now.

I also tried with some other normal video and attached
&html5=True but I am not getting HTML5 response.
Is the mentioned video http://www.youtube.com/watch?v=EGsdnAQcHZM&html5=True is special one..?

with regards
--
Amar Kumar Nandan
IIIT-Bangalore
Karnataka ,India , 560100
http://aknandan.co.nr

Danny Piccirillo

unread,
Jun 23, 2010, 9:39:01 AM6/23/10
to nandan amar, Kevin Carle, WebM Discussion
HTML5/WebM is not displayed on videos with advertisements as yours
somehow has. How did you get ads if this was your first video?

Kevin, so even if a video is uploaded in WebM format, if it is under
720p and not "popular" it will will be converted *out* of webm?

--
.danny

☮♥Ⓐ - http://www.google.com/profiles/danny.piccirillo
Every (in)decision matters.

Kevin Carle

unread,
Jun 23, 2010, 4:35:23 PM6/23/10
to Danny Piccirillo, nandan amar, WebM Discussion
It looks like the music content was claimed, which puts a click-to-buy ad on the video.

We should be adding some ad support to HTML5 soon so these restrictions can be lifted [no exact timeframe on this, but we're working on it].

On the WebM thing -- true for now, looking into getting that changed. 

[We transcode all videos regardless of upload format, h264 is always retranscoded into h264, etc so we can standardize resolution/bitrates/etc. So right now we don't special-case WebM uploads, meaning they're subject to the same restrictions, but I'll see what we can do about that].

-Kevin

Danny Piccirillo

unread,
Jun 23, 2010, 5:05:41 PM6/23/10
to Kevin Carle, nandan amar, WebM Discussion
Hey Kevin,

Thanks for the info! I look forward to these updates =]

Also, i've been told that in the meantime (until YouTube switches to HTML5/WebM by default) that an option may be added for video publishers to have their channel use HTML5 by default, not requiring the viewers to opt-in. They were high up enough in the Google-hierarchy that i wasn't sure how closely they were in contact with the YouTube team, so i wanted to check on the actual status of this.

Steve Lhomme

unread,
Jun 24, 2010, 3:13:27 AM6/24/10
to Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Wed, Jun 23, 2010 at 10:35 PM, Kevin Carle <kca...@google.com> wrote:
It looks like the music content was claimed, which puts a click-to-buy ad on the video.

We should be adding some ad support to HTML5 soon so these restrictions can be lifted [no exact timeframe on this, but we're working on it].

On the WebM thing -- true for now, looking into getting that changed. 

[We transcode all videos regardless of upload format, h264 is always retranscoded into h264, etc so we can standardize resolution/bitrates/etc. So right now we don't special-case WebM uploads, meaning they're subject to the same restrictions, but I'll see what we can do about that].

Shouldn't you check if the original is matching one of your target format before reencoding it to the same target (and losing in quality) ? The test itself is much faster than any reencoding so it's probably worth it.

Andy Berkheimer

unread,
Jun 24, 2010, 10:35:30 AM6/24/10
to Steve Lhomme, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Thu, Jun 24, 2010 at 3:13 AM, Steve Lhomme <slh...@matroska.org> wrote:
On Wed, Jun 23, 2010 at 10:35 PM, Kevin Carle <kca...@google.com> wrote:
It looks like the music content was claimed, which puts a click-to-buy ad on the video.

We should be adding some ad support to HTML5 soon so these restrictions can be lifted [no exact timeframe on this, but we're working on it].

On the WebM thing -- true for now, looking into getting that changed. 

[We transcode all videos regardless of upload format, h264 is always retranscoded into h264, etc so we can standardize resolution/bitrates/etc. So right now we don't special-case WebM uploads, meaning they're subject to the same restrictions, but I'll see what we can do about that].

Shouldn't you check if the original is matching one of your target format before reencoding it to the same target (and losing in quality) ? The test itself is much faster than any reencoding so it's probably worth it.

As we're taking data from external unknown sources and serving it through our domain to a broad audience, we have to be very cautious.

But I think the idea to ensure that a WebM stream is available when the source is WebM is a sound one.  Working on that right now.

-Andy

Steve Lhomme

unread,
Jun 24, 2010, 11:32:43 AM6/24/10
to Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
I added a --details option to mkvalidator 0.1.9 to output the bitrate and codecs in Matroska files. That might be helpful to you.

You may also modify it to check the video size (after aspect ratio is applied) is matching one of the files you want. You may still want to remux it though to ensure that Clusters always start with a keyframe... (mkclean --remux --doctype 4 can do that for you).

Steve

Matthew Heaney

unread,
Jul 8, 2010, 6:40:48 PM7/8/10
to Steve Lhomme, Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Thu, Jun 24, 2010 at 11:32 AM, Steve Lhomme <slh...@matroska.org> wrote:
> I added a --details option to mkvalidator 0.1.9 to output the bitrate and
> codecs in Matroska files. That might be helpful to you.
> You may also modify it to check the video size (after aspect ratio is
> applied) is matching one of the files you want.

What does "aspect ratio is applied" mean?


> You may still want to remux
> it though to ensure that Clusters always start with a keyframe... (mkclean
> --remux --doctype 4 can do that for you).

I still don't understand how this is supposed to work. If we have the
following sequence of frames (in order by timecode), where V1 is a
keyframe:

A0 V0 V1(k) ...

then audio frame A0 and video frames V0 and V1 must be all be together
in the same cluster. But that means a cluster doesn't start with a
keyframe -- in fact it doesn't even start with a video frame. How
does your tool order these frames?

-Matt

Steve Lhomme

unread,
Jul 9, 2010, 10:37:01 AM7/9/10
to Matthew Heaney, Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Fri, Jul 9, 2010 at 12:40 AM, Matthew Heaney <matthew...@google.com> wrote:
On Thu, Jun 24, 2010 at 11:32 AM, Steve Lhomme <slh...@matroska.org> wrote:
> I added a --details option to mkvalidator 0.1.9 to output the bitrate and
> codecs in Matroska files. That might be helpful to you.
> You may also modify it to check the video size (after aspect ratio is
> applied) is matching one of the files you want.

What does "aspect ratio is applied" mean?

In Matroska there is the pixel size and the display size to force the aspect ratio. If the display size is not specified, the pixel size is the one to use for displaying (or to respect the aspect ratio).
 
> You may still want to remux
> it though to ensure that Clusters always start with a keyframe... (mkclean
> --remux --doctype 4 can do that for you).

I still don't understand how this is supposed to work.  If we have the
following sequence of frames (in order by timecode), where V1 is a
keyframe:

A0  V0 V1(k) ...

then audio frame A0 and video frames V0 and V1 must be all be together
in the same cluster.  But that means a cluster doesn't start with a
keyframe -- in fact it doesn't even start with a video frame.  How
does your tool order these frames?

I assume A0 and V0 starts with the same timecode and V1 has another one ?

There's a very good chance that case never exists, because the duration of audio frames is 99.9% of the case smaller than a video frame. So you'd use A1b which is more likely to be starting after V0 starts. So A0 and V0 end up in the previous clusters. And the current one would be A1b V1...

Now if you're talking about Block that can contain several audio frames (using lacing), and thus longer than the duration of a video frame, mkclean --remux will split the lace between the 2 Clusters to match the rule above.

Steve

Matthew Heaney

unread,
Jul 9, 2010, 11:36:34 AM7/9/10
to Steve Lhomme, Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Fri, Jul 9, 2010 at 10:37 AM, Steve Lhomme <slh...@matroska.org> wrote:
>
> I assume A0 and V0 starts with the same timecode and V1 has another one ?

No. Assume all 3 frames have strictly increasing timecodes.


> There's a very good chance that case never exists,

Well the case I'm talking about happens all the time. The mkv
validator tool complains about the files made by the webmmux filter.
We need to determine whether the webmmux filter is really making
invalid webm files, or whether the mkv validator tool is issuing a
false positive result.


> because the duration of
> audio frames is 99.9% of the case smaller than a video frame. So you'd use
> A1b which is more likely to be starting after V0 starts.

I don't know what this means. There was no A1(b) frame in my example.

This is the case I'm talking about:

... A(t) V(t+1) V(t+2, key)...


> Now if you're talking about Block that can contain several audio frames
> (using lacing), and thus longer than the duration of a video frame, mkclean
> --remux will split the lace between the 2 Clusters to match the rule above.

No, let's consider the simple case first -- no lacing.

All 3 frames listed above have strictly increasing timecodes. How do
you think the 3 frames listed above should be distributed among
clusters?

Pavel Koshevoy

unread,
Jul 9, 2010, 11:58:44 AM7/9/10
to webm-d...@webmproject.org
On 7/9/2010 9:48 AM, Steve Lhomme wrote:

> There is no way the start timecode of the A(t) frame is before the start
> timecode of V(t+1) AND the end timecode of A(t) is after the start
> timecode of V(t+2). In other words, the audio frame cannot overlap
> entirely V(t+1). So it should be in the previous cluster and A(t+1.5)
> and V(t+2) in the subsequenct Cluster.

Is this only true for Vorbis audio? I think it is certainly possible to
create audio frames with duration that lasts longer than a video frame
duration, in which case it would be possible for an audio frame to span
several video frames (or even video keyframes).

Pavel.

Steve Lhomme

unread,
Jul 9, 2010, 12:53:42 PM7/9/10
to webm-discuss
It's true for all lossy codecs I know and for regular video fps (60 fps or higher may be different). Lossless codecs usually have bigger frames.

In the case that occurs, I think the non V(t+1) should be in the previous cluster. Audio frames/blocks don't necessarily have to be in front the video. During playback there has to be some form of buffering. But during seeking the time sync is usually based on the audio frames and so it's better if it's on the front.
 
       Pavel.

Matthew Heaney

unread,
Jul 9, 2010, 1:25:20 PM7/9/10
to Steve Lhomme, Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, WebM Discussion
On Fri, Jul 9, 2010 at 11:48 AM, Steve Lhomme <slh...@matroska.org> wrote:
>

> The rule is that when you start a Cluster with a keyframe, you need to put
> in front of it, the first frame(s) that contain the timecode of that
> keyframe. All the rest belongs to the previous Cluster (but it's no big deal
> if it's in that one too).

The rule is that the audio that goes with the keyframe goes in the
same cluster as the keyframe. This is what the server people asked
for.

According to that rule, because A(t) goes with V(t+2, key), then it
must go in the same cluster as V(t+2, key).

You're saying that A(t) goes in the previous cluster. That is not
what the server people asked for. How would seeking work in that
case?

Matthew Heaney

unread,
Jul 9, 2010, 1:29:33 PM7/9/10
to webm-d...@webmproject.org
On Fri, Jul 9, 2010 at 12:53 PM, Steve Lhomme <slh...@matroska.org> wrote:
> In the case that occurs, I think the non V(t+1) should be in the previous
> cluster.

But that would only be true if audio frame A(t) was in previous
cluster. But is not the behavior the server/browser people asked for.

> Audio frames/blocks don't necessarily have to be in front the
> video.

Yes, they do. The server/browser guys specifically asked that the
audio frame be on the same cluster as the keyframe.


> During playback there has to be some form of buffering. But during
> seeking the time sync is usually based on the audio frames and so it's
> better if it's on the front.

Yes, the audio frames are on the front of the cluster that contains
the keyframe.

Steve Lhomme

unread,
Jul 10, 2010, 4:27:50 AM7/10/10
to webm-discuss
On Fri, Jul 9, 2010 at 7:29 PM, Matthew Heaney <matthew...@google.com> wrote:
On Fri, Jul 9, 2010 at 12:53 PM, Steve Lhomme <slh...@matroska.org> wrote:
> In the case that occurs, I think the non V(t+1) should be in the previous
> cluster.

But that would only be true if audio frame A(t) was in previous
cluster.  But is not the behavior the server/browser people asked for.

> Audio frames/blocks don't necessarily have to be in front the
> video.

Yes, they do.  The server/browser guys specifically asked that the
audio frame be on the same cluster as the keyframe.

No and no. I don't know why any server people who need any order in particular. The issue is on playback. And like I said earlier it's because the audio is used as the time basis for A/V sync. If you know any other reasons let me know.

And this problem only occurs when there is a discontinuity (after seeking or gap in audio). In that case, in a poorly designed player, the audio needs to be fed first so that the time basis can be reset and initialised again. So that the A/V clock is always known, no matter what. During normal playback this problem should not occur as there should be some frame buffering should happen on all codecs being played.

This is especially true when you have B frames (not the case in VP8, so not in WebM) as the forward video frame would occur before may other video frames. If we follow your logic that means all the audio up to that forward frame should be placed before that frame, and then all the B frames with no audio in between.
A(t) V(t, key) A(t+1) A(t+2) A(t+3) A(t+4) V(t+4, key) V(t+1) V(t+2) V(t+3)
Even in that case you will need to buffer the audio while the video frames are catching up.

That's why I'm saying, because there is buffering on audio frames, only the init should be at the front, the rest will catch up naturally in the buffering. Because there is also buffering on the video side.

Buffering is inevitable anyway if you don't want to have ugly gaps during the audio playback.

maikm...@googlemail.com

unread,
Jul 10, 2010, 11:28:44 AM7/10/10
to WebM Discussion
On 23 Jun., 08:56, Kevin Carle <kca...@google.com> wrote:
> Right now we're transcoding videos whose source resolution is at least
> 1280x720 into WebM. The outputs will be a "360p" and a "720p" WebM encoding
> in addition to all the normal YouTube formats. We will be rerunning many
> popular videos into WebM regardless of source resolution, and eventually
> we'll expand this (transcoding resources are the issue for now).

Is there a chance YouTube may update their WebM encoding setup to use
a libvorbis-based Vorbis encoder instead of ffmpeg's experimental
(and, so it seems, deprecated) ffvorbis Vorbis encoder before the next
transcoding steps are started? (http://xiphmont.livejournal.com/
51160.html)

It appears YouTube is still affected by the broken ffvorbis encoder. I
know it's always a challenging task to evaluate changes in the
production pipeline, but it would be a pity if audio quality is
needlessly degraded. The current setup is also wasteful on bandwidth
and storage.


Maik

Matthew Heaney

unread,
Aug 6, 2010, 2:49:15 PM8/6/10
to WebM Discussion, Andy Berkheimer, Kevin Carle, Danny Piccirillo, nandan amar, Chris Pearce, Pavel Koshevoy, Steve Lhomme
On Fri, Jul 9, 2010 at 11:48 AM, Steve Lhomme <slh...@matroska.org> wrote:
>
> The rule is that when you start a Cluster with a keyframe, you need to put
> in front of it, the first frame(s) that contain the timecode of that
> keyframe. All the rest belongs to the previous Cluster (but it's no big deal
> if it's in that one too).

This is incorrect (for WebM files). The rules about block placement
within a cluster of a WebM file were agreed to back in April 2010.
They are summarized in the container guidelines document:

http://www.webmproject.org/code/specs/container/
http://www.webmproject.org/code/specs/container/#muxer_guidelines

In particular,

(quote)

Key frames should be placed at the beginning of clusters.

Audio blocks that contain the video key frame's timecode should be in
the same cluster as the video key frame block.

Audio blocks that have same absolute timecode as video blocks should
be written before the video blocks.

(end quote)


To summarize: In a WebM file, the audio frame with the largest
timecode less or equal to the keyframe's timecode must be present on
the same cluster as the keyframe itself. As a consequence, any
non-key video frames with a timecode equal or greater than the audio
frame, but less than the timecode of the video keyframe, must also be


on the same cluster as the keyframe.

This was the agreement that we made with browser authors and server
writers over 4 months ago, and which is enunciated in the muxer
guidelines document cited above.

Regards,
Matt

Danny Piccirillo

unread,
Aug 6, 2010, 5:35:39 PM8/6/10
to webm-d...@webmproject.org

Ah, yes absolutely. If this isn't already the case, it should be.
Also, could the next expansion of WebM transcoding be for videos
uploaded in WebM? This would encourage people to have source files in
WebM, and make for a good announcement about how anyone can have their
videos available in WebM on YouTube

Kevin Carle

unread,
Aug 6, 2010, 7:10:27 PM8/6/10
to webm-d...@webmproject.org
We should now be transcoding WebM uploads into WebM regardless of resolution (I forget exactly when we turned this on). Let me know if this doesn't work (and I should add something to our HTML5 page about it).

-Kevin

--

Kevin Carle

unread,
Aug 6, 2010, 7:22:59 PM8/6/10
to webm-d...@webmproject.org
Argh, after checking it turns out there's a bug on our end that's preventing this from working. I'll send another update when it actually works.

-Kevin

Andy Berkheimer

unread,
Aug 6, 2010, 7:29:36 PM8/6/10
to webm-d...@webmproject.org
A bit of extra detail:

We updated our processing pipeline on July 20th.  The biggest part of this update for WebM was a switch to libvorbis.  That's the good news!  You'll see this change for all videos uploaded after July 20th and we've also started re-encoding some videos that either didn't have WebM before or had WebM with ffvorbis.

The July 20th update was also supposed to start producing WebM outputs for all WebM uploads.  But there's a bug in our pipeline configuration that snuck through on that one, working to fix it for our next update.

-Andy

Danny Piccirillo

unread,
Aug 6, 2010, 8:15:57 PM8/6/10
to webm-d...@webmproject.org
Great, thanks! Please keep us posted

Danny Piccirillo

unread,
Aug 12, 2010, 4:02:12 PM8/12/10
to webm-d...@webmproject.org
Also, i wonder if this could be extended to videos uploaded in Theora
as well? I would think that it's simple to include those videos as
well and i'm sure there aren't that many, relatively.

Andy Berkheimer

unread,
Nov 3, 2010, 1:12:32 PM11/3/10
to Fabio Pedretti, webm-d...@webmproject.org
Yes it's still libvorbis.  We strip such string signatures out of our encoded files before publishing them.

On Wed, Nov 3, 2010 at 1:12 PM, Fabio Pedretti <pedrett...@gmail.com> wrote:
Is YouTube still using libvorbis? I tried with 2 recent uploaded
videos and the libvorbis check (see http://xiphmont.livejournal.com/51160.html
):
strings file_to_be_checked | grep Vorbis
still gives no output (i.e. ffvorbis).


On 7 Ago, 00:29, Andy Berkheimer <andyberkhei...@youtube.com> wrote:
> A bit of extra detail:
>
> We updated our processing pipeline on July 20th.  The biggest part of this
> update for WebM was a switch to libvorbis.  That's the good news!  You'll
> see this change for all videos uploaded after July 20th and we've also
> started re-encoding some videos that either didn't have WebM before or had
> WebM with ffvorbis.
>
> The July 20th update was also supposed to start producing WebM outputs for
> all WebM uploads.  But there's a bug in our pipeline configuration that
> snuck through on that one, working to fix it for our next update.
>
> -Andy
>
> On Fri, Aug 6, 2010 at 7:22 PM, Kevin Carle <kca...@google.com> wrote:
> > Argh, after checking it turns out there's a bug on our end that's
> > preventing this from working. I'll send another update when it actually
> > works.
>
> > -Kevin
>
> > On Fri, Aug 6, 2010 at 4:10 PM, Kevin Carle <kca...@google.com> wrote:
>
> >> We should now be transcoding WebM uploads into WebM regardless of
> >> resolution (I forget exactly when we turned this on). Let me know if this
> >> doesn't work (and I should add something to our HTML5 page about it).
>
> >> -Kevin
>
> >> On Fri, Aug 6, 2010 at 2:35 PM, Danny Piccirillo <

> >>> Every (in)decision matters.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "WebM Discussion" group.
> >>> To post to this group, send email to webm-disc...@webmproject.org.

> >>> To unsubscribe from this group, send email to

> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "WebM Discussion" group.
> > To post to this group, send email to webm-disc...@webmproject.org.

> > To unsubscribe from this group, send email to

Fabio Pedretti

unread,
Nov 3, 2010, 1:12:04 PM11/3/10
to Andy Berkheimer, webm-d...@webmproject.org
Is YouTube still using libvorbis? I tried with 2 recent uploaded
videos and the libvorbis check (see http://xiphmont.livejournal.com/51160.html
):
strings file_to_be_checked | grep Vorbis
still gives no output (i.e. ffvorbis).

On 7 Ago, 00:29, Andy Berkheimer <andyberkhei...@youtube.com> wrote:

> A bit of extra detail:
>
> We updated our processing pipeline on July 20th.  The biggest part of this
> update for WebM was a switch to libvorbis.  That's the good news!  You'll
> see this change for all videos uploaded after July 20th and we've also
> started re-encoding some videos that either didn't have WebM before or had
> WebM with ffvorbis.
>
> The July 20th update was also supposed to start producing WebM outputs for
> all WebM uploads.  But there's a bug in our pipeline configuration that
> snuck through on that one, working to fix it for our next update.
>
> -Andy
>
> On Fri, Aug 6, 2010 at 7:22 PM, Kevin Carle <kca...@google.com> wrote:
> > Argh, after checking it turns out there's a bug on our end that's
> > preventing this from working. I'll send another update when it actually
> > works.
>
> > -Kevin
>
> > On Fri, Aug 6, 2010 at 4:10 PM, Kevin Carle <kca...@google.com> wrote:
>
> >> We should now be transcoding WebM uploads into WebM regardless of
> >> resolution (I forget exactly when we turned this on). Let me know if this
> >> doesn't work (and I should add something to our HTML5 page about it).
>
> >> -Kevin
>
> >> On Fri, Aug 6, 2010 at 2:35 PM, Danny Piccirillo <

> >> danny.picciri...@gmail.com> wrote:

> >>> ☮♥Ⓐ -http://www.google.com/profiles/danny.piccirillo


> >>> Every (in)decision matters.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "WebM Discussion" group.

> >>> To post to this group, send email to webm-disc...@webmproject.org.


> >>> To unsubscribe from this group, send email to

> >>> webm-discuss+unsubscr...@webmproject.org<webm-discuss%2Bunsubscr...@webmproject.org>


> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "WebM Discussion" group.

> > To post to this group, send email to webm-disc...@webmproject.org.


> > To unsubscribe from this group, send email to

> > webm-discuss+unsubscr...@webmproject.org<webm-discuss%2Bunsubscr...@webmproject.org>

Reply all
Reply to author
Forward
0 new messages