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

[Bodecs Bela]

2016.03.01. 10:57 keltezéssel, Nicolas George írta:
> 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:

Thank you. You summarized correctly my 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 agree.
>
> I suspect we could consider adding AVStream.current_duration that tracks the
> maximum recently seen PTS for each stream.
yes, it sounds good.
>
> (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.
>
> Regards,
>
>
I hope somebody will give a better solution than me.
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
best,

bb