[FFmpeg-devel] [PATCH] vulkan_decode: use coded_width/height instead of the non-coded width and h
Fixes several samples. There may be issues with cropping, but so far, I have not found any in my samples set. Patch attached. >From b928053158ec5f63d3c07a9daa9b802cb9229858 Mon Sep 17 00:00:00 2001 From: Lynne Date: Tue, 24 Oct 2023 06:33:07 +0200 Subject: [PATCH] vulkan_decode: use coded_width/height instead of the non-coded width and height Fixes several samples. There may be issues with cropping, but so far, I have not found any in my samples set. --- libavcodec/vulkan_decode.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c index e6a0646139..3b9576c0a9 100644 --- a/libavcodec/vulkan_decode.c +++ b/libavcodec/vulkan_decode.c @@ -872,10 +872,10 @@ static int vulkan_decode_get_profile(AVCodecContext *avctx, AVBufferRef *frames_ " separate_references" : ""); /* Check if decoding is possible with the given parameters */ -if (avctx->width < caps->minCodedExtent.width || -avctx->height < caps->minCodedExtent.height || -avctx->width > caps->maxCodedExtent.width || -avctx->height > caps->maxCodedExtent.height) +if (avctx->coded_width < caps->minCodedExtent.width || +avctx->coded_height < caps->minCodedExtent.height || +avctx->coded_width > caps->maxCodedExtent.width || +avctx->coded_height > caps->maxCodedExtent.height) return AVERROR(EINVAL); if (!(avctx->hwaccel_flags & AV_HWACCEL_FLAG_IGNORE_LEVEL) && @@ -1027,8 +1027,8 @@ int ff_vk_frame_params(AVCodecContext *avctx, AVBufferRef *hw_frames_ctx) frames_ctx->user_opaque = prof; frames_ctx->free= free_profile_data; -frames_ctx->width = avctx->width; -frames_ctx->height = avctx->height; +frames_ctx->width = avctx->coded_width; +frames_ctx->height = avctx->coded_height; frames_ctx->format = AV_PIX_FMT_VULKAN; hwfc->format[0]= vkfmt; @@ -1224,8 +1224,8 @@ int ff_vk_decode_init(AVCodecContext *avctx) dpb_frames = (AVHWFramesContext *)ctx->dpb_hwfc_ref->data; dpb_frames->format= s->frames->format; dpb_frames->sw_format = s->frames->sw_format; -dpb_frames->width = s->frames->width; -dpb_frames->height= s->frames->height; +dpb_frames->width = avctx->coded_width; +dpb_frames->height= avctx->coded_height; dpb_hwfc = dpb_frames->hwctx; dpb_hwfc->create_pnext = (void *)ff_vk_find_struct(ctx->s.hwfc->create_pnext, -- 2.42.0 ___ 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] hwcontext_vulkan: improve queue family init code
Oct 22, 2023, 03:56 by d...@lynne.ee: > When users zero-init'd the struct, or left it as-is, the encode > queue family matched the graphics queue family, which led it to be > incorrectly logged as being used for encode. > > This just improves the logging so this isn't printed anymore. > > Patch attached. > pushed ___ 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] [REFUND-REQUEST]] VDD23 Travel
Stefano Sabatini 于2023年10月10日周二 14:09写道： Hi Stefano, > > On date Sunday 2023-10-08 10:09:03 +0800, Steven Liu wrote: > > Nice to see you all after so long. > > My request is for my flights, 9750,00 CNY Beijing from/to Abu Dhabi, > > Abu Dhabi from/to Dublin > > Approved on my side, pending Michael's approval. > > To get the refund, follow instructions here to generate a refund request: > https://www.spi-inc.org/treasurer/reimbursement-form/ > > When doing so, keep in mind that the XE Travel Expenses Calculator > service mentioned in step 2 is not active anymore - just attach the > receipts to the email. > > Then email it to: > treasu...@rt.spi-inc.org > > putting me and Michael in CC:, and adding the thread link from: CC Michael is ok, but CC your email get error response. > http://ffmpeg.org/pipermail/ffmpeg-devel/ > > Thanks. Thanks Steven ___ 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 00/13] YUVJ removal
On Sat, Oct 21, 2023 at 4:20 PM Michael Niedermayer wrote: > On Fri, Oct 20, 2023 at 07:13:00PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> wrote: > > > > > tbh while it's great that this functionality exists *somewhere* in > ffmpeg, > > > this is really something that should belong to the scaler filter > (whichever > > > implementation) > > > > > > > I agree. The reason this was done separately was to be able to have it at > > all. I considered doing it in sws and realized I probably wouldn't finish > > it. This was a path of less resistance. > > sws supports cascaded_context, with that a sws can just spawn multiple > sws to implement a path. > so if a sws can do just colorspace1->colorspace2 and one can scale > colorspace2 you can quite easily make it support > colorspace1 scaling into colorspace2 for example > > so anything should be quite add-able into sws that you have an > implementation for > Nothing is quite easily add-able to sws, or developers would have done so instead of writing 4 different scaling libraries -- Vittorio ___ 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 3/3] avutil/channel_layout: add a 7.1.4 channel layout
From: Will Wolcott
Mapping to ITU-R BS.2051-3 "Sound System J" and ITU-R BS.1196-8 "Channel
Configuration 19".
Signed-off-by: Will Wolcott
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
4 files changed, 6 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index bd71fb59c4..91e648cfe5 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -721,6 +721,8 @@ FL+FR+FC+BL+BR+BC+SL+SR
FL+FR+BL+BR+TFL+TFR+TBL+TBR
@item 5.1.4
FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
+@item 7.1.4
+FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
@item downmix
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 621606cd59..f529c4f7d0 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -204,6 +204,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "5.1.4", AV_CHANNEL_LAYOUT_5POINT1POINT4_BACK },
+{ "7.1.4", AV_CHANNEL_LAYOUT_7POINT1POINT4_BACK },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
{ "downmix",AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 49adf33880..1a67890e4d 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -236,6 +236,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_5POINT1POINT4_BACK
(AV_CH_LAYOUT_5POINT1POINT2_BACK|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
+#define AV_CH_LAYOUT_7POINT1POINT4_BACK
(AV_CH_LAYOUT_7POINT1|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
@@ -405,6 +406,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_5POINT1POINT4_BACK AV_CHANNEL_LAYOUT_MASK(10,
AV_CH_LAYOUT_5POINT1POINT4_BACK)
+#define AV_CHANNEL_LAYOUT_7POINT1POINT4_BACK AV_CHANNEL_LAYOUT_MASK(12,
AV_CH_LAYOUT_7POINT1POINT4_BACK)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index 194083fb71..f42bea9a0a 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -28,6 +28,7 @@ hexagonal FL+FR+FC+BL+BR+BC
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
5.1.4 FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
+7.1.4 FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
downmixDL+DR
22.2
FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL+TBC+TBR+LFE2+TSL+TSR+BFC+BFL+BFR
--
2.42.0
___
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/3] avutil/channel_layout: add a 5.1.4 channel layout
Mapping to ITU-R BS.2051-3 "Sound System D" and ITU-R BS.1196-8 "Channel
Configuration 16".
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
4 files changed, 6 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index 1388e5dabe..bd71fb59c4 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -719,6 +719,8 @@ FL+FR+FC+LFE+BL+BR+TFL+TFR
FL+FR+FC+BL+BR+BC+SL+SR
@item cube
FL+FR+BL+BR+TFL+TFR+TBL+TBR
+@item 5.1.4
+FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
@item downmix
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 558def4b9e..621606cd59 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -203,6 +203,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "5.1.2", AV_CHANNEL_LAYOUT_5POINT1POINT2_BACK },
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
+{ "5.1.4", AV_CHANNEL_LAYOUT_5POINT1POINT4_BACK },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
{ "downmix",AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 74e6889152..49adf33880 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -235,6 +235,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_5POINT1POINT2_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
+#define AV_CH_LAYOUT_5POINT1POINT4_BACK
(AV_CH_LAYOUT_5POINT1POINT2_BACK|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
@@ -403,6 +404,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_5POINT1POINT2_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_5POINT1POINT2_BACK)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
+#define AV_CHANNEL_LAYOUT_5POINT1POINT4_BACK AV_CHANNEL_LAYOUT_MASK(10,
AV_CH_LAYOUT_5POINT1POINT4_BACK)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index eece8293ad..194083fb71 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -27,6 +27,7 @@ hexagonal FL+FR+FC+BL+BR+BC
5.1.2 FL+FR+FC+LFE+BL+BR+TFL+TFR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
+5.1.4 FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
downmixDL+DR
22.2
FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL+TBC+TBR+LFE2+TSL+TSR+BFC+BFL+BFR
--
2.42.0
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
"Channel
Configuration 14", and it being the first layout with top layer channels, it's
best to use a different scheme to properly convey the presence and amount of
said
channels.
The new name will also be a better fit for the additions in the following
commits.
Signed-off-by: James Almer
---
doc/utils.texi| 2 +-
libavutil/channel_layout.c| 2 +-
libavutil/channel_layout.h| 8 ++--
tests/ref/fate/channel_layout | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 8e8bfa76d4..1388e5dabe 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -713,7 +713,7 @@ FL+FR+FC+LFE+BL+BR+SL+SR
FL+FR+FC+LFE+BL+BR+FLC+FRC
@item 7.1(wide-side)
FL+FR+FC+LFE+FLC+FRC+SL+SR
-@item 7.1(top)
+@item 5.1.2
FL+FR+FC+LFE+BL+BR+TFL+TFR
@item octagonal
FL+FR+FC+BL+BR+BC+SL+SR
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 9b581ae6b3..558def4b9e 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -200,7 +200,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.1",AV_CHANNEL_LAYOUT_7POINT1 },
{ "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
{ "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
-{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
+{ "5.1.2", AV_CHANNEL_LAYOUT_5POINT1POINT2_BACK },
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index ac2ddfa022..74e6889152 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -232,13 +232,15 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1
(AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
-#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
+#define AV_CH_LAYOUT_5POINT1POINT2_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
+#define AV_CH_LAYOUT_7POINT1_TOP_BACK AV_CH_LAYOUT_5POINT1POINT2
+
enum AVMatrixEncoding {
AV_MATRIX_ENCODING_NONE,
AV_MATRIX_ENCODING_DOLBY,
@@ -398,13 +400,15 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_7POINT1 AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE_BACK)
-#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_TOP_BACK)
+#define AV_CHANNEL_LAYOUT_5POINT1POINT2_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_5POINT1POINT2_BACK)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
+#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK
AV_CHANNEL_LAYOUT_5POINT1POINT2_BACK
+
#define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
{ /* .order */ AV_CHANNEL_ORDER_AMBISONIC, \
/* .nb_channels */ 4, \
diff --git a/tests/ref/fate/channel_layout
Re: [FFmpeg-devel] [PATCH 1/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:57 AM James Almer wrote:
>
> On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
> >>
> >> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >>>
> >>> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> >>> "Channel
> >>> Configuration 14", and it being the first layout with top layer channels,
> >>> it's
> >>> best to use a different scheme to properly convey the presence and amount
> >>> of said
> >>> channels.
> >>> The new name will also be a better fit for the additions in the following
> >>> commits.
> >>>
> >>> Signed-off-by: James Almer
> >>> ---
> >>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> >>> index ac2ddfa022..8c40c81b44 100644
> >>> --- a/libavutil/channel_layout.h
> >>> +++ b/libavutil/channel_layout.h
> >>> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> >>> #define AV_CH_LAYOUT_7POINT1
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>> +#define AV_CH_LAYOUT_5POINT1POINT2
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>
> >> Looking at the specs and the naming of the thing, I don't think it
> >> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> >> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> >> that, and not swap the base layer speakers.
> >> Looking at the specifications, they don't map properly to our speaker
> >> definitions, as they assign it a generic "surround" title (at 100-120
> >> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> >> and a side speaker at 90 (as is the standard for 7.1 setups).
> >>
> >> Yes, this doesn't match the one you are renaming, but I think
> >> consistency within our own defined formats is important here. 5.1 ->
> >> 5.1.2 should just add two.
> >>
> >> The renamed one could be 5.1.2(back) or whatever we want to name those.
> >>
> >> Or we do it properly and actually include a proper "surround" speaker
> >> definition and get rid of the confusion between side and back. But
> >> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> >> definitions are mostly sourced from, so might not be worth it.
> >
> > Actually I got confused by our terrible naming. The define
> > AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
> > AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
> > Regardless, rather see consistency within those as well, so while the
> > name of the format is fine, rename the define to include the _BACK
> > maybe?
>
> Yes, it's a mess.
>
> Do i use "5.1.2" alongside AV_CH_LAYOUT_5POINT1POINT2_BACK, then?
That works for me.
- Hendrik
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
"Channel
Configuration 14", and it being the first layout with top layer channels, it's
best to use a different scheme to properly convey the presence and amount of
said
channels.
The new name will also be a better fit for the additions in the following
commits.
Signed-off-by: James Almer
---
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index ac2ddfa022..8c40c81b44 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -232,13 +232,15 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1
(AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
-#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
+#define AV_CH_LAYOUT_5POINT1POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
Looking at the specs and the naming of the thing, I don't think it
should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
that, and not swap the base layer speakers.
Looking at the specifications, they don't map properly to our speaker
definitions, as they assign it a generic "surround" title (at 100-120
degrees azimuth), while a rear/back speaker should be at 135 degrees,
and a side speaker at 90 (as is the standard for 7.1 setups).
Yes, this doesn't match the one you are renaming, but I think
consistency within our own defined formats is important here. 5.1 ->
5.1.2 should just add two.
The renamed one could be 5.1.2(back) or whatever we want to name those.
Or we do it properly and actually include a proper "surround" speaker
definition and get rid of the confusion between side and back. But
that breaks compat with WAVEFORMATEXTENSIBLE that our channel
definitions are mostly sourced from, so might not be worth it.
Actually I got confused by our terrible naming. The define
AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
Regardless, rather see consistency within those as well, so while the
name of the format is fine, rename the define to include the _BACK
maybe?
Yes, it's a mess.
Do i use "5.1.2" alongside AV_CH_LAYOUT_5POINT1POINT2_BACK, then?
- Hendrik
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
>
> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >
> > This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> > "Channel
> > Configuration 14", and it being the first layout with top layer channels,
> > it's
> > best to use a different scheme to properly convey the presence and amount
> > of said
> > channels.
> > The new name will also be a better fit for the additions in the following
> > commits.
> >
> > Signed-off-by: James Almer
> > ---
> > diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> > index ac2ddfa022..8c40c81b44 100644
> > --- a/libavutil/channel_layout.h
> > +++ b/libavutil/channel_layout.h
> > @@ -232,13 +232,15 @@ enum AVChannelOrder {
> > #define AV_CH_LAYOUT_7POINT1
> > (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> > #define AV_CH_LAYOUT_7POINT1_WIDE
> > (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> > +#define AV_CH_LAYOUT_5POINT1POINT2
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
>
> Looking at the specs and the naming of the thing, I don't think it
> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> that, and not swap the base layer speakers.
> Looking at the specifications, they don't map properly to our speaker
> definitions, as they assign it a generic "surround" title (at 100-120
> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> and a side speaker at 90 (as is the standard for 7.1 setups).
>
> Yes, this doesn't match the one you are renaming, but I think
> consistency within our own defined formats is important here. 5.1 ->
> 5.1.2 should just add two.
>
> The renamed one could be 5.1.2(back) or whatever we want to name those.
>
> Or we do it properly and actually include a proper "surround" speaker
> definition and get rid of the confusion between side and back. But
> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> definitions are mostly sourced from, so might not be worth it.
Actually I got confused by our terrible naming. The define
AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
Regardless, rather see consistency within those as well, so while the
name of the format is fine, rename the define to include the _BACK
maybe?
- Hendrik
___
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/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
>
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount of
> said
> channels.
> The new name will also be a better fit for the additions in the following
> commits.
>
> Signed-off-by: James Almer
> ---
> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> index ac2ddfa022..8c40c81b44 100644
> --- a/libavutil/channel_layout.h
> +++ b/libavutil/channel_layout.h
> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> #define AV_CH_LAYOUT_7POINT1
> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> #define AV_CH_LAYOUT_7POINT1_WIDE
> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> +#define AV_CH_LAYOUT_5POINT1POINT2
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
Looking at the specs and the naming of the thing, I don't think it
should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
that, and not swap the base layer speakers.
Looking at the specifications, they don't map properly to our speaker
definitions, as they assign it a generic "surround" title (at 100-120
degrees azimuth), while a rear/back speaker should be at 135 degrees,
and a side speaker at 90 (as is the standard for 7.1 setups).
Yes, this doesn't match the one you are renaming, but I think
consistency within our own defined formats is important here. 5.1 ->
5.1.2 should just add two.
The renamed one could be 5.1.2(back) or whatever we want to name those.
Or we do it properly and actually include a proper "surround" speaker
definition and get rid of the confusion between side and back. But
that breaks compat with WAVEFORMATEXTENSIBLE that our channel
definitions are mostly sourced from, so might not be worth it.
- Hendrik
- Hendrik
___
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] avutil/channel_layout: add a 7.1.4 channel layout
From: Will Wolcott
Mapping to ITU-R BS.2051-3 "Sound System J" and ITU-R BS.1196-8 "Channel
Configuration 19".
Signed-off-by: Will Wolcott
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
4 files changed, 6 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index bd71fb59c4..91e648cfe5 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -721,6 +721,8 @@ FL+FR+FC+BL+BR+BC+SL+SR
FL+FR+BL+BR+TFL+TFR+TBL+TBR
@item 5.1.4
FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
+@item 7.1.4
+FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
@item downmix
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index c6107c9ff2..792d9cef35 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -204,6 +204,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "5.1.4", AV_CHANNEL_LAYOUT_5POINT1POINT4 },
+{ "7.1.4", AV_CHANNEL_LAYOUT_7POINT1POINT4 },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
{ "downmix",AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 1b0d9d0c3c..543908b267 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -236,6 +236,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_5POINT1POINT4
(AV_CH_LAYOUT_5POINT1POINT2|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
+#define AV_CH_LAYOUT_7POINT1POINT4
(AV_CH_LAYOUT_7POINT1|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
@@ -405,6 +406,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_5POINT1POINT4 AV_CHANNEL_LAYOUT_MASK(10,
AV_CH_LAYOUT_5POINT1POINT4)
+#define AV_CHANNEL_LAYOUT_7POINT1POINT4 AV_CHANNEL_LAYOUT_MASK(12,
AV_CH_LAYOUT_7POINT1POINT4)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index 194083fb71..f42bea9a0a 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -28,6 +28,7 @@ hexagonal FL+FR+FC+BL+BR+BC
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
5.1.4 FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
+7.1.4 FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
downmixDL+DR
22.2
FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL+TBC+TBR+LFE2+TSL+TSR+BFC+BFL+BFR
--
2.42.0
___
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] avutil/channel_layout: add a 5.1.4 channel layout
Mapping to ITU-R BS.2051-3 "Sound System D" and ITU-R BS.1196-8 "Channel
Configuration 16".
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
4 files changed, 6 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index 1388e5dabe..bd71fb59c4 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -719,6 +719,8 @@ FL+FR+FC+LFE+BL+BR+TFL+TFR
FL+FR+FC+BL+BR+BC+SL+SR
@item cube
FL+FR+BL+BR+TFL+TFR+TBL+TBR
+@item 5.1.4
+FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
@item downmix
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index b259e75d37..c6107c9ff2 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -203,6 +203,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "5.1.2", AV_CHANNEL_LAYOUT_5POINT1POINT2 },
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
+{ "5.1.4", AV_CHANNEL_LAYOUT_5POINT1POINT4 },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
{ "downmix",AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 8c40c81b44..1b0d9d0c3c 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -235,6 +235,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_5POINT1POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
+#define AV_CH_LAYOUT_5POINT1POINT4
(AV_CH_LAYOUT_5POINT1POINT2|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
@@ -403,6 +404,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_5POINT1POINT2 AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_5POINT1POINT2)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
+#define AV_CHANNEL_LAYOUT_5POINT1POINT4 AV_CHANNEL_LAYOUT_MASK(10,
AV_CH_LAYOUT_5POINT1POINT4)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index eece8293ad..194083fb71 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -27,6 +27,7 @@ hexagonal FL+FR+FC+BL+BR+BC
5.1.2 FL+FR+FC+LFE+BL+BR+TFL+TFR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
+5.1.4 FL+FR+FC+LFE+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
downmixDL+DR
22.2
FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL+TBC+TBR+LFE2+TSL+TSR+BFC+BFL+BFR
--
2.42.0
___
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] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
"Channel
Configuration 14", and it being the first layout with top layer channels, it's
best to use a different scheme to properly convey the presence and amount of
said
channels.
The new name will also be a better fit for the additions in the following
commits.
Signed-off-by: James Almer
---
doc/utils.texi| 2 +-
libavutil/channel_layout.c| 2 +-
libavutil/channel_layout.h| 8 ++--
tests/ref/fate/channel_layout | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 8e8bfa76d4..1388e5dabe 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -713,7 +713,7 @@ FL+FR+FC+LFE+BL+BR+SL+SR
FL+FR+FC+LFE+BL+BR+FLC+FRC
@item 7.1(wide-side)
FL+FR+FC+LFE+FLC+FRC+SL+SR
-@item 7.1(top)
+@item 5.1.2
FL+FR+FC+LFE+BL+BR+TFL+TFR
@item octagonal
FL+FR+FC+BL+BR+BC+SL+SR
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 9b581ae6b3..b259e75d37 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -200,7 +200,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.1",AV_CHANNEL_LAYOUT_7POINT1 },
{ "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
{ "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
-{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
+{ "5.1.2", AV_CHANNEL_LAYOUT_5POINT1POINT2 },
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index ac2ddfa022..8c40c81b44 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -232,13 +232,15 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1
(AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
-#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
+#define AV_CH_LAYOUT_5POINT1POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
#define AV_CH_LAYOUT_22POINT2
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER|AV_CH_BACK_CENTER|AV_CH_LOW_FREQUENCY_2|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_CENTER|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_SIDE_LEFT|AV_CH_TOP_SIDE_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_BOTTOM_FRONT_CENTER|AV_CH_BOTTOM_FRONT_LEFT|AV_CH_BOTTOM_FRONT_RIGHT)
+#define AV_CH_LAYOUT_7POINT1_TOP_BACK AV_CH_LAYOUT_5POINT1POINT2
+
enum AVMatrixEncoding {
AV_MATRIX_ENCODING_NONE,
AV_MATRIX_ENCODING_DOLBY,
@@ -398,13 +400,15 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_7POINT1 AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE_BACK)
-#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_TOP_BACK)
+#define AV_CHANNEL_LAYOUT_5POINT1POINT2 AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_5POINT1POINT2)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
#define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,
AV_CH_LAYOUT_STEREO_DOWNMIX)
#define AV_CHANNEL_LAYOUT_22POINT2 AV_CHANNEL_LAYOUT_MASK(24,
AV_CH_LAYOUT_22POINT2)
+#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_5POINT1POINT2
+
#define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
{ /* .order */ AV_CHANNEL_ORDER_AMBISONIC, \
/* .nb_channels */ 4, \
diff --git a/tests/ref/fate/channel_layout
Re: [FFmpeg-devel] [PATCH 2/6] avcodec/cbs: Do not assert on traces beyond 255 bits
On 23/10/2023 21:53, Michael Niedermayer wrote:
On Sun, Oct 22, 2023 at 03:34:20PM +0100, Mark Thompson wrote:
On 22/10/2023 01:35, Michael Niedermayer wrote:
Fixes: Assertion length < 256 failed at libavcodec/cbs.c:517
Fixes:
62673/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-6490971837431808
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index cdd7adebebd..2f5d0334a2a 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -514,6 +514,11 @@ void ff_cbs_trace_read_log(void *trace_context,
position = get_bits_count(gbc);
+if (length >= 256) {
+av_log(ctx->log_ctx, ctx->trace_level, "trace of %d bits truncated at
255\n", length);
+length = 255;
+}
+
av_assert0(length < 256);
for (i = 0; i < length; i++)
bits[i] = get_bits1(gbc) ? '1' : '0';
IMO the assert is sensible (no syntax element is that large) and so this must
be catching a bug somewhere else. Please don't nullify the assert to hide the
bug.
Can you share the input stream which hit this case?
will mail it to you
the backtrce is this:
#7 0x505748 in ff_cbs_trace_read_log ffmpeg/libavcodec/cbs.c:517:5
#8 0x5273f1 in cbs_av1_read_uvlc ffmpeg/libavcodec/cbs_av1.c:67:5
#9 0x5273f1 in cbs_av1_read_timing_info
ffmpeg/libavcodec/cbs_av1_syntax_template.c:168
#10 0x5273f1 in cbs_av1_read_sequence_header_obu
ffmpeg/libavcodec/cbs_av1_syntax_template.c:214
#11 0x51278a in cbs_av1_read_unit ffmpeg/libavcodec/cbs_av1.c:856:19
#12 0x4ff30a in cbs_read_fragment_content ffmpeg/libavcodec/cbs.c:209:15
#13 0x4ff30a in cbs_read_data ffmpeg/libavcodec/cbs.c:276
#14 0x4edc32 in trace_headers ffmpeg/libavcodec/trace_headers_bsf.c:113:11
#15 0x4c9898 in LLVMFuzzerTestOneInput
ffmpeg/tools/target_bsf_fuzzer.c:154:16
#16 0x136900d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
#17 0x135dbe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
#18 0x1362de1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
#19 0x135d8c0 in main Fuzzer/build/../FuzzerMain.cpp:20:10
#20 0x7f456b8b8c86 in __libc_start_main
/build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
#21 0x41f179 in _start
(ffmpeg/tools/target_bsf_trace_headers_fuzzer+0x41f179)
This is the case in
, and
would be fixed by that patch.
Since the problem is a dubious feature of the standard which other
implementations then do not follow I would appreciate thoughts from other
people on what to do with it, though.
Thanks,
- Mark
___
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] [REFUND-REQUEST] VDD23 Travel
On date Monday 2023-10-23 22:42:02 +0200, Michael Niedermayer wrote: > On Sat, Oct 21, 2023 at 02:10:13PM +0200, Anton Khirnov wrote: > > Hi, > > requesting refund of travel costs for VDD23: > > * PRG -> DUB: 2789 CZK ≈ 116 € > > * DUB -> PRG: 112.44 € > > * bus DUB <-> Dublin: 12 € > > total: ~240 € > > LGTM Looks good to me. To get the refund, follow instructions here to generate a refund request: https://www.spi-inc.org/treasurer/reimbursement-form/ Note that the XE calculator referenced in the linked page above is still broken, so you should probably send the receipts as attachments to the request email. Then email the request to: treasu...@rt.spi-inc.org putting me and Michael in CC:, and adding the thread link from: http://ffmpeg.org/pipermail/ffmpeg-devel/ Thanks. ___ 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] [REFUND-REQUEST] Travel & Accomodation for LDP 23
On date Saturday 2023-10-21 11:39:02 +0200, ffmpeg-devel Mailing List wrote: > Hi, > > I went to Prag for the LinuxDays Prague 23 [1] by Bus and stayed at the > university Dorm/Hotel. > > Bus:54,98 EUR > Hotel: 154,08 EUR (converted from CZK by VISA) > = > Total: 209,06 EUR Looks good to me, pending Michael's approval. To get the refund, follow instructions here to generate a refund request: https://www.spi-inc.org/treasurer/reimbursement-form/ Note that the XE calculator referenced in the linked page above is still broken, so you should probably send the receipts as attachments to the request email. Then email it to: treasu...@rt.spi-inc.org putting me and Michael in CC:, and adding the thread link from: http://ffmpeg.org/pipermail/ffmpeg-devel/ Thanks. ___ 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 2/6] avcodec/cbs: Do not assert on traces beyond 255 bits
On Sun, Oct 22, 2023 at 03:34:20PM +0100, Mark Thompson wrote:
> On 22/10/2023 01:35, Michael Niedermayer wrote:
> > Fixes: Assertion length < 256 failed at libavcodec/cbs.c:517
> > Fixes:
> > 62673/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-6490971837431808
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/cbs.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> > index cdd7adebebd..2f5d0334a2a 100644
> > --- a/libavcodec/cbs.c
> > +++ b/libavcodec/cbs.c
> > @@ -514,6 +514,11 @@ void ff_cbs_trace_read_log(void *trace_context,
> > position = get_bits_count(gbc);
> > +if (length >= 256) {
> > +av_log(ctx->log_ctx, ctx->trace_level, "trace of %d bits truncated
> > at 255\n", length);
> > +length = 255;
> > +}
> > +
> > av_assert0(length < 256);
> > for (i = 0; i < length; i++)
> > bits[i] = get_bits1(gbc) ? '1' : '0';
>
> IMO the assert is sensible (no syntax element is that large) and so this must
> be catching a bug somewhere else. Please don't nullify the assert to hide
> the bug.
>
> Can you share the input stream which hit this case?
will mail it to you
the backtrce is this:
#7 0x505748 in ff_cbs_trace_read_log ffmpeg/libavcodec/cbs.c:517:5
#8 0x5273f1 in cbs_av1_read_uvlc ffmpeg/libavcodec/cbs_av1.c:67:5
#9 0x5273f1 in cbs_av1_read_timing_info
ffmpeg/libavcodec/cbs_av1_syntax_template.c:168
#10 0x5273f1 in cbs_av1_read_sequence_header_obu
ffmpeg/libavcodec/cbs_av1_syntax_template.c:214
#11 0x51278a in cbs_av1_read_unit ffmpeg/libavcodec/cbs_av1.c:856:19
#12 0x4ff30a in cbs_read_fragment_content ffmpeg/libavcodec/cbs.c:209:15
#13 0x4ff30a in cbs_read_data ffmpeg/libavcodec/cbs.c:276
#14 0x4edc32 in trace_headers ffmpeg/libavcodec/trace_headers_bsf.c:113:11
#15 0x4c9898 in LLVMFuzzerTestOneInput
ffmpeg/tools/target_bsf_fuzzer.c:154:16
#16 0x136900d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
#17 0x135dbe2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
#18 0x1362de1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
#19 0x135d8c0 in main Fuzzer/build/../FuzzerMain.cpp:20:10
#20 0x7f456b8b8c86 in __libc_start_main
/build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
#21 0x41f179 in _start
(ffmpeg/tools/target_bsf_trace_headers_fuzzer+0x41f179)
[...]
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.
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 5/6] avutil/tx_template: fix integer ovberflwo in fft3()
On Sun, Oct 22, 2023 at 03:55:47AM +0200, Lynne wrote: > Oct 22, 2023, 02:36 by mich...@niedermayer.cc: > > > Fixes: signed integer overflow: -1028966111 + -1314089526 cannot be > > represented in type 'int' > > Fixes: > > 63174/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5853273711837184 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavutil/tx_template.c | 7 --- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/libavutil/tx_template.c b/libavutil/tx_template.c > > index 8dc3d2519c1..a2c27465cbc 100644 > > --- a/libavutil/tx_template.c > > +++ b/libavutil/tx_template.c > > @@ -185,10 +185,9 @@ static av_always_inline void fft3(TXComplex *out, > > TXComplex *in, > > BF(tmp[1].re, tmp[2].im, in[1].im, in[2].im); > > BF(tmp[1].im, tmp[2].re, in[1].re, in[2].re); > > > > -out[0*stride].re = tmp[0].re + tmp[2].re; > > -out[0*stride].im = tmp[0].im + tmp[2].im; > > - > > #ifdef TX_INT32 > > +out[0*stride].re = (int64_t)tmp[0].re + tmp[2].re; > > +out[0*stride].im = (int64_t)tmp[0].im + tmp[2].im; > > mtmp[0] = (int64_t)tab[ 8] * tmp[1].re; > > mtmp[1] = (int64_t)tab[ 9] * tmp[1].im; > > mtmp[2] = (int64_t)tab[10] * tmp[2].re; > > @@ -198,6 +197,8 @@ static av_always_inline void fft3(TXComplex *out, > > TXComplex *in, > > out[2*stride].re = tmp[0].re - (mtmp[2] - mtmp[0] + 0x4000 >> 31); > > out[2*stride].im = tmp[0].im - (mtmp[3] + mtmp[1] + 0x4000 >> 31); > > #else > > +out[0*stride].re = tmp[0].re + tmp[2].re; > > +out[0*stride].im = tmp[0].im + tmp[2].im; > > tmp[1].re = tab[ 8] * tmp[1].re; > > tmp[1].im = tab[ 9] * tmp[1].im; > > tmp[2].re = tab[10] * tmp[2].re; > > > > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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] [REFUND-REQUEST] VDD23 Travel
On Sat, Oct 21, 2023 at 02:10:13PM +0200, Anton Khirnov wrote: > Hi, > requesting refund of travel costs for VDD23: > * PRG -> DUB: 2789 CZK ≈ 116 € > * DUB -> PRG: 112.44 € > * bus DUB <-> Dublin: 12 € > total: ~240 € LGTM 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. 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] [REFUND-REQUEST] Travel & Accomodation for LDP 23
On Sat, Oct 21, 2023 at 11:39:02AM +0200, Thilo Borgmann via ffmpeg-devel wrote: > Hi, > > I went to Prag for the LinuxDays Prague 23 [1] by Bus and stayed at the > university Dorm/Hotel. > > Bus:54,98 EUR > Hotel: 154,08 EUR (converted from CZK by VISA) > = > Total: 209,06 EUR LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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".
[FFmpeg-devel] [PATCH 2/2] avutil/mem: add av_dynarray2_add_nofree
Signed-off-by: James Almer
---
libavutil/mem.c | 17 +
libavutil/mem.h | 32 +---
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..bd37710968 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -356,6 +356,23 @@ void *av_dynarray2_add(void **tab_ptr, int *nb_ptr, size_t
elem_size,
return tab_elem_data;
}
+void *av_dynarray2_add_nofree(void **tab_ptr, int *nb_ptr, size_t elem_size,
+ const uint8_t *elem_data)
+{
+uint8_t *tab_elem_data = NULL;
+
+FF_DYNARRAY_ADD(INT_MAX, elem_size, *tab_ptr, *nb_ptr, {
+tab_elem_data = (uint8_t *)*tab_ptr + (*nb_ptr) * elem_size;
+if (elem_data)
+memcpy(tab_elem_data, elem_data, elem_size);
+else if (CONFIG_MEMORY_POISONING)
+memset(tab_elem_data, FF_MEMORY_POISON, elem_size);
+}, {
+return NULL;
+});
+return tab_elem_data;
+}
+
static void fill16(uint8_t *dst, int len)
{
uint32_t v = AV_RN16(dst - 2);
diff --git a/libavutil/mem.h b/libavutil/mem.h
index ab7648ac57..c0161be243 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -519,7 +519,7 @@ void av_memcpy_backptr(uint8_t *dst, int back, int cnt);
* @param[in,out] tab_ptr Pointer to the array to grow
* @param[in,out] nb_ptr Pointer to the number of elements in the array
* @param[in] elemElement to add
- * @see av_dynarray_add_nofree(), av_dynarray2_add()
+ * @see av_dynarray_add_nofree(), av_dynarray2_add(), av_dynarray2_add_nofree()
*/
void av_dynarray_add(void *tab_ptr, int *nb_ptr, void *elem);
@@ -531,7 +531,7 @@ void av_dynarray_add(void *tab_ptr, int *nb_ptr, void
*elem);
* instead and leave current buffer untouched.
*
* @return >=0 on success, negative otherwise
- * @see av_dynarray_add(), av_dynarray2_add()
+ * @see av_dynarray_add(), av_dynarray2_add(), av_dynarray2_add_nofree()
*/
av_warn_unused_result
int av_dynarray_add_nofree(void *tab_ptr, int *nb_ptr, void *elem);
@@ -557,11 +557,37 @@ int av_dynarray_add_nofree(void *tab_ptr, int *nb_ptr,
void *elem);
*
* @return Pointer to the data of the element to copy in the newly allocated
* space
- * @see av_dynarray_add(), av_dynarray_add_nofree()
+ * @see av_dynarray2_add_nofree(), av_dynarray_add(), av_dynarray_add_nofree()
*/
void *av_dynarray2_add(void **tab_ptr, int *nb_ptr, size_t elem_size,
const uint8_t *elem_data);
+/**
+ * Add an element of size `elem_size` to a dynamic array.
+ *
+ * The array is reallocated when its number of elements reaches powers of 2.
+ * Therefore, the amortized cost of adding an element is constant.
+ *
+ * In case of success, the pointer to the array is updated in order to
+ * point to the new grown array, and the number pointed to by `nb_ptr`
+ * is incremented.
+ * In case of failure, the array and `nb_ptr` are left untouched, and NULL
+ * is returned.
+ *
+ * @param[in,out] tab_ptr Pointer to the array to grow
+ * @param[in,out] nb_ptrPointer to the number of elements in the array
+ * @param[in] elem_size Size in bytes of an element in the array
+ * @param[in] elem_data Pointer to the data of the element to add. If
+ * `NULL`, the space of the newly added element is
+ * allocated but left uninitialized.
+ *
+ * @return Pointer to the data of the element to copy in the newly allocated
+ * space on success, NULL otherwise.
+ * @see av_dynarray2_add(), av_dynarray_add(), av_dynarray_add_nofree()
+ */
+void *av_dynarray2_add_nofree(void **tab_ptr, int *nb_ptr, size_t elem_size,
+ const uint8_t *elem_data);
+
/**
* @}
*/
--
2.42.0
___
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 2/3] avcodec/rv60: RealVideo 6.0 decoder
On Mon, Oct 23, 2023 at 12:14:52PM +0200, Anton Khirnov wrote:
> Quoting Peter Ross (2023-10-22 01:31:32)
> > On Wed, Oct 18, 2023 at 04:42:01PM +0200, Anton Khirnov wrote:
> > > Quoting Peter Ross (2023-10-18 10:03:54)
> > [..]
> > > I think you can simplify this into:
> > > if (s->last_frame[NEXT_PIC]->data[0]) {
> > > av_frame_move_ref(frame, s->last_frame[NEXT_PIC]);
> > > *got_frame = 1;
> > > }
> > [..]
> > > You just unreffed the frame above, what is the point of using
> > > reget_buffer()?
> > [..]
> > > The generic code should be doing this already.
> > [..]
> > > You could change this into av_frame_move_ref() and drop the unref below.
> >
> > many thanks anton for these suggestions. i agree with all of them.
> >
> > > > +if (s->pict_type != AV_PICTURE_TYPE_B) {
> > > > +s->ref_pts[0] = s->ref_pts[1];
> > > > +s->ref_pts[1] = avpkt->pts;
> > > > +
> > > > +s->ref_ts[0] = s->ref_ts[1];
> > > > +s->ref_ts[1] = s->ts;
> > > > +
> > > > +if (s->ref_pts[1] > s->ref_pts[0] && s->ref_ts[1] >
> > > > s->ref_ts[0])
> > > > +s->ts_scale = (s->ref_pts[1] - s->ref_pts[0]) /
> > > > (s->ref_ts[1] - s->ref_ts[0]);
> > > > +} else {
> > > > +frame->pts = s->ref_pts[0] + (s->ts - s->ref_ts[0]) *
> > > > s->ts_scale;
> > >
> > > This looks immensely evil. Isn't ff_get_buffer() already setting the
> > > timestamps correctly?
> >
> > no ff_reget_buffer() does not set pts correctly.
> > the ref_ts ('s->ts') value is sent with every rv60 in the header, and is
> > used to calculate the pts value. unsure how to make this less evil.
>
> Typically the timestamps come from the container, so the decoder merely
> copies them from packet to frame. Does the container not provide valid
> timestamps here?
the container (rm) does not provide meaningful pts, even though there
b-frames are present in the stream.
should this fixup be done in a bitstream filter?
rv30/rv40 also uses rm container and suffers this problem.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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 1/9] avcodec/vlc: merge lost 16bit end of array check
On Mon, Oct 23, 2023 at 01:02:16AM +0200, Paul B Mahol wrote: [...] > Make sure you do not break >8 bit support in utvideo and magicyuv decoders. Make sure the fate tests cover these cases thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
On Mon, Oct 23, 2023 at 02:10:35AM -0400, Leo Izen wrote: > On 10/22/23 17:51, Michael Niedermayer wrote: > > This makes the code more testable as uninitialized fields are 0 > > and not random values from the last call > > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/vlc.c | 14 +++--- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c > > index 9b7a42f79a3..4adec2da705 100644 > > --- a/libavcodec/vlc.c > > +++ b/libavcodec/vlc.c > > @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const int > > is16bit, > > uint32_t curcode, int curlen, > > int curlimit, int curlevel, > > const int minlen, const int max, > > - unsigned* levelcnt, VLC_MULTI_ELEM *info) > > + unsigned* levelcnt, VLC_MULTI_ELEM info) > > > Is passing a struct by value advisable? Did you benchmark this? How does it > compare to memset(info, 0, sizeof(*info))? The struct is 8 bytes, a pointer on 64bit arch is also 8byte I did not benchmark, I think this code doesnt run that many iterations (when its not buggy), I mean each iteration adds a entry to the table and the table will normally be designed to fit in cache and its only for initializing. do you still want me to bechmark this ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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/cbs_h266: fix SPS VUI extension data leak
Nuo Mi:
> On Mon, Oct 23, 2023 at 7:46 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Nuo Mi:
>>> On Sun, Oct 22, 2023 at 8:58 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Nuo Mi:
> Fixes: VUI extension leak
> Fixes:
>> 63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408
>
> Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> ---
> libavcodec/cbs_h2645.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 470f60b95f..ef631a11fe 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -1979,6 +1979,13 @@ static const CodedBitstreamUnitTypeDescriptor
cbs_h265_unit_types[] = {
> CBS_UNIT_TYPE_END_OF_LIST
> };
>
> +static void cbs_h266_free_sps(FFRefStructOpaque unused, void *content)
> +{
> +H266RawSPS *sps = (H266RawSPS*)content;
> +av_buffer_unref(>extension_data.data_ref);
> +av_buffer_unref(>vui.extension_data.data_ref);
> +}
> +
> static void cbs_h266_free_sei(FFRefStructOpaque unused, void *content)
> {
> H266RawSEI *sei = content;
> @@ -1989,7 +1996,6 @@ static const CodedBitstreamUnitTypeDescriptor
cbs_h266_unit_types[] = {
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI,
extension_data.data),
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI,
extension_data.data),
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS,
extension_data.data),
> -CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS,
extension_data.data),
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS,
extension_data.data),
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
extension_data.data),
> CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
extension_data.data),
> @@ -2003,6 +2009,8 @@ static const CodedBitstreamUnitTypeDescriptor
cbs_h266_unit_types[] = {
> CBS_UNIT_RANGE_INTERNAL_REF(VVC_IDR_W_RADL, VVC_GDR_NUT,
> H266RawSlice, data),
>
> +CBS_UNIT_TYPE_COMPLEX(VVC_SPS_NUT, H266RawSPS, cbs_h266_free_sps),
> +
> CBS_UNIT_TYPES_COMPLEX((VVC_PREFIX_SEI_NUT, VVC_SUFFIX_SEI_NUT),
> H266RawSEI, cbs_h266_free_sei),
>
This should be a CBS_UNIT_TYPE_INTERNAL_REF().
>>> Hi Andreas,
>>> Thank you for the review.
>>>
>>> Do you mean the SEI?
>>>
>>
>> No, I mean the SPS. (If you want to, I can send a patch for this leak.)
>>
> Sure, please go ahead.
>
> Thank you
>
Sent a patch. Rereading this I came to realize that my advice was not
helpful, given that VVC_SPS_NUT already uses CBS_UNIT_TYPE_INTERNAL_REF.
The solution is to use CBS_CONTENT_TYPE_INTERNAL_REFS, but with two
internal refs. There is no macro for this atm (and the only other unit
with two internal refs uses CBS_UNIT_TYPE_RANGE, so one can't simply use
a common macro for them).
- 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] avcodec/cbs_h2645: Fix leak of SPS VUI extension data
Fixes: VUI extension leak
Fixes:
63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 470f60b95f..c48a06b241 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1989,7 +1989,17 @@ static const CodedBitstreamUnitTypeDescriptor
cbs_h266_unit_types[] = {
CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS, extension_data.data),
-CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS, extension_data.data),
+{
+.nb_unit_types = 1,
+.unit_type.list[0] = VVC_SPS_NUT,
+.content_type = CBS_CONTENT_TYPE_INTERNAL_REFS,
+.content_size = sizeof(H266RawSPS),
+.type.ref = {
+.nb_offsets = 2,
+.offsets= { offsetof(H266RawSPS, extension_data.data),
+offsetof(H266RawSPS, vui.extension_data.data) }
+},
+},
CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
extension_data.data),
--
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] avcodec/cbs_h266: fix SPS VUI extension data leak
On Mon, Oct 23, 2023 at 7:46 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nuo Mi:
> > On Sun, Oct 22, 2023 at 8:58 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Nuo Mi:
> >>> Fixes: VUI extension leak
> >>> Fixes:
> >>
> 63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408
> >>>
> >>> Found-by: continuous fuzzing process
> >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> ---
> >>> libavcodec/cbs_h2645.c | 10 +-
> >>> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> >>> index 470f60b95f..ef631a11fe 100644
> >>> --- a/libavcodec/cbs_h2645.c
> >>> +++ b/libavcodec/cbs_h2645.c
> >>> @@ -1979,6 +1979,13 @@ static const CodedBitstreamUnitTypeDescriptor
> >> cbs_h265_unit_types[] = {
> >>> CBS_UNIT_TYPE_END_OF_LIST
> >>> };
> >>>
> >>> +static void cbs_h266_free_sps(FFRefStructOpaque unused, void *content)
> >>> +{
> >>> +H266RawSPS *sps = (H266RawSPS*)content;
> >>> +av_buffer_unref(>extension_data.data_ref);
> >>> +av_buffer_unref(>vui.extension_data.data_ref);
> >>> +}
> >>> +
> >>> static void cbs_h266_free_sei(FFRefStructOpaque unused, void *content)
> >>> {
> >>> H266RawSEI *sei = content;
> >>> @@ -1989,7 +1996,6 @@ static const CodedBitstreamUnitTypeDescriptor
> >> cbs_h266_unit_types[] = {
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI,
> >> extension_data.data),
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI,
> >> extension_data.data),
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS,
> >> extension_data.data),
> >>> -CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS,
> >> extension_data.data),
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS,
> >> extension_data.data),
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
> >> extension_data.data),
> >>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
> >> extension_data.data),
> >>> @@ -2003,6 +2009,8 @@ static const CodedBitstreamUnitTypeDescriptor
> >> cbs_h266_unit_types[] = {
> >>> CBS_UNIT_RANGE_INTERNAL_REF(VVC_IDR_W_RADL, VVC_GDR_NUT,
> >>> H266RawSlice, data),
> >>>
> >>> +CBS_UNIT_TYPE_COMPLEX(VVC_SPS_NUT, H266RawSPS, cbs_h266_free_sps),
> >>> +
> >>> CBS_UNIT_TYPES_COMPLEX((VVC_PREFIX_SEI_NUT, VVC_SUFFIX_SEI_NUT),
> >>> H266RawSEI, cbs_h266_free_sei),
> >>>
> >>
> >> This should be a CBS_UNIT_TYPE_INTERNAL_REF().
> >>
> > Hi Andreas,
> > Thank you for the review.
> >
> > Do you mean the SEI?
> >
>
> No, I mean the SPS. (If you want to, I can send a patch for this leak.)
>
Sure, please go ahead.
Thank you
>
> - 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 v2] avformat: introduce AVStreamGroup
Signed-off-by: James Almer
---
Changes since the first version:
- The union will now hold pointers to Group type specific structs
- The array of elements in the group is now of pointers to the streams
rather than index values.
- Simplified the helpers
- Changed field type for idx and id
- Added an AVDictionary to hold metadata
libavformat/avformat.c | 30 +
libavformat/avformat.h | 138 +
libavformat/internal.h | 33 ++
libavformat/options.c | 62 ++
4 files changed, 263 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 5b8bb7879e..99cda56c2f 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -80,6 +80,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_freep(pst);
}
+void ff_free_stream_group(AVStreamGroup **pstg)
+{
+AVStreamGroup *stg = *pstg;
+
+if (!stg)
+return;
+
+av_freep(>streams);
+av_freep(>priv_data);
+switch (stg->type) {
+// Structs in the union are freed here
+default:
+break;
+}
+
+av_freep(pstg);
+}
+
void ff_remove_stream(AVFormatContext *s, AVStream *st)
{
av_assert0(s->nb_streams>0);
@@ -88,6 +106,14 @@ void ff_remove_stream(AVFormatContext *s, AVStream *st)
ff_free_stream(>streams[ --s->nb_streams ]);
}
+void ff_remove_stream_group(AVFormatContext *s, AVStreamGroup *stg)
+{
+av_assert0(s->nb_stream_groups > 0);
+av_assert0(s->stream_groups[ s->nb_stream_groups - 1 ] == stg);
+
+ff_free_stream_group(>stream_groups[ --s->nb_stream_groups ]);
+}
+
/* XXX: suppress the packet queue */
void ff_flush_packet_queue(AVFormatContext *s)
{
@@ -118,6 +144,9 @@ void avformat_free_context(AVFormatContext *s)
for (unsigned i = 0; i < s->nb_streams; i++)
ff_free_stream(>streams[i]);
+for (unsigned i = 0; i < s->nb_stream_groups; i++)
+ff_free_stream_group(>stream_groups[i]);
+s->nb_stream_groups = 0;
s->nb_streams = 0;
for (unsigned i = 0; i < s->nb_programs; i++) {
@@ -138,6 +167,7 @@ void avformat_free_context(AVFormatContext *s)
av_dict_free(>id3v2_meta);
av_packet_free(>pkt);
av_packet_free(>parse_pkt);
+av_freep(>stream_groups);
av_freep(>streams);
ff_flush_packet_queue(s);
av_freep(>url);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9e7eca007e..f045084c8d 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,6 +1018,77 @@ typedef struct AVStream {
int pts_wrap_bits;
} AVStream;
+enum AVStreamGroupParamsType {
+AV_STREAM_GROUP_PARAMS_NONE,
+};
+
+typedef struct AVStreamGroup {
+/**
+ * A class for @ref avoptions. Set on group creation.
+ */
+const AVClass *av_class;
+
+void *priv_data;
+
+/**
+ * Group index in AVFormatContext.
+ */
+unsigned int index;
+
+/**
+ * Group-specific group ID.
+ *
+ * decoding: set by libavformat
+ * encoding: set by the user, replaced by libavformat if left unset
+ */
+int64_t id;
+
+/**
+ * Group-specific type
+ *
+ * decoding: set by libavformat on group creation
+ * encoding: set by the user on group creation
+ */
+enum AVStreamGroupParamsType type;
+
+/**
+ * Group-specific type parameters
+ */
+union {
+uintptr_t dummy; // Placeholder
+} params;
+
+/**
+ * Metadata that applies to the whole file.
+ *
+ * - demuxing: set by libavformat in avformat_open_input()
+ * - muxing: may be set by the caller before avformat_write_header()
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+AVDictionary *metadata;
+
+/**
+ * Number of elements in AVStreamGroup.streams.
+ *
+ * Set by avformat_stream_group_add_stream() must not be modified by any
other code.
+ */
+unsigned int nb_streams;
+
+/**
+ * A list of streams in the group. New entries are created with
+ * avformat_stream_group_add_stream().
+ *
+ * - demuxing: entries are created by libavformat in avformat_open_input().
+ * If AVFMTCTX_NOHEADER is set in ctx_flags, then new entries
may also
+ * appear in av_read_frame().
+ * - muxing: entries are created by the user before
avformat_write_header().
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+const AVStream **streams;
+} AVStreamGroup;
+
struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
#if FF_API_GET_END_PTS
@@ -1726,6 +1797,26 @@ typedef struct AVFormatContext {
* @return 0 on success, a negative AVERROR code on failure
*/
int (*io_close2)(struct AVFormatContext *s, AVIOContext *pb);
+
+/**
+ * Number of elements in AVFormatContext.stream_groups.
+ *
+ * Set by avformat_stream_group_create(), must not be modified by any
other code.
+ */
+unsigned int nb_stream_groups;
+
+/**
+ *
[FFmpeg-devel] [PATCH avcodec/amfenc: 10-bit support, v5, 3/3] avcodec/amfenc: add 10 bit encoding in av1_amf
v2: refactored after review
Signed-off-by: Evgeny Pavlov
Co-authored-by: Dmitrii Ovchinnikov
---
libavcodec/amfenc.c | 2 ++
libavcodec/amfenc_av1.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 068bb53002..f1b76bd6aa 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -826,6 +826,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
case AV_CODEC_ID_HEVC:
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_AV1:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA, hdrmeta_buffer); break;
}
hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
}
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 8f13aea29e..634eeea48f 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -165,6 +165,9 @@ static av_cold int amf_encode_init_av1(AVCodecContext*
avctx)
AMFGuid guid;
AMFRate framerate;
AMFSize framesize = AMFConstructSize(avctx->width,
avctx->height);
+amf_int64 color_depth;
+amf_int64 color_profile;
+enumAVPixelFormat pix_fmt;
@@ -203,6 +206,25 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_PROFILE, profile);
+/// Color profile
+color_profile = ff_amf_get_color_profile(avctx);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+
+/// Color Depth
+pix_fmt = avctx->hw_frames_ctx ?
((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
+: avctx->pix_fmt;
+color_depth = AMF_COLOR_BIT_DEPTH_8;
+if (pix_fmt == AV_PIX_FMT_P010) {
+color_depth = AMF_COLOR_BIT_DEPTH_10;
+}
+
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_COLOR_BIT_DEPTH, color_depth);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
+
profile_level = avctx->level;
if (profile_level == AV_LEVEL_UNKNOWN) {
profile_level = ctx->level;
--
2.41.0
___
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/amfenc: 10-bit support, v5, 2/3] avcodec/amfenc: HDR metadata.
From: nyanmisaka
v2: fixes for indentation
---
libavcodec/amfenc.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0bd15dd812..068bb53002 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -36,6 +36,57 @@
#include "amfenc.h"
#include "encode.h"
#include "internal.h"
+#include "libavutil/mastering_display_metadata.h"
+
+static int amf_save_hdr_metadata(AVCodecContext *avctx, const AVFrame *frame,
AMFHDRMetadata *hdrmeta)
+{
+AVFrameSideData*sd_display;
+AVFrameSideData*sd_light;
+AVMasteringDisplayMetadata *display_meta;
+AVContentLightMetadata *light_meta;
+
+sd_display = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (sd_display) {
+display_meta = (AVMasteringDisplayMetadata *)sd_display->data;
+if (display_meta->has_luminance) {
+const unsigned int luma_den = 1;
+hdrmeta->maxMasteringLuminance =
+(amf_uint32)(luma_den * av_q2d(display_meta->max_luminance));
+hdrmeta->minMasteringLuminance =
+FFMIN((amf_uint32)(luma_den *
av_q2d(display_meta->min_luminance)), hdrmeta->maxMasteringLuminance);
+}
+if (display_meta->has_primaries) {
+const unsigned int chroma_den = 5;
+hdrmeta->redPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][0])), chroma_den);
+hdrmeta->redPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][1])), chroma_den);
+hdrmeta->greenPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][0])), chroma_den);
+hdrmeta->greenPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][1])), chroma_den);
+hdrmeta->bluePrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][0])), chroma_den);
+hdrmeta->bluePrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][1])), chroma_den);
+hdrmeta->whitePoint[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[0])), chroma_den);
+hdrmeta->whitePoint[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[1])), chroma_den);
+}
+
+sd_light = av_frame_get_side_data(frame,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (sd_light) {
+light_meta = (AVContentLightMetadata *)sd_light->data;
+if (light_meta) {
+hdrmeta->maxContentLightLevel = (amf_uint16)light_meta->MaxCLL;
+hdrmeta->maxFrameAverageLightLevel =
(amf_uint16)light_meta->MaxFALL;
+}
+}
+return 0;
+}
+return 1;
+}
#if CONFIG_D3D11VA
#include
@@ -683,6 +734,26 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
}
+// HDR10 metadata
+if (frame->color_trc == AVCOL_TRC_SMPTE2084) {
+AMFBuffer * hdrmeta_buffer = NULL;
+res = ctx->context->pVtbl->AllocBuffer(ctx->context,
AMF_MEMORY_HOST, sizeof(AMFHDRMetadata), _buffer);
+if (res == AMF_OK) {
+AMFHDRMetadata * hdrmeta =
(AMFHDRMetadata*)hdrmeta_buffer->pVtbl->GetNative(hdrmeta_buffer);
+if (amf_save_hdr_metadata(avctx, frame, hdrmeta) == 0) {
+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_HEVC:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+}
+res = amf_set_property_buffer(surface,
L"av_frame_hdrmeta", hdrmeta_buffer);
+AMF_RETURN_IF_FALSE(avctx, res == AMF_OK, AVERROR_UNKNOWN,
"SetProperty failed for \"av_frame_hdrmeta\" with error %d\n", res);
+}
+hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
+}
+}
+
surface->pVtbl->SetPts(surface, frame->pts);
AMF_ASSIGN_PROPERTY_INT64(res, surface, PTS_PROP, frame->pts);
@@ -746,6 +817,18 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
}
res_resubmit = AMF_OK;
if (ctx->delayed_surface != NULL) { // try to resubmit frame
+if (ctx->delayed_surface->pVtbl->HasProperty(ctx->delayed_surface,
L"av_frame_hdrmeta")) {
+AMFBuffer *
[FFmpeg-devel] [PATCH avcodec/amfenc: 10-bit support, v5, 1/3] avcodec/amfenc: Fixes the color information in the output.
From: Michael Fabian 'Xaymar' Dirks
added 10 bit support for amf hevc.
before:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output - Format of input frames context (p010le) is not supported by AMF.
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - Format of input frames context (p010le) is not supported by AMF.
after:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
output - 10-bit input video is not supported by AMF H264 encoder
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - 10bit file
v2 - lost line returned in ff_amf_pix_fmts
v3 - fixes after review
v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
v5 - non-functional changes after review
Co-authored-by: Evgeny Pavlov
---
libavcodec/amfenc.c | 37 +
libavcodec/amfenc.h | 3 +++
libavcodec/amfenc_h264.c | 24
libavcodec/amfenc_hevc.c | 26 +-
4 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..0bd15dd812 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
#if CONFIG_DXVA2
AV_PIX_FMT_DXVA2_VLD,
#endif
+AV_PIX_FMT_P010,
AV_PIX_FMT_NONE
};
@@ -72,6 +73,7 @@ static const FormatMap format_map[] =
{
{ AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
{ AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
{ AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
{ AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
@@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
return ret;
}
+int ff_amf_get_color_profile(AVCodecContext *avctx)
+{
+amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
+if (avctx->color_range == AVCOL_RANGE_JPEG) {
+/// Color Space for Full (JPEG) Range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
+break;
+}
+} else {
+/// Color Space for Limited (MPEG) range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_2020;
+break;
+}
+}
+return color_profile;
+}
+
const AVCodecHWConfigInternal *const ff_amfenc_hw_configs[] = {
#if CONFIG_D3D11VA
HW_CONFIG_ENCODER_FRAMES(D3D11, D3D11VA),
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..62736ef579 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -21,6 +21,7 @@
#include
+#include
#include
#include
#include
@@ -170,6 +171,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt);
*/
extern const enum AVPixelFormat ff_amf_pix_fmts[];
+int ff_amf_get_color_profile(AVCodecContext *avctx);
+
/**
* Error handling helper
*/
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index bd544d12df..f785e091c9 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -199,6 +199,8 @@ static av_cold int amf_encode_init_h264(AVCodecContext
*avctx)
AMFRate framerate;
AMFSize framesize =
AMFConstructSize(avctx->width, avctx->height);
int deblocking_filter = (avctx->flags &
AV_CODEC_FLAG_LOOP_FILTER) ? 1 : 0;
+amf_int64color_profile;
+enum AVPixelFormat pix_fmt;
if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
framerate = AMFConstructRate(avctx->framerate.num,
avctx->framerate.den);
@@ -262,10 +264,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_RATIO(res, ctx->encoder,
AMF_VIDEO_ENCODER_ASPECT_RATIO, ratio);
}
-/// Color Range (Partial/TV/MPEG or Full/PC/JPEG)
-
Re: [FFmpeg-devel] [PATCH] libavcodec/amfenc: Add more pixel formats support
On Sun, Oct 22, 2023 at 5:01 PM Mark Thompson wrote:
> On 20/10/2023 09:13, Evgeny Pavlov wrote:
> > On Tue, Jul 18, 2023 at 10:32 AM Evgeny Pavlov
> wrote:
> >
> >> This commit adds BGRA, RGBA and ARGB pixel formats for AMF encoders
> >>
> >> Signed-off-by: Evgeny Pavlov
> >> ---
> >> libavcodec/amfenc.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> >> index cb48f8c273..234cd012ef 100644
> >> --- a/libavcodec/amfenc.c
> >> +++ b/libavcodec/amfenc.c
> >> @@ -74,6 +74,9 @@ static const FormatMap format_map[] =
> >> { AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
> >> { AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
> >> { AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
> >> +{ AV_PIX_FMT_BGRA, AMF_SURFACE_BGRA },
> >> +{ AV_PIX_FMT_RGBA, AMF_SURFACE_RGBA },
> >> +{ AV_PIX_FMT_ARGB, AMF_SURFACE_ARGB },
> >> { AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
> >> { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
> >> { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
> >> --
> >> 2.37.3.windows.1
> >>
> >> The purpose of this patch is to fix an issue with feeding ddagrab output
> > to AMF directly. The output of ddagrab might be BGRA, AMF supports this
> > input, but failed to encode due to missing mapping from AV_PIX_BGRA to
> > AMF_SURFACE_BGRA in amfenc.c
> > DXGI isn't firm to distinguish between RGBA & RGBX, so it is safer to
> > support both to avoid failures like with ddagrab.
>
> See patch just sent to fix the bug in ddagrab that it incorrectly
> advertises an alpha channel.
>
> Do you have ddagrab->amfenc working with just something to fix the alpha
> channel? To make it work I also need to mess with the bind flags because
> amfenc wants to use the textures as shader resources.
>
> This has been noted as a problem before, where a proper fix would require
> large changes in the format negotiation setup and so it hasn't been done.
> I'm wondering whether adding "-bind_flags shader_resource" option to
> ddagrab would be a plausible hack for these cases, or whether that's a bit
> too obscure for an actual user?
>
> Thanks,
>
> - Mark
> ___
> 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".>
>
>
Yes, I have ddagrab->amfenc working with just fixing alpha channel, but AMF
encoders sometimes use shader, sometimes VCN for color conversion - it
depends on HW capabilities. I would suggest to always set bind in ddgrab to
D3D11_BIND_SHADER_RESOURCE, because this is no reason not to do it.
Thanks,
Evgeny
___
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/cbs_h266: fix SPS VUI extension data leak
Nuo Mi:
> On Sun, Oct 22, 2023 at 8:58 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Nuo Mi:
>>> Fixes: VUI extension leak
>>> Fixes:
>> 63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408
>>>
>>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> ---
>>> libavcodec/cbs_h2645.c | 10 +-
>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>>> index 470f60b95f..ef631a11fe 100644
>>> --- a/libavcodec/cbs_h2645.c
>>> +++ b/libavcodec/cbs_h2645.c
>>> @@ -1979,6 +1979,13 @@ static const CodedBitstreamUnitTypeDescriptor
>> cbs_h265_unit_types[] = {
>>> CBS_UNIT_TYPE_END_OF_LIST
>>> };
>>>
>>> +static void cbs_h266_free_sps(FFRefStructOpaque unused, void *content)
>>> +{
>>> +H266RawSPS *sps = (H266RawSPS*)content;
>>> +av_buffer_unref(>extension_data.data_ref);
>>> +av_buffer_unref(>vui.extension_data.data_ref);
>>> +}
>>> +
>>> static void cbs_h266_free_sei(FFRefStructOpaque unused, void *content)
>>> {
>>> H266RawSEI *sei = content;
>>> @@ -1989,7 +1996,6 @@ static const CodedBitstreamUnitTypeDescriptor
>> cbs_h266_unit_types[] = {
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI,
>> extension_data.data),
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI,
>> extension_data.data),
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS,
>> extension_data.data),
>>> -CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS,
>> extension_data.data),
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS,
>> extension_data.data),
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
>> extension_data.data),
>>> CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
>> extension_data.data),
>>> @@ -2003,6 +2009,8 @@ static const CodedBitstreamUnitTypeDescriptor
>> cbs_h266_unit_types[] = {
>>> CBS_UNIT_RANGE_INTERNAL_REF(VVC_IDR_W_RADL, VVC_GDR_NUT,
>>> H266RawSlice, data),
>>>
>>> +CBS_UNIT_TYPE_COMPLEX(VVC_SPS_NUT, H266RawSPS, cbs_h266_free_sps),
>>> +
>>> CBS_UNIT_TYPES_COMPLEX((VVC_PREFIX_SEI_NUT, VVC_SUFFIX_SEI_NUT),
>>> H266RawSEI, cbs_h266_free_sei),
>>>
>>
>> This should be a CBS_UNIT_TYPE_INTERNAL_REF().
>>
> Hi Andreas,
> Thank you for the review.
>
> Do you mean the SEI?
>
No, I mean the SPS. (If you want to, I can send a patch for this leak.)
- 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/cbs_h266: fix SPS VUI extension data leak
On Sun, Oct 22, 2023 at 8:58 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nuo Mi:
> > Fixes: VUI extension leak
> > Fixes:
> 63004/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4928832253329408
> >
> > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > ---
> > libavcodec/cbs_h2645.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > index 470f60b95f..ef631a11fe 100644
> > --- a/libavcodec/cbs_h2645.c
> > +++ b/libavcodec/cbs_h2645.c
> > @@ -1979,6 +1979,13 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_h265_unit_types[] = {
> > CBS_UNIT_TYPE_END_OF_LIST
> > };
> >
> > +static void cbs_h266_free_sps(FFRefStructOpaque unused, void *content)
> > +{
> > +H266RawSPS *sps = (H266RawSPS*)content;
> > +av_buffer_unref(>extension_data.data_ref);
> > +av_buffer_unref(>vui.extension_data.data_ref);
> > +}
> > +
> > static void cbs_h266_free_sei(FFRefStructOpaque unused, void *content)
> > {
> > H266RawSEI *sei = content;
> > @@ -1989,7 +1996,6 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_h266_unit_types[] = {
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI,
> extension_data.data),
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI,
> extension_data.data),
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS,
> extension_data.data),
> > -CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS,
> extension_data.data),
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS,
> extension_data.data),
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
> extension_data.data),
> > CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
> extension_data.data),
> > @@ -2003,6 +2009,8 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_h266_unit_types[] = {
> > CBS_UNIT_RANGE_INTERNAL_REF(VVC_IDR_W_RADL, VVC_GDR_NUT,
> > H266RawSlice, data),
> >
> > +CBS_UNIT_TYPE_COMPLEX(VVC_SPS_NUT, H266RawSPS, cbs_h266_free_sps),
> > +
> > CBS_UNIT_TYPES_COMPLEX((VVC_PREFIX_SEI_NUT, VVC_SUFFIX_SEI_NUT),
> > H266RawSEI, cbs_h266_free_sei),
> >
>
> This should be a CBS_UNIT_TYPE_INTERNAL_REF().
>
Hi Andreas,
Thank you for the review.
Do you mean the SEI?
>
> - 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 2/3] avcodec/rv60: RealVideo 6.0 decoder
Quoting Peter Ross (2023-10-22 01:31:32)
> On Wed, Oct 18, 2023 at 04:42:01PM +0200, Anton Khirnov wrote:
> > Quoting Peter Ross (2023-10-18 10:03:54)
> [..]
> > I think you can simplify this into:
> > if (s->last_frame[NEXT_PIC]->data[0]) {
> > av_frame_move_ref(frame, s->last_frame[NEXT_PIC]);
> > *got_frame = 1;
> > }
> [..]
> > You just unreffed the frame above, what is the point of using
> > reget_buffer()?
> [..]
> > The generic code should be doing this already.
> [..]
> > You could change this into av_frame_move_ref() and drop the unref below.
>
> many thanks anton for these suggestions. i agree with all of them.
>
> > > +if (s->pict_type != AV_PICTURE_TYPE_B) {
> > > +s->ref_pts[0] = s->ref_pts[1];
> > > +s->ref_pts[1] = avpkt->pts;
> > > +
> > > +s->ref_ts[0] = s->ref_ts[1];
> > > +s->ref_ts[1] = s->ts;
> > > +
> > > +if (s->ref_pts[1] > s->ref_pts[0] && s->ref_ts[1] > s->ref_ts[0])
> > > +s->ts_scale = (s->ref_pts[1] - s->ref_pts[0]) /
> > > (s->ref_ts[1] - s->ref_ts[0]);
> > > +} else {
> > > +frame->pts = s->ref_pts[0] + (s->ts - s->ref_ts[0]) *
> > > s->ts_scale;
> >
> > This looks immensely evil. Isn't ff_get_buffer() already setting the
> > timestamps correctly?
>
> no ff_reget_buffer() does not set pts correctly.
> the ref_ts ('s->ts') value is sent with every rv60 in the header, and is
> used to calculate the pts value. unsure how to make this less evil.
Typically the timestamps come from the container, so the decoder merely
copies them from packet to frame. Does the container not provide valid
timestamps here?
--
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 2/3] avcodec/rv60: RealVideo 6.0 decoder
On Sun, Oct 22, 2023 at 03:37:34PM +0200, Andreas Rheinhardt wrote:
> Peter Ross:
> > ---
> > diff --git a/libavformat/matroska.c b/libavformat/matroska.c
> > index 5878594e68..1674806f29 100644
> > --- a/libavformat/matroska.c
> > +++ b/libavformat/matroska.c
> > @@ -95,6 +95,7 @@ const CodecTags ff_mkv_codec_tags[]={
> > {"V_REAL/RV20" , AV_CODEC_ID_RV20},
> > {"V_REAL/RV30" , AV_CODEC_ID_RV30},
> > {"V_REAL/RV40" , AV_CODEC_ID_RV40},
> > +{"V_REAL/RV60" , AV_CODEC_ID_RV60},
>
> I don't see the Matroska codec mapping for this.
whoops, i will drop this hunk.
mkv is not supported by the official realmedia tools.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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] fftools: Check HAVE_GETSTDHANDLE before using GetStdHandle
Quoting Martin Storsjö (2023-10-22 13:08:44) > GetStdHandle is unavailable outside of the desktop API subset. > > This didn't use to be a problem with earlier WinSDKs, as kbhit also > used to be available only for desktop apps, and this whole section is > wrapped in #if HAVE_KBHIT. With newer WinSDKs, kbhit() is available also > for non-desktop apps, while GetStdHandle still isn't. > --- > fftools/ffmpeg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM -- 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] libavcodec/aarch64/hevc: Require consistent use of trailing semicolon
On Tue, 26 Sep 2023, Martin Storsjö wrote: --- Some patches had inconsistent semicolons when invoking these macros. By omitting the trailing semicolon in the macro, it requires the callers to use it consistently. --- libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Pushed. // Martin ___ 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] lavc/webp: Remove frame threading
Am 22.10.23 um 16:30 schrieb Andreas Rheinhardt: Thilo Borgmann via ffmpeg-devel: Revealed by the patch to support animated webp, the current frame threading implementation contains a data race. No, it doesn't: The current implementation does not call ff_thread_finish_setup() in vp8.c for webp: if (ffcodec(avctx->codec)->update_thread_context) ff_thread_finish_setup(avctx); It seems that "the patch to support animated webp" (what patch are we talking about?) adds an update_thread_context to the webp decoder, thereby changing things and adding the data race. Oh yes that's true, no update_thread_context(), so not happening. vp8_lossy_decode_frame() calls ff_vp8_decode_frame() wich calls ff_thread_finish_setup() to sync its internal slice threading. Nonsense: ff_thread_finish_setup() is only for frame-threading. Indeed, thx. Though, even if I was too stupid to realize for what, it is called... The race is happens because vp8_lossy_decode_frame() has to touch the AVCodecContext after it was passed to ff_vp8_decode_frame() and ff_thread_finish_setup() had been called. Therefore remove frame threading in webp and rely on slice threading in VP8 only. Also nonsense: The webp decoder does not support slice threading, so the internal VP8 decoder won't ever use it (even though it supports it). Thx again, that's good to know. I am a bit confused here: On the one hand, https://developers.google.com/speed/webp/docs/riff_container says that it only uses VP8 key frame encoding; on the other hand, it has this animation feature. Does this also only use VP8-intra coding (i.e. is the non-intra part of animation just the blending of earlier frames?)? That's how it works. If it does, then the webp decoder should be separated from the VP8 decoder (i.e. it should use it according to the public API) and the sub-decoder should only be used in single-threaded mode. That would solve the issue. How do I force the VP8 decoder to be single-threaded from the API? Tried that and failed - well, you know how stupid I am... Agreed, the internal VP8 decoding for lossless images should be gone from webp.c. IMO removing frame-threading for ordinary WebP due to animated WebP is unacceptable. Once VP8 decoding happens single-threaded, this patch is void of course. Thanks, Thilo ___ 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 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
On 10/22/23 17:51, Michael Niedermayer wrote: This makes the code more testable as uninitialized fields are 0 and not random values from the last call Signed-off-by: Michael Niedermayer --- libavcodec/vlc.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c index 9b7a42f79a3..4adec2da705 100644 --- a/libavcodec/vlc.c +++ b/libavcodec/vlc.c @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const int is16bit, uint32_t curcode, int curlen, int curlimit, int curlevel, const int minlen, const int max, - unsigned* levelcnt, VLC_MULTI_ELEM *info) + unsigned* levelcnt, VLC_MULTI_ELEM info) Is passing a struct by value advisable? Did you benchmark this? How does it compare to memset(info, 0, sizeof(*info))? - Leo Izen (Traneptora) ___ 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".
