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 insertio
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 @@ sta
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 changed
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(-)
>>
&
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
+++ b/libavcodec/he
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 +++-
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
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 e21c2b56ac..164e6e
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
--- a/libavformat/f
On 12/16/2017 04:19 PM, Wang Bin wrote:
> 2017-12-16 15:33 GMT+08:00 Xiaolei Yu :
>> 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:
>>>>
>>
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
>>> texture, using CGLTexImageIOSurface2D for macOS
On 10/16/2017 07:36 PM, wm4 wrote:
> On Mon, 16 Oct 2017 19:28:27 +0800
> Xiaolei Yu wrote:
>
>> On 10/03/2017 09:15 PM, wm4 wrote:
>>> From: Anton Khirnov
>>>
>>> Use the AVFrame.opaque_ref field. The original user's opaque_ref is
>>>
On 10/03/2017 09:15 PM, wm4 wrote:
> From: Anton Khirnov
>
> Use the AVFrame.opaque_ref field. The original user's opaque_ref is
> wrapped in the lavc struct and then unwrapped before the frame is
> returned to the caller.
>
> This new struct will be useful in the following commits.
>
How abou
On 04/21/2017 10:15 PM, Hendrik Leppkes wrote:
> On Fri, Apr 21, 2017 at 3:34 PM, Xiaolei Yu 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 multiple of 16 as the vi
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.
___
---
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
--- a/libavcodec
---
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
--- a/libavcodec/
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 performe
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 dele
On 02/17/2016 03:19 AM, Hendrik Leppkes wrote:
> On Tue, Feb 16, 2016 at 4:00 PM, Yu Xiaolei wrote:
>> On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer >> wrote:
>>
>>> On Tue, Feb 16, 2016 at 02:40:10PM +0800, Xiaolei Yu wrote:
>>>> Current intmat
Current intmath routines for arm require inter-procedure constant propagation
and fail to compile when optimizations are disabled.
---
configure | 1 +
libavutil/intmath.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/configure b/configure
index 2148f11..70e0161 100755
--- a/con
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
22 matches
Mail list logo