Similar to what is currently done for other components, e.g. (de)muxers.
There is nothing in the public part currently, but that will change in
future commits.
---
fftools/ffmpeg.h | 4 +-
fftools/ffmpeg_dec.c | 193 ++-
2 files changed, 104 insertions
Log decoder messages to the decoder rather than InputStream.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 2 +
fftools/ffmpeg_dec.c | 92
2 files changed, 60 insertions(+), 34 deletions(-)
diff --git a/fftools
Also perform them earlier.
---
fftools/ffmpeg_filter.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 82ee4fae7d..4b660002ed 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -663,6
---
fftools/ffmpeg.h | 3 +-
fftools/ffmpeg_dec.c | 90 ++
fftools/ffmpeg_demux.c | 16 +---
3 files changed, 60 insertions(+), 49 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 4c9424d02f..f0f57d48bc 100644
--- a/fftools/f
This way the encoder does not need to access the decoder AVCodecContext,
which will allow to make it private in future commits.
---
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_dec.c | 3 +++
fftools/ffmpeg_enc.c | 19 ++-
3 files changed, 15 insertions(+), 10 deletions(-)
diff
* as this decision is based on demuxing information, move it from the
decoder to the demuxer
* as the issue being addressed is latency added by frame threading, we
only need to disable frame threading, not all threading
---
fftools/ffmpeg_dec.c | 3 ---
fftools/ffmpeg_demux.c | 5 +
2 fi
Reduces the need to access InputFile from decoding.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 5 ++---
fftools/ffmpeg_dec.c | 8
fftools/ffmpeg_demux.c | 5 ++---
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/fftools/ffmpe
---
fftools/ffmpeg_dec.c | 12
1 file changed, 12 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index baaba966c6..00428dff48 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -263,18 +263,6 @@ static int video_frame_process(InputStream *ist, AVFr
It is done based on demuxer information, so that is the more appropriate
place for this code.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg_dec.c | 9 -
fftools/ffmpeg_demux.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/f
Will be useful in the following commit.
---
fftools/ffmpeg.h | 4 +++-
fftools/ffmpeg_dec.c | 4 ++--
fftools/ffmpeg_demux.c | 7 ---
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index abf95f106b..b4288e7352 100644
--- a/fftools/ffm
This function is decoding-only and has no interaction with the rest of
ffmpeg_hw. It thus belongs more properly in ffmpeg_dec.
---
fftools/ffmpeg.h | 2 --
fftools/ffmpeg_dec.c | 42 ++
fftools/ffmpeg_hw.c | 42 -
Do not build it from InputStream values.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_dec.c | 17 +++--
fftools/ffmpeg_demux.c | 4
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.h
Do not retrieve it from InputStream directly.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_dec.c | 2 +-
fftools/ffmpeg_demux.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg
Stop reading them from InputStream.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 7 +++
fftools/ffmpeg_dec.c | 15 ++-
fftools/ffmpeg_demux.c | 6 ++
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.h
Stop reading them from InputStream.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 16 +-
fftools/ffmpeg_dec.c | 67 +++---
fftools/ffmpeg_demux.c | 36 ---
3 files changed, 65 insertions(+)
Previously, the demuxer would register decoder with the scheduler, using
InputStream as opaque, and pass the scheduling index to the decoder.
Now the registration is done by the decoder itself, using DecoderPriv as
opaque, and the scheduling index is returned to demuxer from dec_open().
decoder_t
It is no longer used outside of ffmpeg_demux.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_demux.c | 16 +---
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 29d8ea4355..8395fd260c 100644
--- a/fftools/ffmpeg.h
+++ b/fftools
It is no longer used outside of ffmpeg_demux.
---
fftools/ffmpeg.h | 3 ---
fftools/ffmpeg_demux.c | 13 +
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 4881174632..29d8ea4355 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/
The same information can also be obtained from the decoder itself.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg_dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 6c8f08d33e..
Do not read it from InputStream directly.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 3 +++
fftools/ffmpeg_dec.c | 2 +-
fftools/ffmpeg_demux.c | 6 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmp
---
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_dec.c | 50 +++---
fftools/ffmpeg_demux.c | 4 +++-
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 02c614d0ff..c8cba72006 100644
--- a/fftools/ffmp
Do not retrieve it from InputStream directly.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_dec.c | 4 ++--
fftools/ffmpeg_demux.c | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpe
Do not read it from AVStream directly.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_dec.c | 5 +
fftools/ffmpeg_demux.c | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
---
fftools/ffmpeg_dec.c | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index fd1c9ca609..98cde0a040 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -221,9 +221,8 @@ static void a
---
fftools/ffmpeg.h | 54 +---
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 8395fd260c..33750e0bb3 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -328,35 +328,36 @@ typedef struct Dec
---
fftools/ffmpeg_dec.c | 7 ---
fftools/ffmpeg_demux.c | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 00428dff48..d16049ab4c 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -898,13 +898,6 @@ int
Setting demuxer's video_delay from the decoder cannot accomplish
anything meaningful and is racy, as they run in different threads.
---
fftools/ffmpeg_dec.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 4a59a4b392..baaba966c6
Rather than access the dictionary in InputStream.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 7 ++-
fftools/ffmpeg_dec.c | 17 +
fftools/ffmpeg_demux.c | 3 ++-
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/ff
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 11 +--
fftools/ffmpeg_dec.c | 16
fftools/ffmpeg_demux.c | 4 ++--
3 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 227929b
Rather than access the AVStream one.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg_dec.c | 9 +++--
fftools/ffmpeg_demux.c | 3 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index d16049ab4c..b
Pass this information to dec_open() instead.
This is a step towards decoupling Decoder and InputStream.
---
fftools/ffmpeg.h | 6 +-
fftools/ffmpeg_dec.c | 13 +
fftools/ffmpeg_demux.c | 3 ++-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpe
On Tue, Jan 23, 2024 at 8:44 PM Tomas Härdin wrote:
> tis 2024-01-23 klockan 11:33 +0300 skrev Victor Luchitz:
> > Re-posting the patch as an attachment. Sorry for the inconvenience!
>
> Yep, this one applies and also passes FATE.
>
> I notice ffplay_buffer whines a lot when playing RoQ files:
>
---
fftools/ffmpeg_sched.c | 27 +--
fftools/ffmpeg_sched.h | 7 +++
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 4fc5a33941..c6ed2e21ff 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sc
---
tests/fate/ffmpeg.mak | 10 ++
tests/ref/fate/ffmpeg-filter-in-eof | 55 +
2 files changed, 65 insertions(+)
create mode 100644 tests/ref/fate/ffmpeg-filter-in-eof
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 84489e9fea..8c2f0
There may be other inputs or sources in the filtergraph. Propagate the
EOF to the scheduler and continue filtering.
Fixes #10803
---
fftools/ffmpeg_filter.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 82ee4fae7d..ab64b4610a 100
Quoting Victor Luchitz (2024-01-23 09:33:04)
> Re-posting the patch as an attachment. Sorry for the inconvenience!
>
> --
> Best regards,
> Victor Luchitz
>
> From b6825112446ee220d89cab975e8bcef823884141 Mon Sep 17 00:00:00 2001
> From: Victor Luchits
> Date: Tue, 23 Jan 2024 11:27:07 +0300
>
Quoting Chen Yufei (2024-01-20 16:14:29)
> Usage: "vpp_qsv=lut3d_file="
Passing file paths to a filter and having the filter load the file is
not recommended, it is generally preferable to have an
AV_OPT_TYPE_BINARY option, with IO performed by the caller.
E.g. in ffmpeg CLI you can do
-filter v
Quoting Dai, Jianhui J (2024-01-23 03:58:24)
> This commit adds value range checks to cbs_vp8_read_unsigned_le,
> migrates fixed() to use it, and enforces little-endian consistency for
> all read methods.
>
> The VP8 compressed header may not be byte-aligned due to boolean coding.
> Use bitwise co
Signed-off-by: J. Dekker
---
tests/checkasm/hevc_deblock.c | 225 +-
1 file changed, 195 insertions(+), 30 deletions(-)
- added luma 10/12 bit
- supporting full (*_c) luma & chroma functions
- dynamically generating all test data
Appears to work for me. Testing o
Jan 24, 2024, 08:40 by an...@khirnov.net:
> Quoting Lynne (2024-01-23 21:18:29)
>
>> Jan 23, 2024, 20:22 by mich...@niedermayer.cc:
>>
>> > Hi all
>> >
>> > As it was a little difficult for me to not loose track of what is
>> > blocking a release. I suggest that for all release blocking issues
>>
On 1/24/2024 4:40 AM, Anton Khirnov wrote:
Quoting Lynne (2024-01-23 21:18:29)
Jan 23, 2024, 20:22 by mich...@niedermayer.cc:
Hi all
As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket and set Block
On 1/24/2024 4:45 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-01-23 20:22:41)
Hi all
As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket and set Blocking to 7.0
that way this:
https://t
Quoting Lynne (2024-01-24 13:07:51)
> Which part of "don't consider as blockers" did you find difficult to
> understand?
> I even added newlines top and bottom for you to laser onto that sentence.
Then why are you mentioning them in a thread specifically about release
blockers.
> I have started
On Tue, 23 Jan 2024 20:22:41 +0100 Michael Niedermayer
wrote:
> Hi all
>
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/que
Quoting Marth64 (2024-01-16 00:51:14)
> Hello, I wanted to call out 2 issues that I think are bugs from this, and
> that I was able to trace to the exact commit.
>
> *#1: Concat filter issues: *A user from IRC support reported it, and I was
> able to successfully reproduce it.
> When using concat
Jan 24, 2024, 13:30 by an...@khirnov.net:
> Quoting Lynne (2024-01-24 13:07:51)
>
>> Which part of "don't consider as blockers" did you find difficult to
>> understand?
>> I even added newlines top and bottom for you to laser onto that sentence.
>>
>
> Then why are you mentioning them in a thread
Quoting Lynne (2024-01-24 14:14:00)
> Jan 24, 2024, 13:30 by an...@khirnov.net:
> >> I have started on everything, and two things are finished but need polish,
> >> one is difficult and needs debugging while the other is more difficult.
> >>
> >> And with that release rate attitude, how do you thin
Jan 24, 2024, 14:24 by an...@khirnov.net:
> Quoting Lynne (2024-01-24 14:14:00)
>
>> Jan 24, 2024, 13:30 by an...@khirnov.net:
>> >> I have started on everything, and two things are finished but need polish,
>> >> one is difficult and needs debugging while the other is more difficult.
>> >>
>> >>
On Wed, 24 Jan 2024, J. Dekker wrote:
Signed-off-by: J. Dekker
---
tests/checkasm/hevc_deblock.c | 225 +-
1 file changed, 195 insertions(+), 30 deletions(-)
- added luma 10/12 bit
- supporting full (*_c) luma & chroma functions
- dynamically generating all test
>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
>
Is VVC being run through oss-fuzz yet? I think it would be a shame for 7.0
to be released then a ton of CVEs come out and the security community
hysterically saying FFmpeg
James Almer:
> A 128 byte buffer may not be enough for some layouts with lots of channels.
>
> Signed-off-by: James Almer
> ---
> libavutil/opt.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index 0908751752..814b485a1
James Almer:
> Finishes fixing vp5/potter512-400-partial.avi
>
> The fate-matroska-ms-mode test ref is updated to reflect that the Speex
> decoder
> can now read the stream.
>
> Signed-off-by: James Almer
> ---
> libavcodec/speexdec.c | 4 +---
> tests/ref/fate/matroska-ms-mode | 2 +
Fixes a regression since d9fed9df2a, where the single animated stream would
be exported twice as two independent streams.
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 147 ++---
2 files changed, 99 insertions(+), 49 delet
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 8
libavformat/avformat.h | 86 ++
libavformat/dump.c | 36 ++
libavformat/options.c | 32
4 fil
Export each tile as its own stream, and the tiling information as a Stream
Group of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.
Based on
Signed-off-by: James Almer
---
tests/fate/mov.mak | 2 +-
tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index f202f36d96..f549ae33d7
James Almer:
> Signed-off-by: James Almer
> ---
> libavformat/Makefile | 1 +
> libavformat/avformat.c| 171
> libavformat/demux.h | 29 ---
> libavformat/internal.h| 319 +---
> libavformat/stream.c | 196 +++
On 1/24/2024 12:14 PM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavformat/Makefile | 1 +
libavformat/avformat.c| 171
libavformat/demux.h | 29 ---
libavformat/internal.h| 319 +--
On 1/24/2024 11:35 AM, Andreas Rheinhardt wrote:
James Almer:
Finishes fixing vp5/potter512-400-partial.avi
The fate-matroska-ms-mode test ref is updated to reflect that the Speex decoder
can now read the stream.
Signed-off-by: James Almer
---
libavcodec/speexdec.c | 4 +---
test
Use 8 packets/frames by default rather than 1, which seems to provide
better throughput.
Allow -thread_queue_size to set the muxer queue size manually again.
---
fftools/ffmpeg_mux.h | 2 --
fftools/ffmpeg_mux_init.c| 3 +--
fftools/ffmpeg_opt
Anton Khirnov:
> Use 8 packets/frames by default rather than 1, which seems to provide
> better throughput.
>
> Allow -thread_queue_size to set the muxer queue size manually again.
> ---
> fftools/ffmpeg_mux.h | 2 --
> fftools/ffmpeg_mux_init.c
Signed-off-by: Connor Worley
---
tests/fate/video.mak| 7 +++
tests/ref/fate/dxv3enc-dxt1 | 6 ++
2 files changed, 13 insertions(+)
create mode 100644 tests/ref/fate/dxv3enc-dxt1
diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index 4e7a77537f..fbc8a1a682 100644
--- a/t
Adds tests to cover decoding YCoCg DXV3 formats with and without alpha
Samples:
https://connorworley.com/fate-suite/dxv/dxv3-hqna.mov
https://connorworley.com/fate-suite/dxv/dxv3-hqwa.mov
Signed-off-by: Connor Worley
---
tests/fate/video.mak | 6 ++
tests/ref/fate/dxv3-ycg6 | 6 ++
t
Quoting Andreas Rheinhardt (2024-01-24 20:35:48)
> > diff --git a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > b/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > index bc9b833799..3a3ec96637 100644
> > --- a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > +++ b/tests/ref/fate/ffmp
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dxvenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index 3a5b310c9b..10473038cc 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -56,7 +56,7 @@ static void ht_
The old code set a common struct from each thread;
this only "worked" (but is still UB) because the values
written are the same for each thread.
Fix this by moving the assignments to the main thread.
(This also avoids casting const away from a const AVFrame*.)
Signed-off-by: Andreas Rheinhardt
-
Namely calling avctx->execute2(avctx,...).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dds.c | 2 +-
libavcodec/dxvenc.c | 2 +-
libavcodec/hapdec.c | 2 +-
libavcodec/hapenc.c | 2 +-
libavcodec/texturedsp.c | 2 +-
libav
ff_texturedspenc_init() doesn't support most of the function types
supported for decoding; add a separate context containing only pointers
for the actually supported types.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dxvenc.c| 2 +-
libavcodec/hapenc.c| 2 +-
libavcodec/text
It presumably exists because HapContext contains an AVClass*.
Yet AVClass is actually defined in log.h and even this inclusion
can be avoided by struct AVClass*. This avoids opt.h inclusions
in hap.c and hapdec.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hap.h | 5 ++---
li
Only used during init.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dxvenc.c | 6 +++---
libavcodec/hap.h| 1 -
libavcodec/hapdec.c | 15 ---
libavcodec/hapenc.c | 9 +
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/libavcodec/dxvenc.c b/libavcode
Effectively reverts 50a20de6b9edd1d893fe0ea652ccf796dd9850fb.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/texturedspenc.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/libavcodec/texturedspenc.c b/libavcodec/texturedspenc.c
index 7ae28ea134..54cf6fe6e0 100644
--- a/l
Thanks for fixing this :)
Are you planning more work on the DXV side following this? I have a patch
to follow that replaces `decompress_texture_thread` with purely
texdsp calls (HQ BC4/BC5 textures can be decompressed with
`rgtc1u_gray_block`).
On Wed, Jan 24, 2024 at 11:49 AM Andreas Rheinhardt <
You're right, this is actually a part that's not necessarily tied to bitrate
support, I'll move it to a separate patch.
On Wed, Jan 24, 2024 at 2:06 PM Anton Khirnov wrote:
> Quoting Victor Luchitz (2024-01-23 09:33:04)
> > Re-posting the patch as an attachment. Sorry for the inconvenience!
> >
ons 2024-01-24 klockan 11:50 +0300 skrev Victor Luchitz:
> On Tue, Jan 23, 2024 at 8:44 PM Tomas Härdin wrote:
> >
> > Anyway, using -b:v 100k causes the encoder to effectively become
> > stuck
> > on the first frame, being unable to go below 621 kbps and
> > increasing
> > qscale very slowly. Bu
In our case, the machine we're targeting (the Sega 32X) has only 256KB
of RAM. Even more modern consoles such as XBOX or even PS3 didn't
have enough RAM to hold an entire CD-ROM..
We also have to be concerned about how fast we can move data to the
main CPU. Say you make the first frame BIG to make
tor 2024-01-25 klockan 01:09 +0300 skrev Victor Luchitz:
> In our case, the machine we're targeting (the Sega 32X) has only
> 256KB
> of RAM. Even more modern consoles such as XBOX or even PS3 didn't
> have enough RAM to hold an entire CD-ROM..
>
> We also have to be concerned about how fast we ca
On Wed, Jan 24, 2024 at 01:06:34PM +0100, J. Dekker wrote:
> Signed-off-by: J. Dekker
> ---
> tests/checkasm/hevc_deblock.c | 225 +-
> 1 file changed, 195 insertions(+), 30 deletions(-)
>
> - added luma 10/12 bit
> - supporting full (*_c) luma & chroma functions
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Wednesday, January 24, 2024 7:41 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Use little endian in
> fixed() and improve the pos check
>
> Quoting Dai, Jianhui J
This commit adds value range checks to cbs_vp8_read_unsigned_le,
migrates fixed() to use it, and enforces little-endian consistency for
all read methods.
Signed-off-by: Jianhui Dai
---
libavcodec/cbs_vp8.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git
The VP8 compressed header may not be byte-aligned due to boolean
coding. Use bitwise comparison to prevent the potential overread.
Signed-off-by: Jianhui Dai
---
libavcodec/cbs_vp8.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp
On Wed, Jan 24, 2024 at 09:16:57AM +0100, Anton Khirnov wrote:
> ---
> fftools/ffmpeg.h | 3 ++-
> fftools/ffmpeg_dec.c | 50 +++---
> fftools/ffmpeg_demux.c | 4 +++-
> 3 files changed, 37 insertions(+), 20 deletions(-)
This causes segfaults:
(ill ma
Connor Worley:
> Thanks for fixing this :)
> Are you planning more work on the DXV side following this? I have a patch
> to follow that replaces `decompress_texture_thread` with purely
> texdsp calls (HQ BC4/BC5 textures can be decompressed with
> `rgtc1u_gray_block`).
>
I don't intend to work on
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM decoding in-place and
add support for Dolby-E decoding.
Useful for direct transcoding of non-PCM audio in live inputs.
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m
83 matches
Mail list logo