date:20220722

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread James Almer

On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:

James Almer:

Should fix ticket #3361

Signed-off-by: James Almer
---
This also needs an update to some fate ref samples i'll upload before
pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
decoded
properly as he_aac mono, so the .s16 files need to be replaced).

We have both a fixed-point AAC as well as a floating point AAC decoder.
Is there actually a test that tests that the output they produce is
reasonably close? If not, could we make the test so that the same file
is decoded once with the fixed-point and once with the floating-point
decoder and then compared?

That wouldn't help much, i think. Almost all changes to *_template.c
files are going to affect both decoders, so a breakage would not be
detected if you compare their output with each other as they would both
exhibit it.

I actually thought that the aac_fixed tests used checksums instead of
ref files; then changes and breakages would be visible by changes to
these files. Apparently I was wrong about that and the ref files are
used for both aac and aac_fixed. But a test like the one outlined above
would nevertheless obviate the need for a new ref file.

Judging by
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117
it seems at least for these samples the fixed decoder does not generate
a decoded stream comparable to the float one, so I'll just upload a new
raw pcm file.

___
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 v2 3/3] hwcontext_vaapi: #if guard VAAPI_DRM specifics

2022-07-22 Thread Emil Velikov

On Thu, 21 Jul 2022 at 22:06, Mark Thompson  wrote:
>
> On 20/07/2022 11:56, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind a
> > compiler guard.
> >
> > Signed-off-by: Emil Velikov 
> > ---
> >   libavutil/hwcontext_vaapi.c | 10 ++
> >   1 file changed, 10 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 7734a50fc0..7aea3e7b96 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -18,6 +18,10 @@
> >
> >   #include "config.h"
> >
> > +#if !HAVE_VAAPI_X11 && !HAVE_VAAPI_DRM
> > +#error "At least one VAAPI winsys is required X11 or DRM"
>
> No it isn't.
>
> Originally there wasn't a possibility to link with any winsys here - 
> libavcodec users had to get the device themselves and pass it in.
>
> The winsys link was added to the ffmpeg utility initially for command-line 
> use and then moved to libavutil when it was clear that it would be useful to 
> other library users; there isn't any requirement to use it, though.  (E.g. 
> disable it and note that programs handling the winsys themselves like mpv and 
> vlc still work perfectly well.)
>

Assuming I'm reading the code correctly, currently when both are
undefined vaapi_device_create() will be basically a dummy, doing some
basic malloc + opts parsing and erroring out.

So as-is functions like av_hwdevice_ctx_alloc() will return success,
although as av_hwdevice_ctx_create() is called later on it will always
fail.
My aim was to effectively omit the HWContextType vaapi instance in the
final libavutil, since it cannot work. Perhaps there's a better way to
achieve that?

In either case, I will drop that check for now.

Thank you o/
Emil
___
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 v2 1/2] ffmpeg: refactor post-decoding steps for subtitles into a function

2022-07-22 Thread Jan Ekström

From: Jan Ekström 

This enables us to later call this when generating additional
subtitles for splitting purposes.

Co-authored-by: Andrzej Nadachowski 

Signed-off-by: Jan Ekström 
---
 fftools/ffmpeg.c | 50 
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ed3075f6e6..fb148a0404 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2278,27 +2278,16 @@ fail:
 return err < 0 ? err : ret;
 }
 
-static int transcode_subtitles(InputStream *ist, AVPacket *pkt, int 
*got_output,
-   int *decode_failed)
+static int encode_mux_subtitles(InputStream *ist, AVSubtitle *subtitle, int 
*got_output)
 {
-AVSubtitle subtitle;
+int ret = 0;
 int free_sub = 1;
-int i, ret = avcodec_decode_subtitle2(ist->dec_ctx,
-  &subtitle, got_output, pkt);
 
-check_decode_result(NULL, got_output, ret);
-
-if (ret < 0 || !*got_output) {
-*decode_failed = 1;
-if (!pkt->size)
-sub2video_flush(ist);
-return ret;
-}
 
 if (ist->fix_sub_duration) {
 int end = 1;
 if (ist->prev_sub.got_output) {
-end = av_rescale(subtitle.pts - ist->prev_sub.subtitle.pts,
+end = av_rescale(subtitle->pts - ist->prev_sub.subtitle.pts,
  1000, AV_TIME_BASE);
 if (end < ist->prev_sub.subtitle.end_display_time) {
 av_log(ist->dec_ctx, AV_LOG_DEBUG,
@@ -2310,7 +2299,7 @@ static int transcode_subtitles(InputStream *ist, AVPacket 
*pkt, int *got_output,
 }
 FFSWAP(int,*got_output, ist->prev_sub.got_output);
 FFSWAP(int,ret, ist->prev_sub.ret);
-FFSWAP(AVSubtitle, subtitle,ist->prev_sub.subtitle);
+FFSWAP(AVSubtitle, *subtitle,   ist->prev_sub.subtitle);
 if (end <= 0)
 goto out;
 }
@@ -2319,40 +2308,59 @@ static int transcode_subtitles(InputStream *ist, 
AVPacket *pkt, int *got_output,
 return ret;
 
 if (ist->sub2video.frame) {
-sub2video_update(ist, INT64_MIN, &subtitle);
+sub2video_update(ist, INT64_MIN, subtitle);
 } else if (ist->nb_filters) {
 if (!ist->sub2video.sub_queue)
 ist->sub2video.sub_queue = av_fifo_alloc2(8, sizeof(AVSubtitle), 
AV_FIFO_FLAG_AUTO_GROW);
 if (!ist->sub2video.sub_queue)
 exit_program(1);
 
-ret = av_fifo_write(ist->sub2video.sub_queue, &subtitle, 1);
+ret = av_fifo_write(ist->sub2video.sub_queue, subtitle, 1);
 if (ret < 0)
 exit_program(1);
 free_sub = 0;
 }
 
-if (!subtitle.num_rects)
+if (!subtitle->num_rects)
 goto out;
 
 ist->frames_decoded++;
 
-for (i = 0; i < nb_output_streams; i++) {
+for (int i = 0; i < nb_output_streams; i++) {
 OutputStream *ost = output_streams[i];
 
 if (!check_output_constraints(ist, ost) || !ost->encoding_needed
 || ost->enc->type != AVMEDIA_TYPE_SUBTITLE)
 continue;
 
-do_subtitle_out(output_files[ost->file_index], ost, &subtitle);
+do_subtitle_out(output_files[ost->file_index], ost, subtitle);
 }
 
 out:
 if (free_sub)
-avsubtitle_free(&subtitle);
+avsubtitle_free(subtitle);
 return ret;
 }
 
+static int transcode_subtitles(InputStream *ist, AVPacket *pkt, int 
*got_output,
+   int *decode_failed)
+{
+AVSubtitle subtitle;
+int ret = avcodec_decode_subtitle2(ist->dec_ctx,
+   &subtitle, got_output, pkt);
+
+check_decode_result(NULL, got_output, ret);
+
+if (ret < 0 || !*got_output) {
+*decode_failed = 1;
+if (!pkt->size)
+sub2video_flush(ist);
+return ret;
+}
+
+return encode_mux_subtitles(ist, &subtitle, got_output);
+}
+
 static int send_filter_eof(InputStream *ist)
 {
 int i, ret;
-- 
2.36.1

___
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 v2 2/2] ffmpeg: add video heartbeat capability to fix_sub_duration

2022-07-22 Thread Jan Ekström

From: Jan Ekström 

Splits the currently handled subtitle at random access point
packets that can be configured to follow a specific output stream.

This way the subtitle - which is known to be shown at this time
can be split and passed to muxer before its full duration is
yet known.

Co-authored-by: Andrzej Nadachowski 
Co-authored-by: Bernard Boulay 

Signed-off-by: Jan Ekström 
---
 doc/ffmpeg.texi   |  11 ++
 fftools/ffmpeg.c  | 142 ++
 fftools/ffmpeg.h  |   8 +
 fftools/ffmpeg_opt.c  |   9 ++
 tests/fate/ffmpeg.mak |  14 ++
 .../fate/ffmpeg-fix_sub_duration_heartbeat|  48 ++
 6 files changed, 232 insertions(+)
 create mode 100644 tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 767df69b7f..0b9beb29d9 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1312,6 +1312,17 @@ List all hardware acceleration components enabled in 
this build of ffmpeg.
 Actual runtime availability depends on the hardware and its suitable driver
 being installed.
 
+@item -fix_sub_duration_heartbeat[:@var{stream_specifier}]
+Set a specific output video stream as the heartbeat stream according to which
+to split and push through currently in-progress subtitle upon receipt of a
+random access packet.
+
+This lowers the latency of subtitles for which the end packet or the following
+subtitle has not yet been received.
+
+Requires @option{-fix_sub_duration} to be set for the relevant input subtitle
+stream for this to have any effect.
+
 @end table
 
 @section Audio Options
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index fb148a0404..a0ad5cc39c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -127,6 +127,7 @@ typedef struct BenchmarkTimeStamps {
 int64_t sys_usec;
 } BenchmarkTimeStamps;
 
+static int trigger_fix_sub_duration_heartbeat(OutputStream *ost, const 
AVPacket *pkt);
 static BenchmarkTimeStamps get_benchmark_time_stamps(void);
 static int64_t getmaxrss(void);
 static int ifilter_has_all_input_formats(FilterGraph *fg);
@@ -968,6 +969,13 @@ static int encode_frame(OutputFile *of, OutputStream *ost, 
AVFrame *frame)
av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&enc->time_base));
 }
 
+if ((ret = trigger_fix_sub_duration_heartbeat(ost, pkt)) < 0) {
+av_log(NULL, AV_LOG_ERROR,
+   "Subtitle heartbeat logic failed in %s! (%s)\n",
+   __func__, av_err2str(ret));
+exit_program(1);
+}
+
 if (enc->codec_type == AVMEDIA_TYPE_VIDEO)
 update_video_stats(ost, pkt, !!vstats_filename);
 
@@ -1888,6 +1896,16 @@ static void do_streamcopy(InputStream *ist, OutputStream 
*ost, const AVPacket *p
 
 ost->sync_opts += opkt->duration;
 
+{
+int ret = trigger_fix_sub_duration_heartbeat(ost, pkt);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR,
+   "Subtitle heartbeat logic failed in %s! (%s)\n",
+   __func__, av_err2str(ret));
+exit_program(1);
+}
+}
+
 output_packet(of, opkt, ost, 0);
 
 ost->streamcopy_started = 1;
@@ -2342,6 +2360,130 @@ out:
 return ret;
 }
 
+static int copy_av_subtitle(AVSubtitle *dst, AVSubtitle *src)
+{
+int ret = AVERROR_BUG;
+AVSubtitle tmp = {
+.format = src->format,
+.start_display_time = src->start_display_time,
+.end_display_time = src->end_display_time,
+.num_rects = 0,
+.rects = NULL,
+.pts = src->pts
+};
+
+if (!src->num_rects)
+goto success;
+
+if (!(tmp.rects = av_calloc(src->num_rects, sizeof(*tmp.rects
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < src->num_rects; i++) {
+AVSubtitleRect *src_rect = src->rects[i];
+AVSubtitleRect *dst_rect;
+
+if (!(dst_rect = tmp.rects[i] = av_mallocz(sizeof(*tmp.rects[0] {
+ret = AVERROR(ENOMEM);
+goto cleanup;
+}
+
+tmp.num_rects++;
+
+dst_rect->type  = src_rect->type;
+dst_rect->flags = src_rect->flags;
+
+dst_rect->x = src_rect->x;
+dst_rect->y = src_rect->y;
+dst_rect->w = src_rect->w;
+dst_rect->h = src_rect->h;
+dst_rect->nb_colors = src_rect->nb_colors;
+
+if (src_rect->text)
+if (!(dst_rect->text = av_strdup(src_rect->text))) {
+ret = AVERROR(ENOMEM);
+goto cleanup;
+}
+
+if (src_rect->ass)
+if (!(dst_rect->ass = av_strdup(src_rect->ass))) {
+ret = AVERROR(ENOMEM);
+goto cleanup;
+}
+
+for (int j = 0; j < 4; j++) {
+// SUBTITLE_BITMAP images are special in the sense that they
+// are like PAL8 images. fir

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread Andreas Rheinhardt

James Almer:
> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
 James Almer:
> Should fix ticket #3361
>
> Signed-off-by: James Almer 
> ---
> This also needs an update to some fate ref samples i'll upload before
> pushing
> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
> decoded
> properly as he_aac mono, so the .s16 files need to be replaced).
>

 We have both a fixed-point AAC as well as a floating point AAC decoder.
 Is there actually a test that tests that the output they produce is
 reasonably close? If not, could we make the test so that the same file
 is decoded once with the fixed-point and once with the floating-point
 decoder and then compared?
>>>
>>> That wouldn't help much, i think. Almost all changes to *_template.c
>>> files are going to affect both decoders, so a breakage would not be
>>> detected if you compare their output with each other as they would both
>>> exhibit it.
>>>
>>
>> I actually thought that the aac_fixed tests used checksums instead of
>> ref files; then changes and breakages would be visible by changes to
>> these files. Apparently I was wrong about that and the ref files are
>> used for both aac and aac_fixed. But a test like the one outlined above
>> would nevertheless obviate the need for a new ref file.
> 
> Judging by
> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117
> it seems at least for these samples the fixed decoder does not generate
> a decoded stream comparable to the float one, so I'll just upload a new
> raw pcm file.

When I decode both of these streams with git master, the left channel is
pretty much identical, yet the right channel of the fixed-point decoder
is silent and the right channel of the floating point decoder is not.
With this patch applied, the result are two mono streams that are pretty
much identical: The test sample created by the floating-point decoder
works with the fixed-point decoder test (if one uncomments and modifies
the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
upload new samples.

- Andreas

PS: libfdk-aac produces a file that looks pretty much like the floating
point decoder from git master. Are you sure your patch is correct?
___
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/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread James Almer

On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:

James Almer:

Should fix ticket #3361

When I decode both of these streams with git master, the left channel is
pretty much identical, yet the right channel of the fixed-point decoder
is silent and the right channel of the floating point decoder is not.
With this patch applied, the result are two mono streams that are pretty
much identical: The test sample created by the floating-point decoder
works with the fixed-point decoder test (if one uncomments and modifies
the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
upload new samples.

Ok, can you suggest how to add a test that decodes with the fixed point
decoder then compares that with the output of the float decoder? Is
there a helper in fate.sh already for this?

- Andreas

PS: libfdk-aac produces a file that looks pretty much like the floating
point decoder from git master. Are you sure your patch is correct?

Yes, they duplicate the single channel in the stream and output it as
stereo, something that should be done by a filter if that's what the
user wants. Decoding a mono sample should generate a mono stream.

___
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/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread Andreas Rheinhardt

James Almer:
> On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
 James Almer:
> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Should fix ticket #3361
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> This also needs an update to some fate ref samples i'll upload
>>> before
>>> pushing
>>> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
>>> decoded
>>> properly as he_aac mono, so the .s16 files need to be replaced).
>>>
>>
>> We have both a fixed-point AAC as well as a floating point AAC
>> decoder.
>> Is there actually a test that tests that the output they produce is
>> reasonably close? If not, could we make the test so that the same
>> file
>> is decoded once with the fixed-point and once with the floating-point
>> decoder and then compared?
>
> That wouldn't help much, i think. Almost all changes to *_template.c
> files are going to affect both decoders, so a breakage would not be
> detected if you compare their output with each other as they would
> both
> exhibit it.
>

 I actually thought that the aac_fixed tests used checksums instead of
 ref files; then changes and breakages would be visible by changes to
 these files. Apparently I was wrong about that and the ref files are
 used for both aac and aac_fixed. But a test like the one outlined above
 would nevertheless obviate the need for a new ref file.
>>>
>>> Judging by
>>> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117
>>>
>>> it seems at least for these samples the fixed decoder does not generate
>>> a decoded stream comparable to the float one, so I'll just upload a new
>>> raw pcm file.
>>
>> When I decode both of these streams with git master, the left channel is
>> pretty much identical, yet the right channel of the fixed-point decoder
>> is silent and the right channel of the floating point decoder is not.
>> With this patch applied, the result are two mono streams that are pretty
>> much identical: The test sample created by the floating-point decoder
>> works with the fixed-point decoder test (if one uncomments and modifies
>> the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
>> upload new samples.
> 
> Ok, can you suggest how to add a test that decodes with the fixed point
> decoder then compares that with the output of the float decoder? Is
> there a helper in fate.sh already for this?
> 

There is currently no helper in fate-run.sh for this.

>>
>> - Andreas
>>
>> PS: libfdk-aac produces a file that looks pretty much like the floating
>> point decoder from git master. Are you sure your patch is correct?
> 
> Yes, they duplicate the single channel in the stream and output it as
> stereo, something that should be done by a filter if that's what the
> user wants. Decoding a mono sample should generate a mono stream.

Not really. The channels are different.

- 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".

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread James Almer

On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:

James Almer:

Should fix ticket #3361

Signed-off-by: James Almer
---
This also needs an update to some fate ref samples i'll upload
before
pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
decoded
properly as he_aac mono, so the .s16 files need to be replaced).

We have both a fixed-point AAC as well as a floating point AAC
decoder.
Is there actually a test that tests that the output they produce is
reasonably close? If not, could we make the test so that the same
file
is decoded once with the fixed-point and once with the floating-point
decoder and then compared?

Judging by
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117

it seems at least for these samples the fixed decoder does not generate
a decoded stream comparable to the float one, so I'll just upload a new
raw pcm file.

Ok, can you suggest how to add a test that decodes with the fixed point
decoder then compares that with the output of the float decoder? Is
there a helper in fate.sh already for this?

There is currently no helper in fate-run.sh for this.

Yeah, figures that's the case. Can you suggest how one would work for this?

- Andreas

PS: libfdk-aac produces a file that looks pretty much like the floating
point decoder from git master. Are you sure your patch is correct?

Not really. The channels are different.

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=0 -f md5 -

has the same result as

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=1 -f md5 -

Same with the samples in the ticket.

- 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/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread Andreas Rheinhardt

James Almer:
> On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:
 James Almer:
> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
 James Almer:
> Should fix ticket #3361
>
> Signed-off-by: James Almer 
> ---
> This also needs an update to some fate ref samples i'll upload
> before
> pushing
> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which
> are now
> decoded
> properly as he_aac mono, so the .s16 files need to be replaced).
>

 We have both a fixed-point AAC as well as a floating point AAC
 decoder.
 Is there actually a test that tests that the output they produce is
 reasonably close? If not, could we make the test so that the same
 file
 is decoded once with the fixed-point and once with the
 floating-point
 decoder and then compared?
>>>
>>> That wouldn't help much, i think. Almost all changes to *_template.c
>>> files are going to affect both decoders, so a breakage would not be
>>> detected if you compare their output with each other as they would
>>> both
>>> exhibit it.
>>>
>>
>> I actually thought that the aac_fixed tests used checksums instead of
>> ref files; then changes and breakages would be visible by changes to
>> these files. Apparently I was wrong about that and the ref files are
>> used for both aac and aac_fixed. But a test like the one outlined
>> above
>> would nevertheless obviate the need for a new ref file.
>
> Judging by
> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117
>
>
> it seems at least for these samples the fixed decoder does not
> generate
> a decoded stream comparable to the float one, so I'll just upload a
> new
> raw pcm file.

 When I decode both of these streams with git master, the left
 channel is
 pretty much identical, yet the right channel of the fixed-point decoder
 is silent and the right channel of the floating point decoder is not.
 With this patch applied, the result are two mono streams that are
 pretty
 much identical: The test sample created by the floating-point decoder
 works with the fixed-point decoder test (if one uncomments and modifies
 the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
 upload new samples.
>>>
>>> Ok, can you suggest how to add a test that decodes with the fixed point
>>> decoder then compares that with the output of the float decoder? Is
>>> there a helper in fate.sh already for this?
>>>
>>
>> There is currently no helper in fate-run.sh for this.
> 
> Yeah, figures that's the case. Can you suggest how one would work for this?
> 

A new function in fate-run.sh seems to be necessary. Given that a
similar situation exists for AC-3 we should not hardcode aac; instead it
should have two parameters for the float and the fixed decoder. Then it
should decode the input file twice and do the same comparison that the
current tests use (they use the oneoff method, which results in
do_tiny_psnr with MAXDIFF being called).
I think the tests for the fixed-point decoder (with checksums) should be
separate, so that one can test this without the floating-point decoder
being present.

>>

 - Andreas

 PS: libfdk-aac produces a file that looks pretty much like the floating
 point decoder from git master. Are you sure your patch is correct?
>>>
>>> Yes, they duplicate the single channel in the stream and output it as
>>> stereo, something that should be done by a filter if that's what the
>>> user wants. Decoding a mono sample should generate a mono stream.
>>
>> Not really. The channels are different.
> 
> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> channelmap=channel_layout=mono:map=0 -f md5 -
> 
> has the same result as
> 
> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> channelmap=channel_layout=mono:map=1 -f md5 -
> 
> Same with the samples in the ticket.
> 

This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for
al_sbr_ps_06_new.mp4.

- 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".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/tiff: Check tile_length and tile_width

2022-07-22 Thread Michael Niedermayer

On Fri, Jul 22, 2022 at 08:55:49AM +0200, Michael Niedermayer wrote:
> Fixes: Division by 0
> Fixes: 
> 49235/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5495613847896064
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/tiff.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply and backport patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: PGP signature
___
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/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread James Almer


On 7/22/2022 12:14 PM, Andreas Rheinhardt wrote:

James Almer:

On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:

James Almer:

Should fix ticket #3361

Signed-off-by: James Almer 
---
This also needs an update to some fate ref samples i'll upload
before
pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which
are now
decoded
properly as he_aac mono, so the .s16 files need to be replaced).



We have both a fixed-point AAC as well as a floating point AAC
decoder.
Is there actually a test that tests that the output they produce is
reasonably close? If not, could we make the test so that the same
file
is decoded once with the fixed-point and once with the
floating-point
decoder and then compared?


That wouldn't help much, i think. Almost all changes to *_template.c
files are going to affect both decoders, so a breakage would not be
detected if you compare their output with each other as they would
both
exhibit it.



I actually thought that the aac_fixed tests used checksums instead of
ref files; then changes and breakages would be visible by changes to
these files. Apparently I was wrong about that and the ref files are
used for both aac and aac_fixed. But a test like the one outlined
above
would nevertheless obviate the need for a new ref file.


Judging by
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117


it seems at least for these samples the fixed decoder does not
generate
a decoded stream comparable to the float one, so I'll just upload a
new
raw pcm file.


When I decode both of these streams with git master, the left
channel is
pretty much identical, yet the right channel of the fixed-point decoder
is silent and the right channel of the floating point decoder is not.
With this patch applied, the result are two mono streams that are
pretty
much identical: The test sample created by the floating-point decoder
works with the fixed-point decoder test (if one uncomments and modifies
the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
upload new samples.


Ok, can you suggest how to add a test that decodes with the fixed point
decoder then compares that with the output of the float decoder? Is
there a helper in fate.sh already for this?



There is currently no helper in fate-run.sh for this.


Yeah, figures that's the case. Can you suggest how one would work for this?



A new function in fate-run.sh seems to be necessary. Given that a
similar situation exists for AC-3 we should not hardcode aac; instead it
should have two parameters for the float and the fixed decoder. Then it
should decode the input file twice and do the same comparison that the
current tests use (they use the oneoff method, which results in
do_tiny_psnr with MAXDIFF being called).
I think the tests for the fixed-point decoder (with checksums) should be
separate, so that one can test this without the floating-point decoder
being present.





- Andreas

PS: libfdk-aac produces a file that looks pretty much like the floating
point decoder from git master. Are you sure your patch is correct?


Yes, they duplicate the single channel in the stream and output it as
stereo, something that should be done by a filter if that's what the
user wants. Decoding a mono sample should generate a mono stream.


Not really. The channels are different.


./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=0 -f md5 -

has the same result as

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=1 -f md5 -

Same with the samples in the ticket.



This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for
al_sbr_ps_06_new.mp4.


So looks like nearly a hundred samples into al_sbr_ps_06_new.mp4 frames 
start containing PS info. With this patch the decoder properly decodes 
the first hundred as mono, but since the decoder is locked, it will keep 
decoding the stereo samples as mono.


If i do


diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 4a0fa70ebc..9fd57043d6 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2576,8 +2576,8 @@ static int decode_extension_payload(AACContext *ac, 
GetBitContext *gb, int cnt,
 ac->avctx->profile = FF_PROFILE_AAC_HE;
 }
 res = AAC_RENAME(ff_decode_sbr_extension)(ac, &che->sbr, gb, crc_flag, 
cnt, elem_type);
-if (ac->oc[1].m4ac.ps == 1 && ac->oc[1].status < OC_LOCKED &&
-ac->avctx->ch_layout.nb_channels == 1) {
+if (ac->oc[1].m4ac.ps == 1 && ac->avctx->ch_layout.nb_channels == 1) {
+push_output_configuration(ac);
 output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,

Re: [FFmpeg-devel] [PATCH 22/35] fftools: add an object pool

2022-07-22 Thread Anton Khirnov

Hi,
Quoting Andreas Rheinhardt (2022-06-16 23:41:36)
> AVFifos are often used with non-POD elements that need custom init,
> reset (unref) and free callbacks (in addition to the move callbacks
> already supported). So why not add it to AVFifo? The only drawback to
> this that I see is that the pool could not be shared among multiple
> AVFifos, but apart from that it should support the usecases that you
> propose and do so in a way that avoids having to drain the fifos
> manually when freeing it.

Since neither of us seems to have much time to deal with this right now
--- would you object to me pushing this set as is (Michael confirmed on
IRC he is done testing it) and leaving the objpool question for later?
Objpool is fully private, so it can always be changed or removed at
will.

-- 
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".

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext

2022-07-22 Thread Michael Niedermayer

On Mon, Jul 18, 2022 at 08:56:32PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 09, 2022 at 08:45:31AM +0200, Steve Lhomme wrote:
> > Patch attached in the email.
> > 
> > In some cases, the submit packet can result in configurations changes of the
> > hardware decoders. The previous HW context is then freed and a new one
> > created. That context is supposed to move up to the main context and the
> > other threads.
> > 
> > It appears that when more than 2 frame threads are involved, the new context
> > doesn't move in the right place (or rather at the right time). And it can
> > create a crash when reusing the old HW context. This patch fixes the issue I
> > could reproduce in VLC with DXVA decoding.
> > 
> > I have no idea if this is correct or the side effects induced by this. It
> > seems the right thing to do. Keeping the previous call exhibits the issue.
> > It seems odd the other existing thread context are not updated with the
> > current hwaccel_priv_data. But maybe they are updated later from the "main"
> > thread context, in which case this patch seems solid.
> 
> >  pthread_frame.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 2274e52382008f403c7bf52f76d608d2a56ef859  
> > 0001-avcodec-pthread_frame-update-the-main-avctx-from-the.patch
> > From e8abeeff92f5d7b3b553acdb7595d40153cbec1e Mon Sep 17 00:00:00 2001
> > From: Steve Lhomme 
> > Date: Fri, 8 Jul 2022 11:49:27 +0200
> > Subject: [PATCH] avcodec/pthread_frame: update the main avctx from the 
> > current
> >  ThreadContext
> > 
> > After a submit_decoder() the hwaccel_priv_data may have changed in that 
> > avctx.
> > 
> > Doing it after the "next available frame" loop will likely point to the
> > hwaccel_priv_data from another PerThreadContext which had the old value 
> > which
> > might have been freed, if the submit_decoder() resulting in a format change.
> > ---
> >  libavcodec/pthread_frame.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> It would be nice if a solution to this would make it in 5.1

noone ?
i guess the fix will then be in 5.1.1

is there any note / warning that should be included in the release notes or
something about this open issue ?

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: PGP signature
___
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 22/35] fftools: add an object pool

2022-07-22 Thread Andreas Rheinhardt

Anton Khirnov:
> Hi,
> Quoting Andreas Rheinhardt (2022-06-16 23:41:36)
>> AVFifos are often used with non-POD elements that need custom init,
>> reset (unref) and free callbacks (in addition to the move callbacks
>> already supported). So why not add it to AVFifo? The only drawback to
>> this that I see is that the pool could not be shared among multiple
>> AVFifos, but apart from that it should support the usecases that you
>> propose and do so in a way that avoids having to drain the fifos
>> manually when freeing it.
> 
> Since neither of us seems to have much time to deal with this right now
> --- would you object to me pushing this set as is (Michael confirmed on
> IRC he is done testing it) and leaving the objpool question for later?
> Objpool is fully private, so it can always be changed or removed at
> will.
> 

I don't object to this approach. Sorry for not having time to do any
testing/reviewing.

- 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] [PATCH] qsv: Update ffmpeg qsv_errors to recognize GPU hang

2022-07-22 Thread Dmitry Rogozhkin

GPU hang is one of the most typical errors on Intel GPUs in
case something goes wrong. It's important to recognize it
explicitly for easier bugs triage. Also, this error code
can be used to trigger GPU recovery path in self-written
applications.

Signed-off-by: Hon Wai Chow 
Signed-off-by: Dmitry Rogozhkin 
---
 libavcodec/qsv.c | 1 +
 libavfilter/qsvvpp.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 385b43b..55bcb6e 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -125,6 +125,7 @@ static const struct {
 { MFX_ERR_INVALID_VIDEO_PARAM,  AVERROR(EINVAL), "invalid video 
parameters" },
 { MFX_ERR_UNDEFINED_BEHAVIOR,   AVERROR_BUG, "undefined behavior"  
 },
 { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"   
 },
+{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU Hang"
 },
 { MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio 
parameters"},
 { MFX_ERR_INVALID_AUDIO_PARAM,  AVERROR(EINVAL), "invalid audio 
parameters" },
 
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 954f882..7504906 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -100,6 +100,7 @@ static const struct {
 { MFX_ERR_INVALID_VIDEO_PARAM,  AVERROR(EINVAL), "invalid video 
parameters" },
 { MFX_ERR_UNDEFINED_BEHAVIOR,   AVERROR_BUG, "undefined behavior"  
 },
 { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"   
 },
+{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU Hang"
 },
 { MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio 
parameters"},
 { MFX_ERR_INVALID_AUDIO_PARAM,  AVERROR(EINVAL), "invalid audio 
parameters" },
 
-- 
1.8.3.1

___
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] avformat/mov: Rework the AVIF parser to handle multiple items

2022-07-22 Thread Vignesh Venkatasubramanian

On Wed, Jul 13, 2022 at 9:12 AM Vignesh Venkatasubramanian
 wrote:
>
> On Mon, Jul 11, 2022 at 3:25 PM James Zern
>  wrote:
> >
> > On Thu, Jun 30, 2022 at 2:04 PM Vignesh Venkatasubramanian
> >  wrote:
> > >
> > > Stores the item ids of all the items found in the file and
> > > processes the primary item at the end of the meta box. This patch
> > > does not change any behavior. It sets up the code for parsing
> > > alpha channel (and possibly images with 'grid') in follow up
> > > patches.
> > >
> > > Signed-off-by: Vignesh Venkatasubramanian 
> > > ---
> > >  libavformat/isom.h |   4 ++
> > >  libavformat/mov.c  | 148 -
> > >  2 files changed, 97 insertions(+), 55 deletions(-)
> > >
> > > [...]
> >
> > @@ -4692,9 +4755,25 @@ static int mov_read_meta(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> >  tag = avio_rl32(pb);
> >  atom.size -= 4;
> >  if (tag == MKTAG('h','d','l','r')) {
> > +int ret;
> >  avio_seek(pb, -8, SEEK_CUR);
> >  atom.size += 8;
> > -return mov_read_default(c, pb, atom);
> > +ret = mov_read_default(c, pb, atom);
> > +if (ret < 0)
> >
> > In some other cases these two lines are combined, if ((ret = ...
> >
>
> Done.
>
> > +return ret;
> > +if (c->is_still_picture_avif) {
> > +int ret;
> > +// Add a stream for the YUV planes (primary item).
> > +ret = avif_add_stream(c, c->primary_item_id);
> > +if (ret)
> >
> > This could be updated too and use '< 0' to match other code.
> >
>
> Done.
>
> > +return ret;
> > +// For still AVIF images, the meta box contains all the
> > +// necessary information that would generally be
> > provided by the
> > +// moov box. So simply mark that we have found the moov 
> > box so
> > +// that parsing can continue.
> > +c->found_moov = 1;
> > +}
> > +return ret;
> >  }
> > ___
> > 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".
>
>
>
> --
> Vignesh

Any further comments on this one?

Please note that i have abandoned the second patch in this list. But
this one is still up for merging.

-- 
Vignesh
___
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] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

2022-07-22 Thread Gyan Doshi


Is the News entry forthcoming?

On 2022-07-23 12:00 am, ffmpeg-...@ffmpeg.org wrote:

The branch, master has been updated
via  42a0288d963853aa3c7043946feb4ac3f5242fd4 (commit)
   from  d4a25b141f0a4dadea3b621c6da8c48dde16f608 (commit)


- Log -
commit 42a0288d963853aa3c7043946feb4ac3f5242fd4
Author: Michael Niedermayer 
AuthorDate: Fri Jul 22 20:22:14 2022 +0200
Commit: Michael Niedermayer 
CommitDate: Fri Jul 22 20:30:16 2022 +0200

 web/download: Add FFmpeg 5.1

diff --git a/src/download b/src/download
index d262e94..dd4366b 100644
--- a/src/download
+++ b/src/download
@@ -304,6 +304,42 @@ gpg: Good signature from "FFmpeg release signing key 
Changelog
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/5.1:/RELEASE_NOTES";>Release 
Notes
+ 
+   
+
FFmpeg 5.0.1 "Lorentz"
  



---

Summary of changes:
  src/download | 36 
  1 file changed, 36 insertions(+)


hooks/post-receive


___
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/hevcdec: Output MD5-message in one piece

2022-07-22 Thread Andreas Rheinhardt

Otherwise, there is no guarantee that the various av_log-messages
are not interrupted by another log statement. The latter may originate
from anywhere else, even the HEVC decoder itself, as happens when
one uses frame-threading to decode the BUMPING_A_ericsson_1.bit
sample from the FATE-suite.

Furthermore, the earlier approach suffered from the fact that
various parts of the logmsg were output with different loglevels
and that checking stopped after having encountered the first
plane with MD5 mismatch, although it is probably interesting to
know whether other planes are incorrect, too.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/hevcdec.c | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 2d06d09b75..3c95398b96 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -26,6 +26,7 @@
 #include "config_components.h"
 
 #include "libavutil/attributes.h"
+#include "libavutil/avstring.h"
 #include "libavutil/common.h"
 #include "libavutil/display.h"
 #include "libavutil/film_grain_params.h"
@@ -3374,17 +3375,12 @@ fail:
 return ret;
 }
 
-static void print_md5(void *log_ctx, int level, uint8_t md5[16])
-{
-int i;
-for (i = 0; i < 16; i++)
-av_log(log_ctx, level, "%02"PRIx8, md5[i]);
-}
-
 static int verify_md5(HEVCContext *s, AVFrame *frame)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+char msg_buf[4 * (50 + 2 * 2 * 16 /* MD5-size */)];
 int pixel_shift;
+int err = 0;
 int i, j;
 
 if (!desc)
@@ -3392,9 +3388,6 @@ static int verify_md5(HEVCContext *s, AVFrame *frame)
 
 pixel_shift = desc->comp[0].depth > 8;
 
-av_log(s->avctx, AV_LOG_DEBUG, "Verifying checksum for frame with POC %d: 
",
-   s->poc);
-
 /* the checksums are LE, so we have to byteswap for >8bpp formats
  * on BE arches */
 #if HAVE_BIGENDIAN
@@ -3407,6 +3400,7 @@ static int verify_md5(HEVCContext *s, AVFrame *frame)
 }
 #endif
 
+msg_buf[0] = '\0';
 for (i = 0; frame->data[i]; i++) {
 int width  = s->avctx->coded_width;
 int height = s->avctx->coded_height;
@@ -3428,23 +3422,26 @@ static int verify_md5(HEVCContext *s, AVFrame *frame)
 }
 av_md5_final(s->md5_ctx, md5);
 
+#define MD5_PRI "%016" PRIx64 "%016" PRIx64
+#define MD5_PRI_ARG(buf) AV_RB64(buf), AV_RB64((const uint8_t*)(buf) + 8)
+
 if (!memcmp(md5, s->sei.picture_hash.md5[i], 16)) {
-av_log   (s->avctx, AV_LOG_DEBUG, "plane %d - correct ", i);
-print_md5(s->avctx, AV_LOG_DEBUG, md5);
-av_log   (s->avctx, AV_LOG_DEBUG, "; ");
+av_strlcatf(msg_buf, sizeof(msg_buf),
+"plane %d - correct " MD5_PRI "; ",
+i, MD5_PRI_ARG(md5));
 } else {
-av_log   (s->avctx, AV_LOG_ERROR, "mismatching checksum of plane 
%d - ", i);
-print_md5(s->avctx, AV_LOG_ERROR, md5);
-av_log   (s->avctx, AV_LOG_ERROR, " != ");
-print_md5(s->avctx, AV_LOG_ERROR, s->sei.picture_hash.md5[i]);
-av_log   (s->avctx, AV_LOG_ERROR, "\n");
-return AVERROR_INVALIDDATA;
+av_strlcatf(msg_buf, sizeof(msg_buf),
+   "mismatching checksum of plane %d - " MD5_PRI " != " 
MD5_PRI "; ",
+i, MD5_PRI_ARG(md5), 
MD5_PRI_ARG(s->sei.picture_hash.md5[i]));
+err = AVERROR_INVALIDDATA;
 }
 }
 
-av_log(s->avctx, AV_LOG_DEBUG, "\n");
+av_log(s->avctx, err < 0 ? AV_LOG_ERROR : AV_LOG_DEBUG,
+   "Verifying checksum for frame with POC %d: %s\n",
+   s->poc, msg_buf);
 
-return 0;
+return err;
 }
 
 static int hevc_decode_extradata(HEVCContext *s, uint8_t *buf, int length, int 
first)
-- 
2.34.1

___
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 17/18] avcodec/pthread_slice: Reuse buffer if possible

2022-07-22 Thread Andreas Rheinhardt

Tomas Härdin:
> fre 2022-07-01 klockan 00:29 +0200 skrev Andreas Rheinhardt:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/pthread_slice.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
>> index 756cc59dbf..a4d31c6f4d 100644
>> --- a/libavcodec/pthread_slice.c
>> +++ b/libavcodec/pthread_slice.c
>> @@ -242,9 +242,11 @@ int
>> ff_slice_thread_allocz_entries(AVCodecContext *avctx, int count)
>>  if (avctx->active_thread_type & FF_THREAD_SLICE)  {
>>  SliceThreadContext *p = avctx->internal->thread_ctx;
>>  
>> -    if (p->entries) {
>> -    av_freep(&p->entries);
>> +    if (p->entries_count == count) {
>> +    memset(p->entries, 0, p->entries_count * sizeof(*p-
>>> entries));
>> +    return 0;
> 
> Couldn't this trivially handle p->entries_count < count also?
> 

Yes, but then this would basically be yet another never-shrinking
buffer. And with every such never-shrinking buffer I fear that we might
allocate too much forever (e.g. because of a single invalid packet).

>>  }
>> +    av_freep(&p->entries);
>>  
>>  p->entries   = av_calloc(count, sizeof(*p->entries));
>>  if (!p->entries) {
> 
> Looks like we could use an av_fast_calloc()
> 
> /Tomas
> 

___
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] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

2022-07-22 Thread Michael Niedermayer

On Sat, Jul 23, 2022 at 12:06:29AM +0530, Gyan Doshi wrote:
> Is the News entry forthcoming?

sounds like you want to write the news entry?
Please go ahead

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
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/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread Alex Converse

On Fri, Jul 22, 2022 at 8:37 AM James Almer  wrote:
> On 7/22/2022 12:14 PM, Andreas Rheinhardt wrote:
> > James Almer:
> >> On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:
> >>> James Almer:
>  On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:
> > James Almer:
> >> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
> >>> James Almer:
>  On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
> > James Almer:
> >> Should fix ticket #3361
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> This also needs an update to some fate ref samples i'll upload
> >> before
> >> pushing
> >> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which
> >> are now
> >> decoded
> >> properly as he_aac mono, so the .s16 files need to be replaced).
> >>
> >

[snip]

> >>
> >>
> >> it seems at least for these samples the fixed decoder does not
> >> generate
> >> a decoded stream comparable to the float one, so I'll just upload a
> >> new
> >> raw pcm file.
> >
> > When I decode both of these streams with git master, the left
> > channel is
> > pretty much identical, yet the right channel of the fixed-point decoder
> > is silent and the right channel of the floating point decoder is not.
> > With this patch applied, the result are two mono streams that are
> > pretty
> > much identical: The test sample created by the floating-point decoder
> > works with the fixed-point decoder test (if one uncomments and modifies
> > the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
> > upload new samples.
> 
>  Ok, can you suggest how to add a test that decodes with the fixed point
>  decoder then compares that with the output of the float decoder? Is
>  there a helper in fate.sh already for this?
> 
> >>>
> >>> There is currently no helper in fate-run.sh for this.
> >>
> >> Yeah, figures that's the case. Can you suggest how one would work for this?
> >>
> >
> > A new function in fate-run.sh seems to be necessary. Given that a
> > similar situation exists for AC-3 we should not hardcode aac; instead it
> > should have two parameters for the float and the fixed decoder. Then it
> > should decode the input file twice and do the same comparison that the
> > current tests use (they use the oneoff method, which results in
> > do_tiny_psnr with MAXDIFF being called).
> > I think the tests for the fixed-point decoder (with checksums) should be
> > separate, so that one can test this without the floating-point decoder
> > being present.
> >
> >>>
> >
> > - Andreas
> >
> > PS: libfdk-aac produces a file that looks pretty much like the floating
> > point decoder from git master. Are you sure your patch is correct?
> 
>  Yes, they duplicate the single channel in the stream and output it as
>  stereo, something that should be done by a filter if that's what the
>  user wants. Decoding a mono sample should generate a mono stream.
> >>>
> >>> Not really. The channels are different.
> >>
> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> >> channelmap=channel_layout=mono:map=0 -f md5 -
> >>
> >> has the same result as
> >>
> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> >> channelmap=channel_layout=mono:map=1 -f md5 -
> >>
> >> Same with the samples in the ticket.
> >>
> >
> > This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for
> > al_sbr_ps_06_new.mp4.
>
> So looks like nearly a hundred samples into al_sbr_ps_06_new.mp4 frames
> start containing PS info. With this patch the decoder properly decodes
> the first hundred as mono, but since the decoder is locked, it will keep
> decoding the stereo samples as mono.
>

Hey all,

I thought I should share a little bit of context about this problem,
but I don't mean to come back from nowhere and try to overrule you
all. Do what you decide is best.

An HE-AACv2 decoder treating unsignaled mono as stereo is an
intentional design trade-off that the MPEG audio committee made. It is
a tradeoff that the FFmpeg decoder has mimicked for a number of years.
If you want to revisit the trade-off (and there may very well be good
reasons to do that) that's fine, but I think treating the current
behavior as a "bug" is the wrong approach.

In fact, those fate tests are based on a Coding Technologies test
suite designed to validate a decoder conformed to the MPEG behavior.

Parametric Stereo is nested inside the SBR extension after the main
SBR payload which itself is nested inside the AAC raw data block after
the main channel elements. It takes a full bitstream parse of both the
AAC and SBR layers and finding an SBR intra-frame to even see if PS is
present.


As for why I think MPEG made this trade-off (my opinion of why they did this) :
- It enables cutting (or joining a stream of) audio

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread James Almer


On 7/22/2022 8:00 PM, Alex Converse wrote:

On Fri, Jul 22, 2022 at 8:37 AM James Almer  wrote:

On 7/22/2022 12:14 PM, Andreas Rheinhardt wrote:

James Almer:

On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:

James Almer:

On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:

James Almer:

Should fix ticket #3361

Signed-off-by: James Almer 
---
This also needs an update to some fate ref samples i'll upload
before
pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which
are now
decoded
properly as he_aac mono, so the .s16 files need to be replaced).





[snip]




it seems at least for these samples the fixed decoder does not
generate
a decoded stream comparable to the float one, so I'll just upload a
new
raw pcm file.


When I decode both of these streams with git master, the left
channel is
pretty much identical, yet the right channel of the fixed-point decoder
is silent and the right channel of the floating point decoder is not.
With this patch applied, the result are two mono streams that are
pretty
much identical: The test sample created by the floating-point decoder
works with the fixed-point decoder test (if one uncomments and modifies
the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
upload new samples.


Ok, can you suggest how to add a test that decodes with the fixed point
decoder then compares that with the output of the float decoder? Is
there a helper in fate.sh already for this?



There is currently no helper in fate-run.sh for this.


Yeah, figures that's the case. Can you suggest how one would work for this?



A new function in fate-run.sh seems to be necessary. Given that a
similar situation exists for AC-3 we should not hardcode aac; instead it
should have two parameters for the float and the fixed decoder. Then it
should decode the input file twice and do the same comparison that the
current tests use (they use the oneoff method, which results in
do_tiny_psnr with MAXDIFF being called).
I think the tests for the fixed-point decoder (with checksums) should be
separate, so that one can test this without the floating-point decoder
being present.





- Andreas

PS: libfdk-aac produces a file that looks pretty much like the floating
point decoder from git master. Are you sure your patch is correct?


Yes, they duplicate the single channel in the stream and output it as
stereo, something that should be done by a filter if that's what the
user wants. Decoding a mono sample should generate a mono stream.


Not really. The channels are different.


./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=0 -f md5 -

has the same result as

./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
channelmap=channel_layout=mono:map=1 -f md5 -

Same with the samples in the ticket.



This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for
al_sbr_ps_06_new.mp4.


So looks like nearly a hundred samples into al_sbr_ps_06_new.mp4 frames
start containing PS info. With this patch the decoder properly decodes
the first hundred as mono, but since the decoder is locked, it will keep
decoding the stereo samples as mono.



Hey all,

I thought I should share a little bit of context about this problem,
but I don't mean to come back from nowhere and try to overrule you
all. Do what you decide is best.

An HE-AACv2 decoder treating unsignaled mono as stereo is an
intentional design trade-off that the MPEG audio committee made. It is
a tradeoff that the FFmpeg decoder has mimicked for a number of years.
If you want to revisit the trade-off (and there may very well be good
reasons to do that) that's fine, but I think treating the current
behavior as a "bug" is the wrong approach.

In fact, those fate tests are based on a Coding Technologies test
suite designed to validate a decoder conformed to the MPEG behavior.

Parametric Stereo is nested inside the SBR extension after the main
SBR payload which itself is nested inside the AAC raw data block after
the main channel elements. It takes a full bitstream parse of both the
AAC and SBR layers and finding an SBR intra-frame to even see if PS is
present.


As for why I think MPEG made this trade-off (my opinion of why they did this) :
- It enables cutting (or joining a stream of) audio at arbitrary
frames without losing PS content or stereo detection.
- Most devices with mono output can support downmixing from stereo.
- Down mixing stereo to mono can be ugly with regard to phase but it
doesn't have nearly the complexity of the taste/environment/judgment
factor that surround sound to stereo downmix does.
- In transcode scenarios, most output codecs can support encoding
stereo formatted audio where both channels are identical quite
efficiently (even in AAC-LC with mid-side coding the overhead for
mono-coded as stereo is a single digit number

Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

2022-07-22 Thread Gyan Doshi





On 2022-07-23 02:16 am, Michael Niedermayer wrote:

On Sat, Jul 23, 2022 at 12:06:29AM +0530, Gyan Doshi wrote:

Is the News entry forthcoming?

sounds like you want to write the news entry?


Not exactly. For 4.3, it was never posted. I did it 10 months after the 
release.

So just checking if it's on your radar.

Will do it tomorrow if not posted by then.

Regards,
Gyan
___
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/5] avcodec/hq_hqa: Remove transient GetByteContext from context

2022-07-22 Thread Andreas Rheinhardt

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/hq_hqa.c | 48 +++--
 libavcodec/hq_hqa.h |  2 --
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
index 9a07d83114..a17fa18bf8 100644
--- a/libavcodec/hq_hqa.c
+++ b/libavcodec/hq_hqa.c
@@ -24,6 +24,7 @@
 #include "libavutil/intreadwrite.h"
 
 #include "avcodec.h"
+#include "bytestream.h"
 #include "canopus.h"
 #include "codec_internal.h"
 #include "get_bits.h"
@@ -114,12 +115,12 @@ static int hq_decode_mb(HQContext *c, AVFrame *pic,
 return 0;
 }
 
-static int hq_decode_frame(HQContext *ctx, AVFrame *pic,
+static int hq_decode_frame(HQContext *ctx, AVFrame *pic, GetByteContext *gbc,
int prof_num, size_t data_size)
 {
 const HQProfile *profile;
 GetBitContext gb;
-const uint8_t *perm, *src = ctx->gbc.buffer;
+const uint8_t *perm, *src = gbc->buffer;
 uint32_t slice_off[21];
 int slice, start_off, next_off, i, ret;
 
@@ -144,7 +145,7 @@ static int hq_decode_frame(HQContext *ctx, AVFrame *pic,
 
 /* Offsets are stored from CUV position, so adjust them accordingly. */
 for (i = 0; i < profile->num_slices + 1; i++)
-slice_off[i] = bytestream2_get_be24(&ctx->gbc) - 4;
+slice_off[i] = bytestream2_get_be24(gbc) - 4;
 
 next_off = 0;
 for (slice = 0; slice < profile->num_slices; slice++) {
@@ -240,20 +241,20 @@ static int hqa_decode_slice(HQContext *ctx, AVFrame *pic, 
GetBitContext *gb,
 return 0;
 }
 
-static int hqa_decode_frame(HQContext *ctx, AVFrame *pic, size_t data_size)
+static int hqa_decode_frame(HQContext *ctx, AVFrame *pic, GetByteContext *gbc, 
size_t data_size)
 {
 GetBitContext gb;
 const int num_slices = 8;
 uint32_t slice_off[9];
 int i, slice, ret;
 int width, height, quant;
-const uint8_t *src = ctx->gbc.buffer;
+const uint8_t *src = gbc->buffer;
 
-if (bytestream2_get_bytes_left(&ctx->gbc) < 8 + 4*(num_slices + 1))
+if (bytestream2_get_bytes_left(gbc) < 8 + 4*(num_slices + 1))
 return AVERROR_INVALIDDATA;
 
-width  = bytestream2_get_be16(&ctx->gbc);
-height = bytestream2_get_be16(&ctx->gbc);
+width  = bytestream2_get_be16(gbc);
+height = bytestream2_get_be16(gbc);
 
 ret = ff_set_dimensions(ctx->avctx, width, height);
 if (ret < 0)
@@ -266,8 +267,8 @@ static int hqa_decode_frame(HQContext *ctx, AVFrame *pic, 
size_t data_size)
 
 av_log(ctx->avctx, AV_LOG_VERBOSE, "HQA Profile\n");
 
-quant = bytestream2_get_byte(&ctx->gbc);
-bytestream2_skip(&ctx->gbc, 3);
+quant = bytestream2_get_byte(gbc);
+bytestream2_skip(gbc, 3);
 if (quant >= NUM_HQ_QUANTS) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"Invalid quantization matrix %d.\n", quant);
@@ -280,7 +281,7 @@ static int hqa_decode_frame(HQContext *ctx, AVFrame *pic, 
size_t data_size)
 
 /* Offsets are stored from HQA1 position, so adjust them accordingly. */
 for (i = 0; i < num_slices + 1; i++)
-slice_off[i] = bytestream2_get_be32(&ctx->gbc) - 4;
+slice_off[i] = bytestream2_get_be32(gbc) - 4;
 
 for (slice = 0; slice < num_slices; slice++) {
 if (slice_off[slice] < (num_slices + 1) * 3 ||
@@ -305,32 +306,33 @@ static int hq_hqa_decode_frame(AVCodecContext *avctx, 
AVFrame *pic,
int *got_frame, AVPacket *avpkt)
 {
 HQContext *ctx = avctx->priv_data;
+GetByteContext gbc0, *const gbc = &gbc0;
 uint32_t info_tag;
 unsigned int data_size;
 int ret;
 unsigned tag;
 
-bytestream2_init(&ctx->gbc, avpkt->data, avpkt->size);
-if (bytestream2_get_bytes_left(&ctx->gbc) < 4 + 4) {
+bytestream2_init(gbc, avpkt->data, avpkt->size);
+if (bytestream2_get_bytes_left(gbc) < 4 + 4) {
 av_log(avctx, AV_LOG_ERROR, "Frame is too small (%d).\n", avpkt->size);
 return AVERROR_INVALIDDATA;
 }
 
-info_tag = bytestream2_peek_le32(&ctx->gbc);
+info_tag = bytestream2_peek_le32(gbc);
 if (info_tag == MKTAG('I', 'N', 'F', 'O')) {
 int info_size;
-bytestream2_skip(&ctx->gbc, 4);
-info_size = bytestream2_get_le32(&ctx->gbc);
-if (info_size < 0 || bytestream2_get_bytes_left(&ctx->gbc) < 
info_size) {
+bytestream2_skip(gbc, 4);
+info_size = bytestream2_get_le32(gbc);
+if (info_size < 0 || bytestream2_get_bytes_left(gbc) < info_size) {
 av_log(avctx, AV_LOG_ERROR, "Invalid INFO size (%d).\n", 
info_size);
 return AVERROR_INVALIDDATA;
 }
-ff_canopus_parse_info_tag(avctx, ctx->gbc.buffer, info_size);
+ff_canopus_parse_info_tag(avctx, gbc->buffer, info_size);
 
-bytestream2_skip(&ctx->gbc, info_size);
+bytestream2_skip(gbc, info_size);
 }
 
-data_size = bytestream2_get_bytes_left(&ctx->gbc);
+data_size = bytestream2_get_bytes_left(gbc);
 if (data_size < 4) {
 av_l

[FFmpeg-devel] [PATCH 2/5] avcodec/vp56.h: Move VP8-only functions to vp8.c

2022-07-22 Thread Andreas Rheinhardt

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vp56.h | 36 +---
 libavcodec/vp8.c  | 34 ++
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index d2e6ad3ed0..08172e1987 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -339,7 +339,7 @@ static int vp56_rac_gets(VP56RangeCoder *c, int bits)
 return value;
 }
 
-static int vp8_rac_get_uint(VP56RangeCoder *c, int bits)
+static av_unused int vp8_rac_get_uint(VP56RangeCoder *c, int bits)
 {
 int value = 0;
 
@@ -350,22 +350,6 @@ static int vp8_rac_get_uint(VP56RangeCoder *c, int bits)
 return value;
 }
 
-// fixme: add 1 bit to all the calls to this?
-static av_unused int vp8_rac_get_sint(VP56RangeCoder *c, int bits)
-{
-int v;
-
-if (!vp8_rac_get(c))
-return 0;
-
-v = vp8_rac_get_uint(c, bits);
-
-if (vp8_rac_get(c))
-v = -v;
-
-return v;
-}
-
 // P(7)
 static av_unused int vp56_rac_gets_nn(VP56RangeCoder *c, int bits)
 {
@@ -373,12 +357,6 @@ static av_unused int vp56_rac_gets_nn(VP56RangeCoder *c, 
int bits)
 return v + !v;
 }
 
-static av_unused int vp8_rac_get_nn(VP56RangeCoder *c)
-{
-int v = vp8_rac_get_uint(c, 7) << 1;
-return v + !v;
-}
-
 static av_always_inline
 int vp56_rac_get_tree(VP56RangeCoder *c,
   const VP56Tree *tree,
@@ -407,16 +385,4 @@ static av_always_inline int 
vp8_rac_get_tree(VP56RangeCoder *c, const int8_t (*t
 return -i;
 }
 
-// DCTextra
-static av_always_inline int vp8_rac_get_coeff(VP56RangeCoder *c, const uint8_t 
*prob)
-{
-int v = 0;
-
-do {
-v = (v<<1) + vp56_rac_get_prob(c, *prob++);
-} while (*prob);
-
-return v;
-}
-
 #endif /* AVCODEC_VP56_H */
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 10de962118..9e7616990f 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -52,6 +52,40 @@
 #define VPX(vp7, f) vp8_ ## f
 #endif
 
+// fixme: add 1 bit to all the calls to this?
+static int vp8_rac_get_sint(VP56RangeCoder *c, int bits)
+{
+int v;
+
+if (!vp8_rac_get(c))
+return 0;
+
+v = vp8_rac_get_uint(c, bits);
+
+if (vp8_rac_get(c))
+v = -v;
+
+return v;
+}
+
+static int vp8_rac_get_nn(VP56RangeCoder *c)
+{
+int v = vp8_rac_get_uint(c, 7) << 1;
+return v + !v;
+}
+
+// DCTextra
+static int vp8_rac_get_coeff(VP56RangeCoder *c, const uint8_t *prob)
+{
+int v = 0;
+
+do {
+v = (v<<1) + vp56_rac_get_prob(c, *prob++);
+} while (*prob);
+
+return v;
+}
+
 static void free_buffers(VP8Context *s)
 {
 int i;
-- 
2.34.1

___
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/5] avcodec/vp56: Move VP8/9-only rac functions to a header of their own

2022-07-22 Thread Andreas Rheinhardt

Also rename these functions from vp8_rac_* to vp89_rac_*.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vp56.h |  31 
 libavcodec/vp8.c  | 166 +-
 libavcodec/vp89_rac.h |  66 +
 libavcodec/vp9.c  |  49 +++--
 libavcodec/vp9block.c |  84 ++---
 libavcodec/vp9mvs.c   |  21 +++---
 6 files changed, 229 insertions(+), 188 deletions(-)
 create mode 100644 libavcodec/vp89_rac.h

diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index 08172e1987..174f126309 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -322,12 +322,6 @@ static av_always_inline int vp56_rac_get(VP56RangeCoder *c)
 return bit;
 }
 
-// rounding is different than vp56_rac_get, is vp56_rac_get wrong?
-static av_always_inline int vp8_rac_get(VP56RangeCoder *c)
-{
-return vp56_rac_get_prob(c, 128);
-}
-
 static int vp56_rac_gets(VP56RangeCoder *c, int bits)
 {
 int value = 0;
@@ -339,17 +333,6 @@ static int vp56_rac_gets(VP56RangeCoder *c, int bits)
 return value;
 }
 
-static av_unused int vp8_rac_get_uint(VP56RangeCoder *c, int bits)
-{
-int value = 0;
-
-while (bits--) {
-value = (value << 1) | vp8_rac_get(c);
-}
-
-return value;
-}
-
 // P(7)
 static av_unused int vp56_rac_gets_nn(VP56RangeCoder *c, int bits)
 {
@@ -371,18 +354,4 @@ int vp56_rac_get_tree(VP56RangeCoder *c,
 return -tree->val;
 }
 
-// how probabilities are associated with decisions is different I think
-// well, the new scheme fits in the old but this way has one fewer branches 
per decision
-static av_always_inline int vp8_rac_get_tree(VP56RangeCoder *c, const int8_t 
(*tree)[2],
-   const uint8_t *probs)
-{
-int i = 0;
-
-do {
-i = tree[i][vp56_rac_get_prob(c, probs[i])];
-} while (i > 0);
-
-return -i;
-}
-
 #endif /* AVCODEC_VP56_H */
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 9e7616990f..ade7769943 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -38,6 +38,7 @@
 #include "thread.h"
 #include "threadframe.h"
 #include "vp8.h"
+#include "vp89_rac.h"
 #include "vp8data.h"
 
 #if ARCH_ARM
@@ -57,12 +58,12 @@ static int vp8_rac_get_sint(VP56RangeCoder *c, int bits)
 {
 int v;
 
-if (!vp8_rac_get(c))
+if (!vp89_rac_get(c))
 return 0;
 
-v = vp8_rac_get_uint(c, bits);
+v = vp89_rac_get_uint(c, bits);
 
-if (vp8_rac_get(c))
+if (vp89_rac_get(c))
 v = -v;
 
 return v;
@@ -70,7 +71,7 @@ static int vp8_rac_get_sint(VP56RangeCoder *c, int bits)
 
 static int vp8_rac_get_nn(VP56RangeCoder *c)
 {
-int v = vp8_rac_get_uint(c, 7) << 1;
+int v = vp89_rac_get_uint(c, 7) << 1;
 return v + !v;
 }
 
@@ -303,11 +304,11 @@ static void parse_segment_info(VP8Context *s)
 VP56RangeCoder *c = &s->c;
 int i;
 
-s->segmentation.update_map = vp8_rac_get(c);
-s->segmentation.update_feature_data = vp8_rac_get(c);
+s->segmentation.update_map = vp89_rac_get(c);
+s->segmentation.update_feature_data = vp89_rac_get(c);
 
 if (s->segmentation.update_feature_data) {
-s->segmentation.absolute_vals = vp8_rac_get(c);
+s->segmentation.absolute_vals = vp89_rac_get(c);
 
 for (i = 0; i < 4; i++)
 s->segmentation.base_quant[i]   = vp8_rac_get_sint(c, 7);
@@ -317,7 +318,7 @@ static void parse_segment_info(VP8Context *s)
 }
 if (s->segmentation.update_map)
 for (i = 0; i < 3; i++)
-s->prob->segmentid[i] = vp8_rac_get(c) ? vp8_rac_get_uint(c, 8) : 
255;
+s->prob->segmentid[i] = vp89_rac_get(c) ? vp89_rac_get_uint(c, 8) 
: 255;
 }
 
 static void update_lf_deltas(VP8Context *s)
@@ -326,19 +327,19 @@ static void update_lf_deltas(VP8Context *s)
 int i;
 
 for (i = 0; i < 4; i++) {
-if (vp8_rac_get(c)) {
-s->lf_delta.ref[i] = vp8_rac_get_uint(c, 6);
+if (vp89_rac_get(c)) {
+s->lf_delta.ref[i] = vp89_rac_get_uint(c, 6);
 
-if (vp8_rac_get(c))
+if (vp89_rac_get(c))
 s->lf_delta.ref[i] = -s->lf_delta.ref[i];
 }
 }
 
 for (i = MODE_I4x4; i <= VP8_MVMODE_SPLIT; i++) {
-if (vp8_rac_get(c)) {
-s->lf_delta.mode[i] = vp8_rac_get_uint(c, 6);
+if (vp89_rac_get(c)) {
+s->lf_delta.mode[i] = vp89_rac_get_uint(c, 6);
 
-if (vp8_rac_get(c))
+if (vp89_rac_get(c))
 s->lf_delta.mode[i] = -s->lf_delta.mode[i];
 }
 }
@@ -350,7 +351,7 @@ static int setup_partitions(VP8Context *s, const uint8_t 
*buf, int buf_size)
 int i;
 int ret;
 
-s->num_coeff_partitions = 1 << vp8_rac_get_uint(&s->c, 2);
+s->num_coeff_partitions = 1 << vp89_rac_get_uint(&s->c, 2);
 
 buf  += 3 * (s->num_coeff_partitions - 1);
 buf_size -= 3 * (s->num_coeff_partitions - 1);
@@ -380,12 +381,12 @@ static void vp7_get_quants(VP8Context *s)
 {
 VP56RangeCoder *c = &s

[FFmpeg-devel] [PATCH 4/5] avcodec/vp56: Move VP5-9 range coder functions to a header of their own

2022-07-22 Thread Andreas Rheinhardt

Also use a vpx prefix for them.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/Makefile  |  12 +-
 libavcodec/arm/vp8.h |   4 +-
 libavcodec/arm/vp8_armv6.S   |   2 +-
 libavcodec/arm/{vp56_arith.h => vpx_arith.h} |  18 +-
 libavcodec/vp5.c |  63 +++
 libavcodec/vp56.c|  15 +-
 libavcodec/vp56.h| 118 +
 libavcodec/vp6.c |  77 -
 libavcodec/vp8.c | 171 ++-
 libavcodec/vp8.h |   5 +-
 libavcodec/vp89_rac.h|  14 +-
 libavcodec/vp9.c |  73 
 libavcodec/vp9block.c| 117 ++---
 libavcodec/vp9dec.h  |   7 +-
 libavcodec/vp9mvs.c  |  12 +-
 libavcodec/{vp56rac.c => vpx_rac.c}  |   6 +-
 libavcodec/vpx_rac.h | 135 +++
 libavcodec/x86/{vp56_arith.h => vpx_arith.h} |  14 +-
 18 files changed, 454 insertions(+), 409 deletions(-)
 rename libavcodec/arm/{vp56_arith.h => vpx_arith.h} (88%)
 rename libavcodec/{vp56rac.c => vpx_rac.c} (92%)
 create mode 100644 libavcodec/vpx_rac.h
 rename libavcodec/x86/{vp56_arith.h => vpx_arith.h} (83%)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ef2318438b..a4fab108d6 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -737,11 +737,11 @@ OBJS-$(CONFIG_VORBIS_DECODER)  += vorbisdec.o 
vorbisdsp.o vorbis.o \
 OBJS-$(CONFIG_VORBIS_ENCODER)  += vorbisenc.o vorbis.o \
   vorbis_data.o
 OBJS-$(CONFIG_VP3_DECODER) += vp3.o
-OBJS-$(CONFIG_VP5_DECODER) += vp5.o vp56.o vp56data.o vp56rac.o
+OBJS-$(CONFIG_VP5_DECODER) += vp5.o vp56.o vp56data.o vpx_rac.o
 OBJS-$(CONFIG_VP6_DECODER) += vp6.o vp56.o vp56data.o \
-  vp6dsp.o vp56rac.o
-OBJS-$(CONFIG_VP7_DECODER) += vp8.o vp56rac.o
-OBJS-$(CONFIG_VP8_DECODER) += vp8.o vp56rac.o
+  vp6dsp.o vpx_rac.o
+OBJS-$(CONFIG_VP7_DECODER) += vp8.o vpx_rac.o
+OBJS-$(CONFIG_VP8_DECODER) += vp8.o vpx_rac.o
 OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VP8_MEDIACODEC_DECODER)  += mediacodecdec.o
 OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec.o
@@ -750,7 +750,7 @@ OBJS-$(CONFIG_VP8_VAAPI_ENCODER)   += vaapi_encode_vp8.o
 OBJS-$(CONFIG_VP8_V4L2M2M_DECODER) += v4l2_m2m_dec.o
 OBJS-$(CONFIG_VP8_V4L2M2M_ENCODER) += v4l2_m2m_enc.o
 OBJS-$(CONFIG_VP9_DECODER) += vp9.o vp9data.o vp9dsp.o vp9lpf.o 
vp9recon.o \
-  vp9block.o vp9prob.o vp9mvs.o 
vp56rac.o \
+  vp9block.o vp9prob.o vp9mvs.o 
vpx_rac.o \
   vp9dsp_8bpp.o vp9dsp_10bpp.o 
vp9dsp_12bpp.o
 OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
@@ -1234,7 +1234,7 @@ SKIPHEADERS+= %_tablegen.h
  \
   aaccoder_trellis.h\
   aacenc_quantization.h \
   aacenc_quantization_misc.h\
-  $(ARCH)/vp56_arith.h  \
+  $(ARCH)/vpx_arith.h  \
 
 SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += d3d11va.h dxva2_internal.h
diff --git a/libavcodec/arm/vp8.h b/libavcodec/arm/vp8.h
index 965342d93b..7c59a7d63d 100644
--- a/libavcodec/arm/vp8.h
+++ b/libavcodec/arm/vp8.h
@@ -22,12 +22,12 @@
 #include 
 
 #include "config.h"
-#include "libavcodec/vp56.h"
+#include "libavcodec/vpx_rac.h"
 #include "libavcodec/vp8.h"
 
 #if HAVE_ARMV6_EXTERNAL
 #define vp8_decode_block_coeffs_internal ff_decode_block_coeffs_armv6
-int ff_decode_block_coeffs_armv6(VP56RangeCoder *rc, int16_t block[16],
+int ff_decode_block_coeffs_armv6(VPXRangeCoder *rc, int16_t block[16],
  uint8_t probs[8][3][NUM_DCT_TOKENS-1],
  int i, uint8_t *token_prob, int16_t qmul[2]);
 #endif
diff --git a/libavcodec/arm/vp8_armv6.S b/libavcodec/arm/vp8_armv6.S
index e7d25a45c1..7ecf2641fb 100644
--- a/libavcodec/arm/vp8_armv6.S
+++ b/libavcodec/arm/vp8_armv6.S
@@ -65,7 +65,7 @@ T   orrcs   \cw, \cw, \t1
 
 function ff_decode_block_coeffs_armv6, export=1
 push{r0,r1,r4-r11,lr}
-movrelx lr,  X(ff_vp56_norm_shift)
+movrelx lr,  X(ff_vpx_norm_shift)
 ldrdr4,  r5,  [sp, #44] @ tok

[FFmpeg-devel] [PATCH 5/5] avcodec/vp8, vp9: Avoid using VP56mv and VP56Frame in VP8/9

2022-07-22 Thread Andreas Rheinhardt

Instead replace VP56mv by new and identical structures VP8mv and VP9mv.
Also replace VP56Frame by VP8FrameType in vp8.h and use that
in VP8 code. Also remove VP56_FRAME_GOLDEN2, as this has only
been used by VP8.

This allows to remove all inclusions of vp56.h from everything
that is not VP5/6. This also removes implicit inclusions
of hpeldsp.h, h264chroma.h, vp3dsp.h and vp56dsp.h from all VP8/9
files.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/nvdec_vp8.c   |   8 +-
 libavcodec/vaapi_vp8.c   |  18 ++---
 libavcodec/vp56.h|   1 -
 libavcodec/vp8.c | 138 +--
 libavcodec/vp8.h |  35 ++---
 libavcodec/vp9.c |   3 +-
 libavcodec/vp9_mc_template.c |   6 +-
 libavcodec/vp9block.c|   1 -
 libavcodec/vp9dec.h  |  10 ++-
 libavcodec/vp9mvs.c  |  11 ++-
 libavcodec/vp9prob.c |   2 -
 libavcodec/vp9recon.c|  12 +--
 libavcodec/vp9shared.h   |  10 ++-
 13 files changed, 135 insertions(+), 120 deletions(-)

diff --git a/libavcodec/nvdec_vp8.c b/libavcodec/nvdec_vp8.c
index 9c4608d8cf..1fbd56a289 100644
--- a/libavcodec/nvdec_vp8.c
+++ b/libavcodec/nvdec_vp8.c
@@ -39,7 +39,7 @@ static int nvdec_vp8_start_frame(AVCodecContext *avctx, const 
uint8_t *buffer, u
 CUVIDPICPARAMS *pp = &ctx->pic_params;
 FrameDecodeData *fdd;
 NVDECFrame *cf;
-AVFrame *cur_frame = h->framep[VP56_FRAME_CURRENT]->tf.f;
+AVFrame *cur_frame = h->framep[VP8_FRAME_CURRENT]->tf.f;
 
 int ret;
 
@@ -61,9 +61,9 @@ static int nvdec_vp8_start_frame(AVCodecContext *avctx, const 
uint8_t *buffer, u
 
 .first_partition_size= h->header_partition_size,
 
-.LastRefIdx  = 
safe_get_ref_idx(h->framep[VP56_FRAME_PREVIOUS]),
-.GoldenRefIdx= 
safe_get_ref_idx(h->framep[VP56_FRAME_GOLDEN]),
-.AltRefIdx   = 
safe_get_ref_idx(h->framep[VP56_FRAME_GOLDEN2]),
+.LastRefIdx  = 
safe_get_ref_idx(h->framep[VP8_FRAME_PREVIOUS]),
+.GoldenRefIdx= 
safe_get_ref_idx(h->framep[VP8_FRAME_GOLDEN]),
+.AltRefIdx   = 
safe_get_ref_idx(h->framep[VP8_FRAME_GOLDEN2]),
 /*
  * Explicit braces for anonymous inners and unnamed fields
  * to work around limitations in ancient versions of gcc.
diff --git a/libavcodec/vaapi_vp8.c b/libavcodec/vaapi_vp8.c
index 06c23e760b..cd1594e0fb 100644
--- a/libavcodec/vaapi_vp8.c
+++ b/libavcodec/vaapi_vp8.c
@@ -36,21 +36,21 @@ static int vaapi_vp8_start_frame(AVCodecContext  
*avctx,
  av_unused uint32_t   size)
 {
 const VP8Context *s = avctx->priv_data;
-VAAPIDecodePicture *pic = 
s->framep[VP56_FRAME_CURRENT]->hwaccel_picture_private;
+VAAPIDecodePicture *pic = 
s->framep[VP8_FRAME_CURRENT]->hwaccel_picture_private;
 VAPictureParameterBufferVP8 pp;
 VAProbabilityDataBufferVP8 prob;
 VAIQMatrixBufferVP8 quant;
 int err, i, j, k;
 
-pic->output_surface = vaapi_vp8_surface_id(s->framep[VP56_FRAME_CURRENT]);
+pic->output_surface = vaapi_vp8_surface_id(s->framep[VP8_FRAME_CURRENT]);
 
 pp = (VAPictureParameterBufferVP8) {
 .frame_width = avctx->width,
 .frame_height= avctx->height,
 
-.last_ref_frame  = 
vaapi_vp8_surface_id(s->framep[VP56_FRAME_PREVIOUS]),
-.golden_ref_frame= 
vaapi_vp8_surface_id(s->framep[VP56_FRAME_GOLDEN]),
-.alt_ref_frame   = 
vaapi_vp8_surface_id(s->framep[VP56_FRAME_GOLDEN2]),
+.last_ref_frame  = 
vaapi_vp8_surface_id(s->framep[VP8_FRAME_PREVIOUS]),
+.golden_ref_frame= 
vaapi_vp8_surface_id(s->framep[VP8_FRAME_GOLDEN]),
+.alt_ref_frame   = 
vaapi_vp8_surface_id(s->framep[VP8_FRAME_GOLDEN2]),
 .out_of_loop_frame   = VA_INVALID_SURFACE,
 
 .pic_fields.bits = {
@@ -67,8 +67,8 @@ static int vaapi_vp8_start_frame(AVCodecContext  
*avctx,
 .loop_filter_adj_enable  = s->lf_delta.enabled,
 .mode_ref_lf_delta_update= s->lf_delta.update,
 
-.sign_bias_golden= s->sign_bias[VP56_FRAME_GOLDEN],
-.sign_bias_alternate = s->sign_bias[VP56_FRAME_GOLDEN2],
+.sign_bias_golden= s->sign_bias[VP8_FRAME_GOLDEN],
+.sign_bias_alternate = s->sign_bias[VP8_FRAME_GOLDEN2],
 
 .mb_no_coeff_skip= s->mbskip_enabled,
 .loop_filter_disable = s->filter.level == 0,
@@ -177,7 +177,7 @@ fail:
 static int vaapi_vp8_end_frame(AVCodecContext *avctx)
 {
 const VP8Context *s = avctx->priv_data;
-VAAPIDecodePicture *pic = 
s->framep[VP56_FRAME_CURRENT]->hwaccel_picture_private;
+VAAPIDecodePictur

Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts

2022-07-22 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Michael Niedermayer:
>> On Sat, Jul 02, 2022 at 08:32:06AM +0200, Andreas Rheinhardt wrote:
>>> Michael Niedermayer:
 On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
> The HEVC decoder has both HEVCContext and HEVCLocalContext
> structures. The latter is supposed to be the structure
> containing the per-slicethread state.
>
> Yet up until now that is not how it is handled in practice:
> Each HEVCLocalContext has a unique HEVCContext allocated for it
> and each of these coincides except in exactly one field: The
> corresponding HEVCLocalContext. This makes it possible to pass
> the HEVCContext everywhere where logically a HEVCLocalContext
> should be used. And up until recently, this is how it has been done.
>
> Yet the preceding patches changed this, making it possible
> to avoid allocating redundant HEVCContexts.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/hevcdec.c | 40 
>  libavcodec/hevcdec.h |  2 --
>  2 files changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 9d1241f293..048fcc76b4 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2548,13 +2548,12 @@ static int hls_decode_entry_wpp(AVCodecContext 
> *avctxt, void *hevc_lclist,
>  {
>  HEVCLocalContext *lc = ((HEVCLocalContext**)hevc_lclist)[self_id];
>  const HEVCContext *const s = lc->parent;
> -HEVCContext *s1  = avctxt->priv_data;
> -int ctb_size= 1<< s1->ps.sps->log2_ctb_size;
> +int ctb_size= 1 << s->ps.sps->log2_ctb_size;
>  int more_data   = 1;
>  int ctb_row = job;
> -int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row * 
> ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
> -int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> -int thread = ctb_row % s1->threads_number;
> +int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row * 
> ((s->ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
> +int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> +int thread = ctb_row % s->threads_number;
>  int ret;
>  
>  if(ctb_row) {
> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecContext 
> *avctxt, void *hevc_lclist,
>  
>  ff_thread_await_progress2(s->avctx, ctb_row, thread, 
> SHIFT_CTB_WPP);
>  
> -if (atomic_load(&s1->wpp_err)) {
> +if (atomic_load(&s->wpp_err)) {
>  ff_thread_report_progress2(s->avctx, ctb_row , thread, 
> SHIFT_CTB_WPP);

 the consts in "const HEVCContext *const " make clang version 
 6.0.0-1ubuntu2 unhappy
 (this was building shared libs)


 CC libavcodec/hevcdec.o
 src/libavcodec/hevcdec.c:2574:13: error: address argument to atomic 
 operation must be a pointer to non-const _Atomic type ('const atomic_int 
 *' (aka 'const _Atomic(int) *') invalid)
 if (atomic_load(&s->wpp_err)) {
 ^   ~~~
 /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note: 
 expanded from macro 'atomic_load'
 #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
 ^ ~~
 1 error generated.
 src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o' failed
 make: *** [libavcodec/hevcdec.o] Error 1

 thx

>>>
>>> Thanks for testing this. atomic_load is indeed declared without const in
>>> 7.17.7.2:
>>>
>>> C atomic_load(volatile A *object);
>>>
>>> Upon reflection this makes sense, because if atomics are implemented via
>>> mutexes, even a read may involve a preceding write. So I'll cast const
>>> away here, too, and add a comment. (It works when casting const away,
>>> doesn't it?)
>>
>> This doesnt feel "right". These pointers should not be coming from a const
>> if they are written to
>>
> 
> The HEVCContext is not const because the underlying object is const; the
> HEVCContext is const when accessed from any part of the code that may be
> run from slice threads, because if a slice thread modifies it, you have
> a data race in case any of the other slice threads reads this field or
> modifies it itself. But this is by definition not true for atomic
> operations, so casting const away for them is fine.
> 
>> The compiler accepts it with an explicit cast though. With an implicit cast
>> it produces a warning
>>

Did the above explanation satisfy you? Or do you want something else?

- 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...@f

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH v2 3/3] hwcontext_vaapi: #if guard VAAPI_DRM specifics

[FFmpeg-devel] [PATCH v2 1/2] ffmpeg: refactor post-decoding steps for subtitles into a function

[FFmpeg-devel] [PATCH v2 2/2] ffmpeg: add video heartbeat capability to fix_sub_duration

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/tiff: Check tile_length and tile_width

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH 22/35] fftools: add an object pool

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext

Re: [FFmpeg-devel] [PATCH 22/35] fftools: add an object pool

[FFmpeg-devel] [PATCH] qsv: Update ffmpeg qsv_errors to recognize GPU hang

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: Rework the AVIF parser to handle multiple items

Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

[FFmpeg-devel] [PATCH] avcodec/hevcdec: Output MD5-message in one piece

Re: [FFmpeg-devel] [PATCH 17/18] avcodec/pthread_slice: Reuse buffer if possible

Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 42a0288 web/download: Add FFmpeg 5.1

[FFmpeg-devel] [PATCH 1/5] avcodec/hq_hqa: Remove transient GetByteContext from context

[FFmpeg-devel] [PATCH 2/5] avcodec/vp56.h: Move VP8-only functions to vp8.c

[FFmpeg-devel] [PATCH 3/5] avcodec/vp56: Move VP8/9-only rac functions to a header of their own

[FFmpeg-devel] [PATCH 4/5] avcodec/vp56: Move VP5-9 range coder functions to a header of their own

[FFmpeg-devel] [PATCH 5/5] avcodec/vp8, vp9: Avoid using VP56mv and VP56Frame in VP8/9

Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts

29 matches

Site Navigation

Mail list logo

Footer information