On Wed, Aug 9, 2023 at 2:35 PM Rémi Denis-Courmont wrote:
>
>
>
> Le 9 août 2023 15:02:45 GMT+03:00, David Rosca a écrit :
> >Support for allocating frames with x2rgb10 format was added
> >in c00264f5013, this adds support for importing DMA-BUFs.
> >---
>
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
v2: fix #ifdef -> #if
v3: annotate
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
On Tue, Aug 15, 2023 at 9:25 PM Mark Thompson wrote:
>
> On 15/08/2023 20:09, Mark Thompson wrote:
> > On 15/08/2023 09:02, Xiang, Haihao wrote:
> >> On Ma, 2023-08-07 at 09:27 +0200, David Rosca wrote:
> >>> v2: Add description in encoders.texi
> >>&
ping
On Tue, Jul 4, 2023 at 3:17 AM David Lou
wrote:
> Fix the fact that ffprobe no longer detects m3u8 in a data url correctly.
>
> For example,
>
> ffprobe
> data:application/vnd.ap
Currently the flag eos_reached is set to 1 on end of stream
and there is no mechanism to reset it to 0. After a flush new
buffers should be able to be decoded but the eos_reached flag
causes all the frames to be dropped. Reset the eos_reached flag
to 0 during the flush operation to allow new frames
nd I would like to get it into the
mainline code mostly just to save
having to remember to port it whenever i pull new code.
regards,
David Sowa
On Mon, Oct 26, 2020 at 4:26 PM David Sowa wrote:
> Currently the flag eos_reached is set to 1 on end of stream
> and there is no mechanism to reset
option to disable printing input offsets and delete
all newline characters to output continuous hex values to grep.
Signed-off-by: David Michael
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 2f02d7f5c8..52c02a74c8 100755
--- a/confi
On Wed, Nov 11, 2020 at 5:18 PM Martin Storsjö wrote:
> On Wed, 11 Nov 2020, David Michael wrote:
> > There are two issues:
> >
> > The unused global integer does not make it into the compiled object
> > file, so declare it static to correct this.
>
>
On Wed, Nov 11, 2020 at 6:20 PM Carl Eugen Hoyos wrote:
> Am Mi., 11. Nov. 2020 um 16:30 Uhr schrieb David Michael
> :
> > There are two issues:
> >
> > The unused global integer does not make it into the compiled object
> > file, so declare it static to correct
On Thu, Nov 12, 2020 at 2:56 AM Carl Eugen Hoyos wrote:
> > Am 12.11.2020 um 00:41 schrieb David Michael :
> >> On Wed, Nov 11, 2020 at 6:20 PM Carl Eugen Hoyos
> >> wrote:
> >>> Am Mi., 11. Nov. 2020 um 16:30 Uhr schrieb David Michael
> >>> :
&g
, so the expected value will not
be matched when its four bytes are split across two lines. Use the
POSIX "-A n" option to disable printing input offsets and delete
all newline characters to output continuous hex values to grep.
Signed-off-by: David Michael
---
configure | 5 +++--
1 fi
On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos wrote:
> Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael
> :
> >
> > There are two issues:
> >
> > When build systems enable LTO in CFLAGS, the unused global integer
> > does not make it into the co
On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos wrote:
> Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael
> :
> > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos wrote:
> > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael
> > > :
> &
On Sat, Nov 14, 2020 at 8:21 PM David Michael wrote:
> On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos wrote:
> > Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael
> > :
> > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos
> > > wrote:
> >
---
libavcodec/vaapi_encode_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index dd17be2..d6926c4 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -350,7 +350,7 @@ static
On Mon, Jan 9, 2023 at 3:22 AM Xiang, Haihao wrote:
>
> On Do, 2022-12-29 at 22:20 +0100, David Rosca wrote:
> > ---
> > libavcodec/vaapi_encode_h264.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h26
v2: frame_num steps by 2
---
libavcodec/vaapi_encode_h264.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 7a6b54ab6f..8093c47179 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_en
On Mon, Jan 9, 2023 at 10:11 PM Mark Thompson wrote:
>
> On 09/01/2023 07:37, David Rosca wrote:
> > On Mon, Jan 9, 2023 at 3:22 AM Xiang, Haihao wrote:
> >>
> >> On Do, 2022-12-29 at 22:20 +0100, David Rosca wrote:
> >>> ---
> >>> libavc
v3: pic_order_cnt steps by 2
---
libavcodec/vaapi_encode_h264.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f15bcc6..de0951f 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_e
Hi here little patch for avutil.
Kind regards.
0001-avutil-silencing-const-qualifier-warning.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit li
It was necessary to change the email subscription, because I had used to
subscribe was an alias.
The vc1 decoder could need frame parallelization.
That being said, what normally happens is that
you decide on which part of FFmpeg you would
like to work on and start sending patches. In
theory, th
Eugen Hoyos wrote:
David Ison dtison.net> writes:
(And I suspect parallelization of vc1 is not
an easy task.)
Thank you for any contribution!
Are you referring to the file
libavcodec/vc1.c ?
To libavcodec/vc1*, yes
An easier choice may be parallelization of the
scale filter: It
Begin by identifying portions where the processing can be arranged to
run in parallel, with as little data dependencies as possible between
processing threads.
So far we have identified two possible candidates:
The vc1 decoder
libavcodec/vc1.c
and
the scale filter
scale filter (l
These are some general ideas I have developed about how to approach this.
Parallelization Strategy and Goals:
1. Implement in such manner as can easily be disabled and the program
runs in serial with the same results as the parallel version.
2. The parallel version likewise produces the sam
/ Container Technology at the Moment?
2.3 I guess you just want Remote Access and doing the Migration by yourself?
Thats it for now.
Best Regards,
David
David Sterz
Technischer Projektleiter / Technical Projectleader
G&L Geißendörfer & Leschin
Hi everyone!
My name is David Reidler and I am an undergraduate student looking to
participate in GSoC 2015. My IRC handle on freenode is dreidler.
After reviewing the ideas on the wiki page, I would like to work on
implementing basic servers for network protocols.
I enjoy programming in C
ion 2.6.2-2015-04-13-71430-g4d74c8d Copyright (c) 2000-2015 the
FFmpeg developers
built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
configuration: --cc=/usr/bin/clang --prefix=/david-favor/osx-10.9.5 --mandir=/david-favor/osx-10.9.5/share/man --enable-gpl --enable-yasm --ar
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
imac> avinfo clip.mts
clip.mts
length: 00:01:00
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
https://trac.ffmpeg.org/ticket/974 seems to be a ticket
David Favor wrote:
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
https://trac.ffmpeg.org/ticket/974
Michael Niedermayer wrote:
On Mon, Apr 13, 2015 at 04:36:18PM -0500, David Favor wrote:
David Favor wrote:
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4
work [0], a few weeks ago, I assigned it to Michael Niedermayer as a last
resort but I was told on IRC he is super busy.[0]
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200511143159.19390-1-da...@andreoletti.net/
Any volunteer :-) ?
On Mon, May 25, 2020 4:27 AM, David Andreoletti da...@
On Fri, Dec 22, 2023 at 8:10 AM Romain Beauxis wrote:
> This patch populates the third entry for HLS codec attribute using the
> AAC profile.
>
> The HLS specifications[1] require this digit to be the Object Type ID as
> referred to in table 1.3 of ISO/IEC 14496-3:2009[2].
>
> The numerical const
On Wed, Nov 8, 2023 at 6:38 PM Steven Liu wrote:
> David Johansen 于2023年11月9日周四 07:47写道：
> >
> > On Fri, Oct 27, 2023 at 1:33 AM Steven Liu
> wrote:
> >
> > > David Johansen 于2023年10月27日周五 12:03写道：
> > > >
> > > > >
> >
>
> I love this change, but it appears that st->codecpar->profile is always
> AV_PROFILE_UNKNOWN when using libfdk_aac as the encoder. Any indications
> where I should look for fix that so this can be used with that encoder?
>
It appears that the issue is that profile doesn't default to what's bei
On Sat, Dec 30, 2023 at 8:23 AM Romain Beauxis wrote:
> Le jeu. 28 déc. 2023 à 17:26, David Johansen a
> écrit :
> >>
> >> I love this change, but it appears that st->codecpar->profile is always
> AV_PROFILE_UNKNOWN when using libfdk_aac as the encoder. Any indi
This is a build failure in the master branch as a result of commit
e37b15e26fbc7bc31a86a4a2c7c798e20d4f4c2c:
There is no type AVMediaType prior to macOS 10.13.
---
libavdevice/avfoundation.m | 4
1 file changed, 4 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundat
On Mon, Jan 1, 2024 at 9:08 AM Michael Niedermayer
wrote:
>
> error: corrupt patch at line 19
>
Sorry, I have also attached the patch file to this message.
---
libavdevice/avfoundation.m | 4
1 file changed, 4 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation
On Mon, Jan 1, 2024 at 9:26 AM wrote:
>
>
>
> On 1 Jan 2024, at 15:38, David Bohman wrote:
>
> > This is a build failure in the master branch as a result of commit
> > e37b15e26fbc7bc31a86a4a2c7c798e20d4f4c2c:
> >
> > There is no type AVMediaType prior t
Adds command 'delays' to the adelay filter.
This command accepts same values as option with one difference, to apply
delay to all channels prefix 'all:' to the arguments is accepted.
Signed-off-by: David Lacko
---
libavfilter/af_adelay.c | 183
I would maybe even remove the av_freep(..) call, to keep the
original buffer and the original delay. The user would only
get an error code that the delay could not be changed.
st 19. 1. 2022 o 20:14 Andreas Rheinhardt
napísal(a):
> David Lacko:
> > Adds command 'delays' t
Adds command 'delays' to the adelay filter.
This command accepts same values as the option with one difference, to apply
delay to all channels prefix 'all:' to the argument is accepted.
Signed-off-by: David Lacko
---
libavfilter/af_adelay.c | 182
Is this being reviewed?
št 20. 1. 2022 o 12:38 David Lacko napísal(a):
> Adds command 'delays' to the adelay filter.
> This command accepts same values as the option with one difference, to
> apply
> delay to all channels prefix 'all:' to the argument is accepted
Yes, during development I tested it streaming to rtmp and to file with a
python client sending zmq requests.
I Also tried changing the delay multiple times while running a single
ffmpeg instance.
Seemed to be working fine.
so 5. 2. 2022 o 15:05 Paul B Mahol napísal(a):
> Have this been tested?
>
provides the mime_type hls detection requires.
Signed-off-by: David Lou
---
libavformat/data_uri.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/libavformat/data_uri.c b/libavformat/data_uri.c
index 28eb2b9e08..fdc1a2eef9 100644
--- a
provides the mime_type hls detection requires.
Thank you.
Hopefully this patch doesn't get truncated by email again.
Signed-off-by: David Lou
---
libavformat/data_uri.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/libavformat/data_
, preventing it from overflowing.
Problem is fixed by manually draining the fifo when performing the first
pass
of a 2-pass encode.
Fixes the regression originally introduced in
5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb
Signed-off-by: David Lemler
---
libavcodec/libvpxenc.c | 6 ++
1 file changed, 6
> On 07/05/2023 2:16 PM CDT James Zern wrote:
>
>
> On Wed, Jul 5, 2023 at 12:15 PM James Zern wrote:
> >
> > Hi,
> >
>
> +ffmpeg-dev. I took the wrong email off the reply.
>
> > On Mon, Jul 3, 2023 at 10:08 PM David Lemler wrote:
> > &
2-pass
encode so the fifo is not filled at all; replaces original patch which
drained the fifo after filling to prevent it from becoming full.
Fixes the regression originally introduced in
5bda4ec6c3cb6f286bb40dee4457c3c26e0f78cb
Co-authored-by: James Zern
Signed-off-by: David Lemler
On Mon, Jul 10, 2023 at 9:40 AM Fei Wang
wrote:
>
> Signed-off-by: Fei Wang
> ---
> Changelog |1 +
> configure |3 +
> doc/encoders.texi | 13 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c|1 +
> li
Some code in alimiter assumes that there are 2 channels, resulting in
clipping if the loudest channel is 3 or above and an out-of-bounds read if
the input is monophonic. Fix that in 2 places.
Signed-off-by: David Flater
---
libavfilter/af_alimiter.c | 23 +--
1 file changed
This is a friendly reminder.
Cc: Paul B Mahol
On 2022-08-14 21:53, David Flater wrote:
> Some code in alimiter assumes that there are 2 channels, resulting in
> clipping if the loudest channel is 3 or above and an out-of-bounds read if
> the input is monophonic. Fix that in
around an ARMv4 CPU and just 32MB RAM,
for context more info about this application here:
http://www.megapico.co.uk/sharpfin/mediaserver.html).
Best regards, David.
diff -Nur ./ffmpeg-5.0.1/configure ./ffmpeg-5.0.1-wolfssl/configure
--- ./ffmpeg-5.0.1/configure 2022-04-04 15:40:22.0 +0100
optimised for very fast decoding on the ARMv4 CPU. More info
about this application here:
http://www.megapico.co.uk/sharpfin/mediaserver.html.
Best regards, David.
diff -Nur ./ffmpeg-5.0.1/configure ./ffmpeg-5.0.1-mad/configure
--- ./ffmpeg-5.0.1/configure 2022-04-04 15:40:22.0 +0100
On 2/5/2022, "Paul B Mahol" wrote:
>Only patches for master are accepted.
>
>No more wrappers.
>
>Thanks.
Hi Paul,
Please find attached the libmad MP3 decoding patch against the master
(ffmpeg-master-b67572c).
I'm not sure what "No more wrappers" means?
can tell this is an issue affecting older ARM hardware, it
cannot be reproduced on x86 hardware. I now have some additional ARM
hardware with a more capable CPU which should help pin down the problem.
Best regards, David.
___
ffmpeg-devel mailin
ter-b67572c).
Best regards, David.
diff -Nur ./ffmpeg-master-b67572c/configure ./ffmpeg-master-b67572c-wolfssl/configure
--- ./ffmpeg-master-b67572c/configure 2022-05-02 16:10:22.0 +0100
+++ ./ffmpeg-master-b67572c-wolfssl/configure 2022-05-02 17:52:25.646019060 +0100
@@ -211,7 +211,7
gher alternative when the CPU can
handle that.
I've not tried --arch=generic. I'm cross-compiling on x86 targeting
ARMv4 so the cross-compile will stop working properly if I take out
--arch=armv4t.
I'll do some further investigation and see if I can create ffm
eport about why this exists is at the following link, including
a link to sample distorted audio from decoding an mp3 stream on ARMv4
hardware: https://trac.ffmpeg.org/ticket/9764
Best regards, David.
From c7012e7743d245bfc737bd921341a462cd5c843c Mon Sep 17 00:00:00 2001
From: David Fletcher
Date: T
aster branch.
Best regards, David.
From 3fc91e85b31ce0e5422f6ffe39d7d2287bce5939 Mon Sep 17 00:00:00 2001
From: David Fletcher
Date: Tue, 3 May 2022 19:23:50 +0100
Subject: [PATCH] Patched to work with wolfSSL as a new TLS backend
Signed-off-by: David Fletcher
---
configure
> Andreas Rheinhardt wrote:
>
> David Fletcher:
> > Following today's posts about help with submitting patches I realised I
> > sent the libmad patch yesterday in the wrong format. Apologies, I was
> > not familiar with the git format patches.
> >
> >
ion of MDCT integrated into the native mp3 fixed
point decoder I can test that on the ARMv4 hardware to see if the
decoding bug is fixed. Certainly these are old chips but still lots of
them around - a big part of them being useful is the assembly
optimisations otherwise eve
Move "quality" option from h264_vaapi to common options.
---
libavcodec/vaapi_encode.c | 3 +++
libavcodec/vaapi_encode.h | 8 +++-
libavcodec/vaapi_encode_h264.c | 5 -
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_e
Fixes leaking recon surfaces with VAAPI.
---
libavcodec/hw_base_encode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 7b6ec97d3b..912c707a68 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -80
This is needed to correctly set conformance window crop with Mesa AMD.
---
libavcodec/vaapi_encode_h265.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 2283bcc0b4..0f97c9188b 100644
--- a/liba
It needs to create temporary config to query surface attribute.
---
libavcodec/vaapi_encode.c | 66 +++
libavcodec/vaapi_encode.h | 4 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 16a9a364f0..c8
On Sat, Sep 14, 2024 at 8:59 AM Lynne via ffmpeg-devel
wrote:
>
> Unlike H264/H265, AV1 contains no fields to crop encoded output
> to specific sizes.
> AMD's hardware cannot handle encoding of unaligned dimensions for
> AV1, hence it codes 1920x1080 as 1920x1088.
>
> Add side data to crop the out
On Tue, Oct 22, 2024 at 5:28 PM David Rosca wrote:
>
> It needs to create temporary config to query surface attribute.
> ---
Ping.
Thanks,
David
> libavcodec/vaapi_encode.c | 66 +++
> libavcodec/vaapi_encode.h | 4 +++
> 2 files chan
---
libavcodec/vulkan_encode_h264.c | 1 +
libavcodec/vulkan_encode_h265.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
index cdc87fb4ca..fdd3cc8a55 100644
--- a/libavcodec/vulkan_encode_h264.c
+++ b/libavcodec/vulkan_encod
It needs to first get the query before the context can be used again.
Fixes getting incorrect values from encode query with async_depth > 1.
---
libavutil/vulkan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 2c71312d78..8485c5
Copy AVStream metadata from source file to RTP MPEGTS muxer. Muxer supports
only language metadata. User can set/change language metadata from cli.
Signed-off-by: Vojta David
---
libavformat/rtpenc_mpegts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtpenc_mpegts.c b
Don't need to alternate when only one reference is used.
Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size of
next_prev")
due to AV1 writer complaining about incorrect ref_order_hint value.
---
libavcodec/vaapi_encode_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Mar 4, 2025 at 8:43 AM David Rosca wrote:
>
> On Tue, Mar 4, 2025 at 2:55 AM Wang, Fei W
> wrote:
> >
> > On Mon, 2025-03-03 at 14:47 +0100, David Rosca wrote:
> > > On Wed, Jan 15, 2025 at 10:41 PM David Rosca
> > > wrote:
> > > >
>
We always use two slots, even when only one L0 reference is supported
by the driver. However we still need to set the correct value for the
ref_order_hint of the second slot.
Fixes bf9f921ef7 ("avcodec/hw_base_encode: restrict size of next_prev")
---
libavcodec/vaapi_encode_av1.c | 3 +++
1 file
vaGetImage is currently used for all maps when read access is required
because vaDeriveImage is supposed to be very slow on old Intel HW with
i965 driver.
However, this is not the case with modern drivers and vaDeriveImage
is faster also for reading.
Add a new quirk for i965 driver that will keep
On Wed, Jan 15, 2025 at 10:41 PM David Rosca wrote:
>
> Don't need to alternate when only one reference is used.
> Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size of
> next_prev")
> due to AV1 writer complaining about incorre
On Tue, Mar 4, 2025 at 2:55 AM Wang, Fei W
wrote:
>
> On Mon, 2025-03-03 at 14:47 +0100, David Rosca wrote:
> > On Wed, Jan 15, 2025 at 10:41 PM David Rosca
> > wrote:
> > >
> > > Don't need to alternate when only one reference is used.
> > > Fi
---
libavdevice/avfoundation.m | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 61dac4b713..b625990c37 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -375,6 +375,15 @@ static int configure_video_de
---
libavcodec/hw_base_encode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 33a30c8d10..927aeb4bad 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -666,6 +666,11 @@ int ff_hw_base_init_gop_st
On Mon, Apr 14, 2025 at 4:00 PM David Rosca wrote:
>
> We always use two slots, even when only one L0 reference is supported
> by the driver. However we still need to set the correct value for the
> ref_order_hint of the second slot.
>
> Fixes bf9f921ef7 ("avcodec/hw_base_e
nized as HEVC video, while the fixed one is recognized correctly.
I also ran `make fate` to ensure no regressions were introduced and all
tests passed.
The commit contains the full technical details of the fix.
Thanks,
David McElroy
David McElroy (1):
avformat/movenc: fix HEVC fmp4 HLS init se
ang,
but it was never merged.
Link: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317173.html
Co-authored-by: Jay Zhang
Signed-off-by: David McElroy
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/mov
On Thu, Jun 5, 2025 at 2:17 PM David Rosca wrote:
>
> On Mon, Apr 14, 2025 at 4:00 PM David Rosca wrote:
> >
> > We always use two slots, even when only one L0 reference is supported
> > by the driver. However we still need to set the correct value for the
> > ref
On Wed, Jun 25, 2025 at 8:48 AM David Rosca wrote:
>
> ---
> libavcodec/hw_base_encode.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
> index 33a30c8d10..927aeb4bad 100644
> --- a/libavcodec/
On Thu, Nov 14, 2024 at 10:39 PM David Rosca wrote:
>
> ---
> libavcodec/vulkan_encode_h264.c | 1 +
> libavcodec/vulkan_encode_h265.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
> inde
y), 0x87 (Nordig version)
United Kingdom --> Private Data Specifier = 0x233A, LCN Descriptor Tag =
0x83
Rest of Europe + Most of the World --> Private Data Specifier = 0x0028,
LCN Descriptor Tag = 0x83
Australia --> _Do_not_include_Private_data_specifier_descriptor_ , LCN
Desc
AFAIK.
If you do it, then you do it. We don't care if you label it "release blocker"
or not.
In particular, since practically all tools have false positives, what we're
really looking for is an effort to scan the code, examine the results, and work
down reported or potential problems.
I hope that helps!
--- David A. Wheeler
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: David Maseda Neira
---
libavformat/network.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/network.c b/libavformat/network.c
index 21e20b3e9a..0361346631 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -204,6 +204,12 @@ int ff_socket(int
thanks you Mark! will follow up on libva changes first.
David
On 2024-08-11 14:42, Mark Thompson wrote:
On 11/08/2024 19:27, Mark Thompson wrote:
On 30/07/2024 21:02, David (Ming Qiang) Wu via ffmpeg-devel wrote:
AV1Profile2 VAAPI is supported and tested on AMD VCN5.
Signed-off-by: David
AV1Profile2 VAAPI is supported and tested on AMD VCN5.
Signed-off-by: David (Ming Qiang) Wu
---
libavcodec/av1dec.c | 3 +++
libavcodec/vaapi_decode.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 1d5b9ef4f4..77f63661a0 100644
101 - 190 of 190 matches
Mail list logo
