Plan to push in a couple of days.
On 2021-07-02 15:33, Gyan Doshi wrote:
Allows forcing decoders of different media type.
Needed to decode media data muxed as data streams.
---
doc/ffmpeg.texi | 5 +
fftools/ffmpeg_opt.c | 7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
Hi,
About a month ago, I submitted a patch to add User Data Unregistered SEI
writing to the x265 implementation.
See http://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/280978.html[1]
and
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210605102028.15571-2-br...@frogmouth.net/[2]
If this i
On 6/26/2021 5:24 PM, James Almer wrote:
The main benefit comes from propagating container level metadata like hdr,
which is more commonly used than the relevant Metadata OBUs.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 71 ---
1 file chang
We already require X264_BUILD >= 118, which includes an unconditional
definition of X264_CSP_BGR in itself, thus making this check
effectively always true.
---
configure| 3 +--
libavcodec/libx264.c | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/configure b/confi
Changes compared to v2:
- Kept the CONFIG_LIBX264RGB_ENCODER define check for ff_libx264rgb_encoder
and the AVClass for libx264rgb.
- Removed the libx264rgb removal from this patch set since while I hoped I
would be getting the initial two fixups reviewed even if people would oppose
the libx2
This makes the libx264rgb check work when pkg-config is utilized
and x264.h is not part of the standard include path (as is often
with cross-compilation, or when you just have a custom prefix in
general in f.ex. your home directory).
The X264_BUILD >= 118 required by configure since 2011 should ha
On 7/7/2021 3:12 PM, Marton Balint wrote:
On Wed, 7 Jul 2021, Lynne wrote:
6 Jul 2021, 21:57 by c...@passwd.hu:
On Tue, 6 Jul 2021, Lynne wrote:
3 Jun 2021, 06:58 by d...@lynne.ee:
Apr 26, 2021, 03:27 by andreas.rheinha...@outlook.com:
Lynne:
From 097aed2ac33dda0bb2052d8b0402711ce9
On Wed, 7 Jul 2021, Lynne wrote:
6 Jul 2021, 21:57 by c...@passwd.hu:
On Tue, 6 Jul 2021, Lynne wrote:
3 Jun 2021, 06:58 by d...@lynne.ee:
Apr 26, 2021, 03:27 by andreas.rheinha...@outlook.com:
Lynne:
From 097aed2ac33dda0bb2052d8b0402711ce95079ba Mon Sep 17 00:00:00 2001
From: Lyn
James Almer:
> On 6/15/2021 8:31 PM, Andreas Rheinhardt wrote:
>> by setting the FF_FMT_INIT_CLEANUP flag.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/av1dec.c | 13 -
>> 1 file changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavformat/av1dec.c b/liba
Vorbis has priming samples at the beginning. If the initial_padding is not
set in the encoder, the total sample count will be one frame fewer than it
should be. The result is that we get a truncated version of encoding.
initial_padding should be set to the frame_size used in
vorbis_encode_frame().
Without end_trimming, the last packet will contain unexpected samples used
for padding.
This commit partially fixes #6367 when the audio length is long enough.
dd if=/dev/zero of=./silence.raw count=20 bs=500
oggenc --raw silence.raw --output=silence.ogg
oggdec --raw --output silence.oggdec.raw s
After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
the actual decoded samples become fewer. Three fate tests are failing:
fate-vorbis-20:
The samples in 6.ogg are not frame aligned. 6.pcm file was generated by
ffmpeg before the fix. After the fix, the decoded pcm file does
On Wed, Jul 7, 2021 at 2:41 AM Lynne wrote:
>
> 6 Jul 2021, 18:21 by sunguangy...@gmail.com:
>
> > On Tue, Jul 6, 2021 at 1:15 AM Lynne wrote:
> >
> >>
> >> 6 Jul 2021, 08:02 by sunguangy...@gmail.com:
> >>
> >> > On Mon, Jun 21, 2021 at 9:06 AM Guangyu Sun
> >> > wrote:
> >> >
> >> >>
> >> >>
Hi,
I tried posting a similar question to the ffmpeg user list but got no
response. So I'm trying my luck here now. The thing is I need to be able to
control how the sws dither behaves.
Using a build from master (26.06.2021) I would expect to see different
frame hash on the these two commands:
ff
On Thu, Jun 03, 2021 at 06:58:56AM +0200, Lynne wrote:
> Apr 26, 2021, 03:27 by andreas.rheinha...@outlook.com:
>
> > Lynne:
> >
> >> From 097aed2ac33dda0bb2052d8b0402711ce95079ba Mon Sep 17 00:00:00 2001
> >> From: Lynne
> >> Date: Sat, 23 Jan 2021 19:56:18 +0100
> >> Subject: [PATCH] avpacket:
6 Jul 2021, 18:21 by sunguangy...@gmail.com:
> On Tue, Jul 6, 2021 at 1:15 AM Lynne wrote:
>
>>
>> 6 Jul 2021, 08:02 by sunguangy...@gmail.com:
>>
>> > On Mon, Jun 21, 2021 at 9:06 AM Guangyu Sun wrote:
>> >
>> >>
>> >> From: Guangyu Sun
>> >>
>> >> Without end_trimming, the last packet will co
On Tue, Jul 6, 2021 at 11:20 AM Diederick Niehorster wrote:
>
> This patch series implements a series of features, mostly enhancing the
> dshow avdevice, but also adding new functionality to avformat.
> This whole patchset enabled users of the FFmpeg API to fully
> query and control a dshow device
17 matches
Mail list logo