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 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
