[FFmpeg-devel] [PATCH 0/2] increase fps detection accuracy in wtv demuxer

[Peter Ross]

On Thu, Jan 27, 2011 at 09:25:12AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> 2011/1/27 M?ns Rullg?rd <mans at mansr.com>:
> > Peter Ross <pross at xvid.org> writes:
> >> On Wed, Jan 26, 2011 at 12:52:28PM -0500, Ronald S. Bultje wrote:
> >>> On Tue, Jan 25, 2011 at 5:40 AM, Peter Ross <pross at xvid.org> wrote:
> >>> > [initial stab at git-send-email]
> >>> >
> >>> > FFmpeg currently treats the fps information within MPEG2 and H264
> >>> > video stream headers as unreliable, because many encoders put bogus
> >>> > data in the headers. For streams containg these codecs, libavformat
> >>> > chooses to caculate the fps using dts deltas.
> >>> >
> >>> > In WTV files, the pts values are often sparse, and/or shaky for the
> >>> > first few seconds of video. This results in an incorrect fps value to
> >>> > be caculated. My solution is to introduce CODEC_FLAG2_TIMEBASE_RELIABLE,
> >>> > and flag streams as having reliable header information.
> >>> >
> >>> > Patches threaded below. Other ideas welcome..
> >>>
> >>> Disregard my other email, let's discuss this here. Shaky timestamps =
> >>> unreliable timestamp information. Are you saying the base is OK but
> >>> the timestamps themselves are not? I'm unconfomfortable with adding
> >>> hacks to circumvent other hacks that should fix bugs but don't.
> >>
> >> Hi Ronald, the symptom is an incorrect AVStream.r_frame_rate value, often in
> >> the kilo-frames-per-second range.
> >>
> >> As bit of background, the wtv file format sometimes provides PTS values.
> >> Many packets output by the demuxer have no PTS.
> >
> > How does it end up with that ridiculous value in the first place? ?IMO
> > that should be fixed, not patched up afterwards.

Agree.

> I'm all with this, try not having that value to begin with, and then
> maybe we don't need this hack. AV_NOPTS_VALUE is meant for this, and
> whatever tb_reliable() does should take that into account.

av_stream_info() guesses the r_frame_rate value by calculating the gcd of
the dts of the first n packets. there are a couple of special rules in 
the caclulation

1.  relative dts values fed into the gcd calc. they are offset by 'AVStream.info.last_dts'.
    last_dts is set to the dts of the second packet having dts > 0
    (see libabformat/utils.c lines 2348 ~ 2360 ).

2.  the first four dts values are not fed into the gcd, to avoid jitter.

A ridiculous r_frame_rate value occurs when the dts values do not have
a common divisor. Lets look at the dts values for some problematic files.
Importantly, the dts values are computed; wtv demuxer only supplies pts.

--
Gilmore Girls_Net 5_2011_01_08_16_10_53.wtv, stream #1, dts values
(one packet per line):
 0
 400000 <-- last_dts
 800000
 35232214
 35632214
 36032214
 36432214

gcd(35232214, 35632214, 36032214) = 2

--
RTL GP- WK Superbike - Qatar_RTL7_2009_03_14_15_49_23.wtv, stream #1, dts values
(one packet per line):
 AV_NOPTS_VALUE
 AV_NOPTS_VALUE
 AV_NOPTS_VALUE
 0
 AV_NOPTS_VALUE
 AV_NOPTS_VALUE
 0
 AV_NOPTS_VALUE
 AV_NOPTS_VALUE
 0
 AV_NOPTS_VALUE
 AV_NOPTS_VALUE
 1200000
 1600000 <- last_dts
 2000000
 216596748
 216996748
 217396748
 217796748

gcd(215396748, 215796748, 216196748) = 2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110128/c9d11722/attachment.pgp>