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.
---
libav
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=20
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
This one is perhaps a bit dubious, but on frags.mp4 it saves a seek. I
have no strong feelings on this patch, it just struck me as far simpler
to always read mfra
I checked the ISO/IEC spec and mfra may be present in any file that is
isom branded. Usually it is only present for fragmented files
I
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?Tomas=20H
ons 2024-11-27 klockan 08:34 +0100 skrev Anton Khirnov:
> > It's just an essence stream.
>
> You spent too much time around MXF, consider exorcism. I assume this
> piece of jargon means "raw/elementary stream", correct me if I'm
> wrong.
Blasphemy. But yes, it is MXF parlance for that. It also us
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
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
going any further with it to get some feedback
A proper demuxer would change things up especially for mp3, since a lot
of files that now probe as "mp3" with
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
tis 2024-11-19 klockan 14:19 + skrev Derek Buitenhuis:
> I do not have faith things can improve as long as Fabrice controls
> the the trademark and domain name and only speak to Michael
I've pointed out before on this list that this is a very low bus
factor*. We're going to need a mechanism to
> Needs a sample.
Actually, returning more sensible errors makes sense on its own even
without a sample. However:
> @@ -879,8 +881,10 @@ static int wma_decode_superframe(AVCodecContext *avctx,
> AVFrame *frame,
> return AVERROR_INVALIDDATA;
>
> if ((s->last_supe
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
tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer:
> Hi all
>
> Should libpostproc be split out into a seperate source repository ?
>
> Several people did over the years want libpostproc removed, and such
> a task was part of the submitted and approved STF 2024 projects.
> But when i r
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
---
libavform
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
lör 2024-11-02 klockan 12:34 +0100 skrev Michael Niedermayer:
> Hi
>
> At teh current videolan developer days there where several surprise votes on
> FFmpegs
> infractructure. And to the best of my knowledge no remote participation
> and no recording.
>
> So let me try to reply to the idea of th
tor 2024-10-31 klockan 01:08 +0100 skrev Michael Niedermayer:
> Hi
>
> Theres a problem with libavutil, or maybe more than one
>
> a library implementing a codec that tries do use libavutil and itself
> is
> used by libavcodec. Creates a (build) dependancy like this
> libavutil -> libmycodec -> l
tis 2024-10-29 klockan 08:48 -0700 skrev Pierre-Anthony Lemieux:
> LGTM
Will push later today
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpe
tis 2024-10-29 klockan 15:43 +0100 skrev Tomas Härdin:
> Hi
>
> This is a set of patches that Spotify wants upstreamed, based on
> n6.0.1. I have rebased all of them except except "[PATCH 03/18]
> fftools/ffmpeg: Always exit_program(1) for I/O-errors"
Update on t
tis 2024-10-29 klockan 18:42 +0100 skrev Michael Niedermayer:
> On Tue, Oct 29, 2024 at 03:50:05PM +0100, Tomas Härdin wrote:
> > Reasonable enough. Might want a sample
> >
> > Spotify comments
> >
> > Unexpected EOF is treated as invalid data
tis 2024-10-29 klockan 18:42 +0100 skrev Michael Niedermayer:
> On Tue, Oct 29, 2024 at 03:50:05PM +0100, Tomas Härdin wrote:
> > Reasonable enough. Might want a sample
> >
> > Spotify comments
> >
> > Unexpected EOF is treated as invalid data
sön 2024-10-27 klockan 02:09 +0200 skrev Nicolas Gaullier:
> Signed-off-by: Nicolas Gaullier
> ---
> tests/fate/audio.mak | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Fixes fate-flcl1905 on a clean build
/Tomas
___
ffmpeg-devel mailin
tis 2024-10-29 klockan 12:21 -0300 skrev James Almer:
> > From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00
> > 2001
> > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
> > Date: Tue, 29 Oct 2024 16:13:04 +0100
> > Subject: [PATCH] lavf/mxfenc: Use nb_components, not
> > av_pix_fmt_count_pla
sön 2024-10-27 klockan 21:06 -0700 skrev Pierre-Anthony Lemieux:
> av_pix_fmt_count_planes() in
>
> On Thu, Dec 21, 2023 at 3:11 AM Tomas Härdin wrote:
> >
> > ons 2023-12-20 klockan 18:04 +0100 skrev Cédric Le Barz:
> > > Le 19/12/2023 à 14:36, Tomas Härdin a écr
I think we can drop this one. I thought I'd post it to the list either
way
Spotify comments
To be able to detect severely fragmented MP4 files, and trigger special
handling for them (reducing Photon chunk concurrency). For these files,
the default handling causes so much I/O from
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 + 18. I'm thinking putting in
> > st-
> > > codecpar->ex
Needs sample. Also might be incorrect if mdat has moov atoms inside
mdat for some reason. But the concept is reasonable enough - mov files
tend to have the moov atom either in the header or in the footer. The
need for this patch may have been deprecated by the introduction of
mfra parsing, which is
tor 2024-10-24 klockan 18:59 +0100 skrev South East:
> ffmpeg has existing support for MLV raw video files;
> libavformat/mlvdec.c.
> Since this was added, MLV has been extended to support LJ92
> compressed
> image data. These patches build on lossless DNG support in 7.2-dev
> to
> enable handling
Needs a sample.
Spotify comments
a known broken wma input file fails with ambiguous error code and is
treated as a transient instead of a permanent error.
/Tomas
From 5715032d028695ecc6bf69e88046dbe37620aa12 Mon Sep 17 00:00:00 2001
From: Jonathan Murray
Date: Wed, 9 Jun 2021 1
From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 29 Oct 2024 16:13:04 +0100
Subject: [PATCH] lavf/mxfenc: Use nb_components, not av_pix_fmt_count_planes()
This fixed https://trac.ffmpeg.org/ticket/11267
---
libavformat/mxfen
Could maybe use some kind of compile-time assert that
FLAC_STREAMINFO_SIZE == MD5_BYTE_SIZE + 18. I'm thinking putting in st-
>codecpar->extradata + st->codecpar->extradata_size - MD5_BYTE_SIZE for
the offset
Spotify comments
Make it possible to verify sample checksum for FLAC fil
Reasonable enough. Might want a sample
Spotify comments
Unexpected EOF is treated as invalid data
/Tomas
From 4d803c5f5c13e194a0e52d287f021b73ec7172bd Mon Sep 17 00:00:00 2001
From: Ulrik
Date: Thu, 26 Jan 2023 17:51:02 +0100
Subject: [PATCH 11/15] avformat/flacdec:Return correc
Some samples would be nice. The commit messages mentions many millions
of files, which we obviously can't fit into the FATE suite. But one or
two would be nice
Spotify comments
None
/Tomas
From 30e364f3b8d382f2ec59254ca41fc8a25f1133ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pete
Reasonable enough
Spotify comments
Wrong duration due to not distracting padding samples.
Reported upstream: https://trac.ffmpeg.org/ticket/10163 (has patch) was
also sent as a patch to the dev mailing with subject “[FFmpeg-devel]
[PATCH v3] avformat/mp3dec: Subtract known paddi
This makes me feel we should probably just rely on mfra
Spotify comments
None
/Tomas
From c3adfabb5ad565f562c6a187c2fa2913755d4345 Mon Sep 17 00:00:00 2001
From: Mattias Wadman
Date: Fri, 26 May 2023 14:16:58 +0200
Subject: [PATCH 13/15] avformat/mov: Add more moov and moov chil
Needs a sample
Spotify comments
mp4 file fails to demux due to CTTS sample offset check that seems to
contradict specification
https://github.com/FFmpeg/FFmpeg/commit/4093220029a4d77f272c491e9299680480a08c00
the trac ticket for that change: https://trac.ffmpeg.org/ticket/385
a n
Don't know enough RTMP to comment on. Since the ticket is still open on
red5's github repo I presume this is still an issue
Spotify comments
Interop issue with red5 RTMP server. Is unknown if this is a bug in
red5 or ffmpeg as the RTMP spec is vague and the ffmpeg code uses
differ
Needs sample. Not a huge fan of heuristics like this - surely there's a
way to tell within the first mdat/moov/moof seen?
Spotify comments
Failure to parse non-fragmented file with many mdat-boxes
/Tomas
From 1c67cfd91cc3d18a2e4e1402bb439fe4db0f76b2 Mon Sep 17 00:00:00 2001
From
Needs sample
'Revert "flac: Increase change penalty and header lookahead"' reverts
this, so it seems it's no longer necessary. I therefore haven't
bothered mailing in that patch
Spotify comments
Decrease possibility for flac demuxer frame detect heuristics to find
false frame sta
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 mpeg ps probe code to give lower score
• Make it possible at runtime to enable/disable format/code
Use of stdbool.h might cause issues on some platforms. Otherwise looks
reasonable to me.
Spotify comments
Might not be a priority anymore when we’re using a caching http proxy
to hide some network problems.
/Tomas
From d42ebdc41d02ade1921b91f278e90a15ce33a32f Mon Sep 17 00:00:00
Needs a sample. An option or setting for probe size might be a good
idea
Spotify comments
In mp3 files, id3v2 tag with huge cover art causes the probe code to
not identify valid mp3 files as mp3. Increase default buffer so that
probe can see mp3 frames.
Might not be a priority as
Hi
This is a set of patches that Spotify wants upstreamed, based on
n6.0.1. I have rebased all of them except except "[PATCH 03/18]
fftools/ffmpeg: Always exit_program(1) for I/O-errors" which seems to
need a rewrite due to large changes in fftools since n6.0.1. For now I
want feedback on the patc
mån 2024-10-14 klockan 16:46 +0200 skrev Tomas Härdin:
> Passes fate-mxf
Will push in a few days
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
pful, but there's still
> a
> steep learning curve to get all this put together.
>
> Any help would be greatly appreciated.
>
> On Sat, Oct 12, 2024 at 1:59 AM Tomas Härdin wrote:
>
> > ons 2024-10-09 klockan 20:08 -0600 skrev Devon Sookhoo:
> > &
Passes fate-mxf
/Tomas
From 6e47a43251226c88484f99d18c6b052bb1f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 14 Oct 2024 16:45:35 +0200
Subject: [PATCH] lavf/mxfdec: Set a scan direction explicitly
This prevents a theoretical case where seeks to a gap in an inde
ons 2024-10-09 klockan 20:08 -0600 skrev Devon Sookhoo:
> Sounds good, I'll look into adding rawvideo to the list of
> movcodec_tags.
>
> Looking at the AVPixFmtDescriptor, I noticed: AVComponentDescriptor
> comp[4]; Does this line limit the component count to only four?
> Encoding
> video with ma
ons 2024-10-09 klockan 07:38 -0600 skrev Devon Sookhoo:
> With this patch, I was able to use the following command to generate
> an
> uncompressed mp4:
> $ ffmpeg -i input.mp4 -c:v rawvideo -pix_fmt rgb24 -tag:v uncv
> out.mp4
>
> The output file successfully played in GPAC.
>
> My first
> > As suggested, this next patch uses av_pix_fmt_desc_get() to get the
> > nb_components
> >
> > What is considered sufficient for testing? Is this done by running
> > fate?
>
> I mean adding tests to FATE. Are there any reference files we could
> use?
Wups, I forgot this is a muxer patch, so r
tor 2024-10-03 klockan 10:52 -0600 skrev Devon Sookhoo:
> > "mov_write_uncC_tag() doesn't seem to be called from anywhere"
>
> Yes, I wanted to divide my contributions up into small sections that
> are
> easy to review. However, this means that each contribution isn't a
> full
> implementation wh
tis 2024-10-01 klockan 18:53 -0600 skrev Devon Sookhoo:
> Hello,
>
> I attached the .patch so hopefully this is easier for you to apply.
> The
> patch itself isn't very impressive, but is intended to be the first
> of a
> series of contributions to generate uncompressed MP4 video. I'm
> hoping to
tis 2024-10-01 klockan 08:48 -0600 skrev Devon Sookhoo:
> Hello, I'm implementing ISO/IEC 23001-17:2024 (MPEGs uncompressed
> codec)
> and am looking for an FFmpeg developer to review/approve my
> contributions.
It's easier if you attach the patch normally so people can download and
apply it
/Tom
fre 2024-09-27 klockan 15:22 +0200 skrev Tomas Härdin:
> I'll push patches 1, 4 and 5 in a few days.
Pushed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit li
I'll push patches 1, 4 and 5 in a few days.
/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 "unsubscrib
mån 2024-09-23 klockan 23:32 +0200 skrev Michael Niedermayer:
> Fixes: Use of uninitialized memory
> Fixes: 71444/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 5448597561212928
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Sig
From e036dec9bdd621db809bb23822b7d22f66ab43fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Sun, 15 Sep 2024 22:46:55 +0200
Subject: [PATCH 5/5] lavf/mxfdec: Remove a call to avio_tell() in
klv_read_packet()
---
libavformat/mxfdec.c | 22 ++
1 file ch
This is the big one. The offset_temp calculations that used to be part
of mxf_edit_unit_absolute_offset() are moved to
mxf_compute_index_tables() and are done only once. This also makes
random access in mxf_edit_unit_absolute_offset() possible
/Tomas
From 8d1f84e6b047fcaeba74a76cfc6b8f3ebc450145 M
mxf_match_uid() is rather slow and gets called a lot. Unrolling it like
this saves some cycles, but probably not enough to justify making the
code much more verbose
/Tomas
From ed92d030212e230c7a12d2b265feb470ffd5caa8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Sat, 14 Se
This gives some gains, but would probably be nicer if it leveraged the
type system by defining a specific type for 12-byte keys so there can
be no accidental mixup
/Tomas
From 367a59ac08624326841bfbecbb5cffb664567d27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Sat, 14 Sep
This patchset speeds up mxfdec in various ways. The test file has been
generated with
ffmpeg -t 1 -f lavfi -i testsrc -s 160x120 out2.mxf
Performance is measured with callgrind using the command
valgrind --tool=callgrind ./ffmpeg_g -loglevel quiet -i out2.mxf -codec copy
-f null -
The ca
fre 2024-09-20 klockan 04:59 +0200 skrev Martin Schitter:
> ---
> libavformat/mxf.c | 1 +
> libavformat/mxfdec.c | 1 +
> 2 files changed, 2 insertions(+)
Looks fine, as previously discussed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
mån 2024-09-16 klockan 10:00 +0200 skrev Tomas Härdin:
> Will push in a day or two
Pushed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
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".
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
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
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_MXF_fuzzer-
> 5282235077951488
>
> Found-by: continuous fuzzin
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_MXF_fuzzer-
> 5282235077951488
>
> Found-by: continuous fuzzin
fre 2024-09-13 klockan 01:33 +0200 skrev Michael Niedermayer:
> Fixes: signed integer overflow: 9223372036840103968 + 538976288
> cannot be represented in type 'long'
> Fixes: 70604/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 4844090340999168
>
> Found-by: continuous fuzzing process
>
tor 2024-09-12 klockan 07:52 +0200 skrev Martin Schitter:
> + { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x07,0x01,0x00
> }, 14, AV_CODEC_ID_DNXUC }, /* DNxUncompressed/SMPTE RDD 50 */
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x
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
ons 2024-09-11 klockan 10:15 +0200 skrev Martin Schitter:
> This adds support for empty 'fill' boxes while decoding MXF files.
> ---
> libavformat/mxfdec.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 142b3e6..701fc9f 100644
>
ons 2024-09-11 klockan 01:08 +0200 skrev martin schitter:
>
>
> On 10.09.24 15:14, Tomas Härdin wrote:
> > > +++ b/libavformat/mxf.c
>
> > > + { {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,
> > &
tis 2024-09-10 klockan 16:06 +0200 skrev Martin Schitter:
> ---
> libavformat/mxf.c | 1 +
> libavformat/mxfdec.c | 1 +
> 2 files changed, 2 insertions(+)
Commit message could be better, something like "Add DNxUncompressed
ULs"
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index a73
mån 2024-09-09 klockan 02:04 +0200 skrev Marvin Scholz:
> ---
> libavformat/mxfdec.c | 35 ---
> 1 file changed, 16 insertions(+), 19 deletions(-)
C99 style is fine now? OK then
/Tomas
___
ffmpeg-devel mailing list
ffmpe
tis 2024-09-03 klockan 10:02 +0200 skrev Nicolas Gaullier:
> The time_base was a bad guess.
>
> Currently, fate-time_base test data assumed that overriding the input
> time_base would affect the frame_rate, but this behaviour is not
> documented, so just fix the fate data now that this is fixed.
>
mån 2024-09-09 klockan 01:55 +0200 skrev Marvin Scholz:
> ---
> libavformat/mxfdec.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
Looks OK. Doesn't really change anything
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@f
mån 2024-09-02 klockan 11:52 +0200 skrev Nicolas Gaullier:
> Following yesterday posts by Anton/Tomas on version 1.
>
> v3:
> - do not fall back to time_base (that was my v2)
> - do not remove "-r 25" in the fate test with streamcopy (see below)
>
> What comes out:
> - mxfenc behaves the same as
tis 2024-08-27 klockan 01:33 +0200 skrev Marton Balint:
> If the demuxer does not provide per-stream indexes, the generic seek
> search can
> attempt to read the whole media file from the beginning when seeking.
> For large
> MXF files this can cause huge lockups for a seek after the last
> timesta
tor 2024-08-22 klockan 18:55 +0200 skrev Nicolas Gaullier:
> For fate-copy-trac4914, this is a revert of
> 10185e2d4c1e9839bc58a1d6a63c861677b13fd0.
>
> Signed-off-by: Nicolas Gaullier
> ---
> tests/fate/ffmpeg.mak | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
OK I guess. It isn't
sön 2024-09-01 klockan 12:53 +0200 skrev Anton Khirnov:
> Quoting Nicolas Gaullier (2024-08-22 18:55:32)
> > The input time_base was a bad guess.
> >
> > Currently, fate-time_base test data assumed that overriding the
> > input
> > time_base would affect the frame_rate, but this behaviour is not
>
ons 2024-08-21 klockan 23:19 +0200 skrev Marton Balint:
>
>
> On Wed, 21 Aug 2024, Marc-Antoine ARNAUD wrote:
>
> > Le sam. 17 août 2024 à 21:15, Marton Balint a écrit
> > :
> >
> > >
> > >
> > > On Wed, 14 Aug 2024, Marc-Antoine Arnaud wrote:
> > >
> > > > ---
> > > > libavformat/mxfdec.c
fre 2024-08-23 klockan 10:14 +0200 skrev Nicolas Gaullier:
> The time_base was a bad guess.
>
> Currently, fate-time_base test data assumed that overriding the input
> time_base would affect the frame_rate, but this behaviour is not
> documented, so just fix the fate data now that this is fixed.
>
ons 2024-08-14 klockan 09:59 +0200 skrev Marc-Antoine Arnaud:
> sponsored by nxtedition
> ---
> libavformat/mxfdec.c | 56
> 1 file changed, 56 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index df958819300..83f9e5fc9e0
1 - 100 of 1085 matches
Mail list logo
