On Thu, Dec 30, 2021 at 03:24:28PM +0800, zourenyi wrote:
> since there is only debug log 'no picture ooo' when droping a picture,
> I spent much time to troubleshooting a wrong sps 'num_reorder_frames' param
> changed by webrtc's 'ParseAndRewriteSps',
> FFmpeg keeped silence about this error, so
This will lost the droped picture's infomation, lead to hard to debug when this
error happens.
zozobr...@163.com
From: lance.lmwang
Date: 2021-12-30 17:00
To: ffmpeg-devel
Subject: Re: [FFmpeg-devel] [PATCH v6] avcodec/h264_slice: add warning log when
droping picture at 'h264
Quoting Andreas Rheinhardt (2021-12-15 13:35:32)
> libavcodec currently exports four avpriv symbols that deal with
> PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
> avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
> lists of PixelFormatTags, the former retu
Quoting Andreas Rheinhardt (2021-12-15 13:35:34)
> It is small (16 B) and therefore the overhead of exporting it more
> than outweighs the size savings from not having duplicated symbols:
> When the symbol is no longer avpriv, one saves twice the size of
> the string containing the symbols name (2x
On Thu, Dec 30, 2021 at 05:19:09PM +0800, zozobr...@163.com wrote:
> This will lost the droped picture's infomation, lead to hard to debug when
> this error happens.
Please stop top posting.
As warning message, I think it's enough to print out "no picture ooo", if you
want
to debug, please use g
Quoting sfan5 (2021-12-29 23:12:37)
> On 29.12.2021 at 21:02 Anton Khirnov wrote:
> > Quoting sfan5 (2021-12-13 21:55:41)
> >> If ca_file was set, setting tls_verify=0 would not actually disable
> >> verification.
> >>
> >> From 2677353187c4e3c20b50a3f9aab53130e3ead99b Mon Sep 17 00:00:00 2001
> >
On 30/12/2021 00:29, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Mark
Thompson
Sent: Thursday, December 30, 2021 12:04 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a
hwdevice, search for existing devic
Quoting Yu Yang (2021-12-15 03:17:02)
> From: Yu Yang
>
> '*src' and '*avctx' point to the same memory. It is enough to keep one of
> them.
>
> Signed-off-by: Yu Yang
> ---
> libavcodec/pthread_frame.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
Looks good, will pus
On Thu, Dec 30, 2021 at 10:07:21AM +0530, Gyan Doshi wrote:
>
>
> On 2021-12-29 11:38 pm, Michael Niedermayer wrote:
> > On Wed, Dec 29, 2021 at 09:39:34PM +0530, Gyan Doshi wrote:
> > >
> > > On 2021-12-29 05:58 pm, Michael Niedermayer wrote:
> > > > On Tue, Dec 28, 2021 at 10:26:42PM +0530, Gy
Aborting decoding of the entire packet on a missing PPS can result in
missing the actual PPS on streams with badly ordered NALs, where the
SPS/PPS/VPS are stitched to the back of the previous frame, instead of
the beginning of the next frame.
Instead, skip the undecodable slice, and let the decode
On 12/30/2021 12:08 PM, Hendrik Leppkes wrote:
Aborting decoding of the entire packet on a missing PPS can result in
missing the actual PPS on streams with badly ordered NALs, where the
SPS/PPS/VPS are stitched to the back of the previous frame, instead of
the beginning of the next frame.
Ins
On Thu, Dec 30, 2021 at 4:13 PM James Almer wrote:
>
>
>
> On 12/30/2021 12:08 PM, Hendrik Leppkes wrote:
> > Aborting decoding of the entire packet on a missing PPS can result in
> > missing the actual PPS on streams with badly ordered NALs, where the
> > SPS/PPS/VPS are stitched to the back of t
On 12/30/2021 12:26 PM, Hendrik Leppkes wrote:
On Thu, Dec 30, 2021 at 4:13 PM James Almer wrote:
On 12/30/2021 12:08 PM, Hendrik Leppkes wrote:
Aborting decoding of the entire packet on a missing PPS can result in
missing the actual PPS on streams with badly ordered NALs, where the
SPS/
On 2021-12-30 07:46 pm, Michael Niedermayer wrote:
On Thu, Dec 30, 2021 at 10:07:21AM +0530, Gyan Doshi wrote:
On 2021-12-29 11:38 pm, Michael Niedermayer wrote:
On Wed, Dec 29, 2021 at 09:39:34PM +0530, Gyan Doshi wrote:
On 2021-12-29 05:58 pm, Michael Niedermayer wrote:
On Tue, Dec 28,
On Mon, Dec 13, 2021 at 10:56 PM sfan5 wrote:
>
> This value is later passed to MediaCodec and checked at decoder init.
> Notably decoding of 10-bit streams before this commit would "work" without
> returning errors but only return garbage output (on most Android devices).
Applied as b32b32ba89b5
On Mon, Dec 13, 2021 at 10:55 PM sfan5 wrote:
>
> If ca_file was set, setting tls_verify=0 would not actually disable
> verification.
Applied to master as 65197e9c98f46a79dd02c993cfcb0e70f65878cf .
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Thu, Dec 30, 2021 at 10:39:05PM +0530, Gyan Doshi wrote:
>
>
> On 2021-12-30 07:46 pm, Michael Niedermayer wrote:
> > On Thu, Dec 30, 2021 at 10:07:21AM +0530, Gyan Doshi wrote:
> > >
> > > On 2021-12-29 11:38 pm, Michael Niedermayer wrote:
> > > > On Wed, Dec 29, 2021 at 09:39:34PM +0530, Gy
On 2021-12-30 11:25 pm, Michael Niedermayer wrote:
On Thu, Dec 30, 2021 at 10:39:05PM +0530, Gyan Doshi wrote:
On 2021-12-30 07:46 pm, Michael Niedermayer wrote:
On Thu, Dec 30, 2021 at 10:07:21AM +0530, Gyan Doshi wrote:
On 2021-12-29 11:38 pm, Michael Niedermayer wrote:
On Wed, Dec 29,
This commit adds support to libavcodec to read and parse
encoded Jpeg XL images. Jpeg XL is intended to be an
extended-life replacement to legacy mjpeg.
---
MAINTAINERS| 2 +
libavcodec/Makefile| 1 +
libavcodec/codec_desc.c| 9 +
libavcodec/codec_id.h | 1
This commit adds decoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
MAINTAINERS | 1 +
configure | 5 +
doc/general_contents.texi | 7 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/libjxl.c
This commit adds encoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
configure | 3 +-
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libjxlenc.c | 383 +
4 files changed, 387 inse
This commit adds support to libavformat for muxing
and demuxing Jpeg XL images as image2 streams.
---
libavformat/allformats.c | 1 +
libavformat/img2.c | 1 +
libavformat/img2dec.c| 19 +++
libavformat/img2enc.c| 6 +++---
libavformat/mov.c| 1 +
libavfor
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Thursday, December 30, 2021 12:22 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext: When deriving a
> hwdevice, search for existing device in both directions
>
On Thu, Dec 23, 2021 at 10:15:26PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2147483542 + 128 cannot be represented in
> type 'int'
> Fixes:
> 42812/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-6344057861832704
>
> Found-by: continuous fuzzing process
>
On Thu, Dec 23, 2021 at 10:15:25PM +0100, Michael Niedermayer wrote:
> We do not support this as we multiply by 1000
> Fixes: signed integer overflow: -45318575073853696 * 1000 cannot be
> represented in type 'long'
> Fixes:
> 42804/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-463032
On Thu, Dec 23, 2021 at 10:15:23PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 42667/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TARGA_fuzzer-5619236075077632
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signe
On Sun, Dec 26, 2021 at 02:34:25PM +0100, Michael Niedermayer wrote:
> On Sun, Dec 26, 2021 at 09:50:28AM +0100, Paul B Mahol wrote:
> > Please confirm you are not breaking tile files in any way.
>
> Ive tested both strip and tile dng/tiff files
>
> Thats what i tested with:
>
> 1_1.1.1.dpx
> 1
Hi,
On Fri, Dec 24, 2021 at 12:54 PM Timo Rothenpieler
wrote:
> > On Wed, Jun 30, 2021 at 6:55 AM Moritz Barsnick wrote:
> >>
> >> Hi,
> >>
> >>> -enabled libvmaf && require_pkg_config libvmaf "libvmaf >=
> >>> 1.5.2" libvmaf.h compute_vmaf
> >>> +enabled libvmaf && require_
Hi,
On Sat, Dec 25, 2021 at 1:24 AM Paul B Mahol wrote:
>
> On Fri, Dec 24, 2021 at 9:52 PM Kyle Swanson wrote:
>
> > Hi,
> >
> > Never followed through on this vf_libvmaf patch from last June, and
> > I've had several people asking about its status lately. Rebased patch
> > attached. It's been
Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.
Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
Signed-off
These candidate formats are likely already decoded in floating point
internally anyway, so request float output so that it's also possible
to clip or peak level as necessary.
Signed-off-by: Christopher Snowhill
---
libavcodec/audiotoolboxdec.c | 36
1 file ch
Ping. Will apply (with the minor version bump I forgot) in a few days.
On 28/12/21 15:37, Zane van Iperen wrote:
A simple, interleaved variant, but with initial state and
extra, uncompressed samples. Found in Ubisoft soundbanks from
early-2000's games (Splinter Cell, RS3, etc.)
Signed-off-by: Z
32 matches
Mail list logo
