Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On 2024-07-10 15:51 +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-07-10 15:44:47) > > Do you still object to a 32bit check on width and height ? > > If not i intend to apply a patch adding such limits > > If you object i will take this to the TC > > In my first reply in this thread I asked for a very simple thing - > justify this commit, as the commit message provided ZERO arguments for > why is this done and what it actually improves. > > Instead of answering the question you keep painting ever wordier walls > of text. I'm not reading all that. Just answer the question, in the form > suitable for a commit message. As most of the time a communications problem AFAICS :( The answer Anton was probably looking for: The intention of av_image_check_size2 (and it it's predecessors) always was to use a bigger integer type (64bit) to check width and height fit into the limits of the next smaller integer type (32bit). Unfortunately it wasn't spelled out explicitly in the commit message back then, and the implementation incorrectly assumed that INT_MAX would always refer to 32bit signed max. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-06-02 11:27 +0200, Alexander Strasser via ffmpeg-devel wrote: > On 2024-04-29 23:53 +0200, Alexander Strasser via ffmpeg-devel wrote: > > When piping ffmpeg into ffplay both programs write a status line in > > the terminal. That causes flickering and invisibility of one or the > > other status line. > > > > As compromise set ffplay log level to warning, so it doesn't show > > the status line. > > > > The user is usually testing ffmpeg command lines and want's a > > preview of the result. This way the user can see the ffmpeg output > > and still see errors and warnings from ffplay, should they occur. > > > > Additionally set PTS to zero in ffplay to lessen the delay until > > the frames are displayed. Without it delay is quite observable > > when e.g. live capturing with low frame rates. > > --- > > > > Same as previous patch, but with setpts=0 in ffplay as suggested by > > Nicolas George. > > > > > > libavdevice/opengl_enc.c | 2 +- > > libavdevice/sdl2.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c > > index 6f7a30ff9e..93d3959880 100644 > > --- a/libavdevice/opengl_enc.c > > +++ b/libavdevice/opengl_enc.c > > @@ -1067,7 +1067,7 @@ static av_cold int > > opengl_write_header(AVFormatContext *h) > > av_log(opengl, AV_LOG_WARNING, > > "The opengl output device is deprecated due to being > > fundamentally incompatible with libavformat API. " > > "For monitoring purposes in ffmpeg you can output to a file or > > use pipes and a video player.\n" > > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > > -loglevel warning -vf setpts=0 -\n" > > ); > > opengl->warned = 1; > > } > > diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c > > index 779c8e08b0..491c8dafe8 100644 > > --- a/libavdevice/sdl2.c > > +++ b/libavdevice/sdl2.c > > @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) > > av_log(sdl, AV_LOG_WARNING, > > "The sdl output device is deprecated due to being > > fundamentally incompatible with libavformat API. " > > "For monitoring purposes in ffmpeg you can output to a file or > > use pipes and a video player.\n" > > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > > -loglevel warning -vf setpts=0 -\n" > > ); > > sdl->warned = 1; > > } > > -- > > > Will try to push soon'ish if I don't hear any objections. Finally pushed. Was way more "ish" than "soon"... Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavu/float_dsp: add double-precision scalar product
On 2024-06-02 13:30 +0300, Rémi Denis-Courmont wrote: > Le sunnuntaina 2. kesäkuuta 2024, 13.04.05 EEST Alexander Strasser via ffmpeg- > devel a écrit : > > On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote: > > > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a > > > écrit> > > > > > +static double ff_scalarproduct_double_c(const double *v1, > > > > > > > > Don't use an ff_ prefix for a static function. > > > > > > I can see over 300 such identifiers in the code base (many but not all > > > inline), and I don't see why that would be a problem. > > > > I agree that it's not a problem regarding on the functional side, > > OTOH regarding coding conventions we try to consistently follow it's > > misleading as the ff_ prefix indicates a bigger scope of sharing. > > Anybody can see the 'static' qualifier literally in front to see the function > is not in a bigger scope of sharing. And if you do somehow miss and try to use > the function, you will get a linker error. > > The only case where this *actually* matters is in debugging. And exactly then > it is much better to use the ff_ prefix *because* all symbols, including local > ones like this, end up sharing the namespace. But not at the call site? > > I think Andreas remark is correct and it would be better to not use ff_ > > prefix wrongly when adding new code. > > IMO, it is worse. I tend to disagree here as it makes the meaning of the ff_ prefix arbitrary. Anyway if you want to challenge this convention we are using since many years in this code base, I suggest to do it in a separate discussion thread. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavu/float_dsp: add double-precision scalar product
On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote: > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a écrit > : > > > +static double ff_scalarproduct_double_c(const double *v1, > > > Don't use an ff_ prefix for a static function. > > I can see over 300 such identifiers in the code base (many but not all > inline), > and I don't see why that would be a problem. I agree that it's not a problem regarding on the functional side, OTOH regarding coding conventions we try to consistently follow it's misleading as the ff_ prefix indicates a bigger scope of sharing. Maybe I'm missing something, but it looks to me that more than half of those over 300 instances are correct (the inline ones in the headers). I think Andreas remark is correct and it would be better to not use ff_ prefix wrongly when adding new code. Best regards, Alexander [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-04-29 23:53 +0200, Alexander Strasser via ffmpeg-devel wrote: > When piping ffmpeg into ffplay both programs write a status line in > the terminal. That causes flickering and invisibility of one or the > other status line. > > As compromise set ffplay log level to warning, so it doesn't show > the status line. > > The user is usually testing ffmpeg command lines and want's a > preview of the result. This way the user can see the ffmpeg output > and still see errors and warnings from ffplay, should they occur. > > Additionally set PTS to zero in ffplay to lessen the delay until > the frames are displayed. Without it delay is quite observable > when e.g. live capturing with low frame rates. > --- > > Same as previous patch, but with setpts=0 in ffplay as suggested by > Nicolas George. > > > libavdevice/opengl_enc.c | 2 +- > libavdevice/sdl2.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c > index 6f7a30ff9e..93d3959880 100644 > --- a/libavdevice/opengl_enc.c > +++ b/libavdevice/opengl_enc.c > @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext > *h) > av_log(opengl, AV_LOG_WARNING, > "The opengl output device is deprecated due to being > fundamentally incompatible with libavformat API. " > "For monitoring purposes in ffmpeg you can output to a file or > use pipes and a video player.\n" > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > -loglevel warning -vf setpts=0 -\n" > ); > opengl->warned = 1; > } > diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c > index 779c8e08b0..491c8dafe8 100644 > --- a/libavdevice/sdl2.c > +++ b/libavdevice/sdl2.c > @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) > av_log(sdl, AV_LOG_WARNING, > "The sdl output device is deprecated due to being fundamentally > incompatible with libavformat API. " > "For monitoring purposes in ffmpeg you can output to a file or > use pipes and a video player.\n" > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > -loglevel warning -vf setpts=0 -\n" > ); > sdl->warned = 1; > } > -- Will try to push soon'ish if I don't hear any objections. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] configure: support msvc build inside WSL
On 2024-04-27 22:14 +0200, Timo Rothenpieler wrote:
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 8101b4fce6..89af5f75e7 100755
> --- a/configure
> +++ b/configure
> @@ -5036,7 +5036,12 @@ probe_cc(){
> else
> _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
> fi
> -_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk
> '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, /
> /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +if [ -x "$(command -v wslpath)" ]; then
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); if (!match($$0, / /)) { print
> $$0 } }'\'' | xargs -d\\n -n1 wslpath -u | awk '\''BEGIN { printf "%s:", "$@"
> }; { sub(/\r/,""); printf " %s", $$0 }; END { print "" }'\'' > $(@:.o=.d)'
> +
> +else
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0,
> / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +fi
> _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> _cflags_speed="-O2"
> _cflags_size="-O1"
> --
Should be good enough if it doesn't break MSVC builds outside of WSL.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-04-14 21:24 +0200, Nicolas George wrote: > Nicolas George (12024-04-14): > > Either we find options to make ffplay display frames as fast as > > possible, or we must document to the user that no adequate replacement > > exists. > > Please add “-vf setpts=0”. It still has a little more latency than a > built-in device, but at least the feature is not *completely* broken. Thank for your feedback. I sent a v2 with `-vf setpts=0`. > > Or we make a point of fixing the devices that were broken. > > We still should. As long as we are not able to get it fixed, an improved suggestion in the deprecation message seems better than what we have now. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavdevice: Improve example in deprecation message for opengl and sdl
When piping ffmpeg into ffplay both programs write a status line in the terminal. That causes flickering and invisibility of one or the other status line. As compromise set ffplay log level to warning, so it doesn't show the status line. The user is usually testing ffmpeg command lines and want's a preview of the result. This way the user can see the ffmpeg output and still see errors and warnings from ffplay, should they occur. Additionally set PTS to zero in ffplay to lessen the delay until the frames are displayed. Without it delay is quite observable when e.g. live capturing with low frame rates. --- Same as previous patch, but with setpts=0 in ffplay as suggested by Nicolas George. libavdevice/opengl_enc.c | 2 +- libavdevice/sdl2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index 6f7a30ff9e..93d3959880 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h) av_log(opengl, AV_LOG_WARNING, "The opengl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -vf setpts=0 -\n" ); opengl->warned = 1; } diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c index 779c8e08b0..491c8dafe8 100644 --- a/libavdevice/sdl2.c +++ b/libavdevice/sdl2.c @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) av_log(sdl, AV_LOG_WARNING, "The sdl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -vf setpts=0 -\n" ); sdl->warned = 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] fate: allow https for git URLs
On 2024-04-24 22:26 +0200, Timo Rothenpieler wrote:
> On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
> > On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> > > ---
> > > tests/fate.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/fate.sh b/tests/fate.sh
> > > index c5ee18de80..4081e865ae 100755
> > > --- a/tests/fate.sh
> > > +++ b/tests/fate.sh
> > > @@ -30,14 +30,14 @@ lock(){
> > > checkout(){
> > > case "$repo" in
> > > file:*|/*) src="${repo#file:}" ;;
> > > -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> > > +git:*|https:*) git clone --quiet --branch "$branch" "$repo"
> > > "$src" ;;
> > > esac
> > > }
> > >
> > > update()(
> > > cd ${src} || return
> > > case "$repo" in
> > > -git:*) git fetch --quiet --force && git reset --quiet --hard
> > > "origin/$branch" ;;
> > > +git:*|https:*) git fetch --quiet --force && git reset --quiet
> > > --hard "origin/$branch" ;;
> > > esac
> > > )
> >
>
> If you manually clone the repo, you can use whatever you like anyway, since
Sorry my initial wording was probably ambiguous.
I meant in the repo variable in a fate_config.sh
> it never actually uses the URL for anything after the initial clone.
The URL isn't used per se, but it's used to decide whether to
git fetch or not inside the call to update, isn't it?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fate: allow https for git URLs
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> ---
> tests/fate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/fate.sh b/tests/fate.sh
> index c5ee18de80..4081e865ae 100755
> --- a/tests/fate.sh
> +++ b/tests/fate.sh
> @@ -30,14 +30,14 @@ lock(){
> checkout(){
> case "$repo" in
> file:*|/*) src="${repo#file:}" ;;
> -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> +git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> esac
> }
>
> update()(
> cd ${src} || return
> case "$repo" in
> -git:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> +git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> esac
> )
Should be OK if tested to work with both git and https URLs in repo.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavdevice: Improve example in deprecation message for opengl and sdl
When piping ffmpeg into ffplay both programs write a status line in the terminal. That causes flickering and invisibility of one or the other status line. As compromise set ffplay log level to warning, so it doesn't show the status line. The user is usually testing ffmpeg command lines and want's a preview of the result. This way the user can see the ffmpeg output and still see errors and warnings from ffplay, should they occur. --- libavdevice/opengl_enc.c | 2 +- libavdevice/sdl2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index 6f7a30ff9e..c50d02870a 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h) av_log(opengl, AV_LOG_WARNING, "The opengl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); opengl->warned = 1; } diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c index 779c8e08b0..59e3182df8 100644 --- a/libavdevice/sdl2.c +++ b/libavdevice/sdl2.c @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) av_log(sdl, AV_LOG_WARNING, "The sdl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); sdl->warned = 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 2/2] avcodec: remove sonic lossy/lossless audio
On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote: > > On Wed, 28 Feb 2024, at 18:55, James Almer wrote: > > On 2/28/2024 10:31 AM, J. Dekker wrote: > >> > >> Michael Niedermayer writes: > >> > >>> [[PGP Signed Part:Undecided]] > >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, > >>> > >>> > development has stalled > >>> > >>> Thats not true, there was private dicussion making sonic the most > >>> advanced audio codec in FFmpeg a few months ago. > >>> Iam not saying that will happen, i am just saying there was a > >>> discussion about it. And that iam in principle interrested in > >>> working on this. Its possible i will not have enough time ... > >>> > >> > >> The last commit which actually changed the codec was > >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > >> years ago. For an experimental codec I think it's pretty safe to say > >> that development has stalled. > >> > >> Keeping the codec around based on 'what if?'s doesn't seem > >> reasonable. Besides, if you do make sonic the most advanced audio codec > >> in FFmpeg there's nothing which says you couldn't re-add it at a later > >> date when it's being actively developed again. > > > > Does it hurt keeping it around? If it can at some point be developed > > again, then removing the codec id to re-add it later will be a bit dirty. > > > > IMO, just disable both modules by default during configure, or tag the > > encoder as experimental to prevent new streams to be created unless > > explicitly requested knowing that it's an unfinished format. > > +1 +1 But if it stays it should be regularly compiled (at least on a fate client). Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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/bsf: add a showinfo filter
On 2024-01-29 19:42 +0100, Anton Khirnov wrote:
[...]
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -887,6 +887,10 @@ For example, to set PTS equal to DTS (not recommended if
> B-frames are involved):
> ffmpeg -i INPUT -c:a copy -bsf:a setts=pts=DTS out.mkv
> @end example
>
> +@section showinfo
> +Log basic packet information. Mainly useful for testing, debugging,
> +and development.
> +
Maybe it's a good idea to state something about the stability of
the output format. I assume it's to be treated like other logging
and is not expected to stay stable. Not sure how much it helps to
state it clearly, but it can't hurt IMHO.
[...]
> --- /dev/null
> +++ b/libavcodec/bsf/showinfo.c
[...]
> +static int showinfo_filter(AVBSFContext *ctx, AVPacket *pkt)
> +{
> +ShowinfoContext *priv = ctx->priv_data;
> +
> +while (1) {
> +int ret;
> +
> +ret = ff_bsf_get_packet_ref(ctx, pkt);
> +if (ret < 0)
> +return ret;
> +
> +av_log(ctx, AV_LOG_INFO,
> + "n:%7"PRIu64" "
> + "size:%7d "
> + "pts:%s pt:%s "
> + "dts:%s dt:%s "
> + "ds:%"PRId64" d:%s "
> + "\n",
> + priv->nb_packets, pkt->size,
> + av_ts2str(pkt->pts), av_ts2timestr(pkt->pts,
> >time_base_in),
> + av_ts2str(pkt->dts), av_ts2timestr(pkt->dts,
> >time_base_in),
> + pkt->duration, av_ts2timestr(pkt->duration,
> >time_base_in));
> +
> +priv->nb_packets++;
> +
> +return 0;
> +}
> +}
It's late here and I surely must be missing something. Anyway,
why do we use a while loop here?
Best regards,
Alexander
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg and libavdevice/sdl issue
On 2023-12-14 01:47 +0100, Stefano Sabatini wrote: > On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote: > > Quoting Zhao Zhili (2023-12-12 18:27:39) > [...] > > Honestly I don't see how this could be done in ffmpeg CLI without > > disgusting hacks, but before that the question is: > > > why is there an SDL > > "muxer" and why would anyone want to use it in ffmpeg CLI? What actual > > use cases does it serve that cannot be better handled otherwise? > > As the author of the first sdl.c muxer, maybe I can answer to this > question. It was done partly as an exercise and for fun, but also > because this was useful extremely handy for testing (e.g. to display > the output of a filterchain from ffmpeg, or to display a streamed > video in realtime). That is what I used it for countless times as well. It has a lot of merit in handling compared to piping to a player, where one needs to run 2 processes in one command line with all the drawbacks that come with it. > The final goal was (still is) to unify all the tools as very thin > instances of the library. Even if this might be not practical, I think > it is a good final design plan (e.g. ffprobe might be turned to a > custom muxer, ffplay would be the realtime output of a filtergraph > connected to a rendering device, ffmpeg would be a data filtergraph > processor, and you can mix rendering and encoding if you add a movie > sink to the game). I agree to this perspective. Making most of the functionality available through the FFmpeg libs and therefore available for wider application of a broader audience seems valuable. Such a big goal that cannot be reached in a predictable time frame should be challenged over the years and the plans, in so far they exist, need to be adjusted accordingly. Still that doesn't mean the goal is not worthwhile or not achievable. On an ending note: I don't like at all the way this discussion unraveled: 1. Someone wants to fix a reported problem after the new threading changes 2. It is questioned why a feature that exists for over a decade is there I hope this can get back on a more constructive rail. Otherwise I fear it just sets precedence for more to come :( Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
