[FFmpeg-devel] [PATCH] ffmpeg: fix increment of sync_opts

The encoder time base could been overridden by the command line argument and may not always be 1/ost->frame_rate. --- fftools/ffmpeg.c | 2 +- tests/fate/ffmpeg.mak| 5 + tests/ref/fate/enc_time_base-vfr | 25 + 3 files changed, 31

[FFmpeg-devel] [PATCH v2 2/2] avcodec/hevcdec: detect non-conformant missing refs

For cases which prefer rejecting broken bitstreams. --- libavcodec/hevc_refs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c index 84a21991c7..9f8b6022c4 100644 --- a/libavcodec/hevc_refs.c +++ b/libavcodec/hevc_refs.c @@ -439,6 +439,8 @@

[FFmpeg-devel] [PATCH v2 1/2] avcodec/hevcdec: skip generating missing refs in foll lists

Missing refs shall be generated only when they are actually used. Without this change a sequence of a BLA picture and an associated RASL picture would still be decoded without complaints if the RASL picture is mislabeled as RADL. --- libavcodec/hevc_refs.c | 19 +-- 1 file

Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdec: detect non-conformant missing refs

On 4/5/22 17:10, Anton Khirnov wrote: > Quoting Xiaolei Yu (2022-04-05 08:49:24) >> >> For cases which prefer rejecting broken bitstreams. >> --- >> libavcodec/hevc_refs.c | 15 --- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> &

[FFmpeg-devel] [PATCH] libavcodec/hevcdec: detect non-conformant missing refs

For cases which prefer rejecting broken bitstreams. --- libavcodec/hevc_refs.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c index fe18ca2b1d..7ea70e301b 100644 --- a/libavcodec/hevc_refs.c +++

[FFmpeg-devel] [PATCH v2 1/1] libavcodec/h264: always set video signal type fields

The color range and color description fields when not present shall be inferred to be LIMITED and UNSPECIFIED respectively. Relevant info from containers will always be overriden. This is consistent with the behavior of the hevc decoder. --- libavcodec/h264_ps.c | 4 +++-

[FFmpeg-devel] [PATCH v2 0/1] libavcodec/h264: always set video signal type fields

Fixed fate tests Xiaolei Yu (1): libavcodec/h264: always set video signal type fields libavcodec/h264_ps.c | 4 +++- libavcodec/h264_slice.c | 18 +++--- tests/ref/fate/flv-demux | 2 +- tests/ref/fate/h264

[FFmpeg-devel] [PATCH] libavcodec/h264: always set color description fields

Color description fields shall be inferred to be UNSPECIFIED if not present. --- libavcodec/h264_ps.c| 4 +++- libavcodec/h264_slice.c | 18 +++--- 2 files changed, 10 insertions(+), 12 deletions(-) diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c index

[FFmpeg-devel] [PATCH] libavformat/flvdec: add HEVC demuxing support

Explicitly supply an HEVC codec id to enable this feature. --- libavformat/flv.h| 1 + libavformat/flvdec.c | 21 ++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/libavformat/flv.h b/libavformat/flv.h index 3571b90279..7cb1b72b4c 100644 ---

Re: [FFmpeg-devel] [PATCH 14/14] videotoolbox: remove opengl compatibility attribute

On 12/16/2017 04:19 PM, Wang Bin wrote: > 2017-12-16 15:33 GMT+08:00 Xiaolei Yu <dreifachst...@gmail.com>: >> On 12/16/2017 02:07 PM, Wang Bin wrote: >>> 2017-12-16 2:52 GMT+08:00 wm4 <nfx...@googlemail.com>: >>>> On Fri, 15 Dec 2017 15:02:44 +0800 >

Re: [FFmpeg-devel] [PATCH 14/14] videotoolbox: remove opengl compatibility attribute

On 12/16/2017 02:07 PM, Wang Bin wrote: > 2017-12-16 2:52 GMT+08:00 wm4 : >> On Fri, 15 Dec 2017 15:02:44 +0800 >> wbse...@gmail.com wrote: >> >>> From: wang-bin >>> >>> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl >>>

Re: [FFmpeg-devel] Is it legal to modify h264 sps for cropping

On 04/21/2017 10:15 PM, Hendrik Leppkes wrote: > On Fri, Apr 21, 2017 at 3:34 PM, Xiaolei Yu <dreifachst...@gmail.com> wrote: >> Some android devices do not properly align the input surface of MediaCodec >> (Nexus 4, Galxy Note 2) and >> we are forced to specify a

[FFmpeg-devel] Is it legal to modify h264 sps for cropping

Some android devices do not properly align the input surface of MediaCodec (Nexus 4, Galxy Note 2) and we are forced to specify a multiple of 16 as the video width. A possible workaround is to insert the desired crop into the output sps, but I am not sure if it is legal.

[FFmpeg-devel] [PATCH v2] avcodec: fix vc1dsp dependencies

--- libavcodec/aarch64/Makefile | 2 +- libavcodec/aarch64/h264cmc_neon.S | 2 +- libavcodec/arm/h264cmc_neon.S | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index 36d9d34..c3df887 100644 ---

[FFmpeg-devel] avcodec: fix vc1dsp dependencies

--- libavcodec/aarch64/Makefile | 2 +- libavcodec/aarch64/h264cmc_neon.S | 2 +- libavcodec/arm/h264cmc_neon.S | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index 36d9d34..c3df887 100644 ---

[FFmpeg-devel] [RFC] configure: test inter-procedural constant propagation for armv6 inline asm

There are two routines in avutil/arm/intmath that fail to compile without IPCP. This patch tries to detect if such optimizations are present. I am unable to find a way to test it without using inline asm, so the check flag is bound to each arch extension. I also want optflags checks to be

[FFmpeg-devel] [PATCH] swscale/arm: re-enable neon rgbx to nv12 routines

Commit '842b8f4ba2e79b9c004a67f6fdb3d5c5d05805d3' fixed clang/iphone build but failed on some versions of cygwin. It has now been verified to work on both platforms. --- libswscale/arm/Makefile | 4 ++-- libswscale/arm/swscale_unscaled.c | 4 2 files changed, 2 insertions(+), 6

Re: [FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled

On 02/17/2016 03:19 AM, Hendrik Leppkes wrote: > On Tue, Feb 16, 2016 at 4:00 PM, Yu Xiaolei <dreifachst...@gmail.com> wrote: >> On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer <mich...@niedermayer.cc >>> wrote: >> >>> On Tue, Feb 16, 2016 at 02:40:

Re: [FFmpeg-devel] [PATCH 1/5] libavutil: Some VAAPI infrastructure

On 01/18/2016 03:52 AM, Mark Thompson wrote: > On 17/01/16 19:46, Mark Thompson wrote: >> On 17/01/16 18:46, wm4 wrote: >>> >>> There are two issues: >>> 1. global state in libav* which is not synchronized >>> 2. thread-safety within >>> >>> 1. is is completely unacceptable, because it can trigger