Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Kieran Kunhya]

In this project we prefer internal decoders to external libs.

On Fri, 17 May 2024, 18:20 Cosmin Stejerean via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

>
>
> > On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> >
> > On 14/05/2024 17:09, Christian Bartnik wrote:
> >> From: Thomas Siedel 
> >> Add external decoder VVdeC for H266/VVC decoding.
> >> Register new decoder libvvdec.
> >> Add libvvdec to wrap the vvdec interface.
> >> Enable decoder by adding --enable-libvvdec in configure step.
> >> Co-authored-by: Christian Bartnik chris1031...@gmail.com
> >> Signed-off-by: Christian Bartnik 
> >> ---
> >>  configure  |   5 +
> >>  libavcodec/Makefile|   1 +
> >>  libavcodec/allcodecs.c |   1 +
> >>  libavcodec/libvvdec.c  | 617 +
> >>  4 files changed, 624 insertions(+)
> >>  create mode 100644 libavcodec/libvvdec.c
> >
> > I would prefer to have this one skipped, as initially suggested.
>
> Why? I tried to look back through the list but didn't see anything.
>
> - Cosmin
>
___
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Implement muxing SCTE-35 and EPG packets

[Kieran Kunhya]

On Mon, 8 Nov 2021 at 06:35, Maksym Veremeyenko  wrote:

> Hi,
>
> Attached patch implement muxing SCTE-35 and EPG packets into mpegts stream.
>

SCTE Markers need timestamping, no?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Implement muxing SCTE-35 and EPG packets

[Kieran Kunhya]

On Mon, 8 Nov 2021 at 15:17, Maksym Veremeyenko  wrote:

> On 08.11.2021 16:41, Kieran Kunhya wrote:
> > On Mon, 8 Nov 2021 at 06:35, Maksym Veremeyenko 
> wrote:
> >
> >> Hi,
> >>
> >> Attached patch implement muxing SCTE-35 and EPG packets into mpegts
> stream.
> >>
> >
> > SCTE Markers need timestamping, no?
> >
>
> SCTE markers has no timestamping, during reading at mpegts.c it
> timestamps recovered from PCR.
>

The positioning of the packet relative to the PCR matters. Also
splice_time() is relative to the new PCR and timestamps which I don't think
the mux here can guarantee?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/evc_ps: Check chroma_format_idc

[Kieran Kunhya]

On Fri, 13 Oct 2023 at 00:28, Michael Niedermayer 
wrote:

> Fixes: out of array access
> Fixes:
> 62678/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4858264984354816
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/evc_ps.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/evc_ps.c b/libavcodec/evc_ps.c
> index c11b92d1c5..19895d404d 100644
> --- a/libavcodec/evc_ps.c
> +++ b/libavcodec/evc_ps.c
> @@ -179,6 +179,10 @@ int ff_evc_parse_sps(GetBitContext *gb, EVCParamSets
> *ps)
>  // 2 - 4:2:2
>  // 3 - 4:4:4
>  sps->chroma_format_idc = get_ue_golomb_31(gb);
> +if (sps->chroma_format_idc > 3) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
>
>  sps->pic_width_in_luma_samples = get_ue_golomb_long(gb);
>  sps->pic_height_in_luma_samples = get_ue_golomb_long(gb);
> --
> 2.17.1
>

ok
___
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".

Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Kieran Kunhya]

On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

>
>
> > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> vittorio.giov...@gmail.com> wrote:
> >
> > TBF this is in part why i was suggesting a new library - I feel like sws
> is
> > affected by bad brading because of these caching issues and imprecise
> > conversion, and a new clean api in a new library would make a lot of
> sense
> > in my opinion.
>
> I think the branding issue would solve itself in short order if the actual
> implementation of swscale started to be good. My concern with adding a new
> library is that we'd end up in a situation where we have both swscale and a
> new library side by side for some extended period of time.
>
> By comparison adding cleaner APIs to swscale and then slowly strangling
> the old APIs (along the lines of Niklas' proposal) would allow for a more
> gradual transition that has a higher likelihood of success compared to a
> full rewrite IMO.
>

The issue is not the API, the issue is that swscale is astonishingly
complex and difficult to understand internally, there are lots of different
codepaths and randomly you'll end up with a buggy or slow one and have no
idea how to fix it.

It's probably easier to start from scratch than to try and understand and
then fix swscale (years of work).

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Kieran Kunhya]

On Sat, 14 Oct 2023, 18:00 Michael Niedermayer, 
wrote:

> On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote:
> > On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > >
> > >
> > > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> > > vittorio.giov...@gmail.com> wrote:
> > > >
> > > > TBF this is in part why i was suggesting a new library - I feel like
> sws
> > > is
> > > > affected by bad brading because of these caching issues and imprecise
> > > > conversion, and a new clean api in a new library would make a lot of
> > > sense
> > > > in my opinion.
> > >
> > > I think the branding issue would solve itself in short order if the
> actual
> > > implementation of swscale started to be good. My concern with adding a
> new
> > > library is that we'd end up in a situation where we have both swscale
> and a
> > > new library side by side for some extended period of time.
> > >
> > > By comparison adding cleaner APIs to swscale and then slowly strangling
> > > the old APIs (along the lines of Niklas' proposal) would allow for a
> more
> > > gradual transition that has a higher likelihood of success compared to
> a
> > > full rewrite IMO.
> > >
> >
> > The issue is not the API, the issue is that swscale is astonishingly
> > complex and difficult to understand internally, there are lots of
> different
> > codepaths
>
> > and randomly you'll end up with a buggy or slow one
>
> randomly ?
> code in general doesnt give you randomly something very different.
>

Come on, there's no need to be facetious. Change the PIX_FMT to a the same
sampling but a different packing and you a get totally different codepath,
sometimes just decides to use C. Likewise with any of the lightly
documented flags, you can have drastic changes in speed and quality unless
you pre-test all the code paths.


> So, why do i complain? because swscale has real issues and needs
> to be improved. And these comments point in the wrong direction
>
>
> > and have no
> > idea how to fix it.
>
> If you dont know how to fix it yourself, sending me a bug report is
> probably a good start.
>

Covered in here: https://trac.ffmpeg.org/wiki/swscale

Yuv422p10 to yuv420p10 has forced and useless and CPU costly scaling of the
luma channel with 32 bit intermediates last time I looked. All to be
shifted back to the original values.



>
>
> >
> > It's probably easier to start from scratch than to try and understand and
> > then fix swscale (years of work).
>
> Well there are 2 further aspects with that.
>
> The first one is bluntly put. If you dont understand the old code, then
> you probably are not qualified to write better code.
> People tend not to successfully improve things they dont understand.
>

I'm pretty sure you don't need to understand self-modifying code to write a
scaler.

The rest is covered here:
https://trac.ffmpeg.org/wiki/swscale


> The 2nd issue is, ATM, i maintain swscale. If iam involved in the new
> effort and understand it either because of that or because it has some
> similarity then i can continue to maintain swscale. If its totally
> different and i was totally not involded then i also will not maintain
> it obviously.
> This is something to be especially aware of in case the cleanup/new
> code would be done by someone who comes, does it and leaves. you
> could end up with nicer code thats then unmaintained.
>

Nicer code can be understood by more than one person.

Let's be honest you would block any attempt to even start removing cruft in
swscale like mmx, self-modifying code etc.


> PS: whats the real issue with sws ?
> it evolved out of a piece yuv->rgb converter from a video player.
> It evolved from that and stuff was added into it.
> This is a similar situation to why ffmpeg.c needed cleanup
>

Hmmm, building a simple thing for something and then "stuff being added",
that sounds like the arguments a few of us have been making in another
thread.

Regards,
Kieran Kunhya



> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship: All citizens are under surveillance, all their steps and
> actions recorded, for the politicians to enforce control.
> Democracy: All politicians are under surveillance, all their steps and
> actions recorded, for the citizens to enforce control.
> ___
> 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".
>
___
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".

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

>
> * If you have some flashy FFmpeg project you want to work on with a cost of
>   between 5-15k $ then propose it on the mailing list, make yourself ready
> for
>   some paperwork complexities and some public debate as thats the first
> time we
>   try this, there will be extra issues likely. And once the community
> approves
>   it and stefano with you double checks with SPI if we will be able to
> fund it.
>   Then you can start working on it
>

The mailing list is already an absolute disaster as it is and you now want
to put money into the mix?
I don't think developers should be paid via SPI for this reason.

Kieran
___
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".

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

Hi,

On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> Of course. FFmpeg has a donations account. So the money is already there
> and
> already used for the reimbursement requests. Whatever we spent it for
> needs to
> be decided by the community. Spending more money instead of just watch it
> growing is a good thing. That this will lead to more "disaster" is an
> assumption
> without basis. Even if this does happen and fails, its still better than
> not
> having even tried.
>

Reimbursement requests for clearly defined things like travel costs with
receipts, or hardware that the project owns is in no way comparable to
consulting work, contracts, statements of work etc. And the current swscale
proposal is far from this too.


> Also, you just advertised FFmpeg and asked for more financial support in
> your
> talk at Demuxed [1] - so I figure your prefered way of doing that would be
> to
> channel money into some company without the community being involved?
>

Actually if you watched the presentation, I said big companies need to
support maintenance (not the same as bounties) of FFmpeg by hiring
employees to work full time as they do with Linux Kernel maintainers. Or
failing that they can donate to the community - but as you know well the
numbers we have are not enough to hire full time maintainers.

Agreement via mailing list for money is a recipe for disaster. What we need
are clear statements of work that are voted on by TC.
We can't even agree on patch reviews, throwing money into the mix is
throwing gasoline into the fire.

And since you also advertised explicitly for FFlabs - what is your relation
> to
> FFlabs? I own 25% of that company and I am not aware of any relationship.
> You
> just did advertise FFlabs because... FFlabs exists? FFlabs is a company
> co-owned
> by some FFmpeg developers, it's not FFmpeg nor can it represent it or act
> on its
> behalf.
>

I linked to the consulting page and also to FFlabs which as far as I know
is the only company offering an SLA on FFmpeg.
If others existed I would have included them.


> As soon as we pay developers via SPI it can become a good zero-trust
> environment
> for donators to offer tasks & money to FFmpeg and handle the money flow
> via SPI.
> The donators can be sure that their issues are handled properly in the
> project
> (on the ML) and do not flow away into some other sink and the developers
> can be
> sure to get their money from SPI because the offer is public and backed by
> the
> FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl
> transparent way to handle things and build up trust in potential donators
> that
> the money they spent actually end up with FFmpeg.
>

Do you really think the way SPI funding is managed currently matches your
description?
Stefano approves by saying "Approved on my side, pending Michael's
approval."
This is not at all a community driven process where one person can veto
everything.

> I don't think developers should be paid via SPI for this reason.
>
> I think supporting FFmpeg developers via SPI fits perfectly into what we
> have
> SPI for in the first place - an independant entity that handles the
> community
> funds with absolute objectivity and no intrinsic interest whatsoever. In
> contrast to any company, including (my own-ish) FFlabs.
>

If there is disagreement (which will be inevitable) SPI will not step in.
Money is only going to make our current ML drama situation worse.

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> Am 27.10.23 um 03:28 schrieb Kieran Kunhya:
> > Hi,
> >
> > On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> >> Of course. FFmpeg has a donations account. So the money is already there
> >> and
> >> already used for the reimbursement requests. Whatever we spent it for
> >> needs to
> >> be decided by the community. Spending more money instead of just watch
> it
> >> growing is a good thing. That this will lead to more "disaster" is an
> >> assumption
> >> without basis. Even if this does happen and fails, its still better than
> >> not
> >> having even tried.
> >>
> >
> > Reimbursement requests for clearly defined things like travel costs with
> > receipts, or hardware that the project owns is in no way comparable to
> > consulting work, contracts, statements of work etc. And the current
> swscale
> > proposal is far from this too.
>
> Yes, of course they are different. Most importantly sponsored development
> needs
> to be agreed upon beforehand. That does not imply sponsored work is not
> clearly
> defined. I miss your argument about why it can't be done in this.
>

Do you seriously think this project will have a sudden outbreak of
professionalism and suddenly start producing detailed contracts and
statements of work?
It'll end up being a few lines on the mailing list.

>> Also, you just advertised FFmpeg and asked for more financial support in
> >> your
> >> talk at Demuxed [1] - so I figure your prefered way of doing that would
> be
> >> to
> >> channel money into some company without the community being involved?
> >>
> >
> > Actually if you watched the presentation, I said big companies need to
> > support maintenance (not the same as bounties) of FFmpeg by hiring
> > employees to work full time as they do with Linux Kernel maintainers. Or
> > failing that they can donate to the community - but as you know well the
> > numbers we have are not enough to hire full time maintainers.
>
> I'm totally fine with you asking big companies to hire devs for FFmpeg
> maintenance. That does not relate to my question, though. Do I assume
> correctly
> that your prefered way of doing that would be to channel money into some
> company
> without the community being involved?
>

Contractually yes, this is a better solution. It allows the company to be
in charge of delivery of the maintenance work with a contract behind it.
Do you seriously think big companies will suddenly hand over money to the
community that's got weekly drama around it?
This point was raised to me by a big company that shall remain nameless at
Demuxed.

> Agreement via mailing list for money is a recipe for disaster. What we
> need
> > are clear statements of work that are voted on by TC.
>
> That's not the purpose of the TC. We of course need to have a good way of
> approving or disapproving proposals and of course we need these to be
> clearly
> defined. I again miss to see your argument why that shall not be possible
> on the
> ML - everyone on this list knows where your suspicion comes from but
> again,
> without even having tried, it's just your assumption and should IMHO not
> stopping us from trying to implement such a procedure.
>

The mailing list isn't the be all and end all of all communications and
decision making in the world. History shows it's atrocious for making
decisions.
Many people make valid and succinct points that are outright ignored,
whoever writes the longest wall of text (often with conspiratorial
ramblings that I'm sure go down well with potential donors) seems to get
the most attention (i.e quantity vs quality).

Lots of people have left the project (e.g Derek) because of the toxicity of
this mailing list. Even the Linux Kernel realised their mailing list was
toxic and changed.


> > We can't even agree on patch reviews, throwing money into the mix is
> > throwing gasoline into the fire.
>
> Being in conflict about a patch is completely different to conflict about
> some
> feature we might want. And no, not everything is as controversial as SDR
> or gets
> controversial just because it would be sponsored. You think there would
> have
> been real and non-resolvable opposition against bringing multi-threading
> into
> ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such
> opposition?
> However, since I agree with you that there will be different oppinions,
> why
> would you think tha

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

On Fri, 27 Oct 2023 at 05:32, Michael Niedermayer 
wrote:

> On Fri, Oct 27, 2023 at 01:43:34PM +0300, Rémi Denis-Courmont wrote:
> >
> >
> > Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer <
> mich...@niedermayer.cc> a écrit :
> [...]
> > >* If you have some flashy FFmpeg project you want to work on with a
> cost of
> > >  between 5-15k $ then propose it on the mailing list, make yourself
> ready for
> > >  some paperwork complexities and some public debate as thats the first
> time we
> > >  try this, there will be extra issues likely.
> >
> > I don't think that code bounties count toward OSS "sustainability". It's
> condoning the so-called jig economy, which is the opposite, IMO.
>
> This is just a first step.
> If we can attract the financial resources to pay people in a repeated
> fashion
> "each month" then thats absolutely what id like to do with SPI
>

The thing we need for "sustainability" is someone to work full-time on
maintenance work like YUVJ removal that doesn't get done otherwise
(literally we have talked about this for the last five or more years). Nor
would any company fund it as a bounty as it provides no benefit to them.
This is the complete opposite of "some flashy FFmpeg project".

Kieran Kunhya
___
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".

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

On Sat, 28 Oct 2023 at 18:21, Michael Niedermayer 
wrote:

> Hi ronald
>
> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote:
> > Hi Thilo,
> >
> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > What this is about, is to set up a way to properly spend the SPI money
> > > aside
> > > from travel & hw. Why we should not do it because some companies
> > > beurocracy, I
> > > cannot see.
> > >
> >
> > I sincerely don't think the above description is what Kieran meant when
> he
> > talked about sustainability at Demuxed, which this thread seems to be a
> > response to.
>
> a quick reply here. I have not watched kierans presentation from demuxed
> yet.
> So theres absolutly no chance anything i wrote till now can be a respone to
> it.
>

For the record, I gave the Demuxed lightning talk on Wednesday 25th October
at 1400 PST (2100 UTC).
The first email in this chain was on Thursday 26th October at 1845 EEST
(1545 UTC).

Kieran
___
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".

[FFmpeg-devel] [PATCH] libavcodec/mpeg12: Remove "fast" mode

[Kieran Kunhya]

$subj as discussed at VDD

Kieran


0001-libavcodec-mpeg12-Remove-fast-mode.patch
Description: Binary data
___
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".

Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)

[Kieran Kunhya]

>
> so if we have someone do some payed development work be that one time or
> continous. There would be a contract that says what is going to be done.
> That also would have been approved by the community or GA or whatver and
> the company paying would have a say in whats in that contract, really
> limited by what we are ok with and what the law allows


Do you think a paying company would be happy with the private terms of a
contract being discussed on a public ML? Or within a large group of people
in the GA.
You already mentioned that some of your work is covered under NDA so how
does that fit within what you propose above about community approval?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12: Remove "fast" mode

[Kieran Kunhya]

On Mon, 30 Oct 2023 at 06:41, Matthias Dressel 
wrote:

> On 29.10.23 16:43, Kieran Kunhya wrote:
> > $subj as discussed at VDD
> >
> > Kieran
>
> IMHO the commit message should have contained some reason as to *why*
> this was removed.
> Now, someone looking at the log needs to find this patch on the ML, then
> follow the reference to find VDD meeting notes where they finally
> find... nothing. Because all the notes say is:
>
>  > We should remove it
>
> Unfortunately, I'm too late and it's pushed now, but maybe you can at
> least give a short explanation here on the ML?
>

"Fast" mode did some kind of out-of-spec VLC reading and dequant of MPEG-2
to allow faster decoding. This isn't really relevant in 2023 as MPEG-2
decoding is very fast in the official spec-compliant mode.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation

[Kieran Kunhya]

On Mon, 30 Oct 2023 at 13:10, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Section 7.4.4 of the MPEG-2 specifications requires that the
> last bit of the last coefficient be toggled so that the sum
> of all coefficients is odd; both our decoder and encoder
> did this only if the bitexact flag has been set (although
> stuff like this should be behind AV_CODEC_FLAG2_FAST).
> This patch changes this by removing the spec-incompliant
> functions.
>

LGTM
___
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".

[FFmpeg-devel] [PATCH] libavfilter/vf_hqdn3d: Remove emms

[Kieran Kunhya]

$subj


0001-libavfilter-vf_hqdn3d-Remove-emms.patch
Description: Binary data
___
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".

Re: [FFmpeg-devel] FFmpeg at NAB 2024

[Kieran Kunhya]

On Wed, 1 Nov 2023 at 20:37, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi,
>
> FFmpeg will have a booth at the next NAB from April 14th to 17th 2024 in
> Las
> Vegas [1]!
>
> We reiceived an anonymous corporate sponsorship for the booth, so there
> are no
> costs for the FFmpeg project to it (and no obligations, of course).
>
> Any FFmpeg developer is welcome to join in and man the booth with me,
> especially
> any developers based in the US or other american countries!
>
> Share with us your broken workflows, unfulfilled requirements, ideas for
> enhancements and after show drinks at W4232 [2]!
>

Hi Thilo,

Does this sponsorship include the cost of building, furniture, graphics,
booth design etc?
Having done booths for a decade, I can tell you this is the hardest part
and everything at a show costs what you think it does in your head plus two
zeroes on the end.
These elements cost more than the booth itself.

Note also in the US there are strictly enforced rules on unions building
booths so you have to hire in union labour.

Regards,
Kieran Kunhya




Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] [PATCH 2/6] libavformat/sdp: remove whitespaces in fmtp

[Kieran Kunhya]

On Mon, 6 Nov 2023 at 15:19, Michael Riedl 
wrote:

> Whitespaces after semicolon breaks some servers
>

Are you sure this patch doesn't break other servers? SDP is a painfully
fragile format.

Kieran
___
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".

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

[Kieran Kunhya]

> I think you where root on the trac server you provided and where hosting
> for us.
> but you kicked FFmpeg out and shut that down around the time of the
> vote to ban carl. But its long ago and maybe i misremember. We had a backup
> server and recovered with noone noticing the trac server moved.
> (now we do not have a backup server anymore)
>

This is a completely false allegation to make especially if you misremember.
Reported to cc.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH v2 2/6] libavformat/sdp: remove whitespaces in fmtp

[Kieran Kunhya]

On Tue, 14 Nov 2023 at 16:47, Tomas Härdin  wrote:

> tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > Whitespaces after semicolon breaks some servers
>
> Which servers? If the spec allows whitespace then the onus is on them
> to fix their implementations.
>
> /Tomas
>

Poor Tomas, you are not versed in SDP witchcraft where a single character
breaks dozens of devices but fixes dozens of others.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH v2 2/6] libavformat/sdp: remove whitespaces in fmtp

[Kieran Kunhya]

On Tue, 14 Nov 2023, 21:54 Tomas Härdin,  wrote:

> tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya:
> > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin  wrote:
> >
> > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > > > Whitespaces after semicolon breaks some servers
> > >
> > > Which servers? If the spec allows whitespace then the onus is on
> > > them
> > > to fix their implementations.
> > >
> > > /Tomas
> > >
> >
> > Poor Tomas, you are not versed in SDP witchcraft where a single
> > character
> > breaks dozens of devices but fixes dozens of others.
>
> I have in fact had some contact with SDP, much to my chagrin. This is
> also why we should be very strict with it, and be very clear what the
> spec says, and/or have the spec changed to reflect reality. With MXF,
> being strict has already paid dividends.
>
> /Tomas
>

Not comparable IMO, these are embedded IoT devices that will never be
fixed. I have spent months of my life debugging a single character issue in
SDP. I kid you not.

Kieran

>
___
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".

Re: [FFmpeg-devel] [PATCH 2/3] x86/ac3dsp: add ff_float_to_fixed24_avx2()

[Kieran Kunhya]

On Wed, 22 Nov 2023, 19:49 James Almer,  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/ac3dsp.h  |  4 ++--
>  libavcodec/ac3enc_template.c |  2 +-
>  libavcodec/x86/ac3dsp.asm| 28 ++--
>  libavcodec/x86/ac3dsp_init.c |  4 
>  4 files changed, 33 insertions(+), 5 deletions(-)
>

I think this is AVX, I might be wrong but I don't see any AVX2.

Kieran

>
___
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".

[FFmpeg-devel] [FOSDEM] Call For Participation: Open Media devroom

[Kieran Kunhya]

Dear FFmpeg community.
Please see FOSDEM Open Media Devroom invite:

Hey all,

The Open Media devroom returns at FOSDEM 2024, and we are looking for
propositions of talks and panels. FOSDEM is one of the largest (8,000+
hackers!) gatherings of Free and Open Source Software contributors in
the world and happens every February in Brussels (Belgium, Europe).

This year, the Open Media devroom will take place in-person on:
Sunday, February 4th, 2024.


# About the Open Media devroom

The Open Media room will focus on all Free & Open Source media
projects, including software and hardware, spanning from building
audio & video applications, through standards, formats, codecs, video
analytics and search to Web video, IPTV, broadcasting and radio
practices and much more. If you're interested in video, image or audio
technologies, and the breadth of available open source technologies
and communities for media - the Open Media room is for you!

For more information about the previous year
sessions:https://archive.fosdem.org/2023/schedule/track/open_media/


# CFP Guidelines

The deadline for submission is: December 14th, 2023.

* To submit your proposal, visit: https://pretalx.fosdem.org/fosdem-2024/cfp

* IMPORTANT: Please make sure to select "Open Media" track for your submission.

* Your submission must include the following information
- The title and subtitle of your talk (please be descriptive).
- A short single paragraph detailing what the talk will discuss, and
why attendees should attend it.
- A longer description if you have more details to share.
- Links to related material/websites/blogs etc.
- A biography of yourself.
- If you have a complicated schedule (plane to catch, other talk...)
or need an invitation for a visa, please tell us in the submission
notes and we will try to accommodate.

* You can submit a session of one of the following formats:
- lightning talk (10 minutes incl. questions),
- regular talk (25 minutes incl. questions),
- workshop (40 minutes or more)

* Selected talks will be notified by December 15th 2023.

* All sessions will be recorded and be made available under CC-BY
licence by FOSDEM at https://video.fosdem.org/ .

* You have to be present in Brussels in-person on Sunday, February 4th, 2024.


# Community

The official communication channel is the Open Media devroom
mailing-list. Join the list
at:https://lists.fosdem.org/listinfo/open-media-devroom
You can also find us on IRC at #fosdem-open-media on libera.chat

And please don't hesitate to contact us for more information!

Jaron, Jean-Baptiste and Kieran,
On behalf of the Open Media devroom
___
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".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Kieran Kunhya]

>
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html


There are numerous inactive people in the voting committee, some for years.
Why are they arbitrarily allowed to vote on this?

Kieran
___
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".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Kieran Kunhya]

On Fri, 3 May 2019, 06:27 Jeyapal, Karthick,  wrote:

>
> On Sun, Apr 28, 2019 at 4:02 PM Marton Balint  wrote:
>
> > (In this case, NDI plugin is already open source).


This is untrue.

Furthermore, I am amazed you are all ignoring the fact this is an Open
Source hostile company, actively sending legal threats to a developer
writing an Open Source implementation of NDI.

Kieran
___
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".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Kieran Kunhya]

>
>
> Kieran,
>
> Can you point to evidence on the same? An active legal threat to "a
> developer writing an open source implementation of NDI"?
>
> With that in place, it wouldn't be ignored as a material fact, would it?
>

https://trac.ffmpeg.org/ticket/7589

Discussed in there. A few people in the community can corroborate this.
But it's not the job of the person who was threatened to publicise this in
detail.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input"

[Kieran Kunhya]

>
> if you dont return 3 fields you break the normative specification. This
> speaks
> about the "output of the decoding process" not how to interpret the output.
>
> I bring MPEG2 up here because we dont do what the normative spec says
> because it doesnt make sense for us. It does make sense if you output on a
> analoge interlaced PAL/NTSC screen. It is fundamentally the same as the
> CFR case, on one side a interlaced display as factor on the other a output
> only capable to handle fixed duration (CFR) frames.
>
> About CFR codecs, the cases this is about are generally input packets that
> code the equivalent of "nothing changed". In frameworks that allow only CFR
> an implementation would produce a duplicated frame. In frameworks that
> allow
> VFR an implementation can omit the duplicated frame.
>

I don't really care about qtrle here but this is not comparable.
If you are a cfr output device, you *know* that you have to duplicate a
field because of the flag that's exported and this duration is clearly
defined.
But with the qtrle patch, you don't know how long the duration of the frame
just returned is.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: Check input space

[Kieran Kunhya]

On Tue, 14 May 2019 at 20:42, Michael Niedermayer 
wrote:

> Fixes: Timeout (33sec -> 78ms)
> Fixes:
> 14668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5767073352908800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/pngdec.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 6a681be29d..78988d9e75 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1535,6 +1535,9 @@ static int decode_frame_lscr(AVCodecContext *avctx,
>  AVFrame *frame = data;
>  int ret, nb_blocks, offset = 0;
>
> +if (avpkt->size < 2)
> +return AVERROR_INVALIDDATA;
> +
>

Why not 1?
Or maybe 3?
Or maybe 42?

Random numbers to fix random samples are just absurd.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function

[Kieran Kunhya]

On Thu, 27 Jun 2019 at 20:01, Nicolas George  wrote:

> Andreas Rheinhardt (12019-06-27):
> > The code is indeed dead atm. To quote myself from ticket 7886:
> > "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for
> > alpha channel decoding in Cineform HD (thereby fixing #6265), but
> > commit 9cefb9e7ec508900ba147e6977590f03456aa15c broke it again (the
> > function process_alpha introduced in the first commit is now not even
> > used any more -- thanks to Clang for reporting this). The sample
> > cineform_rgba_12b.mov from #6265 now decodes as before
> > c64c97b972c7325a71440a352a7d541a8c92b2da."
>
> Thanks for clarifying. If it is dead, it can be removed. If it is needed
> back, then it can be added back. Steven, go ahead if you want.
>

Why can this not be fixed properly? If the call to the function has been
removed accidentally, why make things worse and remove the function
completely?
This makes no sense at all.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function

[Kieran Kunhya]

On Thu, 27 Jun 2019 at 20:52, Nicolas George  wrote:

> Kieran Kunhya (12019-06-27):
> > Why can this not be fixed properly?
>
> It can. If you have time and motivation to do it, please go ahead.
> Barring that, removing dead code is still an improvement.
>
> Regards,
>

It's not dead code, the GSOC student last year removed the call to the
function by accident.
It is beyond comprehension how removing more code and making the situation
worse improves things.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function

[Kieran Kunhya]

>
> If it is so easy, you could do it instead of arguing. If it is not so
> easy, you cannot demand somebody do it.
>

I'm happy to do it now that I am aware of the issue. I will do it when I am
at home in a few days.


> > It is beyond comprehension how removing more code and making the
> situation
> > worse improves things.
>
> Dead code is never good.
>

This absolutism is absurd.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add back alpha processing removed in 9cefb9e7ec

[Kieran Kunhya]

On Sat, 29 Jun 2019 at 08:09, Paul B Mahol  wrote:

> Fixes #7886.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/cfhd.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..49a5a2c30a 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -884,6 +884,8 @@ static int cfhd_decode(AVCodecContext *avctx, void
> *data, int *got_frame,
>  high = s->plane[plane].l_h[7];
>  for (i = 0; i < lowpass_height * 2; i++) {
>  horiz_filter_clip(dst, low, high, lowpass_width, s->bpc);
> +if (avctx->pix_fmt == AV_PIX_FMT_GBRAP12 && act_plane ==
> 3)
> +process_alpha(dst, lowpass_width * 2);
>  low  += lowpass_width;
>  high += lowpass_width;
>  dst  += pic->linesize[act_plane] / 2;
> --
> 2.17.1
>

LGTM
___
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".

Re: [FFmpeg-devel] [PATCH v1] Config files for NetBeans IDE

[Kieran Kunhya]

I would ignore what Paul says and perhaps start a Github project with your
patch.
I think it would be useful for developers using the NetBeans IDE.

Kieran

On Fri, 5 Jul 2019 at 23:33, Paul B Mahol  wrote:

> If this is meant to be applied to our tree I'm against.
> We do not need this bloat.
>
> On 7/5/19, Ulf Zibis  wrote:
> > Hi,
> >
> > I have made excellent experience in using the NetBeans IDE for FFmpeg
> > developement. So I like to share the customized configuration for this
> > if people like to try it here:
> > http://jugkoeln.de/Projects/ffmpeg/netbeans_1.patch
> >
> > The most impressing is the graphical debugger.
> >
> > The NetBeans IDE can be found here: https://netbeans.org
> > To run a C project one has add the NetBeans 8.2 Plugin Portal in the
> > Plugin Manager with following URL:
> >
> http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz
> > and then install the C/C++ Plugin.
> >
> > Have fun with it
> >
> > -Ulf
> >
> > ___
> > 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".
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions

[Kieran Kunhya]

>
> What was the cause of the slow decoding? Does this actually fix it, or
> does it just swipe it "under the carpet"?
> If someone ever found a sample with a different solution, how would they
> know that they shouldn't just remove this again? Without any kind of
> comment on the point of this call, people might assume it's pointless
> nonsense.
>

A significant proportion of these patches sweep the issue under the carpet.
Not to mention the swathes of annoyed developers

Kieran
___
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".

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Kieran Kunhya]

On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer 
wrote:

> Hi all
>
> It seems we do not have a list of people volunteering to do uploads to
> samples. And no place to send such requests to except here, where they
> sometimes get ignored.
>

Just give everyone with push access right to upload.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation

[Kieran Kunhya]

On Mon, 5 Aug 2019 at 17:10, Michael Niedermayer 
wrote:

> On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote:
> > The previous calculation code did not account for the fact that the
> > copy_offset for the start of the frame array is at index 0, yet the
> > scan line number from the rfc4175 RTP header starts at 1.
> > This caused 2 issues to appear:
> > - The first scan line was being copied into the array where the second
> >   scan line should be. This caused the resulting video to have a green
> >   line at the top of it.
> > - Since the packet containing the last scan line would fail the
> >   calculation, the packet with the RTP marker would not be processed
> >   which caused a log message saying "Missed previous RTP marker" to be
> >   outputted for each frame.
> >
> > Signed-off-by: Jacob Siddall 
> > ---
> > Changes in v2:
> >   - Don't handle packet if the line number is less than 1
> >
> > Section 12 in the VSF technical recommendation TR-03 specifies that the
> > video scan line numbers should start at 1.
> >
> http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
>
>
SMPTE 2110-20 says line numbers start at 0. (Yes there are 3 different
"standards" for handling the line number because of the geniuses in the
broadcast industry).

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector

[Kieran Kunhya]

>
> You argue that it does not NEED to be in lavu, but not that it SHOULD
> note.
>
> > Plus, its not really common av code, and don't let its name mislead
> > you, its more of a hack.
>
> I will disregard the insulting subtext of this sentence.
>

There is nothing insulting about this sentence. IMO this is a hack, how
come we have not needed such a thing for years?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 05/11] avcodec/h264_parser: Reuse the RBSP buffer

[Kieran Kunhya]

On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Up until now, the H.264 parser has allocated a new buffer for every
> frame in order to store the unescaped RBSP in case the part of the RBSP
> that will be unescaped contains 0x03 escape bytes. This is expensive
> and this commit changes this: The buffer is now kept and reused.
>
> For an AVC file with an average framesize of 15304 B (without in-band
> parameter sets etc.) and 132044 frames (131072 of which ended up in the
> results) this reduced the average time used by the H.264 parser from
> 87708 decicycles (excluding about 1100-1200 skips in each iteration)
> to 16963 decicycles (excluding about 10-15 skips in each iteration).
> The test has been iterated 10 times.
>

If I understand correctly, this patch means if you have a large frame (or
large NAL) you are stuck with the large allocation of memory until the
decoder is closed.
Not sure if you have read the discussion here
https://patchwork.ffmpeg.org/patch/5631/

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 05/11] avcodec/h264_parser: Reuse the RBSP buffer

[Kieran Kunhya]

On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Kieran Kunhya:
> > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Up until now, the H.264 parser has allocated a new buffer for every
> >> frame in order to store the unescaped RBSP in case the part of the RBSP
> >> that will be unescaped contains 0x03 escape bytes. This is expensive
> >> and this commit changes this: The buffer is now kept and reused.
> >>
> >> For an AVC file with an average framesize of 15304 B (without in-band
> >> parameter sets etc.) and 132044 frames (131072 of which ended up in the
> >> results) this reduced the average time used by the H.264 parser from
> >> 87708 decicycles (excluding about 1100-1200 skips in each iteration)
> >> to 16963 decicycles (excluding about 10-15 skips in each iteration).
> >> The test has been iterated 10 times.
> >>
> >
> > If I understand correctly, this patch means if you have a large frame (or
> > large NAL) you are stuck with the large allocation of memory until the
> > decoder is closed.
> > Not sure if you have read the discussion here
> > https://patchwork.ffmpeg.org/patch/5631/
> >
> > Kieran
> >
> I am aware of said discussion; and also of your solution [1] to it. It
> actually does exactly the same as I propose for the parser: It keeps a
> single buffer that does not shrink. Given that this is used for the
> decoders (and for cbs_h2645), I didn't deem this to be problematic.
> (There is clearly no quadratic memory usage and what Derek warns about
> (with huge NALs at specific positions) is a no issue for both.)
>
> - Andreas
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219100.html


My solution frees the buffer when it's done. With yours it stays around as
a large buffer essentially forever.

Kieran
___
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".

Re: [FFmpeg-devel] [REQUEST] avcodec/scpr: revert d70276921348

[Kieran Kunhya]

On Tue, 20 Aug 2019 at 14:16, Carl Eugen Hoyos  wrote:

> Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol  >:
>
> > I kindly ask that following commit:
> d702769213487923c0fb0abe4b61f4d9ebddb88b
>
> I still believe what the patch does is a very good idea and a revert would
> hurt FFmpeg.
>

We should not turn CFR streams into VFR. This would not be acceptable for
H264 not should it be acceptable for any other codec.

Kieran
___
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".

Re: [FFmpeg-devel] [REQUEST] avcodec/scpr: revert d70276921348

[Kieran Kunhya]

On Tue, 20 Aug 2019 at 18:06, Michael Niedermayer 
wrote:

> On Tue, Aug 20, 2019 at 05:09:51PM +0100, Kieran Kunhya wrote:
> > On Tue, 20 Aug 2019 at 14:16, Carl Eugen Hoyos 
> wrote:
> >
> > > Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol <
> one...@gmail.com
> > > >:
> > >
> > > > I kindly ask that following commit:
> > > d702769213487923c0fb0abe4b61f4d9ebddb88b
> > >
> > > I still believe what the patch does is a very good idea and a revert
> would
> > > hurt FFmpeg.
> > >
> >
> > We should not turn CFR streams into VFR. This would not be acceptable for
> > H264 not should it be acceptable for any other codec.
>
> All MPEG & ITU codecs i remember follow this too as far as possible,
> including H264
>
> [...]
> again, we return metadata we do not return the same frame
>
> same is true for msmpeg4 and every other codec which uses metadata at AVI
> level
> that is skiped frames. The codecs are CFR at AVI level but we do not
> output CFR
>

All of these codecs contain metadata to add more frames if the decoder
requires.
Nowhere are frames which can't be decoded are dropped.



> But what is more bizare (to me at least) is that this was not a controversy
> at the time CFR was the standard and all these codecs where "new".
> Please correct me if iam wrong but the "CFR must be CFR" seems to
> originate
> from some professional broadcast people (like you).
>

This is what you would call an "ad-hominem"


> But then it seems the codecs which broadcast people use
> the fact they dont preserve CFR in this way isnt a problem and not even
> noticed
> while for codecs that broadcast has noting to do with like SCPR its a big
> issue.
> This makes no sense to me.
>

Someone decoding an SCPR file to encode to another format now has fewer
frames than before.
All done to pass a fuzzer. Simple as that.

Kieran

-- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Take away the freedom of one citizen and you will be jailed, take away
> the freedom of all citizens and you will be congratulated by your peers
> in Parliament.
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Fix integer overflow in mpeg4_decode_studio_block()

[Kieran Kunhya]

On Thu, 22 Aug 2019 at 23:55, Michael Niedermayer 
wrote:

> Fixes: signed integer overflow: 24023040 * 112 cannot be represented in
> type 'int'
> Fixes:
> 16570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5173275211071488
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
>
>
ok
___
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".

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/qtrle: return last frame even if unchanged

[Kieran Kunhya]

>
> "time of origin, capture" is clearly a timecode, not a timestamp in
> the sense we're talking about here (plus that the bitstream codes it
> in hours/minutes/seconds). I expect you know the difference.
> If these timecodes are considered useful it would be trivial to expose
> them from the decoder too, since they are already being parsed and
> stored.
>

These timecodes are already outputted as side data.
As Nev says they have *nothing* to do with presentation, they are just
metadata.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/qtrle: return last frame even if unchanged

[Kieran Kunhya]

>
>
> Lets check H264
> claim "They do not have a timestamp"
> immedeatly after the pic_struct field which tells you about the repeating
> behavior there is a loop for each repeated value with a timestamp.
> This timestamp is lost, if at CFR one can call it that way.
>
> about "Every encoded frame should produce a decoded frame"
> quote about this timestamp from the h264 spec
> "The contents of the clock timestamp syntax elements indicate a time of
> origin, capture, or alternative ideal display."
>

This is a simple misunderstanding of the difference between timecode and
timestamp.
I point you to numerous publications about the difference.


> "origin, capture" implies that the repeated frame can have come from
> a real input packet because otherwise it wouldnt have a capture or origin
> time.
> So an encoder could use this as a way to represent some input frames
> And in that case only a decoder that follows these repeats exactly would
> have input == output
> which again brings us full circle as this matches what we see in qtrle
> repeats
>

You conflate presentation (with repeated fields/frame) and decoding which
are not the same thing.

Kieran
___
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".

[FFmpeg-devel] [PATCHv2] mpeg4video: Add Studio DPCM support

[Kieran Kunhya]

0001-mpeg4video-Add-Studio-DPCM-support.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mpeg4video: Add SStP FATE test

[Kieran Kunhya]

0001-mpeg4video-Add-SStP-FATE-test.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fwd: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers participation

[Kieran Kunhya]

-- Forwarded message -
From: Zohar Babin 
Date: Fri, 12 Oct 2018 at 12:50
Subject: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers
participation
To: FOSDEM , Open Media devroom <
open-media-devr...@lists.fosdem.org>


Hi all,

Join us on February 2, 2019 in Brussels for the 5th year of the Open Media
devroom at FOSDEM!

Video has gone mainstream, and technologies to handle media assets,
streams, workflows and apps at scale are now critical for many operations
both hobby and commercial.
Submit a speaking session and share your knowledge with the community at
FOSDEM! We want to learn about open standards, software or hardware
projects that deal with media.

We're looking for sessions on software or hardware spanning from building
audio / video applications, through open standards, formats, codecs, media
analytics and search, AI for creating or analyzing media, IPTV,
Broadcasting and Radio practices - anything media is welcome!

This year, the Open Media devroom will take place on:
Saturday, February 2nd, 2019.
About FOSDEM

FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free and Open
Source Software contributors in the world and happens each February in
Brussels (Belgium, Europe).
About the Open Media devroom

A lot of free and open source projects are used in the media business, as
well in the broadcast industry as in the Web streaming. There are seldom
events where project members are able to share and promote their projects,
and FOSDEM is a very good place for such discussions and presentations. The
Open Media room has already been organised at FOSDEM for the last four
years, with a strong attendance and talks of great quality. We intend to
continue the work to make it even greater.
If you're interested in video, image or audio technologies, and the breadth
of available open source technologies and communities for media - the Open
Media Room is for you!
For more information about the previous year sessions:
https://archive.fosdem.org/2018/schedule/track/open_media/ .
CFP Guidelines

The deadline for submission is: December 3rd 2018 (Monday).

   - To submit your proposal, visit:
   https://penta.fosdem.org/submission/FOSDEM19
   - You can submit a session of one of the following formats:


   - lightning talks (10 minutes incl. questions)
   - regular talk (25 minutes incl. questions)
   - workshops (45 minutes or more)


   - Between sessions we will allow additional 5 minutes Q&A and 5 minutes
   for speaker switching/prep in between. Panel discussions may last longer
   (Feel free to ask if you want to have a longer or a shorter slot).
   - IMPORTANT: Please make sure to select *”Open Media devroom”* track for
   your submission.
   - You will need to create an account (or use your account from previous
   years) and then go to "create event”, and add the details of your
   presentation.
   - Selected talks will be notified by December 15th 2018.
   - All sessions will be recorded and be made available under CC-BY
   licence by FOSDEM at https://video.fosdem.org/ .

Your submission must include the following information

   - The title and subtitle of your talk (please be descriptive).
   - select *”Open Media devroom”* as the track.
   - Short single paragraph detailing what the talk will discuss, and why
   attendees should attend it.
   - A longer description if you have more details to share.
   - Links to related material/websites/blogs etc.

Community

The official communication channel is the Open Media devroom mailinglist.
Join the list at: https://lists.fosdem.org/listinfo/open-media-devroom .

And please don't hesitate to contact us for more information!

Zohar, Avital, Jess, Christophe and Kieran,
On behalf of the Open Media devroom.


___
open-media-devroom mailing list
open-media-devr...@lists.fosdem.org
https://lists.fosdem.org/listinfo/open-media-devroom
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Kieran Kunhya]

>
> > What if a majority of the committee is biased and bans everyone they
> disagree with to take over the project? They certainly could.
> What if the committee's decision is something the majority of the
> developers disagree with?
>
> This is why I'm against formalizing such prodecures. They're too inflexible
> and absolute, and end up being abused or overused (like videolan's weekly
> temporary bannings I've heard of).
> Furthermore why do you bring this up now at all? We haven't had accidents
> of this nature in quite some time. In fact the last time it was the ML
> admin's random incorrect decision to block a discussion which ended up
> being a problem that everyone disagreed with. And that was 11 months ago


Thank you for confirming to the rest of the community why we need a
committee and proper Code of Conduct like other comparable Open Source
projects.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency

[Kieran Kunhya]

On Tue, 10 Mar 2020 at 12:07, Hendrik Leppkes  wrote:

> On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai 
> wrote:
> >
> > Avoid constant N frames latency in video streaming.
> >
>
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changing delay.


I agree. Furthermore I do not understand how this patch is allowed.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency

[Kieran Kunhya]

On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J 
wrote:

> Thanks, I will update the commit message.
>
> I test it with FFmpeg native sw H264 decoder.
> In previous FF_THREAD_FRAME,  the latency is constant as N ( =
> thread_count - 1) frames.
> It won't sync thread state until no idle threads available, therefore N
> frames are cached internal, even some frames are ready for output.
> E.g. in RTSP 30fps streaming playback, 16 frame threads (default), the
> internal frame caching contributes 495ms(33ms x 15frame) latency.
> And the latency is the same, regardless the video resolution is 640x480 or
> 4320x2160.
>
> In this patch, I attempt to check thread state and try best output frame
> to reduce the constant frame caching latency.
>
> Thanks,
> Jianhui Dai
>

Unless I misunderstand, surely this outputs frames nondeterministically?
i.e you don't know that the thread which has finished is the next one that
is due

Not to mention the variable latency problems.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency

[Kieran Kunhya]

On Wed, 11 Mar 2020 at 02:59, Dai, Jianhui J 
wrote:

> It does not break FFmpeg output frames management logic (e.g.
> h264_select_output_frame), just enter that phase earlier.
>
> Perhaps my understanding is not correct.
> In my opinions, render should be the one considering variable latency
> issue, instead of decoder.
>

How does the renderer know what the maximum latency of the upstream
pipeline is?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency

[Kieran Kunhya]

>
> Regardless of the actual proposed patch, I think the author's use of
> wallclock time to describe the problem is very reasonable.  I do a
> large amount of work where I'm measuring "glass-to-glass" latency,
> where I am interested in the total pipeline (encode/network/decode),
> and I definitely went through the experience of trying to figure out
> why ffmpeg was introducing nearly 500ms of extra latency during
> decoding.  It turned out that it was because my particular platform
> had 8-cores and thus 16 decoding threads and thus 15x33ms of delay,
> regardless of the stream complexity.
>

You shouldn't be using frame threads for this kind of application.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH v9 4/4] avcodec/h264: create user data unregistered SEI side data for H.264

[Kieran Kunhya]

On Tue, 17 Mar 2020 at 11:25,  wrote:

> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
>

I've seen whole planes (e.g Alpha) taking up 10s or 100s of KB put in SEI,
do we really want to export this all as side data?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH v9 2/4] avcodec/hevc_sei: add support for user data unregistered SEI message

[Kieran Kunhya]

On Wed, 18 Mar 2020 at 02:38, Limin Wang  wrote:

> On Wed, Mar 18, 2020 at 12:13:33AM +, Derek Buitenhuis wrote:
> > On 17/03/2020 23:11, Limin Wang wrote:
> > > The user data unregistered allows arbitrary data to be carried in the
> bitstream,
> > > for example, ROI info, time info etc. For the real support patch,
> please refer to
> > > the pending patch series 7, 8 in below link:
> > >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200107050355.17503-1-lance.lmw...@gmail.com/
> >
> > I understand what the SEI does. I was inquiring as to what the usecase
> you had
> > in mind for it specifically. I don't like the idea of adding APIs that
> are only
> > theorically useful - that is, what data is intended to be shoved in
> there?
>
> In order to identify the source of time used in the live event, the
> encoder system can
> insert a time mode-source code along with each embedded precision time
> stamp.
> Each time mode-source code will be inserted into the H.264/H.265 bitstream
> as an SEI
> message of type User Data (Unregistered). The format is self-defined json
> string
>

And the timecode field is not enough?
You do know that the time at source will not match the rate at which frames
arrive, there will be a drift?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 13/18] h264_sei: parse the picture timing SEIs correctly

[Kieran Kunhya]

On Fri, 13 Mar 2020 at 10:32, Anton Khirnov  wrote:

> Those SEIs refer to the currently active SPS. However, since the SEI
> NALUs precede the coded picture data in the bitstream, the active SPS is
> in general not known when we are decoding the SEI.
>

The spec disagrees with this statement (7.4.1.2.1 Order of sequence and
picture parameter set RBSPs and their activation). There are reasonably
clear rules about SPS activation.
(Whether real world bitstreams comply is a different issue of course).

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 13/18] h264_sei: parse the picture timing SEIs correctly

[Kieran Kunhya]

>
> I don't think you read that section carefully enough. What it says (in
> my interpretation) is that an SPS can be activated only by:
> - buffering period SEI
> - a PPS (which is itself activated by picture data)
> Picture timing SEI is neither of those.
>

The contents of pic-struct do not affect activation but have dependent
syntax elements.
So for example a Buffering Period SEI could activate an SPS and then
followed by pic-struct and pic struct would then have a dependency on the
activated SPS.
This SPS could be different to the one the VCL data refers to. I think
there are other corner cases as well.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH]lavc/sbc: Remove bool usage

[Kieran Kunhya]

On Thu, 2 Apr 2020 at 08:53, Paul B Mahol  wrote:

> On 4/1/20, Thierry Foucu  wrote:
> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos 
> wrote:
> >
> >> Hi!
> >>
> >> It seems to me that this was forgotten when the codec was originally
> >> ported.
> >>
> >
> > why removing "stdbool.h"?
> > it was defined in 2001? so, most compiler should support it..
> > Should we not check for the compiler support of it and if not, then
> either
> > reject the compiler or defines the type ourself?
>
> You are deeply wrong.
>

What modern compiler does not support bool?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH]lavc/sbc: Remove bool usage

[Kieran Kunhya]

On Thu, 2 Apr 2020 at 14:24, Paul B Mahol  wrote:

> On 4/2/20, Derek Buitenhuis  wrote:
> > On 02/04/2020 10:41, Paul B Mahol wrote:
> >> I do not care, bool is evil and should never be used.
> >
> > Why? 'We don't like it' isn't a technical reason.
> >
> > Also, FFmpeg already uses plenty of C99 features and thus
> > requires a C99 compiler. What is so inherently evil about a boolean
> > type that it must not be allowed, but other C99 features are?
> >
> > I am curious what compilers support all the C99 features used that
> > do not support stdbool.h, and are still actually used (even by 2 people).
>
> No code in FFmpeg use it.
> And it was disallowed before and should be now.
>

https://en.wikipedia.org/wiki/Appeal_to_tradition

Kieran
___
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".

Re: [FFmpeg-devel] [inline assembly compliance] Issues and patches

[Kieran Kunhya]

On Fri, 3 Apr 2020 at 22:07, Carl Eugen Hoyos  wrote:

> Am Fr., 3. Apr. 2020 um 22:42 Uhr schrieb FRÉDÉRIC RECOULES
> :
>
> > we are academic researchers working in automated program analysis.
> > We are currently interested in checking compliance of inline asm chunks
> > as found in C programs.
> >
> > While benchmarking our tool and technique, we found a number of issues in
> > FFMPEG. We report them to you, as well as adequate patches.
> > Actually, we found 59 significant compliance issues in your code.
> > We join 3 patches for some of them, together with explanations and
> > we can send you other patches on demand.
> >
> >
> > * All these bugs are related to compliance between the block of asm and
> its
> > surrounding "contract" (in gcc-style notation). They are akin to
> undefined or
> > implementation-defined behaviours in C: they currently do not manifest
> > themselves in your program, but at some point in time with compiler
> > optimizations becoming more and more aggressive or changes in
> undocumented
> > compiler choices regarding asm chunks, they can suddenly trigger a
> > (hard-to-find) bug.
>
> So your current patch does not change compilation output (without
> debug symbols) when compared with md5sum or similar?
>

We do not do such a comparison for C undefined behaviour changes so why
should we do such a comparison for this code?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH]lavfi/telecine: Mark telecined frames as interlaced

[Kieran Kunhya]

; attached.
> > >> >> >> >>> >
> > >> >> >> >>> > Patch applied.
> > >> >> >> >>> >
> > >> >> >> >>>
> > >> >> >> >>> This was never approved by me.
> > >> >> >> >>
> > >> >> >> >> You reviewed it on irc and correctly pointed out the missing
> > >> >> >> >> bits.
> > >> >> >> >
> > >> >> >> > Lies, I was against that idea from start.
> > >> >> >> >
> > >> >> >> >>
> > >> >> >> >>> So revert it ASAP!
> > >> >> >> >>
> > >> >> >> >> What should be changed about it?
> > >> >> >> >
> > >> >> >> > Return of code as it was before this pointless change.
> > >> >> >> > I see no good out of it.
> > >> >> >>
> > >> >> >> I gonna revert this ASAP!
> > >> >> >
> > >> >> > Could you explain why it is wrong to mark interlaced frames
> > >> >> > as interlaced?
> > >> >>
> > >> >> The frames are not interlaced.
> > >> >
> > >> > Using the usual 3:2 telecine, the filter outputs two progressive
> > >> > frames, followed by three interlaced frames, the patch should
> > >> > mark the interlaced frames as interlaced and I believe it does.
> > >>
> > >> You are very ignorant or very stupid or both.
> > >
> > > Apparently yes because ...
> > >
> > >> Interlaced frames are frames produced by interlacing.
> > >> Telecine is not interlacing.
> > >
> > > ... to the best of my knowledge, the telecine process outputs
> > > interlaced (and non-interlaced) frames, so I do not understand
> > > your argumentation, please elaborate.
> >
> > Interlacing usually destroys half of data, telecine never does that.
>
> There are cameras that output interlaced content, they do not
> destroy any data (the "missing" data never existed).
>
> I don't think your definition is ideal, a more useful definition is that
> the fields of one frame originate from different points in time.
>
> > Claiming frames are interlaced will just confuse confused users more.
>
> I was more thinking of encoders, they will be less confused with the
> patch.
>
> > >> >> I thought you knew that interlacing destroys half of data.
> > >> >> Telecine does not destroys data.
> > >> >
> > >> > Telecine duplicates some data, leading to interlaced frames.
> > >> > A (perfect) detecine process can remove the duplicated data
> > >> > (and the interlaced frames).
>

You both seem to misunderstand, confusing the structure of the frame with
the transport.

Telecine is a method of taking progressive content (e.g film) and
displaying it on an interlaced device (e.g CRT)
By definition it converts progressive structured frames to interlaced
transport.
This means that all output frames are interlaced (otherwise a CRT would not
be able to play it).
It might so happen that some (or all) frames still retain a progressive
structure but this is orthogonal to the conversion that has taken place.

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

On Sun, 7 Feb 2021, 14:21 Nicolas George,  wrote:

> Marton Balint (12021-02-07):
> > av_gettime_relative() is using the monotonic clock therefore more
> suitable as a
> > timestamp source and for relative time calculations.
> >
> > Probably fixes ticket #9089.
>
> Not ok.
>
> This is a user-visible change of behavior, we cannot do it just like
> that.
>
> Furthermore, for devices, timestamps are not only needed to synchronize
> between devices within the same computer, they may be needed to
> synchronize between devices connected to different computers, or between
> devices and other network streams (IP webcams are the obvious example).
>

It is wrong to suggest that the clock of an IP webcam has any relation at
all to the PC clock both absolute or relative.

The best course of action is to generalize what was done with v4l: make
> it an option.
>

This is as usual a major flaw in v4l2. The monotonic clock should always be
used. It's the least-worst clock.

Kieran

Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

Sent from my mobile device

On Sun, 7 Feb 2021, 16:31 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > It is wrong to suggest that the clock of an IP webcam has any relation at
> > all to the PC clock both absolute or relative.
>
> It is not wrong to let users observe that their particular model of IP
> webcam uses Unix timestamps and is correctly synchronized. This is a
> common practice, after all.


This is nonsense. The clock on any device comes from the oscillator onboard
the device. Not from any PC clock on the motherboard. These clocks are
almost certainly not the same model, they have different temperatures etc
so they drift differently.

> This is as usual a major flaw in v4l2. The monotonic clock should always
> be
> > used. It's the least-worst clock.
>
> Care to justify how giving the user an option is worse than not?


Give the user the option not to use the monotonic clock.

Care to explain how you propose to synchronize device captured on
> different computers?


This is not possible without high end capture equipment to synchronise the
clocks on each camera. Everything else is guesswork.

I encourage you to read the section on clocks here:
https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-believe-about-%5Bvideo-stuff%5D.html

Kieran

Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

Sent from my mobile device

On Sun, 7 Feb 2021, 16:55 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > Give the user the option not to use the monotonic clock.
>
> So this should be an option. Thank you very much.


Yes the montonic clock should be the default.

> This is not possible without high end capture equipment to synchronise the
> > clocks on each camera. Everything else is guesswork.
>
> This is nonsense. The accuracy of a PC wall time clock with NTP is
> plenty accurate enough for most practical purposes.
>

You misunderstand greatly. How does the clock rate of NTP magically make
its way to the camera? It doesn't except in very high end setups where the
oscillator on the camera is drifted to match an external time source.

Kieran

Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

On Sun, 7 Feb 2021, 17:15 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > Yes the montonic clock should be the default.
>
> Changing the default is acceptable to me. Probably after a transition
> period.
>
> > You misunderstand greatly. How does the clock rate of NTP magically make
> > its way to the camera?
>
> I do not know, I do not care, I am not a driver developer. All I know is
> that the kernel can give me a timestamp based on the NTP-synchronized
> wall time clock, and that it has better than 1/100 second accuracy,
> which is plenty enough for must use cases.
>

You do care because different sources generated either by a PC or different
physical cameras will drift. E.g at 25fps after one hour you might get
9 frames from one and 90002 or whatever frames from another etc. And of
course the timestamps will drift slowly. Unfortunately you seem to share
the same fundamental misunderstandings as the kernel developers.

Applications like VLC and upipe have sophisticated filtering and drift
compensation to correct all of this.

Kieran

Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

On Sun, 7 Feb 2021, 17:29 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > You do care because different sources generated either by a PC or
> different
> > physical cameras will drift. E.g at 25fps after one hour you might get
> > 9 frames from one and 90002 or whatever frames from another etc. And
> of
> > course the timestamps will drift slowly. Unfortunately you seem to share
> > the same fundamental misunderstandings as the kernel developers.
>
> Your reasoning is backwards: different time bases is precisely the
> reason we need the option of timestamps with a common reference frame.
>
> With the situation you describe, the application that captures the two
> cameras can detect that one is faster than the other and duplicate or
> skip frames as necessary. Without a common timestamp, it is not
> possible.
>

Yes and thus you need a monotonic clock as a starting point for proper
filtering. Ffmpeg has neither.

Kieran


> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

Sent from my mobile device

On Sun, 7 Feb 2021, 17:35 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > Yes and thus you need a monotonic clock as a starting point for proper
> > filtering. Ffmpeg has neither.
>
> The kernel provides timestamps that are accurate enough. I do not
> understand why you insist on the contrary in the face of facts.
>
> Also, for a properly configured system, the wall time clock is
> monotonic.
>

This time can jump forward or backwards. It is trivial to do this. The
monotonic clock cannot do that.

Kieran

Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

On Sun, 7 Feb 2021, 18:34 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > This time can jump forward or backwards. It is trivial to do this.
>
> Not on a correctly configured system, it does not.
>

NTP is allowed to jump when it wants for example. It's not trivial for the
user to guarantee this.

> The monotonic clock cannot do that.
>
> The monotonic clock cannot synchronize from different computers.
>
> Each has limitations the other has not, this is why we need both as
> options. Because YOU do not know if the user's computers are correctly
> synchronized, YOU do not know if the user needs to synchronise between
> different computers. But the users knows. Hence the option. For the
> user, because the user knows.
>

Exactly, so by default you must give the user a clock which is guaranteed
not to jump as you don't know. If they need to synchronise between PCs
using your naive process they can choose gettimeofday. Hopefully they
understand the consequences of that unlike you. It's still a flawed process
because of timestamp jitter etc.

Kieran


Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

Sent from my mobile device

On Sun, 7 Feb 2021, 19:21 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > NTP is allowed to jump when it wants for example. It's not trivial for
> the
> > user to guarantee this.
>
> In practice, it does not.
>

Read the docs where it explains where it can jump.


> > Exactly, so by default you must give the user a clock which is guaranteed
> > not to jump as you don't know. If they need to synchronise between PCs
> > using your naive process they can choose gettimeofday.
>
> So why are you still arguing this?
>
> > Hopefully they understand the consequences of that unlike you. It's
> > still a flawed process because of timestamp jitter etc.
>
> I obviously understand the consequences better than you, since you did
> not even realize why the wall time clock was needed.
>

Your scenario is contrived. Its impossible to sync exactly between
different machines for all the reasons I explained and you didn't
understand.

I think this should be the end of the discussion.
>

Yes, since you are not interested in reading the NTP docs or understanding
the purpose of a monotonic clock.

Kieran


> Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

On Sun, 7 Feb 2021, 20:20 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > Your scenario is contrived. Its impossible to sync exactly between
> > different machines for all the reasons I explained and you didn't
> > understand.
>
> I understand very well. What you refuse to understand is that all this
> theoretical stuff does not matter. What matters is that in practice it
> works, full stop.
>


It doesn't work in practice.
It's why every Android phone captures video at 29.970fps ± jitter instead
of the correct 3/1001

Kieran


> Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/3] avdevice: use av_gettime_relative() for timestamps

[Kieran Kunhya]

Sent from my mobile device

On Sun, 7 Feb 2021, 20:27 Nicolas George,  wrote:

> Kieran Kunhya (12021-02-07):
> > It doesn't work in practice.
> > It's why every Android phone captures video at 29.970fps ± jitter instead
> > of the correct 3/1001
>
> Good enough for most uses. Let the user decide.
>

QED that you don't understand the problem whatsoever.

Kieran


> Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [RFC] Event loop

[Kieran Kunhya]

On Fri, 19 Feb 2021 at 17:41, Nicolas George  wrote:

> Lynne (12021-02-19):
> > You poll it in a busy loop in a thread in an event.
>
> Yeah. Events loop are supposed to avoid busy loops. So no.
>
> > Or you find a solution to use libuv's polling instead via a "hacker
> > solution".
>
> This is what I am asking: can you give a good solution with libuv? It
> seems you cannot.
>

I don't have a strong opinion on either. But I think you can use
container_of on the fd.

Kieran
___
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".

Re: [FFmpeg-devel] [RFC] Event loop

[Kieran Kunhya]

On Fri, 19 Feb 2021 at 19:04, Nicolas George  wrote:

> Kieran Kunhya (12021-02-19):
> > I don't have a strong opinion on either. But I think you can use
> > container_of on the fd.
>
> Thanks. I find no trace of it in the docs:
>
>
> http://docs.libuv.org/en/v1.x/search.html?q=container_of&check_keywords=yes&area=default
>
> Can you be a little more precise?
>
> The portability arguments have been compelling for libuv over libev, so
> if we find a way of getting libuv to work for our needs, it would be
> best.
>

Actually maybe you can't use container_of and mmap since the fd is not a
pointer...
Sorry for noise.

Kieran
___
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".

[FFmpeg-devel] Apple M1 Mac Mini Access

[Kieran Kunhya]

Hi,

Please email me privately with your ssh public key and desired username if
you would like access to the second Apple M1 Mac Mini which we bought for
development purposes.

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] Apple M1 Mac Mini Access

[Kieran Kunhya]

On Sun, 28 Feb 2021 at 13:30, Kieran Kunhya  wrote:

> Hi,
>
> Please email me privately with your ssh public key and desired username if
> you would like access to the second Apple M1 Mac Mini which we bought for
> development purposes.
>
> Regards,
> Kieran Kunhya
>

Everyone who has requested access should have it now.

Regards,
Kieran
___
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".

Re: [FFmpeg-devel] Fw: Question about FFmpeg's threading architecture

[Kieran Kunhya]

Hi,

On Tue, 23 Mar 2021 at 16:01, Alireza Heidar-Barghi <
arhdr-at-yahoo@ffmpeg.org> wrote:

>  Hello,
> I am wondering how I can obtain documentation on the detail of FFmpeg's
> threading architecture?
> Thank you in advance.
> Regards,
> Alireza
>

https://github.com/FFmpeg/FFmpeg/blob/master/doc/multithreading.txt

Kieran
___
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".

Re: [FFmpeg-devel] 4.4 Release Name

[Kieran Kunhya]

I would like to suggest:

https://en.m.wikipedia.org/wiki/Kizzmekia_Corbett

Sent from my mobile device

On Fri, 2 Apr 2021, 12:34 RADSL,  wrote:

>
> On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > We still need to choose the name for 4.4
> > previous unused suggestions where:
> > Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> Viterbi, Darwin
> >
> > Feel free to reply with name suggestions
> > If theres a tie then i will randomly pick amongth the tied, i assume all
> previous
> > suggestions where suggested exactly once already.
> >
> > I plan to make the release today or tomorrow unless major bugfixes are
> > still pending. I probably wont have time sunday / monday for making the
> > release
> >
> > Thanks
> >
> >
> version 4.4 Plandemic
>
> Sincerly
> ___
> 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".
___
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".

Re: [FFmpeg-devel] 4.4 Release Name

[Kieran Kunhya]

You seriously think it's worth joking about the deaths of 3 million people?

Kieran

Sent from my mobile device

On Sat, 3 Apr 2021, 11:02 Zane van Iperen,  wrote:

>
>
> On 3/4/21 6:53 pm, Michael Niedermayer wrote:
>
> >> Plandemic sounds cool.
> >
> > it does until you google what it refers too
> >
> > Do the people voting for that want FFmpeg to be associated with the
> movie(s) ?
>
> I'd be inclined to think of it as more of a bit of light-hearted humour in
> hard times rather than anything actually serious.
>
> If that's still too on-the-nose, how's "FFmpeg 4.4 - Corona"?
> ___
> 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".
___
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".

Re: [FFmpeg-devel] 4.4 Release Name

[Kieran Kunhya]

And you think "Corona" is better somehow?

Kieran

Sent from my mobile device

On Sat, 3 Apr 2021, 11:15 Zane van Iperen,  wrote:

>
>
> On 3/4/21 7:04 pm, Kieran Kunhya wrote:
> > You seriously think it's worth joking about the deaths of 3 million
> people?
> >
> > Kieran
> >
> > Sent from my mobile device
> >
>
> No, not at all - the joke is about the name "Plandemic", and how absurd it
> is.
> ___
> 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".
___
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".

Re: [FFmpeg-devel] 4.4 Release Name

[Kieran Kunhya]

Who are you and what on earth are you talking about?

Why on earth is it appropriate to name an ffmpeg release after a disease
that has killed millions?

Kieran

Sent from my mobile device

On Sat, 3 Apr 2021, 20:25 RADSL,  wrote:

>
> On 4/3/2021 8:11 AM, Derek Buitenhuis wrote:
> > On 03/04/2021 11:19, Jean-Baptiste Kempf wrote:
> >> This is Internet and social networks in 2021.
> >> It WILL be taken in the wrong way.
> >>
> >> Do NOT use anything political or related to the news in naming. Never
> Ever. It might be badly taken, but mostly you have NO idea how it will be
> taken in the future…
> > Agree.
> >
> > Frankly using such a name is disgusting and offensive.
> >
> > It's not a funny """joke""". People are dead.
> >
> > This is the exact kind of BS unfunny "humour" (giant quotes) that
> > people look down a the FOSS community for, and with good reason.
> >
> > - Derek
>
>  > Frankly using such a name is disgusting and offensive
> ???
>
>  > It's not a funny """joke"""
> it's a an homage, nothing else. if you take it as a "joke", it's your
> point of view only.
>
>  > This is the exact kind of BS unfunny "humour"
> who said it was humour? again it's only your point of view.
>
> only those who are blind cannot see the reality. and the reality is more
> people are dying from political decisions today.
> and I'm sorry to open this debate, but it concerns all of us since it
> affects all of us, even for thos who don't watch TV.
> ___
> 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".
___
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".

Re: [FFmpeg-devel] 4.4 Release Name

[Kieran Kunhya]

Hey code of conduct committee, can we ban this person?

Kieran

Sent from my mobile device

On Sat, 3 Apr 2021, 22:06 RADSL,  wrote:

>
> On 4/3/2021 12:47 PM, Kieran Kunhya wrote:
> > Who are you and what on earth are you talking about?
> >
> > Why on earth is it appropriate to name an ffmpeg release after a disease
> > that has killed millions?
> >
> > Kieran
> >
> > Sent from my mobile device
> >
> Is it appropriate to make sport shoes with human blood?
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'

[Kieran Kunhya]

On Thu, 30 Apr 2020 at 07:22, Roger Pack  wrote:

> > > c9153590e5f167e41910d867639eb887164e28d2
> 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > > From: rogerdpack 
> > > Date: Tue, 28 Apr 2020 05:15:15 +
> > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new
> codec
> > >  type of 'raw 608 byte pairs'
>

How does this content exist? Are you defining your own file format with the
byte pairs?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'

[Kieran Kunhya]

On Fri, 1 May 2020 at 04:59, Roger Pack  wrote:

> On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya  wrote:
> >
> > On Thu, 30 Apr 2020 at 07:22, Roger Pack  wrote:
> >
> > > > > c9153590e5f167e41910d867639eb887164e28d2
> > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00
> 2001
> > > > > From: rogerdpack 
> > > > > Date: Tue, 28 Apr 2020 05:15:15 +
> > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a
> new
> > > codec
> > > > >  type of 'raw 608 byte pairs'
> > >
> >
> > How does this content exist? Are you defining your own file format with
> the
> > byte pairs?
>
> It's transmitted as "raw byte pairs" by analog TV broadcast in the US.
> https://en.wikipedia.org/wiki/EIA-608 has  details.
>
> I believe it transmits  one closed caption character (or control code)
> per frame (basically a single byte pair on "line 21") so it can do 30
> closed caption chars/second.  Anyway that's where it's originating
> from.  Good question :)
>

Yes, but these byte pairs are usually in a container or exist in an
analogue waveform.
Have you defined your own format of "raw byte pairs"? That doesn't exist in
the wild as far as I know.

Kieran
___
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".

Re: [FFmpeg-devel] [RFC]separation of multiple outputs' encoding

[Kieran Kunhya]

On Mon, 18 May 2020 at 09:33, Anton Khirnov  wrote:

> Quoting Tao Zhang (2020-05-18 08:00:55)
> > If no more comments, I will try to code something to create a pseudo
> > encoder which run the actual encoding in the separate thread. Thanks
>
> I do not think it is a good idea to have the library compensate for
> deficiencies in the calling program.
>

Agreed, what is proposed is a huge hack.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] lavc/h264_cavlc: use inline function get_bits API

[Kieran Kunhya]

On Tue, 26 May 2020 at 15:14, Josh de Kock  wrote:

> To prepare for using the cached bitstream reader, which only defines the
> inline functions rather than the macros, with CAVLC decoding.
>
> Signed-off-by: Josh de Kock 


IMO you should provide cached reader benchmarks on real world CAVLC content
before pushing this patch.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 2/4] tools/target_dec_fuzzer: Do not test AV_CODEC_FLAG2_FAST with AV_CODEC_ID_H264

[Kieran Kunhya]

On Wed, 27 May 2020 at 22:53, Michael Niedermayer 
wrote:

> On Sun, Mar 15, 2020 at 10:20:56PM +0100, Michael Niedermayer wrote:
> > This combination skips allocating large padding which can read out of
> array
> >
> > Fixes:
> 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5746381832847360
> >
> > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tools/target_dec_fuzzer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> will apply
>

Shouldn't there be warnings about FAST mode if it causes security issues?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Kieran Kunhya]

>
> More generally though (outside this unsafe flag case)
> i do disagree with your argument a bit, performance does matter.
> Iam regularly reminded of that for example, so much software becomes
> slower on each upgrade with few if any features added the real users
> care about. Just to pick one, the editor i use to write replies in mutt
> is slower to close than before i upgraded the OS.
>
> Also again to stay general here, this does not apply to the unsafe flag.
> speed / cpu load does add up. Slower code means more CO2 emissions if
> the software is used alot.
> If you want a real example insetad of this flag where we could improve
> IIRC there was some code iterating over options in the iteration over
> options resulting in some sort of O(n^3) or so. Thats from memory though
> would need to check where that was exactly but thats something we should
> fix.
>

Please provide evidence that the H.264 Decoder has got slower.
Surely by your argument all your fuzzing fixes need an #ifdef to turn them
off to save CO2?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Kieran Kunhya]

On Fri, 29 May 2020 at 14:11, Michael Niedermayer 
wrote:

> On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote:
> > >
> > > More generally though (outside this unsafe flag case)
> > > i do disagree with your argument a bit, performance does matter.
> > > Iam regularly reminded of that for example, so much software becomes
> > > slower on each upgrade with few if any features added the real users
> > > care about. Just to pick one, the editor i use to write replies in mutt
> > > is slower to close than before i upgraded the OS.
> > >
> > > Also again to stay general here, this does not apply to the unsafe
> flag.
> > > speed / cpu load does add up. Slower code means more CO2 emissions if
> > > the software is used alot.
> > > If you want a real example insetad of this flag where we could improve
> > > IIRC there was some code iterating over options in the iteration over
> > > options resulting in some sort of O(n^3) or so. Thats from memory
> though
> > > would need to check where that was exactly but thats something we
> should
> > > fix.
> > >
> >
> > Please provide evidence that the H.264 Decoder has got slower.
>
> while, what you quote above was not about h264 at all
> let me provide benchmarks of most fate h264 samples with and without
> flag_unsafe
> the script that made that is after it. a reply to the 2nd part of your
> mail is
> also below
>

Yes, it's no surprise that a "fast" mode that violates the spec to produce
some undefined and unsafe output is going to be faster.
The responses are "aggressive" because many people want "fast" mode gone.

I also would like it gone and I think the consensus is there to remove it.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Kieran Kunhya]

On Mon, 1 Jun 2020 at 14:02, Anton Khirnov  wrote:

> Quoting Paul B Mahol (2020-05-29 18:46:18)
> > I see no aggression at all here.
>
> Same here. People have disagreeing opinions and are expressing them.
> That does not imply aggression or uncivility.
>

There is no aggression here.
If anything the long winded text about how anyone who wants this code
removed is creating CO2 emissions is passive-aggressive.

Kieran
___
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".

[FFmpeg-devel] [PATCH] avcodec: remove FLAG2_FAST mode

[Kieran Kunhya]

$subj


fasterthanlight.diff
Description: Binary data
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec: remove FLAG2_FAST mode

[Kieran Kunhya]

On Thu, 4 Jun 2020 at 00:05, Michael Niedermayer 
wrote:

> On Wed, Jun 03, 2020 at 06:23:27PM +0100, Kieran Kunhya wrote:
> > $subj
>
> >  fftools/ffplay.c   |5
> >  libavcodec/avcodec.h   |4
> >  libavcodec/h264_slice.c|6
> >  libavcodec/mpeg12dec.c |  273
> -
> >  libavcodec/options_table.h |1
> >  tools/target_dec_fuzzer.c  |2
> >  6 files changed, 291 deletions(-)
> > 7edbcba8bf53b74a9621b7e641b2b4b43ab2c79e  fasterthanlight.diff
> > From bb28e7f70dd77d13ea82aca73227f422af80ec7b Mon Sep 17 00:00:00 2001
> > From: Kieran Kunhya 
> > Date: Wed, 3 Jun 2020 18:21:28 +0100
> > Subject: [PATCH] avcodec: remove FLAG2_FAST mode
>
> I would like to keep this feature. And iam maintaining it.


If you are maintaining this feature, why does the code say that it will
crash on corrupt streams?
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpeg12dec.c#L224

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg12dec: Fix got_output

[Kieran Kunhya]

Needs some more explanation IMO

Sent from my mobile device

On Sun, 7 Jun 2020, 21:27 Michael Niedermayer, 
wrote:

> On Thu, May 28, 2020 at 02:12:34PM +0200, Michael Niedermayer wrote:
> > Fixes: assertion failure
> > Fixes:
> 22178/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5664234440753152
> >
> > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/mpeg12dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> will apply
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg12dec: Fix got_output

[Kieran Kunhya]

On Sun, 7 Jun 2020 at 23:33, Michael Niedermayer 
wrote:

> On Sun, Jun 07, 2020 at 11:07:13PM +0100, Kieran Kunhya wrote:
> > Needs some more explanation IMO
>
> If you look at the code which sets the outputed picture
> in slice_end()
> if (s->pict_type == AV_PICTURE_TYPE_B || s->low_delay) {
> int ret = av_frame_ref(pict, s->current_picture_ptr->f);
> ...
> } else {
>
> this patch just makes got_output consistent with that.
>
> ok if i add this to the commit message or where you thinking
> of some other explanation ?
>
> thx
>

Ok.

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] added sei side data

[Kieran Kunhya]

On Mon, 1 Jun 2020 at 22:23, Daniel Loman  wrote:

> Added seperate side data field to allow adding per packet side data
> message to support MISB 604 encoding
>

Are you aware that this is not going to be frame accurate for the non-SPS
frame because of reordering?

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] added sei side data

[Kieran Kunhya]

On Tue, 9 Jun 2020 at 22:26, Daniel Loman  wrote:

> KK>>Are you aware that this is not going to be frame accurate for the
> non-SPS
> KK>>frame because of reordering?
>
> reordering of the frame in terms of pts versus dts?
>
> these are attached to the AVPackets not AVFrame. They data should
> correspond with the pts of the packet. unless i am confused with what youre
> saying
>

 Ok. as long as you are aware PTS may not be in order.

Kieran
___
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".

Re: [FFmpeg-devel] release/4.3

[Kieran Kunhya]

>
> >> Against, release name as always should be George or Carl.
> >
> > Quit it.
>
> You are against my vote for release name?
> How unfortunate.
>

Give it a rest.
___
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".

Re: [FFmpeg-devel] [PATCH] codec_desc: mark CFHD as intra-only

[Kieran Kunhya]

>
> It still seems to me that this is a solution in search of a problem. If
> I understand you correctly, the case you have in mind is a codec where
> there is an internal implementation that only supports intra frames
> and an external implementation that also supports inter frames.
> But that seems incredibly contrived to me. For one thing, I don't know
> of any actual situations like this, now or in the past. For another, why
> pick out specifically the ability to decode intra vs inter frames?
> There is a huge number of codec features that may be potentially
> unsupported by various implementations (see e.g. AAC) and there's no
> sane way we can have capability flags for them all.
>

Hi,

I have no opinion on the issue at hand but this is currently the case with
Cineform.
The internal decoder supports the intra features but the open sourced one
from them supports intra/inter features.

Kieran
___
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".

[FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

[Kieran Kunhya]

Hello,

I have run the following commands on the following CPU which is 7 years old:
Intel(R) Xeon(R) CPU E3-1265L v3

ffmpeg_g -i matrixbench_mpeg2.mpg -f null -
and
ffmpeg_g -flags2 fast -i matrixbench_mpeg2.mpg -f null -

Here are the results:

Normal Fast
2202 2168
2155 2057
2210 2128
2104 2051
2132 2053
2035 2014
2021 2037
2247 1999
2095 2015
2232 2119
Mean 2143.3 2064.1
Stdev 79.82209385 55.9075626

It can therefore be shown that the difference is statistically
insignificant.

I would like to propose removing MPEG-2 fast mode.
Removing it also saves ~4KB on the stripped ffmpeg binary.

Regards,
Kieran Kunhya
___
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".

Re: [FFmpeg-devel] [PATCH] avformat: add MCC demuxer

[Kieran Kunhya]

>
> +if (av_sscanf(line, "%d:%d:%d:%d", &hh, &mm, &ss, &fs) != 4)
>
+continue;
>

Maybe worth a comment saying you're converting a timecode to a PTS here.
These are often not the same.

Kieran
___
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".

Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks

[Kieran Kunhya]

Hi,


> Problem 1
> you have a mean of around 2100 and Stdev of about between 55 and 80 so if
> by
> statistically significant you man 2 Stdev, then with the mean you have.
> You would declare every optimization of less than 6% to be statistically
> insignificant.
> So by what you say here, it seems to me you would have to suggest that
> every optimization which provides 6% or less overall speedup to be
> removed.
> That i doubt many will agree with
>

Logical fallacy.


> Problem 2
> We do not meassure speed this way because its not realiable nor practical
> just look at this, especially the difference and variation
> ./ffmpeg -threads 1 -i ~/videos/matrixbench_mpeg2.mpg -f null -
>8941 decicycles in non-intra, 2097003 runs,149 skipste=N/A
> speed=53.2x
>8941 decicycles in non-intra, 2097013 runs,139 skipste=N/A
> speed=54.1x
>8942 decicycles in non-intra, 2097038 runs,114 skipste=N/A
> speed=54.1x
>8970 decicycles in non-intra, 2097037 runs,115 skipste=N/A speed=
> 54x
>
> ./ffmpeg -threads 1 -flags2 fast -i ~/videos/matrixbench_mpeg2.mpg -f null
> -
>8718 decicycles in non-intra, 2097020 runs,132 skipste=N/A
> speed=54.6x
>8701 decicycles in non-intra, 2097044 runs,108 skipste=N/A
> speed=54.6x
>8718 decicycles in non-intra, 2097034 runs,118 skipste=N/A
> speed=54.5x
>8702 decicycles in non-intra, 2097029 runs,123 skipste=N/A
> speed=54.5x
>
> This difference is statistically significant, i can say this without the
> need
> to check
> Tested on a AMD Ryzen 9 3950X but i expect you will see similar on most
> CPUs
>

Did you remove the branch for FLAGS2_FAST and the large amount of inlined
code when making this measurement?
I also note that you just ignore mb_block_count in FLAGS2_FAST mode so this
is not a fair comparison.


> Problem 3
> You dont search for useless code, this is not a "i tested 100
> optimizations and found these not worth it"
> You search for an argument to remove specific pieces of my code.
> thats seriously not making sense to me. really not


I am not going to even try to respond to that as it clearly extends into
issues larger than FFmpeg.


> Problem 4
> try H264 using good old time
> time ./ffmpeg -thread_type slice -i fate-suite//h264/bbc2.sample.h264 -f
> null -
> real0m0,252s
> real0m0,254s
> real0m0,254s
> real0m0,255s
>
> time ./ffmpeg -flags2 fast  -thread_type slice -i
> fate-suite//h264/bbc2.sample.h264 -f null -
> real0m0,217s
> real0m0,220s
> real0m0,218s
> real0m0,217s
>
> Here even with a crude way of meassuring we can see a clear and strong
> difference
>

That's H.264, not MPEG-2, not relevant to this discussion. Is that file
even capable of using slice threading to decode?

Going back to the original point about MPEG-2, if a user chooses
FLAGS2_FAST, they expect it to make a major difference.
I had tested MPEG-2 expecting it to be much more significant but it is not.
Not 200 decicycles on a single function (making up your own dequant).

Kieran
___
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".

Re: [FFmpeg-devel] [PATCH] avformat/mov: fix demuxing of eia-608

[Kieran Kunhya]

On Sun, 14 Jun 2020 at 13:22, Paul B Mahol  wrote:

> Fixes #4616.
>
> Signed-off-by: Paul B Mahol 
>

LGTM
___
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".