[FFmpeg-cvslog] r22802 - trunk/libavformat/utils.c

[Jai Menon]

On Tue, Apr 13, 2010 at 6:51 AM, Vitor Sessak <vitor1001 at gmail.com> wrote:
> Michael Niedermayer wrote:
>>
>> On Mon, Apr 12, 2010 at 08:12:50PM -0400, Vitor Sessak wrote:
>>>
>>> Michael Niedermayer wrote:
>>>>
>>>> On Sun, Apr 04, 2010 at 09:40:02PM -0400, Vitor Sessak wrote:
>>>>>
>>>>> michael wrote:
>>>>>>
>>>>>> Author: michael
>>>>>> Date: Mon Apr ?5 00:19:42 2010
>>>>>> New Revision: 22802
>>>>>> Log:
>>>>>> Fix rounding direction for calculation of AVPacket.duration.
>>>>>> Fixes issue1579
>>>>>
>>>>> This broke "make fate-nsv-demux" and "make fate-vqf-demux".
>>>>
>>>> both the nsv and vqf demuxers set audio timebases in which audio frame
>>>> timestamps cannot be represented accurately, in nsvs case the effect is
>>>> a negligible +-1 change. For vqf the effect is a fatal growing loss of
>>>> precission.
>>>> For both files the bug is in the demuxers and exists before 22802.
>>>> Also both pre 22802 and post 22802 checksums thus are equally wrong
>>>> The demuxers should be fixed by their respective maintainers
>>>
>>> I suppose like this?
>>>
>>> -Vitor
>>
>>> ?vqf.c | ? ?1 +
>>> ?1 file changed, 1 insertion(+)
>>> b340cee6c3185958d950a45741c35d58ebfe7f57 ?vqf_pts.diff
>>
>> yes, looks correct
>
> Applied. @Mike: Can you update the testspec?
>
> Any idea of how to fix it in NSV demuxer where the sample rate is not
> encoded in the header?

I don't actually see why av_get_pts_info is used, not to mention the
framerate is specific to the video stream. Also, since the parser will
set the samplerate, framesize later, shouldn't that be enough? Or
probably I'm missing something...

-- 
Jai Menon