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

2018-04-05 Thread Derek Buitenhuis
On 4/5/2018 8:14 PM, Rostislav Pehlivanov wrote: > I think it makes sense to have it in AVStream rather than as side data. > I don't have an opinion on whether codec switches should be indicated. It > would be nice for them to be a separate segment if that's possible and > reliable, since it would

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

2018-04-05 Thread Rostislav Pehlivanov
On 5 April 2018 at 16:26, Derek Buitenhuis wrote: > On 4/3/2018 5:26 PM, wm4 wrote: > > Uh no idea. One angle: > > > > The idea with AVStream side data is that it can be attached as AVPacket > > side data. So if an API user is fine with treating all kinds of side > >

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

2018-04-05 Thread wm4
On Thu, 5 Apr 2018 19:51:49 +0100 Derek Buitenhuis wrote: > Hi, > > If you wish to address me, please do so publicly in the future. Nobody > benefits from this stuff happening in private. CCing ffmpeg-devel where > this belongs. > > On 4/5/2018 7:44 PM, Nicolas

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

2018-04-05 Thread Derek Buitenhuis
Hi, If you wish to address me, please do so publicly in the future. Nobody benefits from this stuff happening in private. CCing ffmpeg-devel where this belongs. On 4/5/2018 7:44 PM, Nicolas George wrote: > This remark would have more weight if you also made it to people who > actually deserve

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

2018-04-05 Thread Derek Buitenhuis
On 4/5/2018 7:35 PM, Nicolas George wrote: > A completely braindead API versus using a data structure the way it is > supposed to be used, by adding fields when necessary? You call this a > trade-off? You could have voiced your opinion without being a jackass about it. Cut it out. - Derek

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

2018-04-05 Thread Nicolas George
Derek Buitenhuis (2018-04-05): > I got what you mean. I still don't have an opinion one way or another. > It's a trade-off between Yet Another AVStream Field vs a more complex > API and implementation as side data. I may be slightly erring towards > an AVStream field. > > I would be interested to

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

2018-04-05 Thread Derek Buitenhuis
On 4/3/2018 5:26 PM, wm4 wrote: > Uh no idea. One angle: > > The idea with AVStream side data is that it can be attached as AVPacket > side data. So if an API user is fine with treating all kinds of side > data per AVPacket, it can call av_format_inject_global_side_data() and > ignore AVStream

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

2018-04-03 Thread wm4
On Tue, 3 Apr 2018 17:06:03 +0100 Derek Buitenhuis wrote: > On 4/3/2018 4:15 AM, wm4 wrote: > > So I think all what you've been writing can be reduced to: should this > > really be side data, or would it be better to just make it a new > > AVStream field. > > I

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

2018-04-03 Thread Derek Buitenhuis
On 4/3/2018 4:15 AM, wm4 wrote: > So I think all what you've been writing can be reduced to: should this > really be side data, or would it be better to just make it a new > AVStream field. I don't really have an opinion on this one way or another. Do others? - Derek

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

2018-04-02 Thread wm4
On Tue, 3 Apr 2018 00:45:17 +0200 Michael Niedermayer wrote: > So in this sense my question is what advantage the opaque side data based > system > has over a system simply using a C struct the way AVChapter works ? The _only_ reason the side data is opqaue is because

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

2018-04-02 Thread Michael Niedermayer
Hi On Mon, Apr 02, 2018 at 04:46:18PM +0100, Derek Buitenhuis wrote: > On 4/1/2018 10:38 PM, Michael Niedermayer wrote: > >> I agree that the APIs are annoyingly different, but that they should remain > >> separate APIs. The suggestion of aligned (same names, args, etc.) seems the > >> most

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

2018-04-02 Thread Derek Buitenhuis
On 4/1/2018 10:38 PM, Michael Niedermayer wrote: >> I agree that the APIs are annoyingly different, but that they should remain >> separate APIs. The suggestion of aligned (same names, args, etc.) seems the >> most reasonable to me - consistency. >> >> I don't really think they can share some

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

2018-04-01 Thread Michael Niedermayer
On Sun, Apr 01, 2018 at 03:39:07PM +0100, Derek Buitenhuis wrote: > On 4/1/2018 12:44 AM, Michael Niedermayer wrote: > >> Not sure I follow what this has to do with timelines? There is no format > >> that > >> exists that store timeline data interleaved, as far as I know - it is a > >> purely

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

2018-04-01 Thread Derek Buitenhuis
On 4/1/2018 12:44 AM, Michael Niedermayer wrote: >> Not sure I follow what this has to do with timelines? There is no format that >> exists that store timeline data interleaved, as far as I know - it is a >> purely theoretical scenario. > > that surprises me. But if this case never occurs (or

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

2018-03-31 Thread Michael Niedermayer
On Sat, Mar 31, 2018 at 03:39:58PM +0100, Derek Buitenhuis wrote: > On 3/29/2018 7:55 PM, Michael Niedermayer wrote: > >> 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

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

2018-03-31 Thread Derek Buitenhuis
On 3/29/2018 7:55 PM, Michael Niedermayer wrote: >> 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

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

2018-03-30 Thread Derek Buitenhuis
On 3/30/2018 11:20 AM, Michael Niedermayer wrote: > 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

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

2018-03-30 Thread wm4
On Fri, 30 Mar 2018 12:20:38 +0200 Michael Niedermayer wrote: > On Thu, Mar 29, 2018 at 09:08:52PM +0200, wm4 wrote: > > On Thu, 29 Mar 2018 20:55:52 +0200 > > Michael Niedermayer wrote: > > > > > On Thu, Mar 29, 2018 at 08:49:21PM +0200,

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

2018-03-30 Thread 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 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: > >

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

2018-03-29 Thread wm4
On Thu, 29 Mar 2018 20:55:52 +0200 Michael Niedermayer 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: > > > >

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

2018-03-29 Thread Michael Niedermayer
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. > > >

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

2018-03-29 Thread Michael Niedermayer
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

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

2018-03-29 Thread Derek Buitenhuis
On 3/27/2018 8:44 PM, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > libavcodec/avcodec.h | 8 +++ > libavutil/timeline.h | 160 > +++ > 2 files changed, 168 insertions(+) > create mode 100644

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

2018-03-29 Thread Derek Buitenhuis
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

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

2018-03-29 Thread Derek Buitenhuis
On 3/29/2018 2:06 AM, Michael Niedermayer wrote: > Its how AVStreams are living in AVFormatContext too > so to me it seems thats the obvious and consistent way to go. > i do not know if there are any unforseen issues with that ... Sounds like the best way to go about it then. Thanks, - Derek

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

2018-03-28 Thread Michael Niedermayer
On Wed, Mar 28, 2018 at 09:35:12PM +0300, Jan Ekström wrote: > On Wed, Mar 28, 2018 at 9:12 PM, Michael Niedermayer > wrote: > >> +/** > >> + * An in-order array of entries for the given timeline. > >> + * Each entry contains information on which samples to

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

2018-03-28 Thread Michael Niedermayer
On Wed, Mar 28, 2018 at 07:53:31PM +0100, Derek Buitenhuis wrote: > On 3/28/2018 7:49 PM, wm4 wrote: > > You just need to change * to **. Then the size of the struct doesn't > > matter anymore for array access and can be excluded from the ABI. > > To be thorough: Does anyone else have opinions on

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

2018-03-28 Thread James Almer
On 3/28/2018 3:47 PM, Nicolas George wrote: > Derek Buitenhuis (2018-03-28): >> Do you have an actual suggest though? > > Maybe not using a badly designed API that requires everything to be > stored in a serialized uint8_t array. > >> Afaict, this is exactly

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

2018-03-28 Thread James Almer
On 3/28/2018 3:53 PM, Derek Buitenhuis wrote: > On 3/28/2018 7:49 PM, wm4 wrote: >> You just need to change * to **. Then the size of the struct doesn't >> matter anymore for array access and can be excluded from the ABI. > > To be thorough: Does anyone else have opinions on this approach? It's

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

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:49 PM, wm4 wrote: > You just need to change * to **. Then the size of the struct doesn't > matter anymore for array access and can be excluded from the ABI. To be thorough: Does anyone else have opinions on this approach? - Derek ___

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

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:47 PM, Nicolas George wrote: > Derek Buitenhuis (2018-03-28): >> Do you have an actual suggest though? > > Maybe not using a badly designed API that requires everything to be > stored in a serialized uint8_t array. Isn't this the same as saying "don't use the existing side data

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

2018-03-28 Thread wm4
On Wed, 28 Mar 2018 19:42:21 +0100 Derek Buitenhuis wrote: > On 3/28/2018 7:12 PM, Michael Niedermayer wrote: > > This is problematic as its non extensible. (unless iam missing something) > > Consider that a field is added to AVTimelineEntry, the entries array would >

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

2018-03-28 Thread Nicolas George
Derek Buitenhuis (2018-03-28): > Do you have an actual suggest though? Maybe not using a badly designed API that requires everything to be stored in a serialized uint8_t array. > Afaict, this is exactly how the recently > pushed encryption support works with

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

2018-03-28 Thread Derek Buitenhuis
On 3/28/2018 7:12 PM, Michael Niedermayer wrote: > This is problematic as its non extensible. (unless iam missing something) > Consider that a field is added to AVTimelineEntry, the entries array would > have a larger element size and that would require all user apps to be rebuild Do you have an

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

2018-03-28 Thread Jan Ekström
On Wed, Mar 28, 2018 at 9:12 PM, Michael Niedermayer wrote: >> +/** >> + * An in-order array of entries for the given timeline. >> + * Each entry contains information on which samples to display for a >> + * particular edit. >> + */ >> +

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

2018-03-28 Thread Michael Niedermayer
On Tue, Mar 27, 2018 at 08:44:01PM +0100, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > libavcodec/avcodec.h | 8 +++ > libavutil/timeline.h | 160 > +++ > 2 files changed, 168 insertions(+) >

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

2018-03-27 Thread Derek Buitenhuis
On 3/27/2018 11:46 PM, Alexander Strasser wrote: >> + * of the stream's rate, for example: 1.2 means play back this entry at >> 1.2x speed. >> + * If this value is 0, then the first sample (located at 'start') must >> be displayed >> + * for the duration of the entry. >> + */ >>

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

2018-03-27 Thread Alexander Strasser
Hi Derek, I am happy to see someone trying to extend FFmpeg to support these kind of features in a deeper way. Good luck on this journey! Below I am mostly commenting on typos and rather minor things. So you should for now mostly ignore my comments, but it is easier to write them now that I