* [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. @ 2025-04-24 3:38 jiangjie 2025-04-24 4:19 ` Zhao Zhili 2025-04-24 12:42 ` jiangjie 0 siblings, 2 replies; 11+ messages in thread From: jiangjie @ 2025-04-24 3:38 UTC (permalink / raw) To: ffmpeg-devel; +Cc: jiangjie618 if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will return an error. ffmpeg -i rtmp://xxx/live/xxx -bsf:v "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - --- libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/libavcodec/bsf/h264_mp4toannexb.c b/libavcodec/bsf/h264_mp4toannexb.c index dda064287e..4cd002d166 100644 --- a/libavcodec/bsf/h264_mp4toannexb.c +++ b/libavcodec/bsf/h264_mp4toannexb.c @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext *s, return 0; } +static int is_annexb(const uint8_t *extradata, int extra_size) { + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || + (extra_size >= 4 && AV_RB32(extradata) == 1)) { + return 1; + } else { + return 0; + } +} + static int h264_mp4toannexb_init(AVBSFContext *ctx) { int extra_size = ctx->par_in->extradata_size; /* retrieve sps and pps NAL units from extradata */ - if (!extra_size || - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { + if (is_annexb(ctx->par_in->extradata, extra_size)) { av_log(ctx, AV_LOG_VERBOSE, "The input looks like it is Annex B already\n"); } else if (extra_size >= 7) { @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *opkt) extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, &extradata_size); if (extradata) { - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); - if (ret < 0) - goto fail; + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) { + ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); + if (ret < 0) + goto fail; + av_packet_side_data_remove(in->side_data, &in->side_data_elems, + AV_PKT_DATA_NEW_EXTRADATA); + av_packet_add_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, + ctx->par_out->extradata, + ctx->par_out->extradata_size); + } } /* nothing to filter */ -- 2.49.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 3:38 [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc jiangjie @ 2025-04-24 4:19 ` Zhao Zhili 2025-04-24 5:18 ` jie jiang 2025-04-24 12:42 ` jiangjie 1 sibling, 1 reply; 11+ messages in thread From: Zhao Zhili @ 2025-04-24 4:19 UTC (permalink / raw) To: FFmpeg development discussions and patches; +Cc: jiangjie618 > On Apr 24, 2025, at 11:38, jiangjie <jiangjie618@gmail.com> wrote: > > if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will return an error. > ffmpeg -i rtmp://xxx/live/xxx -bsf:v "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - H.264 in FLV is avcc. Which service provider use annexb in FLV? And I don’t think it makes sense to use AV_PKT_DATA_NEW_EXTRADATA together with annexb. > --- > libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++++++++------ > 1 file changed, 20 insertions(+), 6 deletions(-) > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c b/libavcodec/bsf/h264_mp4toannexb.c > index dda064287e..4cd002d166 100644 > --- a/libavcodec/bsf/h264_mp4toannexb.c > +++ b/libavcodec/bsf/h264_mp4toannexb.c > @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext *s, > return 0; > } > > +static int is_annexb(const uint8_t *extradata, int extra_size) { > + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > + return 1; > + } else { > + return 0; > + } > +} > + > static int h264_mp4toannexb_init(AVBSFContext *ctx) > { > int extra_size = ctx->par_in->extradata_size; > > /* retrieve sps and pps NAL units from extradata */ > - if (!extra_size || > - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > + if (is_annexb(ctx->par_in->extradata, extra_size)) { > av_log(ctx, AV_LOG_VERBOSE, > "The input looks like it is Annex B already\n"); > } else if (extra_size >= 7) { > @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *opkt) > extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > &extradata_size); > if (extradata) { > - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > - if (ret < 0) > - goto fail; > + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) { > + ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > + if (ret < 0) > + goto fail; > + av_packet_side_data_remove(in->side_data, &in->side_data_elems, > + AV_PKT_DATA_NEW_EXTRADATA); > + av_packet_add_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > + ctx->par_out->extradata, > + ctx->par_out->extradata_size); > + } > } > > /* nothing to filter */ > -- > 2.49.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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 4:19 ` Zhao Zhili @ 2025-04-24 5:18 ` jie jiang 2025-04-24 6:41 ` Zhao Zhili 0 siblings, 1 reply; 11+ messages in thread From: jie jiang @ 2025-04-24 5:18 UTC (permalink / raw) To: Zhao Zhili; +Cc: FFmpeg development discussions and patches fmpeg -i rtmp://xxx/live/xxx -bsf:v "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - For h264_mp4toannexb, input 264 is avcc, output is annexb. and for h264_metadata, both input and output are annexb. If the sps/pps header is updated, flvdec module will insert AV_PKT_DATA_NEW_EXTRADATA to AVPacket and is this format of header is avcc. In cbs_bsf_update_side_data function, it will find AV_PKT_DATA_NEW_EXTRADATA and this extradata is avcc, that will cause h264_metadata to judge that its input is also avcc, but its input is from h264_mp4toannexb. Using the logic of parsing avcc to parse annexb is problematic. On Thu, Apr 24, 2025 at 12:19 PM Zhao Zhili <quinkblack@foxmail.com> wrote: > > > > On Apr 24, 2025, at 11:38, jiangjie <jiangjie618@gmail.com> wrote: > > > > if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will > return an error. > > ffmpeg -i rtmp://xxx/live/xxx -bsf:v > "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - > > H.264 in FLV is avcc. Which service provider use annexb in FLV? > > And I don’t think it makes sense to use AV_PKT_DATA_NEW_EXTRADATA together > with annexb. > > > --- > > libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++++++++------ > > 1 file changed, 20 insertions(+), 6 deletions(-) > > > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c > b/libavcodec/bsf/h264_mp4toannexb.c > > index dda064287e..4cd002d166 100644 > > --- a/libavcodec/bsf/h264_mp4toannexb.c > > +++ b/libavcodec/bsf/h264_mp4toannexb.c > > @@ -252,14 +252,21 @@ static int > h264_mp4toannexb_filter_ps(H264BSFContext *s, > > return 0; > > } > > > > +static int is_annexb(const uint8_t *extradata, int extra_size) { > > + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > > + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > > + return 1; > > + } else { > > + return 0; > > + } > > +} > > + > > static int h264_mp4toannexb_init(AVBSFContext *ctx) > > { > > int extra_size = ctx->par_in->extradata_size; > > > > /* retrieve sps and pps NAL units from extradata */ > > - if (!extra_size || > > - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > > - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > > + if (is_annexb(ctx->par_in->extradata, extra_size)) { > > av_log(ctx, AV_LOG_VERBOSE, > > "The input looks like it is Annex B already\n"); > > } else if (extra_size >= 7) { > > @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext > *ctx, AVPacket *opkt) > > extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > > &extradata_size); > > if (extradata) { > > - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > > - if (ret < 0) > > - goto fail; > > + if (!is_annexb(extradata, extradata_size) && extradata_size >= > 7) { > > + ret = h264_extradata_to_annexb(ctx, extradata, > extradata_size); > > + if (ret < 0) > > + goto fail; > > + av_packet_side_data_remove(in->side_data, > &in->side_data_elems, > > + AV_PKT_DATA_NEW_EXTRADATA); > > + av_packet_add_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > > + ctx->par_out->extradata, > > + ctx->par_out->extradata_size); > > + } > > } > > > > /* nothing to filter */ > > -- > > 2.49.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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 5:18 ` jie jiang @ 2025-04-24 6:41 ` Zhao Zhili 0 siblings, 0 replies; 11+ messages in thread From: Zhao Zhili @ 2025-04-24 6:41 UTC (permalink / raw) To: FFmpeg development discussions and patches > On Apr 24, 2025, at 13:18, jie jiang <jiangjie618@gmail.com> wrote: > > fmpeg -i rtmp://xxx/live/xxx -bsf:v > "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - > > For h264_mp4toannexb, input 264 is avcc, output is annexb. and for > h264_metadata, both input and output are annexb. > If the sps/pps header is updated, flvdec module will insert > AV_PKT_DATA_NEW_EXTRADATA to AVPacket and is this format of header is avcc. > In cbs_bsf_update_side_data function, it will find > AV_PKT_DATA_NEW_EXTRADATA and this extradata is avcc, that will cause > h264_metadata to judge that its input is also avcc, but its input is from > h264_mp4toannexb. Using the logic of parsing avcc to parse annexb is > problematic. > > So only remove AV_PKT_DATA_NEW_EXTRADATA can fix the issue? And the error is from bsf or decoder after h264_mp4toannexb, not h264_mp4toannexb itself, right? Please share a sample file and add a fate test. > > > On Thu, Apr 24, 2025 at 12:19 PM Zhao Zhili <quinkblack@foxmail.com> wrote: > >> >> >>> On Apr 24, 2025, at 11:38, jiangjie <jiangjie618@gmail.com> wrote: >>> >>> if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will >> return an error. >>> ffmpeg -i rtmp://xxx/live/xxx -bsf:v >> "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - >> >> H.264 in FLV is avcc. Which service provider use annexb in FLV? >> >> And I don’t think it makes sense to use AV_PKT_DATA_NEW_EXTRADATA together >> with annexb. >> >>> --- >>> libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++++++++------ >>> 1 file changed, 20 insertions(+), 6 deletions(-) >>> >>> diff --git a/libavcodec/bsf/h264_mp4toannexb.c >> b/libavcodec/bsf/h264_mp4toannexb.c >>> index dda064287e..4cd002d166 100644 >>> --- a/libavcodec/bsf/h264_mp4toannexb.c >>> +++ b/libavcodec/bsf/h264_mp4toannexb.c >>> @@ -252,14 +252,21 @@ static int >> h264_mp4toannexb_filter_ps(H264BSFContext *s, >>> return 0; >>> } >>> >>> +static int is_annexb(const uint8_t *extradata, int extra_size) { >>> + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || >>> + (extra_size >= 4 && AV_RB32(extradata) == 1)) { >>> + return 1; >>> + } else { >>> + return 0; >>> + } >>> +} >>> + >>> static int h264_mp4toannexb_init(AVBSFContext *ctx) >>> { >>> int extra_size = ctx->par_in->extradata_size; >>> >>> /* retrieve sps and pps NAL units from extradata */ >>> - if (!extra_size || >>> - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || >>> - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { >>> + if (is_annexb(ctx->par_in->extradata, extra_size)) { >>> av_log(ctx, AV_LOG_VERBOSE, >>> "The input looks like it is Annex B already\n"); >>> } else if (extra_size >= 7) { >>> @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext >> *ctx, AVPacket *opkt) >>> extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, >>> &extradata_size); >>> if (extradata) { >>> - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); >>> - if (ret < 0) >>> - goto fail; >>> + if (!is_annexb(extradata, extradata_size) && extradata_size >= >> 7) { >>> + ret = h264_extradata_to_annexb(ctx, extradata, >> extradata_size); >>> + if (ret < 0) >>> + goto fail; >>> + av_packet_side_data_remove(in->side_data, >> &in->side_data_elems, >>> + AV_PKT_DATA_NEW_EXTRADATA); >>> + av_packet_add_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, >>> + ctx->par_out->extradata, >>> + ctx->par_out->extradata_size); >>> + } >>> } >>> >>> /* nothing to filter */ >>> -- >>> 2.49.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-request@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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 3:38 [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc jiangjie 2025-04-24 4:19 ` Zhao Zhili @ 2025-04-24 12:42 ` jiangjie 2025-04-24 13:04 ` jie jiang 2025-04-24 14:20 ` Zhao Zhili 1 sibling, 2 replies; 11+ messages in thread From: jiangjie @ 2025-04-24 12:42 UTC (permalink / raw) To: ffmpeg-devel, quinkblack; +Cc: jiangjie618 if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will return an error. ffmpeg -i rtmp://xxx/live/xxx -bsf:v "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - --- libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- tests/fate/h264.mak | 3 +++ .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ 3 files changed, 35 insertions(+), 6 deletions(-) create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata diff --git a/libavcodec/bsf/h264_mp4toannexb.c b/libavcodec/bsf/h264_mp4toannexb.c index dda064287e..42a5a274bf 100644 --- a/libavcodec/bsf/h264_mp4toannexb.c +++ b/libavcodec/bsf/h264_mp4toannexb.c @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext *s, return 0; } +static int is_annexb(const uint8_t *extradata, int extra_size) { + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || + (extra_size >= 4 && AV_RB32(extradata) == 1)) { + return 1; + } else { + return 0; + } +} + static int h264_mp4toannexb_init(AVBSFContext *ctx) { int extra_size = ctx->par_in->extradata_size; /* retrieve sps and pps NAL units from extradata */ - if (!extra_size || - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { + if (is_annexb(ctx->par_in->extradata, extra_size)) { av_log(ctx, AV_LOG_VERBOSE, "The input looks like it is Annex B already\n"); } else if (extra_size >= 7) { @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *opkt) extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, &extradata_size); if (extradata) { - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); - if (ret < 0) - goto fail; + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) { + ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); + if (ret < 0) + goto fail; + av_packet_side_data_remove(in->side_data, &in->side_data_elems, + AV_PKT_DATA_NEW_EXTRADATA); + uint8_t *data = av_packet_new_side_data( + in, AV_PKT_DATA_NEW_EXTRADATA, ctx->par_out->extradata_size); + memcpy(data, ctx->par_out->extradata, ctx->par_out->extradata_size); + } } /* nothing to filter */ diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index 00b153cc93..7b3e865955 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to fate-h264-bsf-mp4toannexb-2 \ fate-h264_mp4toannexb_ticket5927 \ fate-h264_mp4toannexb_ticket5927_2 \ + fate-h264-bsf-mp4toannexb-h264_metadata \ FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: CMD = md5 -i $(TARGET_SAMPLES) fate-h264-bsf-mp4toannexb-2: CMP = oneline fate-h264-bsf-mp4toannexb-2: REF = cffcfa6a2d0b58c9de1f5785f099f41d fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ + h264 "-c:v copy -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" fate-h264-bsf-dts2pts: CMD = transcode "h264" $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ mov "-c:v copy -bsf:v dts2pts -frames:v 50" "-c:v copy" fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata new file mode 100644 index 0000000000..d3ba7f1886 --- /dev/null +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata @@ -0,0 +1,12 @@ +a48f175bf3458410d1dd1907682b92d3 *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 +#extradata 0: 38, 0x84d70914 +#tb 0: 1/1200000 +#media_type 0: video +#codec_id 0: h264 +#dimensions 0: 256x128 +#sar 0: 1/1 +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, F=0x0 +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, F=0x0 -- 2.49.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 12:42 ` jiangjie @ 2025-04-24 13:04 ` jie jiang 2025-04-24 14:03 ` Zhao Zhili 2025-04-24 14:20 ` Zhao Zhili 1 sibling, 1 reply; 11+ messages in thread From: jie jiang @ 2025-04-24 13:04 UTC (permalink / raw) To: ffmpeg-devel, quinkblack I resubmitted it according to your suggestion. please check. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250424124250.71553-1-jiangjie618@gmail.com/ So only remove AV_PKT_DATA_NEW_EXTRADATA can fix the issue? answer: yes, but AV_PKT_DATA_NEW_EXTRADATA is used for event notification, it is usefull. And the error is from bsf or decoder after h264_mp4toannexb, not h264_mp4toannexb itself, right? answer: yes i think AV_PKT_DATA_NEW_EXTRADATA and output stream should be the same format, both avvc or annexb. On Thu, Apr 24, 2025 at 8:43 PM jiangjie <jiangjie618@gmail.com> wrote: > if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will > return an error. > ffmpeg -i rtmp://xxx/live/xxx -bsf:v > "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - > --- > libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- > tests/fate/h264.mak | 3 +++ > .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ > 3 files changed, 35 insertions(+), 6 deletions(-) > create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c > b/libavcodec/bsf/h264_mp4toannexb.c > index dda064287e..42a5a274bf 100644 > --- a/libavcodec/bsf/h264_mp4toannexb.c > +++ b/libavcodec/bsf/h264_mp4toannexb.c > @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext > *s, > return 0; > } > > +static int is_annexb(const uint8_t *extradata, int extra_size) { > + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > + return 1; > + } else { > + return 0; > + } > +} > + > static int h264_mp4toannexb_init(AVBSFContext *ctx) > { > int extra_size = ctx->par_in->extradata_size; > > /* retrieve sps and pps NAL units from extradata */ > - if (!extra_size || > - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > + if (is_annexb(ctx->par_in->extradata, extra_size)) { > av_log(ctx, AV_LOG_VERBOSE, > "The input looks like it is Annex B already\n"); > } else if (extra_size >= 7) { > @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, > AVPacket *opkt) > extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > &extradata_size); > if (extradata) { > - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > - if (ret < 0) > - goto fail; > + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) > { > + ret = h264_extradata_to_annexb(ctx, extradata, > extradata_size); > + if (ret < 0) > + goto fail; > + av_packet_side_data_remove(in->side_data, > &in->side_data_elems, > + AV_PKT_DATA_NEW_EXTRADATA); > + uint8_t *data = av_packet_new_side_data( > + in, AV_PKT_DATA_NEW_EXTRADATA, > ctx->par_out->extradata_size); > + memcpy(data, ctx->par_out->extradata, > ctx->par_out->extradata_size); > + } > } > > /* nothing to filter */ > diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak > index 00b153cc93..7b3e865955 100644 > --- a/tests/fate/h264.mak > +++ b/tests/fate/h264.mak > @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, > H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to > > fate-h264-bsf-mp4toannexb-2 \ > > fate-h264_mp4toannexb_ticket5927 \ > > fate-h264_mp4toannexb_ticket5927_2 \ > + > fate-h264-bsf-mp4toannexb-h264_metadata \ > > FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts > > @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: CMD > = md5 -i $(TARGET_SAMPLES) > fate-h264-bsf-mp4toannexb-2: CMP = oneline > fate-h264-bsf-mp4toannexb-2: REF = > cffcfa6a2d0b58c9de1f5785f099f41d > fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov > $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" > +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov > $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ > + h264 "-c:v copy > -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" > fate-h264-bsf-dts2pts: CMD = transcode "h264" > $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ > mov "-c:v copy > -bsf:v dts2pts -frames:v 50" "-c:v copy" > fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" > $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ > diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > new file mode 100644 > index 0000000000..d3ba7f1886 > --- /dev/null > +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > @@ -0,0 +1,12 @@ > +a48f175bf3458410d1dd1907682b92d3 > *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > +#extradata 0: 38, 0x84d70914 > +#tb 0: 1/1200000 > +#media_type 0: video > +#codec_id 0: h264 > +#dimensions 0: 256x128 > +#sar 0: 1/1 > +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb > +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, F=0x0 > +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 > +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, F=0x0 > -- > 2.49.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 13:04 ` jie jiang @ 2025-04-24 14:03 ` Zhao Zhili 0 siblings, 0 replies; 11+ messages in thread From: Zhao Zhili @ 2025-04-24 14:03 UTC (permalink / raw) To: FFmpeg development discussions and patches > On Apr 24, 2025, at 21:04, jie jiang <jiangjie618@gmail.com> wrote: > > I resubmitted it according to your suggestion. > please check. > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250424124250.71553-1-jiangjie618@gmail.com/ > > > So only remove AV_PKT_DATA_NEW_EXTRADATA can fix the issue? > answer: yes, but AV_PKT_DATA_NEW_EXTRADATA is used for event > notification, it is usefull. This isn’t what I mean. I mean the patch should only remove AV_PKT_DATA_NEW_EXTRADATA from packet, not updating ctx->par_out->extradata. > > And the error is from bsf or decoder after h264_mp4toannexb, not > h264_mp4toannexb itself, right? > answer: yes > > i think AV_PKT_DATA_NEW_EXTRADATA and output stream should be the same > format, both avvc or annexb. > > > > > On Thu, Apr 24, 2025 at 8:43 PM jiangjie <jiangjie618@gmail.com> wrote: > >> if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will >> return an error. >> ffmpeg -i rtmp://xxx/live/xxx -bsf:v >> "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - >> --- >> libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- >> tests/fate/h264.mak | 3 +++ >> .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ >> 3 files changed, 35 insertions(+), 6 deletions(-) >> create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >> >> diff --git a/libavcodec/bsf/h264_mp4toannexb.c >> b/libavcodec/bsf/h264_mp4toannexb.c >> index dda064287e..42a5a274bf 100644 >> --- a/libavcodec/bsf/h264_mp4toannexb.c >> +++ b/libavcodec/bsf/h264_mp4toannexb.c >> @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext >> *s, >> return 0; >> } >> >> +static int is_annexb(const uint8_t *extradata, int extra_size) { >> + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || >> + (extra_size >= 4 && AV_RB32(extradata) == 1)) { >> + return 1; >> + } else { >> + return 0; >> + } >> +} >> + >> static int h264_mp4toannexb_init(AVBSFContext *ctx) >> { >> int extra_size = ctx->par_in->extradata_size; >> >> /* retrieve sps and pps NAL units from extradata */ >> - if (!extra_size || >> - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || >> - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { >> + if (is_annexb(ctx->par_in->extradata, extra_size)) { >> av_log(ctx, AV_LOG_VERBOSE, >> "The input looks like it is Annex B already\n"); >> } else if (extra_size >= 7) { >> @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, >> AVPacket *opkt) >> extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, >> &extradata_size); >> if (extradata) { >> - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); >> - if (ret < 0) >> - goto fail; >> + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) >> { >> + ret = h264_extradata_to_annexb(ctx, extradata, >> extradata_size); >> + if (ret < 0) >> + goto fail; >> + av_packet_side_data_remove(in->side_data, >> &in->side_data_elems, >> + AV_PKT_DATA_NEW_EXTRADATA); >> + uint8_t *data = av_packet_new_side_data( >> + in, AV_PKT_DATA_NEW_EXTRADATA, >> ctx->par_out->extradata_size); >> + memcpy(data, ctx->par_out->extradata, >> ctx->par_out->extradata_size); >> + } >> } >> >> /* nothing to filter */ >> diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak >> index 00b153cc93..7b3e865955 100644 >> --- a/tests/fate/h264.mak >> +++ b/tests/fate/h264.mak >> @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, >> H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to >> >> fate-h264-bsf-mp4toannexb-2 \ >> >> fate-h264_mp4toannexb_ticket5927 \ >> >> fate-h264_mp4toannexb_ticket5927_2 \ >> + >> fate-h264-bsf-mp4toannexb-h264_metadata \ >> >> FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts >> >> @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: CMD >> = md5 -i $(TARGET_SAMPLES) >> fate-h264-bsf-mp4toannexb-2: CMP = oneline >> fate-h264-bsf-mp4toannexb-2: REF = >> cffcfa6a2d0b58c9de1f5785f099f41d >> fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" >> +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ >> + h264 "-c:v copy >> -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" >> fate-h264-bsf-dts2pts: CMD = transcode "h264" >> $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ >> mov "-c:v copy >> -bsf:v dts2pts -frames:v 50" "-c:v copy" >> fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" >> $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ >> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >> b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >> new file mode 100644 >> index 0000000000..d3ba7f1886 >> --- /dev/null >> +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >> @@ -0,0 +1,12 @@ >> +a48f175bf3458410d1dd1907682b92d3 >> *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 >> +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 >> +#extradata 0: 38, 0x84d70914 >> +#tb 0: 1/1200000 >> +#media_type 0: video >> +#codec_id 0: h264 >> +#dimensions 0: 256x128 >> +#sar 0: 1/1 >> +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb >> +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, F=0x0 >> +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 >> +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, F=0x0 >> -- >> 2.49.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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 12:42 ` jiangjie 2025-04-24 13:04 ` jie jiang @ 2025-04-24 14:20 ` Zhao Zhili 2025-04-24 14:53 ` jie jiang 1 sibling, 1 reply; 11+ messages in thread From: Zhao Zhili @ 2025-04-24 14:20 UTC (permalink / raw) To: ffmpeg-devel > On Apr 24, 2025, at 20:42, jiangjie <jiangjie618@gmail.com> wrote: > > if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will return an error. > ffmpeg -i rtmp://xxx/live/xxx -bsf:v "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - The subject and commit message is confusing. ’this’ isn’t a bitstream filter, it’s a bsf chain. And what report error is h264_metadata, not h264_mp4toannexb. The subject can be: Remove NEW_EXTRADATA sidedata And commit message can be: We don’t support mixed bitstream format. For example, h264_metadata report error in this case > --- > libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- > tests/fate/h264.mak | 3 +++ > .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ > 3 files changed, 35 insertions(+), 6 deletions(-) > create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c b/libavcodec/bsf/h264_mp4toannexb.c > index dda064287e..42a5a274bf 100644 > --- a/libavcodec/bsf/h264_mp4toannexb.c > +++ b/libavcodec/bsf/h264_mp4toannexb.c > @@ -252,14 +252,21 @@ static int h264_mp4toannexb_filter_ps(H264BSFContext *s, > return 0; > } > > +static int is_annexb(const uint8_t *extradata, int extra_size) { > + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > + return 1; > + } else { > + return 0; > + } > +} > + > static int h264_mp4toannexb_init(AVBSFContext *ctx) > { > int extra_size = ctx->par_in->extradata_size; > > /* retrieve sps and pps NAL units from extradata */ > - if (!extra_size || > - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > + if (is_annexb(ctx->par_in->extradata, extra_size)) { > av_log(ctx, AV_LOG_VERBOSE, > "The input looks like it is Annex B already\n"); > } else if (extra_size >= 7) { > @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *opkt) > extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > &extradata_size); > if (extradata) { > - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > - if (ret < 0) > - goto fail; > + if (!is_annexb(extradata, extradata_size) && extradata_size >= 7) { > + ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > + if (ret < 0) > + goto fail; > + av_packet_side_data_remove(in->side_data, &in->side_data_elems, > + AV_PKT_DATA_NEW_EXTRADATA); > + uint8_t *data = av_packet_new_side_data( > + in, AV_PKT_DATA_NEW_EXTRADATA, ctx->par_out->extradata_size); > + memcpy(data, ctx->par_out->extradata, ctx->par_out->extradata_size); > + } Remove adding AV_PKT_DATA_NEW_EXTRADATA. There’re in-band PS now. There is another case which not belonging to this patch. With AV_PKT_DATA_NEW_EXTRADATA in annexb format, it should be inserted as in-band PS and also be removed after. > } > > /* nothing to filter */ > diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak > index 00b153cc93..7b3e865955 100644 > --- a/tests/fate/h264.mak > +++ b/tests/fate/h264.mak > @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to > fate-h264-bsf-mp4toannexb-2 \ > fate-h264_mp4toannexb_ticket5927 \ > fate-h264_mp4toannexb_ticket5927_2 \ > + fate-h264-bsf-mp4toannexb-h264_metadata \ > > FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts > > @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: CMD = md5 -i $(TARGET_SAMPLES) > fate-h264-bsf-mp4toannexb-2: CMP = oneline > fate-h264-bsf-mp4toannexb-2: REF = cffcfa6a2d0b58c9de1f5785f099f41d > fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" > +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ > + h264 "-c:v copy -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" > fate-h264-bsf-dts2pts: CMD = transcode "h264" $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ > mov "-c:v copy -bsf:v dts2pts -frames:v 50" "-c:v copy" > fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ > diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > new file mode 100644 > index 0000000000..d3ba7f1886 > --- /dev/null > +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > @@ -0,0 +1,12 @@ > +a48f175bf3458410d1dd1907682b92d3 *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > +#extradata 0: 38, 0x84d70914 > +#tb 0: 1/1200000 > +#media_type 0: video > +#codec_id 0: h264 > +#dimensions 0: 256x128 > +#sar 0: 1/1 > +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb > +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, F=0x0 > +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 > +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, F=0x0 > -- > 2.49.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 14:20 ` Zhao Zhili @ 2025-04-24 14:53 ` jie jiang 2025-04-24 17:23 ` Zhao Zhili 0 siblings, 1 reply; 11+ messages in thread From: jie jiang @ 2025-04-24 14:53 UTC (permalink / raw) To: FFmpeg development discussions and patches ctx->par_out->extradata isn't updated by this commit. Only NEW_EXTRADATA is updated (avvc to annexb). You suggest the patch should only remove AV_PKT_DATA_NEW_EXTRADATA from packet, but AV_PKT_DATA_NEW_EXTRADATA is used to notify the codec or the format that the extradata buffer was changed and the receiving side should act upon it appropriately. So i think NEW_EXTRADATA should be reserved. If you think we don't need support mixed bitstream format. maybe this patch that i commit should be rejected. On Thu, Apr 24, 2025 at 10:21 PM Zhao Zhili < quinkblack-at-foxmail.com@ffmpeg.org> wrote: > > > > On Apr 24, 2025, at 20:42, jiangjie <jiangjie618@gmail.com> wrote: > > > > if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will > return an error. > > ffmpeg -i rtmp://xxx/live/xxx -bsf:v > "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - > > The subject and commit message is confusing. > > ’this’ isn’t a bitstream filter, it’s a bsf chain. And what report error > is h264_metadata, not h264_mp4toannexb. > > The subject can be: Remove NEW_EXTRADATA sidedata > > And commit message can be: > > We don’t support mixed bitstream format. For example, h264_metadata report > error in this case > > > > --- > > libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- > > tests/fate/h264.mak | 3 +++ > > .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ > > 3 files changed, 35 insertions(+), 6 deletions(-) > > create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > > > > diff --git a/libavcodec/bsf/h264_mp4toannexb.c > b/libavcodec/bsf/h264_mp4toannexb.c > > index dda064287e..42a5a274bf 100644 > > --- a/libavcodec/bsf/h264_mp4toannexb.c > > +++ b/libavcodec/bsf/h264_mp4toannexb.c > > @@ -252,14 +252,21 @@ static int > h264_mp4toannexb_filter_ps(H264BSFContext *s, > > return 0; > > } > > > > +static int is_annexb(const uint8_t *extradata, int extra_size) { > > + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > > + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > > + return 1; > > + } else { > > + return 0; > > + } > > +} > > + > > static int h264_mp4toannexb_init(AVBSFContext *ctx) > > { > > int extra_size = ctx->par_in->extradata_size; > > > > /* retrieve sps and pps NAL units from extradata */ > > - if (!extra_size || > > - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > > - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > > + if (is_annexb(ctx->par_in->extradata, extra_size)) { > > av_log(ctx, AV_LOG_VERBOSE, > > "The input looks like it is Annex B already\n"); > > } else if (extra_size >= 7) { > > @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext > *ctx, AVPacket *opkt) > > extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > > &extradata_size); > > if (extradata) { > > - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); > > - if (ret < 0) > > - goto fail; > > + if (!is_annexb(extradata, extradata_size) && extradata_size >= > 7) { > > + ret = h264_extradata_to_annexb(ctx, extradata, > extradata_size); > > + if (ret < 0) > > + goto fail; > > + av_packet_side_data_remove(in->side_data, > &in->side_data_elems, > > + AV_PKT_DATA_NEW_EXTRADATA); > > + uint8_t *data = av_packet_new_side_data( > > + in, AV_PKT_DATA_NEW_EXTRADATA, > ctx->par_out->extradata_size); > > + memcpy(data, ctx->par_out->extradata, > ctx->par_out->extradata_size); > > + } > > Remove adding AV_PKT_DATA_NEW_EXTRADATA. There’re in-band PS now. > > There is another case which not belonging to this patch. With > AV_PKT_DATA_NEW_EXTRADATA > in annexb format, it should be inserted as in-band PS and also be removed > after. > > > } > > > > /* nothing to filter */ > > diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak > > index 00b153cc93..7b3e865955 100644 > > --- a/tests/fate/h264.mak > > +++ b/tests/fate/h264.mak > > @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, > H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to > > > fate-h264-bsf-mp4toannexb-2 \ > > > fate-h264_mp4toannexb_ticket5927 \ > > > fate-h264_mp4toannexb_ticket5927_2 \ > > + > fate-h264-bsf-mp4toannexb-h264_metadata \ > > > > FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts > > > > @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: > CMD = md5 -i $(TARGET_SAMPLES) > > fate-h264-bsf-mp4toannexb-2: CMP = oneline > > fate-h264-bsf-mp4toannexb-2: REF = > cffcfa6a2d0b58c9de1f5785f099f41d > > fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov > $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" > > +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov > $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ > > + h264 "-c:v copy > -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" > > fate-h264-bsf-dts2pts: CMD = transcode "h264" > $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ > > mov "-c:v copy > -bsf:v dts2pts -frames:v 50" "-c:v copy" > > fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" > $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ > > diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > > new file mode 100644 > > index 0000000000..d3ba7f1886 > > --- /dev/null > > +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > > @@ -0,0 +1,12 @@ > > +a48f175bf3458410d1dd1907682b92d3 > *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > > +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > > +#extradata 0: 38, 0x84d70914 > > +#tb 0: 1/1200000 > > +#media_type 0: video > > +#codec_id 0: h264 > > +#dimensions 0: 256x128 > > +#sar 0: 1/1 > > +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb > > +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, > F=0x0 > > +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 > > +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, > F=0x0 > > -- > > 2.49.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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 14:53 ` jie jiang @ 2025-04-24 17:23 ` Zhao Zhili 2025-04-25 2:41 ` jie jiang 0 siblings, 1 reply; 11+ messages in thread From: Zhao Zhili @ 2025-04-24 17:23 UTC (permalink / raw) To: FFmpeg development discussions and patches On Apr 24, 2025, at 22:53, jie jiang <jiangjie618@gmail.com> wrote: > > ctx->par_out->extradata isn't updated by this commit. Only NEW_EXTRADATA > is updated (avvc to annexb). > > You suggest the patch should only remove AV_PKT_DATA_NEW_EXTRADATA from > packet, but AV_PKT_DATA_NEW_EXTRADATA is used to notify the codec or the > format that the extradata buffer was changed and the receiving side should > act upon it appropriately. So i think NEW_EXTRADATA should be reserved. h264_mp4toannexb is supposed to convert out-of-band PS in avcc format to in-band annex format, for decoder and for muxer like mpegts. It can be confusing to keep another group of duplicated PS in side data. And we have extract_extradata bsf for any case NEW_EXTRADATA in side data is needed. > > If you think we don't need support mixed bitstream format. maybe this > patch that i commit should be rejected. We don’t support mixed bitstream format. The issue is totally valid and needs to be fixed. Here is my patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342723.html > > On Thu, Apr 24, 2025 at 10:21 PM Zhao Zhili < > quinkblack-at-foxmail.com@ffmpeg.org> wrote: > >> >> >>> On Apr 24, 2025, at 20:42, jiangjie <jiangjie618@gmail.com> wrote: >>> >>> if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter will >> return an error. >>> ffmpeg -i rtmp://xxx/live/xxx -bsf:v >> "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - >> >> The subject and commit message is confusing. >> >> ’this’ isn’t a bitstream filter, it’s a bsf chain. And what report error >> is h264_metadata, not h264_mp4toannexb. >> >> The subject can be: Remove NEW_EXTRADATA sidedata >> >> And commit message can be: >> >> We don’t support mixed bitstream format. For example, h264_metadata report >> error in this case >> >> >>> --- >>> libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- >>> tests/fate/h264.mak | 3 +++ >>> .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ >>> 3 files changed, 35 insertions(+), 6 deletions(-) >>> create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >>> >>> diff --git a/libavcodec/bsf/h264_mp4toannexb.c >> b/libavcodec/bsf/h264_mp4toannexb.c >>> index dda064287e..42a5a274bf 100644 >>> --- a/libavcodec/bsf/h264_mp4toannexb.c >>> +++ b/libavcodec/bsf/h264_mp4toannexb.c >>> @@ -252,14 +252,21 @@ static int >> h264_mp4toannexb_filter_ps(H264BSFContext *s, >>> return 0; >>> } >>> >>> +static int is_annexb(const uint8_t *extradata, int extra_size) { >>> + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || >>> + (extra_size >= 4 && AV_RB32(extradata) == 1)) { >>> + return 1; >>> + } else { >>> + return 0; >>> + } >>> +} >>> + >>> static int h264_mp4toannexb_init(AVBSFContext *ctx) >>> { >>> int extra_size = ctx->par_in->extradata_size; >>> >>> /* retrieve sps and pps NAL units from extradata */ >>> - if (!extra_size || >>> - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || >>> - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { >>> + if (is_annexb(ctx->par_in->extradata, extra_size)) { >>> av_log(ctx, AV_LOG_VERBOSE, >>> "The input looks like it is Annex B already\n"); >>> } else if (extra_size >= 7) { >>> @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext >> *ctx, AVPacket *opkt) >>> extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, >>> &extradata_size); >>> if (extradata) { >>> - ret = h264_extradata_to_annexb(ctx, extradata, extradata_size); >>> - if (ret < 0) >>> - goto fail; >>> + if (!is_annexb(extradata, extradata_size) && extradata_size >= >> 7) { >>> + ret = h264_extradata_to_annexb(ctx, extradata, >> extradata_size); >>> + if (ret < 0) >>> + goto fail; >>> + av_packet_side_data_remove(in->side_data, >> &in->side_data_elems, >>> + AV_PKT_DATA_NEW_EXTRADATA); >>> + uint8_t *data = av_packet_new_side_data( >>> + in, AV_PKT_DATA_NEW_EXTRADATA, >> ctx->par_out->extradata_size); >>> + memcpy(data, ctx->par_out->extradata, >> ctx->par_out->extradata_size); >>> + } >> >> Remove adding AV_PKT_DATA_NEW_EXTRADATA. There’re in-band PS now. >> >> There is another case which not belonging to this patch. With >> AV_PKT_DATA_NEW_EXTRADATA >> in annexb format, it should be inserted as in-band PS and also be removed >> after. >> >>> } >>> >>> /* nothing to filter */ >>> diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak >>> index 00b153cc93..7b3e865955 100644 >>> --- a/tests/fate/h264.mak >>> +++ b/tests/fate/h264.mak >>> @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, >> H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to >>> >> fate-h264-bsf-mp4toannexb-2 \ >>> >> fate-h264_mp4toannexb_ticket5927 \ >>> >> fate-h264_mp4toannexb_ticket5927_2 \ >>> + >> fate-h264-bsf-mp4toannexb-h264_metadata \ >>> >>> FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += fate-h264-bsf-dts2pts >>> >>> @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: >> CMD = md5 -i $(TARGET_SAMPLES) >>> fate-h264-bsf-mp4toannexb-2: CMP = oneline >>> fate-h264-bsf-mp4toannexb-2: REF = >> cffcfa6a2d0b58c9de1f5785f099f41d >>> fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux mov >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map 0:v" >>> +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ >>> + h264 "-c:v copy >> -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" >>> fate-h264-bsf-dts2pts: CMD = transcode "h264" >> $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ >>> mov "-c:v copy >> -bsf:v dts2pts -frames:v 50" "-c:v copy" >>> fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" >> $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ >>> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >> b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >>> new file mode 100644 >>> index 0000000000..d3ba7f1886 >>> --- /dev/null >>> +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata >>> @@ -0,0 +1,12 @@ >>> +a48f175bf3458410d1dd1907682b92d3 >> *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 >>> +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 >>> +#extradata 0: 38, 0x84d70914 >>> +#tb 0: 1/1200000 >>> +#media_type 0: video >>> +#codec_id 0: h264 >>> +#dimensions 0: 256x128 >>> +#sar 0: 1/1 >>> +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb >>> +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, >> F=0x0 >>> +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 >>> +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, >> F=0x0 >>> -- >>> 2.49.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-request@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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc. 2025-04-24 17:23 ` Zhao Zhili @ 2025-04-25 2:41 ` jie jiang 0 siblings, 0 replies; 11+ messages in thread From: jie jiang @ 2025-04-25 2:41 UTC (permalink / raw) To: FFmpeg development discussions and patches Yes, your patch solves my problem too, which is very nice. But I still think AV_PKT_DATA_NEW_EXTRADATA is not just data, it is also an event. As sps/pps data it can be removed, but as event it should be reserved. Anyway, your patch should be merged. On Fri, Apr 25, 2025 at 1:24 AM Zhao Zhili < quinkblack-at-foxmail.com@ffmpeg.org> wrote: > On Apr 24, 2025, at 22:53, jie jiang <jiangjie618@gmail.com> wrote: > > > > ctx->par_out->extradata isn't updated by this commit. Only > NEW_EXTRADATA > > is updated (avvc to annexb). > > > > You suggest the patch should only remove AV_PKT_DATA_NEW_EXTRADATA from > > packet, but AV_PKT_DATA_NEW_EXTRADATA is used to notify the codec or the > > format that the extradata buffer was changed and the receiving side > should > > act upon it appropriately. So i think NEW_EXTRADATA should be reserved. > > h264_mp4toannexb is supposed to convert out-of-band PS in avcc format to > in-band > annex format, for decoder and for muxer like mpegts. It can be confusing > to keep > another group of duplicated PS in side data. > > And we have extract_extradata bsf for any case NEW_EXTRADATA in side data > is needed. > > > > > If you think we don't need support mixed bitstream format. maybe this > > patch that i commit should be rejected. > > We don’t support mixed bitstream format. The issue is totally valid and > needs to be fixed. > Here is my patch: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342723.html > > > > > On Thu, Apr 24, 2025 at 10:21 PM Zhao Zhili < > > quinkblack-at-foxmail.com@ffmpeg.org> wrote: > > > >> > >> > >>> On Apr 24, 2025, at 20:42, jiangjie <jiangjie618@gmail.com> wrote: > >>> > >>> if get AV_PKT_DATA_NEW_EXTRADATA in AVPacket, this bitstream filter > will > >> return an error. > >>> ffmpeg -i rtmp://xxx/live/xxx -bsf:v > >> "h264_mp4toannexb,h264_metadata=aud=remove" -c copy -f null - > >> > >> The subject and commit message is confusing. > >> > >> ’this’ isn’t a bitstream filter, it’s a bsf chain. And what report error > >> is h264_metadata, not h264_mp4toannexb. > >> > >> The subject can be: Remove NEW_EXTRADATA sidedata > >> > >> And commit message can be: > >> > >> We don’t support mixed bitstream format. For example, h264_metadata > report > >> error in this case > >> > >> > >>> --- > >>> libavcodec/bsf/h264_mp4toannexb.c | 26 ++++++++++++++----- > >>> tests/fate/h264.mak | 3 +++ > >>> .../fate/h264-bsf-mp4toannexb-h264_metadata | 12 +++++++++ > >>> 3 files changed, 35 insertions(+), 6 deletions(-) > >>> create mode 100644 tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > >>> > >>> diff --git a/libavcodec/bsf/h264_mp4toannexb.c > >> b/libavcodec/bsf/h264_mp4toannexb.c > >>> index dda064287e..42a5a274bf 100644 > >>> --- a/libavcodec/bsf/h264_mp4toannexb.c > >>> +++ b/libavcodec/bsf/h264_mp4toannexb.c > >>> @@ -252,14 +252,21 @@ static int > >> h264_mp4toannexb_filter_ps(H264BSFContext *s, > >>> return 0; > >>> } > >>> > >>> +static int is_annexb(const uint8_t *extradata, int extra_size) { > >>> + if (!extra_size || (extra_size >= 3 && AV_RB24(extradata) == 1) || > >>> + (extra_size >= 4 && AV_RB32(extradata) == 1)) { > >>> + return 1; > >>> + } else { > >>> + return 0; > >>> + } > >>> +} > >>> + > >>> static int h264_mp4toannexb_init(AVBSFContext *ctx) > >>> { > >>> int extra_size = ctx->par_in->extradata_size; > >>> > >>> /* retrieve sps and pps NAL units from extradata */ > >>> - if (!extra_size || > >>> - (extra_size >= 3 && AV_RB24(ctx->par_in->extradata) == 1) || > >>> - (extra_size >= 4 && AV_RB32(ctx->par_in->extradata) == 1)) { > >>> + if (is_annexb(ctx->par_in->extradata, extra_size)) { > >>> av_log(ctx, AV_LOG_VERBOSE, > >>> "The input looks like it is Annex B already\n"); > >>> } else if (extra_size >= 7) { > >>> @@ -294,9 +301,16 @@ static int h264_mp4toannexb_filter(AVBSFContext > >> *ctx, AVPacket *opkt) > >>> extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA, > >>> &extradata_size); > >>> if (extradata) { > >>> - ret = h264_extradata_to_annexb(ctx, extradata, > extradata_size); > >>> - if (ret < 0) > >>> - goto fail; > >>> + if (!is_annexb(extradata, extradata_size) && extradata_size >= > >> 7) { > >>> + ret = h264_extradata_to_annexb(ctx, extradata, > >> extradata_size); > >>> + if (ret < 0) > >>> + goto fail; > >>> + av_packet_side_data_remove(in->side_data, > >> &in->side_data_elems, > >>> + AV_PKT_DATA_NEW_EXTRADATA); > >>> + uint8_t *data = av_packet_new_side_data( > >>> + in, AV_PKT_DATA_NEW_EXTRADATA, > >> ctx->par_out->extradata_size); > >>> + memcpy(data, ctx->par_out->extradata, > >> ctx->par_out->extradata_size); > >>> + } > >> > >> Remove adding AV_PKT_DATA_NEW_EXTRADATA. There’re in-band PS now. > >> > >> There is another case which not belonging to this patch. With > >> AV_PKT_DATA_NEW_EXTRADATA > >> in annexb format, it should be inserted as in-band PS and also be > removed > >> after. > >> > >>> } > >>> > >>> /* nothing to filter */ > >>> diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak > >>> index 00b153cc93..7b3e865955 100644 > >>> --- a/tests/fate/h264.mak > >>> +++ b/tests/fate/h264.mak > >>> @@ -231,6 +231,7 @@ FATE_H264-$(call DEMMUX, MOV, H264, > >> H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4to > >>> > >> fate-h264-bsf-mp4toannexb-2 \ > >>> > >> fate-h264_mp4toannexb_ticket5927 \ > >>> > >> fate-h264_mp4toannexb_ticket5927_2 \ > >>> + > >> fate-h264-bsf-mp4toannexb-h264_metadata \ > >>> > >>> FATE_H264-$(call DEMMUX, H264, MOV, DTS2PTS_BSF) += > fate-h264-bsf-dts2pts > >>> > >>> @@ -441,6 +442,8 @@ fate-h264-bsf-mp4toannexb-2: > >> CMD = md5 -i $(TARGET_SAMPLES) > >>> fate-h264-bsf-mp4toannexb-2: CMP = oneline > >>> fate-h264-bsf-mp4toannexb-2: REF = > >> cffcfa6a2d0b58c9de1f5785f099f41d > >>> fate-h264-bsf-mp4toannexb-new-extradata: CMD = stream_remux > mov > >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov "" h264 "-map > 0:v" > >>> +fate-h264-bsf-mp4toannexb-h264_metadata: CMD = transcode mov > >> $(TARGET_SAMPLES)/h264/extradata-reload-multi-stsd.mov \ > >>> + h264 "-c:v > copy > >> -bsf:v h264_mp4toannexb,h264_metadata=aud=remove" "-c:v copy" > >>> fate-h264-bsf-dts2pts: CMD = transcode > "h264" > >> $(TARGET_SAMPLES)/h264-conformance/CAPAMA3_Sand_F.264 \ > >>> mov "-c:v copy > >> -bsf:v dts2pts -frames:v 50" "-c:v copy" > >>> fate-h264_mp4toannexb_ticket5927: CMD = transcode "mp4" > >> $(TARGET_SAMPLES)/h264/thezerotheorem-cut.mp4 \ > >>> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > >> b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > >>> new file mode 100644 > >>> index 0000000000..d3ba7f1886 > >>> --- /dev/null > >>> +++ b/tests/ref/fate/h264-bsf-mp4toannexb-h264_metadata > >>> @@ -0,0 +1,12 @@ > >>> +a48f175bf3458410d1dd1907682b92d3 > >> *tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > >>> +4642 tests/data/fate/h264-bsf-mp4toannexb-h264_metadata.h264 > >>> +#extradata 0: 38, 0x84d70914 > >>> +#tb 0: 1/1200000 > >>> +#media_type 0: video > >>> +#codec_id 0: h264 > >>> +#dimensions 0: 256x128 > >>> +#sar 0: 1/1 > >>> +0, -96000, -9223372036854775808, 48000, 2331, 0xc97509cb > >>> +0, -48000, -9223372036854775808, 48000, 64, 0x6ad91f4e, > >> F=0x0 > >>> +0, 0, -9223372036854775808, 48000, 2203, 0xe376d2a9 > >>> +0, 48000, -9223372036854775808, 48000, 44, 0x687a10ea, > >> F=0x0 > >>> -- > >>> 2.49.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-request@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-request@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-request@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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-04-25 2:41 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-04-24 3:38 [FFmpeg-devel] [PATCH] avcodec/bsf/h264_mp4toannexb.c: change extradata to annexb if this is avcc jiangjie 2025-04-24 4:19 ` Zhao Zhili 2025-04-24 5:18 ` jie jiang 2025-04-24 6:41 ` Zhao Zhili 2025-04-24 12:42 ` jiangjie 2025-04-24 13:04 ` jie jiang 2025-04-24 14:03 ` Zhao Zhili 2025-04-24 14:20 ` Zhao Zhili 2025-04-24 14:53 ` jie jiang 2025-04-24 17:23 ` Zhao Zhili 2025-04-25 2:41 ` jie jiang
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git