[FFmpeg-devel] [PATCH 1/2] compat/cuda/ptx2c: remove shell loop
This improves build times dramatically --- compat/cuda/ptx2c.sh | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh index 0750e7a3b7..435a9b4b6c 100755 --- a/compat/cuda/ptx2c.sh +++ b/compat/cuda/ptx2c.sh @@ -27,10 +27,8 @@ IN="$2" NAME="$(basename "$IN" | sed 's/\..*//')" printf "const char %s_ptx[] = \\" "$NAME" > "$OUT" -while IFS= read -r LINE -do -printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e 's/["\\]/\\&/g')" >> "$OUT" -done < "$IN" -printf ";\n" >> "$OUT" +echo >> "$OUT" +sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e 's/$/\\n"/' < "$IN" >> "$OUT" +echo ";" >> "$OUT" exit 0 -- 2.26.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".
[FFmpeg-devel] [PATCH 2/2] compat/cuda/ptx2c: fix BSD sed compatibility
This fixes cross-compiling from macOS to other platforms --- compat/cuda/ptx2c.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh index 435a9b4b6c..c41875a2d4 100755 --- a/compat/cuda/ptx2c.sh +++ b/compat/cuda/ptx2c.sh @@ -28,7 +28,7 @@ NAME="$(basename "$IN" | sed 's/\..*//')" printf "const char %s_ptx[] = \\" "$NAME" > "$OUT" echo >> "$OUT" -sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e 's/$/\\n"/' < "$IN" >> "$OUT" +sed -e $'s/\r//g' -e 's/["\\]/\\&/g' -e $'s/^[[:space:]]*/\t"/' -e 's/$/\\n"/' < "$IN" >> "$OUT" echo ";" >> "$OUT" exit 0 -- 2.26.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".
Re: [FFmpeg-devel] [PATCH] lavc/decode: do not use a context variable for function-local data
Quoting James Almer (2020-05-22 19:32:07)
> On 5/22/2020 1:56 PM, Anton Khirnov wrote:
> > ---
> > libavcodec/decode.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index f3327d74af..dbecdf3f46 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -586,6 +586,7 @@ static int decode_receive_frame_internal(AVCodecContext
> > *avctx, AVFrame *frame)
> > int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const
> > AVPacket *avpkt)
> > {
> > AVCodecInternal *avci = avctx->internal;
> > +AVPacket buffer_pkt = { NULL };
> > int ret;
> >
> > if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec))
> > @@ -597,16 +598,15 @@ int attribute_align_arg
> > avcodec_send_packet(AVCodecContext *avctx, const AVPacke
> > if (avpkt && !avpkt->size && avpkt->data)
> > return AVERROR(EINVAL);
> >
> > -av_packet_unref(avci->buffer_pkt);
> > if (avpkt && (avpkt->data || avpkt->side_data_elems)) {
> > -ret = av_packet_ref(avci->buffer_pkt, avpkt);
> > +ret = av_packet_ref(&buffer_pkt, avpkt);
> > if (ret < 0)
> > return ret;
> > }
> >
> > -ret = av_bsf_send_packet(avci->bsf, avci->buffer_pkt);
> > +ret = av_bsf_send_packet(avci->bsf, &buffer_pkt);
> > if (ret < 0) {
> > -av_packet_unref(avci->buffer_pkt);
> > +av_packet_unref(&buffer_pkt);
> > return ret;
> > }
>
> What's the gain here? You're not removing the context variable since
> it's used in the encode framework as well, and you're introducing a
> stack AVPacket (that, while harmless, is not even properly initialized).
The gain is clarity/readability. A context variable suggests it is used
to some longer-term state. This change makes it clear that the packets
is only used within this function. Even the name is rather confusing,
since the packet does not get buffered there.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/decode: do not use a context variable for function-local data
On Fri, May 22, 2020 at 04:51:05PM -0300, James Almer wrote:
> On 5/22/2020 4:22 PM, Michael Niedermayer wrote:
> > On Fri, May 22, 2020 at 02:32:07PM -0300, James Almer wrote:
> >> On 5/22/2020 1:56 PM, Anton Khirnov wrote:
> >>> ---
> >>> libavcodec/decode.c | 8
> >>> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >>> index f3327d74af..dbecdf3f46 100644
> >>> --- a/libavcodec/decode.c
> >>> +++ b/libavcodec/decode.c
> >>> @@ -586,6 +586,7 @@ static int
> >>> decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
> >>> int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const
> >>> AVPacket *avpkt)
> >>> {
> >>> AVCodecInternal *avci = avctx->internal;
> >>> +AVPacket buffer_pkt = { NULL };
> >>> int ret;
> >>>
> >>> if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec))
> >>> @@ -597,16 +598,15 @@ int attribute_align_arg
> >>> avcodec_send_packet(AVCodecContext *avctx, const AVPacke
> >>> if (avpkt && !avpkt->size && avpkt->data)
> >>> return AVERROR(EINVAL);
> >>>
> >>> -av_packet_unref(avci->buffer_pkt);
> >>> if (avpkt && (avpkt->data || avpkt->side_data_elems)) {
> >>> -ret = av_packet_ref(avci->buffer_pkt, avpkt);
> >>> +ret = av_packet_ref(&buffer_pkt, avpkt);
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>>
> >>> -ret = av_bsf_send_packet(avci->bsf, avci->buffer_pkt);
> >>> +ret = av_bsf_send_packet(avci->bsf, &buffer_pkt);
> >>> if (ret < 0) {
> >>> -av_packet_unref(avci->buffer_pkt);
> >>> +av_packet_unref(&buffer_pkt);
> >>> return ret;
> >>> }
> >>
> >> What's the gain here? You're not removing the context variable since
> >> it's used in the encode framework as well, and you're introducing a
> >
> >> stack AVPacket (that, while harmless, is not even properly initialized).
> >
> > It would be nice if we could avoid all such code, so that we can extend
> > AVPacket like other structs without Major bumping
>
> Yes, some relatively recent commits went in the direction of removing as
> much AVPacket on stack/heap usage as possible precisely to remove
> sizeof(AVPacket) from the ABI, but at least within lavc it's not a problem.
sizeof() may be ok in libavcodec (though still IMHO not great style)
the other issue is NULL initialization. We may want to add new fields
which need to be initialized to a non 0 default. timestamps and AV_NOPTS_VALUE
come to mind as examples of such fields
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/libopusenc: Don't free user-provided AVPacket
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libopusenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 7c025a66d7..13017ac323 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -503,7 +503,6 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket
*avpkt,
// Check if subtraction resulted in an overflow
if ((discard_padding < opus->opts.packet_size) != (avpkt->duration > 0)) {
av_packet_unref(avpkt);
-av_free(avpkt);
return AVERROR(EINVAL);
}
if (discard_padding > 0) {
@@ -512,7 +511,6 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket
*avpkt,
10);
if(!side_data) {
av_packet_unref(avpkt);
-av_free(avpkt);
return AVERROR(ENOMEM);
}
AV_WL32(side_data + 4, discard_padding);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] libavcodec/libvpxenc: Don't free user-provided AVPacket
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libvpxenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 60a858853d..05bcc303d1 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1148,7 +1148,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
cx_frame->sz_alpha + 8);
if(!side_data) {
av_packet_unref(pkt);
-av_free(pkt);
return AVERROR(ENOMEM);
}
AV_WB64(side_data, 1);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] libavcodec/libmp3lame: Don't free user-provided AVPacket
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libmp3lame.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index ecdd2e334c..2beb28e569 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -279,7 +279,6 @@ static int mp3lame_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
if ((discard_padding < avctx->frame_size) != (avpkt->duration > 0)) {
av_log(avctx, AV_LOG_ERROR, "discard padding overflow\n");
av_packet_unref(avpkt);
-av_free(avpkt);
return AVERROR(EINVAL);
}
if ((!s->delay_sent && avctx->initial_padding > 0) || discard_padding
> 0) {
@@ -288,7 +287,6 @@ static int mp3lame_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
10);
if(!side_data) {
av_packet_unref(avpkt);
-av_free(avpkt);
return AVERROR(ENOMEM);
}
if (!s->delay_sent) {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] compat/cuda/ptx2c: remove shell loop
Am Sa., 23. Mai 2020 um 06:01 Uhr schrieb rcombs : > > This improves build times dramatically > --- > compat/cuda/ptx2c.sh | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh > index 0750e7a3b7..435a9b4b6c 100755 > --- a/compat/cuda/ptx2c.sh > +++ b/compat/cuda/ptx2c.sh > @@ -27,10 +27,8 @@ IN="$2" > NAME="$(basename "$IN" | sed 's/\..*//')" > > printf "const char %s_ptx[] = \\" "$NAME" > "$OUT" > -while IFS= read -r LINE > -do > -printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e > 's/["\\]/\\&/g')" >> "$OUT" > -done < "$IN" > -printf ";\n" >> "$OUT" > +echo >> "$OUT" > +sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e 's/$/\\n"/' > < "$IN" >> "$OUT" Is there a reason why you did not merge the two patches? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@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] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser
On Sat, May 23, 2020 at 1:08 AM Michael Niedermayer wrote: > > On Thu, May 21, 2020 at 09:42:18PM +0200, Carl Eugen Hoyos wrote: > > Am Mi., 20. Mai 2020 um 22:21 Uhr schrieb Michael Niedermayer > > : > > > > > > On Wed, May 20, 2020 at 08:48:41PM +0530, Gautam Ramakrishnan wrote: > > > > On Tue, Apr 21, 2020 at 3:41 AM Michael Niedermayer > > > > wrote: > > > > > > > > > > On Mon, Apr 20, 2020 at 04:13:44PM +0530, Gautam Ramakrishnan wrote: > > > > > > On Mon, Apr 20, 2020 at 3:38 PM Michael Niedermayer > > > > > > wrote: > > > > > > > > > > > > > > On Mon, Apr 20, 2020 at 01:36:47AM +0530, gautamr...@gmail.com > > > > > > > wrote: > > > > > > > > From: Gautam Ramakrishnan > > > > > > > > > > > > > > > > I have attempted to write a JPEG2000 Parser. Need > > > > > > > > help on testing the code and some tips on how to > > > > > > > > > > > > > > to test the code i would sugest to generate a file > > > > > > > or files with many jpeg2000 images and then try to > > > > > > > decode it to -f framecrc > > > > > > This helps me check whether the image is correct by comparing the > > > > > > CRC value? > > > > > > > if that work repeat while varying the packet size > > > > > > > input to the parser, a parser must work with anything > > > > > > > from 1 byte per input to sizes being larger than a > > > > > > > single frame. > > > > > > > > > > > > > So a packet to a parser is basically a smaller unit to which the > > > > > > parser is fed > > > > > > data to? When I tried printing buffer size during parse, it shows > > > > > > 4096. > > > > > > > > > > > Does that mean the packet size was 4096? > > > > > > > > > > yes, that likely comes from > > > > > libavformat/img2dec.c:size[0] = 4096; > > > > From my understanding of the documentation, the -packetsize option can > > > > change the > > > > value from 4096 to any particular I want right? However when I try > > > > setting the > > > > -packetsize option, the buf_size variable still shows up as 4096. > > > > > > img2dec hardcodes 4096, thats something you could change of course. > > > packetsize currently is listed with AV_OPT_FLAG_ENCODING_PARAM so its a > > > muxer > > > option. Some demuxers seem to set packet_size though instead of using it > > > as > > > input from the user > > > The header does not document packet_size with any detail > > > > > > Its probably best to add a new AVOption to img2dec to adjust the 4096 > > > > Can't the image2pipe demuxer option -frame_size be used instead? > > yes, indeed, that should work I'll try using this then, thanks > > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have never wished to cater to the crowd; for what I know they do not > approve, and what they approve I do not know. -- Epicurus > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- - Gautam | ___ ffmpeg-devel mailing list ffmpeg-devel@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 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)
> {
> OptionsContext *o = optctx;
> @@ -3548,6 +3564,10 @@ const OptionDef options[] = {
> { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
> OPT_EXPERT | OPT_INPUT, { .off
> = OFFSET(dump_attachment) },
> "extract an attachment into a file", "filename" },
> +{ "dump_filtergraph",HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_fg_filename },
> +"the output filename of filter graph for dump", "filename" },
> +{ "dump_filtergraph_format", HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_fg_format },
> +"the format of filter graph for dump, support DOT or ASCII"},
Possible to use AV_OPT_TYPE_CONST for these? maybe lowercase names?
Output for dot graph will very useful for me, thanks!
> { "stream_loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
> OPT_OFFSET, { .off
> = OFFSET(loop) }, "set number of times input stream shall be looped", "loop
> count" },
> { "debug_ts", OPT_BOOL | OPT_EXPERT,
Re: [FFmpeg-devel] [PATCH v4 1/2] fftools: add options to dump filter graph
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.
> 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.
> +@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.
> +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);
Stray space. Same below.
> +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)
> {
> OptionsContext *o = optctx;
> @@ -3548,6 +3564,10 @@ const OptionDef options[] = {
> { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
> OPT_EXPERT | OPT_INPUT, { .off
> = OFFSET(dump_attachment) },
> "extract an attachment into a file", "filename" },
> +{ "dump_filtergraph",HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_fg_filename },
> +"the output filename of filter graph for dump", "filename" },
> +{ "dump_filtergraph_format", HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_fg_format },
> +"the format of filter graph for dump, support DOT or ASCII"},
> { "stream_loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
> OPT_OFF
Re: [FFmpeg-devel] [PATCH v4 2/2] avdevice/lavf: add more options to dump filter graph
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. The existing dump_graph field can very well serve as the options string for the function. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/libopusenc: Don't free user-provided AVPacket
On 5/23/2020 7:44 AM, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libopusenc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 7c025a66d7..13017ac323 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -503,7 +503,6 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket
> *avpkt,
> // Check if subtraction resulted in an overflow
> if ((discard_padding < opus->opts.packet_size) != (avpkt->duration > 0))
> {
> av_packet_unref(avpkt);
> -av_free(avpkt);
> return AVERROR(EINVAL);
> }
> if (discard_padding > 0) {
> @@ -512,7 +511,6 @@ static int libopus_encode(AVCodecContext *avctx, AVPacket
> *avpkt,
> 10);
> if(!side_data) {
> av_packet_unref(avpkt);
> -av_free(avpkt);
> return AVERROR(ENOMEM);
> }
> AV_WL32(side_data + 4, discard_padding);
LGTM of course. And please backport it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: add untile filter.
Nicolas George (12020-04-16): > Signed-off-by: Nicolas George > --- > doc/filters.texi | 34 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_untile.c | 198 +++ > tests/fate/filter-video.mak | 3 + > tests/ref/fate/filter-untile | 13 +++ > 6 files changed, 250 insertions(+) > create mode 100644 libavfilter/vf_untile.c > create mode 100644 tests/ref/fate/filter-untile Puhed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavu: add av_gcd_q().
Nicolas George (12020-04-16): > TODO APIchanges and minor bump. > > Signed-off-by: Nicolas George > --- > libavutil/rational.c | 9 + > libavutil/rational.h | 6 ++ > 2 files changed, 15 insertions(+) Series pushed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavfi/formats: add ff_formats_pixdesc_filter().
Nicolas George (12020-04-16): > Signed-off-by: Nicolas George > --- > libavfilter/formats.c | 41 + > libavfilter/formats.h | 10 ++ > 2 files changed, 51 insertions(+) Series pushed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 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_filename = av_strdup (arg);
>
> Stray space. Same below.
OK, I copy the code from opt_vstats_file(), it has the stray space, I'll fix it.
>
> > +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)
> > {
> > OptionsContext *o = optctx;
> > @@ -3548,6 +3564,10 @@ const OptionDef options[] = {
> > { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
> > OPT_EXPERT | OPT_INPUT, {
> > .off = OFFSET(dump_attachment) },
> > "extract
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)
> > {
> > OptionsContext *o = optctx;
> > @@ -3548,6 +3564,10 @@ const OptionDef options[] = {
> > { "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
> > OPT_EXPERT | OPT_INPUT, {
> > .off = OFFSET(dump_attachment) },
> > "extract an attachment into a file", "filename" },
> > +{ "dump_filtergraph",HAS_ARG | OPT_EXPERT, {
> > .func_arg = opt_fg_filename },
> > +"the output filename of filter graph for dump", "filename" },
> > +{ "dump_filtergraph_format", HAS_ARG | OPT_EXPERT, {
> > .func_arg = opt_fg_format },
> > +"the format of filter graph for dump, support DOT or ASCII"},
>
> Possible to use AV_OPT_TYPE_CONST for these? maybe lowercase names?
It's used as string, so I
Re: [FFmpeg-devel] [PATCH v4 1/2] fftools: add options to dump filter graph
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. 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. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 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 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 1/2] fftools: add options to dump filter graph
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. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 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(&dict, options, "=", ":", 0);
+if (ret < 0) {
+av_dict_free(&dict);
+return NULL;
+}
+format = av_dict_get(dict, "fmt", NULL, 0);
+
+if (format && !strcmp(format->value, "DOT")) {
+av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
+avfilter_graph2dot_to_buf(&buf, graph);
+av_bprint_finalize(&buf, &dump);
+} 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 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
New version of patch is available by link https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1253 On Sun, 10 May 2020 at 00:55, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Sunday, May 10, 2020 1:19 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > On Sat, 9 May 2020 at 22:29, Soft Works wrote: > > > > > > You replied: > > > > yes, it is only a hint for D11 when possible. > > > > > > I would understand 'when possible' in a way that D3D9 would be used > > > 'when not possible'. > > > > > > If that's true, it means, that an ffmpeg user executing a command line > > > cannot be sure whether D3D9 or DX11 will be used. That would mean that > > > the behavior is not deterministic. > > > > > This is not true, it is your assumptions. > > Behavior is deterministic: > > DX11 by default. > > DX9 if user selects it explicitly via command line. > > > > > > But still, even with your patch: What will happen when DX11 is not > > > > > available? > > > > > > > > > > Will it > > > > > > > > > > Please read the patch > > > > > > > 1. fail? > > > > > > Yes > > > Thanks for confirming this. Deterministic behavior instead of > auto-selection > Is important and should not be changed. > > But on the other side, it needs to be clear to everybody, that this once > again > adds even more to the list of situations that the patch will break: In > this case, > it's all Windows versions where DX11 is not available. > > Best regards, > softworkz > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] apedec: add ability to check CRC
May 22, 2020, 23:50 by ceffm...@gmail.com: > Am Sa., 23. Mai 2020 um 00:43 Uhr schrieb Lynne : > >> >> Posting this again. >> >> The CRC flag is only signalled once every few minutes but CRC is still >> always present so the patch uses the file version instead. >> >> CRC on 24-bit files wants non-padded samples so skip such files. >> > > Should a warning be printed (once) for the 24-bit case if crc check > was requested? > I'm not sure, but I think I'd be inclined to say not here. We don't print warnings in other codecs when error checking is requested but unsupported by the codec. Its an optional feature that itself warns the user that there was a corruption in the file, and if the explode option is set, makes the warning an error and prevents further decoding of the corrupt block. > And please remove the parentheses from the first if, parentheses > in the second if are also superfluous... > Done. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] x86: cabac: Disable the inline asm on clang on windows on i386
The cabac inline assembly is very brittle to assemble properly on i386 windows with clang; libavcodec/hevc_cabac.c fails to build in the default mode (which is -march=pentium4), it only works if ffmpeg is configured with --cpu=i686 (translating to -march=i686), and likewise, the inline assembly fails to assemble in libavcodec/h264_cabac.c if building with optimizations disabled. Instead of trying to step around the problem (and end up bit by it occasionally), just disable the inline assembly for this configuration. --- libavcodec/x86/cabac.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/cabac.h b/libavcodec/x86/cabac.h index cfd3b759c9..5f1b97cec0 100644 --- a/libavcodec/x86/cabac.h +++ b/libavcodec/x86/cabac.h @@ -27,7 +27,7 @@ #include "libavutil/x86/asm.h" #include "config.h" -#if (defined(__i386) && defined(__clang__) && (__clang_major__<2 || (__clang_major__==2 && __clang_minor__<10)))\ +#if (defined(__i386) && defined(__clang__) && (__clang_major__<2 || (__clang_major__==2 && __clang_minor__<10)) || defined(_WIN32))\ || ( !defined(__clang__) && defined(__llvm__) && __GNUC__==4 && __GNUC_MINOR__==2 && __GNUC_PATCHLEVEL__<=1)\ || (defined(__INTEL_COMPILER) && defined(_MSC_VER)) # define BROKEN_COMPILER 1 -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/libopusenc: Don't free user-provided AVPacket
James Almer:
> On 5/23/2020 7:44 AM, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/libopusenc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
>> index 7c025a66d7..13017ac323 100644
>> --- a/libavcodec/libopusenc.c
>> +++ b/libavcodec/libopusenc.c
>> @@ -503,7 +503,6 @@ static int libopus_encode(AVCodecContext *avctx,
>> AVPacket *avpkt,
>> // Check if subtraction resulted in an overflow
>> if ((discard_padding < opus->opts.packet_size) != (avpkt->duration >
>> 0)) {
>> av_packet_unref(avpkt);
>> -av_free(avpkt);
>> return AVERROR(EINVAL);
>> }
>> if (discard_padding > 0) {
>> @@ -512,7 +511,6 @@ static int libopus_encode(AVCodecContext *avctx,
>> AVPacket *avpkt,
>> 10);
>> if(!side_data) {
>> av_packet_unref(avpkt);
>> -av_free(avpkt);
>> return AVERROR(ENOMEM);
>> }
>> AV_WL32(side_data + 4, discard_padding);
>
> LGTM of course. And please backport it.
Applied and backported up to 2.8.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] hwcontext_vulkan: use host mapped buffers when uploading and downloading
Speeds up both use cases by 30%.
Patch attached.
>From f47b694392eb992601459127e3bfc54a81013b3f Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 23 May 2020 19:02:08 +0100
Subject: [PATCH] hwcontext_vulkan: use host mapped buffers when uploading and
downloading
Speeds up both use cases by 30%.
---
libavutil/hwcontext_vulkan.c | 96 +++-
1 file changed, 83 insertions(+), 13 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index d45ab23983..f2db9fcd8f 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -208,6 +208,7 @@ enum VulkanExtensions {
EXT_DRM_MODIFIER_FLAGS = 1ULL << 1, /* VK_EXT_image_drm_format_modifier */
EXT_EXTERNAL_FD_MEMORY = 1ULL << 2, /* VK_KHR_external_memory_fd */
EXT_EXTERNAL_FD_SEM= 1ULL << 3, /* VK_KHR_external_semaphore_fd */
+EXT_EXTERNAL_HOST_MEMORY = 1ULL << 4, /* VK_EXT_external_memory_host */
EXT_NO_FLAG= 1ULL << 63,
};
@@ -226,6 +227,7 @@ static const VulkanOptExtension optional_device_exts[] = {
{ VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME, EXT_EXTERNAL_DMABUF_MEMORY, },
{ VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME,EXT_DRM_MODIFIER_FLAGS, },
{ VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME,EXT_EXTERNAL_FD_SEM,},
+{ VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME, EXT_EXTERNAL_HOST_MEMORY, },
};
/* Converts return values to strings */
@@ -2630,6 +2632,7 @@ typedef struct ImageBuffer {
VkBuffer buf;
VkDeviceMemory mem;
VkMemoryPropertyFlagBits flags;
+int host_mapped;
} ImageBuffer;
static void free_buf(void *opaque, uint8_t *data)
@@ -2668,7 +2671,12 @@ static int create_buf(AVHWDeviceContext *ctx, AVBufferRef **buf,
if (!vkbuf)
return AVERROR(ENOMEM);
-*stride = FFALIGN(*stride, p->props.limits.optimalBufferCopyRowPitchAlignment);
+vkbuf->host_mapped = alloc_pnext != NULL;
+
+/* This means we're importing memory, so we must not change the stride */
+if (!vkbuf->host_mapped)
+*stride = FFALIGN(*stride, p->props.limits.optimalBufferCopyRowPitchAlignment);
+
buf_spawn.size = height*(*stride);
ret = vkCreateBuffer(hwctx->act_dev, &buf_spawn, NULL, &vkbuf->buf);
@@ -2701,6 +2709,7 @@ static int create_buf(AVHWDeviceContext *ctx, AVBufferRef **buf,
return 0;
}
+/* Skips mapping of host mapped buffers but still invalidates them */
static int map_buffers(AVHWDeviceContext *ctx, AVBufferRef **bufs, uint8_t *mem[],
int nb_buffers, int invalidate)
{
@@ -2711,6 +2720,9 @@ static int map_buffers(AVHWDeviceContext *ctx, AVBufferRef **bufs, uint8_t *mem[
for (int i = 0; i < nb_buffers; i++) {
ImageBuffer *vkbuf = (ImageBuffer *)bufs[i]->data;
+if (vkbuf->host_mapped)
+continue;
+
ret = vkMapMemory(hwctx->act_dev, vkbuf->mem, 0,
VK_WHOLE_SIZE, 0, (void **)&mem[i]);
if (ret != VK_SUCCESS) {
@@ -2780,6 +2792,8 @@ static int unmap_buffers(AVHWDeviceContext *ctx, AVBufferRef **bufs,
for (int i = 0; i < nb_buffers; i++) {
ImageBuffer *vkbuf = (ImageBuffer *)bufs[i]->data;
+if (vkbuf->host_mapped)
+continue;
vkUnmapMemory(hwctx->act_dev, vkbuf->mem);
}
@@ -2915,7 +2929,11 @@ static int vulkan_transfer_data_from_mem(AVHWFramesContext *hwfc, AVFrame *dst,
AVHWDeviceContext *dev_ctx = hwfc->device_ctx;
AVBufferRef *bufs[AV_NUM_DATA_POINTERS] = { 0 };
const int planes = av_pix_fmt_count_planes(src->format);
-int log2_chroma = av_pix_fmt_desc_get(src->format)->log2_chroma_h;
+int log2_chroma_w = av_pix_fmt_desc_get(src->format)->log2_chroma_w;
+int log2_chroma_h = av_pix_fmt_desc_get(src->format)->log2_chroma_h;
+VulkanDevicePriv *p = hwfc->device_ctx->internal->priv;
+int host_mapped[AV_NUM_DATA_POINTERS] = { 0 };
+int map_host = p->extensions & EXT_EXTERNAL_HOST_MEMORY;
if ((src->format != AV_PIX_FMT_NONE && !av_vkfmt_from_pixfmt(src->format))) {
av_log(hwfc, AV_LOG_ERROR, "Unsupported source pixel format!\n");
@@ -2945,12 +2963,25 @@ static int vulkan_transfer_data_from_mem(AVHWFramesContext *hwfc, AVFrame *dst,
/* Create buffers */
for (int i = 0; i < planes; i++) {
int h = src->height;
-int p_height = i > 0 ? AV_CEIL_RSHIFT(h, log2_chroma) : h;
+int p_height = i > 0 ? AV_CEIL_RSHIFT(h, log2_chroma_h) : h;
+
+VkImportMemoryHostPointerInfoEXT import_desc = {
+.sType = VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT,
+.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT,
+.pHostPointer = src->data[i],
+};
+
+/* We can only map images with positive stride and alignment appropriate
+ * for the device. */
+host_mapped[i] = map_host && src->lin
Re: [FFmpeg-devel] [PATCH] hwcontext: add av_hwdevice_ctx_create_derived2
May 13, 2020, 00:17 by d...@lynne.ee:
> May 12, 2020, 23:16 by s...@jkqxz.net:
>
>> On 12/05/2020 20:16, Lynne wrote:
>>
>>> From 45ec8f730a183cd98b1d2d705e7a9582ef2f3f28 Mon Sep 17 00:00:00 2001
>>> From: Lynne
>>> Date: Mon, 11 May 2020 11:02:19 +0100
>>> Subject: [PATCH] hwcontext: add av_hwdevice_ctx_create_derived_opts
>>>
>>
>> Can you make the argument names and order consistent with the other
>> functions here?
>>
>> int av_hwdevice_ctx_create(AVBufferRef **device_ctx, enum AVHWDeviceType
>> type,
>> const char *device, AVDictionary *opts, int flags);
>>
>> int av_hwdevice_ctx_create_derived(AVBufferRef **dst_ctx,
>> enum AVHWDeviceType type,
>> AVBufferRef *src_ctx, int flags);
>>
>> int av_hwdevice_ctx_create_derived_opts(AVBufferRef **dst_ctx,
>> enum AVHWDeviceType type,
>> AVBufferRef *src_ctx,
>> AVDictionary *options, int flags);
>>
>> (Also make sure that the names match the documentation, which they do after
>> my suggested change.)
>>
>
> Changed. I copied the arguments from av_hwdevice_ctx_create_derived in
> hwcontext.c and didn't
> notice they were different to the ones in the header.
>
>
>
>>>
>>> /**
>>> * Allocate an AVHWFramesContext tied to a given device context.
>>> ...
>>> diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
>>> index dba0f39944..9d66245a23 100644
>>> --- a/libavutil/hwcontext_internal.h
>>> +++ b/libavutil/hwcontext_internal.h
>>> @@ -66,7 +66,7 @@ typedef struct HWContextType {
>>>
>>> int (*device_create)(AVHWDeviceContext *ctx, const char
>>> *device,
>>> AVDictionary *opts, int flags);
>>> -int (*device_derive)(AVHWDeviceContext *dst_ctx,
>>> +int (*device_derive)(AVHWDeviceContext *dst_ctx,
>>> AVDictionary *opts,
>>> AVHWDeviceContext *src_ctx, int flags);
>>>
>>
>> Arguments in the same order as device_create, please.
>>
>
> Changed.
>
>
>
>>>
>>> int (*device_init)(AVHWDeviceContext *ctx);
>>> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
>>> index 41fdfe96f1..b5a282b55b 100644
>>> --- a/libavutil/hwcontext_opencl.c
>>> +++ b/libavutil/hwcontext_opencl.c
>>> @@ -1193,7 +1193,7 @@ static int
>>> opencl_filter_drm_arm_device(AVHWDeviceContext *hwdev,
>>> }
>>> #endif
>>>
>>> -static int opencl_device_derive(AVHWDeviceContext *hwdev,
>>> +static int opencl_device_derive(AVHWDeviceContext *hwdev, AVDictionary
>>> *opts,
>>> AVHWDeviceContext *src_ctx,
>>> int flags)
>>> {
>>> @@ -1207,16 +1207,17 @@ static int opencl_device_derive(AVHWDeviceContext
>>> *hwdev,
>>> // Surface mapping works via DRM PRIME fds with no special
>>> // initialisation required in advance. This just finds the
>>> // Beignet ICD by name.
>>> -AVDictionary *opts = NULL;
>>> +AVDictionary *selector_opts = NULL;
>>> +av_dict_copy(&selector_opts, opts, 0);
>>>
>>> -err = av_dict_set(&opts, "platform_vendor", "Intel", 0);
>>> +err = av_dict_set(&selector_opts, "platform_vendor", "Intel",
>>> 0);
>>> if (err >= 0)
>>> -err = av_dict_set(&opts, "platform_version", "beignet", 0);
>>> +err = av_dict_set(&selector_opts, "platform_version",
>>> "beignet", 0);
>>> if (err >= 0) {
>>> OpenCLDeviceSelector selector = {
>>> .platform_index = -1,
>>> .device_index= 0,
>>> -.context = opts,
>>> +.context = selector_opts,
>>> .enumerate_platforms = &opencl_enumerate_platforms,
>>> .filter_platform = &opencl_filter_platform,
>>> .enumerate_devices = &opencl_enumerate_devices,
>>> @@ -1224,7 +1225,7 @@ static int opencl_device_derive(AVHWDeviceContext
>>> *hwdev,
>>> };
>>> err = opencl_device_create_internal(hwdev, &selector, NULL);
>>> }
>>> -av_dict_free(&opts);
>>> +av_dict_free(&selector_opts);
>>> }
>>> break;
>>> #endif
>>>
>>
>> Can you explain what this change to the code is trying to do? I might be
>> missing something, but the only additional effect that I can see of passing
>> through the outer options is that it might unexpectedly prevent the search
>> from finding the Beignet ICD (e.g. by having some conflicting device option).
>>
>
> I thought the selector options were passed onto device_init through some
> mechanism I couldn't see,
> where I thought they're set, and I mistakenly thought "device_extensions" in
> the opencl_device_params
> was a list of all accepted keys for options, but I was wrong - they're only
> used as filters for devices.
> Still, the selector code is... somewhat sphagetti, so its not that easy to
> figure out how it works.
> I've removed this change, only kept the change of name from opts to
> selector_opts so it won't
> conflict with the new argument.
>
>
>
>>> ...
>>>
>>> I've been testing and running this code for the past 2 days, planning to
>>> push this tomorrow if no one LGTMs.
>>>
>>
>> For
Re: [FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: expose the amount of queues for each queue family
Pushed, thanks for the review. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 00/10] Vulkan code general/performance improvements
May 15, 2020, 19:36 by d...@lynne.ee: > Just posting this as a single email not to spam the ML too much. > Going to push this sometime over the weekend alongside the other 3 patches to > finish > all work on Vulkan before the next release. > Satisfied with the code, though the last patch is slightly ugly. > Performance improvements out of async code: 78% on a toy GPU with 1 queue for > an upload+scale > Probably closer to 200% on a discrete GPU with 4 transfer/compute queues. > Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] compat/cuda/ptx2c: remove shell loop
> On May 23, 2020, at 06:47, Carl Eugen Hoyos wrote: > > Am Sa., 23. Mai 2020 um 06:01 Uhr schrieb rcombs : >> >> This improves build times dramatically >> --- >> compat/cuda/ptx2c.sh | 8 +++- >> 1 file changed, 3 insertions(+), 5 deletions(-) >> >> diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh >> index 0750e7a3b7..435a9b4b6c 100755 >> --- a/compat/cuda/ptx2c.sh >> +++ b/compat/cuda/ptx2c.sh >> @@ -27,10 +27,8 @@ IN="$2" >> NAME="$(basename "$IN" | sed 's/\..*//')" >> >> printf "const char %s_ptx[] = \\" "$NAME" > "$OUT" >> -while IFS= read -r LINE >> -do >> -printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e >> 's/["\\]/\\&/g')" >> "$OUT" >> -done < "$IN" >> -printf ";\n" >> "$OUT" >> +echo >> "$OUT" > >> +sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e >> 's/$/\\n"/' < "$IN" >> "$OUT" > > Is there a reason why you did not merge the two patches? > > Carl Eugen Just that I wrote them several months apart from one another, and they conceptually serve different purposes (perf in one, compatibility in the other). > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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] x86: cabac: Disable the inline asm on clang on windows on i386
Am Sa., 23. Mai 2020 um 20:35 Uhr schrieb Martin Storsjö : > > The cabac inline assembly is very brittle to assemble properly > on i386 windows with clang; libavcodec/hevc_cabac.c fails to build > in the default mode (which is -march=pentium4), it only works if > ffmpeg is configured with --cpu=i686 (translating to -march=i686), > and likewise, the inline assembly fails to assemble in > libavcodec/h264_cabac.c if building with optimizations disabled. > > Instead of trying to step around the problem (and end up bit by it > occasionally), just disable the inline assembly for this configuration. I think I cannot reproduce this issue, what may I miss? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] compat/cuda/ptx2c: remove shell loop
Am Sa., 23. Mai 2020 um 20:13 Uhr schrieb Ridley Combs : > > > On May 23, 2020, at 06:47, Carl Eugen Hoyos wrote: > > > > Am Sa., 23. Mai 2020 um 06:01 Uhr schrieb rcombs : > >> > >> This improves build times dramatically > >> --- > >> compat/cuda/ptx2c.sh | 8 +++- > >> 1 file changed, 3 insertions(+), 5 deletions(-) > >> > >> diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh > >> index 0750e7a3b7..435a9b4b6c 100755 > >> --- a/compat/cuda/ptx2c.sh > >> +++ b/compat/cuda/ptx2c.sh > >> @@ -27,10 +27,8 @@ IN="$2" > >> NAME="$(basename "$IN" | sed 's/\..*//')" > >> > >> printf "const char %s_ptx[] = \\" "$NAME" > "$OUT" > >> -while IFS= read -r LINE > >> -do > >> -printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e > >> 's/["\\]/\\&/g')" >> "$OUT" > >> -done < "$IN" > >> -printf ";\n" >> "$OUT" > >> +echo >> "$OUT" > > > >> +sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e > >> 's/$/\\n"/' < "$IN" >> "$OUT" > > > > Is there a reason why you did not merge the two patches? > > > Just that I wrote them several months apart from one another, and they > conceptually serve different purposes (perf in one, compatibility in the > other). Please merge them. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avformat/concatdec: Avoid duplicating buffer when adding side-data
Signed-off-by: Andreas Rheinhardt
---
The resulting side-data in this and the next two patches won't be padded
anymore. But the documentation doesn't require it and
av_packet_unpack_dictionary() doesn't rely on this anyway.
libavformat/concatdec.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 2173911ce4..4b56b61404 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -626,17 +626,16 @@ static int concat_read_packet(AVFormatContext *avf,
AVPacket *pkt)
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base));
if (cat->cur_file->metadata) {
-uint8_t* metadata;
int metadata_len;
char* packed_metadata =
av_packet_pack_dictionary(cat->cur_file->metadata, &metadata_len);
if (!packed_metadata)
return AVERROR(ENOMEM);
-if (!(metadata = av_packet_new_side_data(pkt,
AV_PKT_DATA_STRINGS_METADATA, metadata_len))) {
+ret = av_packet_add_side_data(pkt, AV_PKT_DATA_STRINGS_METADATA,
+ packed_metadata, metadata_len);
+if (ret < 0) {
av_freep(&packed_metadata);
-return AVERROR(ENOMEM);
+return ret;
}
-memcpy(metadata, packed_metadata, metadata_len);
-av_freep(&packed_metadata);
}
if (cat->cur_file->duration == AV_NOPTS_VALUE && st->cur_dts !=
AV_NOPTS_VALUE) {
@@ -647,7 +646,7 @@ static int concat_read_packet(AVFormatContext *avf,
AVPacket *pkt)
}
pkt->stream_index = cs->out_stream_index;
-return ret;
+return 0;
}
static void rescale_interval(AVRational tb_in, AVRational tb_out,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avformat/flvdec: Avoid duplicating extradata when adding side-data
Signed-off-by: Andreas Rheinhardt
---
libavformat/flvdec.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 7c3e5b06c6..957acedf39 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1283,12 +1283,11 @@ retry_duration:
pkt->stream_index = st->index;
pkt->pos = pos;
if (flv->new_extradata[stream_type]) {
-uint8_t *side = av_packet_new_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
-
flv->new_extradata_size[stream_type]);
-if (side) {
-memcpy(side, flv->new_extradata[stream_type],
- flv->new_extradata_size[stream_type]);
-av_freep(&flv->new_extradata[stream_type]);
+int ret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ flv->new_extradata[stream_type],
+
flv->new_extradata_size[stream_type]);
+if (ret >= 0) {
+flv->new_extradata[stream_type] = NULL;
flv->new_extradata_size[stream_type] = 0;
}
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avformat/img2dec: Avoid duplicating buffer when adding side-data
Signed-off-by: Andreas Rheinhardt
---
libavformat/img2dec.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 40f3e3d499..ee7ceed08f 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -379,8 +379,7 @@ int ff_img_read_header(AVFormatContext *s1)
* as a dictionary, so it can be used by filters like 'drawtext'.
*/
static int add_filename_as_pkt_side_data(char *filename, AVPacket *pkt) {
-uint8_t* metadata;
-int metadata_len;
+int metadata_len, ret;
AVDictionary *d = NULL;
char *packed_metadata = NULL;
@@ -391,13 +390,12 @@ static int add_filename_as_pkt_side_data(char *filename,
AVPacket *pkt) {
av_dict_free(&d);
if (!packed_metadata)
return AVERROR(ENOMEM);
-if (!(metadata = av_packet_new_side_data(pkt,
AV_PKT_DATA_STRINGS_METADATA, metadata_len))) {
+ret = av_packet_add_side_data(pkt, AV_PKT_DATA_STRINGS_METADATA,
+ packed_metadata, metadata_len);
+if (ret < 0) {
av_freep(&packed_metadata);
-return AVERROR(ENOMEM);
+return ret;
}
-memcpy(metadata, packed_metadata, metadata_len);
-av_freep(&packed_metadata);
-
return 0;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avformat/oggdec: Avoid duplicating buffer when adding side-data
Signed-off-by: Andreas Rheinhardt
---
libavformat/oggdec.c | 12 +---
libavformat/oggparsevorbis.c | 2 +-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 1a3acbb55e..b4ba00df61 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -877,14 +877,12 @@ retry:
}
if (os->new_metadata) {
-uint8_t *side_data = av_packet_new_side_data(pkt,
-
AV_PKT_DATA_METADATA_UPDATE,
- os->new_metadata_size);
-if(!side_data)
-return AVERROR(ENOMEM);
+ret = av_packet_add_side_data(pkt, AV_PKT_DATA_METADATA_UPDATE,
+ os->new_metadata, os->new_metadata_size);
+if (ret < 0)
+return ret;
-memcpy(side_data, os->new_metadata, os->new_metadata_size);
-av_freep(&os->new_metadata);
+os->new_metadata = NULL;
os->new_metadata_size = 0;
}
diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 27d2c686b6..f09d54488b 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -287,7 +287,7 @@ static int vorbis_update_metadata(AVFormatContext *s, int
idx)
os->new_metadata = av_packet_pack_dictionary(st->metadata,
&os->new_metadata_size);
/* Send an empty dictionary to indicate that metadata has been cleared. */
} else {
-os->new_metadata = av_malloc(1);
+os->new_metadata = av_mallocz(1);
os->new_metadata_size = 0;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5 3/3] fftools: add options to dump filter graph
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/ffmpeg.texi | 12
fftools/ffmpeg.c| 1 +
fftools/ffmpeg.h| 1 +
fftools/ffmpeg_filter.c | 11 +++
fftools/ffmpeg_opt.c| 10 ++
5 files changed, 35 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index ed437bb..c7dd73b 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -735,6 +735,18 @@ 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{options} (@emph{global})
+Dump graph to stderr with more options
+
+options is a ':'-separated list of @var{key=value} pairs.
+
+Set the graph with graphviz DOT format by @var{fmt=dot|DOT},
+set the filename of filtergraph to output by @var{filename=path}.
+
+@example
+ffmpeg -dump_filtergraph fmt=dot:filename=./test.tmp -i INPUT
+@end example
+
@item -noautorotate
Disable automatically rotating video based on file metadata.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f697460..2c611a7 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -625,6 +625,7 @@ static void ffmpeg_cleanup(int ret)
av_err2str(AVERROR(errno)));
}
av_freep(&vstats_filename);
+av_freep(&dump_filtergraph);
av_freep(&input_streams);
av_freep(&input_files);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 38205a1..000c682 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -578,6 +578,7 @@ extern intnb_filtergraphs;
extern char *vstats_filename;
extern char *sdp_filename;
+extern char *dump_filtergraph;
extern float audio_drift_threshold;
extern float dts_delta_threshold;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 8b5b157..c5adfae 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1106,6 +1106,17 @@ int configure_filtergraph(FilterGraph *fg)
if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
goto fail;
+if (dump_filtergraph) {
+char *dump = avfilter_graph_dump(fg->graph, dump_filtergraph);
+if (!dump) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+fputs(dump, stderr);
+fflush(stderr);
+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..e4ebc88 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -143,6 +143,7 @@ HWDevice *filter_hw_device;
char *vstats_filename;
char *sdp_filename;
+char *dump_filtergraph;
float audio_drift_threshold = 0.1;
float dts_delta_threshold = 10;
@@ -2914,6 +2915,13 @@ static int opt_vstats_file(void *optctx, const char
*opt, const char *arg)
return 0;
}
+static int opt_dumpgraph(void *optctx, const char *opt, const char *arg)
+{
+av_free (dump_filtergraph);
+dump_filtergraph = av_strdup(arg);
+return 0;
+}
+
static int opt_vstats(void *optctx, const char *opt, const char *arg)
{
char filename[40];
@@ -3548,6 +3556,8 @@ const OptionDef options[] = {
{ "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
OPT_EXPERT | OPT_INPUT, { .off =
OFFSET(dump_attachment) },
"extract an attachment into a file", "filename" },
+{ "dump_filtergraph",HAS_ARG | OPT_EXPERT, {
.func_arg = opt_dumpgraph },
+"dump filter graph to stderr with options"},
{ "stream_loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
OPT_OFFSET, { .off =
OFFSET(loop) }, "set number of times input stream shall be looped", "loop
count" },
{ "debug_ts", OPT_BOOL | OPT_EXPERT, {
&debug_ts },
--
2.6.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".
[FFmpeg-devel] [PATCH v5 1/3] avfilter/graphdump: support for the graph2dot function
From: Limin Wang
reuse the function from tools/graph2dot.c and add support for filter graph with
graphviz DOT format for avfilter directly. So tools/graph2dot.c is duplicated
and can be removed.
In addition, make the options are pair-key format, now it support two key:
fmt=DOT|dot
filename=./outfile
Signed-off-by: Limin Wang
---
libavfilter/graphdump.c | 89 +
tools/graph2dot.c | 204
2 files changed, 89 insertions(+), 204 deletions(-)
delete mode 100644 tools/graph2dot.c
diff --git a/libavfilter/graphdump.c b/libavfilter/graphdump.c
index 79ef1a7..c7298e3 100644
--- a/libavfilter/graphdump.c
+++ b/libavfilter/graphdump.c
@@ -151,15 +151,104 @@ static void avfilter_graph_dump_to_buf(AVBPrint *buf,
AVFilterGraph *graph)
}
}
+static void avfilter_graph2dot_to_buf(AVBPrint *buf, AVFilterGraph *graph)
+{
+int i, j;
+
+av_bprintf(buf, "digraph G {\n");
+av_bprintf(buf, "node [shape=box]\n");
+av_bprintf(buf, "rankdir=LR\n");
+
+for (i = 0; i < graph->nb_filters; i++) {
+char filter_ctx_label[128];
+const AVFilterContext *filter_ctx = graph->filters[i];
+
+snprintf(filter_ctx_label, sizeof(filter_ctx_label), "%s\\n(%s)",
+ filter_ctx->name,
+ filter_ctx->filter->name);
+
+for (j = 0; j < filter_ctx->nb_outputs; j++) {
+AVFilterLink *link = filter_ctx->outputs[j];
+if (link) {
+char dst_filter_ctx_label[128];
+const AVFilterContext *dst_filter_ctx = link->dst;
+
+snprintf(dst_filter_ctx_label, sizeof(dst_filter_ctx_label),
+ "%s\\n(%s)",
+ dst_filter_ctx->name,
+ dst_filter_ctx->filter->name);
+
+av_bprintf(buf, "\"%s\" -> \"%s\" [ label= \"inpad:%s ->
outpad:%s\\n",
+filter_ctx_label, dst_filter_ctx_label,
+avfilter_pad_get_name(link->srcpad, 0),
+avfilter_pad_get_name(link->dstpad, 0));
+
+if (link->type == AVMEDIA_TYPE_VIDEO) {
+const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(link->format);
+av_bprintf(buf,
+"fmt:%s w:%d h:%d tb:%d/%d",
+desc->name,
+link->w, link->h,
+link->time_base.num, link->time_base.den);
+} else if (link->type == AVMEDIA_TYPE_AUDIO) {
+char audio_buf[255];
+av_get_channel_layout_string(audio_buf, sizeof(audio_buf),
-1,
+ link->channel_layout);
+av_bprintf(buf,
+"fmt:%s sr:%d cl:%s tb:%d/%d",
+av_get_sample_fmt_name(link->format),
+link->sample_rate, audio_buf,
+link->time_base.num, link->time_base.den);
+}
+av_bprintf(buf, "\" ];\n");
+}
+}
+}
+av_bprintf(buf, "}\n");
+}
+
char *avfilter_graph_dump(AVFilterGraph *graph, const char *options)
{
AVBPrint buf;
char *dump = NULL;
+int ret;
+AVDictionary *dict = NULL;
+AVDictionaryEntry *format = NULL;
+AVDictionaryEntry *filename = NULL;
+
+ret = av_dict_parse_string(&dict, options, "=", ":", 0);
+if (ret < 0) {
+av_dict_free(&dict);
+return NULL;
+}
+format = av_dict_get(dict, "fmt", NULL, 0);
+if (format && !strcasecmp(format->value, "DOT")) {
+av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
+avfilter_graph2dot_to_buf(&buf, graph);
+av_bprint_finalize(&buf, &dump);
+} else {
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_COUNT_ONLY);
avfilter_graph_dump_to_buf(&buf, graph);
av_bprint_init(&buf, buf.len + 1, buf.len + 1);
avfilter_graph_dump_to_buf(&buf, graph);
av_bprint_finalize(&buf, &dump);
+}
+
+if (filename = av_dict_get(dict, "filename", NULL, 0)) {
+FILE* file = fopen(filename->value, "w");
+if (!file) {
+av_log(graph, AV_LOG_ERROR, "failed to open: %s \n",
filename->value);
+av_freep(&dump);
+return NULL;
+}
+if (dump) {
+fputs(dump, file);
+fflush(file);
+fclose(file);
+}
+}
+
+av_dict_free(&dict);
return dump;
}
diff --git a/tools/graph2dot.c b/tools/graph2dot.c
deleted file mode 100644
index d5c1e4e..000
--- a/tools/graph2dot.c
+++ /dev/null
@@ -1,204 +0,0 @@
-/*
- * Copyright (c) 2008-2010 Stefano Sabatini
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; eit
[FFmpeg-devel] [PATCH v5 2/3] avdevice/lavfi: support the dumpgraph with options
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/indevs.texi | 15 +--
libavdevice/lavfi.c | 2 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf..7ec7062 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -973,8 +973,13 @@ Set the filename of the filtergraph to be read and sent to
the other
filters. Syntax of the filtergraph is the same as the one specified by
the option @var{graph}.
-@item dumpgraph
-Dump graph to stderr.
+@item dumpgraph @var{options}
+Dump graph to stderr with more options
+
+options is a ':'-separated list of @var{key=value} pairs.
+
+Set the graph with graphviz DOT format by @var{fmt=dot|DOT},
+set the filename of filtergraph to output by @var{filename=path}.
@end table
@@ -988,6 +993,12 @@ ffplay -f lavfi -graph "color=c=pink [out0]" dummy
@end example
@item
+dump the filter graph with graphviz DOT output format to ./test.tmp
+@example
+ffplay -dumpgraph fmt=dot:filename=./test.tmp -f lavfi color=c=pink
+@end example
+
+@item
As the previous example, but use filename for specifying the graph
description, and omit the "out0" label:
@example
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index c949ff7..fa75fde 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -493,7 +493,7 @@ static int lavfi_read_packet(AVFormatContext *avctx,
AVPacket *pkt)
static const AVOption options[] = {
{ "graph", "set libavfilter graph", OFFSET(graph_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
{ "graph_file","set libavfilter graph filename", OFFSET(graph_filename),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC},
-{ "dumpgraph", "dump graph to stderr", OFFSET(dump_graph),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
+{ "dumpgraph", "dump graph to stderr with more options",
OFFSET(dump_graph), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
{ NULL },
};
--
2.6.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".
[FFmpeg-devel] [PATCH v6 2/3] avdevice/lavfi: support the dumpgraph with options
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/indevs.texi | 15 +--
libavdevice/lavfi.c | 2 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 6f5afaf..7ec7062 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -973,8 +973,13 @@ Set the filename of the filtergraph to be read and sent to
the other
filters. Syntax of the filtergraph is the same as the one specified by
the option @var{graph}.
-@item dumpgraph
-Dump graph to stderr.
+@item dumpgraph @var{options}
+Dump graph to stderr with more options
+
+options is a ':'-separated list of @var{key=value} pairs.
+
+Set the graph with graphviz DOT format by @var{fmt=dot|DOT},
+set the filename of filtergraph to output by @var{filename=path}.
@end table
@@ -988,6 +993,12 @@ ffplay -f lavfi -graph "color=c=pink [out0]" dummy
@end example
@item
+dump the filter graph with graphviz DOT output format to ./test.tmp
+@example
+ffplay -dumpgraph fmt=dot:filename=./test.tmp -f lavfi color=c=pink
+@end example
+
+@item
As the previous example, but use filename for specifying the graph
description, and omit the "out0" label:
@example
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index c949ff7..fa75fde 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -493,7 +493,7 @@ static int lavfi_read_packet(AVFormatContext *avctx,
AVPacket *pkt)
static const AVOption options[] = {
{ "graph", "set libavfilter graph", OFFSET(graph_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
{ "graph_file","set libavfilter graph filename", OFFSET(graph_filename),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC},
-{ "dumpgraph", "dump graph to stderr", OFFSET(dump_graph),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
+{ "dumpgraph", "dump graph to stderr with more options",
OFFSET(dump_graph), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
{ NULL },
};
--
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] [PATCH v6 1/3] avfilter/graphdump: support for the graph2dot function
From: Limin Wang
reuse the function from tools/graph2dot.c and add support for filter graph with
graphviz DOT format for avfilter directly. So tools/graph2dot.c is duplicated
and can be removed.
In addition, make the options are pair-key format, now it support two key:
fmt=DOT|dot
filename=./outfile
Signed-off-by: Limin Wang
---
libavfilter/graphdump.c | 89 +
tools/graph2dot.c | 204
2 files changed, 89 insertions(+), 204 deletions(-)
delete mode 100644 tools/graph2dot.c
diff --git a/libavfilter/graphdump.c b/libavfilter/graphdump.c
index 79ef1a7..97d4f39 100644
--- a/libavfilter/graphdump.c
+++ b/libavfilter/graphdump.c
@@ -151,15 +151,104 @@ static void avfilter_graph_dump_to_buf(AVBPrint *buf,
AVFilterGraph *graph)
}
}
+static void avfilter_graph2dot_to_buf(AVBPrint *buf, AVFilterGraph *graph)
+{
+int i, j;
+
+av_bprintf(buf, "digraph G {\n");
+av_bprintf(buf, "node [shape=box]\n");
+av_bprintf(buf, "rankdir=LR\n");
+
+for (i = 0; i < graph->nb_filters; i++) {
+char filter_ctx_label[128];
+const AVFilterContext *filter_ctx = graph->filters[i];
+
+snprintf(filter_ctx_label, sizeof(filter_ctx_label), "%s\\n(%s)",
+ filter_ctx->name,
+ filter_ctx->filter->name);
+
+for (j = 0; j < filter_ctx->nb_outputs; j++) {
+AVFilterLink *link = filter_ctx->outputs[j];
+if (link) {
+char dst_filter_ctx_label[128];
+const AVFilterContext *dst_filter_ctx = link->dst;
+
+snprintf(dst_filter_ctx_label, sizeof(dst_filter_ctx_label),
+ "%s\\n(%s)",
+ dst_filter_ctx->name,
+ dst_filter_ctx->filter->name);
+
+av_bprintf(buf, "\"%s\" -> \"%s\" [ label= \"inpad:%s ->
outpad:%s\\n",
+filter_ctx_label, dst_filter_ctx_label,
+avfilter_pad_get_name(link->srcpad, 0),
+avfilter_pad_get_name(link->dstpad, 0));
+
+if (link->type == AVMEDIA_TYPE_VIDEO) {
+const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(link->format);
+av_bprintf(buf,
+"fmt:%s w:%d h:%d tb:%d/%d",
+desc->name,
+link->w, link->h,
+link->time_base.num, link->time_base.den);
+} else if (link->type == AVMEDIA_TYPE_AUDIO) {
+char audio_buf[255];
+av_get_channel_layout_string(audio_buf, sizeof(audio_buf),
-1,
+ link->channel_layout);
+av_bprintf(buf,
+"fmt:%s sr:%d cl:%s tb:%d/%d",
+av_get_sample_fmt_name(link->format),
+link->sample_rate, audio_buf,
+link->time_base.num, link->time_base.den);
+}
+av_bprintf(buf, "\" ];\n");
+}
+}
+}
+av_bprintf(buf, "}\n");
+}
+
char *avfilter_graph_dump(AVFilterGraph *graph, const char *options)
{
AVBPrint buf;
char *dump = NULL;
+int ret;
+AVDictionary *dict = NULL;
+AVDictionaryEntry *format = NULL;
+AVDictionaryEntry *filename = NULL;
+
+ret = av_dict_parse_string(&dict, options, "=", ":", 0);
+if (ret < 0) {
+av_dict_free(&dict);
+return NULL;
+}
+format = av_dict_get(dict, "fmt", NULL, 0);
+if (format && !av_strcasecmp(format->value, "DOT")) {
+av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
+avfilter_graph2dot_to_buf(&buf, graph);
+av_bprint_finalize(&buf, &dump);
+} else {
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_COUNT_ONLY);
avfilter_graph_dump_to_buf(&buf, graph);
av_bprint_init(&buf, buf.len + 1, buf.len + 1);
avfilter_graph_dump_to_buf(&buf, graph);
av_bprint_finalize(&buf, &dump);
+}
+
+if (filename = av_dict_get(dict, "filename", NULL, 0)) {
+FILE* file = fopen(filename->value, "w");
+if (!file) {
+av_log(graph, AV_LOG_ERROR, "failed to open: %s \n",
filename->value);
+av_freep(&dump);
+return NULL;
+}
+if (dump) {
+fputs(dump, file);
+fflush(file);
+}
+fclose(file);
+}
+
+av_dict_free(&dict);
return dump;
}
diff --git a/tools/graph2dot.c b/tools/graph2dot.c
deleted file mode 100644
index d5c1e4e..000
--- a/tools/graph2dot.c
+++ /dev/null
@@ -1,204 +0,0 @@
-/*
- * Copyright (c) 2008-2010 Stefano Sabatini
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; eith
[FFmpeg-devel] [PATCH v6 3/3] fftools: add options to dump filter graph
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/ffmpeg.texi | 12
fftools/ffmpeg.c| 1 +
fftools/ffmpeg.h| 1 +
fftools/ffmpeg_filter.c | 11 +++
fftools/ffmpeg_opt.c| 10 ++
5 files changed, 35 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index ed437bb..c7dd73b 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -735,6 +735,18 @@ 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{options} (@emph{global})
+Dump graph to stderr with more options
+
+options is a ':'-separated list of @var{key=value} pairs.
+
+Set the graph with graphviz DOT format by @var{fmt=dot|DOT},
+set the filename of filtergraph to output by @var{filename=path}.
+
+@example
+ffmpeg -dump_filtergraph fmt=dot:filename=./test.tmp -i INPUT
+@end example
+
@item -noautorotate
Disable automatically rotating video based on file metadata.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ad95a0e..a51167c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -625,6 +625,7 @@ static void ffmpeg_cleanup(int ret)
av_err2str(AVERROR(errno)));
}
av_freep(&vstats_filename);
+av_freep(&dump_filtergraph);
av_freep(&input_streams);
av_freep(&input_files);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 38205a1..000c682 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -578,6 +578,7 @@ extern intnb_filtergraphs;
extern char *vstats_filename;
extern char *sdp_filename;
+extern char *dump_filtergraph;
extern float audio_drift_threshold;
extern float dts_delta_threshold;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 422e126..4a3be39 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1107,6 +1107,17 @@ int configure_filtergraph(FilterGraph *fg)
if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
goto fail;
+if (dump_filtergraph) {
+char *dump = avfilter_graph_dump(fg->graph, dump_filtergraph);
+if (!dump) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+fputs(dump, stderr);
+fflush(stderr);
+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..e4ebc88 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -143,6 +143,7 @@ HWDevice *filter_hw_device;
char *vstats_filename;
char *sdp_filename;
+char *dump_filtergraph;
float audio_drift_threshold = 0.1;
float dts_delta_threshold = 10;
@@ -2914,6 +2915,13 @@ static int opt_vstats_file(void *optctx, const char
*opt, const char *arg)
return 0;
}
+static int opt_dumpgraph(void *optctx, const char *opt, const char *arg)
+{
+av_free (dump_filtergraph);
+dump_filtergraph = av_strdup(arg);
+return 0;
+}
+
static int opt_vstats(void *optctx, const char *opt, const char *arg)
{
char filename[40];
@@ -3548,6 +3556,8 @@ const OptionDef options[] = {
{ "dump_attachment", HAS_ARG | OPT_STRING | OPT_SPEC |
OPT_EXPERT | OPT_INPUT, { .off =
OFFSET(dump_attachment) },
"extract an attachment into a file", "filename" },
+{ "dump_filtergraph",HAS_ARG | OPT_EXPERT, {
.func_arg = opt_dumpgraph },
+"dump filter graph to stderr with options"},
{ "stream_loop", OPT_INT | HAS_ARG | OPT_EXPERT | OPT_INPUT |
OPT_OFFSET, { .off =
OFFSET(loop) }, "set number of times input stream shall be looped", "loop
count" },
{ "debug_ts", OPT_BOOL | OPT_EXPERT, {
&debug_ts },
--
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] [PATCH v2] avfilter/vf_lut3d: prelut support for 3d cinespace luts
From: Mark Reid
changes since v1:
* cleaned up code style
* slightly reworked apply_lut functions to feel more consistent with code
---
libavfilter/vf_lut3d.c | 372 +++--
1 file changed, 317 insertions(+), 55 deletions(-)
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 482e2394a7..e5d9fcc068 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -59,6 +59,15 @@ struct rgbvec {
/* 3D LUT don't often go up to level 32, but it is common to have a Hald CLUT
* of 512x512 (64x64x64) */
#define MAX_LEVEL 256
+#define PRELUT_SIZE 65536
+
+typedef struct Lut3DPreLut {
+int size;
+float min[3];
+float max[3];
+float scale[3];
+float* lut[3];
+} Lut3DPreLut;
typedef struct LUT3DContext {
const AVClass *class;
@@ -71,6 +80,7 @@ typedef struct LUT3DContext {
struct rgbvec *lut;
int lutsize;
int lutsize2;
+Lut3DPreLut prelut;
#if CONFIG_HALDCLUT_FILTER
uint8_t clut_rgba_map[4];
int clut_step;
@@ -234,11 +244,39 @@ static inline struct rgbvec interp_tetrahedral(const
LUT3DContext *lut3d,
return c;
}
+static inline float prelut_interp_1d_linear(const Lut3DPreLut *prelut,
+int idx, const float s)
+{
+const int lut_max = prelut->size - 1;
+const float scaled = (s - prelut->min[idx]) * prelut->scale[idx];
+const float x = av_clipf(scaled, 0.0f, lut_max);
+const int prev = PREV(x);
+const int next = FFMIN((int)(x) + 1, lut_max);
+const float p = prelut->lut[idx][prev];
+const float n = prelut->lut[idx][next];
+const float d = x - (float)prev;
+return lerpf(p, n, d);
+}
+
+static inline struct rgbvec apply_prelut(const Lut3DPreLut *prelut,
+ const struct rgbvec *s)
+{
+if (prelut->size <= 0)
+return *s;
+
+struct rgbvec c;
+c.r = prelut_interp_1d_linear(prelut, 0, s->r);
+c.g = prelut_interp_1d_linear(prelut, 1, s->g);
+c.b = prelut_interp_1d_linear(prelut, 2, s->b);
+return c;
+}
+
#define DEFINE_INTERP_FUNC_PLANAR(name, nbits, depth)
\
static int interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs) \
{
\
int x, y;
\
const LUT3DContext *lut3d = ctx->priv;
\
+const Lut3DPreLut *prelut = &lut3d->prelut;
\
const ThreadData *td = arg;
\
const AVFrame *in = td->in;
\
const AVFrame *out = td->out;
\
@@ -253,9 +291,11 @@ static int
interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
const uint8_t *srcbrow = in->data[1] + slice_start * in->linesize[1];
\
const uint8_t *srcrrow = in->data[2] + slice_start * in->linesize[2];
\
const uint8_t *srcarow = in->data[3] + slice_start * in->linesize[3];
\
-const float scale_r = (lut3d->scale.r / ((1scale.g / ((1scale.b / ((1lutsize - 1;
\
+const float scale_f = 1.0f / ((1scale.g * lut_max;
\
+const float scale_b = lut3d->scale.b * lut_max;
\
\
for (y = slice_start; y < slice_end; y++) {
\
uint##nbits##_t *dstg = (uint##nbits##_t *)grow;
\
@@ -267,9 +307,13 @@ static int
interp_##nbits##_##name##_p##depth(AVFilterContext *ctx, void *arg, i
const uint##nbits##_t *srcr = (const uint##nbits##_t *)srcrrow;
\
const uint##nbits##_t *srca = (const uint##nbits##_t *)srcarow;
\
for (x = 0; x < in->width; x++) {
\
-const struct rgbvec scaled_rgb = {srcr[x] * scale_r,
[FFmpeg-devel] ffmpeg Filtergraph Output
Hello, I've seen the commit about the option for dumping the filtergraph and that reminded me about something that I'd be willing to contribute in case anybody likes it. A while ago I was looking for a way to get information about the filtergraphs that ffmpeg builds at runtime, the individual formats that have been negotiated between input and output pins and which filters have a hardware context. I had expected that this is what the graph2dot is intended to do, but that wasn't the case. Turning a filter string into a graph is not what I was looking for. Eventually I have implemented a feature that iterates all filters, their connections and the negotiated media formats during runtime and writes them out as json or xml (using the same methods that ffprobe uses). I have attached an example output and an image as an example for what could be done with the output. Let me know whether there's some interest in this. Regards Softworkz Direct links to the attachments: https://gist.github.com/softworkz/4f4bf2c1365d2ce3f6ac70b1b434aa40 https://github.com/softworkz/ffmpegfiltergraphs/issues/1 ffmpeg_filtergraph.json Description: ffmpeg_filtergraph.json ___ ffmpeg-devel mailing list ffmpeg-devel@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] ffmpeg Filtergraph Output
On Sun, 24 May 2020 at 05:44, Soft Works wrote: > Hello, > > I've seen the commit about the option for dumping the filtergraph and that > reminded me about something that I'd be willing to contribute in case > anybody likes it. > > A while ago I was looking for a way to get information about the > filtergraphs that ffmpeg builds at runtime, the individual formats that > have been negotiated between input and output pins and which filters have a > hardware context. > > I had expected that this is what the graph2dot is intended to do, but that > wasn't the case. Turning a filter string into a graph is not what I was > looking for. > > Eventually I have implemented a feature that iterates all filters, their > connections and the negotiated media formats during runtime and writes them > out as json or xml (using the same methods that ffprobe uses). > > I have attached an example output and an image as an example for what > could be done with the output. > > Let me know whether there's some interest in this. > > Regards > Softworkz > > Direct links to the attachments: > https://gist.github.com/softworkz/4f4bf2c1365d2ce3f6ac70b1b434aa40 > https://github.com/softworkz/ffmpegfiltergraphs/issues/1 > > > This is very fascinating, thanks for working on this. Such output would allow for troubleshooting filter performance, especially in complex filter setups where hardware contexts are in use. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
