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
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
> > data per AVPacket, it can cal
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 George wrote:
> > This remark wou
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 it,
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
___
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
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 sid
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 don't really have an opinion on
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
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 side data can't
contain po
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 reason
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 commo
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 theo
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 will
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 e
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
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 think
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, Michael Niedermayer wrote:
> > > > On Thu, Mar 29, 2
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:
> > > > On 3/29/2018 2:13 AM,
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:
> > > > Well, no unless we want a s
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.
> > > W
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
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 libavutil/timeline.h
A few notes
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
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
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 display for a
> >> + * p
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
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 h
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 w
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
___
ffmp
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 API
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
> > have a larger element size
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
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 a
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.
>> + */
>> +AVTimelineEntry *entries;
>
> This is
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(+)
> create mode 100644 libavutil/tim
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.
>> + */
>> +
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 read
Signed-off-by: Derek Buitenhuis
---
libavcodec/avcodec.h | 8 +++
libavutil/timeline.h | 160 +++
2 files changed, 168 insertions(+)
create mode 100644 libavutil/timeline.h
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 50c34db..
39 matches
Mail list logo
