On Fri, Nov 10, 2017 at 6:07 PM Aman Gupta <ffm...@tmm1.net> wrote:
> On Fri, Nov 10, 2017 at 5:45 PM, James Almer <jamr...@gmail.com> wrote:
>
>> On 11/10/2017 6:40 PM, Aman Gupta wrote:
>> > From: Aman Gupta <a...@tmm1.net>
>> >
>> > ---
>> > libavcodec/avcodec.h | 14 ++++++++++++++
>> > 1 file changed, 14 insertions(+)
>> >
>> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> > index c4134424f0..2bd46faa50 100644
>> > --- a/libavcodec/avcodec.h
>> > +++ b/libavcodec/avcodec.h
>> > @@ -3459,6 +3459,20 @@ typedef struct AVHWAccel {
>> > */
>> > int (*start_frame)(AVCodecContext *avctx, const uint8_t *buf,
>> uint32_t buf_size);
>> >
>> > + /**
>> > + * Callback for parameter data (SPS/PPS/VPS etc).
>> > + *
>> > + * Useful for hardware decoders which keep persistent state about
>> the
>> > + * video parameters, and need to receive any changes to update
>> that state.
>> > + *
>> > + * @param avctx the codec context
>> > + * @param type the parameter type
>> > + * @param buf the slice data buffer base
>> > + * @param buf_size the size of the slice in bytes
>> > + * @return zero if successful, a negative value otherwise
>> > + */
>> > + int (*decode_params)(AVCodecContext *avctx, int type, const
>> uint8_t *buf, uint32_t buf_size);
>> > +
>> > /**
>> > * Callback for each slice.
>> > *
>> >
>>
>> There's
>>
>> https://git.libav.org/?p=libav.git;a=commitdiff;h=b46a77f19ddc4b2b5fa3187835ceb602a5244e24s
>> in the merge queue, and it would be great if we can make sure we're not
>> duplicating efforts or writing incompatible API for the same purpose.
>>
>> Are these related, and can they coexist?
>>
>
> I don't think they're related, and they should be able to coexist without
> issues (I already tested my patches against a libav based tree earlier
> today).
>
> For the purposes of VideoToolbox, I need the raw SPS/PPS/VPS/SEI_* NALUs
> so that they can be fed into the decoder. I've submitted multiple
> variations of this patch to the list over the past year. The first simply
> added a pix_fmt==VIDEOTOOLBOX check, and it was suggested that I
> re-implement with a more generic callback so I added this one in later
> revisions.
>
> I will say that I'm not fully sold on the callback name "decode_params",
> so if anyone has better suggestions I'm all ears.
>
One suggestion I received off-list was to make this decode_nal_unit and
pass in all NALs, leaving it up to the receiver to decide which ones they
care about.
This could be more useful as a general purpose solution, but I think I
still prefer the current approach since it solves a specific issue (instead
of something generic that might or might not be useful to other accels).
Aman
> Aman
>
>
>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
