Hi,
On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
This also changed the handling of unknown-sized elements: They are now
ended whenever an element not known to be allowed in them is
encountered. If we are already on level 1 and encounter an element not
known to be allowed in an unknown-sized
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
By default, the data_offset member of the AVFormatInternal of the
AVFormatContext associated with the MatroskaDemuxContext has not been
initialized explicitly by any Matroska-specific function, so that it was
initialized by default
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
ebml_read_num had a number of flaws:
1. The check for read errors/EOF was totally wrong. E.g. an EBML number
beginning with the invalid 0x00 would be considered a read error,
although it is just invalid data.
2. The check for read
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
Before this commit, the Matroska muxer would read a block when required
to do so, parse the block, create and return the necessary AVPackets and
yet keep the blocks (in a dynamically allocated list), although they
aren't used at al
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
The earlier code had three flaws:
1. The case of an unknown-sized element inside a finite-sized element
(which is against the specifications) was not caught.
2. The error message wasn't helpful: It compared the length of the chil
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
The earlier code set the level to zero upon seeking and after a
discontinuity although in both cases parsing (re)starts at a level 1
element.
Also set the segment's length to unkown if an error occured in order not
to drop any val
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any finite-sized levels that end
there as well) and info
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
array (with different semantics), one can reduce the duplication of the
other values.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 13
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This is important as unknown-sized elements end upon encountering an
unknown EBML ID.
That's the problem with this approach. Noone is allowed to use their own
custom tags (RAWCooked for example) and the unknown length feature. Y
> On April 7, 2019 at 11:24 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> ebml_read_num had a number of flaws:
> >>
> >> 1. The check for read e
> On April 7, 2019 at 11:38 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> Before this commit, the Matroska muxer would read a block when required
> >> to do
> On April 7, 2019 at 12:54 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> The earlier code had three flaws:
> >>
> >> 1. The case of an unk
> On April 7, 2019 at 8:56 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Hello,
>
> thanks for taking the time to review this. Much appreciated.
>
> Steve Lhomme:
> > Hi,
> >
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
> &g
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
The same problem may exist with H264 alter
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
The same problem may exist with H264 alter
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
libavcodec/h264_slice.c | 12 ++--
If the decoder provides its own buffers it might not be able to release its
buffers once it has been closed. (this is the case with dav1d).
---
fftools/ffmpeg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index da4259a9a8..faf62475a2 100644
--- a/fftools
On 16/10/2018 16:59, Hendrik Leppkes wrote:
On Tue, Oct 16, 2018 at 4:02 PM James Almer wrote:
On 10/16/2018 9:16 AM, Steve Lhomme wrote:
If the decoder provides its own buffers it might not be able to release its
buffers once it has been closed. (this is the case with dav1d).
---
fftools
On 16/10/2018 18:04, James Almer wrote:
On 10/16/2018 12:34 PM, Steve Lhomme wrote:
On 16/10/2018 16:59, Hendrik Leppkes wrote:
On Tue, Oct 16, 2018 at 4:02 PM James Almer wrote:
On 10/16/2018 9:16 AM, Steve Lhomme wrote:
If the decoder provides its own buffers it might not be able to
On 17/10/2018 09:43, Steve Lhomme wrote:
On 16/10/2018 18:04, James Almer wrote:
On 10/16/2018 12:34 PM, Steve Lhomme wrote:
On 16/10/2018 16:59, Hendrik Leppkes wrote:
On Tue, Oct 16, 2018 at 4:02 PM James Almer wrote:
On 10/16/2018 9:16 AM, Steve Lhomme wrote:
If the decoder provides its
---
libavcodec/dxva2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..6add893f3e 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -840,7 +840,7 @@ int ff_dxva2_commit_buffer(AVCodecContext *avctx,
And 4:2:0 12 bits as well.
---
libavcodec/hevcdec.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 8f1c162ace..04496a002b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -420,6 +420,13 @@ static enum AVPixelForm
---
libavcodec/hevcdec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 04496a002b..4c1650c416 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -432,6 +432,16 @@ static enum AVPixelFormat get_format(HEVCContext *s, c
Mimick the existing structure and add the extra fields from the Range Extension
in a wrapping structure.
The FF_DXVA2_WORKAROUND_HEVC_REXT is set by the decoder user to signal the
selected decoder is expecting this extended structure rather than the default
one.
---
libavcodec/d3d11va.h| 1 +
> On March 13, 2020 3:46 PM Hendrik Leppkes wrote:
>
>
> On Fri, Mar 13, 2020 at 11:25 AM Steve Lhomme wrote:
> >
> > Mimick the existing structure and add the extra fields from the Range
> > Extension
> > in a wrapping structure.
> >
> >
On 2020-03-15 13:05, Hendrik Leppkes wrote:
On Sun, Mar 15, 2020 at 8:12 AM Steve Lhomme wrote:
Where is this struct specified? I don't see it in the latest released
Windows SDK.
It is not. It is reversed engineered from the existing structure and wild
guessing based on the HEVC
From: Steve Lhomme
---
libavformat/matroska.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index e177cd027f..5520e9ce8f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -284,18 +284,18
From: Steve Lhomme
---
libavformat/matroska.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 86968a8de1..9e33e51c94 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -271,6 +271,7 @@ typedef enum
From: Steve Lhomme
Always use a comma at the end, order elements by value.
---
libavformat/matroska.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 9e33e51c94..e177cd027f 100644
--- a/libavformat/matroska.h
+++ b
From: Steve Lhomme
The XSLT scripts produces a similar file to this one, minus some spacing
differences.
No value added/removed.
---
libavformat/matroska_ids.h | 70 +++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/libavformat
From: Steve Lhomme
It's an ASCII string, not a UTF-8 string.
---
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4d7fdab99f..383869bced 100644
--- a/libavformat/matroskadec.c
From: Steve Lhomme
According grouped with their parent's elements.
No value added/removed.
---
libavformat/matroska_ids.h | 78 ++
1 file changed, 54 insertions(+), 24 deletions(-)
diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h
From: Steve Lhomme
By default a tag is the default one.
---
libavformat/matroskadec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 383869bced..3640dd76d9 100644
--- a/libavformat/matroskadec.c
+++ b
From: Steve Lhomme
So the file can be generated from the EBML Schema.
No functional change.
---
libavformat/matroska.h | 302 +-
libavformat/matroska_ids.h | 327 +
2 files changed, 328 insertions(+), 301 deletions
From: Steve Lhomme
So they are sorted by their EBML path, in reverse order so we don't extra
declarations.
No functional changes.
---
libavformat/matroskasem.c | 256 +++---
1 file changed, 128 insertions(+), 128 deletions(-)
diff --git a/libavf
From: Steve Lhomme
All integers should be initialized to 0. Make the tables more consistent by
only setting non zero values.
---
libavformat/matroskadec.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat
From: Steve Lhomme
No functional value/added removed, only more regular spacing.
---
libavformat/matroska_ids.h | 290 +++---
libavformat/matroskasem.c | 356 +++--
2 files changed, 326 insertions(+), 320 deletions(-)
diff --git a
From: Steve Lhomme
So the file can be generated from the Matroska Schema.
The EbmlSyntax structures are not shared between files.
matroska_segments and matroska_cluster_enter also have their size predefined.
No functional changes.
---
libavformat/Makefile | 2 +-
libavformat
From: Steve Lhomme
So it's easier to match with the XSLT ordering which has limited possibilities
(15 max criteria for all the syntax tables).
No functional changes.
---
libavformat/matroskasem.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --
> On 22 Mar 2020, at 11:34, Carl Eugen Hoyos wrote:
>
> Am So., 22. März 2020 um 10:02 Uhr schrieb Steve Lhomme :
>>
>> From: Steve Lhomme
>>
>> Usage:
>> xsltproc -o matroska_ids.h schema_2_lavf_h.xsl ebml_matroska.xml
>> xsltproc -o matroskase
On 2020-03-25 23:24, Andreas Rheinhardt wrote:
Steve Lhomme:
From: Steve Lhomme
Always use a comma at the end, order elements by value.
---
libavformat/matroska.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index
On 2020-03-25 3:09, Andreas Rheinhardt wrote:
Steve Lhomme:
From: Steve Lhomme
So the file can be generated from the Matroska Schema.
The EbmlSyntax structures are not shared between files.
matroska_segments and matroska_cluster_enter also have their size predefined.
No functional changes
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> AVChapters have an int as id field and therefore this value can appear
> <= 0. When remuxing from Matroska, this value actually contains
> the lower 32 bits of the original ChapterUID (which can be 64 bits).
>
> In order to ensure t
Wouldn't it be better to set the AVLFG in the MatroskaMuxContext in mkv_init
and keep using it when needed ?
Then you can still update UIDs in the location you really need to create them.
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> This commit reuses the random seed generat
Not sure how FATE works but I suppose the pseudo-random becomes deterministic ?
In that case the size should always be the same. And if not having a fixed size
will make no difference.
If FATE can skip random parts of a file (which your patch would solve) it will
miss inconsitencies of UIDs tha
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> The Matroska muxer currently only adds CuePoints in three cases:
> a) For video keyframes. b) For the first audio frame in a new Cluster if
> in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
> files won't have
> On April 19, 2020 9:11 AM Andreas Rheinhardt
> wrote:
>
>
> Steve Lhomme:
> > Wouldn't it be better to set the AVLFG in the MatroskaMuxContext in
> > mkv_init and keep using it when needed ?
> >
> > Then you can still update UIDs in the
LGTM.
In general it would be nice if this was "automatic". In other words when
writing any element the value is automatically checked against the default
value. Maybe using a macro that would also check the default value like this
PUT_EBML_VALUE(cp, EDITIONFLAGHIDDEN, value)
doing :
if (value
Hi,
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
child_device_type argument is responsible for selection.
Usage examples: -init_hw_device qsv:hw,child_device_type=d3d11va
-init_hw_device qsv:hw,child_device_type=dxva2
Signed-off-by: Artem Galin
---
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Makes selection of d3d11va device type by default and over DirectX 9,
which is still supported but requires explicit selection.
This enables usage of non-powered/headless GPU, better HDR support.
Pool of resources is allocated
Mostly the same remarks as for 2/4 regarding the uneeded loop and
uninitialized handle_type, plus comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callbacks with
proper MediaSDK pair type support.
Extend
Comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callback with
proper MediaSDK pair type support.
Signed-off-by: Artem Galin
---
libavfilter/qsvvpp.c | 40 ++--
1 f
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local
LIBDIR = lib
INSTALL = install
SED = sed
--
2.17.1
__
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a
This is for this repo:
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
On 2019-09-12 15:17, Steve Lhomme wrote:
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4
This is for this repo:
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
On 2019-09-12 15:19, Steve Lhomme wrote:
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-sa
Ah yes, it works (TIL).
Forget about this patch.
On 2019-09-12 16:26, Timo Rothenpieler wrote:
On 12/09/2019 15:17, Steve Lhomme wrote:
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b
On 2019-09-13 11:56, Timo Rothenpieler wrote:
On 12/09/2019 15:19, Steve Lhomme wrote:
It can be useful to determine if the decoder context is the same as
the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h
The internal data should not leak to the user. It can potentially be destroyed
twice since the hwaccel uninit was also copied back to the user.
This behaviour may only be found in VLC which uses frame threading with hardware
decoding.
---
libavcodec/pthread_frame.c | 9 ++---
1 file changed,
AV_LOG_ERROR,
> > "Invalid length 0x%"PRIx64" > 0x%"PRIx64"
> > in parent\n",
> >
> > Resolves our issues. Should all other length tests be done the same
> > way?
> >
> > -
From: Steve Lhomme
---
libavformat/matroskadec.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 5aa8a105dc..0e3a6890c1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -68,6
On 23/02/2019 00:41, Dale Curtis wrote:
Unknown length has a special encoding which is not uint64_t(-1).
Signed-off-by: Dale Curtis
---
libavformat/matroskadec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
___
ffmpeg-devel
On 23/02/2019 19:37, Michael Niedermayer wrote:
On Sat, Feb 23, 2019 at 11:14:33AM +0100, Steve Lhomme wrote:
From: Steve Lhomme
---
libavformat/matroskadec.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
I think the commit message is a bit terse. This is not just a
Hi,
We have this bug in VLC with an MPEG2 file that decodes with green
bars at the top. After investigation it's because we allocate a
1920x1080 texture when it should actually need 1920x1088.
https://trac.videolan.org/vlc/ticket/17856
In software decoding it works because we adjust the
`ctx->cod
---
libavcodec/mpeg12dec.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e49167f89e..55fcac0cb2 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1291,12 +1291,11 @@ static int mpeg_decode_postin
---
libavcodec/hevc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 505249e6b5..35e9a273fa 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -328,6 +328,14 @@ static void export_stream_params(AVCodecContext *avctx,
const HEVC
These data are necessary when transmitting HDR over HDMI.
---
libavcodec/avcodec.h | 7 +++
libavcodec/avpacket.c | 1 +
libavcodec/hevc_sei.c | 15 +++
libavcodec/hevcdec.c | 22 ++
libavcodec/hevcdec.h | 5 +
libavcodec/utils.c| 1 +
libavcodec/
As found in HEVC.
I put the code in mastering_display_metadata as they usually go together in
Blu-Ray UHD sources.
---
libavutil/frame.c | 1 +
libavutil/frame.h | 6 ++
libavutil/mastering_display_metadata.c | 18
libavutil/masteri
---
libavformat/dump.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 7c811ce5d2..a8122f216b 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -343,6 +343,14 @@ static void dump_mastering_display_metadata(void *ctx,
AVPacke
On Thu, Mar 30, 2017 at 5:50 PM, James Almer wrote:
> On 3/30/2017 11:31 AM, Steve Lhomme wrote:
>> As found in HEVC.
>>
>> I put the code in mastering_display_metadata as they usually go together in
>> Blu-Ray UHD sources.
>> ---
>> libavutil/frame.c
On Thu, Mar 30, 2017 at 4:46 PM, Hendrik Leppkes wrote:
> On Thu, Mar 30, 2017 at 4:31 PM, Steve Lhomme wrote:
>> As found in HEVC.
>>
>> I put the code in mastering_display_metadata as they usually go together in
>> Blu-Ray UHD sources.
>> ---
>> liba
These data are necessary when transmitting HDR over HDMI.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- update with MaxCLL/MaxFALL changes in avutil
---
libavcodec/avcodec.h | 7 +++
libavcodec/avpacket.c | 1 +
libavcodec/hevc_sei.c | 15 +++
libavcodec/hevcd
--
update the previous patch:
- use MaxCLL/MaxFALL which are not rational numbers anymore
---
libavformat/dump.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 7c811ce5d2..0ab3465db8 100644
--- a/libavformat/dump.c
+++ b/libavformat/d
As found in HEVC.
I put the code in mastering_display_metadata as they usually go together in
Blu-Ray UHD sources.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- use MaxCLL and MaxFALL names that are more commonly found
- use unsigned integer rather than rational numbers as (supp
As found in HEVC.
I put the code in mastering_display_metadata as they usually go together in
Blu-Ray UHD sources.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- use MaxCLL and MaxFALL names that are more commonly found
- use unsigned integer rather than rational numbers as (supp
These data are necessary when transmitting HDR over HDMI.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- update with MaxCLL/MaxFALL changes in avutil
update the previous patch:
- rebased and updated version bump
---
libavcodec/avcodec.h | 7 +++
libavcodec/avpacket.c | 1 +
--
update the previous patch:
- use MaxCLL/MaxFALL which are not rational numbers anymore
---
libavformat/dump.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index ef4a6b093b..8fd58a0dba 100644
--- a/libavformat/dump.c
+++ b/libavformat/d
As found in HEVC.
I put the code in mastering_display_metadata as they usually go together in
Blu-Ray UHD sources.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- use MaxCLL and MaxFALL names that are more commonly found
- use unsigned integer rather than rational numbers as (supp
These data are necessary when transmitting HDR over HDMI.
--
update the previous patch:
- rename CEA 861.3 to CTA-861.3
- update with MaxCLL/MaxFALL changes in avutil
update the previous patch:
- rebased and updated version bump
---
libavcodec/avcodec.h | 7 +++
libavcodec/avpacket.c | 1 +
Hi,
As I am progressing in proper HDR10 support in VLC, I am facing an
issue. The mastering (and lighting pending patch) metadata are set on
the AVFrame but not available to the ff_get_format() receiver.
That means when we configure our vout and decoder we don't know if
it's going to have HDR met
On Thu, Apr 6, 2017 at 11:08 AM, Hendrik Leppkes wrote:
> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote:
>> Hi,
>>
>> As I am progressing in proper HDR10 support in VLC, I am facing an
>> issue. The mastering (and lighting pending patch) metadata are set on
>&
On Thu, Apr 6, 2017 at 11:38 AM, wm4 wrote:
> On Thu, 6 Apr 2017 11:08:24 +0200
> Hendrik Leppkes wrote:
>
>> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote:
>> > Hi,
>> >
>> > As I am progressing in proper HDR10 support in VLC, I am facing
On Thu, Apr 6, 2017 at 1:08 PM, Hendrik Leppkes wrote:
> On Thu, Apr 6, 2017 at 11:35 AM, Steve Lhomme wrote:
>> On Thu, Apr 6, 2017 at 11:08 AM, Hendrik Leppkes wrote:
>>> On Thu, Apr 6, 2017 at 11:01 AM, Steve Lhomme wrote:
>>>> Hi,
>>>>
>>&
Thanks !
On Thu, Apr 6, 2017 at 4:45 PM, James Almer wrote:
> On 4/2/2017 5:08 AM, Steve Lhomme wrote:
>> --
>> update the previous patch:
>> - use MaxCLL/MaxFALL which are not rational numbers anymore
>> ---
>> libavformat/dump.c | 11 +++
>> 1 fi
---
libavcodec/qsvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 5eb506fb76..772336b719 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -989,7 +989,7 @@ static int encode_frame(AVCodecContext *avctx,
QSVEncCo
From: "Mohammed (Shaan) Huzaifa Danish"
---
libavcodec/h264_sei.c | 6 --
libavcodec/h264_sei.h | 1 +
libavcodec/h264_slice.c | 2 ++
libavutil/stereo3d.h| 4
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 332
This is cleaner to read and less error prone.
---
libavcodec/qsvenc.c | 117 +---
1 file changed, 56 insertions(+), 61 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 772336b719..bbf72e54b0 100644
--- a/libavcodec/qsvenc.c
We only have one possible Payload for now: A53 CC
---
libavcodec/qsv_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index c0305508dd..5419db05be 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_interna
---
libavcodec/qsvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index bbf72e54b0..806cef5633 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1048,7 +1048,7 @@ static int encode_frame(AVCodecContext *avctx,
QSVEnc
t the one from the ID3D11VideoDecoderOutputView array
in AVD3D11VAContext.
Otherwise, when providing decoder slices that do not start from 0,
pictures appear in bogus order. For an invalid index crashes and
image corruption can occur.
On Wed, Oct 5, 2016 at 12:52 PM, Steve Lhomme wrote:
> T
---
libavcodec/dxva2.c | 2 +-
libavcodec/dxva2_internal.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 04a9c11..a64b1b5 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -29,7 +29,7 @@
#include "avcodec.h"
No need to loop through the known surfaces, we'll use it anyway.
The loop is only done for DXVA2
---
libavcodec/dxva2.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index a64b1b5..459e267 100644
--- a/libavcodec/dxva2
On Thu, Dec 1, 2016 at 3:43 PM, Hendrik Leppkes wrote:
> On Thu, Dec 1, 2016 at 3:13 PM, Stève Lhomme wrote:
>> I think I should update the minor version number as I need to rely on
>> this behaviour change in VLC, the surface array will be empty.
>>
>> Should I also change the headers so that th
From: Steve Lhomme
---
libavcodec/dxva2_h264.c | 4 +---
libavcodec/dxva2_hevc.c | 4 +---
libavcodec/dxva2_internal.h | 5 +
libavcodec/dxva2_mpeg2.c| 4 +---
libavcodec/dxva2_vc1.c | 4 +---
libavcodec/dxva2_vp9.c | 4 +---
6 files changed, 10 insertions(+), 15
From: Steve Lhomme
No need to loop through the known surfaces, we'll use it anyway.
The loop is only done for DXVA2
---
libavcodec/dxva2.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index a64b1b5..459e267 1
From: Steve Lhomme
---
libavcodec/dxva2.c | 2 +-
libavcodec/dxva2_internal.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 04a9c11..a64b1b5 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -29,7 +29,7
From: Steve Lhomme
We can pick the correct slice index directly from the
ID3D11VideoDecoderOutputView
casted from data[3].
---
libavcodec/dxva2_internal.h | 4 ++--
libavcodec/version.h| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dxva2_internal.h b
From: Steve Lhomme
The code is similar to ffmpeg_dxva2. The decoded output needs to be copied into
a staging texture that can be accessed by the CPU as the decoder texture can't
be accessed by the CPU.
---
Makefile | 1 +
configure | 14 ++
ffm
From: Steve Lhomme
Otherwise some ARM and other unsupported CPU is linked with -O0
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 9dfd006..d623ced 100755
--- a/configure
+++ b/configure
@@ -4087,6 +4087,7 @@ probe_cc(){
_DEPFLAGS
From: Steve Lhomme
The code is similar to ffmpeg_dxva2. The decoded output needs to be copied into
a staging texture that can be accessed by the CPU as the decoder texture can't
be accessed by the CPU.
---
Makefile | 1 +
configure | 14 ++
ffm
1 - 100 of 215 matches
Mail list logo
