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

[Vitor Sessak]

Jai Menon wrote:
> 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...

I'm not sure I understood your question, but from what I know, in FFmpeg 
every packet should have a timestamp, even audio ones. It does set it 
automatically for audio, but it will set in timebase units, and a 
suitable timebase is not automatically autodetected.

-Vitor