> Am 01.08.2020 um 08:47 schrieb Julio César Rocha :
>
> Friendly ping.
>
> Are these changes acceptable now?
Please allow more than 24 hours reaction time and please find out what
top-posting means and avoid it here.
Carl Eugen
___
ffmpeg-devel ma
Hi,
patches attached.
Added yuv422p10 support to encoder and some comments to tables.
This work is sponsored by VideoLAN.
0001-avcodec-cfhd-move-if-else-out-of-loop-in-inverse-tra.patch
Description: Binary data
0002-avcodec-cfhd-fix-non-aligned-to-8-height-decoding.patch
Description: Binary
lgtm
On 7/31/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
> index 07fa8887d8..9ba70af6f7 100644
> --- a/libavcodec/smac
LGTM. I thought flush_put_bits flushes more bits depending on cache size,
but obviously that assumption is incorrect.
On 7/30/20, Andreas Rheinhardt wrote:
> flush_put_bits() already fills the bitstream with zeroes, so it is
> unnecessary to align the bitstream before.
>
> Signed-off-by: Andreas
On 7/4/20, Kieran Kunhya wrote:
> $subj
>
> I have done basic fuzzing on it with no crashes.
> Fixes this sample:
> http://samples.mplayerhq.hu/V-codecs/CFHD/MT_BeartoothHighway_1min_Cineform.avi
>
> Kieran
>
This patch causes spider sample to crash.
http://www.siliconimaging.com/DigitalCinema/Ga
On 01.08.2020 08:47, Julio César Rocha wrote:
Friendly ping.
Are these changes acceptable now?
I still don't see why they are neccesary. I did a test-build just
yesterday with current git master, and it succeeded just fine with
--toolchain=msvc in WSL launched via msvc cli.
___
I'll try again.
It did not work for me as of version 4.2.2.
Maybe a more recent change has fixed it...
On Sat, Aug 1, 2020 at 3:34 AM Timo Rothenpieler
wrote:
> On 01.08.2020 08:47, Julio César Rocha wrote:
> > Friendly ping.
> >
> > Are these changes acceptable now?
> >
>
> I still don't see w
Am Sa., 1. Aug. 2020 um 12:34 Uhr schrieb Timo Rothenpieler
:
>
> On 01.08.2020 08:47, Julio César Rocha wrote:
> > Friendly ping.
> >
> > Are these changes acceptable now?
> >
>
> I still don't see why they are neccesary. I did a test-build just
> yesterday with current git master, and it succeede
> > Am 01.08.2020 um 08:47 schrieb Julio César Rocha :
> please find out what top-posting means and avoid it here.
Ping, this should not need more than a few minutes.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
These bits are utilized by channel layouts such as 22.2. If those
are dropped, the returned channel layout is no longer a match
against the AV_CH_LAYOUT define when returned from this function.
---
libswresample/rematrix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswre
Only this sub-set of channels actually follows the bit mask order
in the official 22.2 channel mapping. Additionally, the 5.1 channels
are there for backwards compatibility with the previous system.
This enables the utilization of 22.2 content until a proper down/up
matrix is added into swresample
Requires some extraneous top side and bottom front channels to be
defined.
According to STD-B59v2, the defined channel layout is:
- FL
- FR
- FC
- LFE1
- BL
- BR
- FLc
- FRc
- BC
- LFE2
- SiL
- SiR
- TpFL
- TpFR
- TpFC
- TpC
- TpBL
- TpBR
- TpSiL
- TpSiR
- TpBC
- BtFC
- BtFL
- BtFR
---
doc/APIcha
The decoding parts of this patch set have not changed from v2.
I have now added changes so that 22.2 gets properly handled as
5.1 (for which it has backwards compatibility) until it gets a
proper remix matrix defined in swresample. So
-channel_layout "5.1"` now has been verified to just re-utilize
---
libavcodec/aacdec_template.c | 89 +++-
1 file changed, 78 insertions(+), 11 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 21db12fdab..8c5048cc13 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_tem
Utilizes the newly added 22.2 channel layout for channel_layout 13.
---
libavcodec/aacdectab.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index baf51a74bf..c54a3eb943 100644
--- a/libavcodec/aacdectab
Additionally, add comments regarding their definitions. Based on
ARIB STD-B32, which bases on 14496-3:2009 and 14496-3:2009/AMD4.
---
libavcodec/mpeg4audio.c | 17 +++--
libavcodec/mpeg4audio.h | 2 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg4aud
Am Fr., 31. Juli 2020 um 13:02 Uhr schrieb Timo Rothenpieler
:
> For all that ffmpegs build system is concerned it's a normal
> cross-compile from Linux to Windows.
Imo, one of the advantages of using wsl is that you can
do a native Windows compile (not a cross compile).
Carl Eugen
_
Paul B Mahol (12020-08-01):
> Hi,
>
> patches attached.
>
> Added yuv422p10 support to encoder and some comments to tables.
>
> This work is sponsored by VideoLAN.
My concerns have been addressed. Thanks.
--
Nicolas George
signature.asc
Description: PGP signature
_
Am Fr., 31. Juli 2020 um 09:42 Uhr schrieb Julio César Rocha
:
> Hi. I recently submitted a patch to enable building the Windows flavor with
> Windows Subsystem for Linux as an alternative to MSYS / CYGWIN.
>
> I got the feedback that people are already able to achieve this.
>
> Has anyone achieve
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 40942c6..d34c6b3 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -85,7 +85,7 @@ sta
From: Limin Wang
If you enable YUV422 or YUV444, SVT-AV1 library will report "only support 420
now" error,
so it's better to remove the unsupported code.
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavcodec/libsvtav1
We now have the capability to do this.
---
libavcodec/aacdec_template.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a473e1bad7..21db12fdab 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
LGTM.
On Sat, 1 Aug 2020, at 11:15, Paul B Mahol wrote:
> Hi,
>
> patches attached.
>
> Added yuv422p10 support to encoder and some comments to tables.
>
> This work is sponsored by VideoLAN.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.
On Sat, Aug 1, 2020 at 4:20 AM Carl Eugen Hoyos wrote:
> Am Fr., 31. Juli 2020 um 09:42 Uhr schrieb Julio César Rocha
> :
>
> > Hi. I recently submitted a patch to enable building the Windows flavor
> with
> > Windows Subsystem for Linux as an alternative to MSYS / CYGWIN.
> >
> > I got the feedb
From: Limin Wang
Please use the cores and socket for the setting of multi-thread.
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 78e0ee5..dfb361a 100644
--- a/libavco
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index d34c6b3..eb6043b 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -273,23 +273,17 @@ static av_
On 6/16/20, Jan Ekström wrote:
> Requires some extraneous top side and bottom front channels to be
> defined.
>
> According to STD-B59v2, the defined channel layout is:
> - FL
> - FR
> - FC
> - LFE1
> - BL
> - BR
> - FLc
> - FRc
> - BC
> - LFE2
> - SiL
> - SiR
> - TpFL
> - TpFR
> - TpFC
> - TpC
>
Am Di., 16. Juni 2020 um 23:11 Uhr schrieb Jan Ekström :
>
> Requires some extraneous top side and bottom front channels to be
> defined.
>
> According to STD-B59v2, the defined channel layout is:
> - FL
> - FR
> - FC
> - LFE1
> - BL
> - BR
> - FLc
> - FRc
> - BC
> - LFE2
> - SiL
> - SiR
No way t
On Sat, Aug 1, 2020 at 2:51 PM Carl Eugen Hoyos wrote:
>
> Am Di., 16. Juni 2020 um 23:11 Uhr schrieb Jan Ekström :
> >
> > Requires some extraneous top side and bottom front channels to be
> > defined.
> >
> > According to STD-B59v2, the defined channel layout is:
> > - FL
> > - FR
> > - FC
> > -
Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> Additionally, the spec only mentions stereo/5.1 for direct mapping, so
> I've kept to 5.1 since we have the capability for that one.
And you still believe it would be a disadvantage if the decoder outputs
this 5.1 mapping by default if not
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/encoders.texi | 9 +
libavcodec/libsvtav1.c | 9 +
2 files changed, 18 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 2f5457f..da0b68d 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1747
On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
>
> > Additionally, the spec only mentions stereo/5.1 for direct mapping, so
> > I've kept to 5.1 since we have the capability for that one.
>
> And you still believe it would be a di
On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/encoders.texi | 9 +
libavcodec/libsvtav1.c | 9 +
2 files changed, 18 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 2f5457f..da0b68d 100644
On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
From: Limin Wang
Please use the cores and socket for the setting of multi-thread.
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/
On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 40942c6..d34c6b3 100644
--- a/libavcodec/libsvta
On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
From: Limin Wang
If you enable YUV422 or YUV444, SVT-AV1 library will report "only support 420
now" error,
so it's better to remove the unsupported code.
... not that you can even get to that message at the moment, because the
encoder wrapp
On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/libsvtav1.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index d34c6b3..eb6043b 100644
--- a/libavcodec/libsvtav1.c
+++ b/
On 8/1/2020 8:22 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/encoders.texi | 9 +
> libavcodec/libsvtav1.c | 9 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 2f5457f..
Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
>
> On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> >
> > Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> >
> > > Additionally, the spec only mentions stereo/5.1 for direct mapping, so
> > > I've kept to 5.1 since we have t
On 8/1/2020 8:22 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/libsvtav1.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index d34c6b3..eb6043b 100644
> --- a/libavcodec/li
On 8/1/2020 9:17 AM, Jan Ekström wrote:
> On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
>>
>> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
>>
>>> Additionally, the spec only mentions stereo/5.1 for direct mapping, so
>>> I've kept to 5.1 since we have the capability for that on
On Sat, Aug 1, 2020 at 4:29 PM Carl Eugen Hoyos wrote:
>
> Am Sa., 1. Aug. 2020 um 14:47 Uhr schrieb Jan Ekström :
> >
> > On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> > >
> > > Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> > >
> > > > Additionally, the spec only mentions
Given that the code currently accepts only 27 bits long Huffman codes,
the shift 1 << (length - 1) with length in 1..28 that is performed when
parsing the tree is safe. Yet if this limit were ever expanded to the
full 32 bits, this shift would be potentially undefined. So simply use
unsigned.
Sign
When length is zero for a leaf node (which happens iff the Huffman tree
consists of one leaf node only), prefix is also automatically zero.
Performance impact is negligible: For GCC 9 and the sample from #2425,
the time for one call to smka_decode_frame() decreased from 2053758 to
2053671 decicycl
The VLC codes in question originate from a Huffmann tree and so every
sequence of bits that is longer than the longest code contains an
initial sequence that is a valid code. Given that it has been checked
during reading said tree (and once again in ff_init_vlc_sparse()) that
the length of each cod
Using the real number of read codes allows to leave a loop in
ff_init_vlc_sparse earlier; notice that all codes not explicitly
set by reading data have been set to zero earlier (i.e. they are
zero-length codes) and such codes are ignored by ff_init_vlc_sparse.
This improves performance: When compi
Using explicit checks has the advantage that one can combine several
checks into one and does not have to check every time. E.g. reading a
16bit PCM sample involves two calls to get_vlc2(), each of which may
read up to three times up to SMKTREE_BITS (= 9) bits. But given that the
padding that the i
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 5e1b8c59ff..5e88e18aec 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -254,8 +254,7 @@ static int
With the possible exception of the "last" values when decoding video,
only the part that is actually initialized with values derived from the
bitstream is used afterwards, so it is unnecessary to zero everything at
the beginning. This is also no problem for the "last" values at all,
because they ar
Smacker uses two types of Huffman trees: Those for eight bit values and
those for 16 bit values. Given that both return their values via arrays
and that both need to check not to overrun their array, the context for
parsing eight bit values (HuffContext) will necessarily exhibit certain
similaritie
Up until now, the Smacker decoder has pretended that the prediction
values are signed in code like 'pred[0] += (unsigned)sign_extend(val, 16)'
(the cast has been added to this code later to fix undefined behaviour).
This has been even done in case the PCM format is u8.
Yet in case of 8/16 bit samp
This will mean that we will need less stack space lateron when these
arrays are no longer heap-allocated.
No discernible speed impact.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/smacker.c b/li
by using buffers on the stack instead. The fact that the effective
lifetime of most of the allocated buffers doesn't overlap enables one to
limit the stack space used to a fairly modest size (about 1.5 KiB).
That all the buffers used in HuffContexts have always the same number of
elements (namely
Up until now, the return value of get_vlc2() has been used as an index
in an array that contained the value one is really interested in. Yet
since b613bacca9c256f1483c46847f713e47a0e9a5f6 this is no longer
necessary, as one can store the value that is right now stored in the
array in the VLC intern
Besides the obvious advantage of less code this also has a performance
impact: For GCC 9 the time spent on one call to smka_decode_frame() for
the sample from ticket #2425 decreased from 1693619 to 1498127
decicycles. For Clang 9, it decreased from 1369089 to 1366465
decicycles.
Signed-off-by: And
On Sat, Aug 1, 2020 at 4:42 PM James Almer wrote:
>
> On 8/1/2020 9:17 AM, Jan Ekström wrote:
> > On Sat, Aug 1, 2020 at 3:08 PM Carl Eugen Hoyos wrote:
> >>
> >> Am Sa., 1. Aug. 2020 um 14:06 Uhr schrieb Jan Ekström :
> >>
> >>> Additionally, the spec only mentions stereo/5.1 for direct mapping,
lgtm
On 8/1/20, Andreas Rheinhardt wrote:
> Given that the code currently accepts only 27 bits long Huffman codes,
> the shift 1 << (length - 1) with length in 1..28 that is performed when
> parsing the tree is safe. Yet if this limit were ever expanded to the
> full 32 bits, this shift would be
probably ok
On 8/1/20, Andreas Rheinhardt wrote:
> Using the real number of read codes allows to leave a loop in
> ff_init_vlc_sparse earlier; notice that all codes not explicitly
> set by reading data have been set to zero earlier (i.e. they are
> zero-length codes) and such codes are ignored by
On 8/1/20, Andreas Rheinhardt wrote:
> by using buffers on the stack instead. The fact that the effective
> lifetime of most of the allocated buffers doesn't overlap enables one to
> limit the stack space used to a fairly modest size (about 1.5 KiB).
>
> That all the buffers used in HuffContexts h
On 8/1/20, Andreas Rheinhardt wrote:
> Besides the obvious advantage of less code this also has a performance
> impact: For GCC 9 the time spent on one call to smka_decode_frame() for
> the sample from ticket #2425 decreased from 1693619 to 1498127
> decicycles. For Clang 9, it decreased from 1369
I prefer in this case av_calloc or av_malloc_array, if memset hurts.
Anyway LGTM
On 8/1/20, Andreas Rheinhardt wrote:
> With the possible exception of the "last" values when decoding video,
> only the part that is actually initialized with values derived from the
> bitstream is used afterwards,
On 8/1/20, Andreas Rheinhardt wrote:
> Up until now, the return value of get_vlc2() has been used as an index
> in an array that contained the value one is really interested in. Yet
> since b613bacca9c256f1483c46847f713e47a0e9a5f6 this is no longer
> necessary, as one can store the value that is r
LGTM
On 8/1/20, Andreas Rheinhardt wrote:
> This will mean that we will need less stack space lateron when these
> arrays are no longer heap-allocated.
>
> No discernible speed impact.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 8
> 1 file changed, 4 insertion
On 8/1/20, Andreas Rheinhardt wrote:
> Smacker uses two types of Huffman trees: Those for eight bit values and
> those for 16 bit values. Given that both return their values via arrays
> and that both need to check not to overrun their array, the context for
> parsing eight bit values (HuffContext
On 8/1/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
OK
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/l
On 8/1/20, Andreas Rheinhardt wrote:
> Using explicit checks has the advantage that one can combine several
> checks into one and does not have to check every time. E.g. reading a
> 16bit PCM sample involves two calls to get_vlc2(), each of which may
> read up to three times up to SMKTREE_BITS (=
On 8/1/20, Andreas Rheinhardt wrote:
> The VLC codes in question originate from a Huffmann tree and so every
> sequence of bits that is longer than the longest code contains an
> initial sequence that is a valid code. Given that it has been checked
> during reading said tree (and once again in ff_
probably fine
On 8/1/20, Andreas Rheinhardt wrote:
> When length is zero for a leaf node (which happens iff the Huffman tree
> consists of one leaf node only), prefix is also automatically zero.
>
> Performance impact is negligible: For GCC 9 and the sample from #2425,
> the time for one call to
fre 2020-07-31 klockan 11:09 +0100 skrev Harry Mallon:
> Hi,
>
> V2 fixes all the fate tests (I didn't know to download the test
> footage before. Doh).
>
> The following patch adds reading colour metadata (transfer, primaries
> and colour space) from
> standard MXF files. I wrote it without seei
Paul B Mahol:
> On 8/1/20, Andreas Rheinhardt wrote:
>> The VLC codes in question originate from a Huffmann tree and so every
>> sequence of bits that is longer than the longest code contains an
>> initial sequence that is a valid code. Given that it has been checked
>> during reading said tree (a
Paul B Mahol wrote:
>Added yuv422p10 support to encoder and some comments to tables.
LGTM
Thank you and best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit li
On Sat, Aug 01, 2020 at 10:09:20AM -0300, James Almer wrote:
> On 8/1/2020 8:22 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/libsvtav1.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/libavcodec/libsvtav1.c
On Sat, Aug 01, 2020 at 02:02:33PM +0100, Mark Thompson wrote:
> On 01/08/2020 12:22, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > If you enable YUV422 or YUV444, SVT-AV1 library will report "only support
> > 420 now" error,
> > so it's better to remove the unsupported code.
>
> .
If we fail to create a decoder specified by ourself, then try to
let VideoToolbox pick a proper one for us.
Signed-off-by: Wang Chuan
---
libavcodec/videotoolbox.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 8773de3393..9077
On Sat, Aug 01, 2020 at 10:15:02AM -0300, James Almer wrote:
> On 8/1/2020 8:22 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/encoders.texi | 9 +
> > libavcodec/libsvtav1.c | 9 +
> > 2 files changed, 18 insertions
On 01/08/2020 16:25, Wang Chuan wrote:
If we fail to create a decoder specified by ourself, then try to
let VideoToolbox pick a proper one for us.
Signed-off-by: Wang Chuan
---
libavcodec/videotoolbox.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/videotoolbox.c b/libav
I’m just looking at the bug https://trac.ffmpeg.org/ticket/8789
And I found that in this case, VTDecompressionSessionCreate will fail and
return kVTVideoDecoderNotAvailableNowErr
While according to the document of [VTDecompressionSessionCreate], it is
possible to give a null
And let videotoolbo
On 29/07/2020 04:13, Xiang, Haihao wrote:
On Tue, 2020-07-28 at 23:50 +0100, Mark Thompson wrote:
Though still use it if the tile arrangement matches. Also try to keep the
fields in the same order as the standard.
---
libavcodec/vaapi_encode_h265.c | 39 --
1
Paul B Mahol:
> On 7/27/20, Andreas Rheinhardt wrote:
>> Paul B Mahol:
>>> Make sure this does not break demuxing/decoding.
>>>
>>
>> This patch is designed to not change the packets output by the demuxer
>> or the demuxer's return value at all. I have tested this with a small
>> sample created in
On Sat, Aug 1, 2020 at 6:25 PM 王 氚 wrote:
>
> I’m just looking at the bug https://trac.ffmpeg.org/ticket/8789
> And I found that in this case, VTDecompressionSessionCreate will fail and
> return kVTVideoDecoderNotAvailableNowErr
>
> While according to the document of [VTDecompressionSessionCreat
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
Fixes: Ticket8762
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 49 +---
1 file changed, 42 insertions(+), 7 deletions(-)
If "dv remux loses sync", then the timestamps should be fixed, not
X2RGB10 tested on both Intel Gen9 and AMD Polaris 11. NV12 tested on
Intel Gen9 only - since it has multiple planes, this requires GetFB2.
Also add some comments to split the list up a bit.
---
libavdevice/kmsgrab.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavdevice/kmsgra
On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
>
>
> On Sat, 1 Aug 2020, Michael Niedermayer wrote:
>
> > Fixes: Ticket8762
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/dv.c | 49 +---
> > 1 file changed, 42 insertions
Doesn't break msys2 builds, so it's okay to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Sat, Aug 01, 2020 at 02:07:25PM +0300, Jan Ekström wrote:
> These bits are utilized by channel layouts such as 22.2. If those
> are dropped, the returned channel layout is no longer a match
> against the AV_CH_LAYOUT define when returned from this function.
> ---
> libswresample/rematrix.c | 2
On Sat, Aug 01, 2020 at 02:07:26PM +0300, Jan Ekström wrote:
> Only this sub-set of channels actually follows the bit mask order
> in the official 22.2 channel mapping. Additionally, the 5.1 channels
> are there for backwards compatibility with the previous system.
>
> This enables the utilization
On Fri, Jul 31, 2020 at 01:22:36PM +0200, Andreas Rheinhardt wrote:
> ff_init_vlc_sparse() supports arrays of uint8_t, uint16_t and uint32_t
> as input (and it also supports padding/other elements in between the
> elements). This makes the typical case in which the input is a simple
> array more cu
On Sat, Aug 1, 2020 at 9:52 PM Michael Niedermayer
wrote:
>
> On Sat, Aug 01, 2020 at 02:07:26PM +0300, Jan Ekström wrote:
> > Only this sub-set of channels actually follows the bit mask order
> > in the official 22.2 channel mapping. Additionally, the 5.1 channels
> > are there for backwards comp
Hi Michael!
On 2020-07-31 19:54 +0200, Michael Niedermayer wrote:
> On Thu, Jul 30, 2020 at 02:42:30PM +0200, Alexander Strasser wrote:
> > Don't pass a potential NULL pointer to av_log, instead use a default
> > in the rc_eq AVOption definitions. Now the context variable always
> > holds a string
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
Fixes: Ticket8762
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 49 +---
1 f
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type
'int'
Fixes:
24457/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5760093644390400
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Nieder
Fixes: out of array read
Fixes:
24487/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5165847820369920
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeg2000dec.c | 4 +++-
Description:
At arm architechture of Linux system, use ffmpeg to record the screen.
command:
ffmpeg -video_size 1920x1080 -framerate 30 -thread_queue_size
512 -f x11grab -i :0+0,0 -c:v libx264 -pix_fmt yuv420p -crf 1 -vf
'scale=trunc(iw/2)*2:trunc(ih/2)*2' out.mp4
Just dig it a little bit, and I found that the first attempt of
[VTDecompressionSessionCreate] is always ok, if we try to decode some normal
size of video(for example, 640x480, 1280x720...)
But it will fail, it we try to decode h264 video with some special size(for
example, 300x180).
So it see
Previously, the hls-fmp4 and hls-fmp4_ac3 tests used the same file
names for init and segment files, which occasionally could cause
corruption and failed tests, if the input files for both tests are
generated in parallel, as they could overwrite each other.
This happened to work some of the time,
Since this test was added in ac22835db947e, it actually has been
using segment type mpegts, contrary to what the test looks like
it is supposed to test.
---
tests/fate/hlsenc.mak | 2 +-
tests/ref/fate/hls-fmp4 | 384
2 files changed, 193 insertions(+),
96 matches
Mail list logo
