Re: [FFmpeg-devel] Procedure to enable the Windows on ARM64 FFMPEG Libraries

Thanks for the Info. We do have some queries : > It will be good to have Windows on ARM prebuilt libraries for FFMPEG as part > of Download repository (Releases * BtbN/FFmpeg-Builds > (github.com)). I decided against it since it's highly experime

[FFmpeg-devel] [PATCH v2] hw_base_encode_h265: split off SPS/PPS/VPS generation from VAAPI

--- Only difference between V1 and V2 is that V2 actually makes VAAPI use the exported code, rather than copying it. libavcodec/Makefile | 2 +- libavcodec/hw_base_encode_h265.c | 351 + libavcodec/hw_base_encode_h265.h | 56 + libavcodec/vaapi_enco

[FFmpeg-devel] [PATCH] avformat/utils: added av_get_frame_filename3() (changed parameter int -> int64_t)

fix for ticket 11194 (frame_pts codepath requires a larger integer capacity for normal workloads) Signed-off-by: Filip Mašić --- libavformat/avformat.h | 5 - libavformat/img2enc.c | 6 ++ libavformat/utils.c| 12 +--- 3 files changed, 15 insertions(+), 8 deletions(-) di

Re: [FFmpeg-devel] [PATCH] av_get_frame_filename2 parameter int -> int64_t

On Mon, 16 Sept 2024 at 19:59, Leo Izen wrote: > On 9/16/24 2:22 PM, Filip Mašić wrote: > > my apologies for re-sending; i didn't spot that there was a header file. > my previous email may be disregarded. > > > > suggested fix for ticket 11194; see ticket for more info. i haven't been > able to t

Re: [FFmpeg-devel] [PATCH] av_get_frame_filename2 parameter int -> int64_t

On 9/16/24 2:22 PM, Filip Mašić wrote: my apologies for re-sending; i didn't spot that there was a header file. my previous email may be disregarded. suggested fix for ticket 11194; see ticket for more info. i haven't been able to test this since i don't have any build tools installed, but dec

[FFmpeg-devel] [PATCH] av_get_frame_filename2 parameter int -> int64_t

my apologies for re-sending; i didn't spot that there was a header file. my previous email may be disregarded. suggested fix for ticket 11194; see ticket for more info. i haven't been able to test this since i don't have any build tools installed, but decided to submit it since it seems to be a

[FFmpeg-devel] [PATCH] av_get_frame_filename2 parameter int -> int64_t

suggested fix for ticket 11194; see ticket for more info. i haven't been able to test this since i don't have any build tools installed, but decided to submit it since it seems to be a trivial change and easy to test --- libavformat/utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[FFmpeg-devel] [PATCH v2 3/3] avcodec/pngenc: write eXIf chunks

Write EXIF metadata exposed AV_FRAME_DATA_EXIF as an eXIf chunk to PNG files, if present. Signed-off-by: Leo Izen --- libavcodec/pngenc.c | 4 tests/ref/fate/cover-art-mp3-id3v2-remux | 6 +++--- tests/ref/fate/mov-cover-image | 6 +++--- 3 files changed, 10 i

[FFmpeg-devel] [PATCH v2 2/3] avcodec/pngdec: parse eXIf chunk

Add support to parse eXIf chunks using the new EXIF framework. Signed-off-by: Leo Izen --- libavcodec/pngdec.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c index c5b32c166d..efd173e154 100644 --- a/libavcodec/p

[FFmpeg-devel] [PATCH v2 1/3] various: change EXIF metadata into AVFrameSideData

This patch centralizes much of the EXIF parsing and handling code for libavcodec, and delegates its own AVFrameSideData type to containing the buffer that holds EXIF metadata. This patch also adds exposes the exif parsing routing so it can be called by ffprobe, and updates the corresponding FATE te

[FFmpeg-devel] [PATCH v2 0/3] [RFC] Exif Overhaul

I've made some changes to the last EXIF overhaul patch I sent, notably I fixed up some bugs and added MakerNote parsing, so it should not corrupt MakerNotes that are inside TIFF files. MakerNote is supposed to be a binary blob but many camera manufacturers treat it as an IFD (e.g. Canon) with offs

Re: [FFmpeg-devel] [PATCH 1/7] avformat/mov_chan: Check for FF_SANE_NB_CHANNELS

On 9/13/2024 2:48 PM, Michael Niedermayer wrote: On Fri, Sep 13, 2024 at 12:08:45PM +0200, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-09-13 01:33:31) We do not support more channels. For example avcodec_open2() limits channels this way too The example file contains multiple chunks

Re: [FFmpeg-devel] [RFC/PATCH] MV-HEVC decoding

Quoting Anton Khirnov (2024-09-14 11:01:27) > It is, but mainly as a testing/development aid, I do not expect it to be > generally useful. Or is there a particular reason you need to > interleave the views into one stream? Understood. Since we can extract both views synchronized with the view spe

Re: [FFmpeg-devel] [RFC/PATCH] MV-HEVC decoding

Quoting James Almer (2024-09-13 22:57:44) > It's probably not misplaced but mistagged as nuh_layer_id == 0 when it > should be 1 (Can SEI NALUs be in anything other than the base layer?). > The SEI is User Data Unregistered, and its contents are different than > the one preceding the base layer VCL

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add Vulkan video encoding base code

On 15/09/2024 11:55, Lynne via ffmpeg-devel wrote: On 09/09/2024 12:37, Lynne wrote: This commit adds the common Vulkan video encoding framework. It makes full use of the asynchronous features of our new common hardware encoding code, and of Vulkan. The code is able to handle anything from H264

[FFmpeg-devel] [TC] Decision on H.263 DCT dequantization

Hi all, Rémi has requested a while ago that the TC resolve a disagreement around his patches [1-8] changing the structure of the H.263 DCT dequant code. The patches are intended to simplify adding arch-specific optimizations and checkasm tests, however they add an indirect call and Andreas was con

Re: [FFmpeg-devel] [PATCH 21/23] tests/fate/hevc: add a test for nontrivial values of nuh_layer_id

Quoting James Almer (2024-09-15 23:56:13) > On 9/14/2024 7:45 AM, Anton Khirnov wrote: > > Typical files use 0 for the base layer and 1 for the secondary one, but > > any value for the secondary layer should be supported. > > --- > > tests/fate/hevc.mak | 4 > > tests/ref/f

[FFmpeg-devel] [PATCH v2 15/23] lavc/hevcdec: implement decoding MV-HEVC

At most two layers are supported. Aspects of this work were sponsored by Vimeo and Meta. --- Now not using AV_FRAME_FLAG_DISCARD to discard views that are decoded but not output. --- Changelog | 1 + doc/decoders.texi | 45 + libavcodec/hevc/hevcdec.c | 334

[FFmpeg-devel] [PATCH] lavc/decode: do not clear the frame discard flag in ff_decode_frame_props_from_pkt()

Only do it in reget_buffer(). The purpose of this clearing this flag is to prevent it for unintentionally persisting across multiple invocations of this function on one frame, however that is only a problem if the frame is not unreffed between uses, which is only the case with reget_buffer(). In

Re: [FFmpeg-devel] [PATCH v4 00/17] Add avcodec_get_supported_config()

On 16.09.24 09:58, martin schitter wrote: I think, this changes break the very simple fate tests of my DNxUncompressed decoder. see: https://patchwork.ffmpeg.org/project/ffmpeg/ patch/20240916055250.1559817-7-ms+...@mur.at/ Sorry, I was wrong! You changes are only causing this long list

Re: [FFmpeg-devel] [PATCH 1/2] lavf/mxfdec: Switch to mxf_metadata_read_table loop to FF_ARRAY_ELEMS, skip if read == NULL

Will push in a day or two /Tomas ___ 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".

Re: [FFmpeg-devel] [PATCH 5/7] avformat/mxfdec: More offset_temp checks

sön 2024-09-15 klockan 22:28 +0200 skrev Tomas Härdin: > fre 2024-09-13 klockan 01:33 +0200 skrev Michael Niedermayer: > > Fixes: signed integer overflow: 9223372036854775807 - - > > 1927491430256034080 cannot be represented in type 'long' > > Fixes: 70607/clusterfuzz-testcase-minimized-ffmpeg_dem_

Re: [FFmpeg-devel] [PATCH v4 00/17] Add avcodec_get_supported_config()

On 04.09.24 17:03, Niklas Haas wrote: On Wed, 04 Sep 2024 13:02:29 +0200 Niklas Haas wrote: I will merge this version at the end of the week if there are no further blocking comments. I think, this changes break the very simple fate tests of my DNxUncompressed decoder. see: https://pat

Re: [FFmpeg-devel] [PATCH v7 2/6] libavformat/mxf: Add ULs for DNxUncompressed

mån 2024-09-16 klockan 07:52 +0200 skrev Martin Schitter: > --- >  libavformat/mxf.c    | 1 + >  libavformat/mxfdec.c | 1 + >  2 files changed, 2 insertions(+) > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c > index a73e40e..b6c1f17 100644 > --- a/libavformat/mxf.c > +++ b/libavformat/mxf.c

Re: [FFmpeg-devel] Procedure to enable the Windows on ARM64 FFMPEG Libraries

Hi Team, Would be helpful it you can provide the pointers for below queries. Regards, Niranjan From: Niranjan Kshatriya (QUIC) Sent: Thursday, September 12, 2024 12:51 PM To: ffmpeg-devel@ffmpeg.org Subject: Procedure to enable the Windows on ARM64 FFMPEG Libraries Hi team, I am working on Win