Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_ffplay_ffprobe_cmdutils: add -safe to replace the user name and password in the protocol address
Am Sa., 17. Dez. 2022 um 08:36 Uhr schrieb Wujian(Chin) : > > The Protocol address may contain the user name and password. The ps -ef > command may expose the plaintext. Please add a sentence explaining why this is an issue. > The -safe parameter option is added to replace the user name and password in > the command line with the asterisk (*). > > Signed-off-by: wujian_nanjing > --- > doc/ffmpeg.texi| 7 +++ > doc/ffplay.texi| 8 > doc/ffprobe.texi | 7 +++ > fftools/cmdutils.c | 47 +++ > fftools/cmdutils.h | 15 +++ > fftools/ffmpeg.c | 16 +--- > fftools/ffplay.c | 15 +-- > fftools/ffprobe.c | 18 ++ > 8 files changed, 120 insertions(+), 13 deletions(-) > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi > index 0367930..e905542 100644 > --- a/doc/ffmpeg.texi > +++ b/doc/ffmpeg.texi > @@ -50,6 +50,13 @@ output files. Also do not mix options which belong to > different files. All > options apply ONLY to the next input or output file and are reset between > files. > > @itemize > +@item -safe > +The Protocol address may contain the user name and password. The ps -ef > command may expose the plaintext. > +The -safe parameter option is added to replace the user name and password in > the command line with the asterisk (*). > +@example > +ffmpeg -safe -i rtsp://usern...@password..com I believe this should be example.com 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] FFmpeg Media concatenation issue on other system
Am Mi., 14. Dez. 2022 um 13:09 Uhr schrieb Sagar Upadhyay : > I am using FFmpeg Please post all user questions on the user mailing list: https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/ Please remember not to post screen-shots there but copy command line and console output as text into your message. 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]configure: Assume target-os=win32 for toolchain msvc
Am Mi., 14. Dez. 2022 um 00:43 Uhr schrieb Timo Rothenpieler : > > On 13.12.2022 20:00, Carl Eugen Hoyos wrote: > > Ping. > > Could you give an example where host-os is not win32 when > > compiling with msvc? > > WSL, which I quite regularly use to test MSVC builds. > Just need to launch it from inside an msvc shell. This is the bug that my patch is trying to fix: When you build with msvc in wsl, you are doing a native build on win32. I want to avoid the "--host-os=win32" for this case. I had not imagined an msvc build using wine on Linux. 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]configure: Assume target-os=win32 for toolchain msvc
Am Di., 13. Dez. 2022 um 20:21 Uhr schrieb Hendrik Leppkes : > > On Tue, Dec 13, 2022 at 8:02 PM Carl Eugen Hoyos wrote: > > > > Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos > > : > > > > > > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes > > > : > > > > > > > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos > > > > wrote: > > > > > > > > > > Hi! > > > > > > > > > > Attached patch slightly simplifies building with MSVC. > > > > > > > > > > Please comment, Carl Eugen > > > > > > > > I don't think any toolchain value should make assumptions about the > > > > host it is running on, because between WSL and Wine, you can certainly > > > > do a bunch of specific things where this is not true. > > > > > > If this is true, then my patch is of course incorrect. > > > But could you give an example? > > > I was under the impression that cl.exe can only run > > > in win32. > > > > Ping. > > Could you give an example where host-os is not win32 when > > compiling with msvc? > > > > When using wine, your host is linux. Understood, thank you! 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] avcodec/x86/Makefile: Don't build empty files
Am Di., 13. Dez. 2022 um 20:03 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Am Di., 13. Dez. 2022 um 16:02 Uhr schrieb Andreas Rheinhardt
> > :
> >>
> >> Andreas Rheinhardt:
> >>> Should fix ticket #9909, fixing a regression since
> >>> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
> >>>
> >>> Thanks to Carl Eugen Hoyos for analyzing the issue.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt
> >>> ---
> >>> This would be my solution. What do you think of it?
> >>>
> >>> libavcodec/x86/Makefile | 7 +--
> >>> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> >>> index 4e448623af..41ca864849 100644
> >>> --- a/libavcodec/x86/Makefile
> >>> +++ b/libavcodec/x86/Makefile
> >>> @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP) +=
> >>> x86/qpeldsp.o \
> >>> X86ASM-OBJS-$(CONFIG_RV34DSP) += x86/rv34dsp.o
> >>> X86ASM-OBJS-$(CONFIG_VC1DSP) += x86/vc1dsp_loopfilter.o \
> >>>x86/vc1dsp_mc.o
> >>> -X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct10.o \
> >>> - x86/simple_idct.o
> >>> +ifdef ARCH_X86_64
> >>> +X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct10.o
> >>> +else
> >>> +X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
> >>> +endif
> >>> X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
> >>> X86ASM-OBJS-$(CONFIG_VP3DSP) += x86/vp3dsp.o
> >>> X86ASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o \
> >>
> >> It seems like that there are linkers out there that complain about empty
> >> object files like x86/simple_idct.o ("ranlib: file:
> >> libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
> >> BBB); the above patch is still needed to fix this. I will therefore
> >> apply it tonight (with an updated commit message) unless there are
> >> objections.
> >
> > (Three hours is not a lot)
> >
> > Which toolchain broke?
>
> "Broke" is the wrong word; Xcode emits warnings for empty object files.
It does.
(I did not consider this an issue when I saw it.)
I consider this unmaintainable, an argument that in the past was
used to object significantly more important patches (in cases
where maintenance was imo no problem).
Anyway: No objection.
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] [REFUND-REQUEST]Travel cost reimbursement request
Hi! I traveled to Barcelona for the development meeting and request a reimbursement: Flight Vienna - Barcelona - Vienna: 449,99 Two nights in a hotel in Barcelona: 161,06 Bus to Barcelona center: 5,90 Thank you, 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]configure: Assume target-os=win32 for toolchain msvc
Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos : > > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes > : > > > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos wrote: > > > > > > Hi! > > > > > > Attached patch slightly simplifies building with MSVC. > > > > > > Please comment, Carl Eugen > > > > I don't think any toolchain value should make assumptions about the > > host it is running on, because between WSL and Wine, you can certainly > > do a bunch of specific things where this is not true. > > If this is true, then my patch is of course incorrect. > But could you give an example? > I was under the impression that cl.exe can only run > in win32. Ping. Could you give an example where host-os is not win32 when compiling with msvc? Thank you, 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] avcodec/x86/Makefile: Don't build empty files
Am Di., 13. Dez. 2022 um 16:02 Uhr schrieb Andreas Rheinhardt
:
>
> Andreas Rheinhardt:
> > Should fix ticket #9909, fixing a regression since
> > bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
> >
> > Thanks to Carl Eugen Hoyos for analyzing the issue.
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > This would be my solution. What do you think of it?
> >
> > libavcodec/x86/Makefile | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> > index 4e448623af..41ca864849 100644
> > --- a/libavcodec/x86/Makefile
> > +++ b/libavcodec/x86/Makefile
> > @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP) +=
> > x86/qpeldsp.o \
> > X86ASM-OBJS-$(CONFIG_RV34DSP) += x86/rv34dsp.o
> > X86ASM-OBJS-$(CONFIG_VC1DSP) += x86/vc1dsp_loopfilter.o \
> >x86/vc1dsp_mc.o
> > -X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct10.o \
> > - x86/simple_idct.o
> > +ifdef ARCH_X86_64
> > +X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct10.o
> > +else
> > +X86ASM-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
> > +endif
> > X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
> > X86ASM-OBJS-$(CONFIG_VP3DSP) += x86/vp3dsp.o
> > X86ASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o \
>
> It seems like that there are linkers out there that complain about empty
> object files like x86/simple_idct.o ("ranlib: file:
> libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
> BBB); the above patch is still needed to fix this. I will therefore
> apply it tonight (with an updated commit message) unless there are
> objections.
(Three hours is not a lot)
Which toolchain broke?
Thank you, 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] configure: Change _cflags_noopt for MSVC to -Od
Am Mo., 12. Dez. 2022 um 22:02 Uhr schrieb Thomson Tan : > > I built the latest FFmpeg with WSL2+MSVC on Windows. Tried configure > with --disable-optimizations, but still got an optimized build which makes > it hard to set breakpoint on hot functions (likely inlined). Of course, this explains why you wrote the patch. But I still wonder how you tested it. Please find out what top-posting means and avoid it here, 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] configure: Change _cflags_noopt for MSVC to -Od
Am Mo., 12. Dez. 2022 um 19:30 Uhr schrieb :
>
> Currently -O1 is set to _cflags_noopt, but -O1 is actually for size
> optimization instead of no-opt which causes size optimized binaries
> been built with --disable-optimizations.
>
> Signed-off-by: Thomson Tan
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index f4eedfc207..388d518345 100755
> --- a/configure
> +++ b/configure
> @@ -4825,7 +4825,7 @@ probe_cc(){
> _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> _cflags_speed="-O2"
> _cflags_size="-O1"
> -_cflags_noopt="-O1"
> +_cflags_noopt="-Od"
I am curious:
How did you test this patch?
Thank you, 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] AVX512 NUCs for FATE and development
Am Fr., 9. Dez. 2022 um 18:07 Uhr schrieb Michael Niedermayer : > > On Thu, Dec 08, 2022 at 09:40:12PM +, Kieran Kunhya wrote: > > I intend to buy this RAM: > > https://www.amazon.co.uk/Crucial-CT2K16G4SFRA32A-PC4-25600-SODIMM-260-Pin/dp/B08C4X9VR5 > > > > 2x £529 for NUCs > > 2x £102.48 for RAM > > 2x £69 for M.2 NVMe SSD > > > > £1400 total. > > iam in favor of this too +1 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 v3 0/5] Fix FFmpeg compilation without DCE
Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Soft Works : > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Carl Eugen Hoyos > > Sent: Sunday, November 27, 2022 5:47 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v3 0/5] Fix FFmpeg compilation > > without DCE Please consider fixing your mail client. > > Am So., 27. Nov. 2022 um 17:29 Uhr schrieb Soft Works > > : > > > > > How do you set this up when you are compiling with MSVC? > > > > My configure line to compile with MSVC is: > > $ src/configure --enable-gpl --toolchain=msvc --host-os=win32 > > > > But maybe I misunderstand your question? > > What I meant is the environment. Are you running this from > an MSYS shell? Or WSL? WSL >From what I remember, running configure in MSYS literally took ages, I don't know if this has improved. > And does running configure output VS project files I don't think so. > so that you can compile inside VS (I think this > existed at some earlier time at least, but I was > under the impression that it's broken)..? Which commit changed behaviour in this respect? Thank you, 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]configure: Assume target-os=win32 for toolchain msvc
Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes : > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos wrote: > > > > Hi! > > > > Attached patch slightly simplifies building with MSVC. > > > > Please comment, Carl Eugen > > I don't think any toolchain value should make assumptions about the > host it is running on, because between WSL and Wine, you can certainly > do a bunch of specific things where this is not true. If this is true, then my patch is of course incorrect. But could you give an example? I was under the impression that cl.exe can only run in win32. Thank you, 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]configure: Assume target-os=win32 for toolchain msvc
Hi! Attached patch slightly simplifies building with MSVC. Please comment, Carl Eugen 0001-configure-Assume-host-os-win32-for-toolchain-msvc.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/5] Fix FFmpeg compilation without DCE
Am So., 27. Nov. 2022 um 17:29 Uhr schrieb Soft Works : > How do you set this up when you are compiling with MSVC? My configure line to compile with MSVC is: $ src/configure --enable-gpl --toolchain=msvc --host-os=win32 But maybe I misunderstand your question? 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 v3 0/5] Fix FFmpeg compilation without DCE
Am Sa., 26. Nov. 2022 um 20:17 Uhr schrieb L. E. Segovia : > > Hi again, > > Pinging again for review. I've asked for clarification about how should > the EXTERNAL_ checks be dealt with, but I've not received any > response here. As said before: I regularly compile with MSVC without this patch set and I believe the patch set makes our code less readable and harder to maintain. 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] avcodec/mjpegenc: take into account component count when writing the SOF header size
Am Fr., 25. Nov. 2022 um 00:00 Uhr schrieb James Almer : > > Fixes ticket #10069 > > Signed-off-by: James Almer > --- > libavcodec/mjpegenc_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c > index 6dfc4469a5..049ae3d929 100644 > --- a/libavcodec/mjpegenc_common.c > +++ b/libavcodec/mjpegenc_common.c > @@ -308,7 +308,7 @@ void ff_mjpeg_encode_picture_header(AVCodecContext > *avctx, PutBitContext *pb, > default: av_assert0(0); > } > > -put_bits(pb, 16, 17); > +put_bits(pb, 16, 8 + 3 * components); Could this also fix #2967? 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]lavc/mscc: Change BGRA to BGR0, there is no transparency in screen recordings
Am Fr., 25. Nov. 2022 um 00:08 Uhr schrieb Paul B Mahol : > > On 11/24/22, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch fixes an issue mentioned in ticket #10068. > > > > Please comment, Carl Eugen > > > > NAK > Not correct. How do you suggest to fix the issue? Note that the same bug was fixed in several other screen recording codecs in the past. 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]lavc/codec_desc: Mark V210 as lossy
Hi! Our V210 encoder limits the written values, so do not mark the codec as lossless. Please comment, Carl Eugen 0001-lavc-codec_desc-Mark-V210-as-lossy.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavc/mscc: Change BGRA to BGR0, there is no transparency in screen recordings
Hi! Attached patch fixes an issue mentioned in ticket #10068. Please comment, Carl Eugen 0001-lavc-mscc-Change-BGRA-to-BGR0-there-is-no-transparen.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [Question] Technical reason why FFmpeg sets a mstack-alignment value on compile time?
Am Sa., 12. Nov. 2022 um 19:57 Uhr schrieb Nomis101 : > And here comes my questions. I was wondering, about the technical > reason why FFmpeg does set mstack-alignment? It is needed for x86_32. Completely removing the option from all build scripts seems wrong to me. 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] avformat/movenc: Remove experimental status of TrueHD-in-MP4 muxing (mlpa)
Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 : > > Support for mlpa muxing was added back in 2019: > http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619 > But it was hidden back then behind FF_COMPLIANCE_EXPERIMENTAL, because it was > new and there was no > support from other applications. > > In the meantime there is support in MediaInfo: MediaArea/MediaInfoLib#1258 > For VLC: videolan/vlc@9c49f40 > Since version 7.3.4 for Infuse: > https://community.firecore.com/t/dolby-mlp-mlpa-codec-support/26100/31 > And mpv does support this as well. If there was ever a good reason to make this feature experimental, I don't think these applications change the situation. 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]lavc/tiff: Support dng cropping
Am Mo., 31. Okt. 2022 um 13:39 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2022-10-23 20:46:57)
> > Am So., 23. Okt. 2022 um 16:35 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Hi!
> > >
> > > I tried to implement dng cropping, it unfortunately can only work with
> > > -flags +unaligned, is there an alternative to simply print a warning
> > > if the flag was not supplied?
> >
> > New patch with more parentheses attached.
> >
> > Please comment, Carl Eugen
> >
> > From 1bfe065564604659b7703e75b1bb750c031fdc81 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Sun, 23 Oct 2022 16:31:53 +0200
> > Subject: [PATCH] lavc/tiff: Support dng cropping,
>
> A FATE test would be nice.
>
> > needs -flags +unaligned
>
> AFAICT this is not entirely correct. Applying left cropping in
> libavcodec might need AV_CODEC_FLAG_UNALIGNED, but not always. Users may
> also set apply_cropping=0 and apply cropping themselves.
>
> The decoder should not care about it in any case, since it's handled in
> the generic code.
>
> >
> > Fixes samples mentioned in ticket #4364.
> > ---
> > libavcodec/tiff.c | 83 +++
> > libavcodec/tiff.h | 3 ++
> > 2 files changed, 86 insertions(+)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index fd9db18c0b..33edff8213 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -1492,6 +1492,89 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> > *frame)
> > case DNG_WHITE_LEVEL:
> > s->white_level = value;
> > break;
> > +case DNG_CROP_ORIGIN:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
>
> This condition could definitely use more parentheses. Same in two checks
> below.
>
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum1 = ff_tget(>gb, TIFF_LONG, s->le);
> > +value2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +if (denum1 != 1 || denum2 != 1) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> > origin\n");
> > +break;
> > +}
> > +} else {
> > +value = ff_tget(>gb, type, s->le);
> > +value2 = ff_tget(>gb, type, s->le);
> > +}
>
> This entire block is duplicated for DNG_CROP_ORIGIN and DNG_CROP_SIZE,
> you could split it into a function.
>
> > +av_log(s->avctx, AV_LOG_DEBUG, "dng crop origin: %d/%d\n", value,
> > value2);
> > +if (value >= s->width || value2 >= s->height) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin
> > (%d/%d)\n", value, value2);
> > +break;
> > +}
> > +if ((value || value2) && !(s->avctx->flags &
> > AV_CODEC_FLAG_UNALIGNED)) {
> > +av_log(s->avctx, AV_LOG_WARNING,"Correct DNG cropping needs
> > -flags +unaligned\n");
> > +} else {
> > +frame->crop_left = value;
> > +frame->crop_top = value2;
> > +}
> > +break;
> > +case DNG_CROP_SIZE:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop size (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum1 = ff_tget(>gb, TIFF_LONG, s->le);
> > +value2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +if (denum1 != 1 || denum2 != 1) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> > size\n");
> > +break;
> > +}
> > +
[FFmpeg-devel] [PATCH 2/2]lavc/audiotoolboxdec: Support 20/24/32bit Apple Lossless decoding
Hi! Attached patch allows default decoding to s32 for 20-, 24- and 32-bit alac. Please comment, Carl Eugen 0002-lavc-audiotoolboxdec-Support-20-24-32bit-Apple-Lossl.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2]lavc/audiotoolboxdec: Reorder decoder initialization
Hi! Attached patch should not change decoder behaviour, it is only meant to simplify the second patch. Please comment, Carl Eugen 0001-lavc-audiotoolboxdec-Reorder-decoder-initialization.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavf/ass: Allow empty Layer field
Hi! Attached patch fixes ticket #9581 for me. Please comment, Carl Eugen 0001-lavf-ass-Allow-empty-Layer-field.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] all: Replace if (ARCH_FOO) checks by #if ARCH_FOO, part 2
Am Di., 1. Nov. 2022 um 23:00 Uhr schrieb L. E. Segovia : > > Continuation of 40e6575aa3eed64cd32bf28c00ae57edc5acb25a > > Co-authored-by: Nirbheek Chauhan > > Signed-off-by: L. E. Segovia > --- > libavcodec/x86/dcadsp_init.c | 2 + > libavcodec/x86/fdctdsp_init.c| 2 + > libavcodec/x86/flacdsp_init.c| 8 +- > libavcodec/x86/hevcdsp_init.c| 463 ++- > libavcodec/x86/idctdsp_init.c| 9 +- > libavcodec/x86/mlpdsp_init.c | 6 +- > libavcodec/x86/vc1dsp_init.c | 6 +- > libavfilter/x86/colorspacedsp_init.c | 4 +- > libavfilter/x86/vf_atadenoise_init.c | 6 +- > libavfilter/x86/vf_ssim_init.c | 6 +- > libavfilter/x86/vf_w3fdif_init.c | 4 +- > 11 files changed, 272 insertions(+), 244 deletions(-) I regularly compile with MSVC without this patch and I believe the patch makes our code less readable and harder to maintain. 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]lavc/tiff: Support dng cropping
Am Mo., 31. Okt. 2022 um 13:39 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2022-10-23 20:46:57)
> > Am So., 23. Okt. 2022 um 16:35 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Hi!
> > >
> > > I tried to implement dng cropping, it unfortunately can only work with
> > > -flags +unaligned, is there an alternative to simply print a warning
> > > if the flag was not supplied?
> >
> > New patch with more parentheses attached.
> >
> > Please comment, Carl Eugen
> >
> > From 1bfe065564604659b7703e75b1bb750c031fdc81 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Sun, 23 Oct 2022 16:31:53 +0200
> > Subject: [PATCH] lavc/tiff: Support dng cropping,
>
> A FATE test would be nice.
The samples are big but will look into this once the patch is ok.
> > needs -flags +unaligned
>
> AFAICT this is not entirely correct. Applying left cropping in
> libavcodec might need AV_CODEC_FLAG_UNALIGNED, but not always.
Of course, but evidence indicates that in nearly all cases, it is needed.
> Users may also set apply_cropping=0 and apply cropping themselves.
It should be possible to check this.
> The decoder should not care about it in any case, since it's handled in
> the generic code.
Could you elaborate?
The reason I added this check (and I would love to see that it is not
necessary) is that there is no (working) generic code afaict and that
decoding just breaks without a useful hint if the check is removed.
> > Fixes samples mentioned in ticket #4364.
> > ---
> > libavcodec/tiff.c | 83 +++
> > libavcodec/tiff.h | 3 ++
> > 2 files changed, 86 insertions(+)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index fd9db18c0b..33edff8213 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -1492,6 +1492,89 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> > *frame)
> > case DNG_WHITE_LEVEL:
> > s->white_level = value;
> > break;
> > +case DNG_CROP_ORIGIN:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
>
> This condition could definitely use more parentheses. Same in two checks
> below.
Sorry, I disagree.
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum1 = ff_tget(>gb, TIFF_LONG, s->le);
> > +value2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +denum2 = ff_tget(>gb, TIFF_LONG, s->le);
> > +if (denum1 != 1 || denum2 != 1) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> > origin\n");
> > +break;
> > +}
> > +} else {
> > +value = ff_tget(>gb, type, s->le);
> > +value2 = ff_tget(>gb, type, s->le);
> > +}
>
> This entire block is duplicated for DNG_CROP_ORIGIN and DNG_CROP_SIZE,
> you could split it into a function.
Will do, but I expect this to look ugly.
> > +av_log(s->avctx, AV_LOG_DEBUG, "dng crop origin: %d/%d\n", value,
> > value2);
> > +if (value >= s->width || value2 >= s->height) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin
> > (%d/%d)\n", value, value2);
> > +break;
> > +}
> > +if ((value || value2) && !(s->avctx->flags &
> > AV_CODEC_FLAG_UNALIGNED)) {
> > +av_log(s->avctx, AV_LOG_WARNING,"Correct DNG cropping needs
> > -flags +unaligned\n");
> > +} else {
> > +frame->crop_left = value;
> > +frame->crop_top = value2;
> > +}
> > +break;
> > +case DNG_CROP_SIZE:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop size (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(>gb, TIFF_LONG, s->le);
> &
Re: [FFmpeg-devel] [RFC]lavc/tiff: Support dng cropping
Am So., 23. Okt. 2022 um 16:35 Uhr schrieb Carl Eugen Hoyos : > > Hi! > > I tried to implement dng cropping, it unfortunately can only work with > -flags +unaligned, is there an alternative to simply print a warning > if the flag was not supplied? New patch with more parentheses attached. Please comment, Carl Eugen 0001-lavc-tiff-Support-dng-cropping-needs-flags-unaligned.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC]lavc/tiff: Support dng cropping
Hi! I tried to implement dng cropping, it unfortunately can only work with -flags +unaligned, is there an alternative to simply print a warning if the flag was not supplied? Thank you, Carl Eugen 0001-lavc-tiff-Support-dng-cropping-needs-flags-unaligned.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] Enable building with WSL and MSVC
Am Sa., 8. Okt. 2022 um 10:39 Uhr schrieb Julio C. Rocha :
>
> On Sun, Oct 2, 2022 at 4:48 PM Julio C. Rocha wrote:
>
> > ---
> > configure | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 6712d045d9..f5f5eb29dd 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4847,7 +4847,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 [ "$(grep -i Microsoft /proc/version)" ]; then
> > +# Windows Subsystem for Linux
> > +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1
> > | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) { cmd="/usr/bin/wslpath \x27" $$0 "\x27"; cmd |& getline
> > pth; print "$@:", pth } }'\'' > $(@:.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"
> > --
> > 2.37.0 (Apple Git-136)
> >
> >
> Hi! I'd like to re-request feedback for this patch.
>
> To clarify, it allows building FFmpeg using MSVC over WSL, without any
> dependency on MinGW or MSYS.
You write in your own explanations "Succeeds" - this and what the patch
is meant to fix are missing from your commit message.
Your patch would not work here - sadly, cl.exe does not print "including"
for all installations.
I build FFmpeg regularly with wsl and msvc and others do as well.
Dependency files are simply empty here (because cl.exe prints
"Einlesen der Datei" here).
Dependency generation works for me with --dep-cc=clang-cl.exe but
I normally just build without it.
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] avcodec/x86/Makefile: Don't build empty files
Am Mo., 12. Sept. 2022 um 17:04 Uhr schrieb Andreas Rheinhardt : > > Should fix ticket #9909, fixing a regression since > bfb28b5ce89f3e950214b67ea95b45e3355c2caf. > > Thanks to Carl Eugen Hoyos for analyzing the issue. > > Signed-off-by: Andreas Rheinhardt > --- > This would be my solution. What do you think of it? No objection but I do not consider this patch cleaner. Thank you, 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 17:29 Uhr schrieb Andreas Rheinhardt : > > Carl Eugen Hoyos: > > From 421041e7cd1bce8952756e60a0dd428f1618d75a Mon Sep 17 00:00:00 2001 > > From: Carl Eugen Hoyos > > Date: Sun, 11 Sep 2022 16:02:09 +0200 > > Subject: [PATCH] lavc/x86/simple_idct: Fix linking shared libavcodec with MS > > link.exe > > > > link.exe hangs on empty simple_idct.o > > > > Fixes ticket #9909. > > --- > > libavcodec/x86/simple_idct.asm | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm > > index dcf0da6df1..982b2f0bbb 100644 > > --- a/libavcodec/x86/simple_idct.asm > > +++ b/libavcodec/x86/simple_idct.asm > > @@ -25,9 +25,9 @@ > > > > %include "libavutil/x86/x86util.asm" > > > > -%if ARCH_X86_32 > > SECTION_RODATA > > > > +%if ARCH_X86_32 > > cextern pb_80 > > > > wm1010: dw 0, 0x, 0, 0x > > Thanks for bisecting this. (I don't have a MSVC setup myself to do it.) > Looking at the patch makes me feel that the very same issue might > happen with simple_idct10.asm when one tries to link a 32bit build. No, that works fine (32bit creates a symbol in the empty object files iiuc). I will not look into another solution, I am happy if you find one. Thank you, 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 16:26 Uhr schrieb James Almer : > > On 9/11/2022 11:17 AM, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch fixes ticket #9909 for me, regression since 4618f36a > > > > Please comment, Carl Eugen > > It would help if the patch was attached :p Good point! Carl Eugen 0001-lavc-x86-simple_idct-Fix-linking-shared-libavcodec-w.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Am So., 11. Sept. 2022 um 16:17 Uhr schrieb Carl Eugen Hoyos : > > Attached patch fixes ticket #9909 for me, regression since 4618f36a Sorry, it was bfb28b5ce89f3e950214b67ea95b45e3355c2caf 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]lavc/x86/simple_idct: Fix linking shared libavcodec with MS link.exe
Hi! Attached patch fixes ticket #9909 for me, regression since 4618f36a Please comment, 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]lavfi/rotate: Fix undefined behaviour
Am Fr., 2. Sept. 2022 um 09:04 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2022-09-01 21:28:08)
> > Hi!
> >
> > Attached patch fixes ticket #9799.
> >
> > Please comment, Carl Eugen
> >
> > From 2cce687961c3b56a92d88184269bf9fa075ae297 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Thu, 1 Sep 2022 20:55:54 +0200
> > Subject: [PATCH] lavfi/rotate: Avoid undefined behaviour.
> >
> > Fixes the following integer overflows:
> > libavfilter/vf_rotate.c:273:13: runtime error: signed integer overflow:
> > 92951468 + 2058533568 cannot be represented in type 'int'
> > libavfilter/vf_rotate.c:273:37: runtime error: signed integer overflow:
> > 39684 * 54149 cannot be represented in type 'int'
> > libavfilter/vf_rotate.c:272:13: runtime error: signed integer overflow:
> > 247587320 + 1900985032 cannot be represented in type 'int'
> > libavfilter/vf_rotate.c:272:37: runtime error: signed integer overflow:
> > 42584 * 50430 cannot be represented in type 'int'
> > libavfilter/vf_rotate.c:272:50: runtime error: signed integer overflow:
> > 65083 * 52912 cannot be represented in type 'int'
> > libavfilter/vf_rotate.c:273:50: runtime error: signed integer overflow:
> > 65286 * 38044 cannot be represented in type 'int'
> >
> > Fixes ticket #9799, different output with different compilers.
> > ---
> > libavfilter/vf_rotate.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c
> > index 4429e3d543..d319dfe3d9 100644
> > --- a/libavfilter/vf_rotate.c
> > +++ b/libavfilter/vf_rotate.c
> > @@ -269,8 +269,8 @@ static uint8_t *interpolate_bilinear16(uint8_t
> > *dst_color,
> > int s01 = AV_RL16([src_linestep * int_x1 + i + src_linesize *
> > int_y ]);
> > int s10 = AV_RL16([src_linestep * int_x + i + src_linesize *
> > int_y1]);
> > int s11 = AV_RL16([src_linestep * int_x1 + i + src_linesize *
> > int_y1]);
> > -int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
> > -int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
> > +int64_t s0 = (((int64_t)(1<<16) - frac_x)*s00 +
> > (int64_t)frac_x*s01);
> > +int64_t s1 = (((int64_t)(1<<16) - frac_x)*s10 +
> > (int64_t)frac_x*s11);
>
> Given that the same casts also appear in the AV_WL16 below, it seems
> better to just change the types of frac_x/frac_y.
Definitely, new patch attached.
> Also, shouldn't the same change be done also to interpolate_bilinear8?
I was unable to reproduce with 8-bit input.
Thank you, Carl Eugen
From 062b8a3a202f72125fa05582c2a3c0abc8305887 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 3 Sep 2022 22:50:19 +0200
Subject: [PATCH] lavfi/rotate: Avoid undefined behaviour.
Fixes the following integer overflows:
libavfilter/vf_rotate.c:273:13: runtime error: signed integer overflow:
92951468 + 2058533568 cannot be represented in type 'int'
libavfilter/vf_rotate.c:273:37: runtime error: signed integer overflow: 39684 *
54149 cannot be represented in type 'int'
libavfilter/vf_rotate.c:272:13: runtime error: signed integer overflow:
247587320 + 1900985032 cannot be represented in type 'int'
libavfilter/vf_rotate.c:272:37: runtime error: signed integer overflow: 42584 *
50430 cannot be represented in type 'int'
libavfilter/vf_rotate.c:272:50: runtime error: signed integer overflow: 65083 *
52912 cannot be represented in type 'int'
libavfilter/vf_rotate.c:273:50: runtime error: signed integer overflow: 65286 *
38044 cannot be represented in type 'int'
Fixes ticket #9799, different output with different compilers.
---
libavfilter/vf_rotate.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c
index 4429e3d543..96c250a459 100644
--- a/libavfilter/vf_rotate.c
+++ b/libavfilter/vf_rotate.c
@@ -258,8 +258,8 @@ static uint8_t *interpolate_bilinear16(uint8_t *dst_color,
{
int int_x = av_clip(x>>16, 0, max_x);
int int_y = av_clip(y>>16, 0, max_y);
-int frac_x = x&0x;
-int frac_y = y&0x;
+int64_t frac_x = x&0x;
+int64_t frac_y = y&0x;
int i;
int int_x1 = FFMIN(int_x+1, max_x);
int int_y1 = FFMIN(int_y+1, max_y);
@@ -269,10 +269,10 @@ static uint8_t *interpolate_bilinear16(uint8_t *dst_color,
int s01 = AV_RL16([src_linestep * int_x1 + i + src_linesize *
int_y ]);
int s10 = AV_RL16([src_linestep * int_x + i + src_linesize *
int_y1]);
int s11 = AV_RL16([src_linestep * int_x1 + i + src_linesize *
int_y1]);
-int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
Re: [FFmpeg-devel] [PATCH]lavf/hevc: Fix type specifiers
Am Fr., 2. Sept. 2022 um 23:56 Uhr schrieb Andreas Rheinhardt : > > Carl Eugen Hoyos: > > Fixes several warnings: > > warning: format specifies type 'unsigned char' but the argument has type > > 'unsigned int' > > --- > > libavformat/hevc.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/libavformat/hevc.c b/libavformat/hevc.c > > index 1841dd5785..ca5187a92e 100644 > > --- a/libavformat/hevc.c > > +++ b/libavformat/hevc.c > > @@ -848,15 +848,15 @@ static int hvcc_write(AVIOContext *pb, > > HEVCDecoderConfigurationRecord *hvcc) > > if (array->numNalus == 0) > > continue; > > > > -av_log(NULL, AV_LOG_TRACE, "array_completeness[%"PRIu8"]: > > %"PRIu8"\n", > > +av_log(NULL, AV_LOG_TRACE, "array_completeness[%u]: > > %"PRIu8"\n", > > j, array->array_completeness); > > -av_log(NULL, AV_LOG_TRACE, "NAL_unit_type[%"PRIu8"]: > > %"PRIu8"\n", > > +av_log(NULL, AV_LOG_TRACE, "NAL_unit_type[%u]: > > %"PRIu8"\n", > > j, array->NAL_unit_type); > > -av_log(NULL, AV_LOG_TRACE, "numNalus[%"PRIu8"]: > > %"PRIu16"\n", > > +av_log(NULL, AV_LOG_TRACE, "numNalus[%u]: > > %"PRIu16"\n", > > j, array->numNalus); > > for (unsigned k = 0; k < array->numNalus; k++) > > av_log(NULL, AV_LOG_TRACE, > > -"nalUnitLength[%"PRIu8"][%"PRIu16"]: > > %"PRIu16"\n", > > +"nalUnitLength[%u][%u]: %"PRIu16"\n", > > j, k, array->nalUnitLength[k]); > > j++; > > } > > -- > > I didn't catch this, as I didn't get a warning at all. The reason for > this is that it is actually not problematic: > "The ellipsis notation in a function prototype declarator causes > argument type conversion to stop after the last declared parameter. The > default argument > promotions are performed on trailing arguments." The default argument > promotions include promoting integral types of conversion rank < int to > int. So av_log() has to read an int/unsigned even when one uses a > %"PRIu8". And so my inttypes.h contains this: > > # define PRIu8 "u" On Windows where clang shows a warning it is #define PRIu8"hhu" See "Size Prefixes" in https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions > # define PRIu16 "u" > # define PRIu32 "u" > > No wonder neither GCC nor Clang warned about this. > Anyway, patch LGTM. Please push, I currently have no access to my development system. Thank you, 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]lavc/cfhddata: Reduce required stack size
Hi!
Attached patch reduces the stack size of an init function, fixes part
of ticket #9399.
Please comment, Carl Eugen
From 0f034ebed2388e89e241d7e08bf59d335b5c4cee Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 2 Sep 2022 23:36:29 +0200
Subject: [PATCH] lavc/cfhddata: Reduce required stack size.
Fixes part of ticket #9399.
---
libavcodec/cfhddata.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavcodec/cfhddata.c b/libavcodec/cfhddata.c
index 55c8004bdd..17aa888c84 100644
--- a/libavcodec/cfhddata.c
+++ b/libavcodec/cfhddata.c
@@ -276,10 +276,20 @@ static const uint8_t table_18_vlc_level[NB_VLC_TABLE_18]
= {
av_cold int ff_cfhd_init_vlcs(CFHDContext *s)
{
int i, j, ret = 0;
-uint32_t new_cfhd_vlc_bits[NB_VLC_TABLE_18 * 2];
-uint8_t new_cfhd_vlc_len[NB_VLC_TABLE_18 * 2];
-uint16_t new_cfhd_vlc_run[NB_VLC_TABLE_18 * 2];
-int16_t new_cfhd_vlc_level[NB_VLC_TABLE_18 * 2];
+uint32_t *new_cfhd_vlc_bits;
+uint8_t *new_cfhd_vlc_len;
+uint16_t *new_cfhd_vlc_run;
+int16_t *new_cfhd_vlc_level;
+
+new_cfhd_vlc_bits = av_malloc(NB_VLC_TABLE_18 * 2 * 4);
+new_cfhd_vlc_len = av_malloc(NB_VLC_TABLE_18 * 2);
+new_cfhd_vlc_run = av_malloc(NB_VLC_TABLE_18 * 2 * 2);
+new_cfhd_vlc_level = av_malloc(NB_VLC_TABLE_18 * 2 * 2);
+
+if (!new_cfhd_vlc_bits || !new_cfhd_vlc_len || !new_cfhd_vlc_run ||
!new_cfhd_vlc_level) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
/** Similar to dv.c, generate signed VLC tables **/
@@ -306,7 +316,7 @@ av_cold int ff_cfhd_init_vlcs(CFHDContext *s)
ret = init_vlc(>vlc_9, VLC_BITS, j, new_cfhd_vlc_len,
1, 1, new_cfhd_vlc_bits, 4, 4, 0);
if (ret < 0)
-return ret;
+goto end;
for (i = 0; i < s->vlc_9.table_size; i++) {
int code = s->vlc_9.table[i].sym;
int len = s->vlc_9.table[i].len;
@@ -347,7 +357,7 @@ av_cold int ff_cfhd_init_vlcs(CFHDContext *s)
ret = init_vlc(>vlc_18, VLC_BITS, j, new_cfhd_vlc_len,
1, 1, new_cfhd_vlc_bits, 4, 4, 0);
if (ret < 0)
-return ret;
+goto end;
av_assert0(s->vlc_18.table_size == 4572);
for (i = 0; i < s->vlc_18.table_size; i++) {
@@ -367,5 +377,11 @@ av_cold int ff_cfhd_init_vlcs(CFHDContext *s)
s->table_18_rl_vlc[i].run = run;
}
+end:
+av_free(new_cfhd_vlc_bits);
+av_free(new_cfhd_vlc_len);
+av_free(new_cfhd_vlc_run);
+av_free(new_cfhd_vlc_level);
+
return ret;
}
--
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".
[FFmpeg-devel] [PATCH]lavf/hevc: Fix type specifiers
Hi! Attached patch fixes a few warnings. Please comment, Carl Eugen 0001-lavf-hevc-Fix-type-specifiers-missed-in-8b5d1553.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavfi/rotate: Fix undefined behaviour
Hi! Attached patch fixes ticket #9799. Please comment, Carl Eugen From 2cce687961c3b56a92d88184269bf9fa075ae297 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 1 Sep 2022 20:55:54 +0200 Subject: [PATCH] lavfi/rotate: Avoid undefined behaviour. Fixes the following integer overflows: libavfilter/vf_rotate.c:273:13: runtime error: signed integer overflow: 92951468 + 2058533568 cannot be represented in type 'int' libavfilter/vf_rotate.c:273:37: runtime error: signed integer overflow: 39684 * 54149 cannot be represented in type 'int' libavfilter/vf_rotate.c:272:13: runtime error: signed integer overflow: 247587320 + 1900985032 cannot be represented in type 'int' libavfilter/vf_rotate.c:272:37: runtime error: signed integer overflow: 42584 * 50430 cannot be represented in type 'int' libavfilter/vf_rotate.c:272:50: runtime error: signed integer overflow: 65083 * 52912 cannot be represented in type 'int' libavfilter/vf_rotate.c:273:50: runtime error: signed integer overflow: 65286 * 38044 cannot be represented in type 'int' Fixes ticket #9799, different output with different compilers. --- libavfilter/vf_rotate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c index 4429e3d543..d319dfe3d9 100644 --- a/libavfilter/vf_rotate.c +++ b/libavfilter/vf_rotate.c @@ -269,8 +269,8 @@ static uint8_t *interpolate_bilinear16(uint8_t *dst_color, int s01 = AV_RL16([src_linestep * int_x1 + i + src_linesize * int_y ]); int s10 = AV_RL16([src_linestep * int_x + i + src_linesize * int_y1]); int s11 = AV_RL16([src_linestep * int_x1 + i + src_linesize * int_y1]); -int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01); -int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11); +int64_t s0 = (((int64_t)(1<<16) - frac_x)*s00 + (int64_t)frac_x*s01); +int64_t s1 = (((int64_t)(1<<16) - frac_x)*s10 + (int64_t)frac_x*s11); AV_WL16(_color[i], ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32); } -- 2.30.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]lavc/tiff: Support multi-component files without RowsPerStrip tag
Am Do., 1. Sept. 2022 um 04:10 Uhr schrieb Steven Liu : > > Carl Eugen Hoyos 于2022年9月1日周四 01:48写道： > > > > Hi! > > > > Attached patch fixes ticket #9514 for me. > > > > Please review, Carl Eugen > > lgtm Patch applied. Thank you, 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]lavc/tiff: Support multi-component files without RowsPerStrip tag
Hi! Attached patch fixes ticket #9514 for me. Please review, Carl Eugen From 98df40635315363bfc248f5c5e94d89bdb261b5b Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Wed, 31 Aug 2022 19:37:19 +0200 Subject: [PATCH] lavc/tiff: Support multi-component files without RowsPerStrip tag. Fixes ticket #9514. --- libavcodec/tiff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index b0595b56c0..109392ad44 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1367,7 +1367,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame) } else s->strippos = off; s->strips = count; -if (s->strips == 1) +if (s->strips == s->bppcount) s->rps = s->height; s->sot = type; break; -- 2.30.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]lavc/j2kdec: Do not ignore colour association for packed formats
Hi everybody!
Attached patch fixes ticket #9468 for me.
Please review, Carl Eugen
From a28a5e26892adf56a0bb9b33de2fb76b2405cc97 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 28 Aug 2022 17:47:23 +0200
Subject: [PATCH] lavc/j2kdec: Do not ignore colour association for packed
formats.
Fixes ticket #9468.
---
libavcodec/jpeg2000dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 2c1191035c..c6187d6c43 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -2047,7 +2047,8 @@ static inline void tile_codeblocks(const Jpeg2000DecoderContext *s, Jpeg2000Tile
\
x = tile->comp[compno].coord[0][0] -\
ff_jpeg2000_ceildiv(s->image_offset_x, s->cdx[compno]); \
-dst = line + x * pixelsize + compno*!planar; \
+dst = line + x * pixelsize + \
+ (s->cdef[compno] ? s->cdef[compno] - 1 : compno) * !planar; \
\
if (codsty->transform == FF_DWT97) { \
for (; x < w; x++) { \
--
2.30.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 v1 1/9] lavu/pix_fmt: add P012 pixel format
Am Mi., 26. Jan. 2022 um 09:33 Uhr schrieb Xiang, Haihao : > > Did you already explain why you cannot use P016 or in which situation > > it would create a different output? > > $ ffmpeg -hwaccel vaapi -f rawvideo -pix_fmt p016 -s 1920x1080 -i input.yuv > -vf "hwupload,format=vaapi" -c:v hevc_vaapi -f null - > > If using P016, how will we know the input is 12bit indeed Thank you for explaining this, at least I didn't realize this reason earlier! I hope we can find another solution than to add an additional pix_fmt. I believe I had suggested an additional property bit_depth for raw video a long time ago. 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 v1 1/9] lavu/pix_fmt: add P012 pixel format
Am Fr., 21. Jan. 2022 um 06:56 Uhr schrieb Xiang, Haihao : > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Xiang, > > Haihao > > Sent: Tuesday, June 30, 2020 15:34 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel > > format > > > > > Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson : > > > > > > > FFmpeg has always used pixfmt as defining both the memory layout > > > > and which bits are used in that (so, for example, ARGB and 0RGB > > > > are not the same thing) > > > > > > But they have the same bitdepth per component... > > > Agree with Mark. P012 and P016 have different significant bits, we should > > use > > different pixfmts, otherwise an extra field in AVFrame is needed for bit > > depth. > > > > BTW there are the YUV420P variants for 10 / 12 / 14 / 16 bit in FFmpeg, it > > would be better to follow FFmpeg's style to introduce P012 format instead > > of reusing P016. I was under the impression that YUV420P12 is much more different from YUV420P16 than P012 from P016: Did I misunderstand? (Reading the thread again, I don't think I did) > Sorry for picking up this old thread. > > We'd like to add the support for 12bit decoding / encoding in VAAPI and QSV. > Is there any other concern if adding P012 in FFmpeg ? Did you already explain why you cannot use P016 or in which situation it would create a different output? 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 2/2] avformat/img2dec: add GEM Raster image demuxer
Am Fr., 17. Sept. 2021 um 10:39 Uhr schrieb Peter Ross :
> +static int gem_probe(const AVProbeData *p)
> +{
> +const uint8_t *b = p->buf;
> +int ret = 0;
> +if ( AV_RB16(b ) >= 1 && AV_RB16(b) <= 3 &&
> + AV_RB16(b + 2) >= 8 && AV_RB16(b + 2) <= 779 &&
> +(AV_RB16(b + 4) > 0 || AV_RB16(b + 4) <= 8) &&
> +(AV_RB16(b + 6) > 0 || AV_RB16(b + 6) <= 8) &&
> + AV_RB16(b + 8) &&
> + AV_RB16(b + 10) &&
> + AV_RB16(b + 12) &&
> + AV_RB16(b + 14)) {
> +ret = AVPROBE_SCORE_EXTENSION / 4;
Without running probetest, this score looks too high to me.
(1, 2 or 3 followed by anything not 0 with some restrictions?)
Why is the above sufficient? Are there files in the wild
without the fourcc's below?
> +if (AV_RN32(b + 16) == AV_RN32("STTT") ||
> +AV_RN32(b + 16) == AV_RN32("TIMG") ||
> +AV_RN32(b + 16) == AV_RN32("XIMG"))
> +ret += 1;
Should be EXTENSION + 1
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] libavutil/tests/md5: Avoid warnings
Am Fr., 21. Jan. 2022 um 02:18 Uhr schrieb softworkz :
>
> From: softworkz
>
> Those are always showing up on Patchwork
> when FATE tests are failing, covering
> some possibly more useful information.
>
> Signed-off-by: softworkz
> ---
> libavutil/tests/md5: Avoid warnings
>
> Those are always showing up on Patchwork when FATE tests are failing,
> covering some possibly more useful information.
>
> Published-As:
> https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-20%2Fsoftworkz%2Fsubmit_md5-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg
> pr-ffstaging-20/softworkz/submit_md5-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/20
>
> libavutil/tests/md5.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/tests/md5.c b/libavutil/tests/md5.c
> index 42e4538e0a..1f27c40987 100644
> --- a/libavutil/tests/md5.c
> +++ b/libavutil/tests/md5.c
> @@ -33,8 +33,12 @@ int main(void)
> {
> uint8_t md5val[16];
> int i;
> +
> +#if defined(__clang__) && defined(__clang_major__) && __clang_major__ < 4
> volatile uint8_t in[1000]; // volatile to workaround
> http://llvm.org/bugs/show_bug.cgi?id=20849
> -// FIXME remove volatile once it has been fixed and all fate clients are
> updated
I wonder if the volatile shouldn't just be removed after eight years.
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 v2] libavformat/asfdec: Fix regression bug when reading image attachments
Am So., 8. Aug. 2021 um 03:40 Uhr schrieb Soft Works : > When I do this: > > if (value_len < 0 || value_len >= (INT_MAX - LEN) / 2) > return AVERROR_INVALIDDATA; > > Shouldn't we return a different error code? Actually this is not about invalid > data but about a limitation in the implementation.. It is definitely invalid data. 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 v2] libavformat/asfdec: Fix regression bug when reading image attachments
Am So., 8. Aug. 2021 um 03:00 Uhr schrieb Soft Works : > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > James Almer > > Sent: Sunday, 8 August 2021 02:47 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression > > bug when reading image attachments > > > > On 8/7/2021 9:38 PM, Soft Works wrote: > > >> -Original Message- > > >> From: ffmpeg-devel On Behalf Of > > >> Carl Eugen Hoyos > > >> Sent: Sunday, 8 August 2021 01:58 > > >> To: FFmpeg development discussions and patches > >> de...@ffmpeg.org> > > >> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix > > >> regression bug when reading image attachments > > >> > > >> Am So., 8. Aug. 2021 um 01:53 Uhr schrieb Soft Works > > >> : > > >>> > > >>> Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a > > >> check for value_len > UINT16_MAX. > > >>> As a consequence, attached images of sizes larger than UINT16_MAX > > >>> could > > >> no longer be read. > > >>> > > >>> Signed-off-by: softworkz > > >>> --- > > >>> v2: Fix without changing variable type libavformat/asfdec_f.c | 2 +- > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >>> > > >>> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c index > > >>> ff6ddfb967..b9f3918495 100644 > > >>> --- a/libavformat/asfdec_f.c > > >>> +++ b/libavformat/asfdec_f.c > > >>> @@ -614,7 +614,7 @@ static int asf_read_metadata(AVFormatContext > > *s, > > >> int64_t size) > > >>> value_type = avio_rl16(pb); /* value_type */ > > >>> value_len = avio_rl32(pb); > > >>> > > >>> -if (value_len < 0 || value_len > UINT16_MAX) > > >>> +if (value_len < 0) > > >>> return AVERROR_INVALIDDATA; > > >> > > >> I may misread the code but it appears to me that an assert can be > > >> triggered now, no? > > > > > > Right, for these 11 discrete size values only, though: > > > > > > 2147483647, 2147483646, 2147483645, 2147483644, 2147483643, > > > 2147483642, 2147483641, 2147483640, 2147483639, 2147483638 > > > 2147483636 > > > > > > A chance of 11 in 4 Billions :-) > > > > len < (INT_MAX - LEN) / 2 is more than half the range of an int. > > I've been one step ahead in calculation: > > av_malloc takes size_t and on 32bit platforms, this is uint32, which means > that it can take a maximum of 4.294.967.295. > (4.294.967.295 - 22) / 2 = 2.147.483.636 (+ 11 makes INT32_MAX) > > > > > > > > > TBH, I don't understand this assert. When the attachment is too large > > > to handle, we should rather log a warning and goto finish instead IMO. > > > > The assert is to ensure get_tag() is not called with out of range values, > > so the > > relevant checks should happen before the call. > > I'm not sure whether I'd agree with that. It shouldn't be the caller > needing to know what the function can handle and what it can't handle. > The INT32/2 is not only wrong, it also does _only_ apply to reading > unicode. For ASCII and byte arrays, there is no need for this restriction. > And on 64bit platforms, there's no need for this that restriction at all. There is: An allocation >32bit for an attachment in an asf file is always wrong. 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] fftools/cmdutils: don't print build configuration by default
Am Sa., 7. Aug. 2021 um 18:14 Uhr schrieb James Almer : > > On 8/7/2021 1:06 PM, Derek Buitenhuis wrote: > > On 8/6/2021 7:04 PM, James Almer wrote: > >> From: Matthieu Patou > >> > >> Suggested-by: ffm...@fb.com > >> Signed-off-by: James Almer > >> --- > >> fftools/cmdutils.c | 5 +++-- > >> 1 file changed, 3 insertions(+), 2 deletions(-) > > > > What exactly is the point of this? > > > > You've provided a patch with no explanation for its value. > > > > If it's "security", then that's kind of dumb, since if you > > have access to run ffmpeg on something, you have access to > > `strings $(which ffmpeg)` too. > > It's just to reduce the amount of information printed by default. Most > command line utilities don't bother showing build time configuration > options outside of --version or --help output, if at all. > And the string is obviously in the binary (duplicated on every library > at that), so it's not about hiding anything. > > I made the latest version print it on verbose level or higher (and > always with --version), which may be preferable. But i nonetheless > don't have a strong opinion about this change. FWIW, the change is a very bad idea imo. 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] libavformat/asfdec: Fix regression bug when reading image attachments
Am So., 8. Aug. 2021 um 01:33 Uhr schrieb Carl Eugen Hoyos :
>
> Am So., 8. Aug. 2021 um 01:26 Uhr schrieb Soft Works :
> >
> > Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
> > value_len > UINT16_MAX.
> > As a consequence, attached images of sizes larger than UINT16_MAX could no
> > longer be read.
> >
> > Signed-off-by: softworkz
> > ---
> > libavformat/asfdec_f.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> > index f784e62996..708331637e 100644
> > --- a/libavformat/asfdec_f.c
> > +++ b/libavformat/asfdec_f.c
> > @@ -707,7 +707,8 @@ static int asf_read_metadata(AVFormatContext *s,
> > int64_t size)
> > {
> > AVIOContext *pb = s->pb;
> > ASFContext *asf = s->priv_data;
> > -int n, stream_num, name_len_utf16, name_len_utf8, value_len;
> > +int n, stream_num, name_len_utf16, name_len_utf8;
> > + unsigned int value_len;
>
> There is something wrong with the indentation afaict.
> And why can't you fix the issue leaving the variable an int?
Should have been:
Is it possible to fix the issue without changing the variable type?
Sorry for the bad wording, 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 v2] libavformat/asfdec: Fix regression bug when reading image attachments
Am So., 8. Aug. 2021 um 01:53 Uhr schrieb Soft Works : > > Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for > value_len > UINT16_MAX. > As a consequence, attached images of sizes larger than UINT16_MAX could no > longer be read. > > Signed-off-by: softworkz > --- > v2: Fix without changing variable type > libavformat/asfdec_f.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c > index ff6ddfb967..b9f3918495 100644 > --- a/libavformat/asfdec_f.c > +++ b/libavformat/asfdec_f.c > @@ -614,7 +614,7 @@ static int asf_read_metadata(AVFormatContext *s, int64_t > size) > value_type = avio_rl16(pb); /* value_type */ > value_len = avio_rl32(pb); > > -if (value_len < 0 || value_len > UINT16_MAX) > +if (value_len < 0) > return AVERROR_INVALIDDATA; I may misread the code but it appears to me that an assert can be triggered now, no? 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] mxf : correct previous commit
Am Do., 5. Aug. 2021 um 11:03 Uhr schrieb Michael Krebs : > > * Let older tags on the same place as originally > * Add new fate tests for rawvideo and v210 and update checksum for mxf tests This commit message indicates that the patch should be split. 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] libavformat/asfdec: Fix regression bug when reading image attachments
Am So., 8. Aug. 2021 um 01:26 Uhr schrieb Soft Works :
>
> Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
> value_len > UINT16_MAX.
> As a consequence, attached images of sizes larger than UINT16_MAX could no
> longer be read.
>
> Signed-off-by: softworkz
> ---
> libavformat/asfdec_f.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> index f784e62996..708331637e 100644
> --- a/libavformat/asfdec_f.c
> +++ b/libavformat/asfdec_f.c
> @@ -707,7 +707,8 @@ static int asf_read_metadata(AVFormatContext *s, int64_t
> size)
> {
> AVIOContext *pb = s->pb;
> ASFContext *asf = s->priv_data;
> -int n, stream_num, name_len_utf16, name_len_utf8, value_len;
> +int n, stream_num, name_len_utf16, name_len_utf8;
> + unsigned int value_len;
There is something wrong with the indentation afaict.
And why can't you fix the issue leaving the variable an int?
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] Fix SPDIF detection score
Am So., 11. Apr. 2021 um 15:56 Uhr schrieb Denis Shulyaka : > > This patch fixes the detection score for spdif (IEC61937). > > Signed-off-by: Denis Shulyaka > --- > libavformat/spdifdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c > index 1808fa9d65..05c155f49c 100644 > --- a/libavformat/spdifdec.c > +++ b/libavformat/spdifdec.c > @@ -140,7 +140,7 @@ int ff_spdif_probe(const uint8_t *p_buf, int buf_size, > enum AVCodecID *codec) > break; > > /* continue probing to find more sync codes */ > -probe_end = FFMIN(buf + SPDIF_MAX_OFFSET, p_buf + buf_size - 1); > +probe_end = FFMIN(buf + SPDIF_MAX_OFFSET + 1, p_buf + buf_size - > 1); Do you have a sample that shows that this patch fixes detection? 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] libavcodec: r12b decoder
Am Di., 8. Juni 2021 um 11:52 Uhr schrieb Dennis Fleurbaaij : > The four letter "r12b" format code is from the DeckLink documentation; > there are other described formats there as well such as r12l, r10b, r10l > and r210. I'm using DirectShow which signals the encoding to downstream > components through the use of FOURCC codes and hence for this filter to be > of any use in such applications there needs to be a way to identify it. This does not sound like a good reason to add a new fourcc. > r210 from their docs has already gained some traction as a fourcc and hence > adding the others in a similar vein seemed a reasonable approach. "r12b" > also sounds reasonable to me as a fourcc: it starts with an r, indicative > of RGB formats, and the bit/pixel + endianness didn't seem unreasonable. > Also I could find no other fourcc's used for this and hence I added it. The change to riff.c should at least be an independent patch. 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] libavcodec: r12b decoder
Von meinem iPhone gesendet > Am 07.06.2021 um 12:09 schrieb Dennis Fleurbaaij : > > Pulled master and re-applied to resolve version update conflict > R12B is a format used by BlackMagic DeckLink cards How does the card produce avi files / why are you adding a fourcc? Please elaborate, 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] avutil/mem: use GCC builtins to check for overflow in av_size_mult()
Am Do., 27. Mai 2021 um 17:08 Uhr schrieb James Almer :
>
> Signed-off-by: James Almer
> ---
> libavutil/mem.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index e21a1feaae..c876111afb 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
> @@ -674,11 +674,18 @@ void *av_dynarray2_add(void **tab_ptr, int *nb_ptr,
> size_t elem_size,
> */
> static inline int av_size_mult(size_t a, size_t b, size_t *r)
> {
> -size_t t = a * b;
> +size_t t;
> +
> +#if (!defined(__INTEL_COMPILER) && AV_GCC_VERSION_AT_LEAST(5,1)) ||
> AV_HAS_BUILTIN(__builtin_mul_overflow)
> +if (__builtin_mul_overflow(a, b, ))
> +return AVERROR(EINVAL);
> +#else
> +t = a * b;
> /* Hack inspired from glibc: don't try the division if nelem and elsize
> * are both less than sqrt(SIZE_MAX). */
> if ((a | b) >= ((size_t)1 << (sizeof(size_t) * 4)) && a && t / a != b)
> return AVERROR(EINVAL);
> +#endif
The commit message appears to be missing a hint about the performance
difference.
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] FSB File Version 5 Support
Am So., 23. Mai 2021 um 15:51 Uhr schrieb Michael Tonks : > The sampel file is available via github here: > https://gist.github.com/miketonks/b9fe5b647407a44c86c65a017927e7d9 I have created ticket #9261, thank you for the sample! 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] Builds for MAC
Am So., 16. Mai 2021 um 15:00 Uhr schrieb : > Would you be interested in me making additional unofficial > mac builds for you to add to the downloads page? There is nothing wrong with more builds but we will not promise anything before your download page exists. 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] avcodec/videotoolboxenc: #define TARGET_CPU_ARM64 to 0 if not provided by the SDK
> Am 15.05.2021 um 14:12 schrieb Zane van Iperen :
>
>
>
>> On 15/5/21 10:11 pm, Timo Rothenpieler wrote:
>>> On 15.05.2021 11:45, Zane van Iperen wrote:
>>> Fixes build failure on older SDKs without it.
>>>
>>> Fixes #9242
>>>
>>> Signed-off-by: Zane van Iperen
>>> ---
>>> libavcodec/videotoolboxenc.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> NB: This is untested, I do not have a Mac to try it on.
>>>
>>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>>> index 58239e0ab9..3d3677362a 100644
>>> --- a/libavcodec/videotoolboxenc.c
>>> +++ b/libavcodec/videotoolboxenc.c
>>> @@ -50,6 +50,11 @@ enum { kCVPixelFormatType_420YpCbCr10BiPlanarFullRange =
>>> 'xf20' };
>>> enum { kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange = 'x420' };
>>> #endif
>>> +/* Older SDKs don't have this, make sure we can actually compile we're
>>> using one. */
>> Second half of that sentence is missing a word or has too many.
>
> Yeah, picked that up shortly after I posted it. It's meant to read:
> "Older SDKs don't have this, make sure we can actually compile if we're using
> one."
Make it „Defined in macOS 10.x“ instead or remove the comment.
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 v2 67/90] avutil: Switch crypto APIs to size_t
Am Mo., 19. Apr. 2021 um 21:22 Uhr schrieb Andreas Rheinhardt
:
>
> From: Andreas Rheinhardt
>
> Announced in e435beb1ea5380a90774dbf51fdc8c941e486551.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I forgot a printf specifier in tests/api/api-h264-test.c.
> diff --git a/libavutil/version.h b/libavutil/version.h
> index dbeb7ffe23..54b09534a2 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -105,9 +105,6 @@
> * @{
> */
>
> -#ifndef FF_API_CRYPTO_SIZE_T
> -#define FF_API_CRYPTO_SIZE_T(LIBAVUTIL_VERSION_MAJOR < 57)
> -#endif
> #ifndef FF_API_FRAME_GET_SET
> #define FF_API_FRAME_GET_SET(LIBAVUTIL_VERSION_MAJOR < 57)
> #endif
> diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
> index 04bdfbc9d2..6f13e773f9 100644
> --- a/tests/api/api-h264-test.c
> +++ b/tests/api/api-h264-test.c
> @@ -153,7 +153,7 @@ static int video_decode_example(const char
> *input_filename)
> av_frame_unref(fr);
> return number_of_written_bytes;
> }
> -printf("%d, %s, %s, %8"PRId64", %8d, 0x%08lx\n", video_stream,
> +printf("%d, %s, %s, %8"PRId64", %8d, 0x%08"PRIx32"\n",
> video_stream,
> av_ts2str(fr->pts), av_ts2str(fr->pkt_dts),
> fr->pkt_duration,
> number_of_written_bytes, av_adler32_update(0, (const
> uint8_t*)byte_buffer, number_of_written_bytes));
Afaict, this change is either related to another patch or wrong.
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 59/87] Disable vf_uspp/mcdeint.
Am Mo., 19. Apr. 2021 um 16:19 Uhr schrieb James Almer : > > From: Anton Khirnov > > These filters depend on avcodec APIs that are to be removed. Some people > have expressed potential interest in updating these filters, so they are > merely disabled for now instead of being removed. I still believe that updating these filters is simply a prerequisite for the patchset. 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] [FFmpeg-cvslog] avformat/webpenc: don't assume animated webp streams will have more than one packet
> Am 16.04.2021 um 16:15 schrieb James Almer :
>
> ffmpeg | branch: master | James Almer | Sat Apr 10
> 22:53:34 2021 -0300| [55d667d86af7d13fc5aa2b4071a5b97eb10e2da6] | committer:
> James Almer
>
> avformat/webpenc: don't assume animated webp streams will have more than one
> packet
>
> The libwebp_animencoder returns a single packet with the entire animated
> stream, as that's what the external library produces. As such, only ensure the
> stream was produced by said encoder (or propagated by a demuxer, once support
> is added) when attempting to write the requested loop value.
>
> Fixes ticket #9179.
>
> Signed-off-by: James Almer
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=55d667d86af7d13fc5aa2b4071a5b97eb10e2da6
> ---
>
> libavformat/webpenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
> index ed8325c02d..ca4ffc4e2d 100644
> --- a/libavformat/webpenc.c
> +++ b/libavformat/webpenc.c
> @@ -172,7 +172,7 @@ static int webp_write_trailer(AVFormatContext *s)
> WebpContext *w = s->priv_data;
>
> if (w->using_webp_anim_encoder) {
> -if ((w->frame_count > 1) && w->loop) { // Write loop count.
> +if (w->loop) { // Write loop count.
> avio_seek(s->pb, 42, SEEK_SET);
> avio_wl16(s->pb, w->loop);
> }
I wonder now why you are asking for reviews, more so given that you tend to
block patches you consider not good enough.
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/1] libavutil: Fix uClibc build for mips
Am So., 11. Apr. 2021 um 19:53 Uhr schrieb Bernd Kuhls : > > uClibc does not provide sys/auxv.h: Unfortunately, this is also true for older glibc versions, see ticket #9138. A check in configure is necessary instead. 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 3/3] avformat/webpenc: don't assume animated webp streams will have more than one packet
Am So., 11. Apr. 2021 um 18:50 Uhr schrieb James Almer :
>
> On 4/11/2021 1:30 PM, Carl Eugen Hoyos wrote:
> > Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
> >>
> >> The libwebp_animencoder returns a single packet with the entire animated
> >> stream, as that's what the external library produces. As such, only ensure
> >> the
> >> stream was produced by said encoder (or propagated by a demuxer, once
> >> support
> >> is added) when attempting to write the requested loop value.
> >>
> >> Fixes ticket #9179.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavformat/webpenc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
> >> index ed8325c02d..ca4ffc4e2d 100644
> >> --- a/libavformat/webpenc.c
> >> +++ b/libavformat/webpenc.c
> >> @@ -172,7 +172,7 @@ static int webp_write_trailer(AVFormatContext *s)
> >> WebpContext *w = s->priv_data;
> >>
> >> if (w->using_webp_anim_encoder) {
> >> -if ((w->frame_count > 1) && w->loop) { // Write loop count.
> >> +if (w->loop) { // Write loop count.
> >> avio_seek(s->pb, 42, SEEK_SET);
> >> avio_wl16(s->pb, w->loop);
> >
> > Sorry for not understanding this:
> > Why is the seek necessary at all?
>
> If we write the loop value in webp_write_trailer() then there's no other
> way. But if we instead attempt to write it in webp_write_packet() then a
> seek wouldn't be needed, no.
If I don't miss anything, the value should not be written in
webp_write_trailer() then.
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 3/3] avformat/webpenc: don't assume animated webp streams will have more than one packet
Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
>
> The libwebp_animencoder returns a single packet with the entire animated
> stream, as that's what the external library produces. As such, only ensure the
> stream was produced by said encoder (or propagated by a demuxer, once support
> is added) when attempting to write the requested loop value.
>
> Fixes ticket #9179.
>
> Signed-off-by: James Almer
> ---
> libavformat/webpenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
> index ed8325c02d..ca4ffc4e2d 100644
> --- a/libavformat/webpenc.c
> +++ b/libavformat/webpenc.c
> @@ -172,7 +172,7 @@ static int webp_write_trailer(AVFormatContext *s)
> WebpContext *w = s->priv_data;
>
> if (w->using_webp_anim_encoder) {
> -if ((w->frame_count > 1) && w->loop) { // Write loop count.
> +if (w->loop) { // Write loop count.
> avio_seek(s->pb, 42, SEEK_SET);
> avio_wl16(s->pb, w->loop);
Sorry for not understanding this:
Why is the seek necessary at all?
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] lavfi/cas: fix the wrong source linesize
Am So., 11. Apr. 2021 um 17:25 Uhr schrieb Paul B Mahol :
>
> I think this is invalid.
> Give explanation why you think your approach is correct one.
>
> On Sun, Apr 11, 2021 at 4:54 PM Zhong Li wrote:
>
> > Signed-off-by: Zhong Li
> > ---
> > libavfilter/vf_cas.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_cas.c b/libavfilter/vf_cas.c
> > index 7c32ed5f9b..b44a100421 100644
> > --- a/libavfilter/vf_cas.c
> > +++ b/libavfilter/vf_cas.c
> > @@ -65,7 +65,7 @@ static int cas_slice8(AVFilterContext *avctx, void *arg,
> > int jobnr, int nb_jobs)
> > const uint8_t *src = in->data[p];
> >
> > if (!((1 << p) & s->planes)) {
> > -av_image_copy_plane(dst, linesize, src + slice_start *
> > linesize, in_linesize,
> > +av_image_copy_plane(dst, linesize, src + slice_start *
> > in_linesize, in_linesize,
It looks to me as if before the patch the (output) linesize was
combined with the (input) src pointer which is surprising.
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] avformat/rawenc: perform stream checks for mp2 muxer
Am So., 11. Apr. 2021 um 07:28 Uhr schrieb Gyan Doshi :
>
> ---
> libavformat/rawenc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
> index caec297f4a..0802d9a831 100644
> --- a/libavformat/rawenc.c
> +++ b/libavformat/rawenc.c
> @@ -433,6 +433,7 @@ AVOutputFormat ff_mp2_muxer = {
> .extensions= "mp2,m2a,mpa",
> .audio_codec = AV_CODEC_ID_MP2,
> .video_codec = AV_CODEC_ID_NONE,
> +.init = force_one_stream,
Please push.
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] [FFmpeg-cvslog] doc/muxers: add entries for raw muxers
Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi : > > ffmpeg | branch: master | Gyan Doshi | Sat Apr 10 16:35:53 > 2021 +0530| [47b8871ca6f9da4c0467466a43d204dec7fcbd4a] | committer: Gyan Doshi > > doc/muxers: add entries for raw muxers Is this really an improvement of our documentation? > +@subsection mpeg1video > + > +MPEG-1 Part 2 video. > + > +Extensions: mpg, mpeg, m1v I hope and believe that this is wrong. 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] JPEG-LS Decoder: Update
Am Sa., 10. Apr. 2021 um 14:35 Uhr schrieb Spyros Theoharis
:
>
> - 8 up to 16 bits
> - 444/422/420/411
> - fixed restart mechanism support
> - RGB/YUV 444 images (via -rgb444 input option)
This typically indicates that you should send four patches
instead of one.
How can we create samples / please provide samples.
[...]
> + * Skip bitstream for the next restart marker
> + */
Was this completely missing so far or what is the
reason for this change?
> +static int exp_mk = 0;
You cannot use a static variable, add it to the context instead.
> +static inline int ls_decode_skip_restart_marker(MJpegDecodeContext *s, int
> init)
> +{
> +int mk = 0, t = 0;
> +
> +if (init) exp_mk = 0;
> +
> +while (mk != 0xff && t++ < 16) { /* skip 0xFF */
> +mk = (mk<<1) + get_bits1(>gb);
> +}
> +mk &= 0xff;
> +mk <<= 8;
> +mk += get_bits(>gb, 8); /* skip RSTn */
> +
> +if (mk != 0xffd0 + (exp_mk % 8)) {
Use "&" instead of "%".
> +av_log(s->avctx, AV_LOG_WARNING, "ERROR: Invalid restart marker
> 0x%.4X, expected is 0x%.4X\n", mk, 0xffd0 + (exp_mk % 8));
This line does not make sense...
Please split your patch and resend, 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] IEC61937_EAC3 decoding support
Am Sa., 10. Apr. 2021 um 10:46 Uhr schrieb Denis Shulyaka :
>
> This patch adds support to decode IEC61937_EAC3 (aka dolby digital plus).
>
> Signed-off-by: Denis Shulyaka
> ---
> libavformat/spdifdec.c | 47 ++
> 1 file changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c
> index 1808fa9d65..58841e7775 100644
> --- a/libavformat/spdifdec.c
> +++ b/libavformat/spdifdec.c
> @@ -93,6 +93,10 @@ static int spdif_get_offset_and_codec(AVFormatContext *s,
> *offset = 8192;
> *codec = AV_CODEC_ID_DTS;
> break;
> +case IEC61937_EAC3:
> +*offset = AC3_FRAME_SIZE << 4;
> +*codec = AV_CODEC_ID_EAC3;
> +break;
> default:
> if (s) { /* be silent during a probe */
> avpriv_request_sample(s, "Data type 0x%04x in IEC 61937",
> @@ -103,9 +107,34 @@ static int spdif_get_offset_and_codec(AVFormatContext *s,
> return 0;
> }
>
> -/* Largest offset between bursts we currently handle, i.e. AAC with
> - samples = 4096 */
> -#define SPDIF_MAX_OFFSET 16384
> +static int spdif_read_burst_payload_length(AVFormatContext *s,
> + enum IEC61937DataType data_type)
> +{
> +AVIOContext *pb = s->pb;
> +int pkt_size_bits, pkt_size_bytes;
> +
> +switch (data_type & 0xff) {
> +case IEC61937_EAC3:
> +pkt_size_bytes = avio_rl16(pb);
> +
> +if (pkt_size_bytes % 2)
Please use "&" instead of "%".
> +avpriv_request_sample(s, "Packet not ending at a 16-bit
> boundary");
> +
> +return FFALIGN(pkt_size_bytes, 2);
> +break;
Please remove this line.
> +default:
> +pkt_size_bits = avio_rl16(pb);
> +
> +if (pkt_size_bits % 16)
See above.
> +avpriv_request_sample(s, "Packet not ending at a 16-bit
> boundary");
> +
> +return FFALIGN(pkt_size_bits, 16) >> 3;
> +}
> +return 0;
Please remove this line or the default branch above.
> +}
> +
> +/* Largest offset between bursts we currently handle, i.e. E-AC-3 */
> +#define SPDIF_MAX_OFFSET 24576
>
> static int spdif_probe(const AVProbeData *p)
> {
> @@ -140,7 +169,7 @@ int ff_spdif_probe(const uint8_t *p_buf, int buf_size,
> enum AVCodecID *codec)
> break;
>
> /* continue probing to find more sync codes */
> -probe_end = FFMIN(buf + SPDIF_MAX_OFFSET, p_buf + buf_size - 1);
> +probe_end = FFMIN(buf + SPDIF_MAX_OFFSET + 1, p_buf + buf_size -
> 1);
Is this an unrelated fix?
>
> /* skip directly to the next sync code */
> if (!spdif_get_offset_and_codec(NULL, (buf[2] << 8) | buf[1],
> @@ -176,7 +205,7 @@ int ff_spdif_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> enum IEC61937DataType data_type;
> enum AVCodecID codec_id;
> uint32_t state = 0;
> -int pkt_size_bits, offset, ret;
> +int pkt_size, offset, ret;
>
> while (state != (AV_BSWAP16C(SYNCWORD1) << 16 | AV_BSWAP16C(SYNCWORD2)))
> {
> state = (state << 8) | avio_r8(pb);
> @@ -185,12 +214,12 @@ int ff_spdif_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> }
>
> data_type = avio_rl16(pb);
> -pkt_size_bits = avio_rl16(pb);
> +pkt_size = spdif_read_burst_payload_length(s, data_type);
>
> -if (pkt_size_bits % 16)
> -avpriv_request_sample(s, "Packet not ending at a 16-bit boundary");
> +if (!pkt_size)
> +return AVERROR_BUG;
This looks wrong or do I miss something?
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] lavc/aarch64: add pred16x16 10-bit functions
Am Do., 8. Apr. 2021 um 21:10 Uhr schrieb Mikhail Nitenko :
>
> here are the benchmarks https://0x1.st/kX.txt
Instead please add the relevant lines to the commit message.
> ---
> libavcodec/aarch64/h264pred_init.c | 75 +++---
> libavcodec/aarch64/h264pred_neon.S | 123 +
> 2 files changed, 168 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/aarch64/h264pred_init.c
> b/libavcodec/aarch64/h264pred_init.c
> index b144376f90..d74205c2de 100644
> --- a/libavcodec/aarch64/h264pred_init.c
> +++ b/libavcodec/aarch64/h264pred_init.c
> @@ -45,42 +45,57 @@ void ff_pred8x8_0lt_dc_neon(uint8_t *src, ptrdiff_t
> stride);
> void ff_pred8x8_l00_dc_neon(uint8_t *src, ptrdiff_t stride);
> void ff_pred8x8_0l0_dc_neon(uint8_t *src, ptrdiff_t stride);
>
> +void ff_pred16x16_128_dc_neon_10(uint8_t *src, ptrdiff_t stride);
> +void ff_pred16x16_top_dc_neon_10(uint8_t *src, ptrdiff_t stride);
> +void ff_pred16x16_left_dc_neon_10(uint8_t *src, ptrdiff_t stride);
> +void ff_pred16x16_dc_neon_10(uint8_t *src, ptrdiff_t stride);
> +void ff_pred16x16_hor_neon_10(uint8_t *src, ptrdiff_t stride);
> +void ff_pred16x16_vert_neon_10(uint8_t *src, ptrdiff_t stride);
> +
> static av_cold void h264_pred_init_neon(H264PredContext *h, int codec_id,
> const int bit_depth,
> const int chroma_format_idc)
> {
> -const int high_depth = bit_depth > 8;
> -
> -if (high_depth)
> -return;
> -
> -if (chroma_format_idc <= 1) {
> -h->pred8x8[VERT_PRED8x8 ] = ff_pred8x8_vert_neon;
> -h->pred8x8[HOR_PRED8x8 ] = ff_pred8x8_hor_neon;
> -if (codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
> -h->pred8x8[PLANE_PRED8x8] = ff_pred8x8_plane_neon;
> -h->pred8x8[DC_128_PRED8x8 ] = ff_pred8x8_128_dc_neon;
> -if (codec_id != AV_CODEC_ID_RV40 && codec_id != AV_CODEC_ID_VP7 &&
> -codec_id != AV_CODEC_ID_VP8) {
> -h->pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_neon;
> -h->pred8x8[LEFT_DC_PRED8x8] = ff_pred8x8_left_dc_neon;
> -h->pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_neon;
> -h->pred8x8[ALZHEIMER_DC_L0T_PRED8x8] = ff_pred8x8_l0t_dc_neon;
> -h->pred8x8[ALZHEIMER_DC_0LT_PRED8x8] = ff_pred8x8_0lt_dc_neon;
> -h->pred8x8[ALZHEIMER_DC_L00_PRED8x8] = ff_pred8x8_l00_dc_neon;
> -h->pred8x8[ALZHEIMER_DC_0L0_PRED8x8] = ff_pred8x8_0l0_dc_neon;
> +if (bit_depth == 8) {
> +if (chroma_format_idc <= 1) {
> +h->pred8x8[VERT_PRED8x8 ] = ff_pred8x8_vert_neon;
> +h->pred8x8[HOR_PRED8x8 ] = ff_pred8x8_hor_neon;
> +if (codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
> +h->pred8x8[PLANE_PRED8x8] = ff_pred8x8_plane_neon;
> +h->pred8x8[DC_128_PRED8x8 ] = ff_pred8x8_128_dc_neon;
> +if (codec_id != AV_CODEC_ID_RV40 && codec_id != AV_CODEC_ID_VP7
> &&
> +codec_id != AV_CODEC_ID_VP8) {
> +h->pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_neon;
> +h->pred8x8[LEFT_DC_PRED8x8] = ff_pred8x8_left_dc_neon;
> +h->pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_neon;
> +h->pred8x8[ALZHEIMER_DC_L0T_PRED8x8] =
> ff_pred8x8_l0t_dc_neon;
> +h->pred8x8[ALZHEIMER_DC_0LT_PRED8x8] =
> ff_pred8x8_0lt_dc_neon;
> +h->pred8x8[ALZHEIMER_DC_L00_PRED8x8] =
> ff_pred8x8_l00_dc_neon;
> +h->pred8x8[ALZHEIMER_DC_0L0_PRED8x8] =
> ff_pred8x8_0l0_dc_neon;
Please do not re-indent these lines in the patch that adds the new functions,
feel free to send a separate patch for the re-indentation.
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] mov: Prioritize aspect ratio values found in pasp atom
Am Di., 6. Apr. 2021 um 21:51 Uhr schrieb Vittorio Giovara : > > without my patch the sample is shown at a 16:9 > AR (which I assume was the original fix), with my patch the sample uses an > AR of 1:1 and it is therefore square. > However I tried with a recent > Quicktime, and it displays the sample using the square aspect ratio. I would expect that it looks different with older QuickTime versions. 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] mov: Skip computing SAR from invalid display matrix elements
Am Di., 30. März 2021 um 19:24 Uhr schrieb Vittorio Giovara : > > Hello, > I was debugging an issue with a video file containing an invalid > display matrix, probably produced by a non conforming software. > > The content of the matrix is: > :0 65536 0 > 0001: -1 0 0 > 0002:0 0 1073741824 > > The -1 (stored as 4294967295) was probably a 1 shifted 32 times instead > of 16. The problem is that this value is bypassing the validation check > in the code below, and the resulting computed SAR value becomes 1:65536. > > This change interprets extremely low entries as invalid and makes sure > to skip them in the SAR computation. This passes fate, but I haven't been > able to test this extensively. > Please see the attached patch, any feedback or better solution is welcome. Is this related to ticket #7277? 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] avformat/rtpdec: Fix prft wallclock time.
Am Di., 30. März 2021 um 17:02 Uhr schrieb James Almer :
>
> On 3/25/2021 1:46 AM, Alok Priyadarshi wrote:
> > Timestamp difference is available in media timebase (1/90K) where as
> > rtcp time is in the default microseconds timebase. This patch fixes
> > the calculated prft wallclock time by rescaling the timestamp delta
> > to the microseconds timebase.
> > ---
> > libavformat/rtpdec.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> > index b935dba1b8..21c1d01785 100644
> > --- a/libavformat/rtpdec.c
> > +++ b/libavformat/rtpdec.c
> > @@ -585,14 +585,19 @@ void ff_rtp_parse_set_crypto(RTPDemuxContext *s,
> > const char *suite,
> > }
> >
> > static int rtp_set_prft(RTPDemuxContext *s, AVPacket *pkt, uint32_t
> > timestamp) {
> > +int64_t rtcp_time, delta_timestamp, delta_time;
> > +
> > AVProducerReferenceTime *prft =
> > (AVProducerReferenceTime *) av_packet_new_side_data(
> > pkt, AV_PKT_DATA_PRFT, sizeof(AVProducerReferenceTime));
> > if (!prft)
> > return AVERROR(ENOMEM);
> >
> > -prft->wallclock = ff_parse_ntp_time(s->last_rtcp_ntp_time) -
> > NTP_OFFSET_US +
> > - timestamp - s->last_rtcp_timestamp;
> > +rtcp_time = ff_parse_ntp_time(s->last_rtcp_ntp_time) - NTP_OFFSET_US;
> > +delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
> > +delta_time = av_rescale_q(delta_timestamp, s->st->time_base,
> > AV_TIME_BASE_Q);
> > +
> > +prft->wallclock = rtcp_time + delta_time;
> > prft->flags = 24;
> > return 0;
> > }
>
> Applied, thanks.
I still believe that such patches should not get applied.
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] avformat/dashdec: Improve implementation
Am So., 28. März 2021 um 22:58 Uhr schrieb Derek Buitenhuis : > > On 28/03/2021 21:05, Carl Eugen Hoyos wrote: > > The patch clearly mentions that it is a "rework". > > If the maintainer likes it, it would be nice if it can be simplified but > > this may not be possible. > > Of course it's /possible/. People have been splitting rewrites/refactors into > these since forever; > FFmpeg's history is full of them. I wasn't aware, I cannot remember one atm. > I'm not going to argue if Steven is fine with it, but it's certainly possible. > I hope I never come across this in a git bisect or blame... I wish this would count as an argument more often! 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] avformat/dashdec: Improve implementation
Am Sa., 27. März 2021 um 17:45 Uhr schrieb Derek Buitenhuis : > > On 22/03/2021 22:25, zsugabubus wrote: > > Compared to previous implementation, this rework tries to: > > > > - Improve code quality, > > - Provide better error handling (also: reduce numerous (potential) > > memory leaks), > > - Broader coverage of the standard: > > * multiple periods, > > * multiple base URLs (fallback on CDN failure), > > * handle ContentProtection/Role/etc... nodes, > > * manifest chaining, > > * drop ridiculous limits of @id's. > > - Fast startup, thanks to reading/probing streams only when needed. > > - Open multiple connections (HLS can open one more connection in > > advance; DASH can do up to UINT_MAX, configurable via option); > > similarly to HLS, currently it only opens them so only sequential > > reading is possible, however this behavior can be changed in the > > future, > > - Ability to seek live streams. > > - Bonus: Tests show that there are some kind of live streams that old > > implementation was unable to cope with, now it is possible to play > > them. > > These should be separate, testable, atomic commits. One massive > patch that does 40 things is not reviewable or good for git history. The patch clearly mentions that it is a "rework". If the maintainer likes it, it would be nice if it can be simplified but this may not be possible. 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]lavc/mjpegdec: Support pixel format 0x11412100
Hi!
Attached patch fixes decoding of a sample mentioned in ticket #8930.
Please comment, Carl Eugen
From 40fd2f1655839f721ef988d1369c45e00fa9c40b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 28 Mar 2021 00:27:23 +0100
Subject: [PATCH] lavc/mjpegdec: Support pixel format 0x11412100.
Fixes decoding of Nene421-rgb.jpg
---
libavcodec/mjpegdec.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5583d2aa35..3731b2fa1b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -603,6 +603,19 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG;
}
break;
+case 0x11412100:
+if (s->bits > 8)
+goto unk_pixfmt;
+if (s->component_id[0] == 'R' - 1 && s->component_id[1] == 'G' - 1 && s->component_id[2] == 'B' - 1) {
+s->avctx->pix_fmt = AV_PIX_FMT_GBRP;
+s->upscale_h[0] = 0;
+s->upscale_h[1] = 1;
+s->upscale_h[2] = 4;
+} else {
+goto unk_pixfmt;
+}
+s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG;
+break;
case 0x2100:
if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && s->component_id[2] == 'A') {
if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_GBRP;
@@ -2696,6 +2709,12 @@ the_end:
for (index = w - 3; index > 0; index--) {
line[index] = (line[index / 3] + line[(index + 1) / 3] + line[(index + 2) / 3] + 1) / 3;
}
+} else if (s->upscale_h[p] == 4 && w >= 4 && !is16bit){
+line [w - 1] = line [w - 1 >> 2];
+line [w - 2] = line [w - 1 >> 2] * 3 + line [w - 2 >> 2] >> 2;
+line [w - 3] = line [w - 1 >> 2] + line [w - 2 >> 2] >> 1;
+for (index = w - 4; index > 0; index--)
+line[index] = (line[index + 3 >> 2] + line[index + 2 >> 2] + line[index + 1 >> 2] + line[index >> 2]) >> 2;
}
line += s->linesize[p];
}
--
2.30.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]lavc/mjpegdec: Support pixel format 0x41211100
Hi! Attached patch fixes decoding of a sample mentioned in ticket #8930. Please comment, Carl Eugen From 3ff1912cf052eec9f1c1a71b657b7668902b5313 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 28 Mar 2021 00:23:34 +0100 Subject: [PATCH] lavc/mjpegdec: Support pixel format 0x41211100. Fixes decoding of Nene421-ycc.jpg --- libavcodec/mjpegdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index 5583d2aa35..0731be7af9 100644 --- a/libavcodec/mjpegdec.c +++ b/libavcodec/mjpegdec.c @@ -624,6 +624,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s) break; case 0x22121100: case 0x22111200: +case 0x41211100: if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P; else goto unk_pixfmt; @@ -2647,6 +2648,8 @@ the_end: avctx->pix_fmt == AV_PIX_FMT_YUVJ440P || avctx->pix_fmt == AV_PIX_FMT_YUV440P || avctx->pix_fmt == AV_PIX_FMT_YUVA444P || + avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || + avctx->pix_fmt == AV_PIX_FMT_YUV422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUV420P || avctx->pix_fmt == AV_PIX_FMT_YUV420P16|| -- 2.30.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]lavc/mjpegdec: Support pixel format 0x11311100
Hi!
Attached patch fixes decoding of a sample mentioned in ticket #8930.
Please comment, Carl Eugen
From 30316e5626df36089893f0800660e96ecbf25d1e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 28 Mar 2021 00:31:05 +0100
Subject: [PATCH] lavc/mjpegdec: Support pixel format 0x11311100.
Fixes decoding of Nene3xRGB.jpg
---
libavcodec/mjpegdec.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5583d2aa35..575b2d8d4a 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -615,6 +615,17 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG;
}
break;
+case 0x11311100:
+if (s->bits > 8)
+goto unk_pixfmt;
+if (s->component_id[0] == 'R' - 1 && s->component_id[1] == 'G' - 1 && s->component_id[2] == 'B' - 1) {
+s->avctx->pix_fmt = AV_PIX_FMT_GBRP;
+} else {
+goto unk_pixfmt;
+}
+s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG;
+s->upscale_h[1] = s->upscale_h[2] = 2;
+break;
case 0x3100:
if (s->bits > 8)
goto unk_pixfmt;
--
2.30.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 v2] lavu: add BCMVK hwcontext implementation
Am Sa., 27. März 2021 um 01:59 Uhr schrieb : > > From: Suji Velupillai > > Initial commit to add BCMVK hardware accelerator implementation. > The depedency component vkil source code can be obtained from github > https://github.com/Broadcom/vkil I just googled for "BCMVK" and could not quickly find out what it is, the only useful link I saw points to this mailng list. The github page has no readme and a very low number of commits, googling for "vkil" only points to the github page afaict. We had a (short) discussion about this topic, iirc, the outcome was that we will consider accepting this patch if hardware can be bought online (easily). Don't misunderstand me: This is not about "BCMVK" or "vkil" but more about the question if we help FFmpeg users if we add this hardware acceleration to our codebase. Availability of hardware may not be an argument sufficient to justify the addition but I suspect it counts as a necessary condition. 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] avformat/rtpdec: Fix prft wallclock time.
Am Do., 25. März 2021 um 05:47 Uhr schrieb Alok Priyadarshi :
>
> Timestamp difference is available in media timebase (1/90K) where as
> rtcp time is in the default microseconds timebase. This patch fixes
> the calculated prft wallclock time by rescaling the timestamp delta
> to the microseconds timebase.
> ---
> libavformat/rtpdec.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index b935dba1b8..21c1d01785 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -585,14 +585,19 @@ void ff_rtp_parse_set_crypto(RTPDemuxContext *s, const
> char *suite,
> }
>
> static int rtp_set_prft(RTPDemuxContext *s, AVPacket *pkt, uint32_t
> timestamp) {
> +int64_t rtcp_time, delta_timestamp, delta_time;
> +
> AVProducerReferenceTime *prft =
> (AVProducerReferenceTime *) av_packet_new_side_data(
> pkt, AV_PKT_DATA_PRFT, sizeof(AVProducerReferenceTime));
> if (!prft)
> return AVERROR(ENOMEM);
>
> -prft->wallclock = ff_parse_ntp_time(s->last_rtcp_ntp_time) -
> NTP_OFFSET_US +
> - timestamp - s->last_rtcp_timestamp;
Wouldn't this patch get much more readable if you only replace this line?
> +rtcp_time = ff_parse_ntp_time(s->last_rtcp_ntp_time) - NTP_OFFSET_US;
> +delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
> +delta_time = av_rescale_q(delta_timestamp, s->st->time_base,
> AV_TIME_BASE_Q);
> +
> +prft->wallclock = rtcp_time + delta_time;
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]lavc/mjpegdec: Decode format 211121 as YUV 4:4:4
Am Di., 23. März 2021 um 21:00 Uhr schrieb Michael Niedermayer : > > On Sun, Mar 21, 2021 at 01:39:28AM +0100, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch fixes ticket #8930 for me. > > > > Please comment, Carl Eugen > > > mjpegdec.c |1 + > > 1 file changed, 1 insertion(+) > > 092c45ecc5789ce34c9f905ce55d7c573f39fce5 > > 0001-lavc-mjpegdec-Decode-format-211121-as-YUV-4-4-4.patch > > From f032f8963d3da6a074f626e6c97c2c95d3918194 Mon Sep 17 00:00:00 2001 > > From: Carl Eugen Hoyos > > Date: Sun, 21 Mar 2021 01:36:32 +0100 > > Subject: [PATCH] lavc/mjpegdec: Decode format 211121 as YUV 4:4:4 > > > > Fixes ticket #8930. > > --- > > libavcodec/mjpegdec.c | 1 + > > 1 file changed, 1 insertion(+) > > probably ok Patch applied. Thank you, 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] Possibility to add tonemap filter to ffmpeg 3.2.7
Am Di., 23. März 2021 um 15:44 Uhr schrieb Li Jinyao : > I was working on a project with ffmpeg 3.2.7 libraries, and I need use > tonemap filter to do a HDR to SDR convert, but tonemap is not implemented > in 3.2.7. The ffmpeg libraries used by the project had been modified a lot, > added some custom business feature Where can we find the patches for the custom feature? 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] lavc/pngdec: fix exporting frame metadata after 5663301560
Am So., 21. März 2021 um 11:15 Uhr schrieb Anton Khirnov : > > Also avoid a potential race with frame threading, where a frame's > metadata could be modified concurrently with that frame being passed to > another thread. > > Fixes #8972 Ticket #8972 is definitely reproducible with versions older than 5663301560 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]lavc/aom: Force default qmax to 0 if crf was set to 0
Am So., 21. März 2021 um 02:04 Uhr schrieb James Almer : > > On 3/20/2021 3:30 PM, Carl Eugen Hoyos wrote: > > Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer : > >> > >> On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote: > >>> Hi! > >>> > >>> Attached patch fixes lossless aom encoding in some cases for me, it is > >>> still possible to force lossy encoding with crf == 0 and qmax > 0. > >>> > >>> Please comment, Carl Eugen > >> > >> > >>> From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001 > >>> From: Carl Eugen Hoyos > >>> Date: Sat, 20 Mar 2021 18:47:52 +0100 > >>> Subject: [PATCH] lavc/aom: Force default qmax to 0 if crf was set to 0. > >> > >> libaomenc, not just "aom". > > > > I hope "aomenc" is ok. > > > > New patch attached. > > > > Thank you for the review, Carl Eugen > > Should be ok. Pushed. Thank you, 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] avcodec/hevc_cabac: cabac_init_state, do not use magic number which not listed on the spec
Am So., 21. März 2021 um 06:13 Uhr schrieb Nuo Mi : > > Magic number 124 and ^= are not listed on the spec. > Strictly following the spec will make a reader's life much easier. See (9-6) > for details But FFmpeg is not providing a reference application for the reader, this is software actually used by real people (both as a library in other projects and in the ffmpeg application). Afaict, the question is if the hevc cabac reader is faster or slower with your patch. It looks to me as if you are replacing one condition with two conditions. 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]lavc/mjpegdec: Decode format 211121 as YUV 4:4:4
Hi! Attached patch fixes ticket #8930 for me. Please comment, Carl Eugen From f032f8963d3da6a074f626e6c97c2c95d3918194 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 21 Mar 2021 01:36:32 +0100 Subject: [PATCH] lavc/mjpegdec: Decode format 211121 as YUV 4:4:4 Fixes ticket #8930. --- libavcodec/mjpegdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index 20f310fd70..5583d2aa35 100644 --- a/libavcodec/mjpegdec.c +++ b/libavcodec/mjpegdec.c @@ -560,6 +560,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s) case 0x12121100: case 0x22122100: case 0x21211100: +case 0x21112100: case 0x22211200: case 0x1100: case 0x22112200: -- 2.30.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]lavf/swfdec: Allow decoding Nellymoser in swf
Am Di., 16. März 2021 um 21:16 Uhr schrieb Carl Eugen Hoyos : > apart from the existing code and the sample files in ticket #9153, > Nellymoser in swf is apparently supported by Flash binaries if I read > the existing exploit correctly. Patch applied, 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]lavc/aom: Force default qmax to 0 if crf was set to 0
Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer :
>
> On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes lossless aom encoding in some cases for me, it is
> > still possible to force lossy encoding with crf == 0 and qmax > 0.
> >
> > Please comment, Carl Eugen
>
>
> > From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Sat, 20 Mar 2021 18:47:52 +0100
> > Subject: [PATCH] lavc/aom: Force default qmax to 0 if crf was set to 0.
>
> libaomenc, not just "aom".
I hope "aomenc" is ok.
New patch attached.
Thank you for the review, Carl Eugen
From 0c77fe4c284c03f55c95ba05757afb3407ce2ff4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 20 Mar 2021 19:27:48 +0100
Subject: [PATCH] lavc/aomenc: Force default qmax of 0 if crf was set to 0.
Fixes lossless encoding.
---
libavcodec/libaomenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 2c3c3eb185..fcf75e835d 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -654,8 +654,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
if (avctx->qmin >= 0)
enccfg.rc_min_quantizer = avctx->qmin;
-if (avctx->qmax >= 0)
+if (avctx->qmax >= 0) {
enccfg.rc_max_quantizer = avctx->qmax;
+} else if (!ctx->crf) {
+enccfg.rc_max_quantizer = 0;
+}
if (enccfg.rc_end_usage == AOM_CQ || enccfg.rc_end_usage == AOM_Q) {
if (ctx->crf < enccfg.rc_min_quantizer || ctx->crf > enccfg.rc_max_quantizer) {
--
2.30.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]lavc/aom: Force default qmax to 0 if crf was set to 0
Hi!
Attached patch fixes lossless aom encoding in some cases for me, it is
still possible to force lossy encoding with crf == 0 and qmax > 0.
Please comment, Carl Eugen
From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 20 Mar 2021 18:47:52 +0100
Subject: [PATCH] lavc/aom: Force default qmax to 0 if crf was set to 0.
Fixes lossless encoding.
---
libavcodec/libaomenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 2c3c3eb185..a8f0420230 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -640,6 +640,8 @@ static av_cold int aom_init(AVCodecContext *avctx,
if (!avctx->bit_rate)
enccfg.rc_end_usage = AOM_Q;
}
+if (!ctx->crf && avctx->qmax == -1)
+avctx->qmax = 0;
if (avctx->bit_rate) {
enccfg.rc_target_bitrate = av_rescale_rnd(avctx->bit_rate, 1, 1000,
--
2.30.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]lavf/swfdec: Allow decoding Nellymoser in swf
Hi,
apart from the existing code and the sample files in ticket #9153,
Nellymoser in swf is apparently supported by Flash binaries if I read
the existing exploit correctly.
Please comment, Carl Eugen
From 3d1a744ce548fab6f3ae1b8f7f867a80452637b7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 16 Mar 2021 21:11:45 +0100
Subject: [PATCH] lavf/swfdec: Allow decoding Nellymoser in swf.
Such files exist in the wild, see ticket #9153.
---
libavformat/swfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
index 9416187803..60c02cca12 100644
--- a/libavformat/swfdec.c
+++ b/libavformat/swfdec.c
@@ -52,7 +52,7 @@ static const AVCodecTag swf_audio_codec_tags[] = {
{ AV_CODEC_ID_ADPCM_SWF, 0x01 },
{ AV_CODEC_ID_MP3,0x02 },
{ AV_CODEC_ID_PCM_S16LE, 0x03 },
-// { AV_CODEC_ID_NELLYMOSER, 0x06 },
+{ AV_CODEC_ID_NELLYMOSER, 0x06 },
{ AV_CODEC_ID_NONE, 0 },
};
--
2.30.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] Custom allocation functions
Am Fr., 5. März 2021 um 15:45 Uhr schrieb Martijn Otto : > I have made some changes to get custom allocation functions in ffmpeg. > This is useful to me, as the software I work with easily runs into > congestion on memory allocations in certain cases. I thought the dynamic linker allows you to replace (allocation) functions, no? > I hope it is useful to others as well. It would be nice if this could > be part of ffmpeg proper. You cannot store the functions pointers globally. 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] configure: Fix bashism in openal check. (was: [PATCH] Bugfix for #9135)
Am Mi., 3. März 2021 um 00:01 Uhr schrieb Peter White : > Please see the attachment. I'll push this if there are no objections. 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]lavf/sga: Fix several format specifiers
Am Do., 4. März 2021 um 22:23 Uhr schrieb Moritz Barsnick : > > On Thu, Mar 04, 2021 at 20:37:26 +0100, Carl Eugen Hoyos wrote: > > attached patch fixes a few warnings when compiling for 32bit. > > > av_log(s, AV_LOG_DEBUG, "START %s\n", where); > > -av_log(s, AV_LOG_DEBUG, "pos: %lX\n", avio_tell(s->pb)); > > +av_log(s, AV_LOG_DEBUG, "pos: %"PRIX64"\n", avio_tell(s->pb)); > > #include It is included through common.h - do we add it to every C file that would need it if common.h were not included? 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]lavf/sga: Fix several format specifiers
Hi, attached patch fixes a few warnings when compiling for 32bit. Please comment, Carl Eugen From c9941035b19d52fe8d8cbe2183fec823ea7a59d4 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 4 Mar 2021 20:34:36 +0100 Subject: [PATCH] lavf/sga: Silence several warnings because of wrong format specifiers. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes warnings like: warning: format ‘%lX’ expects argument of type ‘long unsigned int’, but argument n has type ‘uint64_t’ --- libavformat/sga.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/sga.c b/libavformat/sga.c index 20da423ebf..e7a41e91ea 100644 --- a/libavformat/sga.c +++ b/libavformat/sga.c @@ -232,11 +232,11 @@ static void print_stats(AVFormatContext *s, const char *where) SGADemuxContext *sga = s->priv_data; av_log(s, AV_LOG_DEBUG, "START %s\n", where); -av_log(s, AV_LOG_DEBUG, "pos: %lX\n", avio_tell(s->pb)); +av_log(s, AV_LOG_DEBUG, "pos: %"PRIX64"\n", avio_tell(s->pb)); av_log(s, AV_LOG_DEBUG, "idx: %X\n", sga->idx); av_log(s, AV_LOG_DEBUG, "packet_type: %X\n", sga->packet_type); av_log(s, AV_LOG_DEBUG, "payload_size: %X\n", sga->payload_size); -av_log(s, AV_LOG_DEBUG, "SECTOR: %016lX\n", AV_RB64(sga->sector)); +av_log(s, AV_LOG_DEBUG, "SECTOR: %016"PRIX64"\n", AV_RB64(sga->sector)); av_log(s, AV_LOG_DEBUG, "stream: %X\n", sga->sector[1]); av_log(s, AV_LOG_DEBUG, "END %s\n", where); } @@ -300,7 +300,7 @@ static int sga_video_packet(AVFormatContext *s, AVPacket *pkt) sga->flags = 0; update_type_size(s); -av_log(s, AV_LOG_DEBUG, "VIDEO PACKET: %d:%016lX i:%X\n", pkt->size, AV_RB64(sga->sector), sga->idx); +av_log(s, AV_LOG_DEBUG, "VIDEO PACKET: %d:%016"PRIX64" i:%X\n", pkt->size, AV_RB64(sga->sector), sga->idx); return 0; } @@ -347,7 +347,7 @@ static int sga_audio_packet(AVFormatContext *s, AVPacket *pkt) sga->flags = 0; update_type_size(s); -av_log(s, AV_LOG_DEBUG, "AUDIO PACKET: %d:%016lX i:%X\n", pkt->size, AV_RB64(sga->sector), sga->idx); +av_log(s, AV_LOG_DEBUG, "AUDIO PACKET: %d:%016"PRIX64" i:%X\n", pkt->size, AV_RB64(sga->sector), sga->idx); return 0; } -- 2.29.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] [FFmpeg-cvslog] avcodec/avrndec: remove max_lowres value
Am Sa., 27. Feb. 2021 um 15:25 Uhr schrieb James Almer : > > ffmpeg | branch: master | James Almer | Sat Feb 27 > 00:12:18 2021 -0300| [0c902a61471a2f45e1c7159bd77146d2b499abb3] | committer: > James Almer > > avcodec/avrndec: remove max_lowres value > > The decoder does not support lowres since 9e4225cf7f. Wouldn't the correct resolution have been to revert 9e4225cf7f or do I misunderstand the process? 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 2/3] avcodec: add SGA Video decoder
Am Fr., 26. Feb. 2021 um 12:55 Uhr schrieb Paul B Mahol :
> +static int decode_palette(GetByteContext *gb, uint32_t *pal)
> +{
> +GetBitContext gbit;
> +
> +if (bytestream2_get_bytes_left(gb) < 18)
> +return AVERROR_INVALIDDATA;
> +
> +memset(pal, 0, 16 * sizeof(*pal));
> +init_get_bits8(, gb->buffer, 18);
> +
> +for (int RGBIndex = 0; RGBIndex < 3; RGBIndex++) {
> +for (int index = 0; index < 16; index++) {
> +unsigned color = get_bits1() << RGBIndex;
> +pal[15 - index] |= color << (5 + 16);
> +}
> +}
> +
> +for (int RGBIndex = 0; RGBIndex < 3; RGBIndex++) {
> +for (int index = 0; index < 16; index++) {
> +unsigned color = get_bits1() << RGBIndex;
> +pal[15 - index] |= color << (5 + 8);
> +}
> +}
> +
> +for (int RGBIndex = 0; RGBIndex < 3; RGBIndex++) {
> +for (int index = 0; index < 16; index++) {
> +unsigned color = get_bits1() << RGBIndex;
> +pal[15 - index] |= color << (5 + 0);
> +}
> +}
> +
> +for (int index = 0; index < 16; index++)
> +pal[index] = (0xFFU << 24) | pal[index] | (pal[index] >> 3);
Looks much better than what I suggested but please
also fill the last two bits of each component.
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".
