Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
On Tue, Jul 27, 2021 at 5:50 AM Gyan Doshi wrote: > > > > On 2021-07-26 22:51, Hendrik Leppkes wrote: > > On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi wrote: > >> > >> > >> On 2021-07-26 19:49, Steven Liu wrote: > >>> 在 2021年7月26日星期一，Gyan Doshi 写道： > >>> > On 2021-07-26 16:39, Steven Liu wrote: > > > 2021年7月26日 下午6:57，Gyan Doshi 写道： > >> Are you referring to the choice of FLV_CODECID values? > >> > > Not only, you can find whole history on: > > > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > > https://trac.ffmpeg.org/ticket/6389 > > https://trac.ffmpeg.org/ticket/3581 > > > try play this sample in ticket > The objections mainly center on compliance with Adobe's spec which is a > concern when muxing. > > no not only muxing, it’s format spec, and no documentation said which > >>> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is > >>> hevc > >>> from users flv? This is very unreasonable. > >> By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > >> > >> > > Which just screams ugly hack even more then anything else. > > Of course. The format is alive but the publisher has abandoned it, so > hacks are all that is left. > That doesn't mean we have to endorse those hacks. HEVC in FLV, and a few other codecs, have been brought up numerous times. You can find all the arguments in the ML archives. Just posting yet-another-patch is not going to change those arguments or the reasons to not apply such a patch. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/concat: finalize the AVBprint buffer immediately
On 7/26/2021 6:49 PM, Marton Balint wrote:
On Mon, 26 Jul 2021, James Almer wrote:
Don't attempt to read its contents in place.
Fixes invalid reads when run under Valgrind.
As far as I remember AVBPrint buffer CAN be read in place by design,
zero terminator is always guaranteed, not only after finalizing. So this
should not be needed. What is causing the invalid reads exactly?
Thanks,
Marton
It happens only when you use a URI string that doesn't end with a line
break. I just noticed that after this patch some invalid reads still
happen in any case.
I think i found out the culprit, and the following seems to fix it:
diff --git a/libavformat/concat.c b/libavformat/concat.c
index aec1f52d8e..94917840c6 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -251,7 +251,7 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
err = AVERROR(ENOMEM);
break;
}
-cursor++;
+if (*cursor) cursor++;
if (++len == SIZE_MAX / sizeof(*nodes)) {
av_free(node_uri);
Basically, av_get_token() returns a pointer to the terminating
character, so cursor++ for the next loop when said character was \0 was
wrong.
___
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] libavformat/flvdec: add HEVC demuxing support
On 2021-07-27 04:28, Steven Liu wrote: 在 2021年7月26日星期一，Gyan Doshi 写道： On 2021-07-26 19:49, Steven Liu wrote: 在 2021年7月26日星期一，Gyan Doshi 写道： On 2021-07-26 16:39, Steven Liu wrote: 2021年7月26日 下午6:57，Gyan Doshi 写道： Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 try play this sample in ticket The objections mainly center on compliance with Adobe's spec which is a concern when muxing. no not only muxing, it’s format spec, and no documentation said which codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... i do not think this can play all flv from other muxing, just private demuxing, so why add it in ffmpeg? It is your private format, it can not play all flv with hevc. Is there a sample HEVC-in-FLV file for which this method won't work? 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".
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
On 2021-07-26 22:51, Hendrik Leppkes wrote: On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi wrote: On 2021-07-26 19:49, Steven Liu wrote: 在 2021年7月26日星期一，Gyan Doshi 写道： On 2021-07-26 16:39, Steven Liu wrote: 2021年7月26日 下午6:57，Gyan Doshi 写道： Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 try play this sample in ticket The objections mainly center on compliance with Adobe's spec which is a concern when muxing. no not only muxing, it’s format spec, and no documentation said which codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... Which just screams ugly hack even more then anything else. Of course. The format is alive but the publisher has abandoned it, so hacks are all that is left. 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".
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
在 2021年7月27日星期二，Gyan Doshi 写道： > > > On 2021-07-27 04:28, Steven Liu wrote: > >> 在 2021年7月26日星期一，Gyan Doshi 写道： >> >> >>> On 2021-07-26 19:49, Steven Liu wrote: >>> >>> 在 2021年7月26日星期一，Gyan Doshi 写道： On 2021-07-26 16:39, Steven Liu wrote: > > 2021年7月26日 下午6:57，Gyan Doshi 写道： > >> Are you referring to the choice of FLV_CODECID values? >>> >>> Not only, you can find whole history on: >>> >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >> https://trac.ffmpeg.org/ticket/6389 >> https://trac.ffmpeg.org/ticket/3581 >> >> try play this sample in ticket >> > The objections mainly center on compliance with Adobe's spec which is a > concern when muxing. > > no not only muxing, it’s format spec, and no documentation said which > > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... >>> >> i do not think this can play all flv from other muxing, just private >> demuxing, so why add it in ffmpeg? It is your private format, it can not >> play all flv with hevc. >> > > Is there a sample HEVC-in-FLV file for which this method won't work? Maybe you can find it in the past mail context > > 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 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] libavformat/flvdec: add HEVC demuxing support
On 2021-07-26 13:45, Steven Liu wrote: 2021年7月26日 上午11:44，Gyan Doshi 写道： On 2021-07-25 19:07, James Almer wrote: On 7/25/2021 10:04 AM, Xiaolei Yu wrote: Explicitly supply an HEVC codec id to enable this feature. --- libavformat/flv.h| 1 + libavformat/flvdec.c | 21 ++--- 2 files changed, 19 insertions(+), 3 deletions(-) This has been rejected time and time again, last time not even a month ago. We may not support muxing it, since that is apparently out of spec, but what's wrong with demuxing? We support demuxing PCM in MP4 but not muxing it. There are a couple of other examples which I can't recall off hand. Isn't Postel's law accepted here? There maybe have lots of codecs, not only hevc, for example opus av1 vvc av2 vp8 vp9 and so on, but there have no enough codec id in flv format. Yes this patch can fix his hevc in his flv, but cannot fix mine. Because it’s not the only one hevc in flv. And not only one patch for demuxing hevc in flv in history mails. Are you referring to the choice of FLV_CODECID values? 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".
Re: [FFmpeg-devel] Fix x264 SEI offset
Oops
Sent wrong patch, Please use the following:
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9afaf19547..f78365a4f7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
On Mon, Jul 26, 2021 at 8:09 PM Jack Waller wrote:
> Dear:
>
> The libavcodec/libx264.c uses the wrong offset to obtain the SEI
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index f78365a4f7..9afaf19547 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
> for (i = 0; i < nnal; i++) {
> /* Don't put the SEI in extradata. */
> if (nal[i].i_type == NAL_SEI) {
> -av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
> +av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
> x4->sei_size = nal[i].i_payload;
> x4->sei = av_malloc(x4->sei_size);
> if (!x4->sei)
>
fix_x264_SEI_offset_2.diff
Description: Binary data
___
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] libswscale: Adds ff_hscale8to15_4_avx2 and ff_hscale8to15_X4_avx2 for all filter sizes.
On Wed, Jul 21, 2021 at 11:11 AM Alan Kelly wrote:
>
>
> On Fri, Jul 16, 2021 at 3:48 PM Alan Kelly wrote:
>
>> These functions replace all ff_hscale8to15_*_ssse3 when avx2 is available.
>> ---
>> EXTERNAL_AVX2_FAST is now used instead of EXTERNAL_AVX2_FAST_GATHER as
>> discussed in the email thread for part 1 of this patch.
>>
>> Benchmark results on Skylake and Haswell:
>>
>> Skylake Haswell
>> hscale_8_to_15_width4_ssse3 761.2 760
>> hscale_8_to_15_width4_avx2 468.7 957
>> hscale_8_to_15_width8_ssse3 1170.7 1032
>> hscale_8_to_15_width8_avx2 865.7 1979
>> hscale_8_to_15_width12_ssse32172.2 2472
>> hscale_8_to_15_width12_avx2 1245.7 2901
>> hscale_8_to_15_width16_ssse32244.2 2400
>> hscale_8_to_15_width16_avx2 1647.2 3681
>>
>> libswscale/swscale_internal.h | 2 +
>> libswscale/utils.c| 37 +++
>> libswscale/x86/Makefile | 1 +
>> libswscale/x86/scale_avx2.asm | 112 ++
>> libswscale/x86/swscale.c | 19 ++
>> tests/checkasm/sw_scale.c | 20 --
>> 6 files changed, 186 insertions(+), 5 deletions(-)
>> create mode 100644 libswscale/x86/scale_avx2.asm
>>
>> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
>> index 673407636a..fba3dabe5b 100644
>> --- a/libswscale/swscale_internal.h
>> +++ b/libswscale/swscale_internal.h
>> @@ -1064,4 +1064,6 @@ void ff_init_vscale_pfn(SwsContext *c,
>> yuv2planar1_fn yuv2plane1, yuv2planarX_fn
>> //number of extra lines to process
>> #define MAX_LINES_AHEAD 4
>>
>> +//shuffle filter and filterPos for hyScale and hcScale filters in avx2
>> +void ff_shuffle_filter_coefficients(SwsContext *c, int* filterPos, int
>> filterSize, int16_t *filter, int dstW);
>> #endif /* SWSCALE_SWSCALE_INTERNAL_H */
>> diff --git a/libswscale/utils.c b/libswscale/utils.c
>> index 176fc6fd63..0577fd5490 100644
>> --- a/libswscale/utils.c
>> +++ b/libswscale/utils.c
>> @@ -268,6 +268,41 @@ static const FormatEntry format_entries[] = {
>> [AV_PIX_FMT_X2RGB10LE] = { 1, 1 },
>> };
>>
>> +void ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos, int
>> filterSize, int16_t *filter, int dstW){
>> +#if ARCH_X86_64
>> +int i, j, k, l;
>> +int cpu_flags = av_get_cpu_flags();
>> +if (EXTERNAL_AVX2_FAST(cpu_flags)){
>> +if ((c->srcBpc == 8) && (c->dstBpc <= 14)){
>> +if (dstW % 16 == 0){
>> +if (filter != NULL){
>> +for (i = 0; i < dstW; i += 8){
>> +FFSWAP(int, filterPos[i + 2], filterPos[i+4]);
>> +FFSWAP(int, filterPos[i + 3], filterPos[i+5]);
>> +}
>> +if (filterSize > 4){
>> +int16_t *tmp2 = av_malloc(dstW * filterSize * 2);
>> +memcpy(tmp2, filter, dstW * filterSize * 2);
>> +for (i = 0; i < dstW; i += 16){//pixel
>> +for (k = 0; k < filterSize / 4; ++k){//fcoeff
>> +for (j = 0; j < 16; ++j){//inner pixel
>> +for (l = 0; l < 4; ++l){//coeff
>> +int from = i * filterSize + j *
>> filterSize + k * 4 + l;
>> +int to = (i) * filterSize + j *
>> 4 + l + k * 64;
>> +filter[to] = tmp2[from];
>> +}
>> +}
>> +}
>> +}
>> +av_free(tmp2);
>> +}
>> +}
>> +}
>> +}
>> +}
>> +#endif
>> +}
>> +
>> int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
>> {
>> return (unsigned)pix_fmt < FF_ARRAY_ELEMS(format_entries) ?
>> @@ -1699,6 +1734,7 @@ av_cold int sws_init_context(SwsContext *c,
>> SwsFilter *srcFilter,
>> get_local_pos(c, 0, 0, 0),
>> get_local_pos(c, 0, 0, 0))) < 0)
>> goto fail;
>> +ff_shuffle_filter_coefficients(c, c->hLumFilterPos,
>> c->hLumFilterSize, c->hLumFilter, dstW);
>> if ((ret = initFilter(>hChrFilter, >hChrFilterPos,
>> >hChrFilterSize, c->chrXInc,
>> c->chrSrcW, c->chrDstW, filterAlign, 1 << 14,
>> @@ -1708,6 +1744,7 @@ av_cold int sws_init_context(SwsContext *c,
>> SwsFilter *srcFilter,
>> get_local_pos(c, c->chrSrcHSubSample,
>> c->src_h_chr_pos, 0),
>> get_local_pos(c, c->chrDstHSubSample,
>> c->dst_h_chr_pos, 0))) < 0)
>> goto fail;
>> +ff_shuffle_filter_coefficients(c, c->hChrFilterPos,
>> c->hChrFilterSize, c->hChrFilter, c->chrDstW);
>> }
>> } // initialize horizontal stuff
>>
>> diff --git
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
> 2021年7月26日 下午6:57，Gyan Doshi 写道： > > Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 And there have lots of use case in China Mainland: https://github.com/CDN-Union/Code As many developers said in irc, maybe there need some add a new format looks like flv in RFC or IEEE, I think this is a better way, or choose mkv :D Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/concat: finalize the AVBprint buffer immediately
Don't attempt to read its contents in place.
Fixes invalid reads when run under Valgrind.
Signed-off-by: James Almer
---
libavformat/concat.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index aec1f52d8e..64ac03e1d8 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -211,6 +211,7 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
struct concat_data *data = h->priv_data;
AVIOContext *in = NULL;
const char *cursor;
+char *buf;
int64_t total_size = 0;
unsigned int nodes_size = 0;
size_t i = 0;
@@ -238,7 +239,11 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
return err;
}
-cursor = bp.str;
+err = av_bprint_finalize(, );
+if (err < 0)
+return err;
+
+cursor = buf;
while (*cursor) {
struct concat_nodes *nodes;
URLContext *uc;
@@ -286,7 +291,7 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
data->nodes[i++].size = size;
total_size += size;
}
-av_bprint_finalize(, NULL);
+av_free(buf);
data->length = i;
if (err < 0)
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
> 2021年7月26日 上午11:44，Gyan Doshi 写道： > > > > On 2021-07-25 19:07, James Almer wrote: >> On 7/25/2021 10:04 AM, Xiaolei Yu wrote: >>> Explicitly supply an HEVC codec id to enable this feature. >>> --- >>> libavformat/flv.h| 1 + >>> libavformat/flvdec.c | 21 ++--- >>> 2 files changed, 19 insertions(+), 3 deletions(-) >> >> This has been rejected time and time again, last time not even a month ago. > > We may not support muxing it, since that is apparently out of spec, but > what's wrong with demuxing? > > We support demuxing PCM in MP4 but not muxing it. There are a couple of other > examples which I can't recall off hand. Isn't Postel's law accepted here? There maybe have lots of codecs, not only hevc, for example opus av1 vvc av2 vp8 vp9 and so on, but there have no enough codec id in flv format. Yes this patch can fix his hevc in his flv, but cannot fix mine. Because it’s not the only one hevc in flv. And not only one patch for demuxing hevc in flv in history mails. > > 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". Thanks Steven Liu ___ 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] avfilter/avf_concat: fix EOF timestamp
Signed-off-by: Paul B Mahol
---
libavfilter/avf_concat.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index cb46f52a04..f7d3889dfa 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -397,12 +397,16 @@ static int activate(AVFilterContext *ctx)
/* Forward status change */
if (cat->cur_idx < ctx->nb_inputs) {
for (i = 0; i < ctx->nb_outputs; i++) {
-ret = ff_inlink_acknowledge_status(ctx->inputs[cat->cur_idx + i],
, );
+AVFilterLink *inlink = ctx->inputs[cat->cur_idx + i];
+
+ret = ff_inlink_acknowledge_status(inlink, , );
/* TODO use pts */
if (ret > 0) {
close_input(ctx, cat->cur_idx + i);
if (cat->cur_idx + ctx->nb_outputs >= ctx->nb_inputs) {
-ff_outlink_set_status(ctx->outputs[i], status, pts);
+ff_outlink_set_status(ctx->outputs[i], status,
+ cat->delta_ts + av_rescale_q(pts,
inlink->time_base,
+
ctx->outputs[i]->time_base));
}
if (!cat->nb_in_active) {
ret = flush_segment(ctx);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/avf_concat: fix EOF timestamp
Paul B Mahol (12021-07-26):
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/avf_concat.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
> index cb46f52a04..f7d3889dfa 100644
> --- a/libavfilter/avf_concat.c
> +++ b/libavfilter/avf_concat.c
> @@ -397,12 +397,16 @@ static int activate(AVFilterContext *ctx)
> /* Forward status change */
> if (cat->cur_idx < ctx->nb_inputs) {
> for (i = 0; i < ctx->nb_outputs; i++) {
> -ret = ff_inlink_acknowledge_status(ctx->inputs[cat->cur_idx +
> i], , );
> +AVFilterLink *inlink = ctx->inputs[cat->cur_idx + i];
> +
> +ret = ff_inlink_acknowledge_status(inlink, , );
Thanks for the change.
> /* TODO use pts */
> if (ret > 0) {
> close_input(ctx, cat->cur_idx + i);
> if (cat->cur_idx + ctx->nb_outputs >= ctx->nb_inputs) {
> -ff_outlink_set_status(ctx->outputs[i], status, pts);
> +ff_outlink_set_status(ctx->outputs[i], status,
> + cat->delta_ts + av_rescale_q(pts,
> inlink->time_base,
> +
> ctx->outputs[i]->time_base));
My first review also said:
"and re-affect pts
in the line before rather than inlining the computation."
This multiply-indented formula is hard to read and would be very
annoying to maintain.
pts = av_rescale_q(pts, inlink->time_base,
ctx->outputs[i]->time_base);
pts += cat->delta_ts;
would be much nicer.
> }
> if (!cat->nb_in_active) {
> ret = flush_segment(ctx);
Regards,
--
Nicolas George
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] avformat/concat: finalize the AVBprint buffer immediately
On Mon, 26 Jul 2021, James Almer wrote:
Don't attempt to read its contents in place.
Fixes invalid reads when run under Valgrind.
As far as I remember AVBPrint buffer CAN be read in place by design,
zero terminator is always guaranteed, not only after finalizing. So this
should not be needed. What is causing the invalid reads exactly?
Thanks,
Marton
Signed-off-by: James Almer
---
libavformat/concat.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index aec1f52d8e..64ac03e1d8 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -211,6 +211,7 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
struct concat_data *data = h->priv_data;
AVIOContext *in = NULL;
const char *cursor;
+char *buf;
int64_t total_size = 0;
unsigned int nodes_size = 0;
size_t i = 0;
@@ -238,7 +239,11 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
return err;
}
-cursor = bp.str;
+err = av_bprint_finalize(, );
+if (err < 0)
+return err;
+
+cursor = buf;
while (*cursor) {
struct concat_nodes *nodes;
URLContext *uc;
@@ -286,7 +291,7 @@ static av_cold int concatf_open(URLContext *h, const char
*uri, int flags)
data->nodes[i++].size = size;
total_size += size;
}
-av_bprint_finalize(, NULL);
+av_free(buf);
data->length = i;
if (err < 0)
--
2.32.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] avformat/concat: finalize the AVBprint buffer immediately
Marton Balint (12021-07-26): > As far as I remember AVBPrint buffer CAN be read in place by design, zero > terminator is always guaranteed, not only after finalizing. So this should > not be needed. What is causing the invalid reads exactly? I confirm your memory. The documentation states: * The string buffer grows as necessary and is always 0-terminated. And I checked: there is no obvious bug in the avio_read_to_bprint() code path, it ends with av_bprint_grow() adding the final 0. Regards, -- Nicolas George 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] libavformat/flvdec: add HEVC demuxing support
在 2021年7月26日星期一，Gyan Doshi 写道： > > > On 2021-07-26 19:49, Steven Liu wrote: > >> 在 2021年7月26日星期一，Gyan Doshi 写道： >> >> >>> On 2021-07-26 16:39, Steven Liu wrote: >>> >>> 2021年7月26日 下午6:57，Gyan Doshi 写道： > Are you referring to the choice of FLV_CODECID values? > > Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 try play this sample in ticket >>> The objections mainly center on compliance with Adobe's spec which is a >>> concern when muxing. >>> >>> no not only muxing, it’s format spec, and no documentation said which >>> >> codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is >> hevc >> from users flv? This is very unreasonable. >> > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... i do not think this can play all flv from other muxing, just private demuxing, so why add it in ffmpeg? It is your private format, it can not play all flv with hevc. > > > This patch is only concerned with demuxing, so we are only talking about >>> files generated by others. >>> >>> The only technical issue is the assignment of FLV_CODECID which can be >>> mitigated by letting the user specify it at runtime. So muxers which use >>> different values can be accommodated. >>> >>> About other codecs, HW enc/dec for HEVC are widely available, not so for >>> VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near >>> or >>> mid-term. >>> >> opus? HEVC is just one codec today, what about tomorrow? This is why so >> many people objection about this kind of patchset. >> > > The slippery slope is theoretical. It will only come up when *other* FLV > producers start muxing new codecs and *other* consumers start accepting > such files. > Without that co-ordination and certain amount of market buy-in, this is > not a concern. Of course, We are using now, ok? > > Regards, > Gyan > > > >> 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 mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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] libavformat/flvdec: add HEVC demuxing support
在 2021年7月27日星期二，Hendrik Leppkes 写道： > On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi wrote: > > > > > > > > On 2021-07-26 19:49, Steven Liu wrote: > > > 在 2021年7月26日星期一，Gyan Doshi 写道： > > > > > >> > > >> On 2021-07-26 16:39, Steven Liu wrote: > > >> > > >>> 2021年7月26日 下午6:57，Gyan Doshi 写道： > > Are you referring to the choice of FLV_CODECID values? > > > > >>> Not only, you can find whole history on: > > >>> > > >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > > >>> https://trac.ffmpeg.org/ticket/6389 > > >>> https://trac.ffmpeg.org/ticket/3581 > > >>> > > >> try play this sample in ticket > > >> The objections mainly center on compliance with Adobe's spec which is > a > > >> concern when muxing. > > >> > > >> no not only muxing, it’s format spec, and no documentation said which > > > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is > hevc > > > from users flv? This is very unreasonable. > > > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > > > > > > Which just screams ugly hack even more then anything else. > Maybe FLV should just export any unknown streams as data and the user > can just deal with identifying and using them. Third way about flv with hevc/av1/opus. :D > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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 v3 1/2] avformat/ttml: split TTML paragraph based or not check into header
From: Jan Ekström
This way it can be re-utilized in movenc.
Signed-off-by: Jan Ekström
---
libavformat/ttmlenc.c | 9 ++---
libavformat/ttmlenc.h | 39 +++
2 files changed, 41 insertions(+), 7 deletions(-)
create mode 100644 libavformat/ttmlenc.h
diff --git a/libavformat/ttmlenc.c b/libavformat/ttmlenc.c
index 7577cb543b..5c4cd8b5e9 100644
--- a/libavformat/ttmlenc.c
+++ b/libavformat/ttmlenc.c
@@ -29,6 +29,7 @@
#include "avformat.h"
#include "internal.h"
+#include "ttmlenc.h"
#include "libavcodec/ttmlenc.h"
#include "libavutil/internal.h"
@@ -137,13 +138,7 @@ static int ttml_write_header(AVFormatContext *ctx)
0);
const char *printed_lang = (lang && lang->value) ? lang->value : "";
-// Not perfect, but decide whether the packet is a document or not
-// by the existence of the lavc ttmlenc extradata.
-ttml_ctx->input_type = (st->codecpar->extradata &&
-st->codecpar->extradata_size >=
TTMLENC_EXTRADATA_SIGNATURE_SIZE &&
-!memcmp(st->codecpar->extradata,
-TTMLENC_EXTRADATA_SIGNATURE,
-TTMLENC_EXTRADATA_SIGNATURE_SIZE)) ?
+ttml_ctx->input_type = ff_is_ttml_stream_paragraph_based(st->codecpar)
?
PACKET_TYPE_PARAGRAPH :
PACKET_TYPE_DOCUMENT;
diff --git a/libavformat/ttmlenc.h b/libavformat/ttmlenc.h
new file mode 100644
index 00..2da233b8f1
--- /dev/null
+++ b/libavformat/ttmlenc.h
@@ -0,0 +1,39 @@
+/*
+ * Generic TTML helpers
+ * Copyright (c) 2021 24i
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFORMAT_TTMLENC_H
+#define AVFORMAT_TTMLENC_H
+
+#include "avformat.h"
+#include "libavcodec/ttmlenc.h"
+
+static inline unsigned int ff_is_ttml_stream_paragraph_based(AVCodecParameters
*codecpar)
+{
+// Not perfect, but decide whether the packet is a document or not
+// by the existence of the lavc ttmlenc extradata.
+return (codecpar->extradata &&
+codecpar->extradata_size >= TTMLENC_EXTRADATA_SIGNATURE_SIZE &&
+!memcmp(codecpar->extradata,
+TTMLENC_EXTRADATA_SIGNATURE,
+TTMLENC_EXTRADATA_SIGNATURE_SIZE));
+}
+
+#endif /* AVFORMAT_TTMLENC_H */
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 0/2] TTML in MP4, part 1
To keep it simpler this first part includes only non-fragmented use cases if the built-in sample squashing is utilized. Contains the basic mapping code as well as the function that writes out the squashed documents. Works with both subtitle-only output as well as with other streams. In a separate patch set I will add additional complexity on top by introducing fragmentation matching based on the other streams in the mux (since most things that ingest fragmented MP4 with subtitles want the fragment time ranges to match between the video/audio streams and subtitles in the mux). Changes from v2: * Switched to the specified handler type (`subt`, which is the ISOBMFF subtitle handler type and should be utilized for XMLSubtitleSampleEntry) and SubtitleMediaHeaderBox (`sthd`, an empty all-zeroes FullBox) with MP4 style TTML. I did not notice this until now since most implementations seem to be fine with just the sample entry being correct. ISMV style TTML was getting the correct boxes written, `text` and `nmhd`. * Switched the `dfxp` tag check from track->mode == MODE_MP4 to != MODE_ISM, as that matches better; After all, `dfxp` is only supposed to be utilized in that specific context. * A trailing semicolon was removed in mov_write_ttml_document_from_queue. * Applied changes based on Andreas' review: ** Using AVERROR_PATCHWELCOME when erroring out that fragmentation is not yet supported. ** movenc_ttml::mov_init_ttml_writer now returns error ASAP if the lavf context allocation fails making the context always a valid pointer after that in the function. As mov_init_ttml_writer handles its own clean-up, the error is then propagated right up in ff_mov_generate_squashed_ttml_packet as well. ** ffio_free_dyn_buf is now being utilized to free the muxer's dynamic buffer in movenc_ttml. ** movenc_ttml::mov_write_ttml_document_from_queue now utilizes a passed AVPacket instead of allocating its own. Jan Jan Ekström (2): avformat/ttml: split TTML paragraph based or not check into header avformat/movenc: add support for TTML muxing libavformat/Makefile | 2 +- libavformat/isom.h | 3 + libavformat/movenc.c | 179 ++- libavformat/movenc.h | 5 + libavformat/movenc_ttml.c| 178 ++ libavformat/movenc_ttml.h| 31 ++ libavformat/ttmlenc.c| 9 +- libavformat/ttmlenc.h| 39 +++ tests/fate/subtitles.mak | 4 + tests/ref/fate/sub-ttml-mp4-dfxp | 44 tests/ref/fate/sub-ttml-mp4-stpp | 44 11 files changed, 528 insertions(+), 10 deletions(-) create mode 100644 libavformat/movenc_ttml.c create mode 100644 libavformat/movenc_ttml.h create mode 100644 libavformat/ttmlenc.h create mode 100644 tests/ref/fate/sub-ttml-mp4-dfxp create mode 100644 tests/ref/fate/sub-ttml-mp4-stpp -- 2.31.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
On 2021-07-26 19:49, Steven Liu wrote: 在 2021年7月26日星期一，Gyan Doshi 写道： On 2021-07-26 16:39, Steven Liu wrote: 2021年7月26日 下午6:57，Gyan Doshi 写道： Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 try play this sample in ticket The objections mainly center on compliance with Adobe's spec which is a concern when muxing. no not only muxing, it’s format spec, and no documentation said which codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... This patch is only concerned with demuxing, so we are only talking about files generated by others. The only technical issue is the assignment of FLV_CODECID which can be mitigated by letting the user specify it at runtime. So muxers which use different values can be accommodated. About other codecs, HW enc/dec for HEVC are widely available, not so for VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or mid-term. opus? HEVC is just one codec today, what about tomorrow? This is why so many people objection about this kind of patchset. The slippery slope is theoretical. It will only come up when *other* FLV producers start muxing new codecs and *other* consumers start accepting such files. Without that co-ordination and certain amount of market buy-in, this is not a concern. Regards, Gyan 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 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] libavformat/flvdec: add HEVC demuxing support
在 2021年7月26日星期一，Gyan Doshi 写道： > > > On 2021-07-26 16:39, Steven Liu wrote: > >> >> 2021年7月26日 下午6:57，Gyan Doshi 写道： >>> >>> Are you referring to the choice of FLV_CODECID values? >>> >> Not only, you can find whole history on: >> >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ >> https://trac.ffmpeg.org/ticket/6389 >> https://trac.ffmpeg.org/ticket/3581 >> > try play this sample in ticket > The objections mainly center on compliance with Adobe's spec which is a > concern when muxing. > > no not only muxing, it’s format spec, and no documentation said which codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc from users flv? This is very unreasonable. > This patch is only concerned with demuxing, so we are only talking about > files generated by others. > > The only technical issue is the assignment of FLV_CODECID which can be > mitigated by letting the user specify it at runtime. So muxers which use > different values can be accommodated. > > About other codecs, HW enc/dec for HEVC are widely available, not so for > VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or > mid-term. opus? HEVC is just one codec today, what about tomorrow? This is why so many people objection about this kind of patchset. > > 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 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] Fix x264 SEI offset
Dear:
The libavcodec/libx264.c uses the wrong offset to obtain the SEI
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index f78365a4f7..9afaf19547 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
fix_x264_SEI_offset.diff
Description: Binary data
___
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] libavformat/flvdec: add HEVC demuxing support
On 2021-07-26 16:39, Steven Liu wrote: 2021年7月26日 下午6:57，Gyan Doshi 写道： Are you referring to the choice of FLV_CODECID values? Not only, you can find whole history on: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ https://trac.ffmpeg.org/ticket/6389 https://trac.ffmpeg.org/ticket/3581 The objections mainly center on compliance with Adobe's spec which is a concern when muxing. This patch is only concerned with demuxing, so we are only talking about files generated by others. The only technical issue is the assignment of FLV_CODECID which can be mitigated by letting the user specify it at runtime. So muxers which use different values can be accommodated. About other codecs, HW enc/dec for HEVC are widely available, not so for VVC, AV1, VP? ..etc, so the slippery slope is not a concern in the near or mid-term. 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 v3 2/2] avformat/movenc: add support for TTML muxing
From: Jan Ekström
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
in case the built-in sample squashing is to be utilized, as this
eases the initial review.
Additionally, add basic tests for both muxing modes in MP4.
Signed-off-by: Jan Ekström
---
libavformat/Makefile | 2 +-
libavformat/isom.h | 3 +
libavformat/movenc.c | 179 ++-
libavformat/movenc.h | 5 +
libavformat/movenc_ttml.c| 178 ++
libavformat/movenc_ttml.h| 31 ++
tests/fate/subtitles.mak | 4 +
tests/ref/fate/sub-ttml-mp4-dfxp | 44
tests/ref/fate/sub-ttml-mp4-stpp | 44
9 files changed, 487 insertions(+), 3 deletions(-)
create mode 100644 libavformat/movenc_ttml.c
create mode 100644 libavformat/movenc_ttml.h
create mode 100644 tests/ref/fate/sub-ttml-mp4-dfxp
create mode 100644 tests/ref/fate/sub-ttml-mp4-stpp
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 813ddd3c20..7e0f587b41 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -337,7 +337,7 @@ OBJS-$(CONFIG_MOV_DEMUXER) += mov.o
mov_chan.o mov_esds.o \
qtpalette.o replaygain.o
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o
\
movenchint.o mov_chan.o rtp.o \
-movenccenc.o rawutils.o
+movenccenc.o movenc_ttml.o
rawutils.o
OBJS-$(CONFIG_MP2_MUXER) += rawenc.o
OBJS-$(CONFIG_MP3_DEMUXER) += mp3dec.o replaygain.o
OBJS-$(CONFIG_MP3_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/isom.h b/libavformat/isom.h
index ac1b3f3d56..34a58c79b7 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -387,4 +387,7 @@ static inline enum AVCodecID ff_mov_get_lpcm_codec_id(int
bps, int flags)
return ff_get_pcm_codec_id(bps, flags & 1, flags & 2, flags & 4 ? -1 : 0);
}
+#define MOV_ISMV_TTML_TAG MKTAG('d', 'f', 'x', 'p')
+#define MOV_MP4_TTML_TAG MKTAG('s', 't', 'p', 'p')
+
#endif /* AVFORMAT_ISOM_H */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index c85efe8748..f3e295ad80 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -56,6 +56,8 @@
#include "hevc.h"
#include "rtpenc.h"
#include "mov_chan.h"
+#include "movenc_ttml.h"
+#include "ttmlenc.h"
#include "vpcc.h"
static const AVOption options[] = {
@@ -119,6 +121,7 @@ static const AVClass mov_isobmff_muxer_class = {
};
static int get_moov_size(AVFormatContext *s);
+static int mov_write_single_packet(AVFormatContext *s, AVPacket *pkt);
static int utf8len(const uint8_t *b)
{
@@ -1787,7 +1790,29 @@ static int mov_write_subtitle_tag(AVIOContext *pb,
MOVTrack *track)
if (track->par->codec_id == AV_CODEC_ID_DVD_SUBTITLE)
mov_write_esds_tag(pb, track);
-else if (track->par->extradata_size)
+else if (track->par->codec_id == AV_CODEC_ID_TTML) {
+switch (track->par->codec_tag) {
+case MOV_ISMV_TTML_TAG:
+// ISMV dfxp requires no extradata.
+break;
+case MOV_MP4_TTML_TAG:
+// As specified in 14496-30, XMLSubtitleSampleEntry
+// Namespace
+avio_put_str(pb, "http://www.w3.org/ns/ttml;);
+// Empty schema_location
+avio_w8(pb, 0);
+// Empty auxiliary_mime_types
+avio_w8(pb, 0);
+break;
+default:
+av_log(NULL, AV_LOG_ERROR,
+ "Unknown codec tag '%s' utilized for TTML stream with "
+ "index %d (track id %d)!\n",
+ av_fourcc2str(track->par->codec_tag), track->st->index,
+ track->track_id);
+return AVERROR(EINVAL);
+}
+} else if (track->par->extradata_size)
avio_write(pb, track->par->extradata, track->par->extradata_size);
if (track->mode == MODE_MP4 &&
@@ -2661,6 +2686,14 @@ static int mov_write_nmhd_tag(AVIOContext *pb)
return 12;
}
+static int mov_write_sthd_tag(AVIOContext *pb)
+{
+avio_wb32(pb, 12);
+ffio_wfourcc(pb, "sthd");
+avio_wb32(pb, 0);
+return 12;
+}
+
static int mov_write_tcmi_tag(AVIOContext *pb, MOVTrack *track)
{
int64_t pos = avio_tell(pb);
@@ -2787,6 +2820,8 @@ static int mov_write_hdlr_tag(AVFormatContext *s,
AVIOContext *pb, MOVTrack *tra
hdlr_type = "sbtl";
} else if (track->tag == MKTAG('m','p','4','s')) {
hdlr_type = "subp";
+} else if (track->tag == MOV_MP4_TTML_TAG) {
+hdlr_type = "subt";
} else {
hdlr_type = "text";
}
@@ -2865,6 +2900,8 @@ static int
Re: [FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support
On Mon, Jul 26, 2021 at 5:16 PM Gyan Doshi wrote: > > > > On 2021-07-26 19:49, Steven Liu wrote: > > 在 2021年7月26日星期一，Gyan Doshi 写道： > > > >> > >> On 2021-07-26 16:39, Steven Liu wrote: > >> > >>> 2021年7月26日 下午6:57，Gyan Doshi 写道： > Are you referring to the choice of FLV_CODECID values? > > >>> Not only, you can find whole history on: > >>> > >>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ > >>> https://trac.ffmpeg.org/ticket/6389 > >>> https://trac.ffmpeg.org/ticket/3581 > >>> > >> try play this sample in ticket > >> The objections mainly center on compliance with Adobe's spec which is a > >> concern when muxing. > >> > >> no not only muxing, it’s format spec, and no documentation said which > > codec id is hevc. 10?11?12?13?14?15? How do you make sure which one is hevc > > from users flv? This is very unreasonable. > > By making it a user option: ffmpeg -f flv -hevc_id 12 -i rtmp://... > > Which just screams ugly hack even more then anything else. Maybe FLV should just export any unknown streams as data and the user can just deal with identifying and using them. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
