[FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

wm4 nfxjfg at googlemail.com
Thu Mar 29 22:08:52 EEST 2018


On Thu, 29 Mar 2018 20:55:52 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Mar 29, 2018 at 08:49:21PM +0200, Michael Niedermayer wrote:
> > On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:  
> > > On 3/29/2018 2:13 AM, Michael Niedermayer wrote:  
> > > > Well, no unless we want a single unified API that represents information
> > > > about timespans.
> > > > We can use completely unrelated systems to handle the virtual timeline,
> > > > the codec and related changes, chapters, ...  
> > > 
> > > Personal opinion time: From design and use perspective, an single unified
> > > API to handle all of those things an their edge cases sounds like a
> > > nightmare to use and write.  
> > 
> > That is not what i meant
> > 
> > what i meant is to align the APIs that handle timespan related information
> > and not have totally different interfaces for each.
> > For example they might share the same struct in some cases to deliver data
> > They do have in common that they all in/export data for a sequence of timespans
> > 
> > Also the function interfaces could be aligned to each other
> > 
> > They also may have in common that some formats store the data interleaved
> > at the time and some store it in a main header.
> > If this is so the case of collecting all this info from the whole
> > duration of a file to store it in the output file header at the start
> > may be a situation common to multiple of these.
> > A similar API may allow simplifying whichever way we handle this
> > 
> > Iam sure there are more advantages of having APIs which deal with
> > similar types of data to be similar ...  
> 
> an example of an API that serves a similar kind of information but is
> differnt is AVChapter
> I think we should minimize the amount of different public structs that 
> describe timespans when that is easily and cleanly possible

Like how?

This sounds like a bikeshed smoke bomb to stop all progress again.


More information about the ffmpeg-devel mailing list