Re: [FFmpeg-devel] [PATCH 3/3] h264: fix data-race with FF_DECODE_ERROR_DECODE_SLICES

2023-09-13 Thread Thomas Guillem via ffmpeg-devel 



On Tue, Sep 12, 2023, at 15:11, Andreas Rheinhardt wrote:
> Thomas Guillem via ffmpeg-devel:
>> Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES
>> 
>> Fix the following data-race:
>> 
>> WARNING: ThreadSanitizer: data race (pid=55935)
>>   Write of size 4 at 0x7b509378 by thread T1 (mutexes: write M608):
>> #0 decode_nal_units src/libavcodec/h264dec.c:742 (ffmpeg+0xb19dd6)
>> #1 h264_decode_frame src/libavcodec/h264dec.c:1016 (ffmpeg+0xb19dd6)
>> #2 frame_worker_thread src/libavcodec/pthread_frame.c:228 
>> (ffmpeg+0xdeea7e)
>> 
>>   Previous read of size 4 at 0x7b509378 by thread T14 (mutexes: write 
>> M610):
>> #0 frame_copy_props src/libavutil/frame.c:321 (ffmpeg+0x1793759)
>> #1 av_frame_replace src/libavutil/frame.c:530 (ffmpeg+0x1794714)
>> #2 ff_thread_replace_frame src/libavcodec/utils.c:898 (ffmpeg+0xfb1d0f)
>> #3 ff_h264_replace_picture src/libavcodec/h264_picture.c:159 
>> (ffmpeg+0x149cd3d)
>> #4 ff_h264_update_thread_context src/libavcodec/h264_slice.c:413 
>> (ffmpeg+0x14abf04)
>> #5 update_context_from_thread src/libavcodec/pthread_frame.c:355 
>> (ffmpeg+0xdec39c)
>> #6 submit_packet src/libavcodec/pthread_frame.c:494 (ffmpeg+0xdecee3)
>> #7 ff_thread_decode_frame src/libavcodec/pthread_frame.c:545 
>> (ffmpeg+0xdecee3)
>> #8 decode_simple_internal src/libavcodec/decode.c:431 (ffmpeg+0x9e1e20)
>> #9 decode_simple_receive_frame src/libavcodec/decode.c:607 
>> (ffmpeg+0x9e1e20)
>> #10 decode_receive_frame_internal src/libavcodec/decode.c:635 
>> (ffmpeg+0x9e1e20)
>> #11 avcodec_send_packet src/libavcodec/decode.c:732 (ffmpeg+0x9e28fa)
>> #12 packet_decode src/fftools/ffmpeg_dec.c:555 (ffmpeg+0x229888)
>> #13 decoder_thread src/fftools/ffmpeg_dec.c:702 (ffmpeg+0x229888)
>> ---
>>  libavcodec/h264dec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>> index 24e849fc5b..b82ca8f14f 100644
>> --- a/libavcodec/h264dec.c
>> +++ b/libavcodec/h264dec.c
>> @@ -739,7 +739,7 @@ static int decode_nal_units(H264Context *h, const 
>> uint8_t *buf, int buf_size)
>>  
>>  // set decode_error_flags to allow users to detect concealed decoding 
>> errors
>>  if ((ret < 0 || h->er.error_occurred) && h->cur_pic_ptr) {
>> -h->cur_pic_ptr->f->decode_error_flags |= 
>> FF_DECODE_ERROR_DECODE_SLICES;
>> +h->cur_pic_ptr->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
>>  }
>>  
>>  ret = 0;
>
> IIRC this does not work: The thread that decodes a frame is typically
> not the same thread that outputs said frame. The H264Picture srcp in
> output_frame() points to one of the H264Picture in the H264Context.DBP
> of the outputting thread, not the decoding thread. The outputting
> threads decode_error_flags will therefore always be zero.
>
> My preferred way to fix this is to allocate the H264Pictures (or at
> least the stuff needed by later decoding threads) separately and make
> them shared between decoder threads (with the caveat that only the
> actual decoding threads may modify them; and they may only do so in a
> controlled manner (i.e. no changes after having signalled to finish the
> picture etc.). But this would be a major rewrite which will probably
> never happen.
>
> In the meantime i will send an alternative patch for this.

Thanks for your patches and your clear explanations !

>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] h264: fix data-race with FF_DECODE_ERROR_CONCEALMENT_ACTIVE

2023-09-12 Thread Thomas Guillem via ffmpeg-devel 
Set the FF_DECODE_ERROR_CONCEALMENT_ACTIVE flags on the AVFrane before
outputing it. Store in in the H264Picture in the meantime, where it
won't be read/write by other threads.

Fix the following data-race:

WARNING: ThreadSanitizer: data race (pid=55134)
  Write of size 4 at 0x7b507f78 by thread T1 (mutexes: write M58):
#0 decode_nal_units src/libavcodec/h264dec.c:783 (ffmpeg+0xb1a678)
#1 h264_decode_frame src/libavcodec/h264dec.c:1014 (ffmpeg+0xb1a678)
#2 frame_worker_thread src/libavcodec/pthread_frame.c:228 (ffmpeg+0xdeea6e)

  Previous read of size 4 at 0x7b507f78 by thread T14 (mutexes: write M60):
#0 frame_copy_props src/libavutil/frame.c:321 (ffmpeg+0x1793739)
#1 av_frame_replace src/libavutil/frame.c:530 (ffmpeg+0x17946f4)
#2 ff_thread_replace_frame src/libavcodec/utils.c:898 (ffmpeg+0xfb1cff)
#3 ff_h264_replace_picture src/libavcodec/h264_picture.c:159 
(ffmpeg+0x149cd2d)
#4 ff_h264_update_thread_context src/libavcodec/h264_slice.c:413 
(ffmpeg+0x14abee4)
#5 update_context_from_thread src/libavcodec/pthread_frame.c:355 
(ffmpeg+0xdec38c)
#6 submit_packet src/libavcodec/pthread_frame.c:494 (ffmpeg+0xdeced3)
#7 ff_thread_decode_frame src/libavcodec/pthread_frame.c:545 
(ffmpeg+0xdeced3)
#8 decode_simple_internal src/libavcodec/decode.c:431 (ffmpeg+0x9e1e20)
#9 decode_simple_receive_frame src/libavcodec/decode.c:607 (ffmpeg+0x9e1e20)
#10 decode_receive_frame_internal src/libavcodec/decode.c:635 
(ffmpeg+0x9e1e20)
#11 avcodec_send_packet src/libavcodec/decode.c:732 (ffmpeg+0x9e28fa)
#12 packet_decode src/fftools/ffmpeg_dec.c:555 (ffmpeg+0x229888)
#13 decoder_thread src/fftools/ffmpeg_dec.c:702 (ffmpeg+0x229888)
---
 libavcodec/h264_slice.c | 1 +
 libavcodec/h264dec.c| 4 +++-
 libavcodec/h264dec.h| 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6cd7bb8fe7..249c764d13 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -535,6 +535,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 pic->f->crop_right  = h->crop_right;
 pic->f->crop_top= h->crop_top;
 pic->f->crop_bottom = h->crop_bottom;
+pic->decode_error_flags = 0;
 
 pic->needs_fg = h->sei.common.film_grain_characteristics.present && 
!h->avctx->hwaccel &&
 !(h->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN);
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 553f300c3d..24e849fc5b 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -780,7 +780,7 @@ end:
 ff_h264_set_erpic(>er.next_pic, sl->ref_list[1][0].parent);
 
 if (ff_er_frame_end(>er) > 0)
-h->cur_pic_ptr->f->decode_error_flags |= 
FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
+h->cur_pic_ptr->decode_error_flags |= 
FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
 if (use_last_pic)
 memset(>ref_list[0][0], 0, sizeof(sl->ref_list[0][0]));
 }
@@ -849,6 +849,8 @@ static int output_frame(H264Context *h, AVFrame *dst, 
H264Picture *srcp)
 if (ret < 0)
 return ret;
 
+dst->decode_error_flags |= srcp->decode_error_flags;
+
 if (srcp->needs_fg && (ret = av_frame_copy_props(dst, srcp->f)) < 0)
 return ret;
 
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index beaab3902c..cb3d5cef00 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -152,6 +152,8 @@ typedef struct H264Picture {
 
 int mb_width, mb_height;
 int mb_stride;
+
+int decode_error_flags;
 } H264Picture;
 
 typedef struct H264Ref {
-- 
2.39.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] h264: fix data-race with FF_DECODE_ERROR_DECODE_SLICES

2023-09-12 Thread Thomas Guillem via ffmpeg-devel 
Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES

Fix the following data-race:

WARNING: ThreadSanitizer: data race (pid=55935)
  Write of size 4 at 0x7b509378 by thread T1 (mutexes: write M608):
#0 decode_nal_units src/libavcodec/h264dec.c:742 (ffmpeg+0xb19dd6)
#1 h264_decode_frame src/libavcodec/h264dec.c:1016 (ffmpeg+0xb19dd6)
#2 frame_worker_thread src/libavcodec/pthread_frame.c:228 (ffmpeg+0xdeea7e)

  Previous read of size 4 at 0x7b509378 by thread T14 (mutexes: write M610):
#0 frame_copy_props src/libavutil/frame.c:321 (ffmpeg+0x1793759)
#1 av_frame_replace src/libavutil/frame.c:530 (ffmpeg+0x1794714)
#2 ff_thread_replace_frame src/libavcodec/utils.c:898 (ffmpeg+0xfb1d0f)
#3 ff_h264_replace_picture src/libavcodec/h264_picture.c:159 
(ffmpeg+0x149cd3d)
#4 ff_h264_update_thread_context src/libavcodec/h264_slice.c:413 
(ffmpeg+0x14abf04)
#5 update_context_from_thread src/libavcodec/pthread_frame.c:355 
(ffmpeg+0xdec39c)
#6 submit_packet src/libavcodec/pthread_frame.c:494 (ffmpeg+0xdecee3)
#7 ff_thread_decode_frame src/libavcodec/pthread_frame.c:545 
(ffmpeg+0xdecee3)
#8 decode_simple_internal src/libavcodec/decode.c:431 (ffmpeg+0x9e1e20)
#9 decode_simple_receive_frame src/libavcodec/decode.c:607 (ffmpeg+0x9e1e20)
#10 decode_receive_frame_internal src/libavcodec/decode.c:635 
(ffmpeg+0x9e1e20)
#11 avcodec_send_packet src/libavcodec/decode.c:732 (ffmpeg+0x9e28fa)
#12 packet_decode src/fftools/ffmpeg_dec.c:555 (ffmpeg+0x229888)
#13 decoder_thread src/fftools/ffmpeg_dec.c:702 (ffmpeg+0x229888)
---
 libavcodec/h264dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 24e849fc5b..b82ca8f14f 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -739,7 +739,7 @@ static int decode_nal_units(H264Context *h, const uint8_t 
*buf, int buf_size)
 
 // set decode_error_flags to allow users to detect concealed decoding 
errors
 if ((ret < 0 || h->er.error_occurred) && h->cur_pic_ptr) {
-h->cur_pic_ptr->f->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
+h->cur_pic_ptr->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
 }
 
 ret = 0;
-- 
2.39.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] error_resilience: set the decode_error_flags outside

2023-09-12 Thread Thomas Guillem via ffmpeg-devel 
This will allow to fix data-races when ff_er_frame_end() is called after
ff_thread_finish_setup()
---
 libavcodec/error_resilience.c | 12 ++--
 libavcodec/error_resilience.h |  2 +-
 libavcodec/h263dec.c  |  6 --
 libavcodec/h264dec.c  |  3 ++-
 libavcodec/mpeg12dec.c|  3 ++-
 libavcodec/mss2.c |  8 +---
 libavcodec/rv10.c | 10 --
 libavcodec/rv34.c | 12 +---
 libavcodec/vc1dec.c   |  6 --
 9 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index 68e20925e0..1f43b233ff 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -889,7 +889,7 @@ void ff_er_add_slice(ERContext *s, int startx, int starty,
 }
 }
 
-void ff_er_frame_end(ERContext *s)
+int ff_er_frame_end(ERContext *s)
 {
 int *linesize = NULL;
 int i, mb_x, mb_y, error, error_type, dc_error, mv_error, ac_error;
@@ -906,7 +906,7 @@ void ff_er_frame_end(ERContext *s)
 !er_supported(s)   ||
 atomic_load(>error_count) == 3 * s->mb_width *
   (s->avctx->skip_top + s->avctx->skip_bottom)) {
-return;
+return 0;
 }
 linesize = s->cur_pic.f->linesize;
 
@@ -921,7 +921,7 @@ void ff_er_frame_end(ERContext *s)
 
 if (mb_x == s->mb_width) {
 av_log(s->avctx, AV_LOG_DEBUG, "ignoring last missing slice\n");
-return;
+return 0;
 }
 }
 
@@ -960,7 +960,7 @@ void ff_er_frame_end(ERContext *s)
 s->cur_pic.ref_index[i]  = NULL;
 s->cur_pic.motion_val[i] = NULL;
 }
-return;
+return 0;
 }
 }
 
@@ -1114,8 +1114,6 @@ void ff_er_frame_end(ERContext *s)
 av_log(s->avctx, AV_LOG_INFO, "concealing %d DC, %d AC, %d MV errors in %c 
frame\n",
dc_error, ac_error, mv_error, 
av_get_picture_type_char(s->cur_pic.f->pict_type));
 
-s->cur_pic.f->decode_error_flags |= FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
-
 is_intra_likely = is_intra_more_likely(s);
 
 /* set unknown mb-type to most likely */
@@ -1352,4 +1350,6 @@ void ff_er_frame_end(ERContext *s)
 memset(>cur_pic, 0, sizeof(ERPicture));
 memset(>last_pic, 0, sizeof(ERPicture));
 memset(>next_pic, 0, sizeof(ERPicture));
+
+return 1;
 }
diff --git a/libavcodec/error_resilience.h b/libavcodec/error_resilience.h
index 47cc8a4fc6..a8cf73c72e 100644
--- a/libavcodec/error_resilience.h
+++ b/libavcodec/error_resilience.h
@@ -90,7 +90,7 @@ typedef struct ERContext {
 } ERContext;
 
 void ff_er_frame_start(ERContext *s);
-void ff_er_frame_end(ERContext *s);
+int ff_er_frame_end(ERContext *s);
 void ff_er_add_slice(ERContext *s, int startx, int starty, int endx, int endy,
  int status);
 
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 52e51dd489..3e83d90586 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -621,8 +621,10 @@ retry:
 
 av_assert1(s->bitstream_buffer_size == 0);
 frame_end:
-if (!s->studio_profile)
-ff_er_frame_end(>er);
+if (!s->studio_profile) {
+if (ff_er_frame_end(>er) > 0)
+s->current_picture.f->decode_error_flags |= 
FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
+}
 
 if (avctx->hwaccel) {
 ret = FF_HW_SIMPLE_CALL(avctx, end_frame);
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index f13b1081fc..553f300c3d 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -779,7 +779,8 @@ end:
 if (sl->ref_count[1])
 ff_h264_set_erpic(>er.next_pic, sl->ref_list[1][0].parent);
 
-ff_er_frame_end(>er);
+if (ff_er_frame_end(>er) > 0)
+h->cur_pic_ptr->f->decode_error_flags |= 
FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
 if (use_last_pic)
 memset(>ref_list[0][0], 0, sizeof(sl->ref_list[0][0]));
 }
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 1accd07e9e..b2cc78c3d3 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2033,7 +2033,8 @@ static int slice_end(AVCodecContext *avctx, AVFrame *pict)
 if (/* s->mb_y << field_pic == s->mb_height && */ !s->first_field && 
!s1->first_slice) {
 /* end of image */
 
-ff_er_frame_end(>er);
+if (ff_er_frame_end(>er) > 0)
+s->current_picture_ptr->f->decode_error_flags |= 
FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
 
 ff_mpv_frame_end(s);
 
diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
index 70aa56cb84..29cb4be614 100644
--- a/libavcodec/mss2.c
+++ b/libavcodec/mss2.c
@@ -421,8 +421,12 @@ static int decode_wmv9(AVCodecContext *avctx, const 
uint8_t *buf, int buf_size,
 
 ff_vc1_decode_blocks(v);
 
+f = s->current_picture.f;
+
 if (v->end_mb_x == s->mb_width && s->end_mb_y == s->mb_height) {
-ff_er_frame_end(>er);
+if

Re: [FFmpeg-devel] [PATCH] avformat/riff: add more GeoVision FOURCC

2022-02-17 Thread Thomas Guillem 
Hello,

Sorry, but I'm not allowed to share these cameras' footage.

I was able to test them, and it runs fine on last ffmpeg.

On Thu, Feb 17, 2022, at 15:32, Michael Niedermayer wrote:
> On Thu, Feb 17, 2022 at 11:01:38AM +0100, Thomas Guillem wrote:
>> ---
>>  libavformat/riff.c | 2 ++
>>  1 file changed, 2 insertions(+)
>
> please provide a link or sample file for these
>
> the change itself should be ok
>
> thx
>
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> Attachments:
> * signature.asc
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/riff: add more GeoVision FOURCC

2022-02-17 Thread Thomas Guillem 
---
 libavformat/riff.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 27a9706510..23e6306b66 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -32,6 +32,7 @@
  * files use it as well.
  */
 const AVCodecTag ff_codec_bmp_tags[] = {
+{ AV_CODEC_ID_H265, MKTAG('G', 'H', 'E', 'C') }, /* GeoVision 
camera */
 { AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
 { AV_CODEC_ID_H264, MKTAG('h', '2', '6', '4') },
 { AV_CODEC_ID_H264, MKTAG('X', '2', '6', '4') },
@@ -115,6 +116,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_MPEG4,MKTAG('P', 'L', 'V', '1') }, /* Pelco DVR 
MPEG-4 */
 { AV_CODEC_ID_MPEG4,MKTAG('G', 'L', 'V', '4') },
 { AV_CODEC_ID_MPEG4,MKTAG('G', 'M', 'P', '4') }, /* GeoVision 
camera */
+{ AV_CODEC_ID_MPEG4,MKTAG('G', 'M', '4', '0') }, /* GeoVision 
camera */
 { AV_CODEC_ID_MPEG4,MKTAG('M', 'N', 'M', '4') }, /* March Networks 
DVR */
 { AV_CODEC_ID_MPEG4,MKTAG('G', 'T', 'M', '4') }, /* Telefactor */
 { AV_CODEC_ID_MSMPEG4V3,MKTAG('M', 'P', '4', '3') },
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: fix hw_device_ctx leak

2021-12-03 Thread Thomas Guillem 



On Fri, Dec 3, 2021, at 09:52, Anton Khirnov wrote:
> Quoting Thomas Guillem (2021-12-02 20:44:33)
>> 
>> On Thu, Dec 2, 2021, at 15:05, Andreas Rheinhardt wrote:
>> > 1. hw_device_ctx is in the public AVCodecContext, not in the private
>> > AVCodecInternal.
>> > 2. ctx->internal is intended to be allocated for all the internal
>> > AVCodecContexts; the check is only there to ensure that we don't crash
>> > if an allocation error happens.
>> > 3. libavcodec only ever modifies avctx->hw_device_ctx at one place: in
>> > avcodec_close() where is unreferences the reference (if any). So if it
>> > was set in avcodec_open2() and NULL in avcodec_close() (i.e. immediately
>> > before avcodec_close()), it has been modified somehow and you need to
>> > find out who did it.
>> > 4. Some parts of the code use hw_device_ctx to derive references from
>> > it. Maybe one of these references did not get freed?
>> > (5. What do Valgrind/ASAN say? When was the reference that leaked created?)
>> 
>> OK, all your point are valid, I missed a precious comment from the avcodec.h 
>> API:
>> "For both encoders and decoders this field should be set before
>>  avcodec_open2() is called and must not be written to thereafter."
>> 
>> Hence, the incomprehension.
>> 
>> So, to sum up: the reference that leaks is created from VLC, from the 
>> get_format() callback.
>> Looking at pthread_frame.c, it seems that get_format() is called with a 
>> AVCodecContext owned by a PerThreadContext, so not the main AVCodecContext. 
>> That is why avcodec_close() is not closing it.
>> 
>> I just discovered that it's not officially supported then, but I really 
>> don't see any other way to plug VAAPI between VLC and ffmpeg.
>> 
>> I explain: VLC can't know the hw_device that will be used when it calls 
>> avcodec_open2(). VLC has a similar struct than hw_device, called dec_device. 
>> For VAAPI, this struct hold the va_dpy that is created when the VLC avcodec 
>> module first create the video output, from the get_format() callback.
>> 
>> I see 2 possibilities:
>> 1/ Patch the documentation and allow to set a hw_device_ctx from 
>> get_format(), review all use case of hw_device_ctx to check if there is no 
>> inconsistency with this new change.
>> 2/ Use any other way to pass the va_dpy from the get_format()? I didn't see 
>> any, but maybe I missed something obvious.
>
> 2. is the right answer - you're supposed to set hw_frames_ctx, possibly
> using the avcodec_get_hw_frames_parameters() helper function.

Thanks! That is exactly what I needed.


>
> -- 
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: fix hw_device_ctx leak

2021-12-02 Thread Thomas Guillem 


On Thu, Dec 2, 2021, at 15:05, Andreas Rheinhardt wrote:
> 1. hw_device_ctx is in the public AVCodecContext, not in the private
> AVCodecInternal.
> 2. ctx->internal is intended to be allocated for all the internal
> AVCodecContexts; the check is only there to ensure that we don't crash
> if an allocation error happens.
> 3. libavcodec only ever modifies avctx->hw_device_ctx at one place: in
> avcodec_close() where is unreferences the reference (if any). So if it
> was set in avcodec_open2() and NULL in avcodec_close() (i.e. immediately
> before avcodec_close()), it has been modified somehow and you need to
> find out who did it.
> 4. Some parts of the code use hw_device_ctx to derive references from
> it. Maybe one of these references did not get freed?
> (5. What do Valgrind/ASAN say? When was the reference that leaked created?)

OK, all your point are valid, I missed a precious comment from the avcodec.h 
API:
"For both encoders and decoders this field should be set before
 avcodec_open2() is called and must not be written to thereafter."

Hence, the incomprehension.

So, to sum up: the reference that leaks is created from VLC, from the 
get_format() callback.
Looking at pthread_frame.c, it seems that get_format() is called with a 
AVCodecContext owned by a PerThreadContext, so not the main AVCodecContext. 
That is why avcodec_close() is not closing it.

I just discovered that it's not officially supported then, but I really don't 
see any other way to plug VAAPI between VLC and ffmpeg.

I explain: VLC can't know the hw_device that will be used when it calls 
avcodec_open2(). VLC has a similar struct than hw_device, called dec_device. 
For VAAPI, this struct hold the va_dpy that is created when the VLC avcodec 
module first create the video output, from the get_format() callback.

I see 2 possibilities:
1/ Patch the documentation and allow to set a hw_device_ctx from get_format(), 
review all use case of hw_device_ctx to check if there is no inconsistency with 
this new change.
2/ Use any other way to pass the va_dpy from the get_format()? I didn't see 
any, but maybe I missed something obvious.

Best,
Thomas

>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: fix hw_device_ctx leak

2021-12-02 Thread Thomas Guillem 



On Thu, Dec 2, 2021, at 14:38, Andreas Rheinhardt wrote:
> Thomas Guillem:
>> Reproduced when using the VAAPI va module on VLC 4.0. No leaks when
>> setting thread count to 1.
>> ---
>>  libavcodec/pthread_frame.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
>> index 73b1b7d7d9..4c578aa44a 100644
>> --- a/libavcodec/pthread_frame.c
>> +++ b/libavcodec/pthread_frame.c
>> @@ -747,6 +747,7 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
>> thread_count)
>>  av_buffer_unref(>internal->pool);
>>  av_freep(>internal);
>>  av_buffer_unref(>hw_frames_ctx);
>> +av_buffer_unref(>hw_device_ctx);
>>  }
>>  
>>  av_frame_free(>frame);
>> 
>
> The AVCodecContext that is freed here is not a full AVCodecContext: It
> never received a reference to hw_device_ctx of its own. Unreferencing
> this here will therefore mess up the refcount and lead to use-after-frees.
> (What is the reference count of hw_device_ctx at this point? Libavcodec
> should only hold one reference at that point, namely the one in the main
> (user-facing) AVCodecContext; this reference will be unreferenced when
> avcodec_close()/avcodec_free_context() is called for the main context.)

Hello Andreas, thanks for the review.

The problem is that hw_device_ctx is NULL when avcodec_close() is called in 
that particular usecase. My first guess is that the get_format callback can be 
called from any avctx (and not necessarily the main one that will be closed by 
avcodec_close().

I'm new to this code, but I thought that only one FrameThreadContext could meet 
the if (ctx->internal) condition, so there should be only one reference to the 
hw_device_ctx.

Best,
Thomas

>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/pthread_frame: fix hw_device_ctx leak

2021-12-02 Thread Thomas Guillem 
Reproduced when using the VAAPI va module on VLC 4.0. No leaks when
setting thread count to 1.
---
 libavcodec/pthread_frame.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 73b1b7d7d9..4c578aa44a 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -747,6 +747,7 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
thread_count)
 av_buffer_unref(>internal->pool);
 av_freep(>internal);
 av_buffer_unref(>hw_frames_ctx);
+av_buffer_unref(>hw_device_ctx);
 }
 
 av_frame_free(>frame);
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-20 Thread Thomas Guillem 


On Thu, Jul 19, 2018, at 18:27, Aman Gupta wrote:
> On Fri, Jul 6, 2018 at 10:55 PM Thomas Guillem  wrote:
> 
> >
> >
> > On Thu, Jul 5, 2018, at 20:49, Aman Gupta wrote:
> > > On Wed, Jul 4, 2018 at 3:05 AM Thomas Guillem  wrote:
> > >
> > > > On macOS, a zero rc_max_rate cause an error from
> > > > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> > > >
> > > > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > > > arguments from the vtenc_output_callback after few frames and then a
> > crash
> > > > within the VideoToolbox library.
> > > > ---
> > > >  libavcodec/videotoolboxenc.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/libavcodec/videotoolboxenc.c
> > b/libavcodec/videotoolboxenc.c
> > > > index ac847358ab..aa9aae7e05 100644
> > > > --- a/libavcodec/videotoolboxenc.c
> > > > +++ b/libavcodec/videotoolboxenc.c
> > > > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> > > >  *avctx,
> > > >
> > > >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> > > >  // kVTCompressionPropertyKey_DataRateLimits is not available
> > for
> > > > HEVC
> > > > +if (max_rate > 0) {
> > >
> > >
> > > I think it would be better to add this condition to the existing if block
> > > above so we can avoid another level of indentation.
> >
> > That's what I first wanted to do but there is a also a profile level in
> > this code block.
> >
> 
> I split the profile block into another conditional, and added max_rate to
> this one. Applied to master and release/4.0
> 
> Aman

OK, Thanks!

> 
> 
> >
> > >
> > > Patch looks fine to me otherwise. I can make this change and commit this
> > > week.
> > >
> > > Aman
> > >
> > >
> > > >  bytes_per_second_value = max_rate >> 3;
> > > >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> > > >kCFNumberSInt64Type,
> > > > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> > > >  *avctx,
> > > >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > > > property: %d\n", status);
> > > >  return AVERROR_EXTERNAL;
> > > >  }
> > > > +}
> > > >
> > > >  if (profile_level) {
> > > >  status = VTSessionSetProperty(vtctx->session,
> > > > --
> > > > 2.18.0
> > > >
> > > > ___
> > > > 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
> > ___
> > 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-06 Thread Thomas Guillem 

On Fri, Jul 6, 2018, at 09:21, Kári Helgason wrote:
> Sorry for jumping in with a slightly OT question,
> 
> Am I understanding correctly that you have noticed that when using kVTCompre
> ssionPropertyKey_DataRateLimits you will sometimes get random garbage from
> the encoder in the output callback?

Not garbage, but the output callback will be called with a 0 error_status (OK 
then) but without any sample_buffer.
Then, a crash within the VT lib will follow.

> 
> How frequently does this happen, and can you reproduce it reliably, or do
> you only see it in production?
> 
> Has a radar been filed with Apple about this?

This issue doesn't reproduce on the iOS 12 beta (with the same device), so I 
guess they are aware or it has been fixed.

> 
> On Wed, Jul 4, 2018 at 1:44 PM Thomas Guillem  wrote:
> 
> > On Wed, Jul 4, 2018, at 09:05, Thomas Guillem wrote:
> > > On macOS, a zero rc_max_rate cause an error from
> > > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> > >
> > > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > > arguments from the vtenc_output_callback after few frames and then a
> > crash
> > > within the VideoToolbox library.
> >
> > In fact, when setting a correct max_rate on iOS, you could still get
> > random crashes the same way. It's happening on ios 11.4 but seems to be OK
> > on iOS 12 Beta.
> >
> > > ---
> > >  libavcodec/videotoolboxenc.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > > index ac847358ab..aa9aae7e05 100644
> > > --- a/libavcodec/videotoolboxenc.c
> > > +++ b/libavcodec/videotoolboxenc.c
> > > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> > >
> > >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> > >  // kVTCompressionPropertyKey_DataRateLimits is not available
> > > for HEVC
> > > +if (max_rate > 0) {
> > >  bytes_per_second_value = max_rate >> 3;
> > >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> > >kCFNumberSInt64Type,
> > > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> > > *avctx,
> > >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > > property: %d\n", status);
> > >  return AVERROR_EXTERNAL;
> > >  }
> > > +}
> > >
> > >  if (profile_level) {
> > >  status = VTSessionSetProperty(vtctx->session,
> > > --
> > > 2.18.0
> > >
> > > ___
> > > 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
> >
> ___
> 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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-06 Thread Thomas Guillem 


On Thu, Jul 5, 2018, at 20:49, Aman Gupta wrote:
> On Wed, Jul 4, 2018 at 3:05 AM Thomas Guillem  wrote:
> 
> > On macOS, a zero rc_max_rate cause an error from
> > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> >
> > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > arguments from the vtenc_output_callback after few frames and then a crash
> > within the VideoToolbox library.
> > ---
> >  libavcodec/videotoolboxenc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index ac847358ab..aa9aae7e05 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> >
> >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> >  // kVTCompressionPropertyKey_DataRateLimits is not available for
> > HEVC
> > +if (max_rate > 0) {
> 
> 
> I think it would be better to add this condition to the existing if block
> above so we can avoid another level of indentation.

That's what I first wanted to do but there is a also a profile level in this 
code block.

> 
> Patch looks fine to me otherwise. I can make this change and commit this
> week.
> 
> Aman
> 
> 
> >  bytes_per_second_value = max_rate >> 3;
> >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> >kCFNumberSInt64Type,
> > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > property: %d\n", status);
> >  return AVERROR_EXTERNAL;
> >  }
> > +}
> >
> >  if (profile_level) {
> >  status = VTSessionSetProperty(vtctx->session,
> > --
> > 2.18.0
> >
> > ___
> > 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-04 Thread Thomas Guillem 
On Wed, Jul 4, 2018, at 09:05, Thomas Guillem wrote:
> On macOS, a zero rc_max_rate cause an error from
> VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> 
> on iOS (depending on device/version), a zero rc_max_rate cause invalid
> arguments from the vtenc_output_callback after few frames and then a crash
> within the VideoToolbox library.

In fact, when setting a correct max_rate on iOS, you could still get random 
crashes the same way. It's happening on ios 11.4 but seems to be OK on iOS 12 
Beta.

> ---
>  libavcodec/videotoolboxenc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index ac847358ab..aa9aae7e05 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
>  
>  if (vtctx->codec_id == AV_CODEC_ID_H264) {
>  // kVTCompressionPropertyKey_DataRateLimits is not available 
> for HEVC
> +if (max_rate > 0) {
>  bytes_per_second_value = max_rate >> 3;
>  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
>kCFNumberSInt64Type,
> @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext   
> *avctx,
>  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate 
> property: %d\n", status);
>  return AVERROR_EXTERNAL;
>  }
> +}
>  
>  if (profile_level) {
>  status = VTSessionSetProperty(vtctx->session,
> -- 
> 2.18.0
> 
> ___
> 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

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-04 Thread Thomas Guillem 

On Tue, Jul 3, 2018, at 20:53, Carl Eugen Hoyos wrote:
> 2018-07-03 17:05 GMT+02:00, Thomas Guillem :
> > On macOS, a zero rc_max_rate cause an error from
> > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> >
> > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > arguments from the vtenc_output_callback after few frames and then a crash
> > within the VideoToolbox library.
> > ---
> >  libavcodec/videotoolboxenc.c | 72 ++--
> >  1 file changed, 37 insertions(+), 35 deletions(-)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index ac847358ab..050e5cefee 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -1019,44 +1019,46 @@ static int vtenc_create_encoder(AVCodecContext
> > *avctx,
> >
> >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> >  // kVTCompressionPropertyKey_DataRateLimits is not available for
> > HEVC
> > -bytes_per_second_value = max_rate >> 3;
> > -bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> > -  kCFNumberSInt64Type,
> > -  _per_second_value);
> > -if (!bytes_per_second) {
> > -return AVERROR(ENOMEM);
> > -}
> > -one_second_value = 1;
> > -one_second = CFNumberCreate(kCFAllocatorDefault,
> > -kCFNumberSInt64Type,
> > -_second_value);
> > -if (!one_second) {
> > -CFRelease(bytes_per_second);
> > -return AVERROR(ENOMEM);
> > -}
> > -nums[0] = (void *)bytes_per_second;
> > -nums[1] = (void *)one_second;
> > -data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
> > - (const void **)nums,
> > - 2,
> > - );
> 
> Please do the re-indentation in a separate patch to make
> reviewing your change easier, both now and on the
> commit mailing list

OK, done, cf. http://ffmpeg.org/pipermail/ffmpeg-devel/2018-July/231931.html

> 
> Carl Eugen
> ___
> 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

[FFmpeg-devel] [PATCH 2/2] avcodec/videotoolboxenc: reindent after previous commit

2018-07-04 Thread Thomas Guillem 
---
 libavcodec/videotoolboxenc.c | 72 ++--
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index aa9aae7e05..050e5cefee 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1020,45 +1020,45 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 if (vtctx->codec_id == AV_CODEC_ID_H264) {
 // kVTCompressionPropertyKey_DataRateLimits is not available for HEVC
 if (max_rate > 0) {
-bytes_per_second_value = max_rate >> 3;
-bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
-  kCFNumberSInt64Type,
-  _per_second_value);
-if (!bytes_per_second) {
-return AVERROR(ENOMEM);
-}
-one_second_value = 1;
-one_second = CFNumberCreate(kCFAllocatorDefault,
-kCFNumberSInt64Type,
-_second_value);
-if (!one_second) {
-CFRelease(bytes_per_second);
-return AVERROR(ENOMEM);
-}
-nums[0] = (void *)bytes_per_second;
-nums[1] = (void *)one_second;
-data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
- (const void **)nums,
- 2,
- );
-
-if (!data_rate_limits) {
+bytes_per_second_value = max_rate >> 3;
+bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
+  kCFNumberSInt64Type,
+  _per_second_value);
+if (!bytes_per_second) {
+return AVERROR(ENOMEM);
+}
+one_second_value = 1;
+one_second = CFNumberCreate(kCFAllocatorDefault,
+kCFNumberSInt64Type,
+_second_value);
+if (!one_second) {
+CFRelease(bytes_per_second);
+return AVERROR(ENOMEM);
+}
+nums[0] = (void *)bytes_per_second;
+nums[1] = (void *)one_second;
+data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
+ (const void **)nums,
+ 2,
+ );
+
+if (!data_rate_limits) {
+CFRelease(bytes_per_second);
+CFRelease(one_second);
+return AVERROR(ENOMEM);
+}
+status = VTSessionSetProperty(vtctx->session,
+  
kVTCompressionPropertyKey_DataRateLimits,
+  data_rate_limits);
+
 CFRelease(bytes_per_second);
 CFRelease(one_second);
-return AVERROR(ENOMEM);
-}
-status = VTSessionSetProperty(vtctx->session,
-  kVTCompressionPropertyKey_DataRateLimits,
-  data_rate_limits);
+CFRelease(data_rate_limits);
 
-CFRelease(bytes_per_second);
-CFRelease(one_second);
-CFRelease(data_rate_limits);
-
-if (status) {
-av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate property: 
%d\n", status);
-return AVERROR_EXTERNAL;
-}
+if (status) {
+av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate 
property: %d\n", status);
+return AVERROR_EXTERNAL;
+}
 }
 
 if (profile_level) {
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-04 Thread Thomas Guillem 
On macOS, a zero rc_max_rate cause an error from
VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).

on iOS (depending on device/version), a zero rc_max_rate cause invalid
arguments from the vtenc_output_callback after few frames and then a crash
within the VideoToolbox library.
---
 libavcodec/videotoolboxenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index ac847358ab..aa9aae7e05 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 
 if (vtctx->codec_id == AV_CODEC_ID_H264) {
 // kVTCompressionPropertyKey_DataRateLimits is not available for HEVC
+if (max_rate > 0) {
 bytes_per_second_value = max_rate >> 3;
 bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
   kCFNumberSInt64Type,
@@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate property: 
%d\n", status);
 return AVERROR_EXTERNAL;
 }
+}
 
 if (profile_level) {
 status = VTSessionSetProperty(vtctx->session,
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-03 Thread Thomas Guillem 
On macOS, a zero rc_max_rate cause an error from
VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).

on iOS (depending on device/version), a zero rc_max_rate cause invalid
arguments from the vtenc_output_callback after few frames and then a crash
within the VideoToolbox library.
---
 libavcodec/videotoolboxenc.c | 72 ++--
 1 file changed, 37 insertions(+), 35 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index ac847358ab..050e5cefee 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1019,44 +1019,46 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 
 if (vtctx->codec_id == AV_CODEC_ID_H264) {
 // kVTCompressionPropertyKey_DataRateLimits is not available for HEVC
-bytes_per_second_value = max_rate >> 3;
-bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
-  kCFNumberSInt64Type,
-  _per_second_value);
-if (!bytes_per_second) {
-return AVERROR(ENOMEM);
-}
-one_second_value = 1;
-one_second = CFNumberCreate(kCFAllocatorDefault,
-kCFNumberSInt64Type,
-_second_value);
-if (!one_second) {
-CFRelease(bytes_per_second);
-return AVERROR(ENOMEM);
-}
-nums[0] = (void *)bytes_per_second;
-nums[1] = (void *)one_second;
-data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
- (const void **)nums,
- 2,
- );
-
-if (!data_rate_limits) {
+if (max_rate > 0) {
+bytes_per_second_value = max_rate >> 3;
+bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
+  kCFNumberSInt64Type,
+  _per_second_value);
+if (!bytes_per_second) {
+return AVERROR(ENOMEM);
+}
+one_second_value = 1;
+one_second = CFNumberCreate(kCFAllocatorDefault,
+kCFNumberSInt64Type,
+_second_value);
+if (!one_second) {
+CFRelease(bytes_per_second);
+return AVERROR(ENOMEM);
+}
+nums[0] = (void *)bytes_per_second;
+nums[1] = (void *)one_second;
+data_rate_limits = CFArrayCreate(kCFAllocatorDefault,
+ (const void **)nums,
+ 2,
+ );
+
+if (!data_rate_limits) {
+CFRelease(bytes_per_second);
+CFRelease(one_second);
+return AVERROR(ENOMEM);
+}
+status = VTSessionSetProperty(vtctx->session,
+  
kVTCompressionPropertyKey_DataRateLimits,
+  data_rate_limits);
+
 CFRelease(bytes_per_second);
 CFRelease(one_second);
-return AVERROR(ENOMEM);
-}
-status = VTSessionSetProperty(vtctx->session,
-  kVTCompressionPropertyKey_DataRateLimits,
-  data_rate_limits);
+CFRelease(data_rate_limits);
 
-CFRelease(bytes_per_second);
-CFRelease(one_second);
-CFRelease(data_rate_limits);
-
-if (status) {
-av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate property: 
%d\n", status);
-return AVERROR_EXTERNAL;
+if (status) {
+av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate 
property: %d\n", status);
+return AVERROR_EXTERNAL;
+}
 }
 
 if (profile_level) {
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/videotoolboxenc: fix invalid session on iOS

2018-06-18 Thread Thomas Guillem 
Ping?

On Thu, Jun 14, 2018, at 17:48, Thomas Guillem wrote:
> Cf. comment. Restart the VT session when the APP goes from foreground to
> background and vice versa.
> ---
>  libavcodec/videotoolboxenc.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 1060055ba5..ac847358ab 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -2175,8 +2175,27 @@ static int create_cv_pixel_buffer(AVCodecContext   
> *avctx,
>  #if TARGET_OS_IPHONE
>  pix_buf_pool = VTCompressionSessionGetPixelBufferPool(vtctx-
> >session);
>  if (!pix_buf_pool) {
> -av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.
> \n");
> -return AVERROR_EXTERNAL;
> +/* On iOS, the VT session is invalidated when the APP switches 
> from
> + * foreground to background and vice versa. Fetch the actual 
> error code
> + * of the VT session to detect that case and restart the VT 
> session
> + * accordingly. */
> +OSStatus vtstatus;
> +
> +vtstatus = VTCompressionSessionPrepareToEncodeFrames(vtctx-
> >session);
> +if (vtstatus == kVTInvalidSessionErr) {
> +CFRelease(vtctx->session);
> +vtctx->session = NULL;
> +status = vtenc_configure_encoder(avctx);
> +if (status == 0)
> +pix_buf_pool = 
> VTCompressionSessionGetPixelBufferPool(vtctx->session);
> +}
> +if (!pix_buf_pool) {
> +av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer 
> pool.\n");
> +return AVERROR_EXTERNAL;
> +}
> +else
> +av_log(avctx, AV_LOG_WARNING, "VT session restarted because 
> of a "
> +   "kVTInvalidSessionErr error.\n");
>  }
>  
>  status = CVPixelBufferPoolCreatePixelBuffer(NULL,
> -- 
> 2.17.1
> 
> ___
> 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

[FFmpeg-devel] [PATCH 3/3] avcodec/videotoolboxenc: fix invalid session on iOS

2018-06-14 Thread Thomas Guillem 
Cf. comment. Restart the VT session when the APP goes from foreground to
background and vice versa.
---
 libavcodec/videotoolboxenc.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 1060055ba5..ac847358ab 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2175,8 +2175,27 @@ static int create_cv_pixel_buffer(AVCodecContext   
*avctx,
 #if TARGET_OS_IPHONE
 pix_buf_pool = VTCompressionSessionGetPixelBufferPool(vtctx->session);
 if (!pix_buf_pool) {
-av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
-return AVERROR_EXTERNAL;
+/* On iOS, the VT session is invalidated when the APP switches from
+ * foreground to background and vice versa. Fetch the actual error code
+ * of the VT session to detect that case and restart the VT session
+ * accordingly. */
+OSStatus vtstatus;
+
+vtstatus = VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
+if (vtstatus == kVTInvalidSessionErr) {
+CFRelease(vtctx->session);
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status == 0)
+pix_buf_pool = 
VTCompressionSessionGetPixelBufferPool(vtctx->session);
+}
+if (!pix_buf_pool) {
+av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
+return AVERROR_EXTERNAL;
+}
+else
+av_log(avctx, AV_LOG_WARNING, "VT session restarted because of a "
+   "kVTInvalidSessionErr error.\n");
 }
 
 status = CVPixelBufferPoolCreatePixelBuffer(NULL,
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avcodec/videotoolboxenc: fix invalid session on iOS

2018-06-11 Thread Thomas Guillem 
Cf. comment. Restart the VT session when the APP goes from foreground to
background and vice versa.
---
 libavcodec/videotoolboxenc.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 1060055ba5..4b79fca45e 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2175,8 +2175,29 @@ static int create_cv_pixel_buffer(AVCodecContext   
*avctx,
 #if TARGET_OS_IPHONE
 pix_buf_pool = VTCompressionSessionGetPixelBufferPool(vtctx->session);
 if (!pix_buf_pool) {
-av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
-return AVERROR_EXTERNAL;
+/* On iOS, the VT session is invalidated when the APP switches from
+ * foreground to background and vice versa. Fetch the actual error code
+ * of the VT session to detect that case and restart the VT session
+ * accordingly. */
+OSStatus vtstatus =
+VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
+
+if (vtstatus == kVTInvalidSessionErr)
+{
+CFRelease(vtctx->session);
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status == 0)
+pix_buf_pool = 
VTCompressionSessionGetPixelBufferPool(vtctx->session);
+}
+if (!pix_buf_pool)
+{
+av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
+return AVERROR_EXTERNAL;
+}
+else
+av_log(avctx, AV_LOG_WARNING, "VT session restarted because of a "
+   "kVTInvalidSessionErr error.\n");
 }
 
 status = CVPixelBufferPoolCreatePixelBuffer(NULL,
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avcodec/videotoolboxenc: split initialization

2018-06-11 Thread Thomas Guillem 
Split vtenc_init() into vtenc_init() (VTEncContext initialization) and
vtenc_configure_encoder() (creates the vt session).

This commit will allow to restart the vt session while encoding.
---
 libavcodec/videotoolboxenc.c | 48 +---
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 9f2a71b15d..1060055ba5 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1262,19 +1262,16 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
 return 0;
 }
 
-static av_cold int vtenc_init(AVCodecContext *avctx)
+static int vtenc_configure_encoder(AVCodecContext *avctx)
 {
 CFMutableDictionaryRef enc_info;
 CFMutableDictionaryRef pixel_buffer_info;
 CMVideoCodecType   codec_type;
 VTEncContext   *vtctx = avctx->priv_data;
 CFStringRefprofile_level;
-CFBooleanRef   has_b_frames_cfbool;
 CFNumberRefgamma_level = NULL;
 intstatus;
 
-pthread_once(_ctrl, loadVTEncSymbols);
-
 codec_type = get_cm_codec_type(avctx->codec_id);
 if (!codec_type) {
 av_log(avctx, AV_LOG_ERROR, "Error: no mapping for AVCodecID %d\n", 
avctx->codec_id);
@@ -1304,8 +1301,6 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
 if (!get_vt_hevc_profile_level(avctx, _level)) return 
AVERROR(EINVAL);
 }
 
-vtctx->session = NULL;
-
 enc_info = CFDictionaryCreateMutable(
 kCFAllocatorDefault,
 20,
@@ -1335,8 +1330,6 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
 pixel_buffer_info = NULL;
 }
 
-pthread_mutex_init(>lock, NULL);
-pthread_cond_init(>cv_sample_sent, NULL);
 vtctx->dts_delta = vtctx->has_b_frames ? -1 : 0;
 
 get_cv_transfer_function(avctx, >transfer_function, _level);
@@ -1363,8 +1356,32 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
   pixel_buffer_info,
   >session);
 
-if (status < 0)
-goto init_cleanup;
+init_cleanup:
+if (gamma_level)
+CFRelease(gamma_level);
+
+if (pixel_buffer_info)
+CFRelease(pixel_buffer_info);
+
+CFRelease(enc_info);
+
+return status;
+}
+
+static av_cold int vtenc_init(AVCodecContext *avctx)
+{
+VTEncContext*vtctx = avctx->priv_data;
+CFBooleanRefhas_b_frames_cfbool;
+int status;
+
+pthread_once(_ctrl, loadVTEncSymbols);
+
+pthread_mutex_init(>lock, NULL);
+pthread_cond_init(>cv_sample_sent, NULL);
+
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status) return status;
 
 status = VTSessionCopyProperty(vtctx->session,

kVTCompressionPropertyKey_AllowFrameReordering,
@@ -1378,16 +1395,7 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
 }
 avctx->has_b_frames = vtctx->has_b_frames;
 
-init_cleanup:
-if (gamma_level)
-CFRelease(gamma_level);
-
-if (pixel_buffer_info)
-CFRelease(pixel_buffer_info);
-
-CFRelease(enc_info);
-
-return status;
+return 0;
 }
 
 static void vtenc_get_frame_info(CMSampleBufferRef buffer, bool *is_key_frame)
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avcodec/videotoolboxenc: fix mutex/cond leak in error path

2018-06-11 Thread Thomas Guillem 
The leak could happen when the vtenc_create_encoder() function failed.
---
 libavcodec/videotoolboxenc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 7796a685c2..9f2a71b15d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2473,13 +2473,14 @@ static av_cold int vtenc_close(AVCodecContext *avctx)
 {
 VTEncContext *vtctx = avctx->priv_data;
 
+pthread_cond_destroy(>cv_sample_sent);
+pthread_mutex_destroy(>lock);
+
 if(!vtctx->session) return 0;
 
 VTCompressionSessionCompleteFrames(vtctx->session,
kCMTimeIndefinite);
 clear_frame_queue(vtctx);
-pthread_cond_destroy(>cv_sample_sent);
-pthread_mutex_destroy(>lock);
 CFRelease(vtctx->session);
 vtctx->session = NULL;
 
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: Make hardware config method support more explicit for hwaccels

2017-12-08 Thread Thomas Guillem 


On Fri, Dec 8, 2017, at 17:15, Mark Thompson wrote:
> From: Thomas Guillem <tho...@gllm.fr>
> 
> This fixes the use of old ad-hoc methods which are still supported by
> some
> hwaccels which also support newer methods (DXVA2, VAAPI, VDPAU,
> videotoolbox) - without the method being visible here, ff_get_format()
> would refuse to use it.
> 
> Signed-off-by: Mark Thompson <s...@jkqxz.net>
> ---
> On 07/12/17 12:25, Thomas Guillem wrote:
> > Add a boolean to specify if an API can work with
> > AV_CODEC_HW_CONFIG_METHOD_AD_HOC.
> > ---
> >  libavcodec/hwaccel.h | 17 +
> >  1 file changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> > index ae55527c2f..16ee822920 100644
> > --- a/libavcodec/hwaccel.h
> > +++ b/libavcodec/hwaccel.h
> > @@ -42,12 +42,13 @@ typedef struct AVCodecHWConfigInternal {
> >  
> >  // These macros are used to simplify AVCodecHWConfigInternal definitions.
> >  
> > -#define HW_CONFIG_HWACCEL(format, device, name) \
> > +#define HW_CONFIG_HWACCEL(format, ad_hoc, device, name) \
> >  &(const AVCodecHWConfigInternal) { \
> >  .public  = { \
> >  .pix_fmt = AV_PIX_FMT_ ## format, \
> >  .methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
> > -   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
> > +   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX | \
> > +   ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC : 0, \
> >  .device_type = AV_HWDEVICE_TYPE_ ## device, \
> >  }, \
> >  .hwaccel = , \
> 
> Once we're having extra arguments in the macros like that I think I would
> prefer all the methods to be specified explicitly (which conveniently
> also lets us delete the second macro).
> 
> How about this?

Fine with me.

> 
> Thanks,
> 
> - Mark
> 
> 
>  libavcodec/hwaccel.h | 36 +---
>  1 file changed, 13 insertions(+), 23 deletions(-)
> 
> diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
> index ae55527c2f..3aaa92571c 100644
> --- a/libavcodec/hwaccel.h
> +++ b/libavcodec/hwaccel.h
> @@ -42,13 +42,14 @@ typedef struct AVCodecHWConfigInternal {
>  
>  // These macros are used to simplify AVCodecHWConfigInternal
>  definitions.
>  
> -#define HW_CONFIG_HWACCEL(format, device, name) \
> +#define HW_CONFIG_HWACCEL(device, frames, ad_hoc, format, device_type_,
> name) \
>  &(const AVCodecHWConfigInternal) { \
>  .public  = { \
>  .pix_fmt = AV_PIX_FMT_ ## format, \
> -.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
> -   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
> -.device_type = AV_HWDEVICE_TYPE_ ## device, \
> +.methods = (device ?
> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX : 0) | \
> +   (frames ?
> AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX : 0) | \
> +   (ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC   
> : 0),  \
> +.device_type = AV_HWDEVICE_TYPE_ ## device_type_, \
>  }, \
>  .hwaccel = , \
>  }
> @@ -63,32 +64,21 @@ typedef struct AVCodecHWConfigInternal {
>  .hwaccel = NULL, \
>  }
>  
> -#define HW_CONFIG_AD_HOC_HWACCEL(format, name) \
> -&(const AVCodecHWConfigInternal) { \
> -.public =  { \
> -.pix_fmt = AV_PIX_FMT_ ## format, \
> -.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC, \
> -.device_type = AV_HWDEVICE_TYPE_NONE, \
> -}, \
> -.hwaccel = , \
> -}
> -
>  #define HWACCEL_DXVA2(codec) \
> -HW_CONFIG_HWACCEL(DXVA2_VLD, DXVA2,   ff_ ## codec ##
> _dxva2_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 1, DXVA2_VLD,DXVA2,ff_ ## codec
> ## _dxva2_hwaccel)
>  #define HWACCEL_D3D11VA2(codec) \
> -HW_CONFIG_HWACCEL(D3D11, D3D11VA, ff_ ## codec ##
> _d3d11va2_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 0, D3D11,D3D11VA,  ff_ ## codec
> ## _d3d11va2_hwaccel)
>  #define HWACCEL_NVDEC(codec) \
> -HW_CONFIG_HWACCEL(CUDA,  CUDA,ff_ ## codec ##
> _nvdec_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 0, CUDA, CUDA, ff_ ## codec
> ## _nvdec_hwaccel)
>  #define HWACCEL_VAAPI(codec) \
> -HW_CONFIG_HWACCEL(VAAPI, VAAPI,   ff_ ## codec ##
> _vaapi_hwaccel)
> +HW_CONFIG_HWACCEL(1, 1, 1, VAAPI,VAAPI,ff_ ## codec
> ## _vaapi_hwaccel)
>  #define HWA

[FFmpeg-devel] [PATCH 2/2] lavc: add back AD_HOC method for DXVA2/D3D11/VAAPI/VDPAU

2017-12-07 Thread Thomas Guillem 
---
 libavcodec/hwaccel.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index 16ee822920..292a87f6b5 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -75,15 +75,15 @@ typedef struct AVCodecHWConfigInternal {
 }
 
 #define HWACCEL_DXVA2(codec) \
-HW_CONFIG_HWACCEL(DXVA2_VLD, 0,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
+HW_CONFIG_HWACCEL(DXVA2_VLD, 1,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
 #define HWACCEL_D3D11VA2(codec) \
-HW_CONFIG_HWACCEL(D3D11, 0,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
+HW_CONFIG_HWACCEL(D3D11, 1,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
 #define HWACCEL_NVDEC(codec) \
 HW_CONFIG_HWACCEL(CUDA,  0, CUDA,ff_ ## codec ## _nvdec_hwaccel)
 #define HWACCEL_VAAPI(codec) \
-HW_CONFIG_HWACCEL(VAAPI, 0,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
+HW_CONFIG_HWACCEL(VAAPI, 1,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
 #define HWACCEL_VDPAU(codec) \
-HW_CONFIG_HWACCEL(VDPAU, 0,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
+HW_CONFIG_HWACCEL(VDPAU, 1,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
 #define HWACCEL_VIDEOTOOLBOX(codec) \
 HW_CONFIG_HWACCEL(VIDEOTOOLBOX, 0, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
 
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavc: change HW_CONFIG_HWACCEL arguments

2017-12-07 Thread Thomas Guillem 
Add a boolean to specify if an API can work with
AV_CODEC_HW_CONFIG_METHOD_AD_HOC.
---
 libavcodec/hwaccel.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index ae55527c2f..16ee822920 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -42,12 +42,13 @@ typedef struct AVCodecHWConfigInternal {
 
 // These macros are used to simplify AVCodecHWConfigInternal definitions.
 
-#define HW_CONFIG_HWACCEL(format, device, name) \
+#define HW_CONFIG_HWACCEL(format, ad_hoc, device, name) \
 &(const AVCodecHWConfigInternal) { \
 .public  = { \
 .pix_fmt = AV_PIX_FMT_ ## format, \
 .methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
-   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
+   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX | \
+   ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC : 0, \
 .device_type = AV_HWDEVICE_TYPE_ ## device, \
 }, \
 .hwaccel = , \
@@ -74,17 +75,17 @@ typedef struct AVCodecHWConfigInternal {
 }
 
 #define HWACCEL_DXVA2(codec) \
-HW_CONFIG_HWACCEL(DXVA2_VLD, DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
+HW_CONFIG_HWACCEL(DXVA2_VLD, 0,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
 #define HWACCEL_D3D11VA2(codec) \
-HW_CONFIG_HWACCEL(D3D11, D3D11VA, ff_ ## codec ## _d3d11va2_hwaccel)
+HW_CONFIG_HWACCEL(D3D11, 0,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
 #define HWACCEL_NVDEC(codec) \
-HW_CONFIG_HWACCEL(CUDA,  CUDA,ff_ ## codec ## _nvdec_hwaccel)
+HW_CONFIG_HWACCEL(CUDA,  0, CUDA,ff_ ## codec ## _nvdec_hwaccel)
 #define HWACCEL_VAAPI(codec) \
-HW_CONFIG_HWACCEL(VAAPI, VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
+HW_CONFIG_HWACCEL(VAAPI, 0,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
 #define HWACCEL_VDPAU(codec) \
-HW_CONFIG_HWACCEL(VDPAU, VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
+HW_CONFIG_HWACCEL(VDPAU, 0,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
 #define HWACCEL_VIDEOTOOLBOX(codec) \
-HW_CONFIG_HWACCEL(VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
+HW_CONFIG_HWACCEL(VIDEOTOOLBOX, 0, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
 
 #define HWACCEL_D3D11VA(codec) \
 HW_CONFIG_AD_HOC_HWACCEL(D3D11VA_VLD, ff_ ## codec ## _d3d11va_hwaccel)
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel