On Fri, 30 Mar 2018 12:20:38 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Thu, Mar 29, 2018 at 09:08:52PM +0200, wm4 wrote: > > On Thu, 29 Mar 2018 20:55:52 +0200 > > Michael Niedermayer <mich...@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. I can think of thousand things. I could bikeshed proposals all day, believe me. But making very vague suggestions that can't be acted upon and that are out of this world anyway is not a good way to make progress. You're just lengthening the discussion by forcing Derek to pull concrete ideas out of your nose. If you have an idea that you think is much better, just make a concrete proposal. > > > > > This sounds like a bikeshed smoke bomb to stop all progress again. > > Why do you try to incite hostilities and discord ? Well, why do you seemingly put brakes on this patch, with nothing real to say, just vague proposals about generalizing everything to a generic thing? > 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
