[FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available

[Bodecs Bela]

2016.03.01. 11:26 keltezéssel, Michael Niedermayer írta:
> On Tue, Mar 01, 2016 at 10:57:57AM +0100, Nicolas George wrote:
>> Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit :
>>> I have checked the code where and when duration filled and made some
>>> reasoning about it.
>>> Duration value for input files has been populated some time after opening.
>>> (estimate_timings function in utils.c) And never again corrected or called
>>> this function..
>>> So, if early in processing there is no duration info, it remains empty.
>>> When input is not a seekable file but a not-seekable stream, the only chance
>>> to get a duration info  when the stream itself contains info about this
>>> value. (eg. flv metadata, mp4-moov)
>>> But mpegts format does not contain this info. So the only moment when
>>> duration calculatable is when we finish the reading. I think contoniously
>>> updating the duration value after each packet would not be a good idea.
>>> (cur_dts is updated is AVStream->info struct)
>>>
>>> So reading a file via pipe or reading hls stream via http it is normal that
>>> duration value remains empty.
>>>
>>> thus, I think to handle the cases when duration value is not populated, this
>>> is not a bug fix but a reasonable solution for these cases.
>>>
>>> I agree with you that we should not "measure" our-own the pts values but I
>>> could not find any existing/available data member to have this info.
>> Sorry for the late reply, I was distracted.
>>
>> If I summarize correctly your findings:
>>
>> For formats without a reliable duration header with seekable backing, the
>> duration is evaluated at the opening by peeking at the last timestamps.
>>
>> With unseekable backing, the duration is not evaluated at all.
>>
>> In particular, the duration is not updated once the end of the file is
>> reached.
>>
>> Well, I thought it was and wrote the code in consequence, thanks for
>> correcting me.
>>
>> Still, the logic for tracking the duration can be a bit tricky, possibly
>> trickier than your original patch if there are B-frames and timestamps
>> resets. I would rather have it in a common part of the code than in the
>> concat demuxer.
>>
>> I suspect we could consider adding AVStream.current_duration that tracks the
>> maximum recently seen PTS for each stream.
>>
>> (We could also have a function that peeks in AVStream.pts_buffer, but that
>> looks tricky; and the corresponding duration is not available.)
>>
>> I hope other can give advice about this issue.
> somewhat independant of this, but i thik some kind of "indexer"
> input would be usefull
> i mean a input format that opens another input and sequentially reads
> the whole at open and creates an index
> with that exact seeking, exact bitrate, exact duration would become
> available.
> the index could also be stored in a on disk cache if the user wants
> making repeated opening of the same file not require sequentially
> scaning the whole
>
> [...]
>
>
like a lookup map
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel