[FFmpeg-devel] looping input and pts rollover

Andrey Utkin andrey.krieger.utkin at gmail.com
Wed May 23 20:47:14 CEST 2012


вторник, 22 мая 2012 г. пользователь Michael Niedermayer <michaelni at gmx.at>
писал:
> On Tue, May 22, 2012 at 03:38:38PM +0200, Nicolas George wrote:
>> Le quartidi 4 prairial, an CCXX, Robert Nagy a écrit :
>> > We had a short discussion on IRC regarding looping input.
>> >
>> > The problem today is that lavfi does not guarantee proper handling of
>> > rollover pts (which happens with e.g. looping input), which means that
>> > either the filter graph needs to be flushed and reinit at the same
>> > time as avcodec_flush_buffers.
>> >
>> > From the discussion I think the general consensus was that graph
>> > reinit would be to complicated, thus I believe we need to review the
>> > filters.
>>
>> I told you my opinion about this last time you raised it, and it has not
>> changed yet: rollovers should be corrected before entry into the filter
>> system, or at words just after with a fixpts filter.
>>
>> That way, no need for anything, no reinit, no review, no duplicated code.
>
> I consider rollovers a special case of timestamp discontinuities
> (resets to 0 are not uncommon)
>
> If you want to handle them in a fixpts filter, this filter will have to
> correct all the streams together because if its done independantly
> for audio and video each could get a slightly different correction
> offset and end with AV desync

It can do well fixing pts on video stream only, for audio it is sufficient
to have independant pts generation, i.e. some filter must not pass input
pts but generate it by itself, for example, aresample.
I have done sth like such vf_ptsfix, it just calculated average pts delta
between frames, and when delta was remarkably big, it fixed pts to prev pts
+ average delta.
Additional questions arise in cases of remuxing without reencoding, or
remuxing only particular substreams, while reencoding others.

> also one disadvantage of removing the discontinuities before the
> filters is that it becomes impossible to preserve them. There was
> at least 1 user who wanted that though i dont remember the exact
> reason why. (it was somthing with cuting and concatenating of mpegs)
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death
your
> right to say it. -- Voltaire
>

-- 
Andrey Utkin


More information about the ffmpeg-devel mailing list