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 output back to the original dimensions.
There's an AV1-spec extension planned t
I submitted DVD seeking support in a small single commit patch. While not
breaking it would be nice to have if I’m not too late. Thank you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
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 output back to the original dimensions.
There's an AV1-spec extension planned t
The AMF HEVC encoder takes a bool option for whether deblocking filter
should be _disabled_ instead of whether it should _enabled_ like the
AMF H.264 encoder does. The logic was accidentally copied from H.264 to
HEVC without negating the bool value, so the deblocking filter was
actually disabled wh
We properly set AMF_VIDEO_ENCODER_HEVC_NOMINAL_RANGE since fb4dd4b6f48.
Signed-off-by: Cameron Gutman
---
libavcodec/amfenc_hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 4898824f3a..71e7d8aa61 100644
--- a/lib
Subject: [PATCH] libavutil/ppc: Make use of getauxval() and elf_aux_info() on
ppc
Modern Linux has getauxval() and FreeBSD/OpenBSD ppc have elf_aux_info().
Signed-off-by: Brad Smith
---
adjust to build with older glibc.
libavutil/ppc/cpu.c | 22 ++
1 file changed, 22 inser
Signed-off-by: James Almer
---
libavcodec/bsf/dts2pts.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavcodec/bsf/dts2pts.c b/libavcodec/bsf/dts2pts.c
index ba4dc43f84..2be79c624b 100644
--- a/libavcodec/bsf/dts2pts.c
+++ b/libavcodec/bsf/dts2pts.c
@@ -3
Much like ff_refstruct_pool_alloc_ext(), it's a wrapper around
ff_refstruct_pool_alloc_ext_c().
Signed-off-by: James Almer
---
libavcodec/refstruct.c | 5 -
libavcodec/refstruct.h | 17 -
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavcodec/refstruct.c
On 14 Sep 2024, at 0:12, martin schitter wrote:
> These a very helpful instructive examples.
>
> Nevertheless, I would highly prefer a preconfigured `make fmt` command, which
> works similar to `cargo fmt` or `deno fmt` and corrects and checks formating
> issues without any human intervention.
These a very helpful instructive examples.
Nevertheless, I would highly prefer a preconfigured `make fmt` command,
which works similar to `cargo fmt` or `deno fmt` and corrects and checks
formating issues without any human intervention. That's IMHO more
productive than constantly work against
bit_rate_tolerance=0 has a few problems:
- infinite loop if frame_bits doesn't become small enough for any lambda
- bad quality, as it's never increasing lambda above the initial value
- not doing the restoring of coeffs after adjusting lambda
Attempt to address these:
- target bitrate a bit bel
In the FFMPEG native AAC encoder, bit_rate_tolerance=0 (-bt:a 0)
enforces a strict bitrate mode, where maximum length of the AAC frame
(frame_bits) is capped below nominal bitrate (rate_bits).
It currently seems to have some issues:
- encoder can get stuck in an infinite loop
- sound quality issu
On 9/13/2024 5:51 PM, Danny Hong wrote:
Quoting James Almer (2024-09-13 22:19:35)
Are you talking about decoding the resulting raw bitstream created from
doing stream copy from the source mov? If so, what's happening is
probably that the parser is splitting AUs when the second SEI with
layer_id
Quoting James Almer (2024-09-13 22:19:35)
> Are you talking about decoding the resulting raw bitstream created from
> doing stream copy from the source mov? If so, what's happening is
> probably that the parser is splitting AUs when the second SEI with
> layer_id == 0 shows up in those non-conforma
On 12 Jul 2024, at 20:38, Marvin Scholz wrote:
> ---
> ffbuild/common.mak | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
If no one has objections in the meantime, I will merge it next week.
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index 87a3ffd2b0..023adb8567 100644
>
On 9/13/2024 2:58 PM, Danny Hong wrote:
Quoting Anton Khirnov (2024-09-13 12:44:55)
Note that -view_ids is a decoder option and does nothing with
streamcopy.
Also, that option is intended for API users, with ffmpeg CLI you should
be using view specifiers instead.
Thanks! Tried with "-map 0:
On 18 May 2024, at 20:22, Andrew Sayers wrote:
> I would have found this very helpful!
Thanks for the review, I just submitted a new version that hopefully
addresses most of your points.
>
> On Sat, May 18, 2024 at 07:00:50PM +0200, Marvin Scholz wrote:
>> Given the frequency that new develop
Makes it easier to immediately see if the code examples given in the
style documentation are good or bad examples, making it harder to
accidentally confuse a bad example for a good one.
---
doc/style.min.css | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/style.min.css b/do
Given the frequency that new developers, myself included, get the
code style wrong, it is useful to add some examples to clarify how
things should be done.
---
doc/developer.texi | 101 -
1 file changed, 100 insertions(+), 1 deletion(-)
diff --git a/doc
Quoting Anton Khirnov (2024-09-13 12:44:55)
> Note that -view_ids is a decoder option and does nothing with
> streamcopy.
> Also, that option is intended for API users, with ffmpeg CLI you should
> be using view specifiers instead.
Thanks! Tried with "-map 0:v:view:all" and the result is the sam
On 13 Sep 2024, at 19:43, Martin Storsjö wrote:
> On Thu, 12 Sep 2024, Marvin Scholz wrote:
>
>> Previously only the C compiler was set, which would lead to
>> confusing situations where even though clang-asan was selected,
>> it would still use g++ for C++ code, failing because configure
>> doe
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 with over 16 million channels
>
>
On Thu, 12 Sep 2024, Marvin Scholz wrote:
Previously only the C compiler was set, which would lead to
confusing situations where even though clang-asan was selected,
it would still use g++ for C++ code, failing because configure
does not support mixing compilers in this way (which is a separate
On Tue, Jul 09, 2024 at 09:19:54AM +, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov | Fri Jul 5
> 12:30:04 2024 +0200| [10185e2d4c1e9839bc58a1d6a63c861677b13fd0] | committer:
> Anton Khirnov
>
> fftools/ffmpeg_mux_init: default to input timebase for streamcopy
>
> Stop tr
It seems that my patch didn't get picked up by patchwork :( Did I miss
a formatting step?
On Fri, Sep 13, 2024 at 1:40 AM wrote:
>
> From: Kevin Wang
>
> When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
> is set, ignore any out of order POC's as they may still be valid
> fra
Hello,
I recently upgraded FFmpeg to version 6.1 in my web application and encountered
a change while running my app's tests. After the upgrade, ffprobe reported an
r_frame_rate of 60/1 instead of the expected 30/1 for two videos in my test
suite.
After investigating, I traced the issue to the f
Here are the necessary samples for the fate checks.
Please upload them to the fate sample collection.
thanks
martin
On 13.09.24 14:48, Martin Schitter wrote:
I'll send the compressed samples attached to the next mail.
dnxuc.tar.xz
Description: application/xz
This is set of sample tests, which should cover all currently supportet
DNxUncompressed decoding capabilities.
I'll send the compressed samples attached to the next mail.
---
tests/Makefile | 1 +
tests/fate/dnxuc.mak| 40 +
tests
On 13.09.24 13:59, Tomas Härdin wrote:
RE: performance, we might want to move to a hash table based approach
so we don't scan the entire table every time. The approach in this
patch would be detrimental to such a change (it's an extra if that's
always evaluated), hence why I prefer a table base
Cuts down on "Dark key" spam in verbose mode, as pointed out by Martin
Schitter
/Tomas
From 0ca53ebb7835624261b97903136579ec9a529736 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 13 Sep 2024 14:10:34 +0200
Subject: [PATCH 2/2] lavf/mxfdec: Handle KLV fill
---
libavfo
Passes fate-mxf
/Tomas
From c96a96dc1f245210997a7d21b158ce504bdf4c73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 13 Sep 2024 14:09:56 +0200
Subject: [PATCH 1/2] lavf/mxfdec: Switch to mxf_metadata_read_table loop to
FF_ARRAY_ELEMS, skip if read == NULL
---
libavfo
fre 2024-09-13 klockan 08:23 + skrev Nicolas Gaullier:
>
> - why not using a simple "if" on the av_log rather than inserting a
> new block of code ?
That's way ugly
RE: performance, we might want to move to a hash table based approach
so we don't scan the entire table every time. The approac
Quoting Danny Hong (2024-09-09 19:45:57)
> Thanks for the patch set! Ran some initial tests and here are some
> findings:
>
> 1. Tested using the HTM ref SW encoded bitstreams; the HTM encoded 2 layer
> MV-HEVC elementary streams are decoded by both the HTM decoder and ffmpeg,
> and both resulted
Steven Liu 于2024年9月2日周一 16:46写道：
>
> jiangjie 于2024年9月2日周一 16:35写道：
> >
> > If the segment is very small, avformat_find_stream_info will read all
> > audio/video data in this segment. cur->is_restart_needed is set to 0 later
> > in dash_read_packet function, and no chance to be set to 1 again i
Quoting Marvin Scholz (2024-09-11 21:07:29)
> The channelmap_init function was returning success even on error after
> 7dc81d33c241b9e176ea85956e8317f29bc9e3c0 due to shadowing of the
> outer ret variable.
>
> Fixes CID1619297 Logically dead code
> ---
> libavfilter/af_channelmap.c | 2 +-
> 1 fi
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 with over 16 million channels
We had this discussion already. Ad-hoc checks like this are only
addressing
Quoting Marvin Scholz (2024-09-08 23:25:51)
> ---
> libavcodec/g2meet.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
Looks good
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/l
Quoting Marvin Scholz (2024-09-08 23:03:35)
> ---
> libavcodec/mjpegdec.c| 15 +++
> libavcodec/mjpegenc_common.c | 13 ++---
> 2 files changed, 13 insertions(+), 15 deletions(-)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel m
Quoting Marvin Scholz (2024-09-08 22:50:45)
> ---
> libavcodec/libx264.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/
Quoting Marvin Scholz (2024-09-08 22:27:44)
> ---
> fftools/ffmpeg_demux.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-
Quoting Marvin Scholz (2024-09-08 22:26:09)
> ---
> fftools/ffmpeg_demux.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
LGTM
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listin
Quoting Marvin Scholz (2024-09-08 22:21:03)
> ---
> fftools/ffmpeg_mux_init.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
> index 8d475f5b45..c2867192ee 100644
> --- a/fftools/ffmpeg_mux_init.c
>
On 13.09.24 10:23, Nicolas Gaullier wrote:
I am not against the idea of the patch: filler items should not be logged as dark metadata.
Fine! -- that's the main point!
I find the patch confusing both because of the commit msg and code:
- the commit msg should not claim it "adds support for"
On 13/09/2024 05:15, fei.w.wang-at-intel@ffmpeg.org wrote:
From: Fei Wang
Signed-off-by: Fei Wang
---
libavcodec/vaapi_encode_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 6d1be9fc07..1b350cd
>De : ffmpeg-devel De la part de martin
>schitter
>Envoyé : jeudi 12 septembre 2024 13:54
>On 12.09.24 13:14, Nicolas Gaullier wrote:
>> The message "Recognize and Ignore" does not make it clear what issue or
>> grave defect is solved here.
>> I see in the code that fill items are currently reco
45 matches
Mail list logo
