On Tue, Jun 22, 2021 at 1:47 PM James Zern
wrote:
> On Thu, Jun 17, 2021 at 10:21 PM Mohammad Izadi
> wrote:
> >
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to packet side da
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Wed, 2021-06-23 at 16:41 +, Soft Works wrote:
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Haihao Xiang
> Sent: Mittwoch, 23. Juni 2021 05:04
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX
>
On 6/23/2021 1:12 PM, Derek Buitenhuis wrote:
These bits are reserved in earlie versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-of
On 6/22/2021 7:56 AM, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libx264.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 36fdb56..d0608e7 100644
--- a/libavcod
On Wed, 23 Jun 2021, Gyan Doshi wrote:
On 2021-06-23 06:11, Marton Balint wrote:
The early return caused isses for the "add" mode (got fixed in
c95dfe5cce98cde3e7fb14fbd04b3897f3927cec) and the "select" mode needs a
similar
fix. It is probably better to fully remove the check, since all
On 18.06.2021 14:50, Timo Rothenpieler wrote:
> [...]
>
> +@item detected(kind)
> +Evaluates the metadata added to frames by various detection filters.
> +Returns -1 if the respective filter has detected what it was looking
for,
> +0 otherwise.
> +
> +Possible values for the @var{kind} parameter
These bits are reserved in earlie versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis
---
e.g. x264 wrote thes
-Original Message-
From: ffmpeg-devel On Behalf Of Haihao Xiang
Sent: Mittwoch, 23. Juni 2021 05:04
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang
Subject: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX method
This allows user set hw_device_ctx instead of hw_frames_ctx
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
doc/protocols.texi | 30 +++
libavformat/Makefile| 1 +
libavformat/concat.c| 111
libavformat/protocols.c | 1 +
4 files changed, 143 insertions(+)
diff --git a/doc/prot
10 matches
Mail list logo
