fre 2019-03-15 klockan 18:45 +0100 skrev Nicolas George:
> Yufei He (12019-03-15):
> > I did not find a better way to make this work.
>
> It exists: make your client libraries GPL-compatible.
I second this
/Tomas
___
ffmpeg-devel mail
chunk_size, bytes_per_sample;
> int ret = 0;
> AVStream *st = s->streams[0];
>
> -if (avio_read(pb, preamble, AUD_CHUNK_PREAMBLE_SIZE) !=
> -AUD_CHUNK_PREAMBLE_SIZE)
> -return AVERROR(EIO);
> +/* AUD files don
m Blade Runner that could be used but wouldn't distributing them
> violate copyright?
Cutting them down to a second or two should be fine I think. If we want
to be paranoid we could zero out the sample data as well, but I doubt
anyone cares. There's plenty of such samples in FATE. We could do this
in a separate thread, it doesn't have to hold up this patch
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
tor 2019-03-21 klockan 01:20 +0100 skrev Carl Eugen Hoyos:
> Hi!
>
> Attached patch makes the only argument to the common probe() function
> const.
Looks good to me. Passes FATE.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
ds like you want to mux them.
It's certainly possible to ape whatever peculiaritites Sony has for its
MXF muxer, I've done similar things with MXF in the past.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
fre 2019-03-22 klockan 12:47 + skrev Yufei He:
> Hi Tomas
>
> From my tests, I find FFmpeg can demux XAVC mxf files from Sony and
> find the video stream is actually h.264 data. This is very good to us.
>
> Actually Sony XAVC mxf has a lot of restrictions on mxf file wr
oyer, so
MAINTAINERS should be updated to point to this one. I also don't work
with MXF any longer, so a new maintainer may be needed for that
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffm
On Tue, 2017-05-16 at 15:42 -0300, James Almer wrote:
> On 5/16/2017 3:13 PM, Tomas Härdin wrote:
> >
> > Hi
> >
> > I got a question from Diego via IRC about what license cinepakenc.c
> > actually has, since the first commit message just has a message
> >
ar *name;
> +enum MXFMetadataSetType type;
> +int instance;
> +} MXFPackage;
> [...]
Looks OK. This would make it easier if someone is crazy enough to
implement the higher op types in the future. I still maintain that
libmxf/bmxlib is better for that however
/Tomas
signature
> -mxf_write_package(s, &packages[i]);
> +for (i = 0; i < package_count; i++) {
> +packages[i].uuid_offset = track_count;
> +track_count += mxf_write_package(s, &packages[i]);
> +}
I see st->index + 1 when deriving instance from uuid_offset,
check if any of the streams contain a reel_name */
> +for (i = 0; i < s->nb_streams; i++) {
> +st = s->streams[i];
> +if (entry = av_dict_get(st->metadata, "reel_name", NULL,
> 0)) {
> +packages[2].name = entry->value;
On 2017-11-28 05:35, Mark Reid wrote:
On Mon, Nov 27, 2017 at 2:40 AM, Tomas Härdin wrote:
On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
@@ -1396,13 +1410,17 @@ static int mxf_write_package(AVFormatContext
*s, MXFPackage *package)
}
// write multiple descriptor reference
On Tue, 2017-11-28 at 21:09 +0100, Michael Niedermayer wrote:
> On Mon, Nov 27, 2017 at 11:00:51AM +0100, Tomas Härdin wrote:
> > On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> > > ---
> > >
e_track, package);
+mxf->track_uuid_offset++;
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
mxf_write_track(s, st, package);
mxf_write_sequence(s, st, package);
mxf_write_structural_component(s, st, package);
+mxf-
es[2].type = SourcePackage;
+packages[2].instance = 2;
+packages[1].ref = &packages[2];
+ package_count = 3;
+}
+
mxf_write_preface(s);
mxf_write_identification(s);
mxf_write_content_storage(s, packages, package_count);
Looks OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, 2017-11-29 at 20:18 -0800, Mark Reid wrote:
> On Wed, Nov 29, 2017 at 1:36 AM, Tomas Härdin
> wrote:
>
> > On 2017-11-29 05:11, Mark Reid wrote:
> >
> > > @@ -980,7 +980,7 @@ static void
> > > mxf_write_structural_component(AVFo
to me :)
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg -i output.mxf -vcodec copy -acodec copy remuxed.mxf
Ideally remuxed.mxf is identical to output.mxf
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, 2017-12-07 at 22:40 +0100, Michael Niedermayer wrote:
> On Thu, Dec 07, 2017 at 04:41:09PM +0100, Tomas Härdin wrote:
> > On 2017-12-05 05:46, Mark Reid wrote:
> > > @@ -1398,16 +1397,26 @@ static void
> > > mxf_write_package(AVFormatCont
On Thu, 2017-12-07 at 14:45 -0800, Mark Reid wrote:
> On Dec 7, 2017 7:45 AM, "Tomas Härdin" wrote:
>
> On 2017-12-05 05:46, Mark Reid wrote:
>
> > ---
> > libavformat/mxf.h| 1 +
> > libavformat/mxfenc.c | 42 +
nt release branches are explicitly unaffected.
My own vote on this issue is "yes" (assuming I still have a right for a
vote, I really don't know).
I'm not on the committee, but I'd vote "yes"
/Tomas
___
ffmpeg-de
codec_tag?
Future work:
* add support for CODEC2_MODE_WB once it's stable
* FATE tests: bitexact remuxing in all modes, encoding all modes,
decoding all modes
For the FATE bit I'm thinking something like the test script attached.
I attached a 12 second sample too, a whopping 5 k
From 630e64fbf080dacfd19b0f62ed874014bd6d3ef2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 8 Aug 2017 15:27:27 +0200
Subject: [PATCH 1/3] Add libcodec2 en/decoder
---
Changelog| 1 +
configure| 5 ++
doc/general.texi
From e4e400fd17e7f248a61ef74681f55eed8b18be7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 8 Aug 2017 15:28:06 +0200
Subject: [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files
---
Changelog| 1 +
doc/general.texi | 4
From 8bd1d9981484c9b4964f3fdfd542951a02f5a01d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 3 Aug 2017 17:33:04 +0200
Subject: [PATCH 3/3] Don't complain about codec2's 700 bit/s modes in ffmpeg.c
---
fftools/ffmpeg.c | 3 ++-
1 file changed, 2 insert
const int plane = td->plane;
> const int n = td->n;
> -int start = (n * jobnr ) / nb_jobs;
> +int start = (n * jobnr) / nb_jobs;
Don't mix cosmetic and functional changes
Rest of the patch looks OK enough to m
}
> +}
> +
> +end:
> +av_free(path);
> +av_free(tmp_str);
> +return updated;
> +
> +}
I don't really like lavf doing URL parsing/manipulation like this when
there's (supposedly) mature libraries to do it. Especially after this
year's B
mån 2017-12-25 klockan 20:07 +0100 skrev Michael Niedermayer:
> On Sat, Dec 23, 2017 at 11:15:56PM +0100, Tomas Härdin wrote:
> >
> > ffmpeg.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> > 68440596af0b5c26d6123f5ee964414ce9e2f48f 0003-Don-t-compl
if (run_len < 0xE0)
> +run_len++;
> +else
> +run_len = 1 << (run_len - 0xE0 + 7);
This overflows on 32-bit if run_len >= 0xF8
(holy crap, C's lack of static checks is annoying)
> +
> +i += run
> +{ AV_CODEC_ID_JPEG2000, INDEX_JPEG2000 },
> +{ AV_CODEC_ID_H264, INDEX_H264 },
> +{ AV_CODEC_ID_NONE }
> +};
This is tangentally relevant perhaps, but that INDEX_ enum should
really be type. Something like ULIndex and a comment with reference to
relevant spec section would be nice
/
suite... So unless somebody can
provide an opAtom AVC intra file which is only a few frames long, I
see no good way to fate test this. Do you have an idea how to proceed?
Try having the user that reported the bug generate a smaller + lower res
sample?
/Tomas
spect_ratio = (AVRational){ 16, 9 };
else
sc->aspect_ratio = (AVRational){ 4, 3 };
Might want to add some { } around those two cases while you're at it
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
g_len))
> +break;
> +
Looks OK
I wonder if other codecs need this kind of special treatment. The
version byte isn't supposed to matter.. If any more pop up then we
could generalize this - for now this is good enough I suppose
/Tomas
___
gotten too much to effectively fix them. Hence this mail
I can stay on as lxfdec maintainer, since I'm subscribed to the "lxf"
tag on trac. I will likely unsubscribe from this list, posting only if
there's an LXF ticket to deal with.
/Tomas
signature.asc
Description: This is a
(t = av_dict_get(s->metadata, "creation_time", NULL, 0))
> -timestamp = ff_iso8601_to_unix_time(t->value);
> -if (timestamp)
> +if (ff_parse_creation_time_metadata(s, ×tamp, 1) > 0)
> mxf->timestamp = mxf_parse_timestamp(timestamp);
hing
without it is fine if it fixes the issue, even preferable (since it'd
be simpler).
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
rack number of the video frames
> (0x15010500 == 352388352).
Hrm, this sounds suspicious. But I think happens for some other files
too, and I guess playing something is better than nothing.. Perhaps we
can have it be a bit more stringent with when it applies this hack?
Like if there's o
On Thu, 2016-03-10 at 15:08 +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> While debugging ticket #5312, I realized that I included the
> track number in the Canopus essence element.
OK
/Tomas
signature.asc
Description: This is a digitally signed
n a while since I looked at AS-10 but I recall it simply being
a narrower version of OP1a (but not as narrow as OPAtom). So just mux
something with the codecs AS-10 expects and run it through an AS-10
analyzer to see if mxfenc spits out the right thing.
/Tomas
_
if (!source_track || !component || !source_package)
> continue;
>
> if (!(source_track->sequence = mxf_resolve_strong_ref(mxf,
> &source_track->sequence_ref, Sequence))) {
Looks OK. Crashes are important
whether extradata should be the entire .c2
header or just the mode byte. It really only matters if we go with RIFF
or ISOM mappings (.wav .avi .mov and friends), which I decided to leave
out for now.
/TomasFrom 569a252536ea224bcd44f55f0f5102ce1aa4ec77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=2
On Thu, 2017-08-03 at 01:07 +0200, Carl Eugen Hoyos wrote:
> 2017-08-03 0:40 GMT+02:00 Tomas Härdin :
>
> >
> > Decoding a .c2 file is straightforward however, thanks to the
> > header:
> >
> > ffmpeg -i report2074.c2 out.wav
> The probe score is too
On Thu, 2017-08-03 at 13:00 +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXV, Tomas Härdin a écrit :
> > With both the raw demuxer and the encoder you need to specify the
> > desired mode, like this:
> The encoder could default to one the two.
Default on-th
On Thu, 2017-08-03 at 22:24 +0200, Reimar Döffinger wrote:
> On Thu, Aug 03, 2017 at 12:40:04AM +0200, Tomas Härdin wrote:
>
> >
> > +//statically assert the size of avpriv_codec2_header
> > +//putting it here because all codec2 things depend on
> >
On Fri, 2017-08-04 at 19:20 +0200, Tomas Härdin wrote:
> TODO:
>
> * have -mode be an integer and use the CONST system Nicolas mentioned
> * option for demuxing multiple frames at a time
> * sort the extradata aliasing thing
> * address API issues in libcodec2, possibly modify
Use 255ULL and 64ULL maybe? It's almost conceivable that you could have
a file constructed to be (1<<31 - 255)x1 that passes the max_pixels check
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2017-08-15 21:15, Moritz Barsnick wrote:
On Tue, Aug 08, 2017 at 23:49:45 +0200, Tomas Härdin wrote:
Feel free to comment
Don't forget to mention #1959 in the commit message.
Huh, I didn't know there was a ticket for it. That audiobook guy popped
up on [Freetel-codec2] too, an
On 2017-08-16 14:35, Michael Niedermayer wrote:
On Wed, Aug 16, 2017 at 09:48:43AM +0200, Tomas Härdin wrote:
On 2017-08-16 05:04, Michael Niedermayer wrote:
Fixes: OOM
Fixes: 2710/clusterfuzz-testcase-minimized-4750001420894208
Found-by: continuous fuzzing process
https://github.com/google
rge\n");
+return AVERROR_INVALIDDATA;
+}
+
Looks like a decent solution
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
format/mov.c
+++ b/libavformat/mov.c
@@ -5572,7 +5572,7 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
if (atom.size < 0)
atom.size = INT64_MAX;
-while (total_size + 8 <= atom.size && !avio_feof(pb)) {
+while (tot
* mean) / (length - 1);
+}
Isn't this method much more numerically unstable compared to the naïve
method? Might not matter too much when the source data is 16-bit, but
throwing it out there anyway
DSP methods for computing mean and variance could be a good project for
someone wanting to lea
ng_win;
-if (!ff_psy_vorbis_block_frame(&venc->vpctx, scratch, ch,
- frame_size, block_size))
-curr_win = 0;
+if (!ff_psy_vorbis_block_frame(&venc->vpctx, scratch, ch,
+ long_win, short_win))
+next_win = 0;
+}
}
Same here
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
264 }, /* H.264/MPEG-4 AVC Intra */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
> }, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x0
_dominance can have 256 different values, do we have samples
> for all ? do they even exist ?
As far as I recall there are only two (1, 2) and possibly "unknown" (0).
/Tomas
signature.asc
Description: This is a digitally signed message part
TFF) makes more sense. For
any illegal value the demuxer should probably complain so the user can
complain at whoever wrote the bad muxer they're using.
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, 2014-09-16 at 09:03 +0100, tim nicholson wrote:
> On 10/09/14 21:45, Tomas Härdin wrote:
> > On Tue, 2014-08-19 at 22:30 +0200, Michael Niedermayer wrote:
> >> On Tue, Aug 19, 2014 at 01:30:24AM +0200, Carl Eugen Hoyos wrote:
> >>> Hi!
> >>>
> +return 0;
> + }
> +}
> +
> +return !!sc->codec_ul;
> +}
Seems awfully specific code to have in a muxer. Can this be reused
elsewhere? Don't let that stop you though.
Overall I'm OK with this patch being GPL. It's not optimal, but I
compile with libx264 for my own purposes anyway and thus have GPL
enabled. If someone wants it LGPL bad enough then they're free to
rewrite this of course. Perhaps as a part of making the functionality of
the above function reusable elsewhere? (I think MOV might support
AVC-Intra)
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
av_rescale()
> +
> +if (av_timecode_init(&tc, mxf_tc->rate, flags,
> start_position + mxf_tc->start_frame, mxf->fc) == 0) {
> +mxf_add_timecode_metadata(&st->metadata, "timecode",
> &tc);
> +return 0;
> +
ws).
> I have no idea against what other players this should be tested.
Do we have a sample + FATE case for this?
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffm
f4c4ec 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
Looks OK..
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
oradically.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sat, 2014-10-18 at 15:26 +0200, Reimar Döffinger wrote:
> Signed-off-by: Reimar Döffinger
> ---
> libavformat/mxfdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 9306cc6..f916d01 100644
> --- a/libavformat/mxfde
resolving stuff
is getting a bit hairy. Could use some refactoring in the future
perhaps?
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2014-10-26 00:33, Mark Reid wrote:
On Sat, Oct 25, 2014 at 1:42 PM, Tomas Härdin
wrote:
On Fri, 2014-10-24 at 17:31 -0700, Mark Reid wrote:
> ---
> libavformat/mxf.h | 1 +
> libavformat/mxfdec.c | 31 +--
> tests/ref/lavf/mxf | 6 +++
if ((1ULL<<61) % last_pos_index++ == 0)
This looks extremely dubious, but I see 1c010fd03 was a stop gap to fix
a an issue discovered by fuzzing. Why didn't anyone poke my on IRC about
it?
I have furniture to move today, after that I might ha
> +if (desc)
> +sc->component_depth = desc->comp[0].depth_minus1 + 1;
Seems unrelated?
In general I didn't check how similar this patch is to the GPL'd
version, so I'm going to trust that this doesn't share anythi
Ticket3278 (see
patch 2/5).
/TomasFrom 55117f8fd8d209830db8932a1c59f0b309e3ac44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:33:04 +0100
Subject: [PATCH 1/5] mxfdec: Break out parts of mxf_read_header() into
separate functions
---
libavformat/mxfdec.c
This fixes the actual issue (Ticket 3278). See also deadlock3.mxf on
FTP.
/TomasFrom 783aaa31271266587fad8f60a588ed755744a765 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:38:18 +0100
Subject: [PATCH 2/5] mxfdec: Parse PreviousPartition in
From 662adc4db39b1925c90fc78fb83d58c0e3e6dfd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 13:33:47 +0100
Subject: [PATCH 3/5] Revert "avformat/mxfdec: detect loops during header
parsing"
This reverts commit 1c010fd035c1a14dc73827b84f21f5
From 86ce75449ef2febb584d7f337a4035ef2cee2b1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 14:27:06 +0100
Subject: [PATCH 4/5] mxfdec: Merge last_partition and footer_partition
FooterPartition offset specified in RIP takes precedence over any value
From d1827479c17186db7bda472e92b272bbdf4ddcfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 28 Oct 2014 14:36:27 +0100
Subject: [PATCH 5/5] mxfdec: Tighten RIP length bounds in
mxf_read_random_index_pack()
---
libavformat/mxfdec.c | 27 +--
1
On 2014-10-28 15:31, tomas.har...@codemill.se wrote:
This fixes the actual issue (Ticket 3278). See also deadlock3.mxf on
FTP.
/Tomas
Oops, wrong subject - I should probably set up git-send-email..
Reattached patch just to be sure.
/TomasFrom 783aaa31271266587fad8f60a588ed755744a765 Mon
mån 2024-03-25 klockan 21:04 +0100 skrev Michael Niedermayer:
> On Mon, Mar 25, 2024 at 08:13:13PM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 21, 2024 at 04:07:14PM +0100, Tomas Härdin wrote:
> > > ons 2024-03-20 klockan 21:35 +0100 skrev Tomas Härdin:
> > > >
ation would discovered these of course, but we have nowhere near
enough labour power to do that across the entire codebase. So limiting
channels is a practical way to ensure channels*bytes_per_sample and so
on can't overflow.
A second question is: which users would need two billion channels
tor 2024-03-28 klockan 03:48 +0100 skrev Michael Niedermayer:
> On Wed, Mar 27, 2024 at 11:13:48AM +0100, Tomas Härdin wrote:
> > mån 2024-03-25 klockan 21:04 +0100 skrev Michael Niedermayer:
> > > On Mon, Mar 25, 2024 at 08:13:13PM +0100, Michael Niedermayer
> > > wr
___
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".
I am once again asking more people on this list to peruse
https://langsec.org/
/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
Oops, forgot to actually attach the patch
From fccc13f728c50a676d20f3ca5b822fa1da60b259 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024 20:30:37 +0100
Subject: [PATCH 1/3] lavf/subtitles: Do not eat \n\n
---
libavformat/subtitles.c | 15 ++-
1
Here as well
From 6d0684ca6fe02d80fc07a622fb85445a6917c29f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024 22:15:18 +0100
Subject: [PATCH 2/3] lavf/srtdec: Permit streaming input
This is largely a rewrite.
Read packets in srt_read_packet() rather than
bably because these kinds of line
ending is explicitly banned by the WebVTT spec. That is, CR CR LF is to
be treated as two line endings, no ifs or buts about it.
/Tomas
From 784672af12da1d5fefeefad83cffa4b31f8b50fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024
perfectly good generic index and seeking
functionality. My recent experiment with srt shows it's possible to
read packets in read_packet() like every other demuxer..
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
Here's an alternative solution which maintains support for \r\r\n by
peeking two bytes into the future.
/Tomas
From ed6f0b2e6c8e52574fcfdac73fcfca560434c079 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024 23:30:06 +0100
Subject: [PATCH] lavf/subtitles
fre 2024-03-29 klockan 09:28 -0500 skrev Marth64:
> Tomas Härdin:
> > Can we please get away from this way of reading subtitles? Every
> > other
> > type of media (audio, video) are capable of being streamed, but not
> > subtitles, precisely because all of
lör 2024-03-30 klockan 00:35 +0100 skrev Michael Niedermayer:
> On Thu, Mar 28, 2024 at 11:57:57PM +0100, Tomas Härdin wrote:
> > Here as well
>
> > libavformat/srtdec.c | 211 --
> > -
> > tests/ref/fate/sub-srt-
compromising in this specific case. But I'd rather we didn't, and stuck
to \r, \n and \r\n. What I really don't want is runs of \r being eaten
without being "terminated" by a \n, because this messes up Mac support.
/Tomas
From 2ec68c51e4599b8493a2e103793f571451d872d3 Mon Sep
om different SRT files. There's little reason to
support such deliberately broken files, at least having a bunch of
sorting logic just for it. There's no reason we couldn't output packets
in stored order.
The rest of the subtitle test cases pass.
/Tomas
[1] https://forum.doom9.o
+1919,9 @@ static inline void tile_codeblocks(const
> Jpeg2000DecoderContext *s, Jpeg2000Tile
> band->coord[1][0] == band->coord[1][1])
> continue;
>
> + if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) &a
INT64_MAX -
> offset_temp
> + )
Nit: looks a bit weird to have the ) there rather than at the end of
the previous line
/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".
lör 2024-03-30 klockan 12:44 +0100 skrev Nicolas George:
> Tomas Härdin (12024-03-30):
> > More interesting is fate-sub-srt-badsyntax. Despite the name it
> > doesn't
> > really have bad syntax, but its cues are in a random order. I guess
> > it
> > exists to
lör 2024-03-30 klockan 15:49 +0100 skrev Nicolas George:
> Tomas Härdin (12024-03-30):
> > Players can implement sorting if they wish.
>
> API break.
lavf's API provides no guarantees regarding presentation order
>
> > Finally I will note that sorting does
API users don't care
but CLI users do then we could put it in ffmpeg.c.
If we are to maintain compatibility with an ill-defined set of API
users rather than say specific packages (vlc, mpv, melt etc) then the
only sensible solution is to put the sorting logic further up in lavf,
say demu
d of the week that
still provides sorted subs when possible, except when the input is a
stream (which doesn't work now anyways).
This kind of nonsense is why being strict with input is a good idea.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-deve
fixes an issues found by some researcher, always
> credit the
> +researcher in the commit message for finding/reporting the issue.
Sounds reasonable.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
data is cached in ffmpeg memory space up to the memory capacity
> specified by this option.
> Memory Size (M,G, or Specify % of Available capacity)
> eg. If the available capacity is 10GB and specify 80%, up to 8GB will
> be used.
This is the job of y
5:
> > - segment->edit_unit_byte_count = avio_rb32(pb);
>
> Why not simply make segment->edit_unit_byte_count unsigned?
This might run afoul with various calcultions. Speaking of,
mxf_edit_unit_absolute_offset() does not check for multiplication
overflows..
/Tomas
__
3d, but the
files it supposedly fixes aren't in FATE. We shouldn't encourage broken
muxers.
/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".
e restrictive with what kind of input we
allow, especially for formats mainly used by professionals such as MXF.
Every feature carries with it a maintenance burden.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
dern development
> workflow such
> as the GitHub PR or gitlab MR would go very long way in helping
> onboarding
> new developers.
Considering which company owns GitHub and which company was the target
of Kieran's criticism, this seems ill
mån 2024-04-08 klockan 16:40 +0200 skrev Nicolas George:
> Tomas Härdin (12024-04-08):
> > We could always start licensing the project under a less permissive
> > license like the GPL or the AGPL and then charge for exceptions.
> > This
> > tactic goes by the name o
mån 2024-04-08 klockan 21:46 +0200 skrev Marton Balint:
>
>
> On Mon, 8 Apr 2024, Tomas Härdin wrote:
>
> > tor 2024-04-04 klockan 00:51 +0200 skrev Michael Niedermayer:
> > > Fixes: Assertion b >=0 failed at libavutil/mathematics.c:62
> > > Fixe
401 - 500 of 1495 matches
Mail list logo
