Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/cbs_h2645: fix parsing and storing Picture Header references in the context
On Sun, Jul 2, 2023 at 7:32 AM James Almer wrote:
> On 7/1/2023 8:51 AM, Nuo Mi wrote:
> > On Fri, Jun 30, 2023 at 6:45 AM James Almer wrote:
> >
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/cbs_h2645.c| 35 ---
> >> libavcodec/cbs_h266.h | 17 +++--
> >> libavcodec/cbs_h266_syntax_template.c | 17 ++---
> >> libavcodec/h266_metadata_bsf.c| 13 +-
> >> libavcodec/vvc_parser.c | 10
> >> 5 files changed, 50 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> >> index cdd7901518..68ccf6a7eb 100644
> >> --- a/libavcodec/cbs_h2645.c
> >> +++ b/libavcodec/cbs_h2645.c
> >> @@ -525,12 +525,6 @@ static int
> >> cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
> >> if (frag->data_size == 0)
> >> return 0;
> >>
> >> -if (codec_id == AV_CODEC_ID_VVC) {
> >> -//we deactive picture header here to avoid reuse previous au's
> ph.
> >> -CodedBitstreamH266Context *h266 = ctx->priv_data;
> >> -h266->priv.ph = NULL;
> >> -}
> >> -
> >> if (header && frag->data[0] && codec_id == AV_CODEC_ID_H264) {
> >> // AVCC header.
> >> size_t size, start, end;
> >> @@ -793,19 +787,20 @@ cbs_h266_replace_ps(6, SPS, sps,
> >> sps_seq_parameter_set_id)
> >> cbs_h266_replace_ps(6, PPS, pps, pps_pic_parameter_set_id)
> >>
> >> static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
> >> - CodedBitstreamUnit *unit)
> >> + CodedBitstreamUnit *unit,
> >> + H266RawPictureHeader *ph)
> >> {
> >> CodedBitstreamH266Context *h266 = ctx->priv_data;
> >> int err;
> >>
> >> -h266->priv.ph = NULL;
> >> err = ff_cbs_make_unit_refcounted(ctx, unit);
> >> if (err < 0)
> >> return err;
> >> -err = av_buffer_replace(&h266->priv.ph_ref, unit->content_ref);
> >> +av_assert0(unit->content_ref);
> >> +err = av_buffer_replace(&h266->ph_ref, unit->content_ref);
> >> if (err < 0)
> >> return err;
> >> -h266->priv.ph = (H266RawPH*)h266->priv.ph_ref->data;
> >> +h266->ph = ph;
> >> return 0;
> >> }
> >>
> >> @@ -,7 +1106,7 @@ static int
> >> cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
> >> err = cbs_h266_read_ph(ctx, &gbc, ph);
> >> if (err < 0)
> >> return err;
> >> -err = cbs_h266_replace_ph(ctx, unit);
> >> +err = cbs_h266_replace_ph(ctx, unit,
> &ph->ph_picture_header);
> >> if (err < 0)
> >> return err;
> >> }
> >> @@ -1139,6 +1134,12 @@ static int
> >> cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
> >> pos = get_bits_count(&gbc);
> >> len = unit->data_size;
> >>
> >> +if (slice->header.sh_picture_header_in_slice_header_flag) {
> >> +err = cbs_h266_replace_ph(ctx, unit,
> >> &slice->header.sh_picture_header);
> >> +if (err < 0)
> >> +return err;
> >> +}
> >> +
> >> slice->data_size = len - pos / 8;
> >> slice->data_ref = av_buffer_ref(unit->data_ref);
> >> if (!slice->data_ref)
> >> @@ -1640,7 +1641,7 @@ static int
> >> cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
> >> if (err < 0)
> >> return err;
> >>
> >> -err = cbs_h266_replace_ph(ctx, unit);
> >> +err = cbs_h266_replace_ph(ctx, unit,
> &ph->ph_picture_header);
> >> if (err < 0)
> >> return err;
> >> }
> >> @@ -1661,6 +1662,12 @@ static int
> >> cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
> >> if (err < 0)
> >> return err;
> >>
> >> +if (slice->header.sh_picture_header_in_slice_header_flag) {
> >> +err = cbs_h266_replace_ph(ctx, unit,
> >> &slice->header.sh_picture_header);
> >> +if (err < 0)
> >> +return err;
> >> +}
> >> +
> >> if (slice->data) {
> >> err = cbs_h2645_write_slice_data(ctx, pbc,
> slice->data,
> >>slice->data_size,
> >> @@ -1884,8 +1891,8 @@ static void cbs_h266_flush(CodedBitstreamContext
> >> *ctx)
> >> av_buffer_unref(&h266->pps_ref[i]);
> >> h266->pps[i] = NULL;
> >> }
> >> -av_buffer_unref(&h266->priv.ph_ref);
> >> -h266->priv.ph = NULL;
> >> +av_buffer_unref(&h266->ph_ref);
> >> +h266->ph = NULL;
> >> }
> >>
> >> static void cbs_h266_close(CodedBitstreamContext *ctx)
> >> diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
> >> index 03dfd4a954..54590748c3 100644
> >> --- a/libavcodec/cbs_h266.h
> >> +++ b/libavcodec/cbs_h266.h
>
Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Thu, Jun 29, 2023 at 5:44 AM Anton Khirnov wrote: > Quoting Dai, Jianhui J (2023-06-29 08:03:18) > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Wednesday, June 28, 2023 11:25 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the > "number of > > > frames" in IVF header > > > > > > Quoting Dai, Jianhui J (2023-06-05 02:53:35) > > > > diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c index > > > > 511f2387ed..01012db948 100644 > > > > --- a/libavformat/ivfdec.c > > > > +++ b/libavformat/ivfdec.c > > > > @@ -53,6 +53,7 @@ static int read_header(AVFormatContext *s) > > > > st->codecpar->height = avio_rl16(s->pb); > > > > time_base.den = avio_rl32(s->pb); > > > > time_base.num = avio_rl32(s->pb); > > > > +// Infer duration from "number of frames". > > > > st->duration = avio_rl32(s->pb); > > > > > > This should be setting st->nb_frames then rather than duration. > > > And the muxer should be using that field as well instead of its custom > version. > > > > ACK. > > Do you suggest letting `duration` unset? > > It is interesting that the 'duration' is often right in this way, if > > the time_base.den/time_base.num == fps which is the popular > > configuration. > > Yes, but AFAIU there is no way to tell whether the file is CFR, so then > the value would be unreliable. So I'd prefer to leave it unset. > I see this discussion now... I don't think I agree with the above. First of all, IVF has two fields there (it seems): duration, and n_frames. We have the ability to set both in the muxer, and therefore should set both. Setting only once was silly, but changing it to set only the other is not better. Similarly, the demuxer should set both. I think it's particularly bad that we change a muxer that has been setting a particular field for years (and the accompanying demuxer code to the the AVStream member) to suddenly not set that field/member anymore. This is technically a regression. Ronald ___ 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] avcodec/cbs_h266: store RowHeightVal and ColWidthVal in the context
Stop overwriting values from the bitstream arrays pps_tile_column_width_minus1
and pps_tile_row_height_minus1.
Signed-off-by: James Almer
---
libavcodec/cbs_h266.h | 2 ++
libavcodec/cbs_h266_syntax_template.c | 37 ++-
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 9e823919af..dc7406f084 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -553,6 +553,8 @@ typedef struct H266RawPPS {
uint16_t slice_height_in_ctus[VVC_MAX_SLICES];
uint16_t num_slices_in_subpic[VVC_MAX_SLICES];
uint16_t sub_pic_id_val[VVC_MAX_SLICES];
+uint16_t col_width_val[VVC_MAX_TILE_COLUMNS];
+uint16_t row_height_val[VVC_MAX_TILE_ROWS];
} H266RawPPS;
typedef struct H266RawAUD {
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index f1cd45f815..f8d0fc8f1b 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -1748,10 +1748,10 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
"Tile column width(%d) exceeds picture width\n",i);
return AVERROR_INVALIDDATA;
}
+ current->col_width_val[i] = current->pps_tile_column_width_minus1[i]
+ 1;
remaining_size -= (current->pps_tile_column_width_minus1[i] + 1);
}
-unified_size = (i == 0 ? pic_width_in_ctbs_y :
-(current->pps_tile_column_width_minus1[i - 1] + 1));
+unified_size = current->pps_tile_column_width_minus1[i - 1] + 1;
while (remaining_size > 0) {
if (current->num_tile_columns > VVC_MAX_TILE_COLUMNS) {
av_log(ctx->log_ctx, AV_LOG_ERROR,
@@ -1760,7 +1760,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
return AVERROR_INVALIDDATA;
}
unified_size = FFMIN(remaining_size, unified_size);
-current->pps_tile_column_width_minus1[i] = unified_size - 1;
+current->col_width_val[i] = unified_size;
remaining_size -= unified_size;
i++;
}
@@ -1779,14 +1779,14 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
"Tile row height(%d) exceeds picture height\n",i);
return AVERROR_INVALIDDATA;
}
+ current->row_height_val[i] = current->pps_tile_row_height_minus1[i]
+ 1;
remaining_size -= (current->pps_tile_row_height_minus1[i] + 1);
}
-unified_size = (i == 0 ? pic_height_in_ctbs_y :
-(current->pps_tile_row_height_minus1[i - 1] + 1));
+unified_size = current->pps_tile_row_height_minus1[i - 1] + 1;
while (remaining_size > 0) {
unified_size = FFMIN(remaining_size, unified_size);
-current->pps_tile_row_height_minus1[i] = unified_size - 1;
+current->row_height_val[i] = unified_size;
remaining_size -= unified_size;
i++;
}
@@ -1852,20 +1852,20 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
ctu_x = ctu_y = 0;
for (j = 0; j < tile_x; j++) {
-ctu_x += current->pps_tile_column_width_minus1[j] + 1;
+ctu_x += current->col_width_val[j];
}
for (j = 0; j < tile_y; j++) {
-ctu_y += current->pps_tile_row_height_minus1[j] + 1;
+ctu_y += current->row_height_val[j];
}
if (current->pps_slice_width_in_tiles_minus1[i] == 0 &&
current->pps_slice_height_in_tiles_minus1[i] == 0 &&
-current->pps_tile_row_height_minus1[tile_y] > 0) {
+current->row_height_val[tile_y] > 1) {
int num_slices_in_tile,
uniform_slice_height, remaining_height_in_ctbs_y;
remaining_height_in_ctbs_y =
-current->pps_tile_row_height_minus1[tile_y] + 1;
+current->row_height_val[tile_y];
ues(pps_num_exp_slices_in_tile[i],
-0, current->pps_tile_row_height_minus1[tile_y], 1, i);
+0, current->row_height_val[tile_y] - 1, 1, i);
if (current->pps_num_exp_slices_in_tile[i] == 0) {
num_slices_in_tile = 1;
slice_top_left_ctu_x[i] = ctu_x;
@@ -1875,7 +1875,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
for (j = 0; j < current->pps_num_exp_slices_in_tile[i];
j++) {
ues(pps_exp_slice_height_in_ctus_minus1[i][j], 0,
-current->pps_tile_row_height_minus1[tile_y], 2,
+
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h266: store RowHeightVal in the context
On 7/1/2023 7:33 PM, James Almer wrote:
On 7/1/2023 12:10 PM, Nuo Mi wrote:
On Sat, Jul 1, 2023 at 9:37 AM James Almer wrote:
Stop overwriting values from the bitstream array
pps_tile_row_height_minus1.
Signed-off-by: James Almer
---
libavcodec/cbs_h266_syntax_template.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index ec2bb1ccc3..625995a2bd 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -1779,14 +1779,14 @@ static int FUNC(pps) (CodedBitstreamContext
*ctx,
RWContext *rw,
"Tile row height(%d) exceeds picture
height\n",i);
return AVERROR_INVALIDDATA;
}
+ current->row_height_val[i] =
current->pps_tile_row_height_minus1[i] + 1;
remaining_size -= (current->pps_tile_row_height_minus1[i]
+ 1);
}
- unified_size = (i == 0 ? pic_height_in_ctbs_y :
- (current->pps_tile_row_height_minus1[i - 1]
+ 1));
+ unified_size = current->pps_tile_row_height_minus1[i - 1] + 1;
while (remaining_size > 0) {
unified_size = FFMIN(remaining_size, unified_size);
- current->pps_tile_row_height_minus1[i] = unified_size - 1;
+ current->row_height_val[i] = unified_size;
remaining_size -= unified_size;
i++;
}
@@ -1855,17 +1855,17 @@ static int FUNC(pps) (CodedBitstreamContext
*ctx,
RWContext *rw,
ctu_x +=
current->pps_tile_column_width_minus1[j] + 1;
}
for (j = 0; j < tile_y; j++) {
- ctu_y += current->pps_tile_row_height_minus1[j]
+ 1;
+ ctu_y += current->row_height_val[j];
}
if (current->pps_slice_width_in_tiles_minus1[i] ==
0 &&
current->pps_slice_height_in_tiles_minus1[i] ==
0 &&
- current->pps_tile_row_height_minus1[tile_y] > 0) {
+ current->row_height_val[tile_y] > 1) {
int num_slices_in_tile,
uniform_slice_height,
remaining_height_in_ctbs_y;
remaining_height_in_ctbs_y =
- current->pps_tile_row_height_minus1[tile_y]
+ 1;
+ current->row_height_val[tile_y];
ues(pps_num_exp_slices_in_tile[i],
- 0, current->pps_tile_row_height_minus1[tile_y],
1, i);
+ 0, current->row_height_val[tile_y] - 1, 1, i);
if (current->pps_num_exp_slices_in_tile[i] == 0) {
num_slices_in_tile = 1;
slice_top_left_ctu_x[i] = ctu_x;
@@ -1875,7 +1875,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
for (j = 0; j <
current->pps_num_exp_slices_in_tile[i];
j++) {
ues(pps_exp_slice_height_in_ctus_minus1[i][j], 0,
-
current->pps_tile_row_height_minus1[tile_y], 2,
+ current->row_height_val[tile_y] - 1, 2,
The benefit is not so obvious when we need to -1 in multiple places.
It's not about having a benefit, but to stop writing derived values to a
raw bitstream struct field. And in the end, i also remove a bunch of +1.
What i did not carefully look in the spec is which of these uses
actually needs pps_tile_row_height_minus1 and which RowHeightVal. I
assumed all wanted the latter since it's calculated almost immediately
after the former is read from the bitstream, but maybe you know better.
Looking at the spec, it's indeed RowHeightVal and ColWidthVal what's
used everywhere, including the couple - 1 where i added them.
I'll send an updated patch to do the same for ColWidthVal, now that i
notice the same happens with it.
___
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 1/2] avcodec/cbs_h2645: fix parsing and storing Picture Header references in the context
On 7/1/2023 8:51 AM, Nuo Mi wrote:
On Fri, Jun 30, 2023 at 6:45 AM James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 35 ---
libavcodec/cbs_h266.h | 17 +++--
libavcodec/cbs_h266_syntax_template.c | 17 ++---
libavcodec/h266_metadata_bsf.c| 13 +-
libavcodec/vvc_parser.c | 10
5 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index cdd7901518..68ccf6a7eb 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -525,12 +525,6 @@ static int
cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
if (frag->data_size == 0)
return 0;
-if (codec_id == AV_CODEC_ID_VVC) {
-//we deactive picture header here to avoid reuse previous au's ph.
-CodedBitstreamH266Context *h266 = ctx->priv_data;
-h266->priv.ph = NULL;
-}
-
if (header && frag->data[0] && codec_id == AV_CODEC_ID_H264) {
// AVCC header.
size_t size, start, end;
@@ -793,19 +787,20 @@ cbs_h266_replace_ps(6, SPS, sps,
sps_seq_parameter_set_id)
cbs_h266_replace_ps(6, PPS, pps, pps_pic_parameter_set_id)
static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
- CodedBitstreamUnit *unit)
+ CodedBitstreamUnit *unit,
+ H266RawPictureHeader *ph)
{
CodedBitstreamH266Context *h266 = ctx->priv_data;
int err;
-h266->priv.ph = NULL;
err = ff_cbs_make_unit_refcounted(ctx, unit);
if (err < 0)
return err;
-err = av_buffer_replace(&h266->priv.ph_ref, unit->content_ref);
+av_assert0(unit->content_ref);
+err = av_buffer_replace(&h266->ph_ref, unit->content_ref);
if (err < 0)
return err;
-h266->priv.ph = (H266RawPH*)h266->priv.ph_ref->data;
+h266->ph = ph;
return 0;
}
@@ -,7 +1106,7 @@ static int
cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
err = cbs_h266_read_ph(ctx, &gbc, ph);
if (err < 0)
return err;
-err = cbs_h266_replace_ph(ctx, unit);
+err = cbs_h266_replace_ph(ctx, unit, &ph->ph_picture_header);
if (err < 0)
return err;
}
@@ -1139,6 +1134,12 @@ static int
cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
pos = get_bits_count(&gbc);
len = unit->data_size;
+if (slice->header.sh_picture_header_in_slice_header_flag) {
+err = cbs_h266_replace_ph(ctx, unit,
&slice->header.sh_picture_header);
+if (err < 0)
+return err;
+}
+
slice->data_size = len - pos / 8;
slice->data_ref = av_buffer_ref(unit->data_ref);
if (!slice->data_ref)
@@ -1640,7 +1641,7 @@ static int
cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
if (err < 0)
return err;
-err = cbs_h266_replace_ph(ctx, unit);
+err = cbs_h266_replace_ph(ctx, unit, &ph->ph_picture_header);
if (err < 0)
return err;
}
@@ -1661,6 +1662,12 @@ static int
cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
if (err < 0)
return err;
+if (slice->header.sh_picture_header_in_slice_header_flag) {
+err = cbs_h266_replace_ph(ctx, unit,
&slice->header.sh_picture_header);
+if (err < 0)
+return err;
+}
+
if (slice->data) {
err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
slice->data_size,
@@ -1884,8 +1891,8 @@ static void cbs_h266_flush(CodedBitstreamContext
*ctx)
av_buffer_unref(&h266->pps_ref[i]);
h266->pps[i] = NULL;
}
-av_buffer_unref(&h266->priv.ph_ref);
-h266->priv.ph = NULL;
+av_buffer_unref(&h266->ph_ref);
+h266->ph = NULL;
}
static void cbs_h266_close(CodedBitstreamContext *ctx)
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 03dfd4a954..54590748c3 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -581,8 +581,7 @@ typedef struct H266RawPredWeightTable {
int16_t delta_chroma_offset_l1[15][2];
} H266RawPredWeightTable;
-typedef struct H266RawPH {
-H266RawNALUnitHeader nal_unit_header;
+typedef struct H266RawPictureHeader {
uint8_t ph_gdr_or_irap_pic_flag;
uint8_t ph_non_ref_pic_flag;
uint8_t ph_gdr_pic_flag;
@@ -670,12 +669,17 @@ typedef struct H266RawPH {
uint8_t ph_extension_length;
uint8_t ph_extension_data_byte[256];
+} H266RawPictureHeader;
+
+typedef struct H266RawPH {
+H266RawNALUnitHeader nal_unit_header;
+H266RawPictureHeader ph_picture_header;
} H266RawPH;
typedef
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cbs_h266: store RowHeightVal in the context
On 7/1/2023 12:10 PM, Nuo Mi wrote:
On Sat, Jul 1, 2023 at 9:37 AM James Almer wrote:
Stop overwriting values from the bitstream array
pps_tile_row_height_minus1.
Signed-off-by: James Almer
---
libavcodec/cbs_h266_syntax_template.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index ec2bb1ccc3..625995a2bd 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -1779,14 +1779,14 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
"Tile row height(%d) exceeds picture height\n",i);
return AVERROR_INVALIDDATA;
}
+ current->row_height_val[i] =
current->pps_tile_row_height_minus1[i] + 1;
remaining_size -= (current->pps_tile_row_height_minus1[i] + 1);
}
-unified_size = (i == 0 ? pic_height_in_ctbs_y :
-(current->pps_tile_row_height_minus1[i - 1] + 1));
+unified_size = current->pps_tile_row_height_minus1[i - 1] + 1;
while (remaining_size > 0) {
unified_size = FFMIN(remaining_size, unified_size);
-current->pps_tile_row_height_minus1[i] = unified_size - 1;
+current->row_height_val[i] = unified_size;
remaining_size -= unified_size;
i++;
}
@@ -1855,17 +1855,17 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
ctu_x += current->pps_tile_column_width_minus1[j] + 1;
}
for (j = 0; j < tile_y; j++) {
-ctu_y += current->pps_tile_row_height_minus1[j] + 1;
+ctu_y += current->row_height_val[j];
}
if (current->pps_slice_width_in_tiles_minus1[i] == 0 &&
current->pps_slice_height_in_tiles_minus1[i] == 0 &&
-current->pps_tile_row_height_minus1[tile_y] > 0) {
+current->row_height_val[tile_y] > 1) {
int num_slices_in_tile,
uniform_slice_height, remaining_height_in_ctbs_y;
remaining_height_in_ctbs_y =
-current->pps_tile_row_height_minus1[tile_y] + 1;
+current->row_height_val[tile_y];
ues(pps_num_exp_slices_in_tile[i],
-0, current->pps_tile_row_height_minus1[tile_y],
1, i);
+0, current->row_height_val[tile_y] - 1, 1, i);
if (current->pps_num_exp_slices_in_tile[i] == 0) {
num_slices_in_tile = 1;
slice_top_left_ctu_x[i] = ctu_x;
@@ -1875,7 +1875,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
for (j = 0; j <
current->pps_num_exp_slices_in_tile[i];
j++) {
ues(pps_exp_slice_height_in_ctus_minus1[i][j], 0,
-
current->pps_tile_row_height_minus1[tile_y], 2,
+current->row_height_val[tile_y] - 1, 2,
The benefit is not so obvious when we need to -1 in multiple places.
It's not about having a benefit, but to stop writing derived values to a
raw bitstream struct field. And in the end, i also remove a bunch of +1.
What i did not carefully look in the spec is which of these uses
actually needs pps_tile_row_height_minus1 and which RowHeightVal. I
assumed all wanted the latter since it's calculated almost immediately
after the former is read from the bitstream, but maybe you know better.
I'll send an updated patch to do the same for ColWidthVal, now that i
notice the same happens with it.
i, j);
slice_height_in_ctus =
current->
@@ -1890,7 +1890,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
remaining_height_in_ctbs_y -=
slice_height_in_ctus;
}
uniform_slice_height = 1 +
-(j == 0 ?
current->pps_tile_row_height_minus1[tile_y] :
+(j == 0 ? current->row_height_val[tile_y] - 1:
current->pps_exp_slice_height_in_ctus_minus1[i][j-1]);
while (remaining_height_in_ctbs_y >
uniform_slice_height) {
current->slice_height_in_ctus[i + j] =
@@ -1919,7 +1919,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
j <=
current->pps_slice_height_in_tiles_minus1[i];
j++) {
height +=
- current->pps_tile_row_height_minus1[tile_y +
j] + 1;
+ current->row_height_val[tile_y + j];
}
Re: [FFmpeg-devel] [PATCH 11/15] avfilter/vf_bwdif: Add neon for filter_line
On Thu, 29 Jun 2023, John Cox wrote:
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 21 ++
libavfilter/aarch64/vf_bwdif_neon.S | 215
2 files changed, 236 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index e75cf2f204..21e67884ab 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -31,6 +31,26 @@ void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void
*cur1, void *next1,
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max);
+
+
+static void filter_line_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_line_neon(dst1, prev1, cur1, next1,
+ w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+}
static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void *next1,
int w, int prefs, int mrefs, int prefs2, int
mrefs2,
@@ -71,6 +91,7 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_line = filter_line_helper;
s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index a33b235882..675e97d966 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -128,6 +128,221 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+// ===
+//
+// void filter_line(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int prefs3, // [sp, #8]
+// int mrefs3, // [sp, #16]
+// int prefs4, // [sp, #24]
+// int mrefs4, // [sp, #32]
+// int parity, // [sp, #40]
+// int clip_max) // [sp, #48]
+
+function ff_bwdif_filter_line_neon, export=1
+// Sanity check w
+cmp w4, #0
+ble 99f
+
+// Rearrange regs to be the same as line3 for ease of debug!
+mov w10, w4 // w10 = loop count
+mov w9, w6 // w9 = mref
+mov w12, w7 // w12 = pref2
+mov w11, w5 // w11 = pref
+ldr w8, [sp, #0] // w8 = mref2
+ldr w7, [sp, #16] // w7 = mref3
+ldr w6, [sp, #32] // w6 = mref4
+ldr w13, [sp, #8] // w13 = pref3
+ldr w14, [sp, #24] // w14 = pref4
Btw, remember that you can load two arguments from the stack at once with
ldp, e.g. "ldp x8, x13, [sp, #0]". If they're made intptr_t/ptrdiff_t, you
won't have an issue with garbage in the upper 32 bits either.
+
+mov x4, x3
+mov x3, x2
+mov x2, x1
+
+// #define prev2 cur
+//const uint8_t * restrict next2 = parity ? prev : next;
+ldr w17, [sp, #40] // parity
+cmp w17, #0
+cselx17, x2, x4, ne
+
+// We want all the V registers - save all the ones we must
+stp d14, d15, [sp, #-64]!
+stp d8, d9, [sp, #48]
+stp d10, d11, [sp, #32]
+stp d12, d13, [sp, #16]
The order looks a bit weird here even if they end up sequential on the
stac
Re: [FFmpeg-devel] [PATCH 08/15] avfilter/vf_bwdif: Add neon for filter_edge
On Thu, 29 Jun 2023, John Cox wrote:
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 20
libavfilter/aarch64/vf_bwdif_neon.S | 104
2 files changed, 124 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 3ffaa07ab3..e75cf2f204 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,10 +24,29 @@
#include "libavfilter/bwdif.h"
#include "libavutil/aarch64/cpu.h"
+void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat);
+
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_edge_neon(dst1, prev1, cur1, next1, w0, prefs, mrefs,
prefs2, mrefs2,
+ parity, clip_max, spat);
+
+if (w0 < w)
+ff_bwdif_filter_edge_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2,
+ parity, clip_max, spat);
+}
+
static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max)
{
@@ -52,5 +71,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 6c5d1598f4..a33b235882 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -128,6 +128,110 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+//
+//
+// void ff_bwdif_filter_edge_neon(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int parity, // [sp, #8]
+// int clip_max, // [sp, #16] unused
+// int spat); // [sp, #24]
This doesn't hold for macOS targets (and the checkasm tests fail on that
platform).
On macOS, arguments that aren't passed in registers but on the stack, are
tightly packed. So since parity is 32 bit and mrefs2 also was 32 bit,
parity is available at [sp, #4].
Therefore, it's usually simplest for portability reasons, to pass any
arguments after the first 8, as intptr_t or ptrdiff_t, as that makes them
consistent across platforms.
// 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 04/15] avfilter/vf_bwdif: Add neon for filter_intra
On Thu, 29 Jun 2023, John Cox wrote:
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 17 +++
libavfilter/aarch64/vf_bwdif_neon.S | 53 +
2 files changed, 70 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 86d53b2ca1..3ffaa07ab3 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,6 +24,22 @@
#include "libavfilter/bwdif.h"
#include "libavutil/aarch64/cpu.h"
+void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+int prefs3, int mrefs3, int parity, int
clip_max);
+
+
+static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+int prefs3, int mrefs3, int parity, int
clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_intra_neon(dst1, cur1, w0, prefs, mrefs, prefs3, mrefs3,
parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_intra_c((char *)dst1 + w0, (char *)cur1 + w0,
+w - w0, prefs, mrefs, prefs3, mrefs3, parity,
clip_max);
+}
+
void
ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
{
@@ -35,5 +51,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
if (!have_neon(cpu_flags))
return;
+s->filter_intra = filter_intra_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index a8f0ed525a..b863b3447d 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -69,3 +69,56 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+//
+//
+// void ff_bwdif_filter_intra_neon(
+// void *dst1, // x0
+// void *cur1, // x1
+// int w, // w2
+// int prefs, // w3
+// int mrefs, // w4
+// int prefs3, // w5
+// int mrefs3, // w6
+// int parity, // w7 unused
+// int clip_max) // [sp, #0] unused
This bit is great to have
+
+function ff_bwdif_filter_intra_neon, export=1
+cmp w2, #0
+ble 99f
+
+ldr q0, coeffs
+
+//for (x = 0; x < w; x++) {
+10:
+
+//interpol = (coef_sp[0] * (cur[mrefs] + cur[prefs]) - coef_sp[1] *
(cur[mrefs3] + cur[prefs3])) >> 13;
I guess the style with intermixed C code is a bit uncommon in our
assembly, but as long as it doesn't affect the overall code style I guess
we can keep it.
+ldr q31, [x1, w4, SXTW]
+ldr q30, [x1, w3, SXTW]
+ldr q29, [x1, w6, SXTW]
+ldr q28, [x1, w5, SXTW]
Don't use shouty uppercase SXTW here
+
+uaddl v20.8h, v31.8b, v30.8b
+uaddl2 v21.8h, v31.16b, v30.16b
+
+UMULL4K v2, v3, v4, v5, v20, v21, v0.h[6]
+
+uaddl v20.8h, v29.8b, v28.8b
+uaddl2 v21.8h, v29.16b, v28.16b
+
+UMLSL4K v2, v3, v4, v5, v20, v21, v0.h[7]
+
+//dst[0] = av_clip(interpol, 0, clip_max);
+SQSHRUNNv2, v2, v3, v4, v5, 13
+str q2, [x0], #16
+
+//dst++;
+//cur++;
+//}
+
+subsw2, w2, #16
+add x1, x1, #16
For in-order cores, it might be good to update these variables sometime
sooner, e.g. before the str instruction. But such scheduling breaks your
mapping between neat C code and assembly.
// 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 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
On Thu, 29 Jun 2023, John Cox wrote:
Add macros for dual scalar half->single multiply and accumulate
Add macro for shift, saturate and shorten single to byte
Add filter constants
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_neon.S | 46 +
1 file changed, 46 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 639ab22998..a8f0ed525a 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -23,3 +23,49 @@
#include "libavutil/aarch64/asm.S"
+.macro SQSHRUNN b, s0, s1, s2, s3, n
+sqshrun \s0\().4h, \s0\().4s, #\n - 8
+sqshrun2\s0\().8h, \s1\().4s, #\n - 8
+sqshrun \s1\().4h, \s2\().4s, #\n - 8
+sqshrun2\s1\().8h, \s3\().4s, #\n - 8
+uzp2\b\().16b, \s0\().16b, \s1\().16b
+.endm
+
+.macro SMULL4K a0, a1, a2, a3, s0, s1, k
+smull \a0\().4s, \s0\().4h, \k
+smull2 \a1\().4s, \s0\().8h, \k
+smull \a2\().4s, \s1\().4h, \k
+smull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMULL4K a0, a1, a2, a3, s0, s1, k
+umull \a0\().4s, \s0\().4h, \k
+umull2 \a1\().4s, \s0\().8h, \k
+umull \a2\().4s, \s1\().4h, \k
+umull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLAL4K a0, a1, a2, a3, s0, s1, k
+umlal \a0\().4s, \s0\().4h, \k
+umlal2 \a1\().4s, \s0\().8h, \k
+umlal \a2\().4s, \s1\().4h, \k
+umlal2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLSL4K a0, a1, a2, a3, s0, s1, k
+umlsl \a0\().4s, \s0\().4h, \k
+umlsl2 \a1\().4s, \s0\().8h, \k
+umlsl \a2\().4s, \s1\().4h, \k
+umlsl2 \a3\().4s, \s1\().8h, \k
+.endm
+
+// static const uint16_t coef_lf[2] = { 4309, 213 };
+// static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
+// static const uint16_t coef_sp[2] = { 5077, 981 };
+
+.align 16
Note that .align for arm is power of two; this triggers a 2^16 byte
alignment here, which certainly isn't intended.
But in general, the usual way of defining constants is with a
const/endconst block, which places them in the right rdata section instead
of in the text section. But that then requires you to use a movrel macro
for accessing the data, instead of a plain ldr instruction.
+coeffs:
+.hword 4309 * 4, 213 * 4 // lf[0]*4 = v0.h[0]
+.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
+.hword 5077, 981 // sp[0] = v0.h[6]
+
--
// 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 00/15] avfilter/vf_bwdif: Add aarch64 neon functions
On Thu, 29 Jun 2023, John Cox wrote: Also adds a filter_line3 method which on aarch64 neon yields approx 30% speedup over 2xfilter_line and a memcpy John Cox (15): avfilter/vf_bwdif: Add outline for aarch neon functions avfilter/vf_bwdif: Add common macros and consts for aarch64 neon avfilter/vf_bwdif: Export C filter_intra avfilter/vf_bwdif: Add neon for filter_intra tests/checkasm: Add test for vf_bwdif filter_intra avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon avfilter/vf_bwdif: Export C filter_edge avfilter/vf_bwdif: Add neon for filter_edge tests/checkasm: Add test for vf_bwdif filter_edge avfilter/vf_bwdif: Export C filter_line avfilter/vf_bwdif: Add neon for filter_line avfilter/vf_bwdif: Add a filter_line3 method for optimisation avfilter/vf_bwdif: Add neon for filter_line3 tests/checkasm: Add test for vf_bwdif filter_line3 avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines It's nice to have this split up in small easily checkable patches, but this is perhaps a bit more finegrained than what's usual. But I guess that's ok... I'll comment on the patches that need commenting on. // 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 v6 0/1] avformat: add Software Defined Radio support
> > You can design something starting with a filter and then define everything > a subclass of filter. > you can design things with no common class and everything different types. > > But whatever you call the class for the SDR code and the class of the > common > demuxers. Their do look very darn similar > they should IMHO have a common parent class. > > Call one Demuxer and one Transport but they still do take one input stream > (a stream of complex values in case of SDR) and spit out multiple streams > raw audio, raw video, mpegts. > And same way (other) demuxers also can return raw audio, raw video, mpegts > False, SDR is doing active DSP processing on the input data, a normal demux is not, it's working in a domain where something upstream (network card+TCP/IPstack, capture card) has done this part. Ergo, by extension SDR should be done upstream as lots of people have been saying. Kieran ___ 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 v7] avformat: add Software Defined Radio support
Signed-off-by: Michael Niedermayer
---
configure|4 +
doc/demuxers.texi| 90 ++
libavdevice/Makefile |1 +
libavdevice/alldevices.c |1 +
libavdevice/sdrindev.c | 370 +++
libavformat/Makefile |1 +
libavformat/allformats.c |1 +
libavformat/sdr.h| 251 +
libavformat/sdrdemux.c | 1999 ++
9 files changed, 2718 insertions(+)
create mode 100644 libavdevice/sdrindev.c
create mode 100644 libavformat/sdr.h
create mode 100644 libavformat/sdrdemux.c
diff --git a/configure b/configure
index 4ac7cc6c0b..f6dfc2f1c1 100755
--- a/configure
+++ b/configure
@@ -269,6 +269,7 @@ External library support:
--enable-libshineenable fixed-point MP3 encoding via libshine [no]
--enable-libsmbclientenable Samba protocol via libsmbclient [no]
--enable-libsnappy enable Snappy compression, needed for hap encoding
[no]
+ --enable-libsoapysdr enable SoapySDR, needed for connecting to SDR HW
[no]
--enable-libsoxr enable Include libsoxr resampling [no]
--enable-libspeexenable Speex de/encoding via libspeex [no]
--enable-libsrt enable Haivision SRT protocol via libsrt [no]
@@ -1888,6 +1889,7 @@ EXTERNAL_LIBRARY_LIST="
libshine
libsmbclient
libsnappy
+libsoapysdr
libsoxr
libspeex
libsrt
@@ -3602,6 +3604,7 @@ oss_outdev_deps_any="sys_soundcard_h"
pulse_indev_deps="libpulse"
pulse_outdev_deps="libpulse"
sdl2_outdev_deps="sdl2"
+sdr_indev_deps="libsoapysdr"
sndio_indev_deps="sndio"
sndio_outdev_deps="sndio"
v4l2_indev_deps_any="linux_videodev2_h sys_videoio_h"
@@ -6776,6 +6779,7 @@ enabled libshine && require_pkg_config libshine
shine shine/layer3.h sh
enabled libsmbclient && { check_pkg_config libsmbclient smbclient
libsmbclient.h smbc_init ||
require libsmbclient libsmbclient.h smbc_init
-lsmbclient; }
enabled libsnappy && require libsnappy snappy-c.h snappy_compress
-lsnappy -lstdc++
+enabled libsoapysdr && require libsoapysdr SoapySDR/Device.h
SoapySDRDevice_enumerate -lSoapySDR
enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr
enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h
sftp_init
enabled libspeex && require_pkg_config libspeex speex speex/speex.h
speex_decoder_init
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2d33b47a56..fc2ab9fc27 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -899,6 +899,96 @@ the script is directly played, the actual times will match
the absolute
timestamps up to the sound controller's clock accuracy, but if the user
somehow pauses the playback or seeks, all times will be shifted accordingly.
+@section sdr / sdrfile
+
+Software Defined Radio Demuxer. The sdr demuxer will demux radio streams
+through the use of a libsoapy compatible software defined radio. sdrfile
+will do the same from a file.
+The short seek forward and backward commands can be used to select the next and
+previous radio stations. Seeking to specific radio stations and similar will be
+supported in the future. This has been tested with a RTL-SDR blog V3 and
sdrplay RSP1A,
+it should work with anything else libsoapy supports but may need minor tweaks.
+
+@table @option
+
+@item block_size
+size of FFT to use, leave at 0 to choose automatically
+
+@item video_size
+Enable vissualization with the specified video resolution. Default is
+disabled
+
+@item mode
+
+@table @samp
+
+@item single_mode
+Demodulate 1 station
+
+@item all_mode
+Demodulate all stations in view
+
+@end table
+
+@item station_freq
+Initial station to pick, if multiple are probed.
+
+@item driver
+libsoapy driver to use. Leave empty to attempt autodetection.
+
+@item sdr_sr
+SDR sample rate, this must be a value supported by the hardware. Leave 0 to
attempt
+autodetection
+
+@item sdr_freq
+initial SDR center frequency, this must be a value supported by the hardware
+
+@item min_freq
+Minimum frequency, leave at 0 for autodetection
+
+@item max_freq
+Maximum frequency, leave at 0 for autodetection
+
+@item dumpurl
+URL to dump RAW SDR stream to, this can be played back later with sdrfile.
Useful
+for debuging.
+
+@item kbd_alpha
+Kaiser Bessel derived window parameter
+
+@item am_mode
+AM Demodulation method. Several different methods are supported.
+@table @samp
+@item am_inphase
+Demodulate mono signal that is in phase with the carrier. This works well if
there is one
+transmitter at the frequency and there is nothing disturbing the signal.
+
+@item am_midside
+Demodulate AM into a stereo signal so that the mid is from the in phase and
side is from the
+quadrature signal. This can be used if there are Multiple transmitters that
transmit at the same
+frequency. Or just for fun.
+
+@item am_envelope
+Demodulate mono signal that is basically the energy of the spectrum.
+
+@end table
+
+@item fm_em
[FFmpeg-devel] [PATCH v7 0/1] avformat: add Software Defined Radio support
Synchronous AM demodulation using Macleod based systhesized carrier better workaround for RTLSDR DC issue show soapy defaults 2 Stage station probing reduce FM bandwidth if station is partly outside range (for example with recoreded files we cannot move the range) 10% faster FM phase computation ___ 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/5] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_w_hv
On Sun, 18 Jun 2023, Logan.Lyu wrote: Hi, Martin, I modified it according to your comments. Please review again. From 47b7f7af634add7680b56a216fff7dbe1f08cd11 Mon Sep 17 00:00:00 2001 From: Logan Lyu Date: Sun, 28 May 2023 10:35:43 +0800 Subject: [PATCH 5/5] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_w_hv Signed-off-by: Logan Lyu --- libavcodec/aarch64/hevcdsp_epel_neon.S| 694 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 + 2 files changed, 700 insertions(+) diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S b/libavcodec/aarch64/hevcdsp_epel_neon.S index 8b6f396a0b..355679af29 100644 --- a/libavcodec/aarch64/hevcdsp_epel_neon.S +++ b/libavcodec/aarch64/hevcdsp_epel_neon.S @@ -717,6 +717,700 @@ function ff_hevc_put_hevc_epel_uni_w_h64_8_neon_i8mm, export=1 ret endfunc +.macro epel_uni_w_hv_start +mov x15, x5 //denom +mov x16, x6 //wx +mov x17, x7 //ox +add w15, w15, #6//shift = denom+6 + + +ldp x5, x6, [sp] +ldr x7, [sp, #16] + +stp q12, q13, [sp, #-128]! +stp q14, q15, [sp, #32] +stp q8, q9, [sp, #64] +stp q10, q11, [sp, #96] Only need to back up 64 bytes, by backing up d8-d15. Also, the order is quite weird here, why not keep them in e.g. linear order? +function ff_hevc_put_hevc_epel_uni_w_hv4_8_neon_i8mm, export=1 +epel_uni_w_hv_start +sxtwx4, w4 + +add x10, x4, #3 +lsl x10, x10, #7 +sub sp, sp, x10 // tmp_array +stp xzr, x30, [sp, #-48]! As mentioned already in the previous review - why do you back up and restore xzr here? That's not necessary. Yes, you should keep the stack 16 byte aligned, but you can just leave an empty slot, and just do "str x30, [sp, #-48]!" here, and vice versa with "ldr" instead of ldp when restoring. The same goes in all functions here. +2: +ldp q14, q15, [sp, #32] +ldp q8, q9, [sp, #64] +ldp q10, q11, [sp, #96] +ldp q12, q13, [sp], #128 Only need d8-d15, and weird register order here, and elsewhere. +function ff_hevc_put_hevc_epel_uni_w_hv24_8_neon_i8mm, export=1 +epel_uni_w_hv_start +sxtwx4, w4 FWIW, it's unusual to need an explicit sxtw instruction, but I guess if you use it in the form "add x10, x4, #3" it might be needed. +function ff_hevc_put_hevc_epel_uni_w_hv32_8_neon_i8mm, export=1 +ldp x15, x16, [sp] +stp x0, x30, [sp, #-16]! +stp x1, x2, [sp, #-16]! +stp x3, x4, [sp, #-16]! +stp x5, x6, [sp, #-16]! Don't do consecutive stack pointer updates like this, but merge it into one large stack decrement followed by positive offsets, like in all the other cases of stp/ldp. +mov x17, #16 +stp x17, x7, [sp, #-16]! +stp x15, x16, [sp, #-16]! +bl X(ff_hevc_put_hevc_epel_uni_w_hv16_8_neon_i8mm) +ldp x15, x16, [sp], #16 +ldp x17, x7, [sp], #16 +ldp x5, x6, [sp], #16 +ldp x3, x4, [sp], #16 +ldp x1, x2, [sp], #16 +ldr x0, [sp] +add x0, x0, #16 +add x2, x2, #16 +mov x17, #16 +stp x17, xzr, [sp, #-16]! +stp x15, x16, [sp, #-16]! Don't do multiple stack decrements, don't needlessly store xzr here. The same goes for all the other functions in this patch. // 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 v6 0/1] avformat: add Software Defined Radio support
On Sat, Jul 01, 2023 at 09:42:14PM +0100, Kieran Kunhya wrote: [...] > > If so, what design ? > > > > This is purely a flaw in FFmpeg that protocol/demux are joined up into the > same library. Also an assumption (coming from things like AVI and probably > reasonable at the time) that there is only going to be one layer of demux, > whereas in modern codecs (HEIF, LC-EVC, Dolby E etc) there can be many > layers of demux required. > > Your logic is flawed, you base your assumption that everyone else is wrong > when it's in fact FFmpeg that's in the wrong by mixing transport and > container into the same library. Iam not assuming anyone is wrong. "wrong" and "right" depend alot on assumtations and point of view. You can be wrong in mathematics. With software you can be wrong if the code doesnt work. Or if code maintaince costs more than the competitor has to pay for the same. if libavformats design is a problem for modern containers it needs to evolve In respect to SDR and multimedia, it seems again not different from the other "many layers of demux" already needed. we even have avpriv_mpegts* as exported functions already ... people may hate libavformats design. Ok but this design doesnt have a problem with the SDR code theres nothing i had to change in libavformats APIs. If theres mpegts id try to pass it throught the existing avpriv_mpegts* code. maybe that would not work and need some amendment, but thats not a big deal > > > > > As for purely AM/FM, I'm not quire sure what the right level for > > > that is though. > > > > > > > > In any case, I disagree with the procedure of stating to push the patch > > if > > > there's no objections, when there has been numerous objections from > > > essentially most of the active community already. > > > > The objections have been unclear, are they against SDR, against the > > implementation. > > I took the liberty to be pushy here to get this more clear. And i will > > continue to do this until i get clear responses. Because otherwise > > iam just stuck as i dont know how to correct the design and code. > > > > They are against SDR as this violates layering. FFmpeg doesn't handle the > physical layer, third party libs do upstream (e.g hardware capture). > Again, should we implement WiFi SDR in FFmpeg? Should we implement a > userspace TCP stack? Should we implement bitbanged Ethernet? All of these > things sit at a different layer to the data and transport layer that FFmpeg > sits in. You can design something starting with a filter and then define everything a subclass of filter. you can design things with no common class and everything different types. But whatever you call the class for the SDR code and the class of the common demuxers. Their do look very darn similar they should IMHO have a common parent class. Call one Demuxer and one Transport but they still do take one input stream (a stream of complex values in case of SDR) and spit out multiple streams raw audio, raw video, mpegts. And same way (other) demuxers also can return raw audio, raw video, mpegts thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. 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 3/5] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_w_v
On Sun, 18 Jun 2023, Logan.Lyu wrote: Hi, Martin, I modified it according to your comments. Please review again. From 45508b099dc99d30e711b9e1f253068f7804e3ed Mon Sep 17 00:00:00 2001 From: Logan Lyu Date: Sat, 27 May 2023 09:42:07 +0800 Subject: [PATCH 3/5] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_w_v Signed-off-by: Logan Lyu --- libavcodec/aarch64/hevcdsp_epel_neon.S| 503 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 + 2 files changed, 509 insertions(+) diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S b/libavcodec/aarch64/hevcdsp_epel_neon.S index 0411de9864..ca37ce1786 100644 --- a/libavcodec/aarch64/hevcdsp_epel_neon.S +++ b/libavcodec/aarch64/hevcdsp_epel_neon.S +function ff_hevc_put_hevc_epel_uni_w_v12_8_neon, export=1 +EPEL_UNI_W_V_HEADER + +ldr q4, [x2] +ldr q5, [x2, x3] +add x2, x2, x3, lsl #1 +ldr q6, [x2] +sub x1, x1, #8 +1: +ldr q7, [x2, x3] +subsw4, w4, #1 +add x2, x2, x3, lsl #1 +EPEL_UNI_W_V12_CALC v16, v17 v4, v5, v6, v7, v24, v25, v26, v27 This is missing a comma between "v17" and "v4" (here and in one other place). This breaks compilation for macOS targets, where the assembler (for historical reasons) has a separate way of handling macro arguments. The same also goes for "v20 v24" in two places. +function ff_hevc_put_hevc_epel_uni_w_v48_8_neon, export=1 +EPEL_UNI_W_V_HEADER +stp q8, q9, [sp, #-64]! +stp q10, q11, [sp, #32] As mentioned in another follow-up reply, you don't need to back up and restore all of q8-q15, only the lower half. This means that it's enough to back up and restore d8-d15, which only takes half as much space. I.e. here you'd have +stp d8, d9, [sp, #-32]! +stp d10, d11, [sp, #16] instead, and for the full d8-d15 you'd have +stp d8, d9, [sp, #-64]! +stp d10, d11, [sp, #16] +stp d12, d13, [sp, #32] +stp d14, d15, [sp, #48] The same goes for both of these places in this patch, and for a number of places in patch 5/5. // 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 1/5] lavc/aarch64: new optimization for 8-bit hevc_pel_uni_pixels
On Sun, 18 Jun 2023, Logan.Lyu wrote: Hi, Martin, I modified it according to your comments. Please review again. And here are the checkasm benchmark results of the related functions: The platform I tested is the g8y instance of Alibaba Cloud, with a chip based on armv9. Thanks for clarifying that. When updating patches, please include those benchmark numbers in the commit message, and mention the HW used for testing there in the commit message. And when tweaking patches, remember to update the benchmark numbers in the commit message if the tweak changes the results notably. The patchset is almost ok to be pushed, there's a couple issues left. I was about to just fix up the last issues myself and push them, but patch 5 had a bit more issues than I wanted to fix silently. // 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 v6 0/1] avformat: add Software Defined Radio support
> > If we look at DAB or DVB in a more fundamental way, they have no need > for mpegts. > Should this (apparently unneeded) design decission in DAB/DVB dictate > design on our side when it has not previously ? > What planet do you live on, of course they need MPEG-TS? How do you have multiple programs in a mux and associated data for EPG? Literally the whole point of Digital TV was that we could put more channels in the space that one analogue channel took. There are no other containers that support multiple programs. For the rest of MPEG-TS justification I point you to: https://www.obe.tv/why-does-mpeg-ts-still-exist/ > If so, what design ? > This is purely a flaw in FFmpeg that protocol/demux are joined up into the same library. Also an assumption (coming from things like AVI and probably reasonable at the time) that there is only going to be one layer of demux, whereas in modern codecs (HEIF, LC-EVC, Dolby E etc) there can be many layers of demux required. Your logic is flawed, you base your assumption that everyone else is wrong when it's in fact FFmpeg that's in the wrong by mixing transport and container into the same library. > > As for purely AM/FM, I'm not quire sure what the right level for > > that is though. > > > > > In any case, I disagree with the procedure of stating to push the patch > if > > there's no objections, when there has been numerous objections from > > essentially most of the active community already. > > The objections have been unclear, are they against SDR, against the > implementation. > I took the liberty to be pushy here to get this more clear. And i will > continue to do this until i get clear responses. Because otherwise > iam just stuck as i dont know how to correct the design and code. > They are against SDR as this violates layering. FFmpeg doesn't handle the physical layer, third party libs do upstream (e.g hardware capture). Again, should we implement WiFi SDR in FFmpeg? Should we implement a userspace TCP stack? Should we implement bitbanged Ethernet? All of these things sit at a different layer to the data and transport layer that FFmpeg sits in. Regards, Kieran Kunhya ___ 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 v6 0/1] avformat: add Software Defined Radio support
On Sat, Jul 01, 2023 at 10:41:34PM +0300, Martin Storsjö wrote: > On Sat, 1 Jul 2023, Michael Niedermayer wrote: > > > On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote: > > > On Fri, 30 Jun 2023, Michael Niedermayer wrote: > > > > > > > On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote: > > > > > If you apply this I will apply my pending libswresample commits and > > > > > also > > > > > remove sonic decoder from libavcodec. > > > > > > > > ok, if you plan to fix the bugs in the libswresample patches > > > > > > > > ill wait a bit, so others can object and if no objections will > > > > apply the current SDR patch with the probe function disabled. > > > > That ensures it will not be used without the user explicitly > > > > selecting it. > > > > > > I object to merging this patch. > > > > > > As numerous others have said already, this is at the wrong level of > > > abstraction, even if it happens to work for you for the current use case. > > > > > > Even if it is disabled by default, git master isn't a playground for > > > personal projects. > > > > If you belive this is implemented at the wrong level, > > can you please elaborately explain the implementation which is > > in your oppinion at the correct level ? > > As there are talks about receiving DAB/DVB from the same source, those would > definitely be on a different level than libavformat, since the output of > them would be an mpegts stream (or multiple), or whatever transport format > DAB uses. If i search for "mpegts" in libavformat i find hls, rtp, rtsp, segment, wtv but iam sure these arent the only mixed containers. If we look at DAB or DVB in a more fundamental way, they have no need for mpegts. Should this (apparently unneeded) design decission in DAB/DVB dictate design on our side when it has not previously ? If so, what design ? > As for purely AM/FM, I'm not quire sure what the right level for > that is though. > > In any case, I disagree with the procedure of stating to push the patch if > there's no objections, when there has been numerous objections from > essentially most of the active community already. The objections have been unclear, are they against SDR, against the implementation. I took the liberty to be pushy here to get this more clear. And i will continue to do this until i get clear responses. Because otherwise iam just stuck as i dont know how to correct the design and code. Thank you for clarifying the libavformat issue. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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 v6 0/1] avformat: add Software Defined Radio support
lör 2023-07-01 klockan 22:41 +0300 skrev Martin Storsjö: > On Sat, 1 Jul 2023, Michael Niedermayer wrote: > > > On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote: > > > On Fri, 30 Jun 2023, Michael Niedermayer wrote: > > > > > > > On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote: > > > > > If you apply this I will apply my pending libswresample > > > > > commits and also > > > > > remove sonic decoder from libavcodec. > > > > > > > > ok, if you plan to fix the bugs in the libswresample patches > > > > > > > > ill wait a bit, so others can object and if no objections will > > > > apply the current SDR patch with the probe function disabled. > > > > That ensures it will not be used without the user explicitly > > > > selecting it. > > > > > > I object to merging this patch. > > > > > > As numerous others have said already, this is at the wrong level > > > of > > > abstraction, even if it happens to work for you for the current > > > use case. > > > > > > Even if it is disabled by default, git master isn't a playground > > > for > > > personal projects. > > > > If you belive this is implemented at the wrong level, > > can you please elaborately explain the implementation which is > > in your oppinion at the correct level ? > > As there are talks about receiving DAB/DVB from the same source, > those > would definitely be on a different level than libavformat, since the > output of them would be an mpegts stream (or multiple), or whatever > transport format DAB uses. This is a good point that hadn't occurred to me. For DAB and DVB what you get is more akin to a protocol than a demux. But obviously considering a stream of analog values to be a protocol (in the lavf sense) would be stretching the concept in the extreme. The violation of the OSI stack here becomes very visible. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
On Sat, 1 Jul 2023, Michael Niedermayer wrote: On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote: On Fri, 30 Jun 2023, Michael Niedermayer wrote: On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote: If you apply this I will apply my pending libswresample commits and also remove sonic decoder from libavcodec. ok, if you plan to fix the bugs in the libswresample patches ill wait a bit, so others can object and if no objections will apply the current SDR patch with the probe function disabled. That ensures it will not be used without the user explicitly selecting it. I object to merging this patch. As numerous others have said already, this is at the wrong level of abstraction, even if it happens to work for you for the current use case. Even if it is disabled by default, git master isn't a playground for personal projects. If you belive this is implemented at the wrong level, can you please elaborately explain the implementation which is in your oppinion at the correct level ? As there are talks about receiving DAB/DVB from the same source, those would definitely be on a different level than libavformat, since the output of them would be an mpegts stream (or multiple), or whatever transport format DAB uses. As for purely AM/FM, I'm not quire sure what the right level for that is though. In any case, I disagree with the procedure of stating to push the patch if there's no objections, when there has been numerous objections from essentially most of the active community already. As for what you asked in another thread, whether the objection is personal and not related to content - I wholeheartedly disagree. I would have expected the same response to a similar patchset from anybody else. The amount of response only varies a bit depending on the position in the community of the person proposing the feature. A more senior community member has easier to push a feature forward than a less known community member. Thus, objections to such things also trigger more voices to show the widespread disagreement on the matter. > Even if it is disabled by default, git master isn't a playground for > personal projects. This is in no way intended as a "personal project" My point was that one can't use the argument of "let's merge it but keep it disabled for now, then you surely can't object to it", as a backdoor to merge disapproved things. // 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 v6 0/1] avformat: add Software Defined Radio support
On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote: [...] > Even if it is disabled by default, git master isn't a playground for > personal projects. This is in no way intended as a "personal project" (other parts replied to already) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato 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 v6 0/1] avformat: add Software Defined Radio support
On Sat, Jul 1, 2023 at 8:56 PM Michael Niedermayer wrote: > On Sat, Jul 01, 2023 at 06:28:03PM +0300, Rémi Denis-Courmont wrote: > > Hi, > > > > Le 30 juin 2023 21:02:36 GMT+03:00, Michael Niedermayer < > mich...@niedermayer.cc> a écrit : > > >On Fri, Jun 30, 2023 at 07:40:53PM +0200, Michael Niedermayer wrote: > > >> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > > >> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: > > >> > > Also as said previously, If there is at least a 2nd developer > working > > >> > > on this then we could & should move this to a seperate libraray > (libavradio) > > >> > > > >> > Why wait for a 2nd dev? > > >> > > >> It is significant work > > > > > >And if we could put it in git master then people could work together to > > >build the libavradio out of it as we all want. > > > > You can also achieve that by creating a separate git repo for libavradio > on git.ffmpeg.org. Admittedly some people could object to hosting this > code by FFmpeg; the point is that I don't see what good putting this inside > the FFmpeg master git branch achieves. > > > > >Such collaboration is kind of one of the reasons of having a "git > master" > > > > You're better off collaborating with people interested in this, than > with the entirety of FFmpeg-devel, me thinks. > > > > That's if this turns into a "Boring Serious Open-Source" project to > paraphrase a certain somebody else. If it remains just your hobby project, > you're probably better off doing it in your own git repository where you > can dictate everything. There you won't have to deal with the FFmpeg TC nor > pesky minders of other people's source code such as I. > > These are wise words. > The thing that i have difficulty getting into my head is how all these > fringe formats and codecs that most of us are not even able to find a > sample for. Let alone have ever used or ever will. > Do fit into FFmpeg while code to support the 2 most widespread analog > radio systems are off limits. > If you are not able to find sample or reference for some format or codec that does not mean there is no samples or people using that samples or reference for some codec. It just shows your huge lack of understanding of multimedia ecosystem. > > One can define that as transport and exclude it but that feels very > contrived. > Explain that to a child, FFmpeg supports all multimedia, that is audio and > video > BUT not that audio you listen here to in the car radio UNLESS you plug that > usb stick in (with an mp3 on it), then we support it. > > If FFmpeg is intending to support all of multimedia it should support > AM & FM audio by some means. > > i can put the input device and demuxer in libavradio with the same API as > currently and put that in a seperate directory or repository. > It seems a technically not thought through decission though. It simply > adds extra work to maintain it. > > the reason why iam pushy is that i belive the FFmpeg users would want this > feature. If i give in and dump it into my github repo, chances are 99% of > users will not have access to this feature as it likely wont get included > in most distributions > > theres nothing i gain from this feature going into git master. I just > think radio support _does_ belong into FFmpeg. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > He who knows, does not speak. He who speaks, does not know. -- Lao Tsu > ___ > 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 v6 0/1] avformat: add Software Defined Radio support
Quoting Martin Storsjö (2023-06-30 23:36:06) > I object to merging this patch. > > As numerous others have said already, this is at the wrong level of > abstraction, even if it happens to work for you for the current use case. > > Even if it is disabled by default, git master isn't a playground for > personal projects. +1 -- 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] configure: use just the pkg-config for sndio
On 2023-06-23 7:36 p.m., Brad Smith wrote: On 2023-06-23 7:35 p.m., Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:56:30PM -0400, Brad Smith wrote: On 2023-06-23 6:55 p.m., Michael Niedermayer wrote: On Fri, Jun 23, 2023 at 06:41:08PM -0400, Brad Smith wrote: ping. On 2023-06-17 6:48 p.m., Brad Smith wrote: On Sun, Jun 18, 2023 at 12:01:14AM +0200, Michael Niedermayer wrote: this breaks a plain configure here on ubuntu ./configure ERROR: sndio not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat. Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus This is what I had intended. You intended to break a plain ./configure on ubuntu ? If so i think we better dont apply that patch :) thx No, there was a second patch there. oops i missed that, the 2nd patch works fine on ubuntu no objections from me thx ping. ___ 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 v6 0/1] avformat: add Software Defined Radio support
On Sat, Jul 01, 2023 at 06:28:03PM +0300, Rémi Denis-Courmont wrote: > Hi, > > Le 30 juin 2023 21:02:36 GMT+03:00, Michael Niedermayer > a écrit : > >On Fri, Jun 30, 2023 at 07:40:53PM +0200, Michael Niedermayer wrote: > >> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > >> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: > >> > > Also as said previously, If there is at least a 2nd developer working > >> > > on this then we could & should move this to a seperate libraray > >> > > (libavradio) > >> > > >> > Why wait for a 2nd dev? > >> > >> It is significant work > > > >And if we could put it in git master then people could work together to > >build the libavradio out of it as we all want. > > You can also achieve that by creating a separate git repo for libavradio on > git.ffmpeg.org. Admittedly some people could object to hosting this code by > FFmpeg; the point is that I don't see what good putting this inside the > FFmpeg master git branch achieves. > > >Such collaboration is kind of one of the reasons of having a "git master" > > You're better off collaborating with people interested in this, than with the > entirety of FFmpeg-devel, me thinks. > > That's if this turns into a "Boring Serious Open-Source" project to > paraphrase a certain somebody else. If it remains just your hobby project, > you're probably better off doing it in your own git repository where you can > dictate everything. There you won't have to deal with the FFmpeg TC nor pesky > minders of other people's source code such as I. These are wise words. The thing that i have difficulty getting into my head is how all these fringe formats and codecs that most of us are not even able to find a sample for. Let alone have ever used or ever will. Do fit into FFmpeg while code to support the 2 most widespread analog radio systems are off limits. One can define that as transport and exclude it but that feels very contrived. Explain that to a child, FFmpeg supports all multimedia, that is audio and video BUT not that audio you listen here to in the car radio UNLESS you plug that usb stick in (with an mp3 on it), then we support it. If FFmpeg is intending to support all of multimedia it should support AM & FM audio by some means. i can put the input device and demuxer in libavradio with the same API as currently and put that in a seperate directory or repository. It seems a technically not thought through decission though. It simply adds extra work to maintain it. the reason why iam pushy is that i belive the FFmpeg users would want this feature. If i give in and dump it into my github repo, chances are 99% of users will not have access to this feature as it likely wont get included in most distributions theres nothing i gain from this feature going into git master. I just think radio support _does_ belong into FFmpeg. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu 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 v6 0/1] avformat: add Software Defined Radio support
Hi, Le 30 juin 2023 21:02:36 GMT+03:00, Michael Niedermayer a écrit : >On Fri, Jun 30, 2023 at 07:40:53PM +0200, Michael Niedermayer wrote: >> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: >> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: >> > > Also as said previously, If there is at least a 2nd developer working >> > > on this then we could & should move this to a seperate libraray >> > > (libavradio) >> > >> > Why wait for a 2nd dev? >> >> It is significant work > >And if we could put it in git master then people could work together to >build the libavradio out of it as we all want. You can also achieve that by creating a separate git repo for libavradio on git.ffmpeg.org. Admittedly some people could object to hosting this code by FFmpeg; the point is that I don't see what good putting this inside the FFmpeg master git branch achieves. >Such collaboration is kind of one of the reasons of having a "git master" You're better off collaborating with people interested in this, than with the entirety of FFmpeg-devel, me thinks. That's if this turns into a "Boring Serious Open-Source" project to paraphrase a certain somebody else. If it remains just your hobby project, you're probably better off doing it in your own git repository where you can dictate everything. There you won't have to deal with the FFmpeg TC nor pesky minders of other people's source code such as I. >If i cannot apply the patches but have to do very deep redesigns then >it forces me to do all this work alone. That would affect other things >i would otherwise work on. >IMHO its better if everyone can collaborate on this libavradio project >if everyone wants it. That reasoning only makes sense if a sizable subset of FFmpeg people, and even then it would probably fit better in a separate git repository of the same organisation, than in the same git repository. ___ 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 v6 0/1] avformat: add Software Defined Radio support
On Fri, Jun 30, 2023 at 06:00:18PM +0100, Kieran Kunhya wrote: > On Fri, 30 Jun 2023 at 15:08, Michael Niedermayer > wrote: > > > On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote: > > > If you apply this I will apply my pending libswresample commits and also > > > remove sonic decoder from libavcodec. > > > > ok, if you plan to fix the bugs in the libswresample patches > > > > ill wait a bit, so others can object and if no objections will > > apply the current SDR patch with the probe function disabled. > > That ensures it will not be used without the user explicitly > > selecting it. > > > > There's clearly a substantial objection to you putting this main FFmpeg. yes, there is substantial objection to ME putting THIS in main FFmpeg. So someone else can ? Or this is a review of a submited patch ? It may seem a silly detail but lets keep this at a technical level and not slip towards people. So what really are the objection from reviewers about ? Me ? ill politely disregard these kind of objections SDR in general? Ill bring this to a vote if such objections remain. Iam just hesitant as i dont want to annoy people with votes unneccessarily If the community decides SDR is off limits for FFmpeg then this should be a universal decission. The specific implementation ? If so I again ask politely for as detailed as possible information on how the implementation should look. Also iam curious if the reviewer intends to use the SDR feature or if he wants to contribute Thank you [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin 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 2/2] avcodec/cbs_h266: store RowHeightVal in the context
On Sat, Jul 1, 2023 at 9:37 AM James Almer wrote:
> Stop overwriting values from the bitstream array
> pps_tile_row_height_minus1.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h266_syntax_template.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index ec2bb1ccc3..625995a2bd 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -1779,14 +1779,14 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> "Tile row height(%d) exceeds picture height\n",i);
>return AVERROR_INVALIDDATA;
>}
> + current->row_height_val[i] =
> current->pps_tile_row_height_minus1[i] + 1;
>remaining_size -= (current->pps_tile_row_height_minus1[i] + 1);
> }
> -unified_size = (i == 0 ? pic_height_in_ctbs_y :
> -(current->pps_tile_row_height_minus1[i - 1] + 1));
> +unified_size = current->pps_tile_row_height_minus1[i - 1] + 1;
>
> while (remaining_size > 0) {
> unified_size = FFMIN(remaining_size, unified_size);
> -current->pps_tile_row_height_minus1[i] = unified_size - 1;
> +current->row_height_val[i] = unified_size;
> remaining_size -= unified_size;
> i++;
> }
> @@ -1855,17 +1855,17 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> ctu_x += current->pps_tile_column_width_minus1[j] + 1;
> }
> for (j = 0; j < tile_y; j++) {
> -ctu_y += current->pps_tile_row_height_minus1[j] + 1;
> +ctu_y += current->row_height_val[j];
> }
> if (current->pps_slice_width_in_tiles_minus1[i] == 0 &&
> current->pps_slice_height_in_tiles_minus1[i] == 0 &&
> -current->pps_tile_row_height_minus1[tile_y] > 0) {
> +current->row_height_val[tile_y] > 1) {
> int num_slices_in_tile,
> uniform_slice_height, remaining_height_in_ctbs_y;
> remaining_height_in_ctbs_y =
> -current->pps_tile_row_height_minus1[tile_y] + 1;
> +current->row_height_val[tile_y];
> ues(pps_num_exp_slices_in_tile[i],
> -0, current->pps_tile_row_height_minus1[tile_y],
> 1, i);
> +0, current->row_height_val[tile_y] - 1, 1, i);
> if (current->pps_num_exp_slices_in_tile[i] == 0) {
> num_slices_in_tile = 1;
> slice_top_left_ctu_x[i] = ctu_x;
> @@ -1875,7 +1875,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> for (j = 0; j <
> current->pps_num_exp_slices_in_tile[i];
> j++) {
>
> ues(pps_exp_slice_height_in_ctus_minus1[i][j], 0,
> -
> current->pps_tile_row_height_minus1[tile_y], 2,
> +current->row_height_val[tile_y] - 1, 2,
>
The benefit is not so obvious when we need to -1 in multiple places.
> i, j);
> slice_height_in_ctus =
> current->
> @@ -1890,7 +1890,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> remaining_height_in_ctbs_y -=
> slice_height_in_ctus;
> }
> uniform_slice_height = 1 +
> -(j == 0 ?
> current->pps_tile_row_height_minus1[tile_y] :
> +(j == 0 ? current->row_height_val[tile_y] - 1:
>
> current->pps_exp_slice_height_in_ctus_minus1[i][j-1]);
> while (remaining_height_in_ctbs_y >
> uniform_slice_height) {
> current->slice_height_in_ctus[i + j] =
> @@ -1919,7 +1919,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> j <=
> current->pps_slice_height_in_tiles_minus1[i];
> j++) {
> height +=
> - current->pps_tile_row_height_minus1[tile_y +
> j] + 1;
> + current->row_height_val[tile_y + j];
> }
> current->slice_height_in_ctus[i] = height;
>
> @@ -1959,7 +1959,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> ctu_x += current->pps_tile_column_width_minus1[j] + 1;
> }
> for (j = 0; j < tile_y; j++) {
> -ctu_y += current->pps_tile_row_height_minus1[j] + 1;
> +ctu_y += current->row_height_val[j];
>
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_h266: store SubpicIdVal in the context
On Sat, Jul 1, 2023 at 9:37 AM James Almer wrote:
> And use it to derive CurrSubpicIdx
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h266.h | 2 ++
> libavcodec/cbs_h266_syntax_template.c | 34 +--
> 2 files changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
> index be3c744426..edcb5ad0e3 100644
> --- a/libavcodec/cbs_h266.h
> +++ b/libavcodec/cbs_h266.h
> @@ -552,6 +552,8 @@ typedef struct H266RawPPS {
> uint16_t num_tiles_in_pic;
> uint16_t slice_height_in_ctus[VVC_MAX_SLICES];
> uint16_t num_slices_in_subpic[VVC_MAX_SLICES];
> +uint16_t sub_pic_id_val[VVC_MAX_SLICES];
> +uint16_t row_height_val[VVC_MAX_TILE_ROWS];
>
row_height_val is not related to this patch. Other things are ok.
> } H266RawPPS;
>
> typedef struct H266RawAUD {
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index 863fecdefa..ec2bb1ccc3 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -1706,6 +1706,15 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> }
> }
>
> +for (i = 0; i <= sps->sps_num_subpics_minus1; i++) {
> +if (sps->sps_subpic_id_mapping_explicitly_signalled_flag)
> +current->sub_pic_id_val[i] =
> current->pps_subpic_id_mapping_present_flag
> + ? current->pps_subpic_id[i]
> + : sps->sps_subpic_id[i];
> +else
> +current->sub_pic_id_val[i] = i;
> +}
> +
> pic_width_in_ctbs_y = AV_CEIL_RSHIFT
> (current->pps_pic_width_in_luma_samples,
> (sps->sps_log2_ctu_size_minus5 + 5));
> pic_height_in_ctbs_y = AV_CEIL_RSHIFT(
> @@ -2697,25 +2706,16 @@ static int FUNC(slice_header)
> (CodedBitstreamContext *ctx, RWContext *rw,
>
> if (sps->sps_subpic_info_present_flag) {
> ub(sps->sps_subpic_id_len_minus1 + 1, sh_subpic_id);
> -if (sps->sps_subpic_id_mapping_explicitly_signalled_flag) {
> -for (i = 0; i <= sps->sps_num_subpics_minus1; i++) {
> -uint16_t subpic_id_val =
> -pps->pps_subpic_id_mapping_present_flag ?
> -pps->pps_subpic_id[i] : sps->sps_subpic_id[i];
> -if (subpic_id_val == current->sh_subpic_id) {
> -curr_subpic_idx = i;
> -break;
> -}
> -}
> -} else {
> -curr_subpic_idx = current->sh_subpic_id;
> -if (curr_subpic_idx > sps->sps_num_subpics_minus1) {
> -av_log(ctx->log_ctx, AV_LOG_ERROR,
> - "sh_subpic_id(%d) should in range [0, %d]\n",
> - curr_subpic_idx, sps->sps_num_subpics_minus1);
> -return AVERROR_INVALIDDATA;
> +for (i = 0; i <= sps->sps_num_subpics_minus1; i++) {
> +if (pps->sub_pic_id_val[i] == current->sh_subpic_id) {
> +curr_subpic_idx = i;
> +break;
> }
> }
> +if (i > sps->sps_num_subpics_minus1) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "invalid CurrSubpicIdx
> %d\n", i);
> +return AVERROR_INVALIDDATA;
> +}
> } else {
> curr_subpic_idx = 0;
> }
> --
> 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 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 v6 0/1] avformat: add Software Defined Radio support
Hi Martin On Sat, Jul 01, 2023 at 12:36:06AM +0300, Martin Storsjö wrote: > On Fri, 30 Jun 2023, Michael Niedermayer wrote: > > > On Thu, Jun 29, 2023 at 05:43:53PM +0200, Paul B Mahol wrote: > > > If you apply this I will apply my pending libswresample commits and also > > > remove sonic decoder from libavcodec. > > > > ok, if you plan to fix the bugs in the libswresample patches > > > > ill wait a bit, so others can object and if no objections will > > apply the current SDR patch with the probe function disabled. > > That ensures it will not be used without the user explicitly > > selecting it. > > I object to merging this patch. > > As numerous others have said already, this is at the wrong level of > abstraction, even if it happens to work for you for the current use case. > > Even if it is disabled by default, git master isn't a playground for > personal projects. If you belive this is implemented at the wrong level, can you please elaborately explain the implementation which is in your oppinion at the correct level ? Thank you [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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 3/3] avcodec/cbs_h266_syntax_template: Avoid shadowing
On Sat, Jul 1, 2023 at 6:07 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/cbs_h266_syntax_template.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index a329b7f9ed..646cd94413 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -514,9 +514,9 @@ static int FUNC(ref_pic_lists) (CodedBitstreamContext
> *ctx, RWContext *rw,
> ref_list = ¤t->rpl_ref_list[i];
>
> num_ltrp_entries = 0;
> -for (int i = 0; i < ref_list->num_ref_entries; i++) {
> -if (!ref_list->inter_layer_ref_pic_flag[i]) {
> -if (!ref_list->st_ref_pic_flag[i]) {
> +for (int k = 0; k < ref_list->num_ref_entries; k++) {
> +if (!ref_list->inter_layer_ref_pic_flag[k]) {
> +if (!ref_list->st_ref_pic_flag[k]) {
> num_ltrp_entries++;
> }
> }
> --
> 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".
>
:) LGTM
___
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/2] avcodec/cbs_h266_syntax_template: Remove set-but-unused variable
On Sat, Jul 1, 2023 at 5:33 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Reported by Clang.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Maybe this was meant to be used?
>
> libavcodec/cbs_h266_syntax_template.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index 56e1205337..a329b7f9ed 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -1711,7 +1711,7 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> pic_height_in_ctbs_y = AV_CEIL_RSHIFT(
>
> current->pps_pic_height_in_luma_samples,(sps->sps_log2_ctu_size_minus5 +
> 5));
> if (!current->pps_no_pic_partition_flag) {
> -unsigned int exp_tile_width = 0, exp_tile_height = 0;
> +unsigned int exp_tile_width = 0;
> unsigned int unified_size, remaining_size;
>
> u(2, pps_log2_ctu_size_minus5,
> @@ -1729,7 +1729,6 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
> RWContext *rw,
> for (i = 0; i <= current->pps_num_exp_tile_rows_minus1; i++) {
> ues(pps_tile_row_height_minus1[i],
> 0, pic_height_in_ctbs_y - 1, 1, i);
> -exp_tile_height += current->pps_tile_row_height_minus1[i] + 1;
> }
>
> remaining_size = pic_width_in_ctbs_y;
>
The original patch
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274535.html is
"remaining_size
= pic_height_in_ctbs_y - exp_tile_height;"
Not sure we removed exp_tile_height.
--
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_h266_syntax_template: Don't use uninitialized value
On Sat, Jul 1, 2023 at 5:31 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Probably a typo. Fixes a warning from Clang. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/cbs_h266_syntax_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_h266_syntax_template.c > b/libavcodec/cbs_h266_syntax_template.c > index 863fecdefa..56e1205337 100644 > --- a/libavcodec/cbs_h266_syntax_template.c > +++ b/libavcodec/cbs_h266_syntax_template.c > @@ -1059,7 +1059,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, > RWContext *rw, > if (current->sps_pic_width_max_in_luma_samples > ctb_size_y) > ubs(wlen, sps_subpic_width_minus1[0], 1, 0); > else > -infer(sps_subpic_width_minus1[i], tmp_width_val - 1); > +infer(sps_subpic_width_minus1[0], tmp_width_val - 1); > if (current->sps_pic_height_max_in_luma_samples > ctb_size_y) > ubs(hlen, sps_subpic_height_minus1[0], 1, 0); > else > -- > 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". LGTM. It's a typo, fixed at https://github.com/ffvvc/FFmpeg/blob/cd27af258d2832706b6831cc3840dd69ddeeb4b5/libavcodec/cbs_h266_syntax_template.c#L1063 It may have some other misc fixes. I will send them out later. ___ 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] Adapted to the latest JPEG XL library version 0.9.0
On 2023-07-01 06:54 pm, Peter Kovář wrote: Signed-off-by: Peter Kovář --- libavcodec/libjxldec.c | 17 + 1 file changed, 17 insertions(+) diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c index 50417bcb02..bfff60769c 100644 --- a/libavcodec/libjxldec.c +++ b/libavcodec/libjxldec.c @@ -210,14 +210,23 @@ static int libjxl_get_icc(AVCodecContext *avctx) JxlDecoderStatus jret; /* an ICC profile is present, and we can meaningfully get it, * because the pixel data is not XYB-encoded */ +#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0) 0.9.0 is still unreleased and unfortunately the API change wasn't accompanied with a version bump. The API changes were pushed on Jun 21st and the version bump to 0.9.0 was pushed on Jan 12th. So this will still break compilation with older git checkouts of libjxl. Ideally libjxl should bump once more to 0.9.1 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Adapted to the latest JPEG XL library version 0.9.0
Signed-off-by: Peter Kovář
---
libavcodec/libjxldec.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 50417bcb02..bfff60769c 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -210,14 +210,23 @@ static int libjxl_get_icc(AVCodecContext *avctx)
JxlDecoderStatus jret;
/* an ICC profile is present, and we can meaningfully get it,
* because the pixel data is not XYB-encoded */
+#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0)
jret = JxlDecoderGetICCProfileSize(ctx->decoder, &ctx->jxl_pixfmt,
JXL_COLOR_PROFILE_TARGET_DATA, &icc_len);
+#else
+jret = JxlDecoderGetICCProfileSize(ctx->decoder,
JXL_COLOR_PROFILE_TARGET_DATA, &icc_len);
+#endif
if (jret == JXL_DEC_SUCCESS && icc_len > 0) {
av_buffer_unref(&ctx->iccp);
ctx->iccp = av_buffer_alloc(icc_len);
if (!ctx->iccp)
return AVERROR(ENOMEM);
+#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0)
jret = JxlDecoderGetColorAsICCProfile(ctx->decoder,
&ctx->jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_DATA,
ctx->iccp->data, icc_len);
+#else
+jret = JxlDecoderGetColorAsICCProfile(ctx->decoder,
JXL_COLOR_PROFILE_TARGET_DATA,
+ctx->iccp->data, icc_len);
+#endif
if (jret != JXL_DEC_SUCCESS) {
av_log(avctx, AV_LOG_WARNING, "Unable to obtain ICC
Profile\n");
av_buffer_unref(&ctx->iccp);
@@ -253,12 +262,20 @@ static int
libjxl_color_encoding_event(AVCodecContext *avctx, AVFrame *frame)
/* set this flag if we need to fall back on wide gamut */
int fallback = 0;
+#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0)
jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder, NULL,
JXL_COLOR_PROFILE_TARGET_ORIGINAL, &jxl_color);
+#else
+jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder,
JXL_COLOR_PROFILE_TARGET_ORIGINAL, &jxl_color);
+#endif
if (jret == JXL_DEC_SUCCESS) {
/* enum values describe the colors of this image */
jret = JxlDecoderSetPreferredColorProfile(ctx->decoder,
&jxl_color);
if (jret == JXL_DEC_SUCCESS)
+#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0)
jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder,
&ctx->jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_DATA, &jxl_color);
+#else
+jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder,
JXL_COLOR_PROFILE_TARGET_DATA, &jxl_color);
+#endif
/* if we couldn't successfully request the pixel data space,
we fall back on wide gamut */
/* this code path is very unlikely to happen in practice */
if (jret != JXL_DEC_SUCCESS)
--
2.41.0
OpenPGP_0x60C29844F4628AE1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital 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 3/4] avfilter/vf_ccrepack: Constify filter
Le 29 juin 2023 22:42:17 GMT+03:00, Paul B Mahol a écrit : >On Thu, Jun 29, 2023 at 9:35 PM Andreas Rheinhardt < >andreas.rheinha...@outlook.com> wrote: > >> Paul B Mahol: >> > On Thu, Jun 29, 2023 at 8:18 PM Andreas Rheinhardt < >> > andreas.rheinha...@outlook.com> wrote: >> > >> >> The discrepancy between the definition and the declaration >> >> in allfilters.c is actually UB. >> >> >> > >> > I get no such message with ubsan. >> > >> >> UBSan is a runtime UB-detector, not a compile-time UB detector. >> The earlier code is UB because of 6.2.7 (2) of C11: "All declarations >> that refer to the same object or function shall have compatible type; >> otherwise, the behavior is undefined." A type and its const-qualified >> type are not compatible. >> > >This is so minor, that it is fully irrelevant. UB is one of the most severe type of bug that can happen in C. How exactly is that "fully irrelevant"? Nobody is ordering you to fix this bug if you don't want to. That's not a reason to block an objective simple well-understood and well-informed bug fix that somebody else made. > > >> >> - 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 v2 1/2] avcodec/cbs_h2645: fix parsing and storing Picture Header references in the context
On Fri, Jun 30, 2023 at 6:45 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h2645.c| 35 ---
> libavcodec/cbs_h266.h | 17 +++--
> libavcodec/cbs_h266_syntax_template.c | 17 ++---
> libavcodec/h266_metadata_bsf.c| 13 +-
> libavcodec/vvc_parser.c | 10
> 5 files changed, 50 insertions(+), 42 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index cdd7901518..68ccf6a7eb 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -525,12 +525,6 @@ static int
> cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
> if (frag->data_size == 0)
> return 0;
>
> -if (codec_id == AV_CODEC_ID_VVC) {
> -//we deactive picture header here to avoid reuse previous au's ph.
> -CodedBitstreamH266Context *h266 = ctx->priv_data;
> -h266->priv.ph = NULL;
> -}
> -
> if (header && frag->data[0] && codec_id == AV_CODEC_ID_H264) {
> // AVCC header.
> size_t size, start, end;
> @@ -793,19 +787,20 @@ cbs_h266_replace_ps(6, SPS, sps,
> sps_seq_parameter_set_id)
> cbs_h266_replace_ps(6, PPS, pps, pps_pic_parameter_set_id)
>
> static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
> - CodedBitstreamUnit *unit)
> + CodedBitstreamUnit *unit,
> + H266RawPictureHeader *ph)
> {
> CodedBitstreamH266Context *h266 = ctx->priv_data;
> int err;
>
> -h266->priv.ph = NULL;
> err = ff_cbs_make_unit_refcounted(ctx, unit);
> if (err < 0)
> return err;
> -err = av_buffer_replace(&h266->priv.ph_ref, unit->content_ref);
> +av_assert0(unit->content_ref);
> +err = av_buffer_replace(&h266->ph_ref, unit->content_ref);
> if (err < 0)
> return err;
> -h266->priv.ph = (H266RawPH*)h266->priv.ph_ref->data;
> +h266->ph = ph;
> return 0;
> }
>
> @@ -,7 +1106,7 @@ static int
> cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
> err = cbs_h266_read_ph(ctx, &gbc, ph);
> if (err < 0)
> return err;
> -err = cbs_h266_replace_ph(ctx, unit);
> +err = cbs_h266_replace_ph(ctx, unit, &ph->ph_picture_header);
> if (err < 0)
> return err;
> }
> @@ -1139,6 +1134,12 @@ static int
> cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
> pos = get_bits_count(&gbc);
> len = unit->data_size;
>
> +if (slice->header.sh_picture_header_in_slice_header_flag) {
> +err = cbs_h266_replace_ph(ctx, unit,
> &slice->header.sh_picture_header);
> +if (err < 0)
> +return err;
> +}
> +
> slice->data_size = len - pos / 8;
> slice->data_ref = av_buffer_ref(unit->data_ref);
> if (!slice->data_ref)
> @@ -1640,7 +1641,7 @@ static int
> cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
> if (err < 0)
> return err;
>
> -err = cbs_h266_replace_ph(ctx, unit);
> +err = cbs_h266_replace_ph(ctx, unit, &ph->ph_picture_header);
> if (err < 0)
> return err;
> }
> @@ -1661,6 +1662,12 @@ static int
> cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
> if (err < 0)
> return err;
>
> +if (slice->header.sh_picture_header_in_slice_header_flag) {
> +err = cbs_h266_replace_ph(ctx, unit,
> &slice->header.sh_picture_header);
> +if (err < 0)
> +return err;
> +}
> +
> if (slice->data) {
> err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
> slice->data_size,
> @@ -1884,8 +1891,8 @@ static void cbs_h266_flush(CodedBitstreamContext
> *ctx)
> av_buffer_unref(&h266->pps_ref[i]);
> h266->pps[i] = NULL;
> }
> -av_buffer_unref(&h266->priv.ph_ref);
> -h266->priv.ph = NULL;
> +av_buffer_unref(&h266->ph_ref);
> +h266->ph = NULL;
> }
>
> static void cbs_h266_close(CodedBitstreamContext *ctx)
> diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
> index 03dfd4a954..54590748c3 100644
> --- a/libavcodec/cbs_h266.h
> +++ b/libavcodec/cbs_h266.h
> @@ -581,8 +581,7 @@ typedef struct H266RawPredWeightTable {
> int16_t delta_chroma_offset_l1[15][2];
> } H266RawPredWeightTable;
>
> -typedef struct H266RawPH {
> -H266RawNALUnitHeader nal_unit_header;
> +typedef struct H266RawPictureHeader {
> uint8_t ph_gdr_or_irap_pic_flag;
> uint8_t ph_non_ref_pic_flag;
> uint8_t ph_gdr_pic_flag;
> @@ -670,12 +669,17 @@ typedef struct H266RawPH {
>
> uint8_t ph_extension_length;
> uint8_t ph_extension_data_byte[256];
> +} H
Re: [FFmpeg-devel] [PATCH v7 00/11] Add support for H266/VVC
On Fri, Jun 30, 2023 at 1:39 AM James Almer wrote: > On 3/21/2023 12:01 PM, Thomas Siedel wrote: > > This patch set adds H266/VVC support. > > This includes parsing, muxing, demuxing, decoding and encoding. > > Decoding is done using the external library VVdeC > > (https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with > > --enable-libvvdec. > > Encoding is done using the external library VVenC > > (https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with > > --enable-libvvenc. > > > > For conformance testing, the following JVET bitstreams can be used: > > > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/ > > DVB test streams can be found here: > > https://dvb.org/specifications/verification-validation/vvc-test-content/ > > All JVET conformance bitstreams that are supported by VVdeC can be > decoded. > > Pallete mode and multi-layer streams are unsupported. > > The DVB MP4 and TS reference files can be decoded as well. > > I have pushed patches 1 to 6, and the raw muxer part of 7. Will look at > the ISOBMFF and ts stuff better later, as well as the encoder wrapper. > ___ > 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". > Great! Really appreciate it. I'll send the native decoder v2 very soon. ___ 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] Optimization: support for libx264's mb_info
Sorry to still nag you, but I just noticed that unlike video_enc_params, you do not store AVVideoRect size in AVVideoHint. This means that no new fields can be added to AVVideoRect without an ABI break. This seems suboptimal, since I do see potential use for per-block information. -- 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 v2 0/7] Misc AFD improvements and support for Bar Data
IIUC the only source of bar data after this set is the new filter you're adding. Is there supposed to be some other demuxer or decoder that produces it? Also, FATE tests would be much appreciated. -- 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 v2 3/7] avcodec/avframe: add new side data types for Bar Data
Quoting Devin Heitmueller (2023-06-30 23:38:51)
> Add new side data types for both AVPacket and AVFrame to support
> "bar data" as defined in SMPTE 2016-1, ATSC A/53, and SCTE 128-1.
>
> Signed-off-by: Devin Heitmueller
> ---
> libavcodec/decode.c | 1 +
> libavcodec/defs.h | 12
> libavcodec/packet.h | 6 ++
> libavutil/frame.h | 6 ++
> 4 files changed, 25 insertions(+)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6ee2c85..5aafce7 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1332,6 +1332,7 @@ int ff_decode_frame_props_from_pkt(const AVCodecContext
> *avctx,
> { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
> { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
> { AV_PKT_DATA_AFD,AV_FRAME_DATA_AFD },
> +{ AV_PKT_DATA_BARDATA,AV_FRAME_DATA_BARDATA },
> { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE
> },
> { AV_PKT_DATA_S12M_TIMECODE,
> AV_FRAME_DATA_S12M_TIMECODE },
> { AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
> AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
> diff --git a/libavcodec/defs.h b/libavcodec/defs.h
> index fbe3254..deadfe7 100644
> --- a/libavcodec/defs.h
> +++ b/libavcodec/defs.h
> @@ -119,6 +119,18 @@ typedef struct AVPanScan {
> } AVPanScan;
>
> /**
> + * Bar data - used by side data for avcodec and avframe. Defines the
> location
> + * of horizontal or vertical black bars (i.e. letterbox/pillar bars)
> + */
> +typedef struct AVBarData {
> +int top_bottom; /* 0=top/bottom 1=left/right */
> +int top;
> +int left;
> +int bottom;
> +int right;
Am I understanding correctly that half of these are never used for a
given AVBarData instance? Seems wasteful. Could make it a generic
bound0, bound1 or a union instead.
--
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".
