[Matroska-devel] requesting "AvgTimePerFrame" or "FieldRate" header field

madshi madshi at gmail.com
Sat Dec 15 14:19:21 CET 2012


Hey,

> Therefore it makes no sense to store AvgFrameDuration
> _before_ deinterlacing

So you're suggesting to let AvgFrameDuration define the frame rate *after*
deinterlacing? That's highly problematic, IMHO, because depending on
whether the content is native video or native movie, the frame rate after
deinterlacing differs. A proper deinterlacer will convert 60i sports to
60p, but it will IVTC telecined 60i movies to 24p. So are you suggesting
that the AvgFrameDuration field should be set to 60p for sports and to 24p
for movies? In order for that to work, the muxer would have to know which
content type is being muxed, and the muxer can't possible know that unless
it decodes the video stream and then runs it through a complex
deinterlacing logic which is able to find out which content type the source
has. But even if the muxer did all that, the content type could change in
the middle of the stream (e.g. advertisement breaks in a movie are often
native video content).

> So let's draw up some comparisons between this proposed
> element and default duration:
> * 50 interlaced fields per second; default duration = 1000ms/50 =
> 20ms; AvgFrameDuration = 1000ms/25 = 40ms
> * 25 progressive frames per second; default duration = 1000ms/25 =
> 40ms; AvgFrameDuration = 1000ms/25 = 40ms
> or what would you expect?

That would be fine with me. However, PAL is the easy stuff, because PAL
doesn't use the "repeat_first_field" flag. So things are much more
"interesting" for NTSC stuff.

Btw, what you're saying here is not *after* deinterlacing, but *before*
deinterlacing. Because if the 50i content is sports or music concerts,
after (proper) deinterlacing it will be 50p. In that case a "fps after
deinterlacing" field would have to be set to 20ms.

Maybe when you're talking about "deinterlacing", you mean weaving separate
interlaced fields together? So 50 separate interlaced fields become 25
interlaced frames? That is not "deinterlacing", though, that is just
weaving.

> As a matter of fact the h.264 bitstream's rate fields tell you the
> rate of fields per second. They don't tell you how many fields per
> frame there are. This is exactly the same value that Matroska's
> DefaultDuration stores. mkvmerge simply calculates the
> DefaultDuration as 1000000000 * num_units_in_tick / time_scale,
> and those two values are exactly the values stored in the h.264
> headers.

Something is wrong here. If mkvmerge really sets DefaultDuration to
"1000000000 * num_units_in_tick / time_scale" then DefaultDuration would be
20ms for both 50i and 25p content. But earlier you said that
DefaultDuration differs for 25p and 50i content. Only one of the 2 things
you said can be correct. h264 always uses 50000/1000 (or 50/1) for any sort
of 25p/50i PAL content.

Best regards, Mathias.


2012/12/15 Moritz Bunkus <moritz at bunkus.org>

> Hey,
>
> you seem to be mixing up some terms here. A Matroska field would not
> include "i" or "p" information at all. Instead it would probably be
> defined something like this:
>
> AvgFrameDuration  --  everage display duration for a whole video frame
> (telecine removal is not taken into account)
>
> So let's draw up some comparisons between this proposed element and
> default duration:
>
> * 50 interlaced fields per second; default duration = 1000ms/50 =
> 20ms; AvgFrameDuration = 1000ms/25 = 40ms
> * 25 progressive frames per second; default duration = 1000ms/25 =
> 40ms; AvgFrameDuration = 1000ms/25 = 40ms
>
> or what would you expect?
>
> > The same format as DefaultDuration for the new field
> > would be fine with me. One alternative solution might be
> > to use a similar logic as h264. Typical h264 values would
> > be 48000/1001, 60000/1001 or 50000/1000, but that would
> > require two new fields. So probably the DefaultDuration
> > format would be simpler = better.
>
> As a matter of fact the h.264 bitstream's rate fields tell you the
> rate of fields per second. They don't tell you how many fields per
> frame there are. This is exactly the same value that Matroska's
> DefaultDuration stores. mkvmerge simply calculates the DefaultDuration
> as 1000000000 * num_units_in_tick / time_scale, and those two values
> are exactly the values stored in the h.264 headers.
>
> However, I guess that you always get a definite answer to the question
> "is the content interlaced or progressive?" from a different part of
> the h.264 headers, and that that information is passed down to your
> filter as well. That's what Matroska does not provide even though it
> formally has an element called FlagInterlaced in the track headers.
> mkvmerge does not write it, unfortunately.
>
> Therefore it makes no sense to store AvgFrameDuration _before_
> deinterlacing, because that's exactly what DefaultDuration already is.
>
> Kind regards,
> mosu
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20121215/6fbfed18/attachment.html>


More information about the Matroska-devel mailing list