tis 2024-04-09 klockan 22:58 +0200 skrev Marton Balint:
>
>
> On Tue, 9 Apr 2024, Tomas Härdin wrote:
>
> > mån 2024-04-08 klockan 21:46 +0200 skrev Marton Balint:
> > >
> > >
> > > On Mon, 8 Apr 2024, Tomas Härdin wrote:
> > >
&g
tis 2024-04-09 klockan 15:57 -0500 skrev Romain Beauxis:
> [Apologies for continuing the conversation, Rémi]
>
> Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit :
>
> > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > > On Wed, Apr 3, 2024, 11:39 Kie
en the maintenance burden though.
I have an old phone (Samsung Galaxy S5) running the most recent
LineageOS possible to install on it (16.0), and that uses Android 9. So
for me bumping to version 5 sounds fine.
Do you have any statistics on Android v
Hi
Patch attached allows preserving PIDs when remuxing MPEG-TS. James
suggested we could generalize this to allow copying from specific
streams, but I think if we want to handle a more general case then it
would be better to handle streamid via metadata.
Passes FATE.
/Tomas
From
tor 2024-04-11 klockan 17:41 +0200 skrev Tomas Härdin:
> Hi
>
> Patch attached allows preserving PIDs when remuxing MPEG-TS. James
> suggested we could generalize this to allow copying from specific
> streams, but I think if we want to handle a more general case then it
>
fre 2024-04-12 klockan 00:32 +0200 skrev Michael Niedermayer:
> On Thu, Apr 11, 2024 at 05:41:48PM +0200, Tomas Härdin wrote:
> > Hi
> >
> > Patch attached allows preserving PIDs when remuxing MPEG-TS. James
> > suggested we could generalize this to allow copying from
space like FFMPEG: or AVSTREAM: or
something, then delete all of them using AV_DICT_IGNORE_SUFFIX near the
end of of_open() since they're for internal ffmpeg use.
The FATE change is just because av_dict() changes the order of things
when elements are delete
-
> > Michael GnuPG fingerprint:
> > 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Nations do behave wisely once they have exhausted all other
> > alternatives.
> > -- Abba Eban
> > ___
> > ffmpeg
tor 2024-04-11 klockan 21:57 +0800 skrev Zhao Zhili:
>
>
> > On Apr 11, 2024, at 21:17, Tomas Härdin wrote:
> >
> > tor 2024-04-11 klockan 20:16 +0800 skrev Zhao Zhili:
> > > We don’t have a minimum required version of Android in FFmpeg.
> > > lib
fre 2024-04-12 klockan 19:23 +0800 skrev Zhao Zhili:
>
>
> > On Apr 12, 2024, at 18:50, Tomas Härdin wrote:
> >
> > tor 2024-04-11 klockan 21:57 +0800 skrev Zhao Zhili:
> > >
> > >
> > > > On Apr 11, 2024, at 21:17, Tomas Härdin wrot
lör 2024-04-13 klockan 01:25 +0200 skrev Michael Niedermayer:
> On Fri, Apr 12, 2024 at 11:40:47AM +0200, Tomas Härdin wrote:
> > This idea could be extended to other fields not presently
> > considered to
> > be metadata, that would be handy to treat as such.
> >
>
sön 2024-04-14 klockan 22:55 +0200 skrev Marton Balint:
>
>
> On Wed, 10 Apr 2024, Tomas Härdin wrote:
>
> > tis 2024-04-09 klockan 22:58 +0200 skrev Marton Balint:
> > >
> > >
> > > On Tue, 9 Apr 2024, Tomas Härdin wrote:
> > >
> >
mån 2024-04-15 klockan 21:33 -0300 skrev James Almer:
> On 4/15/2024 9:30 PM, Michael Niedermayer wrote:
> > On Mon, Apr 15, 2024 at 10:35:44AM +0200, Tomas Härdin wrote:
> > > lör 2024-04-13 klockan 01:25 +0200 skrev Michael Niedermayer:
> > > > On Fri, Apr 12, 2
tis 2024-04-16 klockan 09:52 -0300 skrev James Almer:
> On Tue, Apr 16, 2024 at 9:38 AM Anton Khirnov
> wrote:
>
> > Quoting Tomas Härdin (2024-04-12 11:40:47)
> > > This idea could be extended to other fields not presently
> > > considered to
> > > be
to improve subtitle support. Streaming
support could also be improved, and would be very much with the times.
The fact that we can't pass MPEG-TS through unmolested isn't great.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
ms wrong, when J2K is far from the
only codec that can be used like this in MXF..
/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".
tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer:
> On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote:
> > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer:
> >
> > > * ffchat
> > > (expand into realtime chat / zoom) this wo
lör 2024-04-27 klockan 12:53 +0200 skrev Michael Niedermayer:
> On Thu, Apr 25, 2024 at 12:26:00PM +0200, Tomas Härdin wrote:
> > tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer:
> > > On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote:
> > > >
les would be a pain in more places than here.
MXF is sometimes used to archive scanned copies of film, but even raw
16k rgb48 essence @ 120 Hz takes over 1000 days of footage to hit the
2^63 limit..
I took a look at the body_offset logic and it looks like it should be
correct when we force them to
hout tests covering the workflows we want to support, we have no
confidence in refactoriing. This leads to cargo culting. And to be
sure, every workflow we support means a non-trivial amount of work,
especially when it comes to MXF.
/Tomas
___
ffmpe
tor 2024-05-02 klockan 23:01 +0200 skrev Marton Balint:
>
>
> On Mon, 29 Apr 2024, Tomas Härdin wrote:
>
> > mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint:
> > > Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting
> > > negative
>
lör 2024-05-04 klockan 03:49 +0200 skrev Marton Balint:
>
>
> On Fri, 3 May 2024, Tomas Härdin wrote:
>
> > tor 2024-05-02 klockan 23:01 +0200 skrev Marton Balint:
> > >
> > >
> > > On Mon, 29 Apr 2024, Tomas Härdin wrote:
> > >
> >
..
/Tomas
From d1a7f33a1c394142b6dc14d4e8392ad786f8ba52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 8 May 2024 14:17:18 +0200
Subject: [PATCH 1/3] lavc/speedhqdec: Add AV_CODEC_CAP_FRAME_THREADS
---
libavcodec/speedhqdec.c | 5 +++--
1 file changed, 3 insertions(+), 2
Inspired by qoidec
/Tomas
From ed49d383d40a9a4fad04b76bc7d86107c6350d9a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 8 May 2024 14:17:57 +0200
Subject: [PATCH 2/3] lavc/speedhqdec: Obey AVDISCARD_ALL
---
libavcodec/speedhqdec.c | 3 +++
1 file changed, 3 insertions
From 894a0ff35e892f84b079bef62efa56250bb33e41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 8 May 2024 14:18:10 +0200
Subject: [PATCH 3/3] lavc/speedhqdec: Set AV_PICTURE_TYPE_I
---
libavcodec/speedhqdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
ons 2024-05-08 klockan 09:46 -0300 skrev James Almer:
> On 5/8/2024 9:42 AM, Tomas Härdin wrote:
> > Hi
> >
> > On a 36-core machine (Intel(R) Xeon(R) Platinum 8124M CPU @
> > 3.00GHz)
> > with a 7 minute 125 Mbit/s 1080p sample and -thread_type frame -
&
ons 2024-05-08 klockan 17:06 -0300 skrev James Almer:
> On 5/8/2024 5:01 PM, Marton Balint wrote:
> >
> >
> > On Wed, 8 May 2024, Tomas Härdin wrote:
> >
> > >
> > >
> >
> > What suprises me is that pict_type and the keyf
fre 2024-05-10 klockan 14:48 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > ons 2024-05-08 klockan 17:06 -0300 skrev James Almer:
> > > On 5/8/2024 5:01 PM, Marton Balint wrote:
> > > >
> > > >
>
rmountable impedance mismatches.
This said, I'm not opposed to switching workflow to say gitlab, though
personally I wish gitlab stopped requiring jabbascript. Gitea is better
in this regard.
Finally, email has staying power.
/Tomas
___
ffmpeg-devel
sön 2024-05-12 klockan 01:07 +0200 skrev Tomas Härdin:
> fre 2024-05-10 klockan 14:48 +0200 skrev Andreas Rheinhardt:
> > Tomas Härdin:
> > > ons 2024-05-08 klockan 17:06 -0300 skrev James Almer:
> > > > On 5/8/2024 5:01 PM, Marton Balint wrote:
> > > >
is set.
> +
> + /// The following two fields have the same semantics as the
> DecodeContext field
> + int intra_only_flag;
> + enum AVPictureType initial_pict_type;
Same here
/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".
ytestream2_get_be16(&s->g);
> break;
> - case 3:
> - bytestream2_get_be32(&s->g);
> - break;
Double-checked T.800 table A.34 and indeed ST == 3 is invalid (which is
also checked just above). So looks OK.
/Tomas
___
= 0; i < len; i++) \
> - buf[i] = ((rnd() % 65281) - 32641); \
> + buf[i] = ((rnd() % (MAX_VAL - MIN_VAL + 1)) + MIN_VAL);
This is why formal methods are a good thing
Looks OK of course
/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".
ytestream2_get_be16(&s->g);
> break;
> - case 3:
> - bytestream2_get_be32(&s->g);
> - break;
I will also point out get_tlm() doesn't actually do anything other than
advance the bytestream. We could just as well advance by Ltlm
/
mån 2024-05-13 klockan 10:51 +0200 skrev Tomas Härdin:
> fre 2024-05-10 klockan 16:07 +0200 skrev Michael Niedermayer:
> > Fixes: CID1460979 Logically dead code
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> >
ce
I don't have any interlaced samples at the moment, and speedhqenc can't
make any. I also noticed speedhqenc produces broken output when width %
16 == 8. Will file a ticket on that tomorrow.
/Tomas
From 29a0380a1537ba205ec91399512f676301d5e930 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Toma
From 17aceef1c1a1bb25d651610cd52bc94dbdf20e0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 13 May 2024 17:01:28 +0200
Subject: [PATCH 2/2] lavc/speedhqdec: Reindent
---
libavcodec/speedhqdec.c | 152
1 file changed, 76
mån 2024-05-13 klockan 10:54 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tor 2024-05-09 klockan 04:04 +0200 skrev Andreas Rheinhardt:
> > > This commit is the analog of
> > > 3f11eac75741888c7b2b6f93c458766f2613bab5
> > > for decoding: It sets
mån 2024-05-13 klockan 17:55 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > mån 2024-05-13 klockan 10:54 +0200 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > tor 2024-05-09 klockan 04:04 +0200 skrev Andreas Rheinhardt:
> >
.
For FFmpeg the Eva and WP plugins for Frama-C would be of relevance.
I've been toying with the idea on and off
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
ients anywhere. Then each group of 16
lines could be made into its own job since we know the exact start and
end bit for all of them. This would degrade serial performance and
performance with 4/8 threads but probably a win for 4k and up with
large numbers of threads
/
Stop gap solution. I don't know enough about mpegvideo_enc to provide a
proper implementation, nor do I have access to NDI hardware to feel
comfortable with it. This patch at least prevents us from outputting
files that we know are broken
/Tomas
From 9dd76f9ec153c3d10374a2a4a74348dc39458c0
tis 2024-05-14 klockan 14:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 14 mai 2024 10:37:20 GMT+03:00, "Tomas Härdin" a
> écrit :
> > Formal methods would be better than the heuristics coverity uses.
>
> That sounds like wishful thinking, or at least a distan
nd 100% of statements in those functions are
covered, with zero alarms.
If the project isn't interested in this then I'll probably continue
fiddling with it on my own mostly as exercise. But I suspect it will
bear even more fruit in time.
/Tomas
[1] https://frama-c.com/
[2] http
fre 2018-03-09 klockan 22:34 +0100 skrev Marton Balint:
> Would this be useful for anybody?
I've never even run into this before, so I can't really say. Maybe?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
the libraries don't depend on some run-time environment and
> provide a
> C-compatible ABI, mixing languages (like C, Delphi, Rust) is not a
> problem.
The problem is that C++ people tend to do exactly this. Some libraries
like gmp/gmpxx do the decent thing and export a C API that is
Hi
It's come up a couple of times that IRC nicknames would be useful. I at
least tend to answer IRC much more quickly than email. Something like
patch attached maybe?
/TomasFrom 03225dda47c73c3323c3276353d0ac896123cd3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: S
lör 2018-04-07 klockan 10:00 -0300 skrev James Almer:
> On 4/7/2018 9:08 AM, Tomas Härdin wrote:
> > Hi
> >
> > It's come up a couple of times that IRC nicknames would be useful. I at
> > least tend to answer IRC much more quickly than email. Somethi
sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> >
> > Good suggestion
> >
> > /Tomas
>
> Patch LGTM with the suggestion from James. Although I'm not on IRC
> very often lately you can add mine
tor 2018-04-12 klockan 16:47 +0200 skrev wm4:
> On Thu, 12 Apr 2018 16:43:48 +0200
> Tomas Härdin wrote:
>
> > sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> > > On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> > > >
> > &
AVERROR(EINVAL);
> }
> +} else if (track->par->codec_id == AV_CODEC_ID_AV1) {
> +/* spec is not finished, so forbid for now */
> +av_log(s, AV_LOG_ERROR, "AV1 muxing is currently not
> supported.\n");
>
s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
> +return AVERROR_INVALIDDATA;
Looks like an extra check, not just moving existing checks as the
commit message implies
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
t; +//Empty frame, do not waste time
> +if (!num_strips)
> +return buf_size;
Won't this break in case of palette changes?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
tis 2018-04-17 klockan 14:24 +0200 skrev Michael Niedermayer:
> On Tue, Apr 17, 2018 at 10:32:16AM +0200, Tomas Härdin wrote:
> > tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> > > Speeds up decoding from 8 to 3 seconds for 6302/clusterfuzz-
> &
tor 2018-04-12 klockan 16:54 +0200 skrev Tomas Härdin:
> tor 2018-04-12 klockan 16:47 +0200 skrev wm4:
> > On Thu, 12 Apr 2018 16:43:48 +0200
> > Tomas Härdin wrote:
> >
> > > sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> > > > On Sun, A
ons 2018-04-25 klockan 09:55 +0100 skrev Josh de Kock:
> On 2018/04/25 9:35, Paul B Mahol wrote:
> > On 4/25/18, Tomas Haerdin wrote:
> > > [...]
> > >
> > > I'll push this this some time later this week if I don't hear any
> > > objec
PR quality is an issue too, as others have noted.
GitLab might be nice however, but we'd need a way to import all trac
tickets, with ticket numbers and URLs intact. But I don't think we'd
gain much from that.
/Tomas
___
ffmpeg-deve
ng?
> > > >
> > > > https://trac.ffmpeg.org/
> > >
> > > To be fair, I'd prefer the github issue tracker over TRAC any
> > > day.
> > > Still has the other problems I mentioned.
> >
> > gitlab?
> >
>
> That would mostly get rid of the centralization argument. But I've
> heard bad things from someone who wanted to setup a private instance
> of
> it. Apparently it has a large number of dependencies, is extremely
> hard
> to deploy (unless you use their docker container), and it's SLOW.
>
> In fact even gitlab.com seems to have severe performance problems
> occasionally.
Another problem with gitlab is its inability to work without js. Things
like hamburger menus getting in the way, READMEs not displaying and so
on. Just look at https://gitlab.com/explore with js and third party
domains disabled
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
id to base
> a
> preferrance on.
>
> I favor a hard error as it is easier t debug in case it misbehaves.
> silently cliping (if its wrong) leads to more difficult to trace
> issues.
>
> But if people prefer i can change it to clip of course.
Be as strict as possible and ask for samples if someone has a file that
breaks these expectations
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ice. The rest looks OK, but I didn't read the relevant specs to be
100% sure
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
>
> > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > Hi,
> > >
> > > this is a better version of the patch.
> > > 10 bit and TFF
t = pos - start + klv_fill_size(pos);
Feels like such an elementary error. Probably OK, but it's been a while
since I read the specs
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
this style of computation. But not enough
to hold the patch up, which looks OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
matContext *s)
> mxf_write_local_tag(pb, 2, 0x3B05);
> avio_wb16(pb, 259); // v1.2
>
> +// Object Model Version
> +mxf_write_local_tag(pb, 4, 0x3B07);
> +avio_wb32(pb, 1);
>
Not sure what use this is, but looks OK at least. S377m doesn&#x
odec comes along that has larger or smaller macroblocks?
> int display_height;
> int f1, f2;
> @@ -1143,7 +1144,7 @@ static void mxf_write_cdci_common(AVFormatContext *s,
> AVStream *st, const UID ke
> mxf_write_generic_desc(s, st, key, desc_size);
>
>
ight)&1));
Negative values for DisplayF2Offset are not valid
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
; sc->h_chroma_sub_sample = 1 << pix_desc->log2_chroma_w;
> +sc->v_chroma_sub_sample = 1 << pix_desc->log2_chroma_h;
Looks OK. Had this confused for chrome siting for a while, but I see
that is actually handled correctly.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
epth - 4)) + 1;
> +}
This feels like something that should be part of pix_fmt stuff or
something. But maybe someone can refactor that later. Looks OK
otherwise
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
, sc->color_siting);
>
> +// Padding Bits
> +mxf_write_local_tag(pb, 2, 0x3307);
> +avio_wb16(pb, 0);
I'm pretty sure there's ways of muxing v210 in mxf, so it might be
better to say nothing here unless we're entirely sure. Probably
> klv_fill_size(mxf->edit_unit_byte_count);
>
> sc->signal_standard = 1;
> +sc->color_siting = 0;
> }
Can't find anything in my documents that says anything about this. I
don't remember what D-10 is actually specified in...
/
_write_local_tag(pb, 4, 0x3213);
> +avio_wb32(pb, 0);
> +
> +//Image End Offset
> +mxf_write_local_tag(pb, 4, 0x3214);
> +avio_wb32(pb, 0);
> +}
Looks OK, but of course I don't know what the spec says
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
b32(pb, sc->aspect_ratio.den);
>
> +//Transfer characteristic
> +if (transfer_ul[0]) {
> +mxf_write_local_tag(pb, 16, 0x3210);
> +avio_write(pb, transfer_ul, 16);
> +};
Looks OK, but I didn't check the ULs for correctness
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
avio_wb32(pb, st->codecpar->sample_rate);
> avio_wb32(pb, 1);
>
> +if (s->oformat == &ff_mxf_d10_muxer) {
> +mxf_write_local_tag(pb, 1, 0x3D04);
> +avio_w8(pb, 0);
> +}
Sizes and such look OK, but again I don't know what the D-1
pictures possible? I think there's a check somewhere, but I'm
not 100% sure
/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
ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
fre 2018-01-12 klockan 21:21 +0100 skrev Michael Niedermayer:
> On Sat, Dec 23, 2017 at 11:15:35PM +0100, Tomas Härdin wrote:
> >
>
> [...]
> > +static int codec2_read_header_common(AVFormatContext *s, AVStream *st)
> > +{
> > +int mode = avpriv_codec2
. Could we
document this in avformat.h? Something like:
// Score should be no more than AVPROBE_SCORE_MAX * identifying_bits/64
// if the number of identifying "magic" bits are less than 64
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@
->watermark_key);
Considering the memcpy() above, either this or the old code must be
wrong. My guess is the old code must have been wrong, since to fiddle
the same bits this AV_WL32() would need to set &s->slice_buf[1 -
s->gb.index / 8]...
/Tomas
___
fre 2018-01-19 klockan 19:19 +0100 skrev Carl Eugen Hoyos:
> 2018-01-19 16:54 GMT+01:00 Tomas Härdin :
> > On 2018-01-18 23:34, Carl Eugen Hoyos wrote:
> > >
> > > Hi!
> > >
> > > Attached patch fixes a warning, I suspect it makes the code more
>
Ping? I'd maintain this of course. Plus I'd like to add some tests, but
I need to know if this looks OK to everyone first
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2018-02-09 11:29, Carl Eugen Hoyos wrote:
2018-01-15 22:36 GMT+01:00 Tomas Härdin :
+if (p->buf[4] > EXPECTED_CODEC2_MINOR_VERSION) score -=
AVPROBE_SCORE_MAX/5;
+if (p->buf[5] > AVPRIV_CODEC2_MODE_MAX)score -=
AVPROBE_SCORE_MAX/5;
+if (p-
fre 2018-02-09 klockan 11:29 +0100 skrev Carl Eugen Hoyos:
> 2018-01-15 22:36 GMT+01:00 Tomas Härdin :
>
> > > +if (p->buf[4] > EXPECTED_CODEC2_MINOR_VERSION) score -=
> > > AVPROBE_SCORE_MAX/5;
> > > +if (p->buf[5] > AVPRIV_CODEC2_MODE_M
I believe setting time_base to it
and just having PTS increase monotonically from zero is enough (ptr =
0, pts = 1, pts = 2 ...). There may also be some API for this, or lavf
may come up with some PTSes for you if you say AV_NOPTS_VALUE
/Tomas
signature.asc
Des
Might want to separate this into a check for block_align>0, then
FFMAX(readsize, block_align) so we always get something. That would
take care of the < 100 Hz issue
>
> -ret= av_get_packet(s->pb, pkt, size);
> +ret = av_get_packet(s->pb, pkt, readsize);
Keeping the name as "size" removes the need for this hunk :)
/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
tis 2018-02-13 klockan 19:02 +0100 skrev Michael Niedermayer:
> On Fri, Jan 12, 2018 at 11:32:30AM +0100, Tomas Härdin wrote:
> > ping?
>
> breaks the recently (after teh patchset) added fate-codec_desc
Hrm, a good excuse to set up and dig into how FATE works. I want to add
some
tis 2018-02-13 klockan 11:48 +0100 skrev Tomas Härdin:
> fre 2018-02-09 klockan 11:29 +0100 skrev Carl Eugen Hoyos:
> > 2018-01-15 22:36 GMT+01:00 Tomas Härdin :
> >
> > > > +if (p->buf[4] > EXPECTED_CODEC2_MINOR_VERSION) score -=
> > > > A
be
different there depending on how things are packaged/linked. The LGPL
permits distributing proprietary object files such that a functioning
library may be linked together. See
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic
/Tomas
___
On 2018-02-14 14:48, Ricardo Constantino wrote:
On 14 February 2018 at 12:56, Tomas Härdin wrote:
On 2018-02-14 13:50, Kyle Schwarz wrote:
On Wed, Feb 14, 2018 at 7:45 AM, Hendrik Leppkes
wrote:
On Wed, Feb 14, 2018 at 1:32 PM, Kyle Schwarz wrote:
On Wed, Feb 14, 2018 at 7:20 AM, Carl
On 2018-02-14 15:16, Nicolas George wrote:
Tomas Härdin (2018-02-14):
Oh yeah, that puts a damper on things. The only way around that is dlopen()
or RPC, neither of which is going to make it into FFmpeg
At some point, vendors will need to realize we chose a copyleft license
to forthe them to
>= 0 which makes
size >= 1. I suggest putting it before the 1 << ff_log2.
-ret= av_get_packet(s->pb, pkt, size);
+ret = av_get_packet(s->pb, pkt, size);
Doesn't looks like it belongs, but it makes all the assignments align so
whatever
/Tomas
__
On 2018-02-15 10:17, Philipp M. Scholl wrote:
On Wed, Feb 14, 2018 at 03:41:18PM +0100, Tomas Härdin wrote:
[..snip..]
FFMAX(codec->sample_rate/25, 1) would be nicer
agree.
+size = FFMIN(size, RAW_SAMPLES * codec->block_align);
+size = 1 << ff_log2(size);
-size= R
On 2018-02-16 14:04, Philipp M. Scholl wrote:
Version 3 of the PCM delay patch with further feedback included.
Still not sure about the ramifications of smaller blocksizes in fate. Hence the
tests are also changed.
Code looks good. Can't say anything about the tests however
/
|| !strncmp(str_val, "FlixEngine", 10))) {
Nit: please align the inner str(n)cmp:s
FlixEngine is the VP6 thing, right? Awful, awful tool. Patch probably
OK though
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 9605df7c8402fb8d5fdbb55ae05639338a1ae0a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 19 Feb 2018 18:42:25 +0100
Subject: [PATCH] Add -vf scale example for making pixels square
This is a common use case.
---
doc/filters.texi | 13 +
1 file changed
run-in) so this patch
should be correct. What's perhaps more suspect is the calculation
itself. It should *always* be possible to locate where Op1a essence
starts, by scanning to the first essence KLV. MXF is flexible enough
that having some sketchy calculation for where it
tis 2018-02-20 klockan 02:35 +0100 skrev Michael Niedermayer:
> On Mon, Feb 19, 2018 at 06:45:11PM +0100, Tomas Härdin wrote:
> >
> > filters.texi | 13 +
> > 1 file changed, 13 insertions(+)
> > af8d1d10b307cc4123fda3f8a0d5cd3c9e86b7d7 0001-Add-vf-sc
ons 2018-02-21 klockan 23:06 +0100 skrev Marton Balint:
> On Wed, 21 Feb 2018, Tomas Härdin wrote:
>
> > lör 2018-02-17 klockan 22:45 +0100 skrev Marton Balint:
> > > The reference point for a KAG is the first byte of the key of a Partition
> > > Pack.
&
ons 2018-02-14 klockan 10:20 +0100 skrev Tomas Härdin:
> tis 2018-02-13 klockan 11:48 +0100 skrev Tomas Härdin:
> > fre 2018-02-09 klockan 11:29 +0100 skrev Carl Eugen Hoyos:
> > > 2018-01-15 22:36 GMT+01:00 Tomas Härdin :
> > >
> > > > > +if (p->b
g
> libraries.
This is not the list for questions like these - try libav-user. That
said, it's probably easiest to either use a script or execv() the
ffmpeg CLI
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2018-02-28 17:37, Philipp M. Scholl wrote:
Anything holding this patch back from being applied?
cheers,
-phil
On Fri, Feb 16, 2018 at 02:13:16PM +0100, Tomas Härdin wrote:
On 2018-02-16 14:04, Philipp M. Scholl wrote:
Version 3 of the PCM delay patch with further feedback included
501 - 600 of 1495 matches
Mail list logo
