Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: bpilarz
---
On 9 Jul 2024, at 8:16, Gnattu OC via ffmpeg-devel wrote:
>> On Jul 9, 2024, at 13:47, Helmut K. C. Tessarek wrote:
>>
>> I'm very sorry to bother the dev list with this, but this is the 2nd time in
>> less than a year that the min version of macOS was changed in videotoolbox.
>>
>> 2023-09-22
On 8 Jul 2024, at 8:30, Zhao Zhili wrote:
> From: Zhao Zhili
>
> ---
> libavutil/hwcontext_videotoolbox.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 953155ce32..dd89edfa08 100644
>
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: Bernardo Pila
From: Niklas Haas
scale_frame() inconsistently handled the lifetime of `in`. Fixes a
possible double free and a possible memory leak.
The new code always has `scale_frame` take over ownership of the input
frame. I first tried writing this code in a way where the calling code
retains ownership, b
From: Niklas Haas
Instead of testing the returned frame against NULL, test the return code
itself, going more in line with the usual behavior of such functions.
---
libavfilter/vf_scale.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_scale.c b/
Connecting to an RTSP stream will now cause the SDP attributes of each media
stream to be stored in the codecpar of the relative AVStream.
The SDP attributes are stored in the coded_side_data using the (new) type
AV_PKT_DATA_SDP_ATTRIBUTES (AVPacketSideDataType enum).
Signed-off-by: bpilarz
---
On Tue, Jul 9, 2024 at 6:35 AM Timo Rothenpieler
wrote:
> On 08.07.2024 17:32, Zhao Zhili wrote:
> >
> >
> >> On Jul 8, 2024, at 22:07, Timo Rothenpieler
> wrote:
> >>
> >> On 08.07.2024 09:43, Zhao Zhili wrote:
> >>> From: Zhao Zhili
> >>> av_executor_execute run the task directly when thread
on "INT is 64bit" systems they may have been false
Signed-off-by: Michael Niedermayer
---
libavutil/imgutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index d2463815637..b738cff37c2 100644
--- a/libavutil/imgutils.c
+++ b/li
Fixes: CID1513722 Operands don't affect result
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_scale.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index bf09196e10d..18e9393d6c1
On Tue, Jul 09, 2024 at 06:14:17AM +, Xiang, Haihao wrote:
> On Di, 2024-07-02 at 01:47 +0200, Michael Niedermayer wrote:
> > Fixes: CID1604548 Unused value
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/examples/vaapi_encode.c | 4
> >
On 6 Jul 2024, at 11:26, Stefano Sabatini wrote:
> On date Tuesday 2024-07-02 20:38:00 +0200, Marvin Scholz wrote:
>> An incorrect calculation in ff_perlin_init causes a write to the
>> stack array at index 256, which is out of bounds.
>>
>> Fixes: CID1608711
>> ---
>> libavfilter/perlin.c | 2
On Mon, Jul 08, 2024 at 03:16:28PM +, Tong Wu wrote:
> Ping. As the author of d3d12va_encode, I would like to get the access in
> order maintain the code and add more new features.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The day sold
On Mon, Jul 08, 2024 at 12:25:17AM -0400, Sean McGovern wrote:
> ---
> libswscale/yuv2rgb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
> index 977eb3a7dd..ac0b811f61 100644
> --- a/libswscale/yuv2rgb.c
> +++ b/libswscal
On Mon, Jul 08, 2024 at 09:49:25PM +0800, Nuo Mi wrote:
> LGTM.
> Thank you, Michael,
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted oc
On Mon, Jul 08, 2024 at 07:46:19PM +0200, Marton Balint wrote:
>
>
> On Sun, 9 Jun 2024, Michael Niedermayer wrote:
>
> > Fixes: CID1551679 Data race condition
> > Fixes: CID1551687 Data race condition
>
> How is this a data race? Concurrent reading and writing is not supported for
> UDP as far
Quoting Michael Niedermayer (2024-07-09 13:37:11)
> Fixes: CID1513722 Operands don't affect result
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_scale.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter
> ensure width and height fit in 32bit
why?
--
Anton Khirnov
___
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
On Tue, Jul 09, 2024 at 03:12:52PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 08, 2024 at 07:46:19PM +0200, Marton Balint wrote:
> >
> >
> > On Sun, 9 Jun 2024, Michael Niedermayer wrote:
> >
> > > Fixes: CID1551679 Data race condition
> > > Fixes: CID1551687 Data race condition
marked the
On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote:
> > ensure width and height fit in 32bit
>
> why?
because not everyone wants undefined behavior
because not everyone wants security issues
because we dont support width and height > 32bit and its easier to check in a
central place
be
On Tue, Jul 09, 2024 at 03:28:10PM +0200, Michael Niedermayer wrote:
> On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote:
> > > ensure width and height fit in 32bit
> >
> > why?
>
> because not everyone wants undefined behavior
> because not everyone wants security issues
> because we
On Mon, Jul 08, 2024 at 09:51:30AM +0200, Steve Lhomme wrote:
> Hi Michael,
>
> All the patches in that patches look good to me. You can apply.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the
From: Niklas Haas
This count gets incremented after init succeeds, when it should be
incremented after *alloc* succeeds. Otherwise, we leak the context on
failure.
There are no negative consequences of incrementing for
allocated-but-not-initialized contexts, as the only functions that
reference
I've accidentally used API not available on the checked version.
Additionally check for the SDK to be new enough to even have the
CVImageBufferCreateColorSpaceFromAttachments API to not fail
the build.
---
libavutil/hwcontext_videotoolbox.c | 15 ++-
1 file changed, 14 insertions(+), 1
On Tue, 9 Jul 2024 at 15:17, Anton Khirnov wrote:
>
> Quoting Michael Niedermayer (2024-07-09 13:37:11)
> > Fixes: CID1513722 Operands don't affect result
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/vf_scale.c | 6 ++
> > 1 file ch
Quoting Michael Niedermayer (2024-07-09 15:28:10)
> On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote:
> > > ensure width and height fit in 32bit
> >
> > why?
>
> because not everyone wants undefined behavior
> because not everyone wants security issues
> because we dont support width
Changes since v1:
- changed transcode command
Leo Izen (1):
fate/png: add mDCv read and write test
tests/fate/image.mak| 6 ++
tests/ref/fate/png-mdcv | 22 ++
2 files changed, 28 insertions(+)
create mode 100644 tests/ref/fate/png-mdcv
--
2.45.2
__
This test confirms that we can write mDCv chunks and read them back via
the png decoder. It uses an HEVC conformance sample with this metadata
as the base source for the side data in the frames.
Signed-off-by: Leo Izen
Reported-by: Jan Ekström
Reviewed-by: Andreas Rheinhardt
---
tests/fate/ima
It's meant to override any codec specific (but container level) information,
but its position is not guaranteed, so apply the values after the entire trak
structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set SAR from
existing dimensions while at it.
Signe
For even small values of 'asrc', shifting them by 24 bits or more
will cause arithmetic overflow and be caught by
GCC's undefined behaviour sanitizer.
Ensure the values do not overflow by up-casting the bracketed
expressions involving 'asrc' to int32_t.
---
libswscale/yuv2rgb.c | 4 ++--
1 file c
Hi Andriy,
Any luck with this? I'm still locked out.
On Wed, Jun 12, 2024 at 6:59 PM Michael Niedermayer
wrote:
>
> Hi
>
> adding Andriy to CC, to make sure its not missed
>
> On Tue, Jun 11, 2024 at 07:45:21PM -0400, Sean McGovern wrote:
> > Hi,
> >
> > Can someone help me reset my password on
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
The input sample aspect ratio applies to the pre-cropping dimensions, so update
it.
Signed-off-by: James Almer
---
fftools/ffmpeg_filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 097bd2ed48..0d85c30aba 100644
--
Thanks for the reply.
On 2024-07-09 02:16, Gnattu OC via ffmpeg-devel wrote:
Well the code introduced is to fix certain HDR related bugs and it does not
"works perfectly” before, it was just broken.
I was rather talking about being able to compile it. I can compile
ffmpeg without videotoolbo
On 9 Jul 2024, at 21:44, Helmut K. C. Tessarek wrote:
> Thanks for the reply.
>
> On 2024-07-09 02:16, Gnattu OC via ffmpeg-devel wrote:
>> Well the code introduced is to fix certain HDR related bugs and it does not
>> "works perfectly” before, it was just broken.
>
> I was rather talking about b
On 2024-07-09 16:04, epira...@gmail.com wrote:
Videotoolbox should not have raised the deployment target and I did not notice
any change recently that would
have done it other than mine accidentally.
If you encounter other issues with it, once my fix is merged, do not hesitate
to report them h
On 7/9/24 2:34 PM, Sean McGovern wrote:
For even small values of 'asrc', shifting them by 24 bits or more
will cause arithmetic overflow and be caught by
GCC's undefined behaviour sanitizer.
Ensure the values do not overflow by up-casting the bracketed
expressions involving 'asrc' to int32_t.
--
Signed-off-by: James Almer
---
libavfilter/vf_crop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
index 6361209941..d4966323f5 100644
--- a/libavfilter/vf_crop.c
+++ b/libavfilter/vf_crop.c
@@ -206,7 +206,7 @@ static int config_
For even small values of 'asrc[x]', shifting them by 24 bits or more
will cause arithmetic overflow and be caught by
GCC's undefined behaviour sanitizer.
Ensure the values do not overflow by up-casting the bracketed
expressions involving 'asrc' to uint32_t.
---
libswscale/yuv2rgb.c | 4 ++--
1 fi
On Tue, Jul 09, 2024 at 04:46:59PM +0200, Kacper Michajlow wrote:
> On Tue, 9 Jul 2024 at 15:17, Anton Khirnov wrote:
> >
> > Quoting Michael Niedermayer (2024-07-09 13:37:11)
> > > Fixes: CID1513722 Operands don't affect result
> > >
> > > Sponsored-by: Sovereign Tech Fund
> > > Signed-off-by: Mi
On Tue, Jul 09, 2024 at 05:14:37PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-09 15:28:10)
> > On Tue, Jul 09, 2024 at 03:17:58PM +0200, Anton Khirnov wrote:
> > > > ensure width and height fit in 32bit
> > >
> > > why?
> >
> > because not everyone wants undefined behavior
The issue with the old mechanism is that we had to introduce new
API each time we needed a new queue family, and all the queue families
were functionally fixed to a given purpose.
Nvidia's GPUs are able to handle video encoding and compute on the
same queue, which results in a speedup when pre-pro
---
libavutil/vulkan.c | 68 ++
libavutil/vulkan.h | 2 +-
2 files changed, 21 insertions(+), 49 deletions(-)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index e0208c5a7c..d98e863711 100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@
On 09/07/2024 08:57, Anton Khirnov wrote:
Quoting Lynne via ffmpeg-devel (2024-07-09 03:07:12)
@@ -151,6 +162,17 @@ typedef struct AVVulkanDeviceContext {
* Similar to lock_queue(), unlocks a queue. Must only be called after
locking.
*/
void (*unlock_queue)(struct AVHWDevice
The issue with the old mechanism is that we had to introduce new
API each time we needed a new queue family, and all the queue families
were functionally fixed to a given purpose.
Nvidia's GPUs are able to handle video encoding and compute on the
same queue, which results in a speedup when pre-pro
On Wed, 2024-06-05 at 20:59 +0100, Mark Thompson wrote:
> Rather than turning the constraint flags into a single profile and
> then
> searching for that profile (and failing if it doesn't match any
> profile
> exactly), instead search all supported profiles and use the first one
> which supports th
> -Original Message-
> From: Anton Khirnov
> Sent: Tuesday, June 25, 2024 3:45 PM
> To: FFmpeg development discussions and patches
> Cc: Wang, Fei W
> Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/hevcdec: Update slice index
> before hwaccel decode slice
>
> Quoting fei.w.wang-at-inte
47 matches
Mail list logo
