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

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160301/e6663c51/attachment.sig>