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
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
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
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 +++-
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
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
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
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:
> 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
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
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
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
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:
> 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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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.
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
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 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
> ---
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
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
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
+++
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
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
---
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
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 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
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
@@
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
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 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
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
>
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
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
---
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
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
>
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
+++
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 @@
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
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
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
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
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
---
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
---
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
+++
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
---
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
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
> > 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
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
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
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.
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.
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
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
> ---
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
> 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
Friendly ping.
Are these changes acceptable now?
On Fri, Jul 31, 2020 at 1:35 AM Julio César Rocha
wrote:
> Understood, thanks!
>
> Here are the updated patches.
>
> On Fri, Jul 31, 2020 at 1:07 AM zhilizhao wrote:
>
>>
>>
>> > On Jul 31, 2020, at 3:19 PM, Julio César Rocha
>> wrote:
>> >
>>
95 matches
Mail list logo
