>in case of errors, the context is left in an inconsistent state: The
>PacketDesc linked-list claims that there is data in the FIFO although this is
>wrong. I always prefer avoiding such scenarios over fixing them lateron. In
>this case, fixing them would mean growing the FIFO before >allocating
On Fri, 1 Apr 2022, Martin Storsjö wrote:
On Thu, 31 Mar 2022, Ben Avison wrote:
The VC1 decoder was missing lots of important fast paths for Arm,
especially
for 64-bit Arm. This submission fills in implementations for all functions
where a fast path already existed and the fallback C impleme
Am 28.03.22 um 13:01 schrieb Thilo Borgmann:
Am 22.03.22 um 09:36 schrieb Thilo Borgmann:
Am 18.03.22 um 15:04 schrieb Paul B Mahol:
On 3/18/22, Thilo Borgmann wrote:
On 12 Mar 2022, at 10:06, Thilo Borgmann wrote:
Am 09.03.22 um 18:31 schrieb Paul B Mahol:
On 3/8/22, Thilo Borgmann wro
Since the switch to the new FIFO API in commit
ea511196a6c85eb433e10cdbecb0b2c722faf20d, the FIFO is always
grown by the amount of data intended to be written into it
even in case the FIFO has enough free space. Fix this by
only growing the FIFO if needed and then only by the amount that is
actuall
The texDesc.Format needs to be filled in with a corresponding format. I
add a format check to initialize the format in case sometimes the
ctx->internal->priv is not initialized, such as during the hwmap
process.
For example, for sample command line: ffmpeg.exe -hwaccel qsv -c:v h264_qsv
-i input.2
When uploading rawvideos using d3d11va hardware framecontext, the bindflag
is not initialized and will cause creating texture failure. Now fix it,
assign it the value of D3D11_BIND_RENDER_TARGET.
Signed-off-by: Tong Wu
---
libavutil/hwcontext_d3d11va.c | 5 +
1 file changed, 5 insertions(+)
For hwmap between qsv and d3d11va, The mfxHDLPair information should be
put into texture_infos when deriving from qsv context. Moreover, when
uploading from rawvideo, the ways that the textures are created are
different, bindflag assertions are needed to make sure the right
textures are derived dur
Applied as 234c824820d4c17612c9745e74ef6c934679d138 (with minor changes)
On Thu, 31 Mar 2022 13:34:30 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Signed-off-by: Niklas Haas
> ---
> Changes in v2:
> - expand documentation of tone mapping curves
> - slight rewording of some sections
> - add
Ping
On Thu, Mar 24, 2022 at 6:26 PM Danil Chapovalov wrote:
>
> ---
> libavcodec/libvpxenc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index dff1d06b0e..5db31db5dc 100644
> --- a/libavcodec/libvpxenc.c
> ++
Fixes:
46194/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-580292873827123
Fixes: stack-buffer-overflow on address 0x7ffc0ce69b30 at pc 0x0062fb03 bp
0x7ffc0ce69af0 sp 0x7ffc0ce69ae8
Fixes:
46205/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5354
This ignores >64bit
Alternatively we could support that if it occurs in reality
Fixes: negation of -9223372036854775808
Fixes: integer overflows
Fixes:
46072/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5029840966778880
Found-by: continuous fuzzing process
https://github.com/google
Hi ffmmpeg developers,
As you may know, we are working hard on the Matroska specifications at
the IETF. We already got EBML as an RFC [1]. We are in the process of
finalizing the main Matroska document. Before we submit the document for
formal review before "final" publishing, we would like pe
On 2022-04-01 14:33, Steve Lhomme wrote:
Hi ffmmpeg developers,
As you may know, we are working hard on the Matroska specifications at
the IETF. We already got EBML as an RFC [1]. We are in the process of
finalizing the main Matroska document. Before we submit the document for
formal review b
Niklas Haas:
> From: Niklas Haas
>
> We re-use the PNGEncContext.zstream for deflate-related operations.
> Other than that, the code is pretty straightforward. Special care needs
> to be taken to avoid writing more than 79 characters of the profile
> description (the maximum supported).
>
> To w
On Fri, Apr 01, 2022 at 02:23:23AM +0200, Mark Gaiser wrote:
> On Fri, Apr 1, 2022 at 2:09 AM Mark Gaiser wrote:
>
> > This patch adds support for:
> > - ffplay ipfs://
> > - ffplay ipns://
> >
> > IPFS data can be played from so called "ipfs gateways".
> > A gateway is essentially a webserver th
The doc says those function are like av_free if size or nmemb is
zero. It doesn't match the code. av_realloc() realloc one byte if
size is zero, which was added by 91ff05f6ac5 ten years ago.
realloc() itself in C is implementation-dependent. Make the doc
match the longstanding behaviour.
---
libav
Am 01.04.22 um 10:58 schrieb Thilo Borgmann:
Am 28.03.22 um 13:01 schrieb Thilo Borgmann:
Am 22.03.22 um 09:36 schrieb Thilo Borgmann:
Am 18.03.22 um 15:04 schrieb Paul B Mahol:
On 3/18/22, Thilo Borgmann wrote:
On 12 Mar 2022, at 10:06, Thilo Borgmann wrote:
Am 09.03.22 um 18:31 schrieb
This makes the filters match their declaration in
libavfilter/allfilters.c; the earlier discrepancy was btw UB.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_libplacebo.c | 2 +-
libavfilter/vf_overlay_vaapi.c | 2 +-
libavfilter/vf_siti.c | 2 +-
libavfilter/vf
lgtm
___
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 Mar 31, 2022, at 7:44 PM, Anton Khirnov wrote:
>
> Quoting Andreas Rheinhardt (2022-03-31 00:49:57)
>> From: Andreas Rheinhardt
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> doc/APIchanges| 3 +++
>> fftools/ffmpeg.c | 4 ++--
>> fftools/ffprobe.c | 2 +-
>
20 matches
Mail list logo
