Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: fix no warning message if no input signal detected
On Thu, Jun 18, 2020 at 07:37:50PM +0200, Marton Balint wrote:
>
>
> On Thu, 18 Jun 2020, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Signed-off-by: Limin Wang
> >---
> >libavdevice/decklink_dec.cpp | 2 +-
> >1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> >index 82106aa..90569dc 100644
> >--- a/libavdevice/decklink_dec.cpp
> >+++ b/libavdevice/decklink_dec.cpp
> >@@ -751,7 +751,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
> >}
> >}
> >
> >-if (!no_video) {
> >+if (no_video) {
> >av_log(avctx, AV_LOG_WARNING, "Frame received (#%lu) - No
> > input signal detected "
> >"- Frames dropped %u\n", ctx->frameCount,
> > ++ctx->dropped);
> >}
>
> No, this is good as is, the !no_video condition ensures that it is
> only logged once when the input actually disappears, and not for
> every consecutive frame with no input.
It's good point, but if no input signal after run, no any warning message. I
don't think it's helpful to check the signal status, also the dropped message
isn't correct then, as it'll not count for every dropped frame by the condition.
>
> Regards,
> Marton
> ___
> 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,
Limin Wang
___
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] added sei side data
On Tue, Jun 09, 2020 at 02:39:14PM +1000, Brad Hards wrote:
> >> --git a/libavcodec/packet.h b/libavcodec/packet.h index
> >> 41485f4527..48e0ccbaf0 100644
> >> --- a/libavcodec/packet.h
> >> +++ b/libavcodec/packet.h
> >> @@ -282,6 +282,11 @@ enum AVPacketSideDataType {
> >> */
> >> AV_PKT_DATA_DOVI_CONF,
> >>
> >> +/**
> >> + * This side data contains SEI unregistered Data.
> >> + */
> >> +AV_PKT_DATA_SEI_USER,
> >> +
> >
> >it's public header
>
> I don't understand this comment. What are you expecting as the change here?
It's API change for public header, so I think it's necessary to update
doc/APIchanges
and bump version.
Also SEI unregisted data is h264 and h265 codec SEI data, I haven't clear why
it's packet side
data yet. I add the SEI user data for frame level before, maybe you can check
it:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200317105409.2795-1-lance.lmw...@gmail.com/
>
> Brad
>
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avcodec/mpeg12enc: support mpeg2 encoder const profile
On Sun, May 31, 2020 at 07:19:24PM +0200, Marton Balint wrote:
>
>
> On Sat, 30 May 2020, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Signed-off-by: Limin Wang
> >---
> >doc/encoders.texi | 14 ++
> >libavcodec/mpeg12enc.c | 2 ++
> >libavcodec/profiles.h | 8
> >3 files changed, 24 insertions(+)
> >
> >diff --git a/doc/encoders.texi b/doc/encoders.texi
> >index 954f0f6..1331b79 100644
> >--- a/doc/encoders.texi
> >+++ b/doc/encoders.texi
> >@@ -2740,6 +2740,20 @@ MPEG-2 video encoder.
> >@subsection Options
> >
> >@table @option
> >+@item profile @var{integer}
> >+Select the mpeg2 profile to encode:
> >+
> >+@table @samp
> >+@item 422
> >+@item main
> >+@item ss
> >+Spatially Scalable
> >+@item snr
> >+SNR Scalable
> >+@item high
> >+@item simple
> >+@end table
> >+
> >@item seq_disp_ext @var{integer}
> >Specifies if the encoder should write a sequence_display_extension to the
> >output.
> >diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> >index cab7076..9fbbcef 100644
> >--- a/libavcodec/mpeg12enc.c
> >+++ b/libavcodec/mpeg12enc.c
> >@@ -41,6 +41,7 @@
> >#include "mpeg12data.h"
> >#include "mpegutils.h"
> >#include "mpegvideo.h"
> >+#include "profiles.h"
> >
> >static const uint8_t svcd_scan_offset_placeholder[] = {
> >0x10, 0x0E, 0x00, 0x80, 0x81, 0x00, 0x80,
> >@@ -1167,6 +1168,7 @@ static const AVOption mpeg2_options[] = {
> >{ "mac", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> > VIDEO_FORMAT_MAC}, 0, 0, VE, "video_format" },
> >{ "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> > VIDEO_FORMAT_UNSPECIFIED}, 0, 0, VE, "video_format" },
> >FF_MPV_COMMON_OPTS
> >+FF_MPEG2_PROFILE_OPTS
> >{ NULL },
> >};
> >
> >diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> >index e414ea7..d241925 100644
> >--- a/libavcodec/profiles.h
> >+++ b/libavcodec/profiles.h
> >@@ -43,6 +43,14 @@
> >FF_AVCTX_PROFILE_OPTION("mpeg4_main",NULL, VIDEO,
> > FF_PROFILE_MPEG4_MAIN)\
> >FF_AVCTX_PROFILE_OPTION("mpeg4_asp", NULL, VIDEO,
> > FF_PROFILE_MPEG4_ADVANCED_SIMPLE)\
> >
> >+#define FF_MPEG2_PROFILE_OPTS \
> >+FF_AVCTX_PROFILE_OPTION("422", NULL, VIDEO,
> >FF_PROFILE_MPEG2_422)\
> >+FF_AVCTX_PROFILE_OPTION("high", NULL, VIDEO,
> >FF_PROFILE_MPEG2_HIGH)\
> >+FF_AVCTX_PROFILE_OPTION("ss",NULL, VIDEO,
> >FF_PROFILE_MPEG2_SS)\
> >+FF_AVCTX_PROFILE_OPTION("snr", NULL, VIDEO,
> >FF_PROFILE_MPEG2_SNR_SCALABLE)\
> >+FF_AVCTX_PROFILE_OPTION("main", NULL, VIDEO,
> >FF_PROFILE_MPEG2_MAIN)\
> >+FF_AVCTX_PROFILE_OPTION("simple",NULL, VIDEO,
> >FF_PROFILE_MPEG2_SIMPLE)\
> >+
> >extern const AVProfile ff_aac_profiles[];
> >extern const AVProfile ff_dca_profiles[];
> >extern const AVProfile ff_dnxhd_profiles[];
> >--
>
> LGTM, thanks.
thanks, will apply.
>
> Marton
> ___
> 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,
Limin Wang
___
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 v4 1/2] fftools: add options to dump filter graph
On Sat, May 23, 2020 at 04:52:47PM +0200, Nicolas George wrote:
> Limin Wang (12020-05-23):
> > > In this case, transforming the string into an AVDictionary, passing it
> > > around and warning if there are remaining options should be the simplest
> > > choice.
> >
> > So I should to use av_find_info_tag to parse the options string? any
> > sample code
> > in the existing code for refering?
>
> What?!? Definitely not. Have you read its doc? It is made for URLs, we
> do not have any URL here.
I'm not clear about the char * option usage yet, below is my draft code, am I
understand for you correctly?
+int ret;
+AVDictionary *dict = NULL;
+AVDictionaryEntry *format = NULL;
+ret = av_dict_parse_string(, options, "=", ":", 0);
+if (ret < 0) {
+av_dict_free();
+return NULL;
+}
+format = av_dict_get(dict, "fmt", NULL, 0);
+
+if (format && !strcmp(format->value, "DOT")) {
+av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
+avfilter_graph2dot_to_buf(, graph);
+av_bprint_finalize(, );
+} else {
>
> Regards,
>
> --
> Nicolas George
> ___
> 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,
Limin Wang
___
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 v4 1/2] fftools: add options to dump filter graph
On Sat, May 23, 2020 at 04:36:24PM +0200, Nicolas George wrote: > Limin Wang (12020-05-23): > > OK, if nobody object it, I'll remove it after the patchset are OK. > > That should be in the same patch. > > > I have no idea how to use parse_key_value_pair() and how to support it in > > command > > line with option? so I use it as format directly. > > The answer to something we do not know should be to learn, not to do > without and result in an inferior implementation. OK, I'm glad to learn how to use it, I haven't find how to use it in the existing code. > > I am very much opposed to turning this option into just the name of the > format, especially now that it starts getting extended. > > In this case, transforming the string into an AVDictionary, passing it > around and warning if there are remaining options should be the simplest > choice. So I should to use av_find_info_tag to parse the options string? any sample code in the existing code for refering? > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v4 2/2] avdevice/lavf: add more options to dump filter graph
On Sat, May 23, 2020 at 02:52:12PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-05-23): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/indevs.texi | 16 ++-- > > libavdevice/lavfi.c | 19 +-- > > 2 files changed, 27 insertions(+), 8 deletions(-) > > I think the change to allow to set the format and the change to allow to > set the output file belong in a different patch. OK, will try to split the patch. > > The existing dump_graph field can very well serve as the options string > for the function. So you prefer to the existing dump_graph option as options string for format? > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ 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 v4 1/2] fftools: add options to dump filter graph
On Sat, May 23, 2020 at 02:41:01PM +0200, Mattias Wadman wrote:
> On Sat, May 23, 2020 at 2:23 AM wrote:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/ffmpeg.texi | 15
> > fftools/ffmpeg.h| 2 ++
> > fftools/ffmpeg_filter.c | 20
> > fftools/ffmpeg_opt.c| 20
> > libavfilter/graphdump.c | 63
> > +
> > 5 files changed, 120 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index ed437bb..61f 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -735,6 +735,21 @@ Technical note -- attachments are implemented as codec
> > extradata, so this
> > option can actually be used to extract extradata from any stream, not just
> > attachments.
> >
> > +@item -dump_filtergraph @var{filename} (@emph{global})
> > +Set the output file name of filter graph for dump.
> > +
> > +It is "ASCII" format by default. for Graphviz DOT output format,
> > +you can convert it to png by GraphViz tool:
> > +@example
> > +dot -Tpng dump_fg_filename -o dump_graph.png
> > +@end example
> > +
> > +@item -dump_filtergraph_format @var{format} (@emph{global})
> > +Set the output format of filter graph for dump. Support format: "DOT",
> > "ASCII".
> > +
> > +DOT is the text file format of the suite GraphViz, ASCII is the text file
> > format
> > +of ASCII style.
> > +
> > @item -noautorotate
> > Disable automatically rotating video based on file metadata.
> >
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 38205a1..55f115b 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -606,6 +606,8 @@ extern AVIOContext *progress_avio;
> > extern float max_error_rate;
> > extern char *videotoolbox_pixfmt;
> >
> > +extern char* dump_fg_filename;
> > +extern char* dump_fg_format;
> > extern int filter_nbthreads;
> > extern int filter_complex_nbthreads;
> > extern int vstats_version;
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 8b5b157..485fc73 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -1106,6 +1106,26 @@ int configure_filtergraph(FilterGraph *fg)
> > if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
> > goto fail;
> >
> > +if (dump_fg_filename) {
> > +char *dump = avfilter_graph_dump(fg->graph, dump_fg_format);
> > +FILE *fg_file = fopen(dump_fg_filename, "w");
> > +
> > +if (!dump) {
> > +ret = AVERROR(ENOMEM);
> > +goto fail;
> > +}
> > +if (fg_file) {
> > +fputs(dump, fg_file);
> > +fflush(fg_file);
> > +fclose(fg_file);
> > +} else {
> > +ret = AVERROR(EINVAL);
> > +av_free(dump);
> > +goto fail;
> > +}
> > +av_free(dump);
> > +}
> > +
> > /* limit the lists of allowed formats to the ones selected, to
> > * make sure they stay the same if the filtergraph is reconfigured
> > later */
> > for (i = 0; i < fg->nb_outputs; i++) {
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 60bb437..bdd8957 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -143,6 +143,8 @@ HWDevice *filter_hw_device;
> >
> > char *vstats_filename;
> > char *sdp_filename;
> > +char *dump_fg_filename;
> > +char *dump_fg_format;
> >
> > float audio_drift_threshold = 0.1;
> > float dts_delta_threshold = 10;
> > @@ -2930,6 +2932,20 @@ static int opt_vstats(void *optctx, const char *opt,
> > const char *arg)
> > return opt_vstats_file(NULL, opt, filename);
> > }
> >
> > +static int opt_fg_filename(void *optctx, const char *opt, const char *arg)
> > +{
> > +av_free (dump_fg_filename);
> > +dump_fg_filename = av_strdup (arg);
> > +return 0;
> > +}
> > +
> > +static int opt_fg_format(void *optctx, const char *opt, const char *arg)
> > +{
> > +av_free (dump_fg_format);
> > +dump_fg_format = av_strdup (arg);
> > +return 0;
> > +}
> > +
> > static int opt_video_frames(void *optctx, const char *opt, const char *arg)
> > {
> > Options
Re: [FFmpeg-devel] [PATCH v4 1/2] fftools: add options to dump filter graph
On Sat, May 23, 2020 at 02:49:39PM +0200, Nicolas George wrote:
> lance.lmw...@gmail.com (12020-05-23):
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/ffmpeg.texi | 15
>
> > fftools/ffmpeg.h| 2 ++
> > fftools/ffmpeg_filter.c | 20
> > fftools/ffmpeg_opt.c| 20
> > libavfilter/graphdump.c | 63
> > +
>
> Changes in the library belong and changes in the command-line tools
> belong in different patches with corresponding commit messages.
OK, will split the patch
>
> > 5 files changed, 120 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index ed437bb..61f 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -735,6 +735,21 @@ Technical note -- attachments are implemented as codec
> > extradata, so this
> > option can actually be used to extract extradata from any stream, not just
> > attachments.
> >
> > +@item -dump_filtergraph @var{filename} (@emph{global})
> > +Set the output file name of filter graph for dump.
> > +
> > +It is "ASCII" format by default. for Graphviz DOT output format,
>
> > +you can convert it to png by GraphViz tool:
>
> The is no CammelCase in the official name of this project. Same below.
Yes, will correct them
>
> > +@example
> > +dot -Tpng dump_fg_filename -o dump_graph.png
> > +@end example
> > +
> > +@item -dump_filtergraph_format @var{format} (@emph{global})
> > +Set the output format of filter graph for dump. Support format: "DOT",
> > "ASCII".
> > +
> > +DOT is the text file format of the suite GraphViz, ASCII is the text file
> > format
> > +of ASCII style.
> > +
> > @item -noautorotate
> > Disable automatically rotating video based on file metadata.
> >
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 38205a1..55f115b 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -606,6 +606,8 @@ extern AVIOContext *progress_avio;
> > extern float max_error_rate;
> > extern char *videotoolbox_pixfmt;
> >
> > +extern char* dump_fg_filename;
> > +extern char* dump_fg_format;
> > extern int filter_nbthreads;
> > extern int filter_complex_nbthreads;
> > extern int vstats_version;
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 8b5b157..485fc73 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -1106,6 +1106,26 @@ int configure_filtergraph(FilterGraph *fg)
> > if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
> > goto fail;
> >
> > +if (dump_fg_filename) {
> > +char *dump = avfilter_graph_dump(fg->graph, dump_fg_format);
> > +FILE *fg_file = fopen(dump_fg_filename, "w");
> > +
> > +if (!dump) {
> > +ret = AVERROR(ENOMEM);
> > +goto fail;
> > +}
>
> > +if (fg_file) {
> > +fputs(dump, fg_file);
> > +fflush(fg_file);
> > +fclose(fg_file);
> > +} else {
> > +ret = AVERROR(EINVAL);
> > +av_free(dump);
> > +goto fail;
> > +}
>
> Spaghetti code. Check errors where they happen, not in a weird else
> clause.
OK, will fix.
>
> > +av_free(dump);
> > +}
> > +
> > /* limit the lists of allowed formats to the ones selected, to
> > * make sure they stay the same if the filtergraph is reconfigured
> > later */
> > for (i = 0; i < fg->nb_outputs; i++) {
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 60bb437..bdd8957 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -143,6 +143,8 @@ HWDevice *filter_hw_device;
> >
> > char *vstats_filename;
> > char *sdp_filename;
> > +char *dump_fg_filename;
> > +char *dump_fg_format;
> >
> > float audio_drift_threshold = 0.1;
> > float dts_delta_threshold = 10;
> > @@ -2930,6 +2932,20 @@ static int opt_vstats(void *optctx, const char *opt,
> > const char *arg)
> > return opt_vstats_file(NULL, opt, filename);
> > }
> >
> > +static int opt_fg_filename(void *optctx, const char *opt, const char *arg)
> > +{
> > +av_free (dump_fg_filename);
>
> > +dump_fg_fi
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: fix resync logic stuck in 192 bytes
On Wed, May 20, 2020 at 08:26:37AM +0200, Marton Balint wrote:
>
>
> On Wed, 20 May 2020, lance.lmw...@gmail.com wrote:
>
> >On Tue, May 19, 2020 at 09:06:59PM +0200, Marton Balint wrote:
> >>pos47_full is not updated for every packet, and for unseekable inputs the
> >>resync logic might simply skip some 0x47 sync bytes. In order to detect
> >>these
> >>let's check for modulo instead of exact value.
> >
> >Before modifying and returning directly, I considered whether pos
> >is a multiple of raw_packet_size, by the debug information, it's
> >not true.
>
> Not always, because sometimes there are 0x47 sync bytes in the
> packet payload as well. But we siply ignore that case because of the
> return later originated from your patch. Checking for modulo allows
> faster detection and it also allows detection when UDP packets
> contain a single MPEGTS packet.
>
> >Also it's possible
> >for the pos of two sync byte > 188/192/204 * n. If that's true, it's not
> >correct
> >to look it as stats hit by the modulo logic.
>
> I don't understand what you mean here.
Let me give one example, the size is 192*2, but the second 192 isn't start by
0x47
sync byte, checking with modulo will not correct for the case
>
> Regards,
> Marton
>
>
> >
> >>
> >>Also skip unrecognized sync byte distances instead of considering them as a
> >>failure of detection. It only delays the detection of the new packet size.
> >>
> >>Also note that AVIO only buffers a single packet (for UDP/mpegts, that
> >>usually
> >>means 1316 bytes), so among every ten consecutive 188-byte MPEGTS packets
> >>there
> >>will always be a seek failure, and that caused the old code to not find the
> >>188
> >>byte pattern across 10 consecutive packets.
> >>
> >>Signed-off-by: Marton Balint
> >>---
> >> libavformat/mpegts.c | 8 +---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> >>index a065c61c40..f2b2c05d86 100644
> >>--- a/libavformat/mpegts.c
> >>+++ b/libavformat/mpegts.c
> >>@@ -2846,12 +2846,14 @@ static void reanalyze(MpegTSContext *ts) {
> >> if (pos < 0)
> >> return;
> >> pos -= ts->pos47_full;
> >>-if (pos == TS_PACKET_SIZE) {
> >>+if (pos % TS_PACKET_SIZE == 0) {
> >> ts->size_stat[0] ++;
> >>-} else if (pos == TS_DVHS_PACKET_SIZE) {
> >>+} if (pos % TS_DVHS_PACKET_SIZE == 0) {
> >> ts->size_stat[1] ++;
> >>-} else if (pos == TS_FEC_PACKET_SIZE) {
> >>+} if (pos % TS_FEC_PACKET_SIZE == 0) {
> >> ts->size_stat[2] ++;
> >>+} else {
> >>+return;
> >> }
> >>
> >> ts->size_stat_count ++;
> >>--
> >>2.26.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".
> >
> >--
> >Thanks,
> >Limin Wang
> >___
> >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".
--
Thanks,
Limin Wang
___
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] Revert "avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first"
On Thu, May 14, 2020 at 11:03:49PM +0200, Marton Balint wrote:
> This reverts commit 339593ca90cb3e05d659ec99a1479904ec742294.
>
> Fixes null pointer dereference.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/vf_framerate.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> index 8d16998457..6c8d01c94b 100644
> --- a/libavfilter/vf_framerate.c
> +++ b/libavfilter/vf_framerate.c
> @@ -71,20 +71,13 @@ static double get_scene_score(AVFilterContext *ctx,
> AVFrame *crnt, AVFrame *next
>
> if (crnt->height == next->height &&
> crnt->width == next->width) {
> -AVDictionaryEntry *e_mafd = NULL;
> uint64_t sad;
> -double mafd = HUGE_VAL, diff;
> -char *tail = NULL;
> +double mafd, diff;
>
> ff_dlog(ctx, "get_scene_score() process\n");
> -e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL,
> AV_DICT_MATCH_CASE);
> -if (e_mafd)
> -mafd = strtod(e_mafd->value, );
just have time to look at the issue, I prefer to add one extra checking for
!tail to fix
it, it's better than revert. I'll post patch for the fixes.
> -if (*tail || mafd == HUGE_VAL) {
> -s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
> next->linesize[0], crnt->width, crnt->height, );
> -emms_c();
> -mafd = (double)sad * 100.0 / (crnt->width * crnt->height) / (1
> << s->bitdepth);
> -}
> +s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
> next->linesize[0], crnt->width, crnt->height, );
> +emms_c();
> +mafd = (double)sad * 100.0 / (crnt->width * crnt->height) / (1 <<
> s->bitdepth);
> diff = fabs(mafd - s->prev_mafd);
> ret = av_clipf(FFMIN(mafd, diff), 0, 100.0);
> s->prev_mafd = mafd;
> --
> 2.16.4
>
> ___
> 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,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: improve the function of FF_ALLOC{Z}{_ARRAY}_OR_GOTO
On Tue, May 12, 2020 at 06:58:34PM +0200, Marton Balint wrote:
>
>
> On Wed, 13 May 2020, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Please refer to the details here:
> >https://patchwork.ffmpeg.org/project/ffmpeg/patch/1589212343-8334-1-git-send-email-lance.lmw...@gmail.com/
> >
> >Suggested-by: Nicolas George
> >Signed-off-by: Limin Wang
> >---
> >libavcodec/aacenc.c | 8 ++--
> >libavcodec/ac3enc.c | 102
> >+--
> >libavcodec/ac3enc_template.c | 15 +++
> >libavcodec/adpcmenc.c| 35 +--
> >libavcodec/alac.c| 17 +++-
> >libavcodec/apedec.c | 9 ++--
> >libavcodec/dnxhdenc.c| 73 +++
> >libavcodec/h264dec.c | 69 ++---
> >libavcodec/iirfilter.c | 12 ++---
> >libavcodec/mpegpicture.c | 11 ++---
> >libavcodec/mpegvideo.c | 78 +++--
> >libavcodec/mpegvideo_enc.c | 31 +
> >libavcodec/snow.c| 25 +--
> >libavcodec/twinvq.c | 23 +-
> >libavutil/internal.h | 24 +-
> >libswscale/utils.c | 40 -
> >16 files changed, 260 insertions(+), 312 deletions(-)
> >
> >diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> >index 4d0abb1..9855e40 100644
> >--- a/libavcodec/aacenc.c
> >+++ b/libavcodec/aacenc.c
> >@@ -939,16 +939,14 @@ static av_cold int dsp_init(AVCodecContext *avctx,
> >AACEncContext *s)
> >
> >static av_cold int alloc_buffers(AVCodecContext *avctx, AACEncContext *s)
> >{
> >-int ch;
> >-FF_ALLOCZ_ARRAY_OR_GOTO(avctx, s->buffer.samples, s->channels, 3 * 1024
> >* sizeof(s->buffer.samples[0]), alloc_fail);
> >-FF_ALLOCZ_ARRAY_OR_GOTO(avctx, s->cpe, s->chan_map[0],
> >sizeof(ChannelElement), alloc_fail);
> >+int ret, ch;
> >+FF_ALLOCZ_ARRAY_OR_GOTO(s->buffer.samples, s->channels, 3 * 1024 *
> >sizeof(s->buffer.samples[0]), ret, return ret);
> >+FF_ALLOCZ_ARRAY_OR_GOTO(s->cpe, s->chan_map[0], sizeof(ChannelElement),
> >ret, return ret);
>
> If you want to change the existing macro, then you have to rename
> it, because it no longer does goto...
>
sorry, I forgot to change it
> Also I kind of disagree with Nicholas that we should always assign a
> ret variable, I think a single error statement is better. For
> example in the case above a goto fail is a lot nicer (and returning
> ENOMEM) there.
>
> Please wait a bit before a conclusion is reached about the macro,
> and only implement it later.
>
> Also this patch is non-trivial now, and some changes are definitely
> not OK (e.g removing ff_h264_free_tables(h) and similar cleanup
> functions from the failure path).
Yes, I notice it and it's better to keep goto without return first.
If you're failed to disagree with Nicholas, I'll not update anymore.
>
> Regards,
> Marton
>
>
> >
> >for(ch = 0; ch < s->channels; ch++)
> >s->planar_samples[ch] = s->buffer.samples + 3 * 1024 * ch;
> >
> >return 0;
> >-alloc_fail:
> >-return AVERROR(ENOMEM);
> >}
> >
> >static av_cold void aac_encode_init_tables(void)
> >diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
> >index ddbc7b2..19434d4 100644
> >--- a/libavcodec/ac3enc.c
> >+++ b/libavcodec/ac3enc.c
> >@@ -2322,60 +2322,60 @@ static av_cold void set_bandwidth(AC3EncodeContext
> >*s)
> >
> >static av_cold int allocate_buffers(AC3EncodeContext *s)
> >{
> >-AVCodecContext *avctx = s->avctx;
> >int blk, ch;
> >int channels = s->channels + 1; /* includes coupling channel */
> >int channel_blocks = channels * s->num_blocks;
> >int total_coefs= AC3_MAX_COEFS * channel_blocks;
> >+int ret;
> >+
> >+if (ret = s->allocate_sample_buffers(s))
> >+return ret;
> >
> >-if (s->allocate_sample_buffers(s))
> >-goto alloc_fail;
> >-
> >-FF_ALLOC_ARRAY_OR_GOTO(avctx, s->bap_buffer, total_coefs,
> >- sizeof(*s->bap_buffer), alloc_fail);
> >-FF_ALLOC_ARRAY_OR_GOTO(avctx, s->bap1_buffer, total_coefs,
> >- sizeof(*s->bap1_buffer), alloc_fail);
> >-FF_ALLOCZ_ARRAY_OR_GOTO(avctx, s->mdct_coef_buffer, total_coefs,
> >- sizeof(*s->mdct_coef_buffer), alloc_fail);
> >-FF_
Re: [FFmpeg-devel] [PATCH] avcodec: improve the function of FF_ALLOC{Z}{_ARRAY}_OR_GOTO
On Tue, May 12, 2020 at 07:58:29PM +0200, Nicolas George wrote: > Marton Balint (12020-05-12): > > And you assume that I want to assign the error code to ret. Wrong. What if I > > want to return it as is? > > Assign it to ret and forward ret. > > >Or what if I want to return NULL beacuse the > > function returns a pointer? > > Bad design, fix it. I have notice one such condition: ff_iir_filter_init_coeffs() in iirfilter.c will return NULL without error code. > > > Using variables is complicated. Constants make > > the code more simple and readable. > > Simpler now, much more complex later to fix the incorrect error codes. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avutil/internal: add FF_ALLOC_TYPED_ARRAY_OR_GOTO & FF_ALLOCZ_TYPED_ARRAY_OR_GOTO
On Tue, May 12, 2020 at 05:29:13PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-05-12): > > return the error code directly? I recall some goto have extra cleanup > > function, > > I'm not sure whether it's OK to return error code directly without goto. > > There are many places that do. Forcing them to use a goto just to be > able to benefit from that macro would be backwards. OK, I'll submit a patch with the proposal for review. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] avformat/dashenc: fix invalid pointer access if avio_get_dyn_buf failed
On Thu, Apr 30, 2020 at 12:34:02PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-30): > > Sorry, the old code will segment fault but the new code will not if error > > happened. so I have no idea what's to compare the output as it's error. > > A segfault is better than corrupted data and better than lost data. So > your task is to examine the output file and check whether it is > corrupted and whether it contains all the data it should contain. > > > Also all of the code which are using avio_get_dyn_buf() didn't check the > > size > > for error. I had to say the avio_get_dyn_buf() is designed very well. > > > > Can we change avio_get_dyn_buf() to return the error directly? also the > > description of API isn't clear for the error condition. > > It seems avio_get_dyn_buf() is not a very good API, indeed. I do not > know if it can be fixed. It is public, and therefore hard to change. > > I have been working on a better API for this kind of thing. Can I count > on your support when I propose it again? That's good to hear, please count me. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] avformat/dashenc: fix invalid pointer access if avio_get_dyn_buf failed
On Wed, Apr 29, 2020 at 05:18:18PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-29): > > From: Limin Wang > > > > If an error occurs, avio_get_dyn_buf() will return 0 and buf is NULL, so > > it's necessary to check > > the return value for the following code will access the buf pointer with > > index. In addition, > > the buf len should be greater than written_len to avoid the buffer overflow > > access. > > > > Signed-off-by: Limin Wang > > --- > > libavformat/dashenc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > And if the allocation fails, the data is silently discarded. Seems > broken. Did you test your change? yes, avio_write can process zero len with NULL pointer, but here it'll use buf+written_len, so it's invalid access I think. So what's the broken? Maybe I haven't catch your point. > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/srtenc: split write time into function for better readability
On Wed, Apr 29, 2020 at 04:38:42PM +0200, Nicolas George wrote:
> lance.lmw...@gmail.com (12020-04-29):
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/srtenc.c | 24 ++--
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/srtenc.c b/libavformat/srtenc.c
> > index d811a4da0e..c53b227313 100644
> > --- a/libavformat/srtenc.c
> > +++ b/libavformat/srtenc.c
> > @@ -34,6 +34,20 @@ typedef struct SRTContext{
> > unsigned index;
> > } SRTContext;
> >
> > +static void srt_write_time(AVIOContext *pb, int64_t millisec)
> > +{
> > +int64_t sec = millisec / 1000;
> > +int64_t min = sec / 60;
> > +int64_t hour = min / 60;
> > +
> > +millisec -= 1000 * sec;
> > +sec -= 60 * min;
> > +min -= 60 * hour;
> > +
> > +avio_printf(pb, "%02"PRId64":%02"PRId64":%02"PRId64",%03"PRId64"",
> > +hour, min, sec, millisec);
> > +}
> > +
> > static int srt_write_header(AVFormatContext *avf)
> > {
> > SRTContext *srt = avf->priv_data;
> > @@ -85,12 +99,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > return 0;
> > }
> > e = s + d;
> > -avio_printf(avf->pb, "%d\n%02d:%02d:%02d,%03d --> %02d:%02d:%02d,%03d",
> > - srt->index,
> > - (int)(s / 360), (int)(s / 6) % 60,
> > - (int)(s /1000) % 60, (int)(s % 1000),
> > - (int)(e / 360), (int)(e / 6) % 60,
> > - (int)(e /1000) % 60, (int)(e % 1000));
>
> I find the original code, with aligned divisions and explicit modulo
> more readable.
>
> Your new code is fragile with regard to the order of operations, and it
> takes a little reflection to see it is correct. Not much, but more than
> (s / 6) % 60.
Sorry, the idea is coming from webvtt_write_time(), although I rewrite the code.
I think it's more readability to split the function with hour, minute, second,
if you prefer to old code, then please ignore the patch.
>
> Also, you are using PRId64 tu print numbers between 0 and 1000.
>
> > +avio_printf(avf->pb, "%d\n", srt->index);
> > +srt_write_time(avf->pb, s);
> > +avio_printf(avf->pb, " --> ");
> > +srt_write_time(avf->pb, e);
> > if (p)
> > avio_printf(avf->pb, " X1:%03d X2:%03d Y1:%03d Y2:%03d",
> > x1, x2, y1, y2);
>
> Regards,
>
> --
> Nicolas George
--
Thanks,
Limin Wang
___
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 v1] MAINTAINERS: add myself to the general developers list
On Sun, Apr 26, 2020 at 11:44:32PM +0200, Marton Balint wrote: > > > On Sun, 26 Apr 2020, lance.lmw...@gmail.com wrote: > > >From: Limin Wang > > > >Signed-off-by: Limin Wang > >--- > >I have actively contributed to FFmpeg in the past year and should be familiar > >with the entire code base and the rules of the developers. > > Then maybe could you omit v1 designators in the future? A patch > without a version designator is usually the first version, or at > least that is how most of the developers send patches, so I suggest > you follow this as well. Got it, I'm glad to learn for the rule. Maybe it's better to add the rule to developer document to follow. > > Thanks, > Marton > > >Up to now, more than > >one hundred patches have been accepted and pushed with the help of > >other developers. However, some reviewed patches have not been > >pushed yet, so I am > >glad to request push access to the FFmpeg repository so that I can push them > >by the developer rules. I think being a committer is a duty, I prefer to > >submit > >any patch to ML for review to avoid making mistakes. > > > >Please the core team give comments or vote for my request. > > > >MAINTAINERS | 1 + > >1 file changed, 1 insertion(+) > > > >diff --git a/MAINTAINERS b/MAINTAINERS > >index e19d1ee586..06956f8741 100644 > >--- a/MAINTAINERS > >+++ b/MAINTAINERS > >@@ -564,6 +564,7 @@ Joakim Plate > >Jun Zhao > >Kieran Kunhya > >Kirill Gavrilov > >+Limin Wang > >Martin Storsjö > >Panagiotis Issaris > >Pedro Arthur > >-- > >2.21.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". -- Thanks, Limin Wang ___ 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 v1] avcodec/utils: use av_rescale()
On Tue, Apr 21, 2020 at 11:05:59PM +0200, Michael Niedermayer wrote: > On Mon, Apr 20, 2020 at 07:00:55PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/utils.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > > index 26c038dfd9..005d596dfd 100644 > > --- a/libavcodec/utils.c > > +++ b/libavcodec/utils.c > > @@ -2229,8 +2229,8 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx) > > const AVPixFmtDescriptor *desc = > > av_pix_fmt_desc_get(avctx->pix_fmt); > > bits_per_coded_sample = av_get_bits_per_pixel(desc); > > } > > -bitrate = (int64_t)bits_per_coded_sample * avctx->width * > > avctx->height * > > - framerate.num / framerate.den; > > +bitrate = av_rescale(avctx->width * avctx->height, > > +bits_per_coded_sample * framerate.num, framerate.den); > > why this change ? I recall mp3dec.c, avidec.c etc always use av_scale to get the bitrate, so I think it's more general to use av_rescale. If I'm misunderstanding, please ignore the patch. > > also > bits_per_coded_sample * framerate.num > could possibly overflow after this i think It seems that the int64_t is necessary still. Then I prefer to: +bitrate = av_rescale((int64_t)bits_per_coded_sample * avctx->width * avctx->height, +framerate.num, framerate.den); > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Nations do behave wisely once they have exhausted all other alternatives. > -- Abba Eban > ___ > 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, Limin Wang ___ 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 04:21:38PM +0200, Nicolas George wrote: > Limin Wang (12020-04-21): > > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > > difference is frag flags of tfhd: > > The trace log is still seeing things from the inside. If there is a bug > after the trace point, it will not be detected. It is important to test > the RESULTING FILE with a DIFFERENT TOOL. I have checked the result files with boxtool and have updated the commit message, please check and review it. thanks. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 05:34:09PM +0300, Jan Ekström wrote: > On Tue, Apr 21, 2020 at 5:19 PM Limin Wang wrote: > > > > On Tue, Apr 21, 2020 at 04:52:16PM +0300, Jan Ekström wrote: > > > On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > > > > > > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > > > > Limin Wang (12020-04-21): > > > > > > OK, below is the commit log, please help to review whether it's > > > > > > your expected log: > > > > > > > > > > > > NOTE about the testing effect: > > > > > > subtitle packet will be marked as keyframe, it'll change below > > > > > > testing reference > > > > > > files: > > > > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > > > > reference file > > > > > > tests/ref/fate/movenc > > > > > > > > > > You are writing in the future tense, meaning you are making a > > > > > prediction. > > > > > > > > > > You need to explain what you did, and the results. For example, did > > > > > you > > > > > re-run the tests with -w, as suggested in > > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > > > > to examine the files before and after the change? > > > > > > > > I have checked with one of non-empty-moov.mp4, and have observed one > > > > byte difference > > > > only(02 and 01). I haven't tool to dump every box in detail. If you > > > > think it's necessary, > > > > I can looked at the movenc muxer further and figure out which field > > > > it's. > > > > > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > > > > > non-empty-moov1.hex > > > > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > > > > 162c162 > > > > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > > |.tfdt...| > > > > --- > > > > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > > > |.tfdt...| > > > > > > > > > > As noted elsewhere before in a related thread, L-SMASH's > > > (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a > > > text representation of MOV/MP4/etc boxes. utilize the --box parameter > > > and dump stdout to a file. Then you can diff -u or otherwise. > > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > > difference is frag flags of tfhd: > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] type:'tfhd' parent:'traf' sz: 36 8 76 > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] frag flags 0x101 > > > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] type:'tfhd' parent:'traf' sz: 36 8 76 > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] frag flags 0x200 > > > > If I recall correctly, boxdumper will give you what these flags mean > in a more readable manner. Yes, I have download and build it, below is the different result. For audio packet is set as keyframe, so it'll look as sync sample. [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box non-empty-moov.mp4 > non-empty-moov.box [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box non-empty-moov1.mp4 > non-empty-moov1.box [lmwang@vpn ffmpeg]$ diff -u non-empty-moov.box non-empty-moov1.box --- non-empty-moov.box 2020-04-21 22:39:30.502512430 +0800 +++ non-empty-moov1.box 2020-04-21 22:39:43.992870378 +0800 @@ -661,9 +661,9 @@ base_data_offset = 2425 default_sample_duration = 1024 default_sample_size = 8 -default_sample_flags = 0x0200 -independent -sync sample +default_sample_flags = 0x0101 +dependent +non-sync sample degradation_priority = 0 [tfdt: Track Fragment Base Media Decode Time Box] position = 2581 > > Jan > ___ > 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, Limin Wang ___ 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 04:52:16PM +0300, Jan Ekström wrote: > On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > > Limin Wang (12020-04-21): > > > > OK, below is the commit log, please help to review whether it's your > > > > expected log: > > > > > > > > NOTE about the testing effect: > > > > subtitle packet will be marked as keyframe, it'll change below testing > > > > reference > > > > files: > > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > > reference file > > > > tests/ref/fate/movenc > > > > > > You are writing in the future tense, meaning you are making a > > > prediction. > > > > > > You need to explain what you did, and the results. For example, did you > > > re-run the tests with -w, as suggested in > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > > to examine the files before and after the change? > > > > I have checked with one of non-empty-moov.mp4, and have observed one byte > > difference > > only(02 and 01). I haven't tool to dump every box in detail. If you think > > it's necessary, > > I can looked at the movenc muxer further and figure out which field it's. > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex > > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > > 162c162 > > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > > |.tfdt...| > > --- > > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > |.tfdt...| > > > > As noted elsewhere before in a related thread, L-SMASH's > (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a > text representation of MOV/MP4/etc boxes. utilize the --box parameter > and dump stdout to a file. Then you can diff -u or otherwise. Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the difference is frag flags of tfhd: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] type:'tfhd' parent:'traf' sz: 36 8 76 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] frag flags 0x101 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] type:'tfhd' parent:'traf' sz: 36 8 76 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] frag flags 0x200 > > Best regards, > Jan > ___ > 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, Limin Wang ___ 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > Limin Wang (12020-04-21): > > OK, below is the commit log, please help to review whether it's your > > expected log: > > > > NOTE about the testing effect: > > subtitle packet will be marked as keyframe, it'll change below testing > > reference > > files: > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > audio packet will be marked as keyframe, it'll change below testing > > reference file > > tests/ref/fate/movenc > > You are writing in the future tense, meaning you are making a > prediction. > > You need to explain what you did, and the results. For example, did you > re-run the tests with -w, as suggested in > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > to examine the files before and after the change? I have checked with one of non-empty-moov.mp4, and have observed one byte difference only(02 and 01). I haven't tool to dump every box in detail. If you think it's necessary, I can looked at the movenc muxer further and figure out which field it's. [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex 162c162 < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 |.tfdt...| --- > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 |.tfdt...| > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 12:35:39PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-21): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavformat/internal.h | 2 + > > libavformat/mux.c| 7 +++- > > tests/ref/fate/binsub-movtextenc | 2 +- > > tests/ref/fate/movenc| 50 +++ > > tests/ref/fate/sub2video | 86 > > > > 5 files changed, 77 insertions(+), 70 deletions(-) > > I should have replied to this message: > > You forgot the part about writing the result of your examination of the > tests in the commit message. > > A commit that changes tests reference files should explain what changed. OK, below is the commit log, please help to review whether it's your expected log: NOTE about the testing effect: subtitle packet will be marked as keyframe, it'll change below testing reference files: tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video audio packet will be marked as keyframe, it'll change below testing reference file tests/ref/fate/movenc > > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Tue, Apr 21, 2020 at 11:26:14AM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-21): > > From: Limin Wang > > > > For better code review, the patch is helping to update the fate tests result > > so the change of ffmpeg.c will be deleted in the last patch. > > > > Signed-off-by: Limin Wang > > You did not need to post it. You only needed to make it, run it, note > carefully the results, and the go back to your work and consign the > results in the relevant commit message. > > I mean, I do not know how you work, but personally I frequently add tons > of av_log() everywhere to track an issue. But they never get to the > mailing list. OK, Got it, I'll merge patch #1,#2,#4 into one patch and update the patch set. > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ 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 v1] avcodec/bsf: simplify the code
On Fri, Apr 17, 2020 at 05:24:32PM +0200, Paul B Mahol wrote:
> On 4/17/20, Limin Wang wrote:
> > On Fri, Apr 17, 2020 at 04:41:44PM +0200, Andreas Rheinhardt wrote:
> >> lance.lmw...@gmail.com:
> >> > From: Limin Wang
> >> >
> >> > Signed-off-by: Limin Wang
> >> > ---
> >> > libavcodec/bsf.c | 10 ++
> >> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> >> > index 7b96183e64..c4c939c205 100644
> >> > --- a/libavcodec/bsf.c
> >> > +++ b/libavcodec/bsf.c
> >> > @@ -533,7 +533,7 @@ end:
> >> > int av_bsf_list_parse_str(const char *str, AVBSFContext **bsf_lst)
> >> > {
> >> > AVBSFList *lst;
> >> > -char *bsf_str, *buf, *dup, *saveptr;
> >> > +char *bsf_str, *buf, *dup;
> >> > int ret;
> >> >
> >> > if (!str)
> >> > @@ -548,16 +548,10 @@ int av_bsf_list_parse_str(const char *str,
> >> > AVBSFContext **bsf_lst)
> >> > goto end;
> >> > }
> >> >
> >> > -while (1) {
> >> > -bsf_str = av_strtok(buf, ",", );
> >> > -if (!bsf_str)
> >> > -break;
> >> > -
> >> > +while (bsf_str = av_strtok(buf, ",", )) {
> >> > ret = bsf_parse_single(bsf_str, lst);
> >> > if (ret < 0)
> >> > goto end;
> >> > -
> >> > -buf = NULL;
> >> > }
> >> >
> >> > ret = av_bsf_list_finalize(, bsf_lst);
> >> >
> >> This is against the documentation of av_strtok() which states:
> >> * On the first call to av_strtok(), s should point to the string to
> >> * parse, and the value of saveptr is ignored. In subsequent calls, s
> >> * should be NULL, and saveptr should be unchanged since the previous
> >> * call.
> >>
> >> It works now, but it is not guaranteed to work.
> >
> > I don't know why the subsequent calls, s should be NULL. I think it's
> > willing,
> > not must. If we're clear, why not to make the buf point to the next token,
> > it
> > looks more simple and easy to read.
> >
> > Also, a lot of such case have used in existing code.
> >
> > [lmwang@vpn ffmpeg]$ grep av_strtok libavformat/*.c |grep while
> > libavformat/dashdec.c:while (mpdName = av_strtok(tmp, "/", )) {
> > libavformat/ftp.c:while(fact = av_strtok(mlsd, ";", )) {
> > libavformat/http.c:while ((param = av_strtok(next_param, ";",
> > _param))) {
> > libavformat/http.c:while ((cookie = av_strtok(next, "\n", )) &&
> > !ret) {
> >
>
> Thanks for listing invalid code lines.
Sorry, have checked with man of strtok_r, it has the same requirement, so it's
better to follow its rule:
On the first call to strtok_r(), str should point to the string to be parsed,
and the value of saveptr is ignored. In subsequent calls, str should be NULL,
and saveptr should be unchanged since the previous call.
I'll try to submit patches to fix these invalid case if you're OK.
>
> >
> >>
> >> - Andreas
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".
--
Thanks,
Limin Wang
___
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 v1] avcodec/bsf: simplify the code
On Fri, Apr 17, 2020 at 04:41:44PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/bsf.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> > index 7b96183e64..c4c939c205 100644
> > --- a/libavcodec/bsf.c
> > +++ b/libavcodec/bsf.c
> > @@ -533,7 +533,7 @@ end:
> > int av_bsf_list_parse_str(const char *str, AVBSFContext **bsf_lst)
> > {
> > AVBSFList *lst;
> > -char *bsf_str, *buf, *dup, *saveptr;
> > +char *bsf_str, *buf, *dup;
> > int ret;
> >
> > if (!str)
> > @@ -548,16 +548,10 @@ int av_bsf_list_parse_str(const char *str,
> > AVBSFContext **bsf_lst)
> > goto end;
> > }
> >
> > -while (1) {
> > -bsf_str = av_strtok(buf, ",", );
> > -if (!bsf_str)
> > -break;
> > -
> > +while (bsf_str = av_strtok(buf, ",", )) {
> > ret = bsf_parse_single(bsf_str, lst);
> > if (ret < 0)
> > goto end;
> > -
> > -buf = NULL;
> > }
> >
> > ret = av_bsf_list_finalize(, bsf_lst);
> >
> This is against the documentation of av_strtok() which states:
> * On the first call to av_strtok(), s should point to the string to
> * parse, and the value of saveptr is ignored. In subsequent calls, s
> * should be NULL, and saveptr should be unchanged since the previous
> * call.
>
> It works now, but it is not guaranteed to work.
I don't know why the subsequent calls, s should be NULL. I think it's willing,
not must. If we're clear, why not to make the buf point to the next token, it
looks more simple and easy to read.
Also, a lot of such case have used in existing code.
[lmwang@vpn ffmpeg]$ grep av_strtok libavformat/*.c |grep while
libavformat/dashdec.c:while (mpdName = av_strtok(tmp, "/", )) {
libavformat/ftp.c:while(fact = av_strtok(mlsd, ";", )) {
libavformat/http.c:while ((param = av_strtok(next_param, ";",
_param))) {
libavformat/http.c:while ((cookie = av_strtok(next, "\n", )) && !ret) {
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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 v3 1/3] avfilter/af_acrossover: Check sscanf() return value
On Fri, Apr 17, 2020 at 04:34:28PM +0200, Paul B Mahol wrote:
> On 4/17/20, Limin Wang wrote:
> >
> > ping for merge please.
>
> trival patch, apply at will.
I can't push it directly, so ping it for developer/maintainer help to apply it.
>
> >
> > On Sun, Mar 29, 2020 at 08:08:04AM +0800, lance.lmw...@gmail.com wrote:
> >> From: Limin Wang
> >>
> >> Signed-off-by: Limin Wang
> >> ---
> >> libavfilter/af_acrossover.c | 5 -
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavfilter/af_acrossover.c b/libavfilter/af_acrossover.c
> >> index f70c50b..002f378 100644
> >> --- a/libavfilter/af_acrossover.c
> >> +++ b/libavfilter/af_acrossover.c
> >> @@ -99,7 +99,10 @@ static av_cold int init(AVFilterContext *ctx)
> >>
> >> p = NULL;
> >>
> >> -av_sscanf(arg, "%f", );
> >> +if (av_sscanf(arg, "%f", ) != 1) {
> >> +av_log(ctx, AV_LOG_ERROR, "Invalid syntax for
> >> frequency[%d].\n", i);
> >> +return AVERROR(EINVAL);
> >> +}
> >> if (freq <= 0) {
> >> av_log(ctx, AV_LOG_ERROR, "Frequency %f must be positive
> >> number.\n", freq);
> >> return AVERROR(EINVAL);
> >> --
> >> 2.9.5
> >>
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".
--
Thanks,
Limin Wang
___
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 v3 1/3] avfilter/af_acrossover: Check sscanf() return value
ping for merge please.
On Sun, Mar 29, 2020 at 08:08:04AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/af_acrossover.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_acrossover.c b/libavfilter/af_acrossover.c
> index f70c50b..002f378 100644
> --- a/libavfilter/af_acrossover.c
> +++ b/libavfilter/af_acrossover.c
> @@ -99,7 +99,10 @@ static av_cold int init(AVFilterContext *ctx)
>
> p = NULL;
>
> -av_sscanf(arg, "%f", );
> +if (av_sscanf(arg, "%f", ) != 1) {
> +av_log(ctx, AV_LOG_ERROR, "Invalid syntax for frequency[%d].\n",
> i);
> +return AVERROR(EINVAL);
> +}
> if (freq <= 0) {
> av_log(ctx, AV_LOG_ERROR, "Frequency %f must be positive
> number.\n", freq);
> return AVERROR(EINVAL);
> --
> 2.9.5
>
--
Thanks,
Limin Wang
___
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 v3 2/2] avcodec/mpeg12enc: Support mpeg2 encoder profile with const options
ping for merge, please.
On Sat, Apr 04, 2020 at 08:25:31AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/encoders.texi | 8
> libavcodec/mpeg12enc.c | 22 +-
> libavcodec/mpegvideo.h | 1 +
> 3 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e23b6b3..5022b94 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2753,6 +2753,14 @@ For maximum compatibility, use @samp{component}.
> @item a53cc @var{boolean}
> Import closed captions (which must be ATSC compatible format) into output.
> Default is 1 (on).
> +@item profile @var{integer}
> +Select the mpeg2 profile to encode, possible values:
> +@table @samp
> +@item 422
> +@item high
> +@item main
> +@item simple
> +@end table
> @end table
>
> @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index 643ba81..9fe0c8b 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -156,23 +156,30 @@ static av_cold int encode_init(AVCodecContext *avctx)
> }
> }
>
> -if (avctx->profile == FF_PROFILE_UNKNOWN) {
> +if (s->profile == FF_PROFILE_UNKNOWN)
> +s->profile = avctx->profile;
> +
> +if (s->profile == FF_PROFILE_UNKNOWN) {
> if (avctx->level != FF_LEVEL_UNKNOWN) {
> av_log(avctx, AV_LOG_ERROR, "Set profile and level\n");
> return -1;
> }
> /* Main or 4:2:2 */
> avctx->profile = s->chroma_format == CHROMA_420 ?
> FF_PROFILE_MPEG2_MAIN : FF_PROFILE_MPEG2_422;
> +s->profile = s->chroma_format == CHROMA_420 ? FF_PROFILE_MPEG2_MAIN
> : FF_PROFILE_MPEG2_422;
> +} else if (s->profile < FF_PROFILE_MPEG2_422) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid mpeg2 profile set\n");
> +return -1;
> }
>
> if (avctx->level == FF_LEVEL_UNKNOWN) {
> -if (avctx->profile == FF_PROFILE_MPEG2_422) { /* 4:2:2 */
> +if (s->profile == FF_PROFILE_MPEG2_422) { /* 4:2:2 */
> if (avctx->width <= 720 && avctx->height <= 608)
> avctx->level = 5; /* Main */
> else
> avctx->level = 2; /* High */
> } else {
> -if (avctx->profile != FF_PROFILE_MPEG2_HIGH && s->chroma_format
> != CHROMA_420) {
> +if (s->profile != FF_PROFILE_MPEG2_HIGH && s->chroma_format !=
> CHROMA_420) {
> av_log(avctx, AV_LOG_ERROR,
> "Only High(1) and 4:2:2(0) profiles support 4:2:2
> color sampling\n");
> return -1;
> @@ -321,9 +328,9 @@ static void mpeg1_encode_sequence_header(MpegEncContext
> *s)
> put_header(s, EXT_START_CODE);
> put_bits(>pb, 4, 1); // seq ext
>
> -put_bits(>pb, 1, s->avctx->profile == FF_PROFILE_MPEG2_422);
> // escx 1 for 4:2:2 profile
> +put_bits(>pb, 1, s->profile == FF_PROFILE_MPEG2_422); // escx
> 1 for 4:2:2 profile
>
> -put_bits(>pb, 3, s->avctx->profile); // profile
> +put_bits(>pb, 3, s->profile); // profile
> put_bits(>pb, 4, s->avctx->level); // level
>
> put_bits(>pb, 1, s->progressive_sequence);
> @@ -1165,6 +1172,11 @@ static const AVOption mpeg2_options[] = {
> { "secam",NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> VIDEO_FORMAT_SECAM }, 0, 0, VE, "video_format" },
> { "mac", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> VIDEO_FORMAT_MAC}, 0, 0, VE, "video_format" },
> { "unspecified", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
> VIDEO_FORMAT_UNSPECIFIED}, 0, 0, VE, "video_format" },
> +{ "profile", "Set the profile", OFFSET(profile),
> AV_OPT_TYPE_INT,{ .i64 = FF_PROFILE_UNKNOWN }, FF_PROFILE_UNKNOWN,
> FF_PROFILE_MPEG2_SIMPLE, VE, "profile" },
> +{ "422", "", 0, AV_OPT_TYPE_CONST,{ .i64 =
> FF_PROFILE_MPEG2_422 }, 0, 0, VE, "profile" },
> +{ "high", "", 0, AV_OPT_TYPE_CONST,{ .i64 =
> FF_PROFILE_MPEG2_HIGH}, 0, 0, VE, "profile" },
> +{ "main", "", 0, AV_OPT_TYPE_CONST,{ .i64 =
> FF_PROFILE_MPEG2_
Re: [FFmpeg-devel] [PATCH v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Fri, Apr 17, 2020 at 10:24:53AM -0300, James Almer wrote:
> On 4/16/2020 10:23 PM, Limin Wang wrote:
> > On Thu, Apr 16, 2020 at 05:16:35PM +0200, Nicolas George wrote:
> >> Sorry, forgot to reply to that.
> >>
> >> Limin Wang (12020-04-04):
> >>> the md5 framecrc is generated by libavformat/tests/movenc.c, I have no
> >>> clue how the movenc testing work and how to get the real input to check
> >>> why
> >>> the frame isn't bitexact as I haven't see any subtitle track.
> >>
> >> Well, check: re-run the test manually, change it to have an actual
> >> output, examine the file. The possibilities are many.
> >>
> >> But tests are there for a reason. If a patch changes the output of
> >> tests, then we cannot accept it unless somebody did examine the changes
> >> very carefully and confirmed they are for the best. Ideally, an
> >> explanation of the changes goes in the commit message.
> >
> > Thanks, it's difficult to examine how it works for the tests/movenc.c
> > without any
> > documenets. As I can't give good explanation for the md5 changed so I had
> > to stop
> > to update the patch.
>
> The change is effectively just the keyframe flag being added to audio
> packets in all of the movenc tests.
>
> To verify, simply apply
>
> diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
> index 1d15d97ad9..0ff87da7d6 100644
> --- a/libavformat/tests/movenc.c
> +++ b/libavformat/tests/movenc.c
> @@ -256,6 +256,7 @@ static void mux_frames(int n, int c)
> pkt.dts = pkt.pts = audio_dts;
> pkt.stream_index = 1;
> pkt.duration = audio_duration;
> +pkt.flags |= AV_PKT_FLAG_KEY;
> audio_dts += audio_duration;
> } else {
> if (frames == end_frames)
>
> without your patch, and you'll get the same changes in the test.
>
> Feel free to update your patch with what Andreas suggested.
James, thanks for the hint, I'll continue to update the patch with Andreas
suggested.
> _______
> 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,
Limin Wang
___
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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Thu, Apr 16, 2020 at 05:16:35PM +0200, Nicolas George wrote: > Sorry, forgot to reply to that. > > Limin Wang (12020-04-04): > > the md5 framecrc is generated by libavformat/tests/movenc.c, I have no > > clue how the movenc testing work and how to get the real input to check why > > the frame isn't bitexact as I haven't see any subtitle track. > > Well, check: re-run the test manually, change it to have an actual > output, examine the file. The possibilities are many. > > But tests are there for a reason. If a patch changes the output of > tests, then we cannot accept it unless somebody did examine the changes > very carefully and confirmed they are for the best. Ideally, an > explanation of the changes goes in the commit message. Thanks, it's difficult to examine how it works for the tests/movenc.c without any documenets. As I can't give good explanation for the md5 changed so I had to stop to update the patch. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v1] fftools/ffprobe: Use format specifier PRId64 instead of %lld
On Fri, Apr 10, 2020 at 07:37:40PM +0200, Michael Niedermayer wrote:
> On Fri, Apr 10, 2020 at 07:04:38PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > fftools/ffprobe.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> > index e3f221f560..a32bc529d9 100644
> > --- a/fftools/ffprobe.c
> > +++ b/fftools/ffprobe.c
> > @@ -408,7 +408,7 @@ static char *value_string(char *buf, int buf_size,
> > struct unit_value uv)
> > if (show_float || (use_value_prefix && vald != (long long
> > int)vald))
> > snprintf(buf, buf_size, "%f", vald);
> > else
> > -snprintf(buf, buf_size, "%lld", vali);
> > +snprintf(buf, buf_size, "%"PRId64, vali);
> > av_strlcatf(buf, buf_size, "%s%s%s", *prefix_string ||
> > show_value_unit ? " " : "",
> > prefix_string, show_value_unit ? uv.unit : "");
> > }
> > @@ -1002,7 +1002,7 @@ static void default_print_int(WriterContext *wctx,
> > const char *key, long long in
> >
> > if (!def->nokey)
> > printf("%s%s=", wctx->section_pbuf[wctx->level].str, key);
> > -printf("%lld\n", value);
> > +printf("%"PRId64"\n", value);
> > }
> >
> > static const Writer default_writer = {
> > @@ -1179,7 +1179,7 @@ static void compact_print_int(WriterContext *wctx,
> > const char *key, long long in
> > if (wctx->nb_item[wctx->level]) printf("%c", compact->item_sep);
> > if (!compact->nokey)
> > printf("%s%s=", wctx->section_pbuf[wctx->level].str, key);
> > -printf("%lld", value);
> > +printf("%"PRId64, value);
> > }
> >
> > static const Writer compact_writer = {
>
> > @@ -1322,7 +1322,7 @@ static void flat_print_section_header(WriterContext
> > *wctx)
> >
> > static void flat_print_int(WriterContext *wctx, const char *key, long long
> > int value)
> > {
> > -printf("%s%s=%lld\n", wctx->section_pbuf[wctx->level].str, key, value);
> > +printf("%s%s=%"PRId64"\n", wctx->section_pbuf[wctx->level].str, key,
> > value);
> > }
>
> the type does not match here
yes, my fault, lld is for "long long int" is no problem. I originally plan to
change "long
long int" to int64_t, but I'm not sure if the original code has other ideas
which I'm missing.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
> ___
> 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,
Limin Wang
___
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 v1 2/2] avfilter/vf_subtitles: add force_style option for ass subtitle filter
please help to review, so that we can change the subtitle postion, color by
force_style.
On Mon, Mar 30, 2020 at 06:52:33PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/filters.texi | 4
> libavfilter/vf_subtitles.c | 23 +++
> 2 files changed, 27 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 328e984e92..d26d90d1bb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -6399,6 +6399,10 @@ Slower shaper using OpenType for substitutions and
> positioning
> @end table
>
> The default is @code{auto}.
> +
> +@item force_style
> +Override default style or script info parameters of the subtitles. It
> accepts a
> +string containing ASS style format @code{KEY=VALUE} couples separated by ",".
> @end table
>
> @section atadenoise
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index 2f312b0ba8..e3ad8b8d94 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -218,6 +218,7 @@ static const AVOption ass_options[] = {
> {"auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = -1},
> INT_MIN, INT_MAX, FLAGS, "shaping_mode"},
> {"simple", "simple shaping", 0, AV_OPT_TYPE_CONST, {.i64 =
> ASS_SHAPING_SIMPLE}, INT_MIN, INT_MAX, FLAGS, "shaping_mode"},
> {"complex", "complex shaping", 0, AV_OPT_TYPE_CONST, {.i64 =
> ASS_SHAPING_COMPLEX}, INT_MIN, INT_MAX, FLAGS, "shaping_mode"},
> +{"force_style", "force subtitle style", OFFSET(force_style),
> AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS},
> {NULL},
> };
>
> @@ -234,6 +235,28 @@ static av_cold int init_ass(AVFilterContext *ctx)
> /* Initialize fonts */
> ass_set_fonts(ass->renderer, NULL, NULL, 1, NULL, 1);
>
> +if (ass->force_style) {
> +char **list = NULL;
> +char *temp = NULL;
> +char *ptr = av_strtok(ass->force_style, ",", );
> +int i = 0;
> +while (ptr) {
> +av_dynarray_add(, , ptr);
> +if (!list) {
> +ret = AVERROR(ENOMEM);
> +return ret;
> +}
> +ptr = av_strtok(NULL, ",", );
> +}
> +av_dynarray_add(, , NULL);
> +if (!list) {
> +ret = AVERROR(ENOMEM);
> +return ret;
> +}
> +ass_set_style_overrides(ass->library, list);
> +av_free(list);
> +}
> +
> ass->track = ass_read_file(ass->library, ass->filename, NULL);
> if (!ass->track) {
> av_log(ctx, AV_LOG_ERROR,
> --
> 2.21.0
>
--
Thanks,
Limin Wang
___
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 v1 1/4] avfilter/af_loudnorm: Add file option for the measured stats
On Thu, Apr 09, 2020 at 07:57:14PM +0200, Nicolas George wrote: > Limin Wang (12020-04-09): > > My patch set try to make the loudnorm filter easy to use for end user if > > they > > want to process the volume in two pass. > > Yes: you are seeing a problem, and you want to fix it, that's fine. > > But the problem you are seeing is part of a wider problem, and fixing > the part you see will make fixing the whole problem harder. > > We did things like that many time, and it always caused problems. Let us > not do it again. Since your goal is "make things easier" and not "fix an > exploitable crash", we can take time to do things properly. > > > I have no clue how to make it common > > yet. > > Well, let us start discussing it right now. > > There is JSON-specific code in af_loudnorm.c, there should not be, I > think we should start here. > > My opinion is we should rework ffprobe's writers and move them to lavu. > That would be the first step. If someone can rework the ffprobe writers with a helper function, I'm glad to use it. I'm not code maintainer, if no other developer review my code and help to push it, then it's difficult to merge. The time cycle is too long, so I have no plan to do such work. > > What do you think? > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v1 1/4] avfilter/af_loudnorm: Add file option for the measured stats
On Thu, Apr 09, 2020 at 01:16:16PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-09): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/filters.texi | 3 +++ > > libavfilter/af_loudnorm.c | 54 +-- > > 2 files changed, 55 insertions(+), 2 deletions(-) > > NACK. > > If we are doing something like that, we should be doing it in a way that > works for all filters that output statistics, not just one: common > options name and syntax, common code. > > Doing it that way will only result in similar filters having different > features in a way that no user can understand. > > Same for the compact output. My patch set try to make the loudnorm filter easy to use for end user if they want to process the volume in two pass. I have no clue how to make it common yet. > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/7] avformat/hlsenc: Check some unchecked allocations
On Thu, Apr 09, 2020 at 11:48:10AM +0200, Andreas Rheinhardt wrote:
> Steven Liu:
> >
> >
> >> 2020年2月28日 下午5:53，Andreas Rheinhardt 写道：
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/hlsenc.c | 13 -
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index a281c379f0..18f40ff3ed 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -1610,6 +1610,8 @@ static int hls_start(AVFormatContext *s,
> >> VariantStream *vs)
> >> if (c->use_localtime_mkdir) {
> >> const char *dir;
> >> char *fn_copy = av_strdup(oc->url);
> >> +if (!fn_copy)
> >> +return AVERROR(ENOMEM);
> >> dir = av_dirname(fn_copy);
> >> if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
> >> av_log(oc, AV_LOG_ERROR, "Could not create directory
> >> %s with use_localtime_mkdir\n", dir);
> >> @@ -1770,6 +1772,8 @@ static int validate_name(int nb_vs, const char *fn)
> >> }
> >>
> >> fn_dup = av_strdup(fn);
> >> +if (!fn_dup)
> >> +return AVERROR(ENOMEM);
> >> filename = av_basename(fn);
> >> subdir_name = av_dirname(fn_dup);
> >>
> >> @@ -2139,6 +2143,8 @@ static int update_master_pl_info(AVFormatContext *s)
> >> int ret = 0;
> >>
> >> fn1 = av_strdup(s->url);
> >> +if (!fn1)
> >> +return AVERROR(ENOMEM);
> > It’s unnecessary here,
> > I have checked all strdup return checker in hlsenc some month ago, and
> > double check the workflow in update_master_pl_info,
> > It's the safe whether you check the strdup or not.
> > Reference commit id: 61aa77272a25d83e5ce5c63d93c64bb9a3e15557
>
> If these strdups fail, the relevant dirnames will be wrong. While you
> don't get segfaults, you will not create the files at the right
> destinations. We should rather error out instead.
Sorry, it seems that I remove these checking when av_dirname claims to support
NULL for path in the API comments like glib dirname function. So I think it's
duplicate check if the function claims to support NULL. If have different
opinions, please add the checking anyway. I don't know why dirname support
NULL?
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_mix: Check sscanf() return value
On Sun, Mar 29, 2020 at 11:18:11AM +0200, Nicolas George wrote: > Limin Wang (12020-03-29): > > OK, update the patch to print a message and return error. > > Thanks. I have no objection to that new version, but I do not maintain > that code. ping for the patchset for merge. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v1] avfilter/src_movie: Fix the loop function of dynamic logo
ping this patch for review.
On Tue, Mar 17, 2020 at 06:55:00PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> The following command will attempt to create the input and overlay test
> sequence for you.
> ./ffmpeg -f lavfi -i color=white:duration=100:r=25:size=1280x720 input.mkv
> ./ffmpeg -f lavfi -i "testsrc=duration=5:size=320x240:rate=25" overlay.mkv
>
> Please try with below command and compare the final output.
> ./ffmpeg -y -filter_complex
> "movie=./input.mkv,setpts=PTS-STARTPTS[main];movie=./overlay.mkv:loop=5,setpts=PTS-STARTPTS[overlay];[main][overlay]overlay=10:10:
> enable='between(t,0,25)" test.mkv
>
> Without the patch applied, the overlay will repeat the last frame in
> overlay.mkv after the first loop.
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/src_movie.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> index 79423a8..2327046 100644
> --- a/libavfilter/src_movie.c
> +++ b/libavfilter/src_movie.c
> @@ -68,6 +68,8 @@ typedef struct MovieContext {
> int loop_count;
> int64_t discontinuity_threshold;
> int64_t ts_offset;
> +int64_t last_pts;
> +int64_t last_loop_pts;
>
> AVFormatContext *format_ctx;
> int eof;
> @@ -455,6 +457,7 @@ static int rewind_file(AVFilterContext *ctx)
> movie->st[i].done = 0;
> }
> movie->eof = 0;
> +movie->last_loop_pts = movie->last_pts;
> return 0;
> }
>
> @@ -565,6 +568,8 @@ static int movie_push_frame(AVFilterContext *ctx,
> unsigned out_id)
> if (frame->pts != AV_NOPTS_VALUE) {
> if (movie->ts_offset)
> frame->pts += av_rescale_q_rnd(movie->ts_offset, AV_TIME_BASE_Q,
> outlink->time_base, AV_ROUND_UP);
> +if (movie->last_loop_pts)
> +frame->pts += movie->last_loop_pts;
> if (st->discontinuity_threshold) {
> if (st->last_pts != AV_NOPTS_VALUE) {
> int64_t diff = frame->pts - st->last_pts;
> @@ -575,6 +580,7 @@ static int movie_push_frame(AVFilterContext *ctx,
> unsigned out_id)
> }
> }
> }
> +movie->last_pts =
> st->last_pts = frame->pts;
> }
> ff_dlog(ctx, "movie_push_frame(): file:'%s' %s\n", movie->file_name,
> --
> 2.9.5
>
--
Thanks,
Limin Wang
___
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 v9 3/4] avfilter/vf_showinfo: display H.26[45] user data unregistered sei message
ping this patch for merge, it'll dump the metadata and don't change API.
On Tue, Mar 17, 2020 at 06:54:08PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 79b79db..36b9bf1 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -23,6 +23,7 @@
> */
>
> #include
> +#include
>
> #include "libavutil/bswap.h"
> #include "libavutil/adler32.h"
> @@ -170,6 +171,39 @@ static void dump_content_light_metadata(AVFilterContext
> *ctx, AVFrameSideData *s
> metadata->MaxCLL, metadata->MaxFALL);
> }
>
> +static int string_is_print(const uint8_t *str)
> +{
> +while (isprint(*str)) str++;
> +return !*str;
> +}
> +
> +static void dump_sei_unregistered_metadata(AVFilterContext *ctx,
> AVFrameSideData *sd)
> +{
> +const int uuid_size = 16;
> +uint8_t *user_data = sd->data;
> +
> +if (sd->size < uuid_size) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data(%d < UUID(%d-bytes))",
> sd->size, uuid_size);
> +return;
> +}
> +
> +av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
> +av_log(ctx, AV_LOG_INFO, "UUID=");
> +for (int i = 0; i < uuid_size; i++) {
> +av_log(ctx, AV_LOG_INFO, "%02x", user_data[i]);
> +if (i == 3 || i == 5 || i == 7 || i == 9)
> +av_log(ctx, AV_LOG_INFO, "-");
> +}
> +av_log(ctx, AV_LOG_INFO, "\n");
> +
> +user_data += uuid_size;
> +/* Only print the user data details if it's string */
> +if (string_is_print(user_data)) {
> +av_log(ctx, AV_LOG_INFO, "User Data=");
> +av_log(ctx, AV_LOG_INFO, "%s", user_data);
> +}
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
> const char *color_range_str =
> av_color_range_name(frame->color_range);
> @@ -347,6 +381,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> av_log(ctx, AV_LOG_INFO, "GOP timecode - %s", tcbuf);
> break;
> }
> +case AV_FRAME_DATA_SEI_UNREGISTERED:
> +dump_sei_unregistered_metadata(ctx, sd);
> +break;
> default:
> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> bytes)",
> sd->type, sd->size);
> --
> 2.9.5
>
--
Thanks,
Limin Wang
___
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/libsrt: Change latency option to milliseconds
On Wed, Apr 08, 2020 at 09:34:45AM +0200, pkv wrote:
>
> Le 08/04/2020 à 3:45 am, Limin Wang a écrit :
> >On Wed, Apr 08, 2020 at 02:16:23AM +0200, pkv wrote:
> >>Hi
> >>
> >>Le 08/04/2020 à 12:33 am, Limin Wang a écrit :
> >>>On Tue, Apr 07, 2020 at 08:25:44PM +0200, pkv wrote:
> >>>>Hi
> >>>>
> >>>>new patch for latency option following the comments from N. George.
> >>>I recall I had submit a patchset for related option incliding latency.
> >>>https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200331140808.8839-2-lance.lmw...@gmail.com/
> >>hadn't spotted it; why was it not merged ?
> >>
> >>
> >>>Why I haven't change to use AV_OPT_TYPE_DURATION, for the latency can
> >>>be used in format srt://:port?latency=?, it's in unit of ms,
> >>>in addition, AV_OPT_TYPE_DURATION is in unit of second default, it'll
> >>>break the old user.
> >>i tested with ffmpeg.exe; the change to
> >>
> >>AV_OPT_TYPE_DURATION
> >>
> >>didn't seem to break anything.
> >>
> >>The default is still set to whatever the libsrt API has set (120 ms
> >>for transtype=live).
> >>
> >>Can you produce code broken by that change ?
> >What's your command line?
> >I recall If use AV_OPT_TYPE_DURATION for option, the default is in unit of
> >second if your
> >don't add suffix of ms, us. However the old is us, so it'll cause old user
> >setting broken.
> >
> Ok I get your point.
>
> here are the commands I tested with:
>
> ffmpeg.exe -re -i source.mp4 -c copy -f mpegts srt:://dest:port
>
> and
>
> ffmpeg.exe -re -i source.mp4 -c copy -f mpegts
> srt:://dest:port?latency=40
>
> These two don't break anything.
>
> But indeed
>
> ffmpeg.exe -re -i source.mp4 -c copy -latency=40 -f mpegts
> srt:://dest:port
>
> is breaking stuff.
>
> I'll revert the change suggested by N. George in that case.
I have ping for my old patchset for review, it change all the time related
option document
>
> Thanks.
>
> Regards
>
>
>
> >>Regards
> >>
> >>
> >>>>=
> >>>>
> >>>>Updated protocol doc for srt to specify the unit of various latency
> >>>>options.
> >>>>Furthermore the type of the latency options is changed to
> >>>>AV_OPT_TYPE_DURATION
> >>>>(following comment from N. George).
> >>>>
> >>>>The microsecond unit has caused confusion for both FFmpeg and
> >>>>obs-studio users:
> >>>>- https://github.com/Haivision/srt/issues/1223
> >>>>
> >>>>- https://obsproject.com/mantis/view.php?id=1617
> >>>>
> >>>>=
> >>>>
> >>>>Regards
> >>>>
> >>>> From 1dd49812553f44bc5f1ed60660a2365d6a036c97 Mon Sep 17 00:00:00 2001
> >>>>From: pkv
> >>>>Date: Tue, 7 Apr 2020 18:08:22 +0200
> >>>>Subject: [PATCH] avformat/libsrt: Document latency options unit
> >>>>
> >>>>Updated protocol doc for srt to specify the unit of various latency
> >>>>options.
> >>>>Furthermore the type of the latency options is changed to
> >>>>AV_OPT_TYPE_DURATION
> >>>>(following comment from N. George).
> >>>>
> >>>>The microsecond unit has caused confusion for both FFmpeg and obs-studio
> >>>>users:
> >>>>- https://github.com/Haivision/srt/issues/1223
> >>>>
> >>>>- https://obsproject.com/mantis/view.php?id=1617
> >>>>---
> >>>> doc/protocols.texi | 6 +++---
> >>>> libavformat/libsrt.c | 6 +++---
> >>>> 2 files changed, 6 insertions(+), 6 deletions(-)
> >>>>
> >>>>diff --git a/doc/protocols.texi b/doc/protocols.texi
> >>>>index e510019f2d..ebf9dec529 100644
> >>>>--- a/doc/protocols.texi
> >>>>+++ b/doc/protocols.texi
> >>>>@@ -1286,8 +1286,8 @@ IP Type of Service. Applies to sender only. Default
> >>>>value is 0xB8.
> >>>> @item ipttl=@var{ttl}
> >>>> IP Time To Live. Applies to sender only. Default value is 64.
> >>>>-@item latency
> >>>>-Timestamp-based Packet Delivery Delay.
> >>>>+@item latency=@var{microseconds}
> >>>>+Timestamp-based Packet Delivery Delay in
Re: [FFmpeg-devel] [PATCH v1 1/3] doc/protocols: clarify timeout and latency unit of measurement for SRT
ping the patchset.
On Tue, Mar 31, 2020 at 10:08:06PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/protocols.texi | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index e510019..7aa7585 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1255,7 +1255,7 @@ options.
> This protocol accepts the following options.
>
> @table @option
> -@item connect_timeout
> +@item connect_timeout=@var{milliseconds}
> Connection timeout; SRT cannot connect for RTT > 1500 msec
> (2 handshake exchanges) with the default connect timeout of
> 3 seconds. This option applies to the caller and rendezvous
> @@ -1286,7 +1286,7 @@ IP Type of Service. Applies to sender only. Default
> value is 0xB8.
> @item ipttl=@var{ttl}
> IP Time To Live. Applies to sender only. Default value is 64.
>
> -@item latency
> +@item latency=@var{microseconds}
> Timestamp-based Packet Delivery Delay.
> Used to absorb bursts of missed packet retransmissions.
> This flag sets both @option{rcvlatency} and @option{peerlatency}
> @@ -1297,7 +1297,7 @@ when side is sender and @option{rcvlatency}
> when side is receiver, and the bidirectional stream
> sending is not supported.
>
> -@item listen_timeout
> +@item listen_timeout=@var{microseconds}
> Set socket listen timeout.
>
> @item maxbw=@var{bytes/seconds}
> @@ -1377,7 +1377,7 @@ use a bigger maximum frame size, though not greater than
> @item pkt_size=@var{bytes}
> Alias for @samp{payload_size}.
>
> -@item peerlatency
> +@item peerlatency=@var{microseconds}
> The latency value (as described in @option{rcvlatency}) that is
> set by the sender side as a minimum value for the receiver.
>
> @@ -1389,7 +1389,7 @@ Not required on receiver (set to 0),
> key size obtained from sender in HaiCrypt handshake.
> Default value is 0.
>
> -@item rcvlatency
> +@item rcvlatency=@var{microseconds}
> The time that should elapse since the moment when the
> packet was sent and the moment when it's delivered to
> the receiver application in the receiving function.
> @@ -1407,7 +1407,7 @@ Set UDP receive buffer size, expressed in bytes.
> @item send_buffer_size=@var{bytes}
> Set UDP send buffer size, expressed in bytes.
>
> -@item timeout
> +@item timeout=@var{microseconds}
> Set raise error timeouts for read, write and connect operations. Note that
> the
> SRT library has internal timeouts which can be controlled separately, the
> value set here is only a cap on those.
> --
> 2.9.5
>
--
Thanks,
Limin Wang
___
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/libsrt: Change latency option to milliseconds
On Wed, Apr 08, 2020 at 02:16:23AM +0200, pkv wrote:
> Hi
>
> Le 08/04/2020 à 12:33 am, Limin Wang a écrit :
> >On Tue, Apr 07, 2020 at 08:25:44PM +0200, pkv wrote:
> >>Hi
> >>
> >>new patch for latency option following the comments from N. George.
> >I recall I had submit a patchset for related option incliding latency.
> >https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200331140808.8839-2-lance.lmw...@gmail.com/
>
> hadn't spotted it; why was it not merged ?
>
>
> >
> >Why I haven't change to use AV_OPT_TYPE_DURATION, for the latency can
> >be used in format srt://:port?latency=?, it's in unit of ms,
> >in addition, AV_OPT_TYPE_DURATION is in unit of second default, it'll
> >break the old user.
> i tested with ffmpeg.exe; the change to
>
> AV_OPT_TYPE_DURATION
>
> didn't seem to break anything.
>
> The default is still set to whatever the libsrt API has set (120 ms
> for transtype=live).
>
> Can you produce code broken by that change ?
What's your command line?
I recall If use AV_OPT_TYPE_DURATION for option, the default is in unit of
second if your
don't add suffix of ms, us. However the old is us, so it'll cause old user
setting broken.
>
> Regards
>
>
> >
> >>=
> >>
> >>Updated protocol doc for srt to specify the unit of various latency options.
> >>Furthermore the type of the latency options is changed to
> >>AV_OPT_TYPE_DURATION
> >>(following comment from N. George).
> >>
> >>The microsecond unit has caused confusion for both FFmpeg and
> >>obs-studio users:
> >>- https://github.com/Haivision/srt/issues/1223
> >>
> >>- https://obsproject.com/mantis/view.php?id=1617
> >>
> >>=
> >>
> >>Regards
> >>
> >> From 1dd49812553f44bc5f1ed60660a2365d6a036c97 Mon Sep 17 00:00:00 2001
> >>From: pkv
> >>Date: Tue, 7 Apr 2020 18:08:22 +0200
> >>Subject: [PATCH] avformat/libsrt: Document latency options unit
> >>
> >>Updated protocol doc for srt to specify the unit of various latency options.
> >>Furthermore the type of the latency options is changed to
> >>AV_OPT_TYPE_DURATION
> >>(following comment from N. George).
> >>
> >>The microsecond unit has caused confusion for both FFmpeg and obs-studio
> >>users:
> >>- https://github.com/Haivision/srt/issues/1223
> >>
> >>- https://obsproject.com/mantis/view.php?id=1617
> >>---
> >> doc/protocols.texi | 6 +++---
> >> libavformat/libsrt.c | 6 +++---
> >> 2 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/doc/protocols.texi b/doc/protocols.texi
> >>index e510019f2d..ebf9dec529 100644
> >>--- a/doc/protocols.texi
> >>+++ b/doc/protocols.texi
> >>@@ -1286,8 +1286,8 @@ IP Type of Service. Applies to sender only. Default
> >>value is 0xB8.
> >> @item ipttl=@var{ttl}
> >> IP Time To Live. Applies to sender only. Default value is 64.
> >>-@item latency
> >>-Timestamp-based Packet Delivery Delay.
> >>+@item latency=@var{microseconds}
> >>+Timestamp-based Packet Delivery Delay in microseconds.
> >> Used to absorb bursts of missed packet retransmissions.
> >> This flag sets both @option{rcvlatency} and @option{peerlatency}
> >> to the same value. Note that prior to version 1.3.0
> >>@@ -1389,7 +1389,7 @@ Not required on receiver (set to 0),
> >> key size obtained from sender in HaiCrypt handshake.
> >> Default value is 0.
> >>-@item rcvlatency
> >>+@item rcvlatency@var{microseconds}
> >> The time that should elapse since the moment when the
> >> packet was sent and the moment when it's delivered to
> >> the receiver application in the receiving function.
> >>diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> >>index 2d6fc4b7e7..5c61f9e0d7 100644
> >>--- a/libavformat/libsrt.c
> >>+++ b/libavformat/libsrt.c
> >>@@ -118,10 +118,10 @@ static const AVOption libsrt_options[] = {
> >> { "iptos", "IP Type of Service",
> >> OFFSET(iptos),AV_OPT_TYPE_INT, {
> >> .i64 = -1 }, -1, 255, .flags = D|E },
> >> { "inputbw","Estimated input stream rate",
> >> OFFSET(inputbw), AV_OPT_TYPE_INT64,{
> >> .i64 = -1 }, -1, INT64_MAX, .flags =
Re: [FFmpeg-devel] [PATCH v2] avformat/dashenc: remove the arbitrary restrictions for filename
On Wed, Apr 08, 2020 at 01:54:12AM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/dashenc.c | 28
> > 1 file changed, 12 insertions(+), 16 deletions(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 94d4639..f80f6f2 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -1832,28 +1832,24 @@ static void dashenc_delete_file(AVFormatContext *s,
> > char *filename) {
> > static int dashenc_delete_segment_file(AVFormatContext *s, const char*
> > file)
> > {
> > DASHContext *c = s->priv_data;
> > -size_t dirname_len, file_len;
> > -char filename[1024];
> > -
> > -dirname_len = strlen(c->dirname);
> > -if (dirname_len >= sizeof(filename)) {
> > -av_log(s, AV_LOG_WARNING, "Cannot delete segments as the directory
> > path is too long: %"PRIu64" characters: %s\n",
> > -(uint64_t)dirname_len, c->dirname);
> > -return AVERROR(ENAMETOOLONG);
> > -}
> > +char *filename;
> > +AVBPrint buf;
> >
> > -memcpy(filename, c->dirname, dirname_len);
> > +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
> >
> > -file_len = strlen(file);
> > -if ((dirname_len + file_len) >= sizeof(filename)) {
> > -av_log(s, AV_LOG_WARNING, "Cannot delete segments as the path is
> > too long: %"PRIu64" characters: %s%s\n",
> > -(uint64_t)(dirname_len + file_len), c->dirname, file);
> > -return AVERROR(ENAMETOOLONG);
> > +av_bprintf(, "%s%s", c->dirname, file);
> > +if (!av_bprint_is_complete()) {
> > +av_bprint_finalize(, NULL);
> > +return AVERROR(ENOMEM);
> > +}
> > +if (av_bprint_finalize(, ) < 0) {
>
> No, don't finalize the AVBPrint -- this will make an allocation even if
> the string fits into the internal buffer of the AVBPrint. Instead simply
> use buf.str directly for dashenc_delete_file().
OK, I have update the patch, please help to review whether my understand is
correct.
thx.
>
> - Andreas
>
> > +av_log(s, AV_LOG_WARNING, "Out of memory for filename\n");
> > +return AVERROR(ENOMEM);
> > }
> >
> > -memcpy(filename + dirname_len, file, file_len + 1); // include the
> > terminating zero
> > dashenc_delete_file(s, filename);
> >
> > +av_freep();
> > return 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".
--
Thanks,
Limin Wang
___
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 v1] avformat/dashenc: use av_asprintf()
On Tue, Apr 07, 2020 at 07:08:56PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/dashenc.c | 23 ++-
> > 1 file changed, 6 insertions(+), 17 deletions(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 94d4639..0c281a4 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -1832,27 +1832,16 @@ static void dashenc_delete_file(AVFormatContext *s,
> > char *filename) {
> > static int dashenc_delete_segment_file(AVFormatContext *s, const char*
> > file)
> > {
> > DASHContext *c = s->priv_data;
> > -size_t dirname_len, file_len;
> > -char filename[1024];
> > -
> > -dirname_len = strlen(c->dirname);
> > -if (dirname_len >= sizeof(filename)) {
> > -av_log(s, AV_LOG_WARNING, "Cannot delete segments as the directory
> > path is too long: %"PRIu64" characters: %s\n",
> > -(uint64_t)dirname_len, c->dirname);
> > -return AVERROR(ENAMETOOLONG);
> > -}
> > +char *filename;
> >
> > -memcpy(filename, c->dirname, dirname_len);
> > -
> > -file_len = strlen(file);
> > -if ((dirname_len + file_len) >= sizeof(filename)) {
> > -av_log(s, AV_LOG_WARNING, "Cannot delete segments as the path is
> > too long: %"PRIu64" characters: %s%s\n",
> > -(uint64_t)(dirname_len + file_len), c->dirname, file);
> > -return AVERROR(ENAMETOOLONG);
> > +filename = av_asprintf("%s%s", c->dirname, file);
> > +if (!filename) {
> > +av_log(s, AV_LOG_WARNING, "Out of memory for filename\n");
> > +return AVERROR(ENOMEM);
> > }
> >
> > -memcpy(filename + dirname_len, file, file_len + 1); // include the
> > terminating zero
> > dashenc_delete_file(s, filename);
> > +av_free(filename);
> >
> > return 0;
> > }
> >
> It's good to remove these arbitrary restrictions, but you are adding an
> allocation whereas the old code had none. You can get the best of both
> approaches by using an AVBPrint.
sure, I'll change to use the AVBPrint.
>
> And the commit title should mention that you remove an arbitrary
> restriction on the length of filenames. This is more important than the
> switch from one function to another.
OK, will update it
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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/libsrt: Change latency option to milliseconds
{ "rcvlatency", "receive latency",
>OFFSET(rcvlatency), AV_OPT_TYPE_DURATION, { .i64 =
> -1 }, -1, INT64_MAX, .flags = D|E },
> +{ "peerlatency","peer latency",
>OFFSET(peerlatency), AV_OPT_TYPE_DURATION, { .i64 =
> -1 }, -1, INT64_MAX, .flags = D|E },
> { "tlpktdrop", "Enable receiver pkt drop",
>OFFSET(tlpktdrop),AV_OPT_TYPE_BOOL, { .i64 =
> -1 }, -1, 1, .flags = D|E },
> { "nakreport", "Enable receiver to send periodic NAK reports",
>OFFSET(nakreport),AV_OPT_TYPE_BOOL, { .i64 =
> -1 }, -1, 1, .flags = D|E },
> { "connect_timeout", "Connect timeout. Caller default: 3000, rendezvous
> (x 10)",OFFSET(connect_timeout), AV_OPT_TYPE_INT64, { .i64 = -1
> }, -1, INT64_MAX, .flags = D|E },
> --
> 2.24.1.windows.2
>
> ___
> 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,
Limin Wang
___
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 v3] avutil/frame: Use av_realloc_array()
ping. On Thu, Dec 26, 2019 at 08:33:38AM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavutil/frame.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/libavutil/frame.c b/libavutil/frame.c > index e403809..2e763ef 100644 > --- a/libavutil/frame.c > +++ b/libavutil/frame.c > @@ -696,11 +696,8 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame > *frame, > if (!buf) > return NULL; > > -if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1) > -return NULL; > - > -tmp = av_realloc(frame->side_data, > - (frame->nb_side_data + 1) * sizeof(*frame->side_data)); > +tmp = av_realloc_array(frame->side_data, > + frame->nb_side_data + 1, sizeof(*frame->side_data)); > if (!tmp) > return NULL; > frame->side_data = tmp; > -- > 2.9.5 > -- Thanks, Limin Wang ___ 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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Sat, Apr 04, 2020 at 11:42:06AM +0200, Nicolas George wrote: > Limin Wang (12020-04-04): > > I think it's caused by the keyframe flags, so have no clue how to check > > the beneficial for these fate testing. > > Take the actual files produced by the tests, possibly changing the > output format from framecrc to an actual format, and compare carefully > the version before the patch and the version after the patch. the md5 framecrc is generated by libavformat/tests/movenc.c, I have no clue how the movenc testing work and how to get the real input to check why the frame isn't bitexact as I haven't see any subtitle track. > > Tests are there for a reason. If you cannot explain exactly why a change > in a reference file is beneficial, then the patch is not acceptable. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ 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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Fri, Apr 03, 2020 at 11:23:59PM +0200, Michael Niedermayer wrote:
> On Fri, Apr 03, 2020 at 11:05:59PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/mux.c| 16
> > tests/ref/fate/binsub-movtextenc | 2 +-
> > tests/ref/fate/movenc| 50 +++
> > tests/ref/fate/sub2video | 86
> >
> > 4 files changed, 85 insertions(+), 69 deletions(-)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index cc2d1e2..dc897c2 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -548,6 +548,17 @@ fail:
> > return ret;
> > }
> >
> > +static int is_intra_only(enum AVCodecID id)
> > +{
> > +const AVCodecDescriptor *d = avcodec_descriptor_get(id);
> > +if (!d)
> > +return 0;
> > +if ((d->type == AVMEDIA_TYPE_VIDEO || d->type == AVMEDIA_TYPE_AUDIO) &&
> > +!(d->props & AV_CODEC_PROP_INTRA_ONLY))
> > +return 0;
> > +return 1;
> > +}
>
> this should not be duplicated with code in utils.c
OK
>
>
> > +
> > #define AV_PKT_FLAG_UNCODED_FRAME 0x2000
> >
> > /* Note: using sizeof(AVFrame) from outside lavu is unsafe in general, but
> > @@ -664,6 +675,11 @@ static int compute_muxer_pkt_fields(AVFormatContext
> > *s, AVStream *st, AVPacket *
> > frac_add(st->internal->priv_pts, (int64_t)st->time_base.den *
> > st->time_base.num);
> > break;
> > }
> > +
> > +/* update flags */
> > +if (is_intra_only(st->codecpar->codec_id))
> > +pkt->flags |= AV_PKT_FLAG_KEY;
> > +
>
> it may make sense to store the AVCodecDescriptor and not search it again for
> each packet. But then the "is_intra_only" itself also does not change so that
> should itself be computet just once per stream
Do you say we should add a is_intra_only field in AVStream to compute at
beginning,
however it'll change the API header. So I prefer to use is_intra_only()
function first,
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
> ___
> 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,
Limin Wang
___
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 v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Fri, Apr 03, 2020 at 05:19:08PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/mux.c| 16
> > tests/ref/fate/binsub-movtextenc | 2 +-
> > tests/ref/fate/movenc| 50 +++
> > tests/ref/fate/sub2video | 86
> >
> > 4 files changed, 85 insertions(+), 69 deletions(-)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index cc2d1e2..dc897c2 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -548,6 +548,17 @@ fail:
> > return ret;
> > }
> >
> > +static int is_intra_only(enum AVCodecID id)
> > +{
> > +const AVCodecDescriptor *d = avcodec_descriptor_get(id);
> > +if (!d)
> > +return 0;
> > +if ((d->type == AVMEDIA_TYPE_VIDEO || d->type == AVMEDIA_TYPE_AUDIO) &&
> > +!(d->props & AV_CODEC_PROP_INTRA_ONLY))
> > +return 0;
> > +return 1;
> > +}
> > +
> > #define AV_PKT_FLAG_UNCODED_FRAME 0x2000
> >
> > /* Note: using sizeof(AVFrame) from outside lavu is unsafe in general, but
> > @@ -664,6 +675,11 @@ static int compute_muxer_pkt_fields(AVFormatContext
> > *s, AVStream *st, AVPacket *
> > frac_add(st->internal->priv_pts, (int64_t)st->time_base.den *
> > st->time_base.num);
> > break;
> > }
> > +
> > +/* update flags */
> > +if (is_intra_only(st->codecpar->codec_id))
> > +pkt->flags |= AV_PKT_FLAG_KEY;
> > +
> > return 0;
> > }
> > FF_ENABLE_DEPRECATION_WARNINGS
>
> You have added the check to code that is deprecated and slated to be
> removed. Maybe it would be better to add it to prepare_input_packet()
> instead?
OK, I'll move the check to prepare_input_packet.
>
> > diff --git a/tests/ref/fate/binsub-movtextenc
> > b/tests/ref/fate/binsub-movtextenc
> > index 78c05f4..a8f94b7 100644
> > --- a/tests/ref/fate/binsub-movtextenc
> > +++ b/tests/ref/fate/binsub-movtextenc
> > @@ -1 +1 @@
> > -35adf776cd73e808186ae7124445f4b8
> > +fc6d07679ac1f718aa50de687924cd97
> > diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
> > index 637a347..fb39b98 100644
> > --- a/tests/ref/fate/movenc
> > +++ b/tests/ref/fate/movenc
> > @@ -2,17 +2,17 @@ write_data len 36, time nopts, type header atom ftyp
> > write_data len 2389, time nopts, type header atom -
> > write_data len 788, time 100, type sync atom moof
> > write_data len 110, time nopts, type trailer atom -
> > -66cf48604f039aa9a51711786f5c8778 3323 non-empty-moov
> > +5f401347fc3c771b819e2449d69d4861 3323 non-empty-moov
> > write_data len 36, time nopts, type header atom ftyp
> > write_data len 2721, time nopts, type header atom -
> > write_data len 908, time 97, type sync atom moof
> > write_data len 110, time nopts, type trailer atom -
> > -04b2e86f455af94f9258b8d66dbf71f5 3775 non-empty-moov-elst
> > +4267feee527adf8cd4f7b36ac0fc0872 3775 non-empty-moov-elst
> > write_data len 36, time nopts, type header atom ftyp
> > write_data len 2629, time nopts, type header atom -
> > write_data len 908, time 100, type sync atom moof
> > write_data len 110, time nopts, type trailer atom -
> > -e9f6fa032d6d8265d67aef5de81a48bf 3683 non-empty-moov-no-elst
> > +44077b9ad45f3e16fafe4e5ada54e9b0 3683 non-empty-moov-no-elst
> > write_data len 24, time nopts, type header atom ftyp
> [...]
> > -1, 22564, 22564, 2127000, 2133, 0x670c11a5, F=0x0
> > +1, 22564, 22564, 2127000, 2133, 0x670c11a5
> > 0, 1139, 1139,1, 518400, 0xbab197ea
> > -1, 227834000, 227834000, 1262000, 1264, 0xc1d9fc57, F=0x0
> > +1, 227834000, 227834000, 1262000, 1264, 0xc1d9fc57
> > 0, 1140, 1140, 1, 518400, 0xb046dd30
> > 0, 1145, 1145,1, 518400, 0xbab197ea
> >
> Have you checked whether all these changes are beneficial?
I think it's caused by the keyframe flags, so have no clue how to check
the beneficial for these fate testing.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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 v1 2/2] avcodec/mpeg12enc: Support mpeg2 encoder profile with const options
On Fri, Apr 03, 2020 at 03:47:09PM +, Fu, Linjie wrote: > > From: ffmpeg-devel On Behalf Of > > Limin Wang > > Sent: Friday, April 3, 2020 22:55 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v1 2/2] avcodec/mpeg12enc: Support > > mpeg2 encoder profile with const options > > > > On Fri, Apr 03, 2020 at 04:25:15PM +0200, Hendrik Leppkes wrote: > > > On Fri, Apr 3, 2020 at 3:12 PM wrote: > > > > > > > > From: Limin Wang > > > > > > > > make setting profile more user friendly > > > > > > > > > > Please make sure API users can still set it through avctx->profile, > > > otherwise this would be an API break. > > > > Right, I'll update the patch to check avctx->profile != unknown, then > > overwrite > > the s->profile with it to void API break. > > > Would it be better to determine the profile with a priority like: > 1.s->profile; then > 2. avctx->profile; then > 3. a default profile; > in case both avctx->profile and s->profile are set? > > If user set a profile explicitly (through either option in cmdline or > av_opt_set()), > above priority seems to be natural. (and libx264 [1] has the same logic) I'm OK with the logic, will update the patch change the priority. thx. > > - Linjie > > [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L806 > > ___ > 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, Limin Wang ___ 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 v1 2/2] avcodec/mpeg12enc: Support mpeg2 encoder profile with const options
On Fri, Apr 03, 2020 at 04:25:15PM +0200, Hendrik Leppkes wrote: > On Fri, Apr 3, 2020 at 3:12 PM wrote: > > > > From: Limin Wang > > > > make setting profile more user friendly > > > > Please make sure API users can still set it through avctx->profile, > otherwise this would be an API break. Right, I'll update the patch to check avctx->profile != unknown, then overwrite the s->profile with it to void API break. > > - 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". -- Thanks, Limin Wang ___ 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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Fri, Mar 27, 2020 at 01:47:10AM +0100, Michael Niedermayer wrote:
> On Thu, Mar 26, 2020 at 10:47:37AM +0100, Anton Khirnov wrote:
> > Quoting Andreas Rheinhardt (2020-03-20 17:51:41)
> > > Jan Ekström:
> > > > On Fri, Mar 20, 2020 at 5:45 PM wrote:
> > > >>
> > > >> From: Limin Wang
> > > >>
> > > >> This fixes webvtt segment output.
> > > >>
> > > >> Please testing with the following command and check the output:
> > > >> ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f
> > > >> segment -segment_time 10 \
> > > >> -segment_list_size 0 -segment_list sub.m3u8 -segment_format
> > > >> webvtt -scodec webvtt sub-%d.vtt
> > > >>
> > > >>
> > > >> Signed-off-by: Limin Wang
> > > >> ---
> > > >> fftools/ffmpeg.c | 1 +
> > > >> tests/ref/fate/binsub-movtextenc | 2 +-
> > > >> tests/ref/fate/sub2video | 86
> > > >> 3 files changed, 45 insertions(+), 44 deletions(-)
> > > >>
> > > >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > >> index aaaf241314..c5a2d0731d 100644
> > > >> --- a/fftools/ffmpeg.c
> > > >> +++ b/fftools/ffmpeg.c
> > > >> @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> > > >> else
> > > >> pkt.pts += av_rescale_q(sub->end_display_time,
> > > >> (AVRational){ 1, 1000 }, ost->mux_timebase);
> > > >> }
> > > >> +pkt.flags |= AV_PKT_FLAG_KEY;
> > > >> pkt.dts = pkt.pts;
> > > >> output_packet(of, , ost, 0);
> > > >> }
> > > >
> > > > I do wonder if this is just a case of people forgetting to set the
> > > > flag for the relevant packets in the relevant modules?
> > > >
> > > > I'm not sure if all API users should be forced to handle this
> > > > separately. If the packets are decode'able by themselves, they should
> > > > be marked as such.
> > > >
> > > > (Unfortunately, this probably means that all subtitle encoders and
> > > > text-based subtitle format demuxers would have to be updated where
> > > > this flag is not set)
> > > >
> > > av_read_frame() already sets the AV_PKT_FLAG_KEY-flag for all subtitle
> > > packets (see is_intra_only() in libavformat/utils.c; the subtitle
> > > demuxer based around FFDemuxSubtitlesQueues actually have the flag set
> > > even before it reaches is_intra_only()). One could do something similar
> > > in libavformat/mux.c.
> > > But are we actually sure that all subtitle packets are decodable by
> > > themselves? IIRC this is not true for all PGS subtitles.
> > >
> > > - Andreas
> > >
> > > PS: The semantics of the AV_CODEC_PROP_INTRA_ONLY-flag seem to be based
> > > around the assumption that subtitle packets are always intra-only: It is
> > > only for video and audio-codecs only.
> >
> > I would interpret it as simply not being defined for subtitles, rather
> > than saying they are all always intra only. So we can always add new
> > semantics for subtitles to it.
>
> +1
I have updated the patch, please review whether it's expected.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
> ___
> 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,
Limin Wang
___
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 v1 3/4] avformat: add subtitle support in master playlist m3u8
On Sun, Mar 29, 2020 at 04:32:06PM +0800, Steven Liu wrote:
>
>
> > 2020年3月26日 下午9:56，lance.lmw...@gmail.com 写道：
> >
> > From: Limin Wang
> >
> > Test with the following command for the webvtt subtitle:
> > $ ./ffmpeg -y -i input_with_subtitle.mkv \
> > -b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
> > -b:a:0 256k \
> > -c:s webvtt -c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0 -map 0:s:0 \
> > -f hls -var_stream_map "v:0,a:0,s:0,sgroup:subtitle” \
> What about add the example into doc/muxer.texi ?
Sure, I have add one example into muxer.texi and send updated the patch.
> > -master_pl_name master.m3u8 -t 300 -hls_time 10 -hls_init_time 4
> > -hls_list_size \
> > 10 -master_pl_publish_rate 10 -hls_flags \
> > delete_segments+discont_start+split_by_time ./tmp/video.m3u8
> >
> > Check the master m3u8:
> > $ cat tmp/master.m3u8
> > #EXTM3U
> > #EXT-X-VERSION:3
> > #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subtitle",NAME="subtitle_0",DEFAULT=YES,URI="video_vtt.m3u8"
> > #EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33",SUBTITLES="subtitle"
> > video.m3u8
> >
> > Check the result by convert to mkv:
> > $ ./ffmpeg -strict experimental -i ./tmp/master.m3u8 -c:v copy -c:a mp2
> > -c:s srt ./test.mkv
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/dashenc.c | 2 +-
> > libavformat/hlsenc.c | 26 --
> > libavformat/hlsplaylist.c | 17 -
> > libavformat/hlsplaylist.h | 4 +++-
> > 4 files changed, 44 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 94d463972a..d1fe90b00c 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -1311,7 +1311,7 @@ static int write_manifest(AVFormatContext *s, int
> > final)
> > get_hls_playlist_name(playlist_file, sizeof(playlist_file),
> > NULL, i);
> > ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
> > playlist_file, agroup,
> > - codec_str_ptr, NULL);
> > + codec_str_ptr, NULL, NULL);
> > }
> > dashenc_io_close(s, >m3u8_out, temp_filename);
> > if (use_rename)
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index a0a3a4647b..d7b9c0e20a 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -164,6 +164,7 @@ typedef struct VariantStream {
> > int is_default; /* default status of audio group */
> > char *language; /* audio lauguage name */
> > char *agroup; /* audio group name */
> > +char *sgroup; /* subtitle group name */
> > char *ccgroup; /* closed caption group name */
> > char *baseurl;
> > char *varname; // variant name
> > @@ -1289,7 +1290,9 @@ static int create_master_playlist(AVFormatContext *s,
> > unsigned int i, j;
> > int ret, bandwidth;
> > const char *m3u8_rel_name = NULL;
> > +const char *vtt_m3u8_rel_name = NULL;
> > char *ccgroup;
> > +char *sgroup = NULL;
> > ClosedCaptionsStream *ccs;
> > const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
> > int is_file_proto = proto && !strcmp(proto, "file");
> > @@ -1412,13 +1415,24 @@ static int create_master_playlist(AVFormatContext
> > *s,
> > vs->ccgroup);
> > }
> >
> > +if (vid_st && vs->sgroup) {
> > +sgroup = vs->sgroup;
> > +vtt_m3u8_rel_name = get_relative_url(hls->master_m3u8_url,
> > vs->vtt_m3u8_name);
> > +if (!vtt_m3u8_rel_name) {
> > +av_log(s, AV_LOG_WARNING, "Unable to find relative
> > subtitle URL\n");
> > +break;
> > +}
> > +
> > +ff_hls_write_subtitle_rendition(hls->m3u8_out, sgroup,
> > vtt_m3u8_rel_name, vs->language, i, hls->has_default_key ? vs->is_default :
> > 1);
> > +}
> > +
> > if (!hls->has_default_key || !hls->has_video_m3u8) {
> > ff_hls_write_stream_info(vid_st, hls->m3u8_out, bandwidth,
> > m3u8_rel_name,
> > -aud_st ? vs->agroup : NULL, vs->codec_attr, ccgroup);
> > +aud_st ? vs->
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: skip first char after compare path with path separator
On Sun, Mar 29, 2020 at 11:14:37AM +0800, Steven Liu wrote: > before patch: > ffmpeg -i input -g 25 -y -c:a aac -map 0:v -map 0:a > -master_pl_name playlist.m3u8 -var_stream_map "v:0,a:0" c%v.m3u8" > the master file playlist.m3u8 context is > #EXTM3U > #EXT-X-VERSION:3 > > #EXT-X-STREAM-INF:BANDWIDTH=2890800,RESOLUTION=1920x800,CODECS="avc1.640028,mp4a.40.2" > /c0.m3u8 > > this is incorrect. > after patch: > #EXTM3U > #EXT-X-VERSION:3 > > #EXT-X-STREAM-INF:BANDWIDTH=2890800,RESOLUTION=1920x800,CODECS="avc1.640028,mp4a.40.2" > c0.m3u8 > I have send patch set to fix the issue before. Please see: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200326135700.11167-1-lance.lmw...@gmail.com/ > Reported-by: Ibrahim Tachijian > Signed-off-by: Steven Liu > --- > libavformat/hlsenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c > index b4c72b6e54..a3c59432c5 100644 > --- a/libavformat/hlsenc.c > +++ b/libavformat/hlsenc.c > @@ -1260,7 +1260,7 @@ static const char* get_relative_url(const char > *master_url, const char *media_ur > } > } > > -return media_url + base_len; > +return media_url + 1 + base_len; > } > > static int64_t get_stream_bit_rate(AVStream *stream) > -- > 2.25.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". -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_mix: Check sscanf() return value
On Sun, Mar 29, 2020 at 01:32:59AM +0100, Nicolas George wrote: > Limin Wang (12020-03-29): > > Anyway if the user option is typo, > > the result may be unexpected for user. > > But your change does not address that. For that, you would print a > message and return an error. Which is probably the right thing to do, > actually. OK, update the patch to print a message and return error. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] avfilter/af_adelay: Check sscanf() return value
On Sat, Mar 28, 2020 at 07:06:13PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 28, 2020 at 08:17:33AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/af_adelay.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/af_adelay.c b/libavfilter/af_adelay.c
> > index c964777..2bb05e7 100644
> > --- a/libavfilter/af_adelay.c
> > +++ b/libavfilter/af_adelay.c
> > @@ -155,7 +155,10 @@ static int config_input(AVFilterLink *inlink)
> > ret = av_sscanf(arg, "%d%c", >delay, );
> > if (ret != 2 || type != 'S') {
> > div = type == 's' ? 1.0 : 1000.0;
> > -av_sscanf(arg, "%f", );
> > +if (av_sscanf(arg, "%f", ) != 1) {
>
> > +av_log(ctx, AV_LOG_ERROR, "Invalid syntax.\n");
>
> I suggest to print the part of the string that is invalid.
> This would make it easier to the user to know where the error is
Fixed and update, thx.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No human being will ever know the Truth, for even if they happen to say it
> by chance, they would not even known they had done so. -- Xenophanes
> ___
> 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,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_mix: Check sscanf() return value
On Sun, Mar 29, 2020 at 12:31:40AM +0100, Nicolas George wrote: > Limin Wang (12020-03-29): > > If av_sscanf failed, s->weights[i] is invalid data and can't be used > > further. > > I think you are mistaken: if av_sscanf() fails, s->weights[i] stays > unchanged: it was 0, it's still 0. > > > As the old code allow to use the last weights, so I use > > continue to avoid invalid access only. > > It's not invalid, it's 0. > > > Do you think it's better to > > print out one warning message? > > With this correction, I think this change is not necessary at all. Yes, the result is same with my change. Anyway if the user option is typo, the result may be unexpected for user. > > Regards, > > -- > Nicolas George > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_mix: Check sscanf() return value
On Sat, Mar 28, 2020 at 08:10:51PM +0100, Nicolas George wrote: > lance.lmw...@gmail.com (12020-03-28): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavfilter/vf_mix.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > Why? What do you expect to change with this patch, and how is it > supposed to be better? If av_sscanf failed, s->weights[i] is invalid data and can't be used further. As the old code allow to use the last weights, so I use continue to avoid invalid access only. Do you think it's better to print out one warning message? > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ 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 v1 1/2] avfilter/vf_showinfo: check if the s12m data size is valid
On Fri, Mar 27, 2020 at 01:42:02AM +0100, Michael Niedermayer wrote: > On Wed, Mar 25, 2020 at 06:45:47PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavfilter/vf_showinfo.c | 4 > > 1 file changed, 4 insertions(+) > > will apply Thanks, please help to review patchset#2, it'll check the valid of tc[0] to avoid buffer overflow access. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In a rich man's house there is no place to spit but his face. > -- Diogenes of Sinope > ___ > 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, Limin Wang ___ 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 v1 3/3] avfilter/af_adelay: Check sscanf() return value
On Fri, Mar 27, 2020 at 08:34:02PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 26, 2020 at 07:04:24AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/af_adelay.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/af_adelay.c b/libavfilter/af_adelay.c
> > index c9647771f2..7f498ba190 100644
> > --- a/libavfilter/af_adelay.c
> > +++ b/libavfilter/af_adelay.c
> > @@ -155,7 +155,8 @@ static int config_input(AVFilterLink *inlink)
> > ret = av_sscanf(arg, "%d%c", >delay, );
> > if (ret != 2 || type != 'S') {
> > div = type == 's' ? 1.0 : 1000.0;
> > -av_sscanf(arg, "%f", );
> > +if (av_sscanf(arg, "%f", ) != 1)
> > +return AVERROR(EINVAL);
>
> If this case occurs is it clear to the user what is the problem ?
> Maybe an error message should be added here
Yes, I have add error message and update the patch, please review it.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch
> ___
> 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,
Limin Wang
___
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 v1] avcodec/decode: increase nb_bsfs after av_bsf_alloc in case alloc failed
ping for review, thanks.
On Tue, Dec 24, 2019 at 09:06:18AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/decode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index cd275bacc4..1ebbca4724 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -227,13 +227,13 @@ int ff_decode_bsfs_init(AVCodecContext *avctx)
> goto fail;
> }
> s->bsfs = tmp;
> -s->nb_bsfs++;
>
> -ret = av_bsf_alloc(filter, >bsfs[s->nb_bsfs - 1]);
> +ret = av_bsf_alloc(filter, >bsfs[s->nb_bsfs]);
> if (ret < 0) {
> av_freep();
> goto fail;
> }
> +s->nb_bsfs++;
>
> if (s->nb_bsfs == 1) {
> /* We do not currently have an API for passing the input
> timebase into decoders,
> --
> 2.21.0
>
--
Thanks,
Limin Wang
___
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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Fri, Mar 20, 2020 at 06:03:53PM +0200, Jan Ekström wrote:
> On Fri, Mar 20, 2020 at 5:45 PM wrote:
> >
> > From: Limin Wang
> >
> > This fixes webvtt segment output.
> >
> > Please testing with the following command and check the output:
> > ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment
> > -segment_time 10 \
> > -segment_list_size 0 -segment_list sub.m3u8 -segment_format webvtt
> > -scodec webvtt sub-%d.vtt
> >
> >
> > Signed-off-by: Limin Wang
> > ---
> > fftools/ffmpeg.c | 1 +
> > tests/ref/fate/binsub-movtextenc | 2 +-
> > tests/ref/fate/sub2video | 86
> > 3 files changed, 45 insertions(+), 44 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index aaaf241314..c5a2d0731d 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> > else
> > pkt.pts += av_rescale_q(sub->end_display_time,
> > (AVRational){ 1, 1000 }, ost->mux_timebase);
> > }
> > +pkt.flags |= AV_PKT_FLAG_KEY;
> > pkt.dts = pkt.pts;
> > output_packet(of, , ost, 0);
> > }
>
> I do wonder if this is just a case of people forgetting to set the
> flag for the relevant packets in the relevant modules?
>
> I'm not sure if all API users should be forced to handle this
> separately. If the packets are decode'able by themselves, they should
> be marked as such.
If we're using -c:s copy for the subtitle, the flag is set in
ff_subtitles_queue_insert() of libavformat/subtitles.c.
>
> (Unfortunately, this probably means that all subtitle encoders and
> text-based subtitle format demuxers would have to be updated where
> this flag is not set)
subtitle encoder haven no way to set the flag in the encoder api now.
>
> Best regards,
> Jan
> _______
> 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,
Limin Wang
___
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 v9 2/4] avcodec/hevc_sei: add support for user data unregistered SEI message
On Wed, Mar 18, 2020 at 12:13:33AM +, Derek Buitenhuis wrote: > On 17/03/2020 23:11, Limin Wang wrote: > > The user data unregistered allows arbitrary data to be carried in the > > bitstream, > > for example, ROI info, time info etc. For the real support patch, please > > refer to > > the pending patch series 7, 8 in below link: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200107050355.17503-1-lance.lmw...@gmail.com/ > > I understand what the SEI does. I was inquiring as to what the usecase you had > in mind for it specifically. I don't like the idea of adding APIs that are > only > theorically useful - that is, what data is intended to be shoved in there? In order to identify the source of time used in the live event, the encoder system can insert a time mode-source code along with each embedded precision time stamp. Each time mode-source code will be inserted into the H.264/H.265 bitstream as an SEI message of type User Data (Unregistered). The format is self-defined json string > > - Derek > ___ > 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, Limin Wang ___ 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 v9 2/4] avcodec/hevc_sei: add support for user data unregistered SEI message
On Tue, Mar 17, 2020 at 05:25:29PM +, Derek Buitenhuis wrote: > On 17/03/2020 10:54, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/hevc_sei.c | 31 +++ > > libavcodec/hevc_sei.h | 6 ++ > > libavcodec/hevcdec.c| 14 ++ > > tests/ref/fate/hevc-monochrome-crop | 3 +++ > > 4 files changed, 54 insertions(+) > > Apologies if I missed this in previous iterations. > > What is the proposed usecase? The user data unregistered allows arbitrary data to be carried in the bitstream, for example, ROI info, time info etc. For the real support patch, please refer to the pending patch series 7, 8 in below link: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200107050355.17503-1-lance.lmw...@gmail.com/ > > - Derek > ___ > 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, Limin Wang ___ 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 v1 2/2] avfilter/vf_overlay: remove the duplicated framesync option
On Tue, Mar 17, 2020 at 01:09:59PM +0100, Paul B Mahol wrote:
> NAK
>
> Was added explicitly by Michael, to keep all scripts working.
> So you should not sent such patches.
Sorry, I have realized it'll break the short option without eof_action.
please ignore the patch.
>
> On 3/17/20, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > After applied the patch, we can change default eof_action from repeat to
> > pass still.
> >
> > ./ffmpeg -y -filter_complex
> > "movie=./input.mkv,setpts=PTS-STARTPTS[main];movie=./overlay.mkv:loop=2,setpts=PTS-STARTPTS[overlay];[main][overlay]overlay=10:10:
> > enable='between(t,0,25):eof_action=pass" test.mkv
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_overlay.c | 8
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> > index 0a8f089c0d..a481f74076 100644
> > --- a/libavfilter/vf_overlay.c
> > +++ b/libavfilter/vf_overlay.c
> > @@ -993,16 +993,9 @@ static int activate(AVFilterContext *ctx)
> > static const AVOption overlay_options[] = {
> > { "x", "set the x expression", OFFSET(x_expr), AV_OPT_TYPE_STRING,
> > {.str = "0"}, CHAR_MIN, CHAR_MAX, FLAGS },
> > { "y", "set the y expression", OFFSET(y_expr), AV_OPT_TYPE_STRING,
> > {.str = "0"}, CHAR_MIN, CHAR_MAX, FLAGS },
> > -{ "eof_action", "Action to take when encountering EOF from secondary
> > input ",
> > -OFFSET(fs.opt_eof_action), AV_OPT_TYPE_INT, { .i64 =
> > EOF_ACTION_REPEAT },
> > -EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
> > -{ "repeat", "Repeat the previous frame.", 0, AV_OPT_TYPE_CONST, {
> > .i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
> > -{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, {
> > .i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
> > -{ "pass", "Pass through the main input.", 0, AV_OPT_TYPE_CONST, {
> > .i64 = EOF_ACTION_PASS }, .flags = FLAGS, "eof_action" },
> > { "eval", "specify when to evaluate expressions", OFFSET(eval_mode),
> > AV_OPT_TYPE_INT, {.i64 = EVAL_MODE_FRAME}, 0, EVAL_MODE_NB-1, FLAGS, "eval"
> > },
> > { "init", "eval expressions once during initialization", 0,
> > AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_INIT}, .flags = FLAGS, .unit = "eval" },
> > { "frame", "eval expressions per-frame", 0,
> > AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_FRAME}, .flags = FLAGS, .unit = "eval" },
> > -{ "shortest", "force termination when the shortest input terminates",
> > OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > { "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT,
> > {.i64=OVERLAY_FORMAT_YUV420}, 0, OVERLAY_FORMAT_NB-1, FLAGS, "format" },
> > { "yuv420", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV420},
> > .flags = FLAGS, .unit = "format" },
> > { "yuv422", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV422},
> > .flags = FLAGS, .unit = "format" },
> > @@ -1010,7 +1003,6 @@ static const AVOption overlay_options[] = {
> > { "rgb","", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_RGB},
> > .flags = FLAGS, .unit = "format" },
> > { "gbrp", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_GBRP},
> > .flags = FLAGS, .unit = "format" },
> > { "auto", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_AUTO},
> > .flags = FLAGS, .unit = "format" },
> > -{ "repeatlast", "repeat overlay of the last overlay frame",
> > OFFSET(fs.opt_repeatlast), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
> > { "alpha", "alpha format", OFFSET(alpha_format), AV_OPT_TYPE_INT,
> > {.i64=0}, 0, 1, FLAGS, "alpha_format" },
> > { "straight", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, .flags =
> > FLAGS, .unit = "alpha_format" },
> > { "premultiplied", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, .flags =
> > FLAGS, .unit = "alpha_format" },
> > --
> > 2.21.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".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/libx264: return error if unknown picture type encountered
On Sat, Jan 18, 2020 at 03:27:12PM +0100, Michael Niedermayer wrote: > On Sat, Jan 18, 2020 at 06:38:25AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/libx264.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > > index ca8f6c0..4fef0be 100644 > > --- a/libavcodec/libx264.c > > +++ b/libavcodec/libx264.c > > @@ -471,7 +471,8 @@ static int X264_frame(AVCodecContext *ctx, AVPacket > > *pkt, const AVFrame *frame, > > pict_type = AV_PICTURE_TYPE_B; > > break; > > default: > > -pict_type = AV_PICTURE_TYPE_NONE; > > +av_log(ctx, AV_LOG_ERROR, "Unknown picture type encountered.\n"); > > +return AVERROR_EXTERNAL; > > } > > This builds now but it does not work > > ./ffmpeg -i mm-short.mpg -t 1 test.mp4 > > [libx264 @ 0x2d2c1c0] Unknown picture type encountered. > Video encoding failed I have submit a patch to fix the unknown picture type issue. I have do some basic valid testing. Please help to review it. I'm not sure whether it's better to check the nnal zero to return immediately. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/libx264: return error if unknown picture type encountered
On Sat, Jan 18, 2020 at 03:27:12PM +0100, Michael Niedermayer wrote: > On Sat, Jan 18, 2020 at 06:38:25AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/libx264.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > > index ca8f6c0..4fef0be 100644 > > --- a/libavcodec/libx264.c > > +++ b/libavcodec/libx264.c > > @@ -471,7 +471,8 @@ static int X264_frame(AVCodecContext *ctx, AVPacket > > *pkt, const AVFrame *frame, > > pict_type = AV_PICTURE_TYPE_B; > > break; > > default: > > -pict_type = AV_PICTURE_TYPE_NONE; > > +av_log(ctx, AV_LOG_ERROR, "Unknown picture type encountered.\n"); > > +return AVERROR_EXTERNAL; > > } > > This builds now but it does not work > > ./ffmpeg -i mm-short.mpg -t 1 test.mp4 > > [libx264 @ 0x2d2c1c0] Unknown picture type encountered. > Video encoding failed Sorry, please ignore the patch, libx264 can return 0. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ > 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, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/libx264: return error if unknown picture type encountered
On Fri, Jan 17, 2020 at 10:09:47PM +0100, Michael Niedermayer wrote: > On Fri, Jan 17, 2020 at 12:48:48PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/libx264.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > > index ca8f6c0..4fef0be 100644 > > --- a/libavcodec/libx264.c > > +++ b/libavcodec/libx264.c > > @@ -471,7 +471,8 @@ static int X264_frame(AVCodecContext *ctx, AVPacket > > *pkt, const AVFrame *frame, > > pict_type = AV_PICTURE_TYPE_B; > > break; > > default: > > -pict_type = AV_PICTURE_TYPE_NONE; > > +av_log(avctx, AV_LOG_ERROR, "Unknown picture type encountered.\n"); > > +return AVERROR_EXTERNAL; > > } > > its ctx not avctx, this wont build yes, it's my fault, I realized that my test branch did not compile the libx264 library. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > You can kill me, but you cannot change the truth. > ___ > 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, Limin Wang ___ 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 v8 3/4] avfilter/vf_showinfo: display H.26[45] user data unregistered sei message
On Thu, Jan 09, 2020 at 10:37:44AM +0100, Moritz Barsnick wrote:
> On Wed, Jan 08, 2020 at 23:46:02 +0800, lance.lmw...@gmail.com wrote:
> > +/* Only print the user data details if it's string */
> > +if (string_is_print(user_data)) {
> > +av_log(ctx, AV_LOG_INFO, "User Data=");
> > +av_log(ctx, AV_LOG_INFO, "%s", user_data);
> > +}
>
> Is this missing a final linebreak? Just wondering, I didn't test.
good catch, if you're checking the code, you'll notice the line break is
placed after the case condition.
>
> Moritz
> ___
> 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,
Limin Wang
___
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] Add vps/sps/pps id offset to hevc_metadata bsf
EVC_NAL_CRA_NUT:
> +case HEVC_NAL_RADL_N:
> +case HEVC_NAL_RADL_R:
> +case HEVC_NAL_RASL_N:
> +case HEVC_NAL_RASL_R:
> +err = h265_metadata_update_slice_header(bsf,
> au->units[i].content);
> +if (err < 0)
> +goto fail;
> +break;
> }
> }
>
> @@ -455,15 +512,42 @@ static int h265_metadata_init(AVBSFContext *bsf)
> h265_metadata_guess_level(bsf, au);
>
> for (i = 0; i < au->nb_units; i++) {
> -if (au->units[i].type == HEVC_NAL_VPS) {
> +switch (au->units[i].type) {
> +case HEVC_NAL_VPS:
> err = h265_metadata_update_vps(bsf, au->units[i].content);
> if (err < 0)
> goto fail;
> -}
> -if (au->units[i].type == HEVC_NAL_SPS) {
> +break;
> +case HEVC_NAL_SPS:
> err = h265_metadata_update_sps(bsf, au->units[i].content);
> if (err < 0)
> goto fail;
> +break;
> +case HEVC_NAL_PPS:
> +err = h265_metadata_update_pps(bsf, au->units[i].content);
> +if (err < 0)
> +goto fail;
> +break;
> +case HEVC_NAL_TRAIL_N:
> +case HEVC_NAL_TRAIL_R:
> +case HEVC_NAL_TSA_N:
> +case HEVC_NAL_TSA_R:
> +case HEVC_NAL_STSA_N:
> +case HEVC_NAL_STSA_R:
> +case HEVC_NAL_BLA_W_LP:
> +case HEVC_NAL_BLA_W_RADL:
> +case HEVC_NAL_BLA_N_LP:
> +case HEVC_NAL_IDR_W_RADL:
> +case HEVC_NAL_IDR_N_LP:
> +case HEVC_NAL_CRA_NUT:
> +case HEVC_NAL_RADL_N:
> +case HEVC_NAL_RADL_R:
> +case HEVC_NAL_RASL_N:
> +case HEVC_NAL_RASL_R:
> +err = h265_metadata_update_slice_header(bsf,
> au->units[i].content);
> +if (err < 0)
> +goto fail;
> +break;
> }
> }
>
> @@ -547,6 +631,16 @@ static const AVOption h265_metadata_options[] = {
> OFFSET(crop_bottom), AV_OPT_TYPE_INT,
> { .i64 = -1 }, -1, HEVC_MAX_HEIGHT, FLAGS },
>
> +{ "vps_id_offset", "Increase the vps id by this offset",
> +OFFSET(vps_id_offset), AV_OPT_TYPE_INT,
> +{ .i64 = 0 }, 0, HEVC_MAX_VPS_COUNT, FLAGS },
> +{ "sps_id_offset", "Increase the sps id by this offset",
> +OFFSET(sps_id_offset), AV_OPT_TYPE_INT,
> +{ .i64 = 0 }, 0, HEVC_MAX_SPS_COUNT, FLAGS },
> +{ "pps_id_offset", "Increase the pps id by this offset",
> +OFFSET(pps_id_offset), AV_OPT_TYPE_INT,
> +{ .i64 = 0 }, 0, HEVC_MAX_PPS_COUNT, FLAGS },
> +
> { "level", "Set level (tables A.6 and A.7)",
> OFFSET(level), AV_OPT_TYPE_INT,
> { .i64 = LEVEL_UNSET }, LEVEL_UNSET, 0xff, FLAGS, "level" },
> --
> 2.24.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".
--
Thanks,
Limin Wang
___
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 v7 1/8] avutil: add AV_FRAME_DATA_USER_DATA_UNREGISTERED side data type
On Wed, Jan 08, 2020 at 06:07:29AM +0100, Anton Khirnov wrote:
> Quoting lance.lmw...@gmail.com (2020-01-07 06:03:48)
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/APIchanges | 3 +++
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 8
> > libavutil/version.h | 2 +-
> > 4 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 3c24dc6fbc..6e1673e25e 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> > API changes, most recent first:
> >
> > +2020-01-xx - xx - lavu 56.39.100 - frame.h
> > + Add AV_FRAME_DATA_USER_DATA_UNREGISTERED.
> > +
> > 2019-12-27 - xx - lavu 56.38.100 - eval.h
> >Add av_expr_count_func().
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index e4038096c2..1d0faec687 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > #endif
> > case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> > SMPTE2094-40 (HDR10+)";
> > case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED: return "User Data
> > Unregistered";
> > }
> > return NULL;
> > }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index b5afb58634..54863c86ce 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -179,6 +179,14 @@ enum AVFrameSideDataType {
> > * array element is implied by AVFrameSideData.size /
> > AVRegionOfInterest.self_size.
> > */
> > AV_FRAME_DATA_REGIONS_OF_INTEREST,
> > +
> > +/**
> > + * User data unregistered metadata associated with a video frame.
> > + * This is the H.26[45] UDU SEI message, and shouldn't be used for any
> > other purpose
> > + * The data is stored as uint8_t in AVFrameSideData.data which is 16
> > bytes of
> > + * uuid_iso_iec_11578 followed by AVFrameSideData.size-16 bytes of
> > user_data_payload_byte.
> > + */
> > +AV_FRAME_DATA_USER_DATA_UNREGISTERED,
>
> This naming is too generic IMO. Something like
> AV_FRAME_DATA_SEI_UNREGISTERED would make it clearer that it refers to
> the H.26x concept rather than any other kind of "registration" or "user
> data".
Sure, I'll change to AV_FRAME_DATA_SEI_UNREGISTERED.
>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avutil: add AV_FRAME_DATA_USER_DATA_UNREGISTERED side data type
On Mon, Jan 06, 2020 at 10:03:42PM +, Mark Thompson wrote:
> On 06/01/2020 14:54, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > Fix for the v5 commit message change when copy(add avutil:)
> >
> > doc/APIchanges | 3 +++
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 8
> > libavutil/version.h | 2 +-
> > 4 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 3c24dc6..6e1673e 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> > API changes, most recent first:
> >
> > +2020-01-xx - xx - lavu 56.39.100 - frame.h
> > + Add AV_FRAME_DATA_USER_DATA_UNREGISTERED.
> > +
> > 2019-12-27 - xx - lavu 56.38.100 - eval.h
> >Add av_expr_count_func().
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index e403809..1d0faec6 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > #endif
> > case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> > SMPTE2094-40 (HDR10+)";
> > case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED: return "User Data
> > Unregistered";
> > }
> > return NULL;
> > }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index b5afb58..9e8c3a9 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -179,6 +179,14 @@ enum AVFrameSideDataType {
> > * array element is implied by AVFrameSideData.size /
> > AVRegionOfInterest.self_size.
> > */
> > AV_FRAME_DATA_REGIONS_OF_INTEREST,
> > +
> > +/**
> > + * User data unregistered metadata associated with a video frame.
>
> IMO it should be stated directly that this is the H.26[45] UDU SEI message,
> and shouldn't be used for any other purpose. Mention it here and reference
> the relevant sections of the standards.
>
> > + * This data payload is stored as uint8_t in AVFrameSideData.data.
> > + * The number of bytes of data payload is AVFrameSideData.size.
> > + * The data payload consists of 16 bytes UUID and real user data.
>
> The ambiguity around the word payload is kindof confusing here. I think
> either avoid using the word payload at all, or name the syntax elements
> explicitly (16 bytes of uuid_iso_iec_11578 followed by size-16 bytes of
> user_data_payload_byte).
Mark, I have updated the patch set by your comments, please help to review to
sure I have catch your points. If have any missing, please comments further.
In addition, I put other related patch into this thread for better review.
>
> > + */
> > +AV_FRAME_DATA_USER_DATA_UNREGISTERED,
> > };
> >
> > enum AVActiveFormatDescription {
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index af8f614..2bc1b98 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -79,7 +79,7 @@
> > */
> >
> > #define LIBAVUTIL_VERSION_MAJOR 56
> > -#define LIBAVUTIL_VERSION_MINOR 38
> > +#define LIBAVUTIL_VERSION_MINOR 39
> > #define LIBAVUTIL_VERSION_MICRO 100
> >
> > #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> >
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avutil: add AV_FRAME_DATA_USER_DATA_UNREGISTERED side data type
On Mon, Jan 06, 2020 at 10:03:42PM +, Mark Thompson wrote:
> On 06/01/2020 14:54, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > Fix for the v5 commit message change when copy(add avutil:)
> >
> > doc/APIchanges | 3 +++
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 8
> > libavutil/version.h | 2 +-
> > 4 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 3c24dc6..6e1673e 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> > API changes, most recent first:
> >
> > +2020-01-xx - xx - lavu 56.39.100 - frame.h
> > + Add AV_FRAME_DATA_USER_DATA_UNREGISTERED.
> > +
> > 2019-12-27 - xx - lavu 56.38.100 - eval.h
> >Add av_expr_count_func().
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index e403809..1d0faec6 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > #endif
> > case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> > SMPTE2094-40 (HDR10+)";
> > case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED: return "User Data
> > Unregistered";
> > }
> > return NULL;
> > }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index b5afb58..9e8c3a9 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -179,6 +179,14 @@ enum AVFrameSideDataType {
> > * array element is implied by AVFrameSideData.size /
> > AVRegionOfInterest.self_size.
> > */
> > AV_FRAME_DATA_REGIONS_OF_INTEREST,
> > +
> > +/**
> > + * User data unregistered metadata associated with a video frame.
>
> IMO it should be stated directly that this is the H.26[45] UDU SEI message,
> and shouldn't be used for any other purpose. Mention it here and reference
> the relevant sections of the standards.
OK
>
> > + * This data payload is stored as uint8_t in AVFrameSideData.data.
> > + * The number of bytes of data payload is AVFrameSideData.size.
> > + * The data payload consists of 16 bytes UUID and real user data.
>
> The ambiguity around the word payload is kindof confusing here. I think
> either avoid using the word payload at all, or name the syntax elements
> explicitly (16 bytes of uuid_iso_iec_11578 followed by size-16 bytes of
> user_data_payload_byte).
OK, will update by your suggestion.
>
> > + */
> > +AV_FRAME_DATA_USER_DATA_UNREGISTERED,
> > };
> >
> > enum AVActiveFormatDescription {
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index af8f614..2bc1b98 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -79,7 +79,7 @@
> > */
> >
> > #define LIBAVUTIL_VERSION_MAJOR 56
> > -#define LIBAVUTIL_VERSION_MINOR 38
> > +#define LIBAVUTIL_VERSION_MINOR 39
> > #define LIBAVUTIL_VERSION_MICRO 100
> >
> > #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> >
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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 v5 4/4] avcodec/h264: create user data unregistered side data H.264
On Mon, Jan 06, 2020 at 10:18:13PM +, Mark Thompson wrote:
> On 02/01/2020 01:28, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/h264_sei.c | 20 +++--
> > libavcodec/h264_sei.h | 2 +
> > libavcodec/h264_slice.c | 14
> > tests/ref/fate/mov-zombie | 195
> > ++
> > 4 files changed, 161 insertions(+), 70 deletions(-)
> >
> > diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
> > index a565fea..43e2814 100644
> > --- a/libavcodec/h264_sei.c
> > +++ b/libavcodec/h264_sei.c
> > @@ -52,6 +52,10 @@ void ff_h264_sei_uninit(H264SEIContext *h)
> > h->afd.present = 0;
> >
> > av_buffer_unref(>a53_caption.buf_ref);
> > +for (int i = 0; i < h->unregistered.nb_buf_ref; i++)
> > +av_buffer_unref(>unregistered.buf_ref[i]);
> > +h->unregistered.nb_buf_ref = 0;
> > +av_freep(>unregistered.buf_ref);
> > }
> >
> > static int decode_picture_timing(H264SEIPictureTiming *h, GetBitContext
> > *gb,
> > @@ -246,25 +250,31 @@ static int
> > decode_unregistered_user_data(H264SEIUnregistered *h, GetBitContext *
> > {
> > uint8_t *user_data;
> > int e, build, i;
> > +AVBufferRef *buf_ref, **tmp;
> >
> > -if (size < 16 || size >= INT_MAX - 1)
> > +if (size < 16)
> > return AVERROR_INVALIDDATA;
> >
> > -user_data = av_malloc(size + 1);
> > -if (!user_data)
> > +tmp = av_realloc_array(h->buf_ref, h->nb_buf_ref + 1,
> > sizeof(*h->buf_ref));
> > +if (!tmp)
> > return AVERROR(ENOMEM);
> > +h->buf_ref = tmp;
> > +
> > +buf_ref = av_buffer_alloc(size);
> > +if (!buf_ref)
> > +return AVERROR(ENOMEM);> +user_data = buf_ref->data;
> >
> > for (i = 0; i < size; i++)
> > user_data[i] = get_bits(gb, 8);
> > +h->buf_ref[h->nb_buf_ref++] = buf_ref;
> >
> > -user_data[i] = 0;
>
> You've lost this terminator, which allows
I need keep the user data same with original data so remove the extra terminator
data, I prefer to add a isprint() checking before x264 string processing.
>
> > e = sscanf(user_data + 16, "x264 - core %d", );
>
> to read over the end of the allocated buffer.
>
> > if (e == 1 && build > 0)
> > h->x264_build = build;
> > if (e == 1 && build == 1 && !strncmp(user_data+16, "x264 - core ",
> > 16))
> > h->x264_build = 67;
> >
> > -av_free(user_data);
> > return 0;
> > }
> >
> > diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
> > index a75c3aa..aa4595f 100644
> > --- a/libavcodec/h264_sei.h
> > +++ b/libavcodec/h264_sei.h
> > @@ -121,6 +121,8 @@ typedef struct H264SEIA53Caption {
> >
> > typedef struct H264SEIUnregistered {
> > int x264_build;
> > +AVBufferRef **buf_ref;
> > +int nb_buf_ref;
> > } H264SEIUnregistered;
> >
> > typedef struct H264SEIRecoveryPoint {
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index e24d41c..ea967c8 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -1285,6 +1285,20 @@ static int h264_export_frame_props(H264Context *h)
> > h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > }
> >
> > +for (int i = 0; i < h->sei.unregistered.nb_buf_ref; i++) {
> > +H264SEIUnregistered *unreg = >sei.unregistered;
> > +
> > +if (unreg->buf_ref[i]) {
> > +AVFrameSideData *sd = av_frame_new_side_data_from_buf(cur->f,
> > +AV_FRAME_DATA_USER_DATA_UNREGISTERED,
> > +unreg->buf_ref[i]);
> > +if (!sd)
> > +av_buffer_unref(>buf_ref[i]);
> > +unreg->buf_ref[i] = NULL;
> > +}
> > +}
> > +h->sei.unregistered.nb_buf_ref = 0;
> > +
> > if (h->sei.picture_timing.timecode_cnt > 0) {
> > uint32_t tc = 0;
> > uint32_t *tc_sd;
>
> Everything else looks good to me.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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 v5 3/4] avfilter/vf_showinfo: display user data unregistered message
On Mon, Jan 06, 2020 at 10:38:22PM +, Mark Thompson wrote:
> On 02/01/2020 01:28, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_showinfo.c | 33 +
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index 31f6b32..bb3b37e 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -169,6 +169,36 @@ static void
> > dump_content_light_metadata(AVFilterContext *ctx, AVFrameSideData *s
> > metadata->MaxCLL, metadata->MaxFALL);
> > }
> >
> > +static int string_is_ascii(const uint8_t *str)
> > +{
> > +while (*str && *str < 128) str++;
> > +return !*str;
>
> Perhaps isprint() would be better? You don't really want to allow any
> control characters like newline either.
Sure, it's OK to use isprint, I'll update to use it.
>
> > +}
> > +
> > +static void dump_user_data_unregistered_metadata(AVFilterContext *ctx,
> > AVFrameSideData *sd)
> > +{
> > +const int uuid_size = 16;
> > +uint8_t *user_data = sd->data;
> > +
> > +if (sd->size < uuid_size) {
> > +av_log(ctx, AV_LOG_ERROR, "invalid data(%d < UUID(%d-bytes))",
> > sd->size, uuid_size);
> > +return;
> > +}
> > +
> > +av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
> > +av_log(ctx, AV_LOG_INFO, "UUID=");
> > +for (int i = 0; i < uuid_size; i++)
> > +av_log(ctx, AV_LOG_INFO, "%x", user_data[i]);
>
> "%02x"
OK
> Putting the hyphens in the standard places would make this more readable, too.
I'll try to add the hyphens in the standard places.
>
> > +av_log(ctx, AV_LOG_INFO, "\n");
> > +
> > +user_data += uuid_size;
> > +/* Only print the user data details if it's string */
> > +if (string_is_ascii(user_data)) {
> > +av_log(ctx, AV_LOG_INFO, "User Data=");
> > +av_log(ctx, AV_LOG_INFO, "%s", user_data);
> > +}
> > +}
> > +
> > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > {
> > const char *color_range_str =
> > av_color_range_name(frame->color_range);
> > @@ -319,6 +349,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *frame)
> > av_log(ctx, AV_LOG_INFO, "GOP timecode - %s", tcbuf);
> > break;
> > }
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED:
> > +dump_user_data_unregistered_metadata(ctx, sd);
> > +break;
> > default:
> > av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > bytes)",
> > sd->type, sd->size);
> >
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/h265_metadata_bsf: add option to insert a string as SEI unregistered user data
On Mon, Jan 06, 2020 at 09:51:34PM +, Mark Thompson wrote: > On 28/12/2019 01:38, Limin Wang wrote: > > On Fri, Dec 27, 2019 at 11:32:40PM +, Mark Thompson wrote: > >> On 26/12/2019 01:01, lance.lmw...@gmail.com wrote: > >>> From: Limin Wang > >>> > >>> Signed-off-by: Limin Wang > >>> --- > >>> update to add keyframe NAL checking as H.264 patch for global header > >> > >> This case is much easier in H.265, though - the extradata can include SEI > >> which applies globally, so just put it there rather than splicing it into > >> the stream. > > > > Mark, are you say put the user data into the extradata? For my case, the > > string > > in the user data will be updated for every key frame runtime. > > Yes - if you put it in the extradata then it isn't necessary to update any > frames in the stream at all. That ends up being far simpler for > global-header streams (MP4 / MKV), and in flat streams (Annex B, TS) the > extradata will be spliced in at every seek point by the writer. Sorry, my description isn't clear before, for my case, The user data may have time related string, so it'll updated for every insertion. Also, it'll be used for real time streaming, RTMP protocol etc. You had to use API to get the function, FFmpeg cli can't test it. > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ 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 v1] avfilter/af_amix: change the max range of the number of inputs
On Mon, Jan 06, 2020 at 02:27:36PM +0100, Paul B Mahol wrote:
> On 1/6/20, Limin Wang wrote:
> > On Mon, Jan 06, 2020 at 01:28:45PM +0100, Paul B Mahol wrote:
> >> Limit is not real, its too big.
> >
> > So what's reasonable value to use?
> > I notice video mix choose INT_MAX, so I use the same.
>
> INT16_MAX seems high enough.
Sure, I'll update to use INT16_MAX.
>
> >
> > [lmwang@vpn ffmpeg]$ grep nb_inputs libavfilter/vf_mix.c |grep INT_MAX
> > { "inputs", "set number of inputs", OFFSET(nb_inputs), AV_OPT_TYPE_INT,
> > {.i64=2}, 2, INT_MAX, .flags = FLAGS },
> >
> >>
> >> On 1/6/20, lance.lmw...@gmail.com wrote:
> >> > From: Limin Wang
> >> >
> >> > Signed-off-by: Limin Wang
> >> > ---
> >> > libavfilter/af_amix.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
> >> > index 89a1b0568f..1e1753b078 100644
> >> > --- a/libavfilter/af_amix.c
> >> > +++ b/libavfilter/af_amix.c
> >> > @@ -182,7 +182,7 @@ typedef struct MixContext {
> >> > #define F AV_OPT_FLAG_FILTERING_PARAM
> >> > static const AVOption amix_options[] = {
> >> > { "inputs", "Number of inputs.",
> >> > -OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 1024,
> >> > A|F
> >> > },
> >> > +OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1,
> >> > INT_MAX,
> >> > A|F },
> >> > { "duration", "How to determine the end-of-stream.",
> >> > OFFSET(duration_mode), AV_OPT_TYPE_INT, { .i64 =
> >> > DURATION_LONGEST }, 0, 2, A|F, "duration" },
> >> > { "longest", "Duration of longest input.", 0,
> >> > AV_OPT_TYPE_CONST,
> >> > { .i64 = DURATION_LONGEST }, 0, 0, A|F, "duration" },
> >> > --
> >> > 2.21.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".
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".
--
Thanks,
Limin Wang
___
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 v1] avfilter/af_amix: change the max range of the number of inputs
On Mon, Jan 06, 2020 at 01:28:45PM +0100, Paul B Mahol wrote:
> Limit is not real, its too big.
So what's reasonable value to use?
I notice video mix choose INT_MAX, so I use the same.
[lmwang@vpn ffmpeg]$ grep nb_inputs libavfilter/vf_mix.c |grep INT_MAX
{ "inputs", "set number of inputs", OFFSET(nb_inputs), AV_OPT_TYPE_INT,
{.i64=2}, 2, INT_MAX, .flags = FLAGS },
>
> On 1/6/20, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/af_amix.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
> > index 89a1b0568f..1e1753b078 100644
> > --- a/libavfilter/af_amix.c
> > +++ b/libavfilter/af_amix.c
> > @@ -182,7 +182,7 @@ typedef struct MixContext {
> > #define F AV_OPT_FLAG_FILTERING_PARAM
> > static const AVOption amix_options[] = {
> > { "inputs", "Number of inputs.",
> > -OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 1024, A|F
> > },
> > +OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, INT_MAX,
> > A|F },
> > { "duration", "How to determine the end-of-stream.",
> > OFFSET(duration_mode), AV_OPT_TYPE_INT, { .i64 =
> > DURATION_LONGEST }, 0, 2, A|F, "duration" },
> > { "longest", "Duration of longest input.", 0, AV_OPT_TYPE_CONST,
> > { .i64 = DURATION_LONGEST }, 0, 0, A|F, "duration" },
> > --
> > 2.21.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".
--
Thanks,
Limin Wang
___
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 v3] avfilter/vf_showinfo: Fix erroneous results for mean and stdev with pixel bits >8
ping, please review it. I'll add packed format support after that.
On Fri, Nov 29, 2019 at 07:28:23PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Have tested with be and le pixel format on be and le system for >8bit.
> System:
> lmwang@ubuntu:~/ffmpeg.git.mips$ grep HAVE_BIGENDIAN config.h
> #define HAVE_BIGENDIAN 1
> ffmpeg.git git:(showinfo) ✗ grep HAVE_BIGENDIAN config.h
> #define HAVE_BIGENDIAN 0
>
> Test result:
> 1, yuv420p
> ./ffmpeg -f lavfi -i
> color=black:duration=1:r=1:size=1280x720,format=yuv420p,showinfo
> Master:
> mean:[16 128 128] stdev:[0.0 0.0 0.0]
> After applied the patch:
> mean:[16 128 128] stdev:[0.0 0.0 0.0]
>
> 2, yuv420p10le
> ./ffmpeg -f lavfi -i
> color=black:duration=1:r=1:size=1280x720,format=yuv420p10le,showinfo
> Master:
> mean:[32 1 1] stdev:[32.0 1.0 1.0]
> After applied the patch:
> mean:[64 512 512] stdev:[0.0 0.0 0.0]
>
> 3, yuv420p10be
> ./ffmpeg -f lavfi -i
> color=black:duration=1:r=1:size=1280x720,format=yuv420p10be,showinfo
> Master:
> mean:[32 1 1] stdev:[32.0 1.0 1.0]
> After applied the patch:
> mean:[64 512 512] stdev:[0.0 0.0 0.0]
>
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 34 +++---
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 31f6b32aa4..5856722122 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -24,6 +24,7 @@
>
> #include
>
> +#include "libavutil/bswap.h"
> #include "libavutil/adler32.h"
> #include "libavutil/display.h"
> #include "libavutil/imgutils.h"
> @@ -202,7 +203,7 @@ static void dump_color_property(AVFilterContext *ctx,
> AVFrame *frame)
> av_log(ctx, AV_LOG_INFO, "\n");
> }
>
> -static void update_sample_stats(const uint8_t *src, int len, int64_t *sum,
> int64_t *sum2)
> +static void update_sample_stats_8(const uint8_t *src, int len, int64_t *sum,
> int64_t *sum2)
> {
> int i;
>
> @@ -212,6 +213,30 @@ static void update_sample_stats(const uint8_t *src, int
> len, int64_t *sum, int64
> }
> }
>
> +static void update_sample_stats_16(int be, const uint8_t *src, int len,
> int64_t *sum, int64_t *sum2)
> +{
> +const uint16_t *src1 = (const uint16_t *)src;
> +int i;
> +
> +for (i = 0; i < len / 2; i++) {
> +if ((HAVE_BIGENDIAN && !be) || (!HAVE_BIGENDIAN && be)) {
> +*sum += av_bswap16(src1[i]);
> +*sum2 += av_bswap16(src1[i]) * av_bswap16(src1[i]);
> +} else {
> +*sum += src1[i];
> +*sum2 += src1[i] * src1[i];
> +}
> +}
> +}
> +
> +static void update_sample_stats(int depth, int be, const uint8_t *src, int
> len, int64_t *sum, int64_t *sum2)
> +{
> +if (depth <= 8)
> +update_sample_stats_8(src, len, sum, sum2);
> +else
> +update_sample_stats_16(be, src, len, sum, sum2);
> +}
> +
> static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> {
> AVFilterContext *ctx = inlink->dst;
> @@ -220,12 +245,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> uint32_t plane_checksum[4] = {0}, checksum = 0;
> int64_t sum[4] = {0}, sum2[4] = {0};
> int32_t pixelcount[4] = {0};
> +int bitdepth = desc->comp[0].depth;
> +int be = desc->flags & AV_PIX_FMT_FLAG_BE;
> int i, plane, vsub = desc->log2_chroma_h;
>
> for (plane = 0; plane < 4 && s->calculate_checksums &&
> frame->data[plane] && frame->linesize[plane]; plane++) {
> uint8_t *data = frame->data[plane];
> int h = plane == 1 || plane == 2 ? AV_CEIL_RSHIFT(inlink->h, vsub) :
> inlink->h;
> int linesize = av_image_get_linesize(frame->format, frame->width,
> plane);
> +int width = linesize >> (bitdepth > 8);
>
> if (linesize < 0)
> return linesize;
> @@ -234,8 +262,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> plane_checksum[plane] = av_adler32_update(plane_checksum[plane],
> data, linesize);
> checksum = av_adler32_update(checksum, data, linesize);
>
> -update_sample_stats(data, linesize, sum+plane, sum2+plane);
> -pixelcount[plane] += linesize;
> +update_sample_stats(bitdepth, be, data, linesize, sum+plane,
> sum2+plane);
> +pixelcount[plane] += width;
> data += frame->linesize[plane];
> }
> }
> --
> 2.21.0
>
--
Thanks,
Limin Wang
___
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 v1] avfilter: add colorstats, colorrgbstats, coloryuvstats video filter
On Mon, Dec 30, 2019 at 04:36:53PM -0500, Dave Rice wrote: > > > On Dec 27, 2019, at 10:49 AM, Paul B Mahol wrote: > > > > That is because signalstats is doing more stuff. > > signalstats includes options to disable some of the calculations, possibly > this could be extended to enable or disable the ones you want. It would be > interesting to merge these ideas rather than have two filters with such a > substantial overlap. It's more difficult to change existing code, too long time for review and even no reviewer. Anyway, I plan to remove the 8bit and 16bit huge duplicate code first. > > > On 12/27/19, Limin Wang wrote: > >> On Fri, Dec 27, 2019 at 03:20:19PM +0100, Paul B Mahol wrote: > >>> On 12/27/19, Limin Wang wrote: > >>>> On Fri, Dec 27, 2019 at 12:35:25PM +0100, Paul B Mahol wrote: > >>>>> You are duplicating some functionality of signalstats filter. > >>>>> > >>>> Yes, I have other function need to use the mean and stdev which is > >>>> support in showinfo filter(only 8bit and don't support packed format, > >>>> no multi-thread), and signalstats don't support rgb format and don't > >>>> have stdev, also it have too many other function and difficult to change > >>>> it, so I think it's more simple to create a new filter to do it. > >>>> > >>> > >>> No, unacceptable. use signalstats filter. > >> > >> The performance is one major reason also, below is the profiling result for > >> performance: > >> > >> ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf > >> bench=start,signalstats,bench=stop -f null - > >> [bench @ 0x3fb9080] t:0.161589 avg:0.165756 max:0.169923 min:0.161589 > >> [bench @ 0x3fb9080] t:0.160334 avg:0.163948 max:0.169923 min:0.160334 > >> [bench @ 0x3fb9080] t:0.160345 avg:0.163047 max:0.169923 min:0.160334 > >> [bench @ 0x3fb9080] t:0.160924 avg:0.162623 max:0.169923 min:0.160334 > >> [bench @ 0x3fb9080] t:0.160318 avg:0.162238 max:0.169923 min:0.160318 > >> > >> ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf > >> bench=start,colorstats,bench=stop -f null - > >> [bench @ 0x26f6100] t:0.012596 avg:0.012612 max:0.012628 min:0.012596 > >> [bench @ 0x26f6100] t:0.012542 avg:0.012588 max:0.012628 min:0.012542 > >> [bench @ 0x26f6100] t:0.012529 avg:0.012573 max:0.012628 min:0.012529 > >> [bench @ 0x26f6100] t:0.012532 avg:0.012565 max:0.012628 min:0.012529 > >> [bench @ 0x26f6100] t:0.012527 avg:0.012559 max:0.012628 min:0.012527 > >> [bench @ 0x26f6100] t:0.012525 avg:0.012554 max:0.012628 min:0.012525 > >> [bench @ 0x26f6100] t:0.012522 avg:0.012550 max:0.012628 min:0.012522 > >> [bench @ 0x26f6100] t:0.012552 avg:0.012550 max:0.012628 min:0.012522 > >> > >> > >>> > >>>> > >>>>> On 12/27/19, lance.lmw...@gmail.com wrote: > >>>>>> From: Limin Wang > >>>>>> > >>>>>> Signed-off-by: Limin Wang > >>>>>> --- > >>>>>> doc/filters.texi| 74 ++ > >>>>>> libavfilter/Makefile| 1 + > >>>>>> libavfilter/allfilters.c| 3 + > >>>>>> libavfilter/vf_colorstats.c | 461 > >>>>>> > >>>>>> 4 files changed, 539 insertions(+) > >>>>>> create mode 100644 libavfilter/vf_colorstats.c > >>>>>> > >>>>>> diff --git a/doc/filters.texi b/doc/filters.texi > >>>>>> index 8c5d3a5760..81968b2c17 100644 > >>>>>> --- a/doc/filters.texi > >>>>>> +++ b/doc/filters.texi > >>>>>> @@ -7695,6 +7695,80 @@ For example to convert the input to > >>>>>> SMPTE-240M, > >>>>>> use > >>>>>> the command: > >>>>>> colorspace=smpte240m > >>>>>> @end example > >>>>>> > >>>>>> +@section colorstats, colorrgbstats, coloryuvstats > >>>>>> +The filter provides statistical video measurements such as mean, > >>>>>> minimum, > >>>>>> maximum and > >>>>>> +standard deviation for each frame. The user can check for > >>>>>> unexpected/accidental errors > >>>>>> +very quickly with them. > >>>>>> + > >>>>>> +@var
Re: [FFmpeg-devel] [PATCH v2 3/4] FATE: add a test for lut1d and lut3d
On Thu, Nov 14, 2019 at 10:55:30PM +0100, Michael Niedermayer wrote: > On Thu, Nov 14, 2019 at 09:46:22PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips > > tested on mingw32/64, qemu arm/mips ping, please help to push the patchset(except 4) if no other issues. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Freedom in capitalist society always remains about the same as it was in > ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin > ___ > 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, Limin Wang ___ 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 v1] avcodec/h264_metadata_bsf: Fix user data failed to insert in case no SPSs NAL for global headers
On Fri, Dec 27, 2019 at 11:30:34PM +, Mark Thompson wrote:
> On 26/12/2019 00:55, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > FLV, MP4... will enable global_header default and place SPSs headers in
> > extradata
> > instead of every keyframe. So it'll failed to insert user data unregisted
> > for no SPSs NAL after first AU without the patch.
> >
> > Please test it with below command:
> > ./ffmpeg -f lavfi -i testsrc -c:v libx264 -g 25 \
> > -bsf:v
> > h264_metadata=sei_user_data=086f3693-b7b3-4f2c-9653-21492feee5b8+hello \
> > -frames:v 150 test.mp4
> >
> > After applied the patch, you'll get the user data for every keyframe with
> > below command:
> > ./ffmpeg -i test.mp4 -vf showinfo -frames:v 150 -f null -
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/h264_metadata_bsf.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> > index 5de74be9d6..9690ca433b 100644
> > --- a/libavcodec/h264_metadata_bsf.c
> > +++ b/libavcodec/h264_metadata_bsf.c
> > @@ -279,7 +279,7 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> > AVPacket *pkt)
> > {
> > H264MetadataContext *ctx = bsf->priv_data;
> > CodedBitstreamFragment *au = >access_unit;
> > -int err, i, j, has_sps;
> > +int err, i, j, has_sps, is_keyframe = 0;
> > H264RawAUD aud;
> >
> > err = ff_bsf_get_packet_ref(bsf, pkt);
> > @@ -359,11 +359,13 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> > AVPacket *pkt)
> > goto fail;
> > has_sps = 1;
> > }
> > +if (au->units[i].type == H264_NAL_IDR_SLICE)
> > +is_keyframe = 1;
> > }
> >
> > // Only insert the SEI in access units containing SPSs, and also
> > // unconditionally in the first access unit we ever see.
> > -if (ctx->sei_user_data && (has_sps || !ctx->done_first_au)) {
> > +if (ctx->sei_user_data && (has_sps || !ctx->done_first_au ||
> > is_keyframe)) {
> > H264RawSEIPayload payload = {
> > .payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED,
> > };
> >
>
> This was avoided originally because identifying key frames (or really, seek
> points) in an H.264 stream is really hard. I don't particularly like the
> idea of having it work in some streams but not others, depending on exactly
> how the stream was encoded - hence the original decision to only include it
> in access units which were already distinguished as flat-file seek-points by
> having the parameter sets in them.
>
> I guess I'm not against this in itself, but please add more of a comment in
> the code explaining the rationale and noting the cases which are not
> included. (And if you can cover more cases, such as recovery points, then
> that would be even better.)
FFmpeg CLI can't support change the parameter on the fly, by my case, the user
data string will be updated periodically. For the stream, like rtmp, no SPSs
header in the stream, so the user data failed to insert anymore. For IDR_SLICE
is good to cover most condition, so I did not add recovery points as the user
data don't depend on it in fact. If you think it's needed, I'll add more
checking.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/h265_metadata_bsf: add option to insert a string as SEI unregistered user data
On Fri, Dec 27, 2019 at 11:32:40PM +, Mark Thompson wrote: > On 26/12/2019 01:01, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > update to add keyframe NAL checking as H.264 patch for global header > > This case is much easier in H.265, though - the extradata can include SEI > which applies globally, so just put it there rather than splicing it into the > stream. Mark, are you say put the user data into the extradata? For my case, the string in the user data will be updated for every key frame runtime. > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ 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 v1] avfilter: add colorstats, colorrgbstats, coloryuvstats video filter
On Fri, Dec 27, 2019 at 03:20:19PM +0100, Paul B Mahol wrote:
> On 12/27/19, Limin Wang wrote:
> > On Fri, Dec 27, 2019 at 12:35:25PM +0100, Paul B Mahol wrote:
> >> You are duplicating some functionality of signalstats filter.
> >>
> > Yes, I have other function need to use the mean and stdev which is
> > support in showinfo filter(only 8bit and don't support packed format,
> > no multi-thread), and signalstats don't support rgb format and don't
> > have stdev, also it have too many other function and difficult to change
> > it, so I think it's more simple to create a new filter to do it.
> >
>
> No, unacceptable. use signalstats filter.
The performance is one major reason also, below is the profiling result for
performance:
./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
bench=start,signalstats,bench=stop -f null -
[bench @ 0x3fb9080] t:0.161589 avg:0.165756 max:0.169923 min:0.161589
[bench @ 0x3fb9080] t:0.160334 avg:0.163948 max:0.169923 min:0.160334
[bench @ 0x3fb9080] t:0.160345 avg:0.163047 max:0.169923 min:0.160334
[bench @ 0x3fb9080] t:0.160924 avg:0.162623 max:0.169923 min:0.160334
[bench @ 0x3fb9080] t:0.160318 avg:0.162238 max:0.169923 min:0.160318
./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
bench=start,colorstats,bench=stop -f null -
[bench @ 0x26f6100] t:0.012596 avg:0.012612 max:0.012628 min:0.012596
[bench @ 0x26f6100] t:0.012542 avg:0.012588 max:0.012628 min:0.012542
[bench @ 0x26f6100] t:0.012529 avg:0.012573 max:0.012628 min:0.012529
[bench @ 0x26f6100] t:0.012532 avg:0.012565 max:0.012628 min:0.012529
[bench @ 0x26f6100] t:0.012527 avg:0.012559 max:0.012628 min:0.012527
[bench @ 0x26f6100] t:0.012525 avg:0.012554 max:0.012628 min:0.012525
[bench @ 0x26f6100] t:0.012522 avg:0.012550 max:0.012628 min:0.012522
[bench @ 0x26f6100] t:0.012552 avg:0.012550 max:0.012628 min:0.012522
>
> >
> >> On 12/27/19, lance.lmw...@gmail.com wrote:
> >> > From: Limin Wang
> >> >
> >> > Signed-off-by: Limin Wang
> >> > ---
> >> > doc/filters.texi| 74 ++
> >> > libavfilter/Makefile| 1 +
> >> > libavfilter/allfilters.c| 3 +
> >> > libavfilter/vf_colorstats.c | 461
> >> > 4 files changed, 539 insertions(+)
> >> > create mode 100644 libavfilter/vf_colorstats.c
> >> >
> >> > diff --git a/doc/filters.texi b/doc/filters.texi
> >> > index 8c5d3a5760..81968b2c17 100644
> >> > --- a/doc/filters.texi
> >> > +++ b/doc/filters.texi
> >> > @@ -7695,6 +7695,80 @@ For example to convert the input to SMPTE-240M,
> >> > use
> >> > the command:
> >> > colorspace=smpte240m
> >> > @end example
> >> >
> >> > +@section colorstats, colorrgbstats, coloryuvstats
> >> > +The filter provides statistical video measurements such as mean,
> >> > minimum,
> >> > maximum and
> >> > +standard deviation for each frame. The user can check for
> >> > unexpected/accidental errors
> >> > +very quickly with them.
> >> > +
> >> > +@var{colorrgbstats} report the color stats for RGB input video,
> >> > @var{coloryuvstats}
> >> > +to an YUV input video.
> >> > +
> >> > +These filters accept the following parameters:
> >> > +@table @option
> >> > +@item planes
> >> > +Set which planes to filter. Default is only the first plane.
> >> > +@end table
> >> > +
> >> > +By default the filter will report these metadata values if the planes
> >> > +are processed:
> >> > +
> >> > +@table @option
> >> > +@item min.y, min.u, min.v, min.r, min.g, min.b, min.a
> >> > +Display the minimal Y/U/V/R/G/B/A plane value contained within the
> >> > input
> >> > frame.
> >> > +Expressed in range of [0, 1< >> > +
> >> > +@item pmin.y, pmin.u, pmin.v, pmin.r, pmin.g, pmin.b, min.a
> >> > +Display the minimal Y/U/V/R/G/B/A plane percentage of maximum contained
> >> > within
> >> > +the input frame. Expressed in range of [0, 1]
> >> > +
> >> > +@item max.y, max.u, max.v, max.r, max.g, max.b, max.a
> >> > +Display the maximum Y/U/V/R/G/B/A plane value contained within the
> >> > input
> >> > frame.
> >> > +Expressed in range of [0, 1< >> > +
> >> > +@item pmax.y, pmax.u, pmax.v, pmax.r, pmax.g, pmax.b, pmax.a
> >> > +Display the maximum Y/U/V/R/G/B/A plane p
Re: [FFmpeg-devel] [PATCH v1] avfilter: add colorstats, colorrgbstats, coloryuvstats video filter
On Fri, Dec 27, 2019 at 12:35:25PM +0100, Paul B Mahol wrote:
> You are duplicating some functionality of signalstats filter.
>
Yes, I have other function need to use the mean and stdev which is
support in showinfo filter(only 8bit and don't support packed format,
no multi-thread), and signalstats don't support rgb format and don't
have stdev, also it have too many other function and difficult to change
it, so I think it's more simple to create a new filter to do it.
> On 12/27/19, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/filters.texi| 74 ++
> > libavfilter/Makefile| 1 +
> > libavfilter/allfilters.c| 3 +
> > libavfilter/vf_colorstats.c | 461
> > 4 files changed, 539 insertions(+)
> > create mode 100644 libavfilter/vf_colorstats.c
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 8c5d3a5760..81968b2c17 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -7695,6 +7695,80 @@ For example to convert the input to SMPTE-240M, use
> > the command:
> > colorspace=smpte240m
> > @end example
> >
> > +@section colorstats, colorrgbstats, coloryuvstats
> > +The filter provides statistical video measurements such as mean, minimum,
> > maximum and
> > +standard deviation for each frame. The user can check for
> > unexpected/accidental errors
> > +very quickly with them.
> > +
> > +@var{colorrgbstats} report the color stats for RGB input video,
> > @var{coloryuvstats}
> > +to an YUV input video.
> > +
> > +These filters accept the following parameters:
> > +@table @option
> > +@item planes
> > +Set which planes to filter. Default is only the first plane.
> > +@end table
> > +
> > +By default the filter will report these metadata values if the planes
> > +are processed:
> > +
> > +@table @option
> > +@item min.y, min.u, min.v, min.r, min.g, min.b, min.a
> > +Display the minimal Y/U/V/R/G/B/A plane value contained within the input
> > frame.
> > +Expressed in range of [0, 1< > +
> > +@item pmin.y, pmin.u, pmin.v, pmin.r, pmin.g, pmin.b, min.a
> > +Display the minimal Y/U/V/R/G/B/A plane percentage of maximum contained
> > within
> > +the input frame. Expressed in range of [0, 1]
> > +
> > +@item max.y, max.u, max.v, max.r, max.g, max.b, max.a
> > +Display the maximum Y/U/V/R/G/B/A plane value contained within the input
> > frame.
> > +Expressed in range of [0, 1< > +
> > +@item pmax.y, pmax.u, pmax.v, pmax.r, pmax.g, pmax.b, pmax.a
> > +Display the maximum Y/U/V/R/G/B/A plane percentage of maximum contained
> > within
> > +the input frame. Expressed in range of [0, 1]
> > +
> > +@item mean.y, mean.u, mean.v, mean.r, mean.g, mean.b, mean.a
> > +Display the Y/U/V/R/G/B/A plane mean value contained within the input
> > frame.
> > +Expressed in range of [0, 1< > +
> > +@item pmean.y, pmean.u, pmean.v, pmean.r, pmean.g, pmean.b, pmean.a
> > +Display the Y/U/V/R/G/B/A plane mean value percentage of maximum contained
> > within
> > +the input frame. Expressed in range of [0, 1]
> > +
> > +@item stdev.y, stdev.u, stdev.v, stdev.r, stdev.g, stdev.b, stdev.a
> > +Display the Y/U/V/R/G/B/A plane standard deviation value contained within
> > the
> > +input frame. Expressed in range of [0, 1< > +
> > +@item pstdev.y, pstdev.u, pstdev.v, pstdev.r, pstdev.g, pstdev.b, pstdev.a
> > +Display the Y/U/V/R/G/B/A plane standard deviation value percentage of
> > maximum contained
> > +within the input frame. Expressed in range of [0, 1]
> > +@end table
> > +
> > +@subsection Examples
> > +
> > +@itemize
> > +@item
> > +Show all YUV color stats for each frame:
> > +@example
> > +ffprobe -f lavfi movie=example.mov,coloryuvstats=planes=0xf -show_frames
> > +@end example
> > +
> > +@item
> > +Draw graph for the pmean and pstdev value of the Y plane per frame:
> > +@example
> > +ffplay -i example.mov -vf
> > coloryuvstats,drawgraph=m1=lavf.colorstats.pmean.y:m2=lavf.colorstats.pstdev.y:min=0:max=1
> > +@end example
> > +
> > +@item
> > +Print all RGB color stats for each frame:
> > +@example
> > +ffplay -i example.mov -vf colorrgbstats=planes=0xf,metadata=mode=print
> > +@end example
> > +
> > +@end itemize
> > +
> > @section convolution
> >
> > Apply convolution of 3x3, 5x5, 7x7 or horizontal/vertical up to
Re: [FFmpeg-devel] [PATCH v1 3/3] avfilter/vf_yadif: remove duplicate code with macro-based function
On Wed, Dec 25, 2019 at 05:57:58PM +0100, Michael Niedermayer wrote:
> On Tue, Dec 24, 2019 at 09:13:39AM +0800, Limin Wang wrote:
> > On Thu, Nov 28, 2019 at 09:34:18AM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavfilter/vf_yadif.c | 147 +++--
> > > 1 file changed, 54 insertions(+), 93 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
> > > index f53bb77008..15d8c47b0b 100644
> > > --- a/libavfilter/vf_yadif.c
> > > +++ b/libavfilter/vf_yadif.c
> > > @@ -91,101 +91,62 @@ typedef struct ThreadData {
> > > next2++; \
> > > }
> > >
> > > -static void filter_line_c(void *dst1,
> > > - void *prev1, void *cur1, void *next1,
> > > - int w, int prefs, int mrefs, int parity, int
> > > mode)
> > > -{
> > > -uint8_t *dst = dst1;
> > > -uint8_t *prev = prev1;
> > > -uint8_t *cur = cur1;
> > > -uint8_t *next = next1;
> > > -int x;
> > > -uint8_t *prev2 = parity ? prev : cur ;
> > > -uint8_t *next2 = parity ? cur : next;
> > > -
> > > -/* The function is called with the pointers already pointing to
> > > data[3] and
> > > - * with 6 subtracted from the width. This allows the FILTER macro
> > > to be
> > > - * called so that it processes all the pixels normally. A constant
> > > value of
> > > - * true for is_not_edge lets the compiler ignore the if statement. */
> > > -FILTER(0, w, 1)
> > > +#define FILTER_LINE_FUNC(type, depth, bps)
> > > \
> > > +static void filter_line_c_##depth##bit(void *dst1,
> > > \
> > > + void *prev1, void *cur1, void *next1,
> > > \
> > > + int w, int prefs, int mrefs, int parity, int
> > > mode) \
> > > +{
> > > \
> > > +type *dst = dst1;
> > > \
> > > +type *prev = prev1;
> > > \
> > > +type *cur = cur1;
> > > \
> > > +type *next = next1;
> > > \
> > > +int x;
> > > \
> > > +type *prev2 = parity ? prev : cur ;
> > > \
> > > +type *next2 = parity ? cur : next;
> > > \
> > > +mrefs /= bps;
> > > \
> > > +prefs /= bps;
> > > \
> > > +
> > > \
> > > +/* The function is called with the pointers already pointing to
> > > data[3] and */ \
> > > +/* with 6 subtracted from the width. This allows the FILTER macro
> > > to be */\
> > > +/* called so that it processes all the pixels normally. A constant
> > > value of */ \
> > > +/* true for is_not_edge lets the compiler ignore the if statement.
> > > */ \
> > > +FILTER(0, w, 1)
> > > \
> > > }
> > > +FILTER_LINE_FUNC(uint16_t, 16, 2);
> > > +FILTER_LINE_FUNC(uint8_t, 8, 1);
> > >
> > > #define MAX_ALIGN 8
> > > -static void filter_edges(void *dst1, void *prev1, void *cur1, void
> > > *next1,
> > > - int w, int prefs, int mrefs, int parity, int
> > > mode)
> > > -{
> > > -uint8_t *dst = dst1;
> > > -uint8_t *prev = prev1;
> > > -uint8_t *cur = cur1;
> > > -uint8_t *next = next1;
> > > -int x;
> > > -uint8_t *prev2 = parity ? prev : cur ;
> > > -uint8_t *next2 = parity ? cur : next;
> > > -
> >
Re: [FFmpeg-devel] [PATCH v1] avutil/frame: Use av_realloc_array()
On Tue, Dec 24, 2019 at 01:46:00AM +, Andreas Rheinhardt wrote: > Limin Wang: > > On Mon, Dec 23, 2019 at 10:20:37PM -0300, James Almer wrote: > >> On 12/23/2019 8:32 PM, Michael Niedermayer wrote: > >>> On Mon, Dec 23, 2019 at 10:48:13PM +0800, lance.lmw...@gmail.com wrote: > >>>> From: Limin Wang > >>>> > >>>> Signed-off-by: Limin Wang > >>>> --- > >>>> libavutil/frame.c | 7 ++- > >>>> 1 file changed, 2 insertions(+), 5 deletions(-) > >>>> > >>>> diff --git a/libavutil/frame.c b/libavutil/frame.c > >>>> index 1d0faec687..0a1ba877cc 100644 > >>>> --- a/libavutil/frame.c > >>>> +++ b/libavutil/frame.c > >>>> @@ -696,11 +696,8 @@ AVFrameSideData > >>>> *av_frame_new_side_data_from_buf(AVFrame *frame, > >>>> if (!buf) > >>>> return NULL; > >>>> > >>>> -if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1) > >>>> -return NULL; > >>>> - > >>>> -tmp = av_realloc(frame->side_data, > >>>> - (frame->nb_side_data + 1) * > >>>> sizeof(*frame->side_data)); > >>>> +tmp = av_realloc_array(frame->side_data, > >>>> + (frame->nb_side_data + 1), > >>>> sizeof(*frame->side_data)); > >>> > >>> does something prevent "frame->nb_side_data + 1" from overflowing ? > >> > >> av_realloc_array() is called with x + 1 as nmemb argument in several > >> places. It checks for "nmemb >= INT_MAX / size", so it will never > >> overflow with a buffer that increases by one element at a time (It would > >> if the check was > alone). > > > > I think about it, in case nb_side_data is INT_MAX, then frame->nb_side_data > > + 1 will overflow already > > before enter av_realloc_array, so I add check for this overflow only. > > > When frame->nb_side_data is INT_MAX - 1, you request to realloc the > array to INT_MAX members. And because of the check James mentioned > this allocation will already fail, hence frame->nb_side_data can never > become INT_MAX (unless it is also set somewhere else in the code). So > no overflow check is necessary in the caller as long as the size of > the array is only increased in steps of 1. Yes, please ignore my second patch. > > But this relies on undocumented behaviour of av_realloc_array. Maybe > it should be documented? > > - Andreas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avutil/frame: Use av_realloc_array()
On Mon, Dec 23, 2019 at 10:20:37PM -0300, James Almer wrote: > On 12/23/2019 8:32 PM, Michael Niedermayer wrote: > > On Mon, Dec 23, 2019 at 10:48:13PM +0800, lance.lmw...@gmail.com wrote: > >> From: Limin Wang > >> > >> Signed-off-by: Limin Wang > >> --- > >> libavutil/frame.c | 7 ++- > >> 1 file changed, 2 insertions(+), 5 deletions(-) > >> > >> diff --git a/libavutil/frame.c b/libavutil/frame.c > >> index 1d0faec687..0a1ba877cc 100644 > >> --- a/libavutil/frame.c > >> +++ b/libavutil/frame.c > >> @@ -696,11 +696,8 @@ AVFrameSideData > >> *av_frame_new_side_data_from_buf(AVFrame *frame, > >> if (!buf) > >> return NULL; > >> > >> -if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1) > >> -return NULL; > >> - > >> -tmp = av_realloc(frame->side_data, > >> - (frame->nb_side_data + 1) * > >> sizeof(*frame->side_data)); > >> +tmp = av_realloc_array(frame->side_data, > >> + (frame->nb_side_data + 1), > >> sizeof(*frame->side_data)); > > > > does something prevent "frame->nb_side_data + 1" from overflowing ? > > av_realloc_array() is called with x + 1 as nmemb argument in several > places. It checks for "nmemb >= INT_MAX / size", so it will never > overflow with a buffer that increases by one element at a time (It would > if the check was > alone). I think about it, in case nb_side_data is INT_MAX, then frame->nb_side_data + 1 will overflow already before enter av_realloc_array, so I add check for this overflow only. > > The version 2 of this patch is pointless since it adds an extra check to > the process, so if this one isn't applied then IMO none should. > > > > > thx > > > > [...] > > > > > > ___ > > 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 v1 1/2] avfilter/vf_colormatrix: av_frame_free() in case of error
On Wed, Nov 27, 2019 at 06:46:50PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavfilter/vf_colormatrix.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c > index 3a02e2b86e..3a0c3f01da 100644 > --- a/libavfilter/vf_colormatrix.c > +++ b/libavfilter/vf_colormatrix.c > @@ -448,6 +448,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in) > case AVCOL_SPC_BT2020_CL : source = COLOR_MODE_BT2020; break; > default : > av_log(ctx, AV_LOG_ERROR, "Input frame does not specify a > supported colorspace, and none has been specified as source either\n"); > +av_frame_free(); > av_frame_free(); > return AVERROR(EINVAL); ping > } > -- > 2.21.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 v1 3/3] avfilter/vf_yadif: remove duplicate code with macro-based function
On Thu, Nov 28, 2019 at 09:34:18AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_yadif.c | 147 +++--
> 1 file changed, 54 insertions(+), 93 deletions(-)
>
> diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
> index f53bb77008..15d8c47b0b 100644
> --- a/libavfilter/vf_yadif.c
> +++ b/libavfilter/vf_yadif.c
> @@ -91,101 +91,62 @@ typedef struct ThreadData {
> next2++; \
> }
>
> -static void filter_line_c(void *dst1,
> - void *prev1, void *cur1, void *next1,
> - int w, int prefs, int mrefs, int parity, int mode)
> -{
> -uint8_t *dst = dst1;
> -uint8_t *prev = prev1;
> -uint8_t *cur = cur1;
> -uint8_t *next = next1;
> -int x;
> -uint8_t *prev2 = parity ? prev : cur ;
> -uint8_t *next2 = parity ? cur : next;
> -
> -/* The function is called with the pointers already pointing to data[3]
> and
> - * with 6 subtracted from the width. This allows the FILTER macro to be
> - * called so that it processes all the pixels normally. A constant
> value of
> - * true for is_not_edge lets the compiler ignore the if statement. */
> -FILTER(0, w, 1)
> +#define FILTER_LINE_FUNC(type, depth, bps)
> \
> +static void filter_line_c_##depth##bit(void *dst1,
> \
> + void *prev1, void *cur1, void *next1,
> \
> + int w, int prefs, int mrefs, int parity, int mode)
> \
> +{
> \
> +type *dst = dst1;
> \
> +type *prev = prev1;
> \
> +type *cur = cur1;
> \
> +type *next = next1;
> \
> +int x;
> \
> +type *prev2 = parity ? prev : cur ;
> \
> +type *next2 = parity ? cur : next;
> \
> +mrefs /= bps;
> \
> +prefs /= bps;
> \
> +
> \
> +/* The function is called with the pointers already pointing to data[3]
> and */ \
> +/* with 6 subtracted from the width. This allows the FILTER macro to be
> */\
> +/* called so that it processes all the pixels normally. A constant value
> of */ \
> +/* true for is_not_edge lets the compiler ignore the if statement. */
> \
> +FILTER(0, w, 1)
> \
> }
> +FILTER_LINE_FUNC(uint16_t, 16, 2);
> +FILTER_LINE_FUNC(uint8_t, 8, 1);
>
> #define MAX_ALIGN 8
> -static void filter_edges(void *dst1, void *prev1, void *cur1, void *next1,
> - int w, int prefs, int mrefs, int parity, int mode)
> -{
> -uint8_t *dst = dst1;
> -uint8_t *prev = prev1;
> -uint8_t *cur = cur1;
> -uint8_t *next = next1;
> -int x;
> -uint8_t *prev2 = parity ? prev : cur ;
> -uint8_t *next2 = parity ? cur : next;
> -
> -const int edge = MAX_ALIGN - 1;
> -
> -/* Only edge pixels need to be processed here. A constant value of false
> - * for is_not_edge should let the compiler ignore the whole branch. */
> -FILTER(0, 3, 0)
> -
> -dst = (uint8_t*)dst1 + w - edge;
> -prev = (uint8_t*)prev1 + w - edge;
> -cur = (uint8_t*)cur1 + w - edge;
> -next = (uint8_t*)next1 + w - edge;
> -prev2 = (uint8_t*)(parity ? prev : cur);
> -next2 = (uint8_t*)(parity ? cur : next);
> -
> -FILTER(w - edge, w - 3, 1)
> -FILTER(w - 3, w, 0)
> -}
> -
> -
> -static void filter_line_c_16bit(void *dst1,
> -void *prev1, void *cur1, void *next1,
> -int w, int prefs, int mrefs, int parity,
> -int mode)
> -{
> -uint16_t *dst = dst1;
> -uint16_t *prev = prev1;
> -uint16_t *cur = cur1;
> -uint16_t *next = next1;
> -int x;
> -uint16_t *prev2 = parity ? prev : cur ;
> -uint16_t *next2 = parit
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_h264: add support for the Content light level information SEI message
On Thu, Nov 28, 2019 at 11:06:52PM -0300, James Almer wrote:
> Defined in ITU-T H.264 (06/2019)
LGTM
>
> Signed-off-by: James Almer
> ---
> This is basically a copy paste of the H.265 implementation, both here and in
> the spec.
>
> libavcodec/cbs_h264.h | 6 ++
> libavcodec/cbs_h2645.c| 1 +
> libavcodec/cbs_h264_syntax_template.c | 17 +
> libavcodec/h264_sei.h | 1 +
> 4 files changed, 25 insertions(+)
>
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index 9f7c2a0d30..f8e5b743be 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -314,6 +314,11 @@ typedef struct H264RawSEIMasteringDisplayColourVolume {
> uint32_t min_display_mastering_luminance;
> } H264RawSEIMasteringDisplayColourVolume;
>
> +typedef struct H264RawSEIContentLightLevelInfo {
> +uint16_t max_content_light_level;
> +uint16_t max_pic_average_light_level;
> +} H264RawSEIContentLightLevelInfo;
> +
> typedef struct H264RawSEIAlternativeTransferCharacteristics {
> uint8_t preferred_transfer_characteristics;
> } H264RawSEIAlternativeTransferCharacteristics;
> @@ -331,6 +336,7 @@ typedef struct H264RawSEIPayload {
> H264RawSEIRecoveryPoint recovery_point;
> H264RawSEIDisplayOrientation display_orientation;
> H264RawSEIMasteringDisplayColourVolume
> mastering_display_colour_volume;
> +H264RawSEIContentLightLevelInfo content_light_level;
> H264RawSEIAlternativeTransferCharacteristics
> alternative_transfer_characteristics;
> struct {
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 88fa0029cd..0944585fa8 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -458,6 +458,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload
> *payload)
> case H264_SEI_TYPE_PAN_SCAN_RECT:
> case H264_SEI_TYPE_RECOVERY_POINT:
> case H264_SEI_TYPE_DISPLAY_ORIENTATION:
> +case H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
> case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
> case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
> break;
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index 1671a15d33..62b40dfb42 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -819,6 +819,19 @@ static int
> FUNC(sei_mastering_display_colour_volume)(CodedBitstreamContext *ctx,
> return 0;
> }
>
> +static int FUNC(sei_content_light_level)(CodedBitstreamContext *ctx,
> RWContext *rw,
> + H264RawSEIContentLightLevelInfo
> *current)
> +{
> +int err;
> +
> +HEADER("Content Light Level");
> +
> +ub(16, max_content_light_level);
> +ub(16, max_pic_average_light_level);
> +
> +return 0;
> +}
> +
> static int
> FUNC(sei_alternative_transfer_characteristics)(CodedBitstreamContext *ctx,
>RWContext *rw,
>
> H264RawSEIAlternativeTransferCharacteristics *current)
> @@ -883,6 +896,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx,
> RWContext *rw,
> CHECK(FUNC(sei_mastering_display_colour_volume)
>(ctx, rw, >payload.mastering_display_colour_volume));
> break;
> +case H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
> +CHECK(FUNC(sei_content_light_level)
> + (ctx, rw, >payload.content_light_level));
> +break;
> case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
> CHECK(FUNC(sei_alternative_transfer_characteristics)
>(ctx, rw,
> >payload.alternative_transfer_characteristics));
> diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
> index a75c3aa175..ffd3948c5b 100644
> --- a/libavcodec/h264_sei.h
> +++ b/libavcodec/h264_sei.h
> @@ -36,6 +36,7 @@ typedef enum {
> H264_SEI_TYPE_DISPLAY_ORIENTATION= 47, ///< display orientation
> H264_SEI_TYPE_GREEN_METADATA = 56, ///< GreenMPEG information
> H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME = 137, ///< mastering
> display properties
> +H264_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144, ///< content light level
> information
> H264_SEI_TYPE_ALTERNATIVE_TRANSFER = 147, ///< alternative transfer
> } H264_SEI_Type;
>
> --
> 2.24.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 v1] avutil/frame: Use av_realloc_array()
On Tue, Dec 24, 2019 at 12:32:07AM +0100, Michael Niedermayer wrote: > On Mon, Dec 23, 2019 at 10:48:13PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavutil/frame.c | 7 ++- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/libavutil/frame.c b/libavutil/frame.c > > index 1d0faec687..0a1ba877cc 100644 > > --- a/libavutil/frame.c > > +++ b/libavutil/frame.c > > @@ -696,11 +696,8 @@ AVFrameSideData > > *av_frame_new_side_data_from_buf(AVFrame *frame, > > if (!buf) > > return NULL; > > > > -if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1) > > -return NULL; > > - > > -tmp = av_realloc(frame->side_data, > > - (frame->nb_side_data + 1) * > > sizeof(*frame->side_data)); > > +tmp = av_realloc_array(frame->side_data, > > + (frame->nb_side_data + 1), sizeof(*frame->side_data)); > > does something prevent "frame->nb_side_data + 1" from overflowing ? no, I have add the check for the overflow and update the patch. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > ___ > 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/mpegtsenc: warn users if codec isn't supported
On Fri, Dec 20, 2019 at 04:55:12PM +0530, Gyan wrote: > > Regards, > Gyan > From fbbd221b089f3b272cfd712c3d4824dd86b4eac0 Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Fri, 20 Dec 2019 16:39:32 +0530 > Subject: [PATCH] avformat/mpegtsenc: warn users if codec isn't supported > > The MPEG-TS muxer will mux streams with unsupported codec id > as a private data stream; this usually makes the stream > not recognizable by ffmpeg and likely other tools. > --- > libavformat/mpegtsenc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c > index 5b4694bfd1..f24112465a 100644 > --- a/libavformat/mpegtsenc.c > +++ b/libavformat/mpegtsenc.c > @@ -382,6 +382,7 @@ static int mpegts_write_pmt(AVFormatContext *s, > MpegTSService *service) > stream_type = STREAM_TYPE_METADATA; > break; > default: > +av_log(s, AV_LOG_WARNING, "Stream %d, codec %s, is muxed as a > private data stream and may not be recognized upon reading.\n", i, > avcodec_get_name(st->codecpar->codec_id)); I suggest that you can split long code into two lines. > stream_type = STREAM_TYPE_PRIVATE_DATA; > break; > } > -- > 2.24.1 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavc/midivid: FIX CID 1456088
On Mon, Dec 23, 2019 at 02:00:10AM +0100, Andreas Rheinhardt wrote:
> On Mon, Dec 23, 2019 at 1:53 AM Limin Wang wrote:
>
> > On Sun, Dec 22, 2019 at 03:26:58PM +, Zhong Li wrote:
> > > Signed-off-by: Zhong Li
> > > ---
> > > libavcodec/midivid.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavcodec/midivid.c b/libavcodec/midivid.c
> > > index 38465c5..3dac3f1 100644
> > > --- a/libavcodec/midivid.c
> > > +++ b/libavcodec/midivid.c
> > > @@ -63,17 +63,20 @@ static int decode_mvdv(MidiVidContext *s,
> > AVCodecContext *avctx, AVFrame *frame)
> > > if (intra_flag) {
> > > nb_blocks = (avctx->width / 2) * (avctx->height / 2);
> > > } else {
> > > -int skip_linesize;
> > > +int ret, skip_linesize;
> > >
> > > nb_blocks = bytestream2_get_le32(gb);
> > > skip_linesize = avctx->width >> 1;
> > > mask_start = gb->buffer_start + bytestream2_tell(gb);
> > > mask_size = (avctx->width >> 5) * (avctx->height >> 2);
> > >
> > > -if (bytestream2_get_bytes_left(gb) < mask_size)
> > > +ret = bytestream2_get_bytes_left(gb);
> > > +if (ret < mask_size)
> > > return AVERROR_INVALIDDATA;
> >
> > don't need change it I think.
> >
> > >
> > > -init_get_bits8(, mask_start, mask_size);
> > > +ret = init_get_bits8(, mask_start, mask_size);
> > > +if (ret < 0)
> > > +return AVERROR_INVALIDDATA;
> >
> > return ret. That's why use ret.
> >
> >
> But you are not returning ret.
But It's not my code, I'm a code reviewer.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavc/midivid: FIX CID 1456088
On Sun, Dec 22, 2019 at 03:26:58PM +, Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavcodec/midivid.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/midivid.c b/libavcodec/midivid.c
> index 38465c5..3dac3f1 100644
> --- a/libavcodec/midivid.c
> +++ b/libavcodec/midivid.c
> @@ -63,17 +63,20 @@ static int decode_mvdv(MidiVidContext *s, AVCodecContext
> *avctx, AVFrame *frame)
> if (intra_flag) {
> nb_blocks = (avctx->width / 2) * (avctx->height / 2);
> } else {
> -int skip_linesize;
> +int ret, skip_linesize;
>
> nb_blocks = bytestream2_get_le32(gb);
> skip_linesize = avctx->width >> 1;
> mask_start = gb->buffer_start + bytestream2_tell(gb);
> mask_size = (avctx->width >> 5) * (avctx->height >> 2);
>
> -if (bytestream2_get_bytes_left(gb) < mask_size)
> +ret = bytestream2_get_bytes_left(gb);
> +if (ret < mask_size)
> return AVERROR_INVALIDDATA;
don't need change it I think.
>
> -init_get_bits8(, mask_start, mask_size);
> +ret = init_get_bits8(, mask_start, mask_size);
> +if (ret < 0)
> +return AVERROR_INVALIDDATA;
return ret. That's why use ret.
> bytestream2_skip(gb, mask_size);
> skip = s->skip;
>
> --
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 v1] avcodec/mpeg12dec: switch to AVBufferRef buffer for a53 caption
On Sun, Dec 22, 2019 at 05:37:21PM +, Kieran Kunhya wrote: > On Sun, 22 Dec 2019 at 13:27, wrote: > > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/mpeg12dec.c | 73 > > +++--- > > 1 file changed, 40 insertions(+), 33 deletions(-) > > > > Does this fix a particular issue? > My patch to H.264 fixed a particular case of field mode captions but this > doesn't look like it fixes it? No, it's just switch to the new reference buffer as H.264 and HEVC as it has more benefit to export the data, I try my best to keep the function same. One difference is keep the old_size and realloc process from H.264, I can't sure whether it'll happed as I don't own such sample. Now I have tested with one mpeg2 with normal CC by showinfo only. If you have old sample broken, please let me know. > > Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: keep closed captions in sync between multiple thread contexts
On Fri, Dec 20, 2019 at 02:05:42PM -0300, James Almer wrote:
> Based on h264 code.
>
> Signed-off-by: James Almer
> ---
> libavcodec/hevcdec.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index f8270b87c3..19b0cd815d 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -3463,6 +3463,13 @@ static int hevc_update_thread_context(AVCodecContext
> *dst,
> s->max_ra = INT_MAX;
> }
>
> +av_buffer_unref(>sei.a53_caption.buf_ref);
> +if (s0->sei.a53_caption.buf_ref) {
> +s->sei.a53_caption.buf_ref =
> av_buffer_ref(s0->sei.a53_caption.buf_ref);
> +if (!s->sei.a53_caption.buf_ref)
> +return AVERROR(ENOMEM);
> +}
> +
LGTM
> s->sei.frame_packing= s0->sei.frame_packing;
> s->sei.display_orientation = s0->sei.display_orientation;
> s->sei.mastering_display= s0->sei.mastering_display;
> --
> 2.24.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 3/5] avfilter/vf_showinfo: display user data unregistered message
On Fri, Dec 20, 2019 at 02:30:23PM -0300, James Almer wrote:
> On 12/19/2019 2:09 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_showinfo.c | 33 +
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index 31f6b32aa4..bb3b37e0c5 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -169,6 +169,36 @@ static void
> > dump_content_light_metadata(AVFilterContext *ctx, AVFrameSideData *s
> > metadata->MaxCLL, metadata->MaxFALL);
> > }
> >
> > +static int string_is_ascii(const uint8_t *str)
> > +{
> > +while (*str && *str < 128) str++;
>
> I don't think the buffer is guaranteed to end with \0. You have
> sd->size, so you should probably use that, while also ensuring it ends
> with a \0 so the av_log below using %s works as intended.
If the str has any '\0', it'll end immediately, even < sd->size still, for the
print %s will work like that. In case it's end without '\0', we don't
consider it's string, so it'll not print out like binary code.
Below is the example:
'hello\0'will print hello
'hello\0tty' will print hello
'hello' don't print
>
> Also < 128 includes DEL. And you're not checking for >= 32.
I consider LF(\r), CR(\n) should be expected ascii, for example the
string may be json format, so I change to include all valid ascii
including the control character(0-31 and 121).
For example
'hello\ncc'will print hello
cc
>
> > +return !*str;
> > +}
> > +
> > +static void dump_user_data_unregistered_metadata(AVFilterContext *ctx,
> > AVFrameSideData *sd)
> > +{
> > +const int uuid_size = 16;
> > +uint8_t *user_data = sd->data;
> > +
> > +if (sd->size < uuid_size) {
> > +av_log(ctx, AV_LOG_ERROR, "invalid data(%d < UUID(%d-bytes))",
> > sd->size, uuid_size);
> > +return;
> > +}
> > +
> > +av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
> > +av_log(ctx, AV_LOG_INFO, "UUID=");
> > +for (int i = 0; i < uuid_size; i++)
> > +av_log(ctx, AV_LOG_INFO, "%x", user_data[i]);
> > +av_log(ctx, AV_LOG_INFO, "\n");
> > +
> > +user_data += uuid_size;
> > +/* Only print the user data details if it's string */
> > +if (string_is_ascii(user_data)) {
> > +av_log(ctx, AV_LOG_INFO, "User Data=");
> > +av_log(ctx, AV_LOG_INFO, "%s", user_data);
> > +}
> > +}
> > +
> > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > {
> > const char *color_range_str =
> > av_color_range_name(frame->color_range);
> > @@ -319,6 +349,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *frame)
> > av_log(ctx, AV_LOG_INFO, "GOP timecode - %s", tcbuf);
> > break;
> > }
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED:
> > +dump_user_data_unregistered_metadata(ctx, sd);
> > +break;
> > default:
> > av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > bytes)",
> > sd->type, sd->size);
> >
>
> ___
> 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 v3 2/5] avcodec/hevc_sei: add support for user data unregistered SEI message
On Fri, Dec 20, 2019 at 02:23:40PM -0300, James Almer wrote:
> On 12/19/2019 2:09 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/hevc_sei.c | 34 +
> > libavcodec/hevc_sei.h | 6 +
> > libavcodec/hevcdec.c| 18 +++
> > tests/ref/fate/hevc-monochrome-crop | 3 +++
> > 4 files changed, 61 insertions(+)
> >
> > diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> > index c59bd4321e..7f738a049c 100644
> > --- a/libavcodec/hevc_sei.c
> > +++ b/libavcodec/hevc_sei.c
> > @@ -206,6 +206,33 @@ static int
> > decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
> > return 0;
> > }
> >
> > +static int decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s,
> > GetBitContext *gb,
> > + int size)
> > +{
> > +AVBufferRef *buf_ref, **tmp;
> > +
> > +if (size < 16)
> > + return AVERROR(EINVAL);
> > +
> > +if (s->nb_buf_ref > INT_MAX / sizeof(*s->buf_ref) - 1)
> > + return AVERROR(EINVAL);
> > +
> > +tmp = av_realloc(s->buf_ref, (s->nb_buf_ref + 1) *
> > sizeof(*s->buf_ref));
>
> Use av_realloc_array() instead and you can remove the above check.
will update to use it
>
> > +if (!tmp)
> > +return AVERROR(ENOMEM);
> > +s->buf_ref = tmp;
> > +
> > +buf_ref = av_buffer_alloc(size);
> > +if (!buf_ref)
> > +return AVERROR(ENOMEM);
> > +
> > +for (int i = 0; i < size; i++)
> > +buf_ref->data[i] = get_bits(gb, 8);
> > +s->buf_ref[s->nb_buf_ref++] = buf_ref;
> > +
> > +return 0;
> > +}
> > +
> > static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> > GetBitContext *gb,
> > int size)
> > {
> > @@ -293,6 +320,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb,
> > void *logctx, HEVCSEI *s,
> > return decode_nal_sei_active_parameter_sets(s, gb, logctx);
> > case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
> > return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
> > +case HEVC_SEI_TYPE_USER_DATA_UNREGISTERED:
> > +return decode_nal_sei_user_data_unregistered(>unregistered, gb,
> > size);
> > case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
> > return
> > decode_nal_sei_alternative_transfer(>alternative_transfer, gb);
> > default:
> > @@ -365,4 +394,9 @@ void ff_hevc_reset_sei(HEVCSEI *s)
> > {
> > s->a53_caption.a53_caption_size = 0;
> > av_freep(>a53_caption.a53_caption);
> > +
> > +for (int i = 0; i < s->unregistered.nb_buf_ref; i++)
> > +av_buffer_unref(>unregistered.buf_ref[i]);
> > +s->unregistered.nb_buf_ref = 0;
> > +av_freep(>unregistered.buf_ref);
> > }
> > diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
> > index f6516ae982..2464117d47 100644
> > --- a/libavcodec/hevc_sei.h
> > +++ b/libavcodec/hevc_sei.h
> > @@ -87,6 +87,11 @@ typedef struct HEVCSEIA53Caption {
> > uint8_t *a53_caption;
> > } HEVCSEIA53Caption;
> >
> > +typedef struct HEVCSEIUnregistered {
> > +AVBufferRef **buf_ref;
> > +int nb_buf_ref;
> > +} HEVCSEIUnregistered;
> > +
> > typedef struct HEVCSEIMasteringDisplay {
> > int present;
> > uint16_t display_primaries[3][2];
> > @@ -112,6 +117,7 @@ typedef struct HEVCSEI {
> > HEVCSEIDisplayOrientation display_orientation;
> > HEVCSEIPictureTiming picture_timing;
> > HEVCSEIA53Caption a53_caption;
> > +HEVCSEIUnregistered unregistered;
> > HEVCSEIMasteringDisplay mastering_display;
> > HEVCSEIContentLight content_light;
> > int active_seq_parameter_set_id;
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 8f1c162ace..a4981e983c 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -2789,6 +2789,24 @@ static int set_side_data(HEVCContext *s)
> > s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > }
> >
> > +for (int i = 0; i < s->sei.unregistered.nb_buf_ref; i++) {
> > +HEVCSEIUnregistered *unreg = >sei.unregist
Re: [FFmpeg-devel] [PATCH v2 3/5] avfilter/vf_showinfo: display user data unregistered message
On Wed, Dec 18, 2019 at 12:47:49PM -0300, James Almer wrote:
> On 12/18/2019 8:06 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_showinfo.c | 40 +++
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index 31f6b32aa4..77ee7f312c 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -169,6 +169,43 @@ static void
> > dump_content_light_metadata(AVFilterContext *ctx, AVFrameSideData *s
> > metadata->MaxCLL, metadata->MaxFALL);
> > }
> >
> > +static int is_ascii(uint8_t ch)
> > +{
> > +if (ch >= 32 && ch <= 127)
>
> Should be < 127, i think.
>
yes, 127 is DEL control character
> > +return 1;
> > +else
> > +return 0;
> > +}
> > +
> > +static void dump_user_data_unregistered_metadata(AVFilterContext *ctx,
> > AVFrameSideData *sd)
> > +{
> > +const int uuid_size = 16;
> > +uint8_t *user_data = sd->data;
> > +
> > +if (sd->size < uuid_size) {
> > +av_log(ctx, AV_LOG_ERROR, "invalid data(%d < UUID(%d-bytes))",
> > sd->size, uuid_size);
> > +return;
> > +}
> > +
> > +av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
> > +av_log(ctx, AV_LOG_INFO, "UUID=");
> > +for (int i = 0; i < uuid_size; i++)
> > +av_log(ctx, AV_LOG_INFO, "%x", user_data[i]);
> > +av_log(ctx, AV_LOG_INFO, "\n");
> > +av_log(ctx, AV_LOG_INFO, "User Data=");
> > +for (int i = uuid_size; i < sd->size; i++) {
> > +/* printable ascii */
> > +if (is_ascii(*(user_data + i))) {
>
> user_data[i]
yes, it's more simple
> > +av_log(ctx, AV_LOG_INFO, "%c", *(user_data + i));
>
> Ditto.
>
> > +} else {
> > +/* don't print the last byte `\0` character for ascii */
> > +if ((i == sd->size - 1) && *(user_data + i) == 0)
>
> Ditto.
>
> > +continue;
> > +av_log(ctx, AV_LOG_INFO, "%x", *(user_data + i));
>
> Ditto.
>
> Also, maybe print 0x%02x instead.
sure.
>
> > +}
> > +}
>
> What if it's binary data where a few of the bytes are in the printable
> range? It might be worth checking if the entire buffer is printable and
> then choosing between using %s or %x for the whole thing.
I prefer to print the data, for most of user data is string, so it'll
helpful for user to dump the info. I'll add a function a check the entire buffer
first like below function:
static int string_is_ascii(const uint8_t *str)
{
while (*str && *str < 128) str++;
return !*str;
}
>
> Or maybe just not print anything at all. We're not doing it for closed
> captions frame side data after all.
>
> > +}
> > +
> > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > {
> > const char *color_range_str =
> > av_color_range_name(frame->color_range);
> > @@ -319,6 +356,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *frame)
> > av_log(ctx, AV_LOG_INFO, "GOP timecode - %s", tcbuf);
> > break;
> > }
> > +case AV_FRAME_DATA_USER_DATA_UNREGISTERED:
> > +dump_user_data_unregistered_metadata(ctx, sd);
> > +break;
> > default:
> > av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > bytes)",
> > sd->type, sd->size);
> >
>
> ___
> 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".
