Discussion:
[issue2629] 23.976 H.264 matroska files detected as 24fps
(too old to reply)
Anssi Hannula
2011-02-27 23:18:09 UTC
Permalink
New submission from Anssi Hannula <***@iki.fi>:

23.976 H.264 Matroska files are commonly detected as 24fps
(r_frame_rate).

The most visible issue caused by this I've seen is probably frame-based
subtitle misalignment on MPlayer and XBMC (though the latter has
workarounded it).

Background and the issue specifics:

- normally lavf assumes that the (1 / codec->time_base /
codec->ticks_per_frame) is the fps (r_frame_rate), unless it would be
too high to be represented by the st->time_base, in which case
(1 / st->time_base) is taken instead (utils.c 2431-2440)

- if ((1/5) > codec->time_base >= (1/101)) is false, the
codec->time_base is considered unreliable and instead a custom
fps probing code is used (tb_unreliable()) which reads the timestamps
of the first 20 packets

- some H.264 (and I guess MPEG2) streams have a specific interlacing
mode that causes there to be 2x more packets (as output from the
demuxer) than codec->time_base and codec->ticks_per_frame would
indicate (well, I guess technically they are correct, if the packets
actually contain half-frames due to interlacing), e.g.
http://samples.ffmpeg.org/V-codecs/h264/hdtv-interlaced/
sky_720p_test_why-cant-i-overwrite.ts

- due to the above (AFAIK), H264 and MPEG2 are always assumed to have
unreliable timebase and the fps probing code is always used

- mkv tracks have generally millisecond precision for timestamps

- 23.976fps therefore requires a pattern of 41ms and 42ms frames, that
add up to 1.001s in 24 frames

- the fps probing code doesn't detect the difference between 24fps and
23.976fps from just 20 frames, it would need more than that (25-30)
=> 23.976fps files are wrongly detected as 24fps

- 23.976fps files are progressive (unless insane), so the codec timebase
as got from the decoder would actually be reliable and show an exact
rate of 24/1.001.

- mkv tracks also contain a default_duration field that contains the
length of frames in nanosecond precision. In the file I checked it
was accurate to within 1.5ns (some rounding issue I guess), which
corresponds to an error of about 0.000001 fps.

The issue was discussed at
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-
January/104856.html

----------
messages: 13770
nosy: anssi
priority: normal
status: open
substatus: open
title: 23.976 H.264 matroska files detected as 24fps
topic: avformat
type: bug

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2629>
________________________________________________
Anssi Hannula
2011-02-27 23:22:59 UTC
Permalink
Anssi Hannula <***@iki.fi> added the comment:

A sample is in incoming/lavf-issue2629 and
http://onse.fi/files/h264-23.976-detected-as-24.mkv (though from what
I've seen this is issue is very widespread).

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2629>
________________________________________________
Anssi Hannula
2011-04-05 10:37:56 UTC
Permalink
Anssi Hannula <***@iki.fi> added the comment:

This specific issue has been fixed in FFmpeg, by doing longer fps
inspection when timebase is coarse:
http://git.videolan.org/?
p=ffmpeg.git;a=commitdiff;h=78431098f9e306ebe27e7698d0ae539e3df2afe9

----------
nosy: -anssi
topic: -avformat

______________________________________________
Libav issue tracker <***@roundup.libav.org>
<https://roundup.libav.org/issue2629>
______________________________________________
Anssi Hannula
2011-04-05 10:38:53 UTC
Permalink
Anssi Hannula <***@iki.fi> added the comment:

Add me back to nosy list, roundup removed that for some reason...

----------
nosy: +anssi

______________________________________________
Libav issue tracker <***@roundup.libav.org>
<https://roundup.libav.org/issue2629>
______________________________________________

Loading...