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

[Ronald S. Bultje]

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.

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.

Ronald