> 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
--
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.
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.
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].
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.
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
On Thu, Jun 24, 2010 at 11:32 AM, Steve Lhomme <slh...@matroska.org> wrote:What does "aspect ratio is applied" mean?
> 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 remuxI still don't understand how this is supposed to work. If we have the
> it though to ensure that Clusters always start with a keyframe... (mkclean
> --remux --doctype 4 can do that for you).
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?
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?
> 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.
Pavel.
> 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?
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.
On Fri, Jul 9, 2010 at 12:53 PM, Steve Lhomme <slh...@matroska.org> wrote:But that would only be true if audio frame A(t) was in previous
> In the case that occurs, I think the non V(t+1) should be in the previous
> cluster.
cluster. But is not the behavior the server/browser people asked for.
Yes, they do. The server/browser guys specifically asked that the
> Audio frames/blocks don't necessarily have to be in front the
> video.
audio frame be on the same cluster as the keyframe.
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
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
--
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).
> 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:
> >>> 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
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>