Hi,
For the record we have been running this in VLC for quite some time,
only for Intel hardware.
https://code.videolan.org/videolan/vlc/-/blob/3.0.x/contrib/src/ffmpeg/0001-avcodec-dxva2_hevc-add-support-for-parsing-HEVC-Rang.patch?ref_type=heads
https://code.videolan.org/videolan/vlc/-/blob/3
Hi Michael,
All the patches in that patches look good to me. You can apply.
Steve
On 07/07/2024 22:23, Michael Niedermayer wrote:
Hi Steve
you are listed as maintainer for d3d11va, there are some trivial patches in
this patchset that i cannot easily test
can you either apply/approve/reject/t
The callback passed to CreateThread is not the same as with _beginthreadex().
This WinRT check could be removed if Win8 WinRT is not maintained
as _beginthreadex() is now available [1]
[1]
https://learn.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?
They are not mapped into structures but the IDs and their allowed position is
set properly.
---
libavformat/matroska_ids.h | 93 ++
libavformat/matroskasem.c | 58 +---
libavformat/matroskasem.h | 2 +-
3 files changed, 145 insertions(+),
---
libavformat/matroskasem.c | 69 +++
libavformat/matroskasem.h | 7 +---
2 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index 0f4455058a..cdef0dbff4 100644
--- a/libavformat/matroskasem.
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 | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavforma
re details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Matroska file semantic element definitions
+ * @
The XSLT scripts produces a similar file to this one, minus some spacing
differences.
No value added/removed.
---
libavformat/matroska_ids.h | 106 ++---
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/libavformat/matroska_ids.h b/libavformat/matros
According grouped with their parent's elements.
No value added/removed.
Some IDs have been moved to match their parent section.
Use a consistent wording in all sections.
---
libavformat/matroska_ids.h | 83 ++
1 file changed, 58 insertions(+), 25 deletions(-)
No functional value/added removed, only more regular spacing.
---
libavformat/matroska_ids.h | 303 +++---
libavformat/matroskasem.c | 370 ++---
2 files changed, 336 insertions(+), 337 deletions(-)
diff --git a/libavformat/matroska_ids.h b
So they are sorted by their EBML path, in reverse order so we don't extra
declarations.
No functional changes.
---
libavformat/matroskasem.c | 263 +++---
1 file changed, 132 insertions(+), 131 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matr
So the file can be generated from the EBML Schema.
No functional change.
---
libavformat/matroska.h | 314 +-
libavformat/matroska_ids.h | 339 +
2 files changed, 340 insertions(+), 313 deletions(-)
create mode 100644 libavf
---
libavformat/matroska.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 45077ed33f..1e8a91295f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -296,18 +296,18 @@ typedef enum {
} Ma
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 d582f566a2..9e756bb030 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -7
All integers should be initialized to 0. Make the tables more consistent by
only setting non zero values, so they stand out.
---
libavformat/matroskadec.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/
From: robux4
Following an earlier version of the generated code, I reworked to code and move
the generator outside of the FFmpeg source tree.
The XSLT code to generate this code from the EBML Schema for Matroska can be
found at https://github.com/Matroska-Org/foundation-source/pull/116
Steve
Hi Anton,
On 2022-09-02 22:59, Anton Khirnov wrote:
This state is not refcounted, so make sure it always has a well-defined
owner.
---
Steve, could you please test this?
I can confirm it doesn't leak the context and plays correctly. It also
doesn't crash ;)
---
libavcodec/pthread_frame.c
Hi,
On 2022-08-02 16:19, Anton Khirnov wrote:
Why are you not resubmitting your original patch that stops copying
hwaccel_priv_data to the user-facing context?
It seemed more correct to me, since the user-facing context should never
see any hwaccel data. Or does it not fix the issue fully?
Th
his patch seems solid.From e8abeeff92f5d7b3b553acdb7595d40153cbec1e Mon Sep 17 00:00:00 2001
From: Steve Lhomme
Date: Fri, 8 Jul 2022 11:49:27 +0200
Subject: [PATCH] avcodec/pthread_frame: update the main avctx from the current
ThreadContext
After a submit_decoder() the hwaccel_priv_data may have
On 2022-04-01 14:33, Steve Lhomme wrote:
Hi ffmmpeg developers,
As you may know, we are working hard on the Matroska specifications at
the IETF. We already got EBML as an RFC [1]. We are in the process of
finalizing the main Matroska document. Before we submit the document for
formal review
Hi ffmmpeg developers,
As you may know, we are working hard on the Matroska specifications at
the IETF. We already got EBML as an RFC [1]. We are in the process of
finalizing the main Matroska document. Before we submit the document for
formal review before "final" publishing, we would like pe
ample file, and
playback seems correct.
On 2022-03-23 14:54, Steve Lhomme wrote:
Similar to how a frame is considered for referencing for the RefPicList array.
This will do the same for RefPicSetStCurrBefore, RefPicSetStCurrAfter and
RefPicSetLtCurr.
Fixes playback of http://www.gbbsoft.pl/!download/
/26738
Signed-off-by: Steve Lhomme
---
libavcodec/dxva2_hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
index c91bcf3eeb..6b239d9917 100644
--- a/libavcodec/dxva2_hevc.c
+++ b/libavcodec/dxva2_hevc.c
@@ -184,7 +184,7
We should return 0 and assert there's something wrong. This is how it's done
with the other DXVA variants.
It fixes bad reference usage in http://www.gbbsoft.pl/!download/!/Film1.mp4
It's using a frame that doesn't have any data[] fields set (yet?).
Signed-off-by: Steve Lho
On 2021-09-02 17:41, Andreas Rheinhardt wrote:
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them woul
initialization.
This is undefined behaviour and certain threading implementations
like pthreadGC2 crash when it is attempted.
Fix this by initializing these objects once during init and freeing
them in close.
Works for me.
Reported-by: Steve Lhomme
Signed-off-by: Andreas Rheinhardt
On 2021-09-02 11:27, Andreas Rheinhardt wrote:
Steve Lhomme:
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL
v2: shorter commit lines and removed an extra space, now I realize it's
the wrong one, the original being also wrong...
On 2021-09-02 11:19, Steve Lhomme wrote:
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy pro
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread implementations allows NULL as a special
value (and should return EINVAL but
Do the conversion from double to uint64_t explicitly and only once.
The comparison to UINT64_MAX is not correct.
---
libavformat/matroskadec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 8a5bc4018a..4ff472005e
The Block timestamp read in matroska_parse_block() is in track timebase and is
passed on as such to the AVPacket which uses this timebase.
In the normal case the Cluster and Track timebases are the same because the
track->time_scale is 1.0. But when it is not the case, the values in Cluster
timeba
No need to multiplying/dividing when we know it's zero.
---
libavformat/matroskadec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4ff472005e..25b22afebe 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat
No need to check if the cluster has a timestamp or not. If we found a timestamp
for this block, then it's usable. This is actually the same condition to decide
if we can use the timestamp or not.
---
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/liba
---
libavformat/matroskadec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 981e044263..ba0e2956df 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2672,8 +2672,12 @@ static int matrosk
On 2020-08-13 1:01, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Wednesday, August 12, 2020 2:05 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
On 2020-08-11 12:43, Steve Lhomme wrote:
Sorry if you seem to know all the answers already, but I don't and so
I have to
investigate.
Last year, I had literally worked this down to death. I followed every
slightest
hint from countless searches, read through hundreds of discussions,
d
On 2020-08-11 13:08, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Tuesday, August 11, 2020 12:44 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
Sorry if you seem to know all the answers already, but I don't and so I have to
investigate.
Last year, I had literally worked this down to death. I followed every slightest
hint from countless searches, read through hundreds of discussions, driven
because I was unwilling to believe that up-/dow
On 2020-08-11 8:58, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Tuesday, August 11, 2020 6:35 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
On 2020-08-11 3:52, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Monday, August 10, 2020 2:15 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
On 2020-08-10 12:04, Soft Works wrote:
the very least the locks are needed inside libavcodec to avoid
setting DXVA buffers concurrently from different threads. It will
most likely result in very bad distortions if not crashes. Maybe
you're only using 1 decoding thread with DXVA (which a lot of pe
On 2020-08-08 8:24, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Saturday, August 8, 2020 7:10 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
On 2020-08-07 23:59, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Steve Lhomme
Sent: Friday, August 7, 2020 3:05 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
copies are done before submitting them
I
U.
On 2020-08-05 12:07, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU mem
v3 with support for the old API as well.
On 2020-08-05 12:07, Steve Lhomme wrote:
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d1
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d11va.h | 6 ++
libavcodec/dxva2.c | 38 +++---
libavcodec/version.h | 2 +-
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
On 2020-08-05 9:55, Marton Balint wrote:
On Wed, 5 Aug 2020, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the subm
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
On 2020-08-05 9:07, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
*creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memo
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait
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
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
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
---
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
> 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
> 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
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
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
> 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
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 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
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 --
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 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
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
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
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
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
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
---
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
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
> 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.
> >
> >
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 +
---
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
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/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,
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,
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
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
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
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
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
---
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'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 ++--
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
> 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
> 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 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 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 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
1 - 100 of 215 matches
Mail list logo
