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

[Michael Niedermayer]

On Thu, Mar 29, 2018 at 09:08:52PM +0200, wm4 wrote:
> 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?

Wait, you cannot think of a single way on how to store timespan data
except by using a completely seperate and different API for each case where
we need to store timespan data? Like not even similarity in the order of
arguments of functions.
because thats ultimatly the only thing i suggested we should not do.


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

Why do you try to incite hostilities and discord ?
I mean derek (who wrote the patch) has not even had time to reply to my
comment. 
I am very interrested in what his oppinion is, does he agree? does he
think its impossible or too hard or irrelevant ? Or does he see something
i didnt think of at all.

Lets wait for derek before arguing over it.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180330/4c344334/attachment.sig>