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

[Måns Rullgård]

Peter Ross <pross at xvid.org> writes:

> On Wed, Jan 26, 2011 at 12:52:28PM -0500, Ronald S. Bultje wrote:
>> Hi,
>> 
>> On Tue, Jan 25, 2011 at 5:40 AM, Peter Ross <pross at xvid.org> wrote:
>> > Hi,
>> >
>> > [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.

> An alternate fix is to increase the number of frames used to calculate
> r_frame_rate. The enclosed patch fixes all (three) of my broken samples.

If this guessing is required at all, we should add a flag to demuxer
which do no provide accurate values, and calculate the average only
when needed.  Libavformat already does too much work up front.

-- 
M?ns Rullg?rd
mans at mansr.com