On Wed, 2020-09-02 at 04:32 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Soft Works
> > Sent: Wednesday, September 2, 2020 6:13 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc
liush...@aosc.io:
> From: Zixing Liu
>
> Signed-off-by: liushuyu
> ---
> Changelog| 1 +
> doc/general.texi | 2 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/mca.c| 240 +++
> liba
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Wednesday, September 2, 2020 6:13 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use
> initialized device
>
> >
>
Looking for SCTE-35 pass through implementation:
1. Extract SCTE-35 from MPEG-TS.
2. Translate timing of the original SCTE-35 events to match timing in the
output file appropriately or keep timing as is.
3. Signal encoder to force key frames at the boundaries of the SCTE-35
event.
4. Inject SCTE-3
On Wed, 2020-09-02 at 04:20 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Wednesday, September 2, 2020 6:01 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Wednesday, September 2, 2020 6:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> specify a device for VAAPI backend
>
> According to
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Wednesday, September 2, 2020 5:33 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use
> initialized device
>
>
>
According to the FFmpeg documentation, -hwaccel_device can be used to
select a device for hardware acceleration
Example:
ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \
-i in.h264 -c:v hevc_qsv out.h265
---
fftools/ffmpeg_qsv.c | 8
1 file changed, 8 insertions(+)
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Dmitry Rogozhkin
> Sent: Wednesday, September 2, 2020 4:44 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Dmitry Rogozhkin
> Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use
> initialized device
>
> qsv decoders did
qsv decoders did not allow to use devices explicitly initialized on
the command line and actually were using default device. This starts
to cause confusion with intel discrete GPUs since in this case decoder
might run on default integrated GPU device (/dev/dri/renderD128) and
encoder on the device
Hi,
I found a bug in libavcodec/qsvenc.c. You know, QSV has several
bitrate control modes (CBR, VBR, .. and so on). The bug is bitrate
setting in QVBR.
In the original code, bitrate value is set in "mfx.MaxKbps". Actually,
it must be "mfx.TargetKbps". As a result, FFmpeg's QVBR always works
in qu
From: Zixing Liu
Signed-off-by: liushuyu
---
Changelog| 1 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mca.c| 240 +++
libavformat/version.h| 4 +-
6 files
From: Zixing Liu
This patch adds the MCA demuxer to FFmpeg.
MCA is a format used by Capcom in some of their games, the audio format
is always ADPCM_THP_LE in these files.
This MCA demuxer implementation currently supports MCA version 1-5 and
can partially handle some of the version 5 files with
On 2020-09-01 17:21, Carl Eugen Hoyos wrote:
Am Mi., 2. Sept. 2020 um 01:17 Uhr schrieb :
On 2020-09-01 17:07, Carl Eugen Hoyos wrote:
> Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
>
>> +static int probe(const AVProbeData *p)
>> +{
>> +if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
>>
On 01/09/2020 08:16, Wang, Fei W wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Mark
Thompson
Sent: Tuesday, September 1, 2020 5:01 AM
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH v2] cbs_av1: Fill tile width/height values when
uniform_tile_spacing_flag is set
On 2020-09-01 17:07, Carl Eugen Hoyos wrote:
Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
+static int probe(const AVProbeData *p)
+{
+if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
+(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
+return AVPROBE_SCORE_MAX /
On 23/08/2020 23:33, Mark Thompson wrote:
---
This series depends on the CBS unit table rewrite and following cleanups.
Since comments on that series seem to have dried up, I will apply it in a few
days if nothing further comes up.
Applied the first half. I'm going to look into adding some
Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
> +static int probe(const AVProbeData *p)
> +{
> +if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
> +(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
> +return AVPROBE_SCORE_MAX / 3 * 2;
> +return 0;
At least add
From: Zixing Liu
This patch adds the MCA demuxer to FFmpeg.
MCA is a format used by Capcom in some of their games, the audio format
is always ADPCM_THP_LE in these files.
This MCA demuxer implementation currently supports MCA version 1-5 and
can partially handle some of the version 5 files with
From: Zixing Liu
Signed-off-by: liushuyu
---
Changelog| 1 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mca.c| 240 +++
libavformat/version.h| 4 +-
6 files
> I'll continue to work on trying to fix mxfdec.c anyway, thanks.
Update to the patch proposal, seems to be working ok (as far as pixel
format is concerned) for both SMPTE & INTEROP DCP.
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6f6e8d586c..4c146a152d 100644
--- a/libavforma
On 9/1/2020 4:16 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Keeping only the latest packet fed to the decoder works only for decoders
>> that
>> return a frame immediately after every consumed packet. Decoders that consume
>> several packets before they return a frame will fill said frame wit
James Almer:
> Keeping only the latest packet fed to the decoder works only for decoders that
> return a frame immediately after every consumed packet. Decoders that consume
> several packets before they return a frame will fill said frame with
> properties
> taken from the last consumed packet in
Jan Ekström:
> On Tue, Sep 1, 2020 at 9:56 PM Andreas Rheinhardt
> wrote:
>>
>> Jan Ekström:
>>> On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
>>> wrote:
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavf
On Tue, Sep 1, 2020 at 9:56 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Jan Ekström:
> >>> This enables people to override the sanity check without compiling
> >>> a new binary.
> >>> ---
> >>> libavformat/dashdec.c | 1
Jan Ekström:
> On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
> wrote:
>>
>> Jan Ekström:
>>> This enables people to override the sanity check without compiling
>>> a new binary.
>>> ---
>>> libavformat/dashdec.c | 17 ++---
>>> 1 file changed, 14 insertions(+), 3 deletions(-)
>>>
On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/li
On Tue, Sep 1, 2020 at 9:19 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavf
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..4080b9b650
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..bea9616f4a 1006
> Please elaborate!
Sure, here are some comparisons I just made, please note the huge
difference in speed between current master and n4.0 that I picked as a
representative of the state of the decoder back then.
There are great improvements being made for sure, I still think there could
be some be
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..4080b9b650 100644
--- a/libavformat/dash
> Sure, here are some comparisons I just made, please note the huge
difference in speed between current master and n4.0 that I picked as a
representative of the state of the decoder back then.
Also worth noting that the n4.0 decoder was not even able to transcode the
full sequence properly and out
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..bea9616f4a 100644
--- a/libavformat/dashdec.
On Tue, Sep 1, 2020 at 8:45 PM Jan Ekström wrote:
>
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashde
This is absurdly large, but unfortunately a ~2 hour Youtube
live stream archive can still be around 3.2 megabytes when
requested as MPEG-DASH.
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index bea9616f4
Am Di., 1. Sept. 2020 um 19:32 Uhr schrieb Rémi Achard :
> We can use the native decoder yes, not sure what the state is right now
> though, because I heard that some work was ongoing on that decoder, but
> back then (approx. 1 year ago) it was not really an option due to its poor
> performance, e
> So what problem do you see?
> Yes, we prefer using the native codecs over external dependencies.
ffmpeg -v debug -vcodec libopenjpeg -i
~/Projects/ClairMeta/tests/resources/DCP/ECL-SET/ECL07-SINGLE-CPL_TST-3D-48_S_EN-XX_UK-U_71-ATMOS_2K_ECL_20180301_ECL_SMPTE-3D_OV/ECL07SingleCPL_TST-3D-48_S_EN-
On 9/1/2020 2:00 PM, Andreas Rheinhardt wrote:
> James Almer:
>> diff --git a/libavcodec/packet_internal.h b/libavcodec/packet_internal.h
>> index cdb9a27f2f..387b63169a 100644
>> --- a/libavcodec/packet_internal.h
>> +++ b/libavcodec/packet_internal.h
>> @@ -23,6 +23,51 @@
>>
>> #include "packe
Am Di., 1. Sept. 2020 um 12:14 Uhr schrieb Rémi Achard :
>
> > Do you have a sample that does not work with the native decoder?
>
> According to my tests, the native decoder detect pixel format just fine
So what problem do you see?
Yes, we prefer using the native codecs over external dependencies.
James Almer:
> Signed-off-by: James Almer
> ---
> Not making these public because someone mentioned that the current signature
> for these helpers was ugly (two AVPacketList pointers the caller needs to keep
> around to track the list), and changing it would either require modifying a
> public str
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis
---
Applied both of James' review comments.
---
libavformat/mov.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
On 9/1/2020 1:14 PM, Derek Buitenhuis wrote:
> On 01/09/2020 17:11, James Almer wrote:
>> Oh, you mean how it worked with mfra_size being declared as an int32_t.
>> I was just mentioning why there was a <= 0 check for it. And I guess
>> because no mfra box parsed by lavf was ever bigger than ~2gb,
On 01/09/2020 17:11, James Almer wrote:
> Oh, you mean how it worked with mfra_size being declared as an int32_t.
> I was just mentioning why there was a <= 0 check for it. And I guess
> because no mfra box parsed by lavf was ever bigger than ~2gb, so it
> never failed.
> But yes, it was a bug that
On 9/1/2020 1:06 PM, Derek Buitenhuis wrote:
> On 01/09/2020 17:02, James Almer wrote:
>> How else would you read 32bit signed integers using AVIOContext function
>> helpers if not with avio_rb32()?
>
> The mfra size is not signed. It is an unsigned 32-bit integer.
>
> Spec (mfro is the last part
On 01/09/2020 17:02, James Almer wrote:
> How else would you read 32bit signed integers using AVIOContext function
> helpers if not with avio_rb32()?
The mfra size is not signed. It is an unsigned 32-bit integer.
Spec (mfro is the last part of the mfra):
aligned(8) class MovieFragmentRandomA
On 9/1/2020 12:49 PM, Derek Buitenhuis wrote:
> On 01/09/2020 16:36, James Almer wrote:
>> mfra_size in this function was an int32_t, so storing the output of
>> avio_rb32() could end up with a negative value.
>> It'll no longer be the case now that you made mfra_size in MOVContext an
>> uint32_t.
On 9/1/2020 12:03 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index f0b4edc2ed..49c2d05d21 100644
> --- a/libavformat/mov.c
> +++ b/libavfo
On 01/09/2020 16:36, James Almer wrote:
> mfra_size in this function was an int32_t, so storing the output of
> avio_rb32() could end up with a negative value.
> It'll no longer be the case now that you made mfra_size in MOVContext an
> uint32_t.
How was that ever valid in the first place, conside
On 9/1/2020 12:03 PM, Derek Buitenhuis wrote:
> This also changes a check for mfra_size from < 0 to == 0, since
> it was always wrong, as avio_rb32 returns an unsigned integer.
mfra_size in this function was an int32_t, so storing the output of
avio_rb32() could end up with a negative value.
It'll
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index dcec7
On 8/18/2020 4:53 PM, James Almer wrote:
> More details within each patch.
>
> James Almer (2):
> avcodec/packet: move AVPacketList definition and function helpers over
> from libavformat
> avcodec/decode: use a packet list to store copies of packets fed to
> the decoder
>
> libavcod
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buite
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f0b4edc2ed..49c2d05d21 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5094,7 +5094,7 @@ static int mov_read_sidx(MOVCon
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.
On 9/1/20, Xu Jun wrote:
> Hi, Mark
>
> - Original Message -
>> From: "Mark Thompson"
>> To: "FFmpeg development discussions and patches"
>> Sent: Tuesday, September 1, 2020 4:41:06 AM
>> Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for
>> dnn_backend_native_laye
On Tue, Sep 1, 2020 at 5:22 PM Harry Mallon wrote:
>
>
>
>
> > On 12 Aug 2020, at 21:58, Vittorio Giovara
> > wrote:
> >
> > On Wed, Aug 12, 2020 at 6:40 PM Mohammad Izadi wrote:
> >
> >> Vittorio,
> >>
> >> What is the next step for me?
> >>
> >> Thanks,
> >> Mohammad
> >>
> >
> > Hi, I don't
Hi, Mark
- Original Message -
> From: "Mark Thompson"
> To: "FFmpeg development discussions and patches"
> Sent: Tuesday, September 1, 2020 4:41:06 AM
> Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for
> dnn_backend_native_layer_conv2d.c
> On 31/08/2020 18:03,
Hi.
Please upload this file to FATE servers.
http://trac.ffmpeg.org/raw-attachment/ticket/8872/200828-005.wav
Will add chapter/cue test later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
> On 12 Aug 2020, at 21:58, Vittorio Giovara wrote:
>
> On Wed, Aug 12, 2020 at 6:40 PM Mohammad Izadi wrote:
>
>> Vittorio,
>>
>> What is the next step for me?
>>
>> Thanks,
>> Mohammad
>>
>
> Hi, I don't have any more comments for the patch, except that it would be
> nice if there were
On 9/1/2020 9:14 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-08-31 04:59:54)
>> Fixes memleaks with some encoders that don't unref the packet before
>> returning.
>> This is consistent with the behavior of AVCodec.encode()
>> implementations in encode_simple_internal().
>>
>> Found-by: mkv
On 9/1/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-08-31 14:20:11)
>> Support parsing 'cue ' and 'adtl' chunks.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/wavdec.c | 50
>> 1 file changed, 50 insertions(+)
>
> Looks ok beyond so
Quoting James Almer (2020-08-31 04:59:54)
> Fixes memleaks with some encoders that don't unref the packet before
> returning.
> This is consistent with the behavior of AVCodec.encode()
> implementations in encode_simple_internal().
>
> Found-by: mkver
> Signed-off-by: James Almer
> ---
> libavco
Quoting Paul B Mahol (2020-08-31 14:20:11)
> Support parsing 'cue ' and 'adtl' chunks.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/wavdec.c | 50
> 1 file changed, 50 insertions(+)
Also, FATE tests would be nice.
--
Anton Khirnov
__
Quoting Paul B Mahol (2020-08-31 14:20:11)
> Support parsing 'cue ' and 'adtl' chunks.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/wavdec.c | 50
> 1 file changed, 50 insertions(+)
Looks ok beyond some nits.
>
> diff --git a/libavformat/wav
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 26 ++
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/utils.c | 2 ++
6 files changed, 38 insertions(+)
diff -
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/moflex.c | 360 +++
3 files changed, 362 insertions(+)
create mode 100644 libavformat/moflex.c
diff --git a/libavformat/Makefile b/libavformat/
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/codec_desc.c |7 +
libavcodec/codec_id.h |1 +
libavcodec/mobiclip.c | 1427 +++
5 files changed, 1437 insertions(+)
create mode 100644 l
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mods.c | 100 +++
3 files changed, 102 insertions(+)
create mode 100644 libavformat/mods.c
diff --git a/libavformat/Makefile b/libavformat/Ma
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/fastaudio.c | 200
libavcodec/utils.c | 2 +
6 files changed, 212 insert
Quoting Paul B Mahol (2020-08-31 23:37:07)
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/qpeg.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
> index 40931e3bdc..8bc710acfd 100644
> --- a/libavcodec/qpeg.c
> +++ b/libavco
> * 3D SMPTE MXF
Typo, this is 2D SMPTE MXF, there are 3D versions in that same repo
however, but it probably don't matter much here.
Le mar. 1 sept. 2020 à 11:06, Rémi Achard a écrit :
> > Do you have a sample that does not work with the native decoder?
>
> According to my tests, the native de
> Do you have a sample that does not work with the native decoder?
According to my tests, the native decoder detect pixel format just fine,
I'm talking about the libopenjpeg wrapper here (ie. libopenjpegdec.c).
As for sample materials, I guess you can check this link
https://github.com/Ymagis/Cla
Paul B Mahol:
> On 8/31/20, Andreas Rheinhardt wrote:
>> When the MagicYUV decoder builds Huffman tables from an array of code
>> lengths, it proceeds as follows: First it copies the entries of the
>> array of lengths into an array of HuffEntries (a struct which contains
>> a length and a symbol f
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Tuesday, September 1, 2020 5:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] cbs_av1: Fill tile width/height values when
> uniform_tile_spacing_flag is set
>
> They are not explicitly
75 matches
Mail list logo
