detected as "Generic ANC
> Data".
Sounds OK. We obviously shouldn't mimic broken muxers, especially when
there's a standard saying what ULs to use
/Tomas
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-le...@ffmpeg.org
may be a little contentious.
> Mainly leaving it here as an RFC.
I don't think we should go inventing our own ULs. The idea is good
though. It just needs to go through official channels
/Tomas
___
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.
tor 2025-07-24 klockan 00:51 +0200 skrev Marton Balint:
>
>
> On Wed, 23 Jul 2025, Tomas Härdin wrote:
>
> > ons 2025-07-23 klockan 13:45 +0200 skrev Michael Niedermayer:
> > > Fixes: read of uninitialized memory
> > > Fixes: 391916474/clusterfuzz-testcase-mi
ons 2025-07-23 klockan 00:32 +0800 skrev Zhao Zhili:
> From: Zhao Zhili
>
> Fix assert failure.
> Fix #11666.
>
> Signed-off-by: Zhao Zhili
> ---
> libavformat/mxfenc.c | 48
Looks fine
/Tomas
___
ffmpeg-devel mailing list
+ int ret = ffio_read_size(pb, klv->key + 4, 12);
> + if (ret < 0)
> + return ret;
ret != 12 is better. If it's non-negative then return AVERROR_EOF
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
tis 2025-07-22 klockan 13:56 -0700 skrev Jacob Lifshay:
> On July 22, 2025 5:21:24 AM PDT, "Tomas Härdin"
> > * combining 436M and video essence to a full frame for playout
> iirc ffmpeg architecturally doesn't support merging a 608 stream into
> video side data sin
ately, or as 436M packets, or inside the H.264 packets as SEI
messages. Or all three at the same time.
It's unfortunate that libav* has chosen to separate audio and video,
rather than carrying them as combined edit units as libmlt does, into
which we could also slip ANC data, subtitles
)
> + return err;
> avio_w8(pb, key_index - i); // key frame offset
Why not avio_w8(offset) here also?
/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".
already exists (libmlt)
The upside of a proper API is that we can export edit lists from other
formats as well, such as:
* IMF
* MKV
* MXF
Sharp minds should have realized back in 2016 that any hack that
"implements" edit lists in mov.c would also have to be duplicated in
demuxers for ot
fre 2025-06-13 klockan 13:03 + skrev Marcos Del Sol:
> Tomas Härdin:
> > tis 2025-06-10 klockan 11:42 + skrev Marcos Del Sol:
> > > WebVTT is supposed to be an extensible format.
> >
> > The syntax says otherwise. Why the W3C feels the need to specify a
>
fre 2025-06-13 klockan 20:07 +0530 skrev Gyan Doshi:
>
>
> On 2025-06-13 04:25 pm, Tomas Härdin wrote:
> > The present level of
> > edit list support could be reimplemented by just fiddling with the
> > -ss
> > and -t options. That is, the ffmpeg CLI could automa
fre 2025-06-13 klockan 18:19 +0200 skrev Michael Niedermayer:
> Hi
>
> On Fri, Jun 13, 2025 at 04:53:14PM +0200, Tomas Härdin wrote:
> > fre 2025-06-13 klockan 16:21 +0200 skrev Michael Niedermayer:
> > > > 3) remove edit list hacks from all demuxers, especially mov.c
&
fre 2025-06-13 klockan 20:27 +0530 skrev Gyan Doshi:
>
>
> On 2025-06-13 08:23 pm, Tomas Härdin wrote:
> > For now I'll probably dummy out elst support and the associated
> > tests
> > just to make progress on segmented indexes.
>
> Does `-ignore_editl
s;
---
More fine points to consider that are touched on above:
* how do we express a timeline that points to multiple files, including
external files?
* when should playback start?
* should we add an AVMediaType for timecodes?
/Tomas
___
ffmpeg-devel maili
ming complete removal of elst support is
out of the question.
For now I'll probably dummy out elst support and the associated tests
just to make progress on segmented indexes.
/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".
tis 2025-06-10 klockan 00:17 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > Hi
> >
> > These two patches are a bit of a warmup for another pass at
> > streamable
> > subtitles. FATE passes.
> >
> > /Tomas
> >
> Users who
ng the edit lists and the original uncut essence. And
of course back again to MOV if so desired.
I haven't sketched out any API yet, but it would probably closely
mirror how elst works in MOV. Care should be taken that MXF operational
pattern 3a can also fit into this API. Possibly
implementation is O(n²).
That doesn't need to hold up this patch though, since it just moves the
existing implementation
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
fre 2025-06-06 klockan 22:22 +0200 skrev Marcos Del Sol Vives:
>
>
> El 6 de junio de 2025 21:43:58 CEST, "Tomas Härdin"
> escribió:
> >
> > Sounds like the demuxer correctly rejected some broken files
> >
>
> The WebVTT standard does not call fo
From c879c0b8a810a53e1d424edb129a1aba2df1b9d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 9 Jun 2025 22:03:12 +0200
Subject: [PATCH 2/2] lavf/srtenc: avio_flush() output
This make streaming srt possible
---
libavformat/srtenc.c | 1 +
1 file changed, 1 insertion
Hi
These two patches are a bit of a warmup for another pass at streamable
subtitles. FATE passes.
/Tomas
From c5b1e1774e5d4e720295e6cb589eb7699e0ddaa3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 16 May 2025 14:07:00 +0200
Subject: [PATCH 1/2] lavf/webvttenc
(res != AVERROR_INVALIDDATA)
> +goto end;
> +av_log(s, AV_LOG_DEBUG, "Ignoring non-cue block at
> 0x%"PRIx64"\n", pos);
> }
This kind of change will cause broken files to proliferate, which is
bad for
t; information, quantization tables, and similar codec-specific elements
> to binary files for further analysis.
So you want to convert data from one binary format to another? A text
format seems more sensible if you're going through that effort
/Tomas
_
that one can change the LGPL to a GPL or AGPL.
> The purpose of this is allowing to combine LGPL with GPL or AGPL
> NOT to fork a project and prevent the parent project and its users
> from having access to the modifications.
Only users that want to downgrade the license are pre
mån 2025-03-10 klockan 09:57 -0400 skrev Devin Heitmueller:
> On Mon, Mar 10, 2025 at 5:57 AM Tomas Härdin wrote:
>
> > > Muxing together captions from different sources is pretty painful,
> > > since you have to parse/decompose the 708 stream and recombine streams
>
mån 2025-03-31 klockan 11:55 -0400 skrev Devin Heitmueller:
> Hello Tomas,
>
> On Mon, Mar 31, 2025 at 11:24 AM Tomas Härdin wrote:
> >
> > Did you report this to libcaption's devs?
>
> Respectfully, libcaption is essentially a dead project. The main repo
>
tis 2025-03-04 klockan 10:13 -0500 skrev Devin Heitmueller:
> On Tue, Mar 4, 2025 at 4:02 AM Tomas Härdin wrote:
>
> > > Even if the captions are intended to
> > > serve other countries, the country code will stay the same (defining
> > > the country code for ind
tis 2025-03-04 klockan 12:36 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > +@item ref-frame-config @tab @tab @tab
> > +@item reverb @tab S @tab argo_cvg @tab
>
> The first is libvp9enc-only, the second argo_cvg only. IMO it is
> better
> to document this at the do
ons 2025-02-19 klockan 16:42 +0100 skrev Tomas Härdin:
> Hi
>
> Rather than continue the RFC thread for this, I decided to submit a
> patch that begins the process of documenting metadata keys.
>
> There's quite a lot of keys used in the codebase, and this patch does
>
mån 2025-03-03 klockan 14:12 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > #include "libavutil/mem.h"
> > #include "atsc_a53.h"
> > +#include "itut35.h"
> > #include "get_bits.h"
> >
>
> Proper alphabetic
mån 2025-03-03 klockan 08:55 -0500 skrev Devin Heitmueller:
> On Mon, Mar 3, 2025 at 7:25 AM Tomas Härdin wrote:
> >
> > Looking at CTA-708 at the moment and noticed this. In the future we
> > might want to make it possible for the user to set the country
> > code.
&
Looking at CTA-708 at the moment and noticed this. In the future we
might want to make it possible for the user to set the country code.
This patch makes finding usage of the US country code easier
Running FATE at the moment, but I don't expected it to fail from this
kind of change.
/Tomas
tis 2025-02-18 klockan 15:43 +0100 skrev Tomas Härdin:
> Based on replies so far it seems no one is objecting to the following
> patches:
>
> * [PATCH 1/8] avformat/http: Return EIO for prematurely broken connection
> * [PATCH 2/8] libavcodec/wmadec: Return AVERROR_INVALIDDATA on
mån 2025-02-24 klockan 16:51 +0200 skrev Rémi Denis-Courmont:
> Hi,
>
> Le 23 février 2025 23:30:03 GMT+02:00, "Tomas Härdin"
> a écrit :
> > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > Le perjantaina 21. helmikuuta 2025, 20.0
sön 2025-02-23 klockan 22:51 +0100 skrev Michael Niedermayer:
> Hi
>
> On Sun, Feb 23, 2025 at 10:30:03PM +0100, Tomas Härdin wrote:
> > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a é
; > mailto:ffmpeg-devel-bounces@ff
> > > > mpeg.org>> On Behalf Of
> > > > Michael Niedermayer
> > > > Sent: Freitag, 21. Februar 2025 14:22
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org<mailto:de...@ffmpeg
lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a écrit :
> > The above said, I'm not against Rust. It has some nice properties. But
> > it does not seem very "stable" so far. Perhaps
agers.
The above said, I'm not against Rust. It has some nice properties. But
it does not seem very "stable" so far. Perhaps this has changed in
recent years..
If we're in the habit of allowing other languages I'd be in favor of
allowing C++, so that we can make use of t
tor 2025-02-20 klockan 22:08 +0100 skrev Michael Niedermayer:
> On Thu, Feb 13, 2025 at 10:29:33PM +0100, Tomas Härdin wrote:
> > Might be better to leverage afl-fuzz since it is more wily in its
> > tricks to provoke different program behavior. Then exit(1) whenever
> >
(which
> will take some time i suspect)
Have we not gone over and rejected plugins many times? I recall points
about them encouraging proliferation of proprietary code. I also feel
this project is increasingly forgetting about the power of the UNIX
pipe.
/Tomas
__
. See "man doc/ffmpeg-all.1" and search for "Audio
Codecs"
Anyway, thoughts on this?
/Tomas
From e5909ffbdd2b993aab1574901741eed2953c6600 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 19 Feb 2025 16:24:16 +0100
Subject: [PATCH] doc/metadata.tex
tis 2025-02-18 klockan 18:35 +0100 skrev Marvin S.:
>
>
> On 18 Feb 2025, at 17:56, Tomas Härdin wrote:
>
> > tor 2025-02-13 klockan 12:54 +0100 skrev Tomas Härdin:
> > > Hi
> > >
> > > In the samples_md5 patch discussion Michael wanted the propose
tor 2025-02-13 klockan 12:54 +0100 skrev Tomas Härdin:
> Hi
>
> In the samples_md5 patch discussion Michael wanted the proposed key
> to
> be documented. But it turns out we don't have any documentation for
> metadata keys! So I'm starting this thread to talk about it
FIG_SAMPLE_RATE, 0,
> ^~~
> libavcodec/allcodecs.c:954:41: error: type of formal parameter 3 is incomplete
> libavcodec/allcodecs.c:958:41: error: 'AV_CODEC_CONFIG_CHANNEL_LAYOUT'
> undeclared (first use in this function)
> AV_
. I'm on the fence about
patch 8, more feedback would be good before we push that. In general I
think taking MIME type into account is a good idea, similar to how file
extensions are sometimes used.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
tor 2025-02-13 klockan 13:03 +0100 skrev Michael Niedermayer:
> On Thu, Feb 13, 2025 at 12:40:24PM +0100, Tomas Härdin wrote:
> > ons 2025-02-12 klockan 23:03 +0100 skrev Michael Niedermayer:
> > > On Wed, Feb 12, 2025 at 12:03:37PM +0100, Tomas Härdin wrote:
> > > >
away from the e-mail-
> based submission procedure to something easy and user-friendly, would
> end up in replacing the current rarely-known mechanism with another
> even more rare and obscure procedure which would (again) force
> everybody to use the Git c
as well? (as long as one doesn’t specify which
> branches to download)
Yeah, so? Two people might want to work on a branch. This is standard
git stuff. It's even worse with github's fork feature, because most
forks don't have any actual new code. They just pollute the list wit
nity to propose informative output-
only metadata could reside in their own namespace. I propose info: for
that, so info:samples_md5 in this specific case, or maybe just
info:md5. HEVC frames could similarly have such metadata applied.
/Tomas
__
ons 2025-02-12 klockan 22:55 +0100 skrev Michael Niedermayer:
> Hi
> On Wed, Feb 12, 2025 at 11:56:16AM +0100, Tomas Härdin wrote:
> > tor 2025-02-06 klockan 16:07 +0100 skrev Michael Niedermayer:
> > > Hi Tomas
> > >
> > > On Wed, Feb 05, 2025
ons 2025-02-12 klockan 23:03 +0100 skrev Michael Niedermayer:
> On Wed, Feb 12, 2025 at 12:03:37PM +0100, Tomas Härdin wrote:
> > tor 2025-02-06 klockan 15:58 +0100 skrev Michael Niedermayer:
> > > Hi Tomas
> > >
> > > On Wed, Feb 05, 2025 at 03:24:24PM +010
ons 2025-02-12 klockan 12:49 +0100 skrev Nicolas George:
> Tomas Härdin (HE12025-02-12):
> > This is aristocracy, not democracy.
>
> Why do you believe democracy would be a good model for a Libre
> Software
> project?
The title of the thread includes the word "democrat
ons 2025-02-12 klockan 13:27 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > ons 2025-02-12 klockan 12:14 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > >
> > > >
> > > > ___
ronger voice than those with minimal
> involvement. This creates a system where contribution equals
> influence.
This is aristocracy, not democracy. Just set up a non-profit with
appropriate bylaws. This is a solved problem.
/Tomas
___
ffmpeg-devel m
ons 2025-02-12 klockan 12:14 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> &
er/input device
>
> So this Project is about someone within GSoC re structuring
> libavradio
> and interfacing with a demuxer/input device as was previously
> suggested.
>
> Please clearly list all requirements you have for this to get into
> git master
This is still vastly out o
ons 2025-02-05 klockan 15:22 +0100 skrev Tomas Härdin:
> I trust that ticket #385 has a FATE test these days
Just tested the file in said ticket and it transcodes fine with this
patch applied.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-de
tor 2025-02-06 klockan 15:58 +0100 skrev Michael Niedermayer:
> Hi Tomas
>
> On Wed, Feb 05, 2025 at 03:24:24PM +0100, Tomas Härdin wrote:
> > Seems reasonable to me and passes FATE
> >
> > /Tomas
>
> > avformat.h | 2 +-
> > format.c | 8 +
tor 2025-02-06 klockan 16:07 +0100 skrev Michael Niedermayer:
> Hi Tomas
>
> On Wed, Feb 05, 2025 at 03:20:09PM +0100, Tomas Härdin wrote:
> >
>
> > libavformat/flacdec.c | 6 ++
> > tests/ref/fate/cover-art-aiff-id3v2-remux | 5 +++--
tis 2024-11-12 klockan 18:49 +0100 skrev Tomas Härdin:
> fre 2024-11-08 klockan 11:29 +0100 skrev Tomas Härdin:
> > Passes fate-mxf
>
> Will push in a day or two
.. or a month or two. Tested and pushed.
/Tomas
___
ffmpeg-devel mail
dex_table(mxf, track->index_sid);
>
> - if (!t || track->wrapping == UnknownWrapped)
> + if (!t || track->wrapping == UnknownWrapped || edit_unit >
> INT64_MAX - track->edit_units_per_packet)
Looks OK
/Tomas
___
ffmpeg-devel mail
(st->codecpar->codec_id);
> + if (st->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE
> + || st->codecpar->codec_id == AV_CODEC_ID_PCM_S24LE) {
> + FFStream *const sti = ffstream(st);
> + sti-
Seems reasonable to me and passes FATE
/Tomas
From ecc3459990f2871fd907f96fe66362b8fea41bd8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Peter=20Zeb=C3=BChr?=
Date: Tue, 21 Nov 2023 14:16:49 +0100
Subject: [PATCH 8/8] Make mime-type award a bonus probe score
This changes the default behaviour of
From 6dca5b958693588d74081e8fa29f05a5f257c841 Mon Sep 17 00:00:00 2001
From: Ulrik Mikaelsson
Date: Tue, 22 Aug 2023 13:55:14 +0200
Subject: [PATCH 7/8] avformat/mp3dec: Subtract known padding from duration
When an Info-tag is present, marking initial and trailing samples as
padding, those sampl
I trust that ticket #385 has a FATE test these days
/Tomas
From 8c105c5953c494402749eb27d2eb6a7a2393f855 Mon Sep 17 00:00:00 2001
From: ekir
Date: Tue, 18 Apr 2023 17:31:43 +0200
Subject: [PATCH 6/8] GOL-1361: Remove invalid CTTS sample_offset check
We checked in this places:
* In 8.6.1.3 of
extended metadata.
However, many times, the IO-layer is not at fault, the input data is simply
corrupted (truncated), so we return `AVERROR_INVALIDDATA` here as well.
---
Tomas: changed to use AVERROR_EOF
---
libavformat/flacdec.c | 16
1 file changed, 12 insertions(+), 4 deletions
This one is difficult to test. Any ideas?
/Tomas
From c8689abcbf9bf85e1f7775a347b6bc994679cb77 Mon Sep 17 00:00:00 2001
From: Jonathan Murray
Date: Thu, 31 Mar 2022 16:23:17 +0200
Subject: [PATCH 5/8] rtmp: Set correct message stream id when writing as
server
rtmp_write is used both for
From e1c4dfa4cc7a574f6fac76c11591547d3cd90ad2 Mon Sep 17 00:00:00 2001
From: Mattias Wadman
Date: Mon, 11 Oct 2021 15:38:13 +0200
Subject: [PATCH 3/8] libavformat/flacdec: Export samples md5 as metadata
Will be used by mal to compare metadat md5 with decoded samples md5.
Part of fixing https://
ma_decode_superframe, previous occurrences of returning
AVERROR_INVALIDDATA are also affected by this. This includes
"total_gain overread" and a "channel exponents_initialized" check.
---
Tomas: changed some -1's to AVERROR_INVALIDDATA
---
libavcodec/wmadec.c | 40 +++
Rebased and trimmed down Spotify patchset. Does not include the mfra or
ID3v2 stuff since those are turning out to be bigger tasks
/Tomas
From c808ca473529ca952c42f00d12aa50ade38850d8 Mon Sep 17 00:00:00 2001
From: Ulrik
Date: Mon, 27 Jul 2020 11:46:56 +0200
Subject: [PATCH 1/8] avformat/http
mån 2024-12-16 klockan 16:23 +0100 skrev Tomas Härdin:
> Updated patchset. Patches 1-2 could maybe be squashed
>
> The end result of these patches is that fragmented files probe much
> faster over HTTP. The final patch is just a small optimization to
> movenc
Darn, this breaks fa
mån 2024-12-16 klockan 16:27 +0100 skrev Tomas Härdin:
> Two reference files. One with sidx+mfra, the other with only mfra
Forgot the FATE refs. Updated patch attached
/Tomas
From f6d28d84413f2f674cfac86d4ed0868e8afb604b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date:
From 2698fc4b53e482adfe09781d90aa936a567524aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 14:15:12 +0100
Subject: [PATCH 6/6] lavf/movenc: Write version 0 (32-bit) traf if possible
This results in smaller files.
Update fate-movenc accordingly
Without this we get a bogus bitrate whenever we rely on mfra
With this patch we could potentially drop -use_mfra_for
/Tomas
From 7484bb3b83e23b152e1cabb7b00bdceff0a217e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 16:15:10 +0100
Subject: [PATCH 4/6] lavf
This avoid a seek on some files that might accidentally have a
seemingly valid mfra offset
/Tomas
From 23f1ddc8ae4064f6d03efd54fb9da5ca9fc450ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 11 Dec 2024 14:56:31 +0100
Subject: [PATCH 3/6] lavf/mov: Parse and verify the
Hopefully I got the calls to mov_switch_root() right.
mov_read_default() just ends up calling mov_read_moof() twice on the
first moof
/Tomas
From bbcff7581177b25b03e0f53ebb4732b7f10f0616 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 16 Dec 2024 15:25:44 +0100
Subject
Updated patchset. Patches 1-2 could maybe be squashed
The end result of these patches is that fragmented files probe much
faster over HTTP. The final patch is just a small optimization to
movenc
/Tomas
From 357be61ac65149b826769c07a7a3dbb7af7164db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas
ons 2024-12-11 klockan 15:41 +0100 skrev Tomas Härdin:
> ons 2024-12-11 klockan 15:24 +0100 skrev Tomas Härdin:
> > Hi
> >
> > This patchset addresses the issues Spotify has been having reading
> > fragmented MP4 over HTTP. The issue is that mov.c does hundreds of
>
ons 2024-12-11 klockan 15:24 +0100 skrev Tomas Härdin:
> Hi
>
> This patchset addresses the issues Spotify has been having reading
> fragmented MP4 over HTTP. The issue is that mov.c does hundreds of
> seeks unless -use_mfra_for is set to something other than auto.
> H
I also noticed movenc writes moof after mdat rather than before it.
This forces movdec to read more than would otherwise be necessary
/Tomas
From db3d3e7bf6d12493e571506dc85003d5f957e964 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 11 Dec 2024 14:59:10 +0100
Subject
This saves a seek on files that don't have mfra but where the last 4
bytes happen to seeem valid
It just struck me that we could tighten the bound on mfra_size, because
it has to be at least 24
/Tomas
From ccf83120683dcbcaba9191c058b820e516392b11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?
it in
init_input()
> > Another concern is HLS, which mandates ID3 support for MP3, AAC,
> > ADTS,
> > AC3 and EAC3:
> > https://datatracker.ietf.org/doc/html/rfc8216#section-3.4
> > The spec doesn't say whether by "ID3" it means ID3v1 or ID3v2.
>
sön 2024-11-24 klockan 02:37 +0100 skrev Michael Niedermayer:
> Hi
>
> On Fri, Nov 22, 2024 at 03:50:18PM +0100, Anton Khirnov wrote:
> > Quoting Tomas Härdin (2024-11-22 10:51:21)
> > > Hi all
> > >
> > > So after looking at options for how to better
fre 2024-11-22 klockan 15:50 +0100 skrev Anton Khirnov:
> Quoting Tomas Härdin (2024-11-22 10:51:21)
> > Hi all
> >
> > So after looking at options for how to better deal with ID3v2 I'm
> > leaning towards creating a demuxer for it. I'm writing this before
outputting the cover art once and only
once, regardless of seeks. That way it doesn't have to be kept around
in RAM
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
ons 2024-11-13 klockan 15:28 +0100 skrev Tomas Härdin:
> tis 2024-10-29 klockan 15:45 +0100 skrev Tomas Härdin:
> > Reasonable enough
> >
> > Spotify comments
> >
> > mp3 input misdetected as mpeg ps and fails to decode
> >
> > Po
need a mechanism to transfer ownership of the
trademark and domain name sooner or later.
If Debian can deal with this problem then I'm sure we can as well.
/Tomas
*) the number of people who can be hit by a bus and the project still
chugging along
___
superframe(AVCodecContext *avctx,
> AVFrame *frame,
> len = buf_size - pos;
> if (len > MAX_CODED_SUPERFRAME_SIZE || len < 0) {
> av_log(s->avctx, AV_LOG_ERROR, "len %d invalid\n", len);
> +ret = -1;
The
tis 2024-10-29 klockan 15:50 +0100 skrev Tomas Härdin:
> This makes me feel we should probably just rely on mfra
An update on this: it seems 6.x fixes this issue for Spotify. It seems
"-use_mfra_for pts" now does what they need, but I need confirmation on
that. If this is the case
tis 2024-10-29 klockan 16:01 +0100 skrev Tomas Härdin:
> tis 2024-10-29 klockan 11:57 -0300 skrev James Almer:
> > On 10/29/2024 11:47 AM, Tomas Härdin wrote:
> > > Could maybe use some kind of compile-time assert that
> > > FLAC_STREAMINFO_SIZE == MD5_BYTE_SIZE +
tor 2024-11-14 klockan 01:26 +0100 skrev Michael Niedermayer:
> On Wed, Nov 13, 2024 at 03:26:40PM +0100, Tomas Härdin wrote:
> > ons 2024-11-13 klockan 14:40 +0100 skrev Michael Niedermayer:
> > > Hi
> > >
> > > On Tue, Oct 29, 2024 at 03:44:30PM +0100, Tomas
tis 2024-10-29 klockan 15:45 +0100 skrev Tomas Härdin:
> Reasonable enough
>
> Spotify comments
>
> mp3 input misdetected as mpeg ps and fails to decode
>
> Possible other solutions:
> • Improve mp3 probe code to give higher score
> • Improve
ons 2024-11-13 klockan 14:40 +0100 skrev Michael Niedermayer:
> Hi
>
> On Tue, Oct 29, 2024 at 03:44:30PM +0100, Tomas Härdin wrote:
> > Needs a sample. An option or setting for probe size might be a good
> > idea
> >
> > Spotify comments
> > --
fre 2024-11-08 klockan 11:29 +0100 skrev Tomas Härdin:
> Passes fate-mxf
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 em
ons 2024-10-30 klockan 11:44 +0100 skrev Tomas Härdin:
> I also made some test files to demonstrate the differences in behavior.
> What's being addressed here is early termination of the file. One thing
> to bikeshed over is whether to return AVERROR_EOF or
> AVERROR_INVALIDDATA
ects.
> But when i recently started posting related work, tomas questioned
> if spliting libpostproc into a seperate source repository actually is a good
> idea.
>
> No invoice was submitted yet, so we could likely still change
> this to something else, if thats what people prefer
tor 2024-10-31 klockan 20:02 +0100 skrev Marton Balint:
>
>
> On Tue, 29 Oct 2024, Tomas Härdin wrote:
>
> > tis 2024-10-29 klockan 12:21 -0300 skrev James Almer:
> > > > From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00
> > > > 2001
&
Also passes fate-mxf
/Tomas
From 164175d6f7e2e1eab767c129d953e6e9ebbfc94d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:26:24 +0100
Subject: [PATCH 2/2] lavf/mxfenc: Return AVERROR(EINVAL) in
mxf_write_jpeg2000_subdesc() is pixfmt not set
Passes fate-mxf
/Tomas
From 8f221258a9e5328c4a03fef6e8eab18ce20ce4f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:24:05 +0100
Subject: [PATCH 1/2] lavf/mxfenc: Make write_desc return int
This enables returning AVERRORs
---
libavformat/mxfenc.c | 61
tor 2024-10-31 klockan 09:57 +0100 skrev Tomas Härdin:
> tis 2024-10-29 klockan 08:48 -0700 skrev Pierre-Anthony Lemieux:
> > LGTM
>
> Will push later today
Wups, forgot to. Pushed now though
/Tomas
___
ffmpeg-devel mailing li
1 - 100 of 1155 matches
Mail list logo
