On Mon, Jan 08, 2018 at 05:03:32PM -0800, Jacob Trimble wrote:
> On Mon, Jan 8, 2018 at 11:40 AM, Jacob Trimble wrote:
> >> I'd assume we'd wait with applying this until the mp4 patch that uses
> >> it is reviewed. I'm fine with this patch and I think it can be pushed
> >> as it is, although I jus
On Mon, Jan 8, 2018 at 11:40 AM, Jacob Trimble wrote:
>> I'd assume we'd wait with applying this until the mp4 patch that uses
>> it is reviewed. I'm fine with this patch and I think it can be pushed
>> as it is, although I just noticed an APIchanges entry and minor version
>> bump is actually mis
> I'd assume we'd wait with applying this until the mp4 patch that uses
> it is reviewed. I'm fine with this patch and I think it can be pushed
> as it is, although I just noticed an APIchanges entry and minor version
> bump is actually missing. You could add them when sending the final
> patch set
On 1/5/2018 7:32 PM, Michael Niedermayer wrote:
> On Fri, Jan 05, 2018 at 08:27:41PM +0100, wm4 wrote:
>> On Fri, 5 Jan 2018 10:22:31 -0800
>> Jacob Trimble wrote:
>>
>>> Just noticed the new files were in libavcodec, moved to libavutil.
>>> Can someone please review this so it can be pushed. I h
On Fri, Jan 05, 2018 at 08:27:41PM +0100, wm4 wrote:
> On Fri, 5 Jan 2018 10:22:31 -0800
> Jacob Trimble wrote:
>
> > Just noticed the new files were in libavcodec, moved to libavutil.
> > Can someone please review this so it can be pushed. I have the MP4
> > implementation ready and I would lik
On Fri, Jan 05, 2018 at 10:22:31AM -0800, Jacob Trimble wrote:
> On Tue, Jan 2, 2018 at 9:57 AM, Jacob Trimble wrote:
> > On Wed, Dec 20, 2017 at 4:31 PM, wm4 wrote:
> >> On Wed, 20 Dec 2017 15:10:43 -0800
> >> Jacob Trimble wrote:
> >>
> >>> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep
On Mon, Dec 18, 2017 at 11:17:48AM -0800, Jacob Trimble wrote:
> >> @@ -1327,6 +1384,19 @@ enum AVPacketSideDataType {
> >> */
> >> AV_PKT_DATA_A53_CC,
> >>
> >> +/**
> >> + * This side data is encryption "initialization data".
> >> + * For MP4 this is the entire 'pssh' box.
On Fri, 5 Jan 2018 10:22:31 -0800
Jacob Trimble wrote:
> Just noticed the new files were in libavcodec, moved to libavutil.
> Can someone please review this so it can be pushed. I have the MP4
> implementation ready and I would like to get that reviewed and pushed
> as soon as possible.
I'd ass
On Tue, Jan 2, 2018 at 9:57 AM, Jacob Trimble wrote:
> On Wed, Dec 20, 2017 at 4:31 PM, wm4 wrote:
>> On Wed, 20 Dec 2017 15:10:43 -0800
>> Jacob Trimble wrote:
>>
>>> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep 17 00:00:00 2001
>>> From: Jacob Trimble
>>> Date: Tue, 5 Dec 2017 14:52:
On Wed, Dec 20, 2017 at 4:31 PM, wm4 wrote:
> On Wed, 20 Dec 2017 15:10:43 -0800
> Jacob Trimble wrote:
>
>> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep 17 00:00:00 2001
>> From: Jacob Trimble
>> Date: Tue, 5 Dec 2017 14:52:22 -0800
>> Subject: [PATCH] avcodec/avcodec.h: Add encryption
On Wed, 20 Dec 2017 15:10:43 -0800
Jacob Trimble wrote:
> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep 17 00:00:00 2001
> From: Jacob Trimble
> Date: Tue, 5 Dec 2017 14:52:22 -0800
> Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.
>
> This new side-data will contain
On Wed, Dec 20, 2017 at 12:23 PM, wm4 wrote:
> On Wed, 20 Dec 2017 12:07:09 -0800
> Jacob Trimble wrote:
>
>> On Tue, Dec 19, 2017 at 3:05 PM, wm4 wrote:
>> > On Tue, 19 Dec 2017 14:20:38 -0800
>> > Jacob Trimble wrote:
>> >
>> >> > I don't think this is sane. So far, side data could simply be
On Wed, 20 Dec 2017 12:07:09 -0800
Jacob Trimble wrote:
> On Tue, Dec 19, 2017 at 3:05 PM, wm4 wrote:
> > On Tue, 19 Dec 2017 14:20:38 -0800
> > Jacob Trimble wrote:
> >
> >> > I don't think this is sane. So far, side data could simply be copied
> >> > with memcpy, and having pointers to non-st
On Tue, Dec 19, 2017 at 3:05 PM, wm4 wrote:
> On Tue, 19 Dec 2017 14:20:38 -0800
> Jacob Trimble wrote:
>
>> > I don't think this is sane. So far, side data could simply be copied
>> > with memcpy, and having pointers to non-static data in side data would
>> > break this completely
>>
>> Then how
On Tue, 19 Dec 2017 14:20:38 -0800
Jacob Trimble wrote:
> > You pretty much did. Side data is an ffmpeg internal concept, and if
> > your hypothetical streaming protocol needs special support for side
> > data, it's automatically relying on ffmpeg internals.
>
> I thought side data was public
> You pretty much did. Side data is an ffmpeg internal concept, and if
> your hypothetical streaming protocol needs special support for side
> data, it's automatically relying on ffmpeg internals.
I thought side data was public data? Doesn't it contain public info
like display info and required d
On Mon, Dec 18, 2017 at 06:29:14PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 6:00 PM, Michael Niedermayer > wrote:
>
> > If you decode this again you need the side data in the format of the
> > platform
> > the decoder runs on. This is very very basic logic. Something must
On Tue, 19 Dec 2017 01:14:37 +0100
Michael Niedermayer wrote:
> On Tue, Dec 19, 2017 at 12:17:11AM +0100, wm4 wrote:
> > On Tue, 19 Dec 2017 00:00:15 +0100
> > Michael Niedermayer wrote:
> >
> > > On Mon, Dec 18, 2017 at 10:28:14PM +0100, wm4 wrote:
> > > > On Mon, 18 Dec 2017 22:17:14 +010
On Tue, Dec 19, 2017 at 12:17:11AM +0100, wm4 wrote:
> On Tue, 19 Dec 2017 00:00:15 +0100
> Michael Niedermayer wrote:
>
> > On Mon, Dec 18, 2017 at 10:28:14PM +0100, wm4 wrote:
> > > On Mon, 18 Dec 2017 22:17:14 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Mon, Dec 18, 2017 at 10:
On Tue, 19 Dec 2017 00:36:36 +0100
Carl Eugen Hoyos wrote:
> 2017-12-19 0:17 GMT+01:00 wm4 :
>
> [...]
>
> Instead of sending random insults, could you just go away?
Why don't you follow your own advice? At this point you're acting like
a miserable troll who has absolutely nothing to contribut
2017-12-19 0:17 GMT+01:00 wm4 :
[...]
Instead of sending random insults, could you just go away?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
On Mon, Dec 18, 2017 at 6:00 PM, Michael Niedermayer wrote:
> If you decode this again you need the side data in the format of the
> platform
> the decoder runs on. This is very very basic logic. Something must convert
> it
Right, this concept is typically called a "serializer" and "deseri
On Tue, 19 Dec 2017 00:00:15 +0100
Michael Niedermayer wrote:
> On Mon, Dec 18, 2017 at 10:28:14PM +0100, wm4 wrote:
> > On Mon, 18 Dec 2017 22:17:14 +0100
> > Michael Niedermayer wrote:
> >
> > > On Mon, Dec 18, 2017 at 10:02:52PM +0100, wm4 wrote:
> > > > On Mon, 18 Dec 2017 21:38:24 +010
On Mon, Dec 18, 2017 at 10:28:14PM +0100, wm4 wrote:
> On Mon, 18 Dec 2017 22:17:14 +0100
> Michael Niedermayer wrote:
>
> > On Mon, Dec 18, 2017 at 10:02:52PM +0100, wm4 wrote:
> > > On Mon, 18 Dec 2017 21:38:24 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Mon, Dec 18, 2017 at 04:
On Mon, 18 Dec 2017 22:17:14 +0100
Michael Niedermayer wrote:
> On Mon, Dec 18, 2017 at 10:02:52PM +0100, wm4 wrote:
> > On Mon, 18 Dec 2017 21:38:24 +0100
> > Michael Niedermayer wrote:
> >
> > > On Mon, Dec 18, 2017 at 04:56:08PM -0300, James Almer wrote:
> > > > On 12/18/2017 4:52 PM, wm
On Mon, Dec 18, 2017 at 10:02:52PM +0100, wm4 wrote:
> On Mon, 18 Dec 2017 21:38:24 +0100
> Michael Niedermayer wrote:
>
> > On Mon, Dec 18, 2017 at 04:56:08PM -0300, James Almer wrote:
> > > On 12/18/2017 4:52 PM, wm4 wrote:
> > > > On Fri, 15 Dec 2017 14:24:17 -0800
> > > > Jacob Trimble wro
On Mon, 18 Dec 2017 21:38:24 +0100
Michael Niedermayer wrote:
> On Mon, Dec 18, 2017 at 04:56:08PM -0300, James Almer wrote:
> > On 12/18/2017 4:52 PM, wm4 wrote:
> > > On Fri, 15 Dec 2017 14:24:17 -0800
> > > Jacob Trimble wrote:
> > >
> > >> From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 M
On Mon, 18 Dec 2017 16:56:08 -0300
James Almer wrote:
> On 12/18/2017 4:52 PM, wm4 wrote:
> > On Fri, 15 Dec 2017 14:24:17 -0800
> > Jacob Trimble wrote:
> >
> >> From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
> >> From: Jacob Trimble
> >> Date: Tue, 5 Dec 2017 14:52:
On Mon, Dec 18, 2017 at 04:56:08PM -0300, James Almer wrote:
> On 12/18/2017 4:52 PM, wm4 wrote:
> > On Fri, 15 Dec 2017 14:24:17 -0800
> > Jacob Trimble wrote:
> >
> >> From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
> >> From: Jacob Trimble
> >> Date: Tue, 5 Dec 2017 14:
On 12/18/2017 4:52 PM, wm4 wrote:
> On Fri, 15 Dec 2017 14:24:17 -0800
> Jacob Trimble wrote:
>
>> From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
>> From: Jacob Trimble
>> Date: Tue, 5 Dec 2017 14:52:22 -0800
>> Subject: [PATCH] avcodec/avcodec.h: Add encryption info side
On Fri, 15 Dec 2017 14:24:17 -0800
Jacob Trimble wrote:
> From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
> From: Jacob Trimble
> Date: Tue, 5 Dec 2017 14:52:22 -0800
> Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.
>
> This new side-data will contain
>> @@ -1327,6 +1384,19 @@ enum AVPacketSideDataType {
>> */
>> AV_PKT_DATA_A53_CC,
>>
>> +/**
>> + * This side data is encryption "initialization data".
>> + * For MP4 this is the entire 'pssh' box.
>> + * For WebM this is the key ID.
>> + */
>> +AV_PKT_DATA_ENCRY
On Fri, Dec 15, 2017 at 02:24:17PM -0800, Jacob Trimble wrote:
> >> +
> >> +/** The ID of the key used to encrypt the packet. */
> >> +uint8_t key_id[16];
> >> +
> >> +/** The initialization vector. */
> >> +uint8_t iv[16];
> >
> > what happens if the key or iv is longer ?
>
> Both
>> +
>> +/** The ID of the key used to encrypt the packet. */
>> +uint8_t key_id[16];
>> +
>> +/** The initialization vector. */
>> +uint8_t iv[16];
>
> what happens if the key or iv is longer ?
Both are specified by common encryption to be exactly that size. To
be able to be
long
On Fri, Dec 08, 2017 at 10:06:13AM -0800, Jacob Trimble wrote:
> On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
> wrote:
> > On 12/6/2017 12:36 AM, Jacob Trimble wrote:
> >> Would a 0-length array work? Otherwise I would need to have it be a
> >> 1-length array and have to account for that when
On Fri, Dec 8, 2017 at 10:06 AM, Jacob Trimble wrote:
> On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
> wrote:
>> On 12/6/2017 12:36 AM, Jacob Trimble wrote:
>>> Would a 0-length array work? Otherwise I would need to have it be a
>>> 1-length array and have to account for that when calculatin
On Tue, Dec 5, 2017 at 5:22 PM, Derek Buitenhuis
wrote:
> On 12/6/2017 12:36 AM, Jacob Trimble wrote:
>> Would a 0-length array work? Otherwise I would need to have it be a
>> 1-length array and have to account for that when calculating the size
>> to allocate; it would also require a comment to
On 12/6/2017 12:36 AM, Jacob Trimble wrote:
> Would a 0-length array work? Otherwise I would need to have it be a
> 1-length array and have to account for that when calculating the size
> to allocate; it would also require a comment to ignore the size of the
> array.
Aren't 0-length arrays a GNU
On Tue, Dec 5, 2017 at 3:25 PM, Derek Buitenhuis
wrote:
> On 12/5/2017 11:00 PM, Jacob Trimble wrote:
>> Also, can I use the flexible array member feature, it was introduced
>> in C99? Would a 0-length array be better?
>
> No, I don't think this would be OK inside a public header, unfortunately.
On 12/5/2017 11:00 PM, Jacob Trimble wrote:
> Also, can I use the flexible array member feature, it was introduced
> in C99? Would a 0-length array be better?
No, I don't think this would be OK inside a public header, unfortunately.
- Derek
___
ffmpeg-
I am trying to playback encrypted content. I know that libavformat
handles decryption already when using clearkey, but I want to handle
the decryption myself. The encryption info is parsed in mov.c but not
exposed to the app.
This adds some structures to hold new side-data that will hold the
inf
41 matches
Mail list logo
