Re: [FFmpeg-devel] [RFC PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Michael, Andreas,

On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
 wrote:
>
> Michael Niedermayer:
> > On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> >> Output the producer reference time to a dirty raw output.
> >>
> >> Signed-off-by: Clément Péron 
> >> ---
> >>  libavformat/rawenc.c | 122 +++
> >>  1 file changed, 122 insertions(+)
> >
> > this breaks fate-filter-volume and others
> > (Segmentation fault)
> >
> > I can rerun it with debug symbols and provide peoper gdb output
> > but i suspect given this has "HACK" in the title you are aware of this

The "HACK" tag meaning was not supposed to be: "it's ok if it
segfaults", but more to trigger a discussion is it possible to
properly support an output timestamp in the raw video demux, and if
yes how to do it :)

I consider this patch dirty and not upstreamable like this.

I thought about it during the night and would it be ok to add a
"raw_fmt" option.

-raw_fmt="prft:packet"
or
-raw_fmt="packet:prft"
or
-raw_fmt="prft" to only output the prft packet

If you have another idea I would be glad to hear it,
thanks

> >
>
> The reason is that this patch presumes that every user of
> ff_raw_write_packet() uses the newly added RawVideoContext as context,
> but that is just not true.

Thanks for the explanation, I will fix it in v2,

Clement

>
> - Andreas
>
> ___
> 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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Andreas Rheinhardt]

Clément Péron:
> Hi Michael, Andreas,
> 
> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
>  wrote:
>>
>> Michael Niedermayer:
>>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
 Output the producer reference time to a dirty raw output.

 Signed-off-by: Clément Péron 
 ---
  libavformat/rawenc.c | 122 +++
  1 file changed, 122 insertions(+)
>>>
>>> this breaks fate-filter-volume and others
>>> (Segmentation fault)
>>>
>>> I can rerun it with debug symbols and provide peoper gdb output
>>> but i suspect given this has "HACK" in the title you are aware of this
> 
> The "HACK" tag meaning was not supposed to be: "it's ok if it
> segfaults", but more to trigger a discussion is it possible to
> properly support an output timestamp in the raw video demux, and if
> yes how to do it :)

If you need a timestamp for raw video, then use a proper container and
not raw video. In fact, this patch basically creates new formats
different from all the raw formats.

- Andreas

___
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] TRAC Spam

[Michael Koch]

I'm not sure if I understood that right. If I add a keyword to the list 
on this page

https://trac.ffmpeg.org/wiki/BadContent
then any posting which contains this keyword will get a negative score?
And if the score exceeds a threshold, then the posting will be rejected?
Is this only for changes in the wiki, or also for comments in tickets?

By the way, in the above page the link to "Python syntax" is dead.

Michael



___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Andreas,

On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
 wrote:
>
> Clément Péron:
> > Hi Michael, Andreas,
> >
> > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> >  wrote:
> >>
> >> Michael Niedermayer:
> >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
>  Output the producer reference time to a dirty raw output.
> 
>  Signed-off-by: Clément Péron 
>  ---
>   libavformat/rawenc.c | 122 +++
>   1 file changed, 122 insertions(+)
> >>>
> >>> this breaks fate-filter-volume and others
> >>> (Segmentation fault)
> >>>
> >>> I can rerun it with debug symbols and provide peoper gdb output
> >>> but i suspect given this has "HACK" in the title you are aware of this
> >
> > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > segfaults", but more to trigger a discussion is it possible to
> > properly support an output timestamp in the raw video demux, and if
> > yes how to do it :)
>
> If you need a timestamp for raw video, then use a proper container and
> not raw video. In fact, this patch basically creates new formats
> different from all the raw formats.

Yes I agree, but I do not want to add too much overhead nor
computation processing or memory copy to my pipeline just to mux and
demux between ffmpeg and my python script.

The idea is to have a very light structure to easily pipe it.

I'm not familiar with audio/video container but it seems to me that
parsing containers are not very light no?

Thanks,
Clement


>
> - Andreas
>
> ___
> 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] TRAC Spam

[Michael Koch]

(?i)customer.?support
(?i)customer.?care
(?i)customer.?service

What's the meaning of (?i) and .?
I can't find that in Python syntax description.

Michael



___
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] TRAC Spam

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 10:00:39AM +0200, Michael Koch wrote:
> I'm not sure if I understood that right. If I add a keyword to the list on
> this page
> https://trac.ffmpeg.org/wiki/BadContent
> then any posting which contains this keyword will get a negative score?
> And if the score exceeds a threshold, then the posting will be rejected?

yes


> Is this only for changes in the wiki, or also for comments in tickets?

should be for everything


> 
> By the way, in the above page the link to "Python syntax" is dead.

you should be able to edit it
i dont know where to link to either without searching

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: PGP signature
___
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] TRAC Spam

[Diederick C. Niehorster]

On Fri, Sep 22, 2023 at 10:39 AM Michael Koch
 wrote:
>
> (?i)customer.?support
> (?i)customer.?care
> (?i)customer.?service
>
> What's the meaning of (?i) and .?
> I can't find that in Python syntax description.
>

This is regular expression syntax, not python syntax. There are some
nice online tools that show you what your regular expression will
match.

Cheers,
Dee
___
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] TRAC Spam

[Michael Koch]

Is it ok if I remove the dead link to Python syntax, and replace it by 
this link to Wikipedia?

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

Michael
___
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] MXF - Add jpeg2000 subdescriptor - Sponsored by INA

[Cédric Le Barz]

Le 04/06/2023 à 20:24, Tomas Härdin a écrit :

tor 2023-06-01 klockan 17:19 +0200 skrev Cédric Le Barz:

Attach to this mail, is my new patch for adding jpeg2000 sub-
descriptor
in MXF file  taking into account remarks from FFmpeg community
(remarks
from Pierre-Anthony above as well as this from Tomas), i.e. :

1 - When there is a mismatch in components number, this is now
process
as an error.

2 - When defining and using the J2K descriptor items, I now refer to
the
symbol name from the SMPTE registers (X0siz, XT0siz...)

3 - As suggested, I make use of  jpeg2000_read_main_headers() in
libavcodec. But, I let the parsing function in mxfenc.c file as all
other parsing functions are in this file (mxf_parse_mpeg2_frame,
mxf_parse_h264_frame...). The use of jpeg2000_read_main_headers() in
mxfenc implies some minor modifications in jpeg2000 files :

* rename of Jpeg2000Tile structure to J2kTile in j2kenc.c (to avoid
redefinition)

* move some structure declarations from jpeg2000dec.c to jpeg2000.h

* make jpeg2000_read_main_headers() function "public"

For this you need to prefix the name with ff_ and bump libavcodec's
minor version number


+static int mxf_parse_jpeg2000_frame(AVFormatContext *s, AVStream
*st, AVPacket *pkt)
+{
+MXFContext *mxf = s->priv_data;
+MXFStreamContext *sc = st->priv_data;
+int component_count = av_pix_fmt_count_planes(st->codecpar-

format);

+Jpeg2000DecoderContext jpeg2000ctx;

This makes sizeof(Jpeg2000DecoderContext) part of the public API which
is a big no-no. Consider making the fields part of a different smaller
struct instead that is also included in Jpeg2000DecoderContext. The
safest option is to have a function that allocates that struct. The
reason for this is because we might want to read other things from the
headers at a later date. Another possibility is to pass a bunch of
pointers to ints that the parsed values get written to. If at a later
date we need to parse more fields then we can introduce
ff_jpeg2000_read_main_headers_2() and so on. The latter seems easier
API stability wise, if a bit tedious with the number of function
arguments.

/Tomas

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Hi,

I'm facing a problem to get the jpeg2000 information I need to build the 
mxf file.


All the functions to extract jpeg2000 information exist : they are 
located in libavcodec side and used Jpeg2000DecoderContext, which is not 
obviously public and therefore unknown from libavformat side.


Is there a way to get a pointer on the Jpeg2000DecoderContext (at least 
a void*) from libavcodec side ?


Thanks for your help.

Cédric



___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Paul B Mahol]

On Fri, Sep 22, 2023 at 10:38 AM Clément Péron  wrote:

> Hi Andreas,
>
> On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
>  wrote:
> >
> > Clément Péron:
> > > Hi Michael, Andreas,
> > >
> > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > >  wrote:
> > >>
> > >> Michael Niedermayer:
> > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> >  Output the producer reference time to a dirty raw output.
> > 
> >  Signed-off-by: Clément Péron 
> >  ---
> >   libavformat/rawenc.c | 122
> +++
> >   1 file changed, 122 insertions(+)
> > >>>
> > >>> this breaks fate-filter-volume and others
> > >>> (Segmentation fault)
> > >>>
> > >>> I can rerun it with debug symbols and provide peoper gdb output
> > >>> but i suspect given this has "HACK" in the title you are aware of
> this
> > >
> > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > segfaults", but more to trigger a discussion is it possible to
> > > properly support an output timestamp in the raw video demux, and if
> > > yes how to do it :)
> >
> > If you need a timestamp for raw video, then use a proper container and
> > not raw video. In fact, this patch basically creates new formats
> > different from all the raw formats.
>
> Yes I agree, but I do not want to add too much overhead nor
> computation processing or memory copy to my pipeline just to mux and
> demux between ffmpeg and my python script.
>
> The idea is to have a very light structure to easily pipe it.
>
> I'm not familiar with audio/video container but it seems to me that
> parsing containers are not very light no?
>
>
Containers range from almost no processing like .y4m to complex monsters
like .mxf

This patch is hack and approach/solution it tries is flawed.


> Thanks,
> Clement
>
>
> >
> > - Andreas
> >
> > ___
> > 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] [RFC] Release 6.1

[Michael Niedermayer]

On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-07-07 17:06:54)
> > Hi
> > 
> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > > It's been a while since we've had a release, and we've had
> > > a lot of new features in.
> > > We did say we would make releases more often, and I think
> > > it's about time we have a new release.
> > 
> > yes
> > 
> > 
> > > 
> > > Anything anyone wants to have merged or should we branch
> > > off 6.1 in a few days?
> > 
> > libavradio needs testing, at least build testing.
> > all parts of git master are tested automatically by our user base
> > but anything in seperate repositories might receive less testing
> > so we should encourage people to test these seperate repositories
> > for the release
> > 
> > also note iam quite busy ATM, its not the best time for me to
> > do 6.1, so "in a few days" is a bit too optimistic i think
> 
> How is libavradio related to the release?

Right, thats a valid question
when i wrote the SDR code it seemed to me that including it in 6.1 was
very simple. But as then some people tried to block SDR by any means
(blocking patches randomly, asking for moving it into a seperate libraray
 while not replying to any questions about that libraray and so on)
that made libavradio now have much more strings attached
then the original simple self contained input device
secondary, i lost the will to really work on FFmpeg around the time
of these attacks, so even without SDR i had limited motivation
and then more things that should be in 6.1 accumulated and summer and
good waether ...
And noone else took up the accumulating work either ...

Now the SDR + blockings is solved by not including any SDR that the
community doesnt like in 6.1 but instead me simply making a seperate
release with SDR, or so i thought. It seems given the replies I seem
to have touched some nerve here too

The idea was really just, that i said ill include SDR and i want to
keep this word so i want our users to have that 6.1 with SDR that i
promised and also have everyone happy about 6.1 and the long term
design of the SDR code.
I have some more comments about the seperate libraray and SDR but
thats better in a seperate mail in the future.

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



signature.asc
Description: PGP signature
___
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] Release 6.1

[Paul B Mahol]

On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer 
wrote:

> On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-07-07 17:06:54)
> > > Hi
> > >
> > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > > > It's been a while since we've had a release, and we've had
> > > > a lot of new features in.
> > > > We did say we would make releases more often, and I think
> > > > it's about time we have a new release.
> > >
> > > yes
> > >
> > >
> > > >
> > > > Anything anyone wants to have merged or should we branch
> > > > off 6.1 in a few days?
> > >
> > > libavradio needs testing, at least build testing.
> > > all parts of git master are tested automatically by our user base
> > > but anything in seperate repositories might receive less testing
> > > so we should encourage people to test these seperate repositories
> > > for the release
> > >
> > > also note iam quite busy ATM, its not the best time for me to
> > > do 6.1, so "in a few days" is a bit too optimistic i think
> >
> > How is libavradio related to the release?
>
> Right, thats a valid question
> when i wrote the SDR code it seemed to me that including it in 6.1 was
> very simple. But as then some people tried to block SDR by any means
> (blocking patches randomly, asking for moving it into a seperate libraray
>  while not replying to any questions about that libraray and so on)
> that made libavradio now have much more strings attached
> then the original simple self contained input device
> secondary, i lost the will to really work on FFmpeg around the time
> of these attacks, so even without SDR i had limited motivation
> and then more things that should be in 6.1 accumulated and summer and
> good waether ...
> And noone else took up the accumulating work either ...
>

What accumulating work? The SDR work for certainly nobody else wants to
pick, except maybe Peter.
If you mean real FFmpeg work, than by all means give access to services
only you have to other
interesting parties, like security related reports and others.


>
> Now the SDR + blockings is solved by not including any SDR that the
> community doesnt like in 6.1 but instead me simply making a seperate
> release with SDR, or so i thought. It seems given the replies I seem
> to have touched some nerve here too
>
> The idea was really just, that i said ill include SDR and i want to
> keep this word so i want our users to have that 6.1 with SDR that i
> promised and also have everyone happy about 6.1 and the long term
> design of the SDR code.
> I have some more comments about the seperate libraray and SDR but
> thats better in a seperate mail in the future.
>


Thank you for all hard FFmpeg related work, hope your continuing work on
your SDR hobby related projects.


>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "You are 36 times more likely to die in a bathtub than at the hands of a
> terrorist. Also, you are 2.5 times more likely to become a president and
> 2 times more likely to become an astronaut, than to die in a terrorist
> attack." -- Thoughty2
>
> ___
> 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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Andreas Rheinhardt]

Clément Péron:
> Hi Andreas,
> 
> On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
>  wrote:
>>
>> Clément Péron:
>>> Hi Michael, Andreas,
>>>
>>> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
>>>  wrote:

 Michael Niedermayer:
> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
>> Output the producer reference time to a dirty raw output.
>>
>> Signed-off-by: Clément Péron 
>> ---
>>  libavformat/rawenc.c | 122 +++
>>  1 file changed, 122 insertions(+)
>
> this breaks fate-filter-volume and others
> (Segmentation fault)
>
> I can rerun it with debug symbols and provide peoper gdb output
> but i suspect given this has "HACK" in the title you are aware of this
>>>
>>> The "HACK" tag meaning was not supposed to be: "it's ok if it
>>> segfaults", but more to trigger a discussion is it possible to
>>> properly support an output timestamp in the raw video demux, and if
>>> yes how to do it :)
>>
>> If you need a timestamp for raw video, then use a proper container and
>> not raw video. In fact, this patch basically creates new formats
>> different from all the raw formats.
> 
> Yes I agree, but I do not want to add too much overhead nor
> computation processing or memory copy to my pipeline just to mux and
> demux between ffmpeg and my python script.
> 
> The idea is to have a very light structure to easily pipe it.
> 

Our libraries are meant to be used by API users and are designed for
that. The ffmpeg command line tool is just one user among many and
adding code to a library to circumvent a limitation of ffmpeg (or
another user of the libraries) is not appropriate. We would end up with
a ton of hacks.

> I'm not familiar with audio/video container but it seems to me that
> parsing containers are not very light no?

For certain formats the overhead of parsing containers can be negative
when compared to the raw format, because the containers provide a length
field for the packet whereas one has to search for the packet boundaries
in case of a truely raw stream. But this is not true for raw video which
is fixed size.

- Andreas

___
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] Release 6.1

[Nicolas George]

Michael Niedermayer (12023-09-22):
> Now the SDR + blockings is solved by not including any SDR that the
> community doesnt like in 6.1 but instead me simply making a seperate
> release with SDR, or so i thought.

I strongly suggest you just refuse to make any release that do not
include SDR. If somebody wants it, let them do the work.

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

Re: [FFmpeg-devel] [RFC PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Paul

On Fri, 22 Sept 2023 at 11:27, Paul B Mahol  wrote:
>
> On Fri, Sep 22, 2023 at 10:38 AM Clément Péron  wrote:
>
> > Hi Andreas,
> >
> > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> >  wrote:
> > >
> > > Clément Péron:
> > > > Hi Michael, Andreas,
> > > >
> > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > > >  wrote:
> > > >>
> > > >> Michael Niedermayer:
> > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> > >  Output the producer reference time to a dirty raw output.
> > > 
> > >  Signed-off-by: Clément Péron 
> > >  ---
> > >   libavformat/rawenc.c | 122
> > +++
> > >   1 file changed, 122 insertions(+)
> > > >>>
> > > >>> this breaks fate-filter-volume and others
> > > >>> (Segmentation fault)
> > > >>>
> > > >>> I can rerun it with debug symbols and provide peoper gdb output
> > > >>> but i suspect given this has "HACK" in the title you are aware of
> > this
> > > >
> > > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > > segfaults", but more to trigger a discussion is it possible to
> > > > properly support an output timestamp in the raw video demux, and if
> > > > yes how to do it :)
> > >
> > > If you need a timestamp for raw video, then use a proper container and
> > > not raw video. In fact, this patch basically creates new formats
> > > different from all the raw formats.
> >
> > Yes I agree, but I do not want to add too much overhead nor
> > computation processing or memory copy to my pipeline just to mux and
> > demux between ffmpeg and my python script.
> >
> > The idea is to have a very light structure to easily pipe it.
> >
> > I'm not familiar with audio/video container but it seems to me that
> > parsing containers are not very light no?
> >
> >
> Containers range from almost no processing like .y4m to complex monsters
> like .mxf

.y4m doesn't contain a timestamp either, and I don't want to use a
complex container :),

>
> This patch is hack and approach/solution it tries is flawed.

100% agree with you that's why I prefix the patch with "HACK:",

Regards,
Clement


>
>
> > Thanks,
> > Clement
> >
> >
> > >
> > > - Andreas
> > >
> > > ___
> > > 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".
___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Andreas,

On Fri, 22 Sept 2023 at 12:01, Andreas Rheinhardt
 wrote:
>
> Clément Péron:
> > Hi Andreas,
> >
> > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> >  wrote:
> >>
> >> Clément Péron:
> >>> Hi Michael, Andreas,
> >>>
> >>> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> >>>  wrote:
> 
>  Michael Niedermayer:
> > On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> >> Output the producer reference time to a dirty raw output.
> >>
> >> Signed-off-by: Clément Péron 
> >> ---
> >>  libavformat/rawenc.c | 122 +++
> >>  1 file changed, 122 insertions(+)
> >
> > this breaks fate-filter-volume and others
> > (Segmentation fault)
> >
> > I can rerun it with debug symbols and provide peoper gdb output
> > but i suspect given this has "HACK" in the title you are aware of this
> >>>
> >>> The "HACK" tag meaning was not supposed to be: "it's ok if it
> >>> segfaults", but more to trigger a discussion is it possible to
> >>> properly support an output timestamp in the raw video demux, and if
> >>> yes how to do it :)
> >>
> >> If you need a timestamp for raw video, then use a proper container and
> >> not raw video. In fact, this patch basically creates new formats
> >> different from all the raw formats.
> >
> > Yes I agree, but I do not want to add too much overhead nor
> > computation processing or memory copy to my pipeline just to mux and
> > demux between ffmpeg and my python script.
> >
> > The idea is to have a very light structure to easily pipe it.
> >
>
> Our libraries are meant to be used by API users and are designed for
> that. The ffmpeg command line tool is just one user among many and
> adding code to a library to circumvent a limitation of ffmpeg (or
> another user of the libraries) is not appropriate. We would end up with
> a ton of hacks.

Yes I agree and maybe the final solution for this is "keep a fork of
FFMpeg with your patch on your side",

But my idea is could introducing a "raw-format user-defined" would be
acceptable or will it be considered a hack?

like we pass the pix_fmt why not passing a raw_fmt to specify the raw
output format? It will default to only "packet" but a user could add
other metadata if wanted.


>
> > I'm not familiar with audio/video container but it seems to me that
> > parsing containers are not very light no?
>
> For certain formats the overhead of parsing containers can be negative
> when compared to the raw format, because the containers provide a length
> field for the packet whereas one has to search for the packet boundaries
> in case of a truely raw stream. But this is not true for raw video which
> is fixed size.

Yes, good point, in my case I have a fixed size raw video.

Thanks for your comments,
Regards,
Clement

>
> - Andreas
>
> ___
> 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] TRAC Spam

[Hendrik Leppkes]

On Fri, Sep 22, 2023 at 11:14 AM Michael Koch
 wrote:
>
> Is it ok if I remove the dead link to Python syntax, and replace it by
> this link to Wikipedia?
> https://en.wikipedia.org/wiki/Regular_expression
>

A more accurate page would probably to just point to the correct
python regex docs, eg:
https://docs.python.org/2.7/library/re.html
___
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] TRAC Spam

[Michael Koch]

I just updated the dead link, also added the link to Wikipedia, added 
some keywords for our favourite spammer, and added short descriptions 
what (?i) and .? means.


Michael
___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Andreas Rheinhardt]

Clément Péron:
> Hi Andreas,
> 
> On Fri, 22 Sept 2023 at 12:01, Andreas Rheinhardt
>  wrote:
>>
>> Clément Péron:
>>> Hi Andreas,
>>>
>>> On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
>>>  wrote:

 Clément Péron:
> Hi Michael, Andreas,
>
> On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
>  wrote:
>>
>> Michael Niedermayer:
>>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
 Output the producer reference time to a dirty raw output.

 Signed-off-by: Clément Péron 
 ---
  libavformat/rawenc.c | 122 +++
  1 file changed, 122 insertions(+)
>>>
>>> this breaks fate-filter-volume and others
>>> (Segmentation fault)
>>>
>>> I can rerun it with debug symbols and provide peoper gdb output
>>> but i suspect given this has "HACK" in the title you are aware of this
>
> The "HACK" tag meaning was not supposed to be: "it's ok if it
> segfaults", but more to trigger a discussion is it possible to
> properly support an output timestamp in the raw video demux, and if
> yes how to do it :)

 If you need a timestamp for raw video, then use a proper container and
 not raw video. In fact, this patch basically creates new formats
 different from all the raw formats.
>>>
>>> Yes I agree, but I do not want to add too much overhead nor
>>> computation processing or memory copy to my pipeline just to mux and
>>> demux between ffmpeg and my python script.
>>>
>>> The idea is to have a very light structure to easily pipe it.
>>>
>>
>> Our libraries are meant to be used by API users and are designed for
>> that. The ffmpeg command line tool is just one user among many and
>> adding code to a library to circumvent a limitation of ffmpeg (or
>> another user of the libraries) is not appropriate. We would end up with
>> a ton of hacks.
> 
> Yes I agree and maybe the final solution for this is "keep a fork of
> FFMpeg with your patch on your side",
> 

Yes, that is the likely outcome.

> But my idea is could introducing a "raw-format user-defined" would be
> acceptable or will it be considered a hack?
> 
> like we pass the pix_fmt why not passing a raw_fmt to specify the raw
> output format? It will default to only "packet" but a user could add
> other metadata if wanted.

This would require us to add hacks and introduce new container formats
instead of you simply using one of the already existing containers.

- Andreas

___
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 PATCH 1/2] libavdevice/pipewiregrab: add pipewire based grab

[llyyr]

On 9/21/23 00:10, Abhishek Ojha wrote:

This is an proof of concept for pipewire grab to enable screen capture
on wayland. Add a new Linux capture based on [1] PipeWire and the
[2] Desktop portal.
This new capture starts by asking the Desktop portal for a screencapture
session.There are quite a few D-Bus calls involved in this, but the key
points are:

1. A connection to org.freedesktop.portal.ScreenCast is estabilished,
and the available cursor modes are updated. Currently only embedded
and hidden currsor mode enabled.

2. Call CreateSession via dbus call. This is the first step of the
communication. Response callback return the status of created
session.

3. Call SelectSources . This is when a system dialog pops up asking
the user to either select a monitor (desktop capture).Only monitor
capture is enabled in current implementation.

4. Call Start . This signals the compositor that it can setup a PipeWire
stream, and start sending buffers.

Above flow is implemented as per the [2] xdg-desktop-portal. Once flow
is completed, pipewire fd is received and using this pipewire stream is
created and receive buffer from the created stream.

For cursor implementation, embedded cursor mode is enabled that means
cursor metadata is not handled in current implementation and has no
control over the cursor bitmap.

gdbus/pipewire logic, this is based on obs-xdg, gstpipewire and
pipewire examples, and initial pipewire grab logic, this is based on
libavdevice/xcbgrab and libavdevice/v4l2

This implementation shows the skeleton implementation and enables basic
functionality. I'd like to hear opinions and suggestions to improve and
properly use this.

[1] https://pipewire.org/
[2] https://github.com/flatpak/xdg-desktop-portal/

Below are the arguments for pipewiregrab.
ffplay -f pipewiregrab -draw_mouse 1 -i :0.0

Signed-off-by: Abhishek Ojha 
---
  configure  |9 +
  libavdevice/Makefile   |1 +
  libavdevice/alldevices.c   |1 +
  libavdevice/pipewiregrab.c | 1836 
  4 files changed, 1847 insertions(+)
  create mode 100644 libavdevice/pipewiregrab.c

diff --git a/configure b/configure
index e40dcce09e..325b10484f 100755
--- a/configure
+++ b/configure
@@ -299,6 +299,7 @@ External library support:
--enable-libxcb-shm  enable X11 grabbing shm communication [autodetect]
--enable-libxcb-xfixes   enable X11 grabbing mouse rendering [autodetect]
--enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
+  --enable-libpipewire enable screen grabbing using pipewire [autodetect]
--enable-libxvid enable Xvid encoding via xvidcore,
 native MPEG-4/Xvid encoder exists [no]
--enable-libxml2 enable XML parsing using the C library libxml2, 
needed
@@ -1788,6 +1789,8 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
  libxcb_shm
  libxcb_shape
  libxcb_xfixes
+libpipewire
+libgio_unix
  lzma
  mediafoundation
  metal
@@ -3621,6 +3624,7 @@ v4l2_outdev_suggest="libv4l2"
  vfwcap_indev_deps="vfw32 vfwcap_defines"
  xcbgrab_indev_deps="libxcb"
  xcbgrab_indev_suggest="libxcb_shm libxcb_shape libxcb_xfixes"
+pipewiregrab_indev_deps="libpipewire libgio_unix pthreads"
  xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
  
  # protocols

@@ -7041,6 +7045,11 @@ if enabled libxcb; then
  enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
  fi
  
+enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 0.3.40" pipewire/pipewire.h pw_init

+if enabled libpipewire; then
+enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
+fi
+
I just tried this and it failed to build due to missing locale_t and 
other locale related issues in pipewire's spa library. Upon further 
inspection, it seems Pipewire wants _XOPEN_SOURCE=700 but ffmpeg's 
configure sets _XOPEN_SOURCE=600. Not sure who's at fault here but I was 
able to get it to build after explicitly setting that.

___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Paul B Mahol]

On Fri, Sep 22, 2023 at 12:06 PM Clément Péron  wrote:

> Hi Paul
>
> On Fri, 22 Sept 2023 at 11:27, Paul B Mahol  wrote:
> >
> > On Fri, Sep 22, 2023 at 10:38 AM Clément Péron 
> wrote:
> >
> > > Hi Andreas,
> > >
> > > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> > >  wrote:
> > > >
> > > > Clément Péron:
> > > > > Hi Michael, Andreas,
> > > > >
> > > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > > > >  wrote:
> > > > >>
> > > > >> Michael Niedermayer:
> > > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> > > >  Output the producer reference time to a dirty raw output.
> > > > 
> > > >  Signed-off-by: Clément Péron 
> > > >  ---
> > > >   libavformat/rawenc.c | 122
> > > +++
> > > >   1 file changed, 122 insertions(+)
> > > > >>>
> > > > >>> this breaks fate-filter-volume and others
> > > > >>> (Segmentation fault)
> > > > >>>
> > > > >>> I can rerun it with debug symbols and provide peoper gdb output
> > > > >>> but i suspect given this has "HACK" in the title you are aware of
> > > this
> > > > >
> > > > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > > > segfaults", but more to trigger a discussion is it possible to
> > > > > properly support an output timestamp in the raw video demux, and if
> > > > > yes how to do it :)
> > > >
> > > > If you need a timestamp for raw video, then use a proper container
> and
> > > > not raw video. In fact, this patch basically creates new formats
> > > > different from all the raw formats.
> > >
> > > Yes I agree, but I do not want to add too much overhead nor
> > > computation processing or memory copy to my pipeline just to mux and
> > > demux between ffmpeg and my python script.
> > >
> > > The idea is to have a very light structure to easily pipe it.
> > >
> > > I'm not familiar with audio/video container but it seems to me that
> > > parsing containers are not very light no?
> > >
> > >
> > Containers range from almost no processing like .y4m to complex monsters
> > like .mxf
>
> .y4m doesn't contain a timestamp either, and I don't want to use a
> complex container :),
>

I doubt storing clock time in container for each frame is correct approach.
Is this variable frame rate video?

One can always add another, trivial container with just one field having
whatever you want and with optional magic string in header.

Or can try/explore NUT container in FFmpeg.


>
> >
> > This patch is hack and approach/solution it tries is flawed.
>
> 100% agree with you that's why I prefix the patch with "HACK:",
>
> Regards,
> Clement
>
>
> >
> >
> > > Thanks,
> > > Clement
> > >
> > >
> > > >
> > > > - Andreas
> > > >
> > > > ___
> > > > 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".
> ___
> 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] Release 6.1

[Paul B Mahol]

On Fri, Sep 22, 2023 at 12:04 PM Nicolas George  wrote:

> Michael Niedermayer (12023-09-22):
> > Now the SDR + blockings is solved by not including any SDR that the
> > community doesnt like in 6.1 but instead me simply making a seperate
> > release with SDR, or so i thought.
>
> I strongly suggest you just refuse to make any release that do not
> include SDR. If somebody wants it, let them do the work.
>

Agreed, I want to be release maintainer.


>
> 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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Andreas,

On Fri, 22 Sept 2023 at 13:33, Andreas Rheinhardt
 wrote:
>
> Clément Péron:
> > Hi Andreas,
> >
> > On Fri, 22 Sept 2023 at 12:01, Andreas Rheinhardt
> >  wrote:
> >>
> >> Clément Péron:
> >>> Hi Andreas,
> >>>
> >>> On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> >>>  wrote:
> 
>  Clément Péron:
> > Hi Michael, Andreas,
> >
> > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> >  wrote:
> >>
> >> Michael Niedermayer:
> >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
>  Output the producer reference time to a dirty raw output.
> 
>  Signed-off-by: Clément Péron 
>  ---
>   libavformat/rawenc.c | 122 
>  +++
>   1 file changed, 122 insertions(+)
> >>>
> >>> this breaks fate-filter-volume and others
> >>> (Segmentation fault)
> >>>
> >>> I can rerun it with debug symbols and provide peoper gdb output
> >>> but i suspect given this has "HACK" in the title you are aware of this
> >
> > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > segfaults", but more to trigger a discussion is it possible to
> > properly support an output timestamp in the raw video demux, and if
> > yes how to do it :)
> 
>  If you need a timestamp for raw video, then use a proper container and
>  not raw video. In fact, this patch basically creates new formats
>  different from all the raw formats.
> >>>
> >>> Yes I agree, but I do not want to add too much overhead nor
> >>> computation processing or memory copy to my pipeline just to mux and
> >>> demux between ffmpeg and my python script.
> >>>
> >>> The idea is to have a very light structure to easily pipe it.
> >>>
> >>
> >> Our libraries are meant to be used by API users and are designed for
> >> that. The ffmpeg command line tool is just one user among many and
> >> adding code to a library to circumvent a limitation of ffmpeg (or
> >> another user of the libraries) is not appropriate. We would end up with
> >> a ton of hacks.
> >
> > Yes I agree and maybe the final solution for this is "keep a fork of
> > FFMpeg with your patch on your side",
> >
>
> Yes, that is the likely outcome.
>
> > But my idea is could introducing a "raw-format user-defined" would be
> > acceptable or will it be considered a hack?
> >
> > like we pass the pix_fmt why not passing a raw_fmt to specify the raw
> > output format? It will default to only "packet" but a user could add
> > other metadata if wanted.
>
> This would require us to add hacks and introduce new container formats
> instead of you simply using one of the already existing containers.

I could propose it, if it's an acceptable solution and could also help
other users.

Regards,

>
> - Andreas
>
> ___
> 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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Paul,

On Fri, 22 Sept 2023 at 13:41, Paul B Mahol  wrote:
>
> On Fri, Sep 22, 2023 at 12:06 PM Clément Péron  wrote:
>
> > Hi Paul
> >
> > On Fri, 22 Sept 2023 at 11:27, Paul B Mahol  wrote:
> > >
> > > On Fri, Sep 22, 2023 at 10:38 AM Clément Péron 
> > wrote:
> > >
> > > > Hi Andreas,
> > > >
> > > > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> > > >  wrote:
> > > > >
> > > > > Clément Péron:
> > > > > > Hi Michael, Andreas,
> > > > > >
> > > > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > > > > >  wrote:
> > > > > >>
> > > > > >> Michael Niedermayer:
> > > > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron wrote:
> > > > >  Output the producer reference time to a dirty raw output.
> > > > > 
> > > > >  Signed-off-by: Clément Péron 
> > > > >  ---
> > > > >   libavformat/rawenc.c | 122
> > > > +++
> > > > >   1 file changed, 122 insertions(+)
> > > > > >>>
> > > > > >>> this breaks fate-filter-volume and others
> > > > > >>> (Segmentation fault)
> > > > > >>>
> > > > > >>> I can rerun it with debug symbols and provide peoper gdb output
> > > > > >>> but i suspect given this has "HACK" in the title you are aware of
> > > > this
> > > > > >
> > > > > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > > > > segfaults", but more to trigger a discussion is it possible to
> > > > > > properly support an output timestamp in the raw video demux, and if
> > > > > > yes how to do it :)
> > > > >
> > > > > If you need a timestamp for raw video, then use a proper container
> > and
> > > > > not raw video. In fact, this patch basically creates new formats
> > > > > different from all the raw formats.
> > > >
> > > > Yes I agree, but I do not want to add too much overhead nor
> > > > computation processing or memory copy to my pipeline just to mux and
> > > > demux between ffmpeg and my python script.
> > > >
> > > > The idea is to have a very light structure to easily pipe it.
> > > >
> > > > I'm not familiar with audio/video container but it seems to me that
> > > > parsing containers are not very light no?
> > > >
> > > >
> > > Containers range from almost no processing like .y4m to complex monsters
> > > like .mxf
> >
> > .y4m doesn't contain a timestamp either, and I don't want to use a
> > complex container :),
> >
>
> I doubt storing clock time in container for each frame is correct approach.
> Is this variable frame rate video?

Why would it not? The python takes as an input a list of frames.
It then runs an inference model on it and could discard some frames if needed.
Taking the absolute timestamp of each frame avoids relying on a
supposed frame rate (based on a free running clock) that is not
guaranteed.
Also the result gives inference results which are properly timestamped
with the correct data acquisition time and I can easily resynchronize
with other sensor acquisition.

>
> One can always add another, trivial container with just one field having
> whatever you want and with optional magic string in header.

Yes, if this is acceptable by FFMpeg community I could propose a
trivial container where the format is user defined.
Else I can keep this dirty patch downstream, but I'm not a big fan.

Regards,

>
> Or can try/explore NUT container in FFmpeg.
>
>
> >
> > >
> > > This patch is hack and approach/solution it tries is flawed.
> >
> > 100% agree with you that's why I prefix the patch with "HACK:",
> >
> > Regards,
> > Clement
> >
> >
> > >
> > >
> > > > Thanks,
> > > > Clement
> > > >
> > > >
> > > > >
> > > > > - Andreas
> > > > >
> > > > > ___
> > > > > 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".
> > ___
> > 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,

Re: [FFmpeg-devel] [RFC PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Paul B Mahol]

On Fri, Sep 22, 2023 at 2:39 PM Clément Péron  wrote:

> Hi Paul,
>
> On Fri, 22 Sept 2023 at 13:41, Paul B Mahol  wrote:
> >
> > On Fri, Sep 22, 2023 at 12:06 PM Clément Péron 
> wrote:
> >
> > > Hi Paul
> > >
> > > On Fri, 22 Sept 2023 at 11:27, Paul B Mahol  wrote:
> > > >
> > > > On Fri, Sep 22, 2023 at 10:38 AM Clément Péron  >
> > > wrote:
> > > >
> > > > > Hi Andreas,
> > > > >
> > > > > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> > > > >  wrote:
> > > > > >
> > > > > > Clément Péron:
> > > > > > > Hi Michael, Andreas,
> > > > > > >
> > > > > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > > > > > >  wrote:
> > > > > > >>
> > > > > > >> Michael Niedermayer:
> > > > > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron
> wrote:
> > > > > >  Output the producer reference time to a dirty raw output.
> > > > > > 
> > > > > >  Signed-off-by: Clément Péron 
> > > > > >  ---
> > > > > >   libavformat/rawenc.c | 122
> > > > > +++
> > > > > >   1 file changed, 122 insertions(+)
> > > > > > >>>
> > > > > > >>> this breaks fate-filter-volume and others
> > > > > > >>> (Segmentation fault)
> > > > > > >>>
> > > > > > >>> I can rerun it with debug symbols and provide peoper gdb
> output
> > > > > > >>> but i suspect given this has "HACK" in the title you are
> aware of
> > > > > this
> > > > > > >
> > > > > > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > > > > > segfaults", but more to trigger a discussion is it possible to
> > > > > > > properly support an output timestamp in the raw video demux,
> and if
> > > > > > > yes how to do it :)
> > > > > >
> > > > > > If you need a timestamp for raw video, then use a proper
> container
> > > and
> > > > > > not raw video. In fact, this patch basically creates new formats
> > > > > > different from all the raw formats.
> > > > >
> > > > > Yes I agree, but I do not want to add too much overhead nor
> > > > > computation processing or memory copy to my pipeline just to mux
> and
> > > > > demux between ffmpeg and my python script.
> > > > >
> > > > > The idea is to have a very light structure to easily pipe it.
> > > > >
> > > > > I'm not familiar with audio/video container but it seems to me that
> > > > > parsing containers are not very light no?
> > > > >
> > > > >
> > > > Containers range from almost no processing like .y4m to complex
> monsters
> > > > like .mxf
> > >
> > > .y4m doesn't contain a timestamp either, and I don't want to use a
> > > complex container :),
> > >
> >
> > I doubt storing clock time in container for each frame is correct
> approach.
> > Is this variable frame rate video?
>
> Why would it not? The python takes as an input a list of frames.
> It then runs an inference model on it and could discard some frames if
> needed.
> Taking the absolute timestamp of each frame avoids relying on a
> supposed frame rate (based on a free running clock) that is not
> guaranteed.
> Also the result gives inference results which are properly timestamped
> with the correct data acquisition time and I can easily resynchronize
> with other sensor acquisition.
>
> >
> > One can always add another, trivial container with just one field having
> > whatever you want and with optional magic string in header.
>
> Yes, if this is acceptable by FFMpeg community I could propose a
> trivial container where the format is user defined.
> Else I can keep this dirty patch downstream, but I'm not a big fan.
>

FFmpeg usually supports files found in wild, and not inventing own formats
unless there is very good reason for it.


>
> Regards,
>
> >
> > Or can try/explore NUT container in FFmpeg.
> >
> >
> > >
> > > >
> > > > This patch is hack and approach/solution it tries is flawed.
> > >
> > > 100% agree with you that's why I prefix the patch with "HACK:",
> > >
> > > Regards,
> > > Clement
> > >
> > >
> > > >
> > > >
> > > > > Thanks,
> > > > > Clement
> > > > >
> > > > >
> > > > > >
> > > > > > - Andreas
> > > > > >
> > > > > > ___
> > > > > > 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 "unsubscr

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Gijs Peskens]

On 21-09-2023 18:21, Michael Niedermayer wrote:

Hi all

As the 6.1 release is upcoming and as it was previously stated by me that sdr
will be part of 6.1. Heres some update of what i intend to do about that.

People previously agreed to including a SDR input device in libavdevice with
SDR in a seperate library.

If the community and the SDR code are happy with each other before the release
then SDR will simply be merged and be part of 6.1 like any other feature.

OTOH If a majority of people are against the SDR code at the time of
branching 6.1. Then i will make a separate release identical to 6.1 with
the SDR code and of course also provide security support
What does this mean? Does this mean an FFmpeg release containing code 
that interfaces with your SDR library? Or does it mean the library fully 
integrated into FFmpeg?


Of course iam happy to change my plans if someone has a better suggestion!

What i intend to do with SDR next is AVExecutor support to improve processing
capacity with multiple threads and also to look into factoring the code so
SDR is more seperated, where this will lead to i do not know

thx

[...]


___
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 PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Clément Péron]

Hi Paul,

On Fri, 22 Sept 2023 at 15:17, Paul B Mahol  wrote:
>
> On Fri, Sep 22, 2023 at 2:39 PM Clément Péron  wrote:
>
> > Hi Paul,
> >
> > On Fri, 22 Sept 2023 at 13:41, Paul B Mahol  wrote:
> > >
> > > On Fri, Sep 22, 2023 at 12:06 PM Clément Péron 
> > wrote:
> > >
> > > > Hi Paul
> > > >
> > > > On Fri, 22 Sept 2023 at 11:27, Paul B Mahol  wrote:
> > > > >
> > > > > On Fri, Sep 22, 2023 at 10:38 AM Clément Péron  > >
> > > > wrote:
> > > > >
> > > > > > Hi Andreas,
> > > > > >
> > > > > > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
> > > > > >  wrote:
> > > > > > >
> > > > > > > Clément Péron:
> > > > > > > > Hi Michael, Andreas,
> > > > > > > >
> > > > > > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
> > > > > > > >  wrote:
> > > > > > > >>
> > > > > > > >> Michael Niedermayer:
> > > > > > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron
> > wrote:
> > > > > > >  Output the producer reference time to a dirty raw output.
> > > > > > > 
> > > > > > >  Signed-off-by: Clément Péron 
> > > > > > >  ---
> > > > > > >   libavformat/rawenc.c | 122
> > > > > > +++
> > > > > > >   1 file changed, 122 insertions(+)
> > > > > > > >>>
> > > > > > > >>> this breaks fate-filter-volume and others
> > > > > > > >>> (Segmentation fault)
> > > > > > > >>>
> > > > > > > >>> I can rerun it with debug symbols and provide peoper gdb
> > output
> > > > > > > >>> but i suspect given this has "HACK" in the title you are
> > aware of
> > > > > > this
> > > > > > > >
> > > > > > > > The "HACK" tag meaning was not supposed to be: "it's ok if it
> > > > > > > > segfaults", but more to trigger a discussion is it possible to
> > > > > > > > properly support an output timestamp in the raw video demux,
> > and if
> > > > > > > > yes how to do it :)
> > > > > > >
> > > > > > > If you need a timestamp for raw video, then use a proper
> > container
> > > > and
> > > > > > > not raw video. In fact, this patch basically creates new formats
> > > > > > > different from all the raw formats.
> > > > > >
> > > > > > Yes I agree, but I do not want to add too much overhead nor
> > > > > > computation processing or memory copy to my pipeline just to mux
> > and
> > > > > > demux between ffmpeg and my python script.
> > > > > >
> > > > > > The idea is to have a very light structure to easily pipe it.
> > > > > >
> > > > > > I'm not familiar with audio/video container but it seems to me that
> > > > > > parsing containers are not very light no?
> > > > > >
> > > > > >
> > > > > Containers range from almost no processing like .y4m to complex
> > monsters
> > > > > like .mxf
> > > >
> > > > .y4m doesn't contain a timestamp either, and I don't want to use a
> > > > complex container :),
> > > >
> > >
> > > I doubt storing clock time in container for each frame is correct
> > approach.
> > > Is this variable frame rate video?
> >
> > Why would it not? The python takes as an input a list of frames.
> > It then runs an inference model on it and could discard some frames if
> > needed.
> > Taking the absolute timestamp of each frame avoids relying on a
> > supposed frame rate (based on a free running clock) that is not
> > guaranteed.
> > Also the result gives inference results which are properly timestamped
> > with the correct data acquisition time and I can easily resynchronize
> > with other sensor acquisition.
> >
> > >
> > > One can always add another, trivial container with just one field having
> > > whatever you want and with optional magic string in header.
> >
> > Yes, if this is acceptable by FFMpeg community I could propose a
> > trivial container where the format is user defined.
> > Else I can keep this dirty patch downstream, but I'm not a big fan.
> >
>
> FFmpeg usually supports files found in wild, and not inventing own formats
> unless there is very good reason for it.

Indeed, It will be hard to find a file in the wild as it's supposed to
be used when you read from a pipe.

So if I propose a patch to support a new demux where the format is
user defined is there a chance to be accepted?

Thanks,
>
>
> >
> > Regards,
> >
> > >
> > > Or can try/explore NUT container in FFmpeg.
> > >
> > >
> > > >
> > > > >
> > > > > This patch is hack and approach/solution it tries is flawed.
> > > >
> > > > 100% agree with you that's why I prefix the patch with "HACK:",
> > > >
> > > > Regards,
> > > > Clement
> > > >
> > > >
> > > > >
> > > > >
> > > > > > Thanks,
> > > > > > Clement
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > - Andreas
> > > > > > >
> > > > > > > ___
> > > > > > > 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] Release 6.1

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote:
> On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer 
[...]

> If you mean real FFmpeg work, than by all means give access to services
> only you have to other
> interesting parties, like security related reports and others.

what ?

There are 633 open issues in coverity, every FFmpeg developer can work on.
i remember bringing this number down years ago to something rather small but now
the statistics dwarf that with the upward trend ...

if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can work 
on these
https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg

and the ffmpeg ossfuzz tickets, go to
ffmpeg-security, 3 people from google, 1 from mozilla, jb
and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger combs

so thats not just me
and a quick count, i think i have 32 open ossfuzz issues in my inbox,
with the 18 subtracted more are public with noone caring about.
if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones that 
are
not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah these 
ive
already posted fixes for i think)

Also theres our bug tracker and just the normal compiler warnings
if you want to work on this sort of thing

where are the developers who want to work on something above but do not have
access ?

the only other issue i remember on ffmpeg-security thats not spam and not 
ossfuzz
is a XSS issue in the fate server which i believe nicolas is working on.
If someone is interrested in working on the fate server code, please come forth
the code is in need for a maintainer outside this issue. I just had asked 
nicolas
about it because i did not know anyone else who knows perl and be willing
to help look into a not entirely trivial (for me) issue in fate server

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
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] Release 6.1

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote:
>> On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer
>> 
> [...]
>
>> If you mean real FFmpeg work, than by all means give access to services
>> only you have to other
>> interesting parties, like security related reports and others.
>
> what ?
>
> There are 633 open issues in coverity, every FFmpeg developer can work on.
> i remember bringing this number down years ago to something rather small but
> now
> the statistics dwarf that with the upward trend ...
>
> if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can
> work on these
> https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg
>
> and the ffmpeg ossfuzz tickets, go to
> ffmpeg-security, 3 people from google, 1 from mozilla, jb
> and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger
> combs
>
> so thats not just me
> and a quick count, i think i have 32 open ossfuzz issues in my inbox,
> with the 18 subtracted more are public with noone caring about.
> if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones
> that are
> not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah
> these ive
> already posted fixes for i think)
>
> Also theres our bug tracker and just the normal compiler warnings
> if you want to work on this sort of thing
>
> where are the developers who want to work on something above but do not
> have
> access ?
>
> the only other issue i remember on ffmpeg-security thats not spam and not
> ossfuzz
> is a XSS issue in the fate server which i believe nicolas is working on.
> If someone is interrested in working on the fate server code, please come
> forth
> the code is in need for a maintainer outside this issue. I just had asked
> nicolas
> about it because i did not know anyone else who knows perl and be willing
> to help look into a not entirely trivial (for me) issue in fate server
>

Do not lie, you are working for FFlabs now.

> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
___
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 release 6.1 (SDR Plans)

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> 
> On 21-09-2023 18:21, Michael Niedermayer wrote:
> > Hi all
> > 
> > As the 6.1 release is upcoming and as it was previously stated by me that 
> > sdr
> > will be part of 6.1. Heres some update of what i intend to do about that.
> > 
> > People previously agreed to including a SDR input device in libavdevice with
> > SDR in a seperate library.
> > 
> > If the community and the SDR code are happy with each other before the 
> > release
> > then SDR will simply be merged and be part of 6.1 like any other feature.
> > 
> > OTOH If a majority of people are against the SDR code at the time of
> > branching 6.1. Then i will make a separate release identical to 6.1 with
> > the SDR code and of course also provide security support
> What does this mean? Does this mean an FFmpeg release containing code that
> interfaces with your SDR library? Or does it mean the library fully
> integrated into FFmpeg?

It depends on the code at the time of release. ATM there is no seperate
library, just a SDR input device.
creating a separte library and the related API/ABI needs to be done with
thought and care not something to rush quickly.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


signature.asc
Description: PGP signature
___
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/6] avcodec/osq: Check that pkt_offset does not exceed pkt size

[Michael Niedermayer]

On Thu, Sep 21, 2023 at 08:14:31PM +0200, Paul B Mahol wrote:
> On Thu, Sep 21, 2023 at 8:09 PM Michael Niedermayer 
> wrote:
> 
> > Fixes: out of array access
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6227491892887552
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6268561729126400
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6414805046788096
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6538151088488448
> > Fixes:
> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6608131540779008
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/osq.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/osq.c b/libavcodec/osq.c
> > index e7f11691d2e..bcc75fef6fc 100644
> > --- a/libavcodec/osq.c
> > +++ b/libavcodec/osq.c
> > @@ -408,6 +408,9 @@ static int osq_receive_frame(AVCodecContext *avctx,
> > AVFrame *frame)
> >  GetBitContext *gb = &s->gb;
> >  int ret, n;
> >
> > +if (s->pkt_offset > s->pkt->size)
> > +s->pkt_offset = 0;
> >
> 
> This is more hack than real fix.

why ?

pkt->size is reset outside the codec, so either it needs to be
checked on codec entry or the codec should not use
internal->in_pkt and expect its size to be conserved
or implement flush() or something

ff_decode_flush_buffers() for example will clear teh packet

if you prefer i can implement flush() and reset pkt_offset in it
that probably would achieve teh same
just say if you prefer that ?

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: PGP signature
___
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] hwcontext_vulkan: guard unistd.h include

[Benjamin Cheng via ffmpeg-devel]

win32 typically doesn't have unistd.h, so always including it will break
MSVC builds. The usage of those POSIX functions are already guarded by
_WIN32, so use that to guard unistd.h include as well.
---
 libavutil/hwcontext_vulkan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index c676f4fc57..6c573abb8b 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -27,10 +27,10 @@
 #include "compat/w32dlfcn.h"
 #else
 #include 
+#include 
 #endif
 
 #include "thread.h"
-#include 
 
 #include "config.h"
 #include "pixdesc.h"
-- 
2.42.0

___
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] avradio/avdevice/sdrindev: -sdr_ant option

[Michael Niedermayer]

On Thu, Sep 21, 2023 at 07:06:28PM +1000, Peter Ross wrote:
> Signed-off-by: Peter Ross 
> ---
> 
> For use with uhd device with run-time selectable antenna jack.
> 
>  libavdevice/sdrindev.c | 3 +++
>  libavformat/sdr.h  | 1 +
>  libavformat/sdrdemux.c | 1 +
>  3 files changed, 5 insertions(+)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: PGP signature
___
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/6] avcodec/osq: Check that pkt_offset does not exceed pkt size

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Thu, Sep 21, 2023 at 08:14:31PM +0200, Paul B Mahol wrote:
>> On Thu, Sep 21, 2023 at 8:09 PM Michael Niedermayer
>> 
>> wrote:
>>
>> > Fixes: out of array access
>> > Fixes:
>> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6227491892887552
>> > Fixes:
>> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6268561729126400
>> > Fixes:
>> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6414805046788096
>> > Fixes:
>> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6538151088488448
>> > Fixes:
>> > 62164/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6608131540779008
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by
>> > :
>> > Michael Niedermayer 
>> > ---
>> >  libavcodec/osq.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>> > diff --git a/libavcodec/osq.c b/libavcodec/osq.c
>> > index e7f11691d2e..bcc75fef6fc 100644
>> > --- a/libavcodec/osq.c
>> > +++ b/libavcodec/osq.c
>> > @@ -408,6 +408,9 @@ static int osq_receive_frame(AVCodecContext *avctx,
>> > AVFrame *frame)
>> >  GetBitContext *gb = &s->gb;
>> >  int ret, n;
>> >
>> > +if (s->pkt_offset > s->pkt->size)
>> > +s->pkt_offset = 0;
>> >
>>
>> This is more hack than real fix.
>
> why ?
>
> pkt->size is reset outside the codec, so either it needs to be
> checked on codec entry or the codec should not use
> internal->in_pkt and expect its size to be conserved
> or implement flush() or something
>
> ff_decode_flush_buffers() for example will clear teh packet
>
> if you prefer i can implement flush() and reset pkt_offset in it
> that probably would achieve teh same
> just say if you prefer that ?

Yup, that is much cleaner, go ahead with that solution with flush().
I forgot about flush() case completely.

>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When the tyrant has disposed of foreign enemies by conquest or treaty, and
> there is nothing more to fear from them, then he is always stirring up
> some war or other, in order that the people may require a leader. -- Plato
>
___
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] ptrdiff_t related fixes and negative linesizes

[Paul B Mahol]

Hi,

Patches attached.
From c5ae33c4e36a476c44ee4c64b5889ade2ecfe701 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 22 Sep 2023 09:15:13 +0200
Subject: [PATCH 1/3] avfilter/avcodec: use ptrdiff_t instead of int for
 linesize

Signed-off-by: Paul B Mahol 
---
 libavcodec/aic.c   |  2 +-
 libavcodec/argo.c  | 10 -
 libavcodec/bink.c  |  6 ++---
 libavcodec/cdgraphics.c|  6 ++---
 libavcodec/cfhd.c  |  4 ++--
 libavcodec/dxtory.c| 22 +--
 libavcodec/fic.c   |  2 +-
 libavcodec/gif.c   | 18 +++
 libavcodec/gifdec.c|  7 +++---
 libavcodec/ljpegenc.c  |  8 ---
 libavcodec/magicyuvenc.c   |  4 ++--
 libavcodec/mdec.c  |  2 +-
 libavcodec/roqvideo.c  | 10 +
 libavcodec/roqvideoenc.c   |  2 +-
 libavcodec/smc.c   | 21 --
 libavfilter/vf_codecview.c | 12 +-
 libavfilter/vf_colorcontrast.c | 16 +++---
 libavfilter/vf_colorcorrect.c  | 36 +++---
 libavfilter/vf_colorize.c  | 12 +-
 libavfilter/vf_fillborders.c   | 28 
 libavfilter/vf_huesaturation.c |  2 +-
 libavfilter/vf_lut3d.c | 14 ++--
 libavfilter/vf_monochrome.c| 20 -
 libavfilter/vf_paletteuse.c|  2 +-
 libavfilter/vf_vibrance.c  | 40 +-
 libavfilter/vsrc_gradients.c   | 12 +-
 libavfilter/vsrc_testsrc.c | 38 
 27 files changed, 179 insertions(+), 177 deletions(-)

diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index f8b0f60354..8f44e8031a 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -320,7 +320,7 @@ static int aic_decode_slice(AICContext *ctx, int mb_x, int mb_y,
 int16_t *base_c = ctx->data_ptr[COEFF_CHROMA];
 int16_t *ext_y  = ctx->data_ptr[COEFF_LUMA_EXT];
 int16_t *ext_c  = ctx->data_ptr[COEFF_CHROMA_EXT];
-const int ystride = ctx->frame->linesize[0];
+const ptrdiff_t ystride = ctx->frame->linesize[0];
 
 if (last_row) {
 y_pos = (ctx->avctx->height - 16);
diff --git a/libavcodec/argo.c b/libavcodec/argo.c
index 589feed410..139d36b7b7 100644
--- a/libavcodec/argo.c
+++ b/libavcodec/argo.c
@@ -65,7 +65,7 @@ static int decode_avcf(AVCodecContext *avctx, AVFrame *frame)
 {
 ArgoContext *s = avctx->priv_data;
 GetByteContext *gb = &s->gb;
-const int l = frame->linesize[0];
+const ptrdiff_t l = frame->linesize[0];
 const uint8_t *map = gb->buffer;
 uint8_t *dst = frame->data[0];
 
@@ -95,7 +95,7 @@ static int decode_alcd(AVCodecContext *avctx, AVFrame *frame)
 ArgoContext *s = avctx->priv_data;
 GetByteContext *gb = &s->gb;
 GetByteContext sb;
-const int l = frame->linesize[0];
+const ptrdiff_t l = frame->linesize[0];
 const uint8_t *map = gb->buffer;
 uint8_t *dst = frame->data[0];
 uint8_t codes = 0;
@@ -144,7 +144,7 @@ static int decode_mad1(AVCodecContext *avctx, AVFrame *frame)
 GetByteContext *gb = &s->gb;
 const int w = frame->width;
 const int h = frame->height;
-const int l = frame->linesize[0];
+const ptrdiff_t l = frame->linesize[0];
 
 while (bytestream2_get_bytes_left(gb) > 0) {
 int size, type, pos, dy;
@@ -354,7 +354,7 @@ static int decode_mad1_24(AVCodecContext *avctx, AVFrame *frame)
 GetByteContext *gb = &s->gb;
 const int w = frame->width;
 const int h = frame->height;
-const int l = frame->linesize[0] / 4;
+const ptrdiff_t l = frame->linesize[0] / 4;
 
 while (bytestream2_get_bytes_left(gb) > 0) {
 int osize, type, pos, dy, di, bcode, value, v14;
@@ -562,7 +562,7 @@ static int decode_rle(AVCodecContext *avctx, AVFrame *frame)
 GetByteContext *gb = &s->gb;
 const int w = frame->width;
 const int h = frame->height;
-const int l = frame->linesize[0];
+const ptrdiff_t l = frame->linesize[0];
 uint8_t *dst = frame->data[0];
 int pos = 0, y = 0;
 
diff --git a/libavcodec/bink.c b/libavcodec/bink.c
index 804c141981..0fcefd67eb 100644
--- a/libavcodec/bink.c
+++ b/libavcodec/bink.c
@@ -865,13 +865,13 @@ static int binkb_decode_plane(BinkContext *c, AVFrame *frame, GetBitContext *gb,
 int ybias = is_key ? -15 : 0;
 int qp, quant_idx, coef_count, coef_idx[64];
 
-const int stride = frame->linesize[plane_idx];
+const ptrdiff_t stride = frame->linesize[plane_idx];
 int bw = is_chroma ? (c->avctx->width  + 15) >> 4 : (c->avctx->width  + 7) >> 3;
 int bh = is_chroma ? (c->avctx->height + 15) >> 4 : (c->avctx->height + 7) >> 3;
 
 binkb_init_bundles(c);
 ref_start = frame->data[plane_idx];
-ref_end   = frame->data[plane_idx] + ((bh - 1) * frame->linesize[plane_idx] + bw - 1) * 8;
+ref_end   = frame->data[plane_idx] + ((bh - 1) * stride + bw - 1) * 8;
 
 for (i = 0; i < 64; i++)
 coordmap[i] = (i & 

Re: [FFmpeg-devel] [RFC PATCH 3/3] HACK: avformat: rawenc: allow to output a raw PRFT

[Paul B Mahol]

On 9/22/23, Clément Péron  wrote:
> Hi Paul,
>
> On Fri, 22 Sept 2023 at 15:17, Paul B Mahol  wrote:
>>
>> On Fri, Sep 22, 2023 at 2:39 PM Clément Péron 
>> wrote:
>>
>> > Hi Paul,
>> >
>> > On Fri, 22 Sept 2023 at 13:41, Paul B Mahol  wrote:
>> > >
>> > > On Fri, Sep 22, 2023 at 12:06 PM Clément Péron 
>> > wrote:
>> > >
>> > > > Hi Paul
>> > > >
>> > > > On Fri, 22 Sept 2023 at 11:27, Paul B Mahol 
>> > > > wrote:
>> > > > >
>> > > > > On Fri, Sep 22, 2023 at 10:38 AM Clément Péron
>> > > > > > > >
>> > > > wrote:
>> > > > >
>> > > > > > Hi Andreas,
>> > > > > >
>> > > > > > On Fri, 22 Sept 2023 at 09:58, Andreas Rheinhardt
>> > > > > >  wrote:
>> > > > > > >
>> > > > > > > Clément Péron:
>> > > > > > > > Hi Michael, Andreas,
>> > > > > > > >
>> > > > > > > > On Thu, 21 Sept 2023 at 22:50, Andreas Rheinhardt
>> > > > > > > >  wrote:
>> > > > > > > >>
>> > > > > > > >> Michael Niedermayer:
>> > > > > > > >>> On Thu, Sep 21, 2023 at 02:17:00PM +0200, Clément Péron
>> > wrote:
>> > > > > > >  Output the producer reference time to a dirty raw output.
>> > > > > > > 
>> > > > > > >  Signed-off-by: Clément Péron 
>> > > > > > >  ---
>> > > > > > >   libavformat/rawenc.c | 122
>> > > > > > +++
>> > > > > > >   1 file changed, 122 insertions(+)
>> > > > > > > >>>
>> > > > > > > >>> this breaks fate-filter-volume and others
>> > > > > > > >>> (Segmentation fault)
>> > > > > > > >>>
>> > > > > > > >>> I can rerun it with debug symbols and provide peoper gdb
>> > output
>> > > > > > > >>> but i suspect given this has "HACK" in the title you are
>> > aware of
>> > > > > > this
>> > > > > > > >
>> > > > > > > > The "HACK" tag meaning was not supposed to be: "it's ok if
>> > > > > > > > it
>> > > > > > > > segfaults", but more to trigger a discussion is it possible
>> > > > > > > > to
>> > > > > > > > properly support an output timestamp in the raw video demux,
>> > and if
>> > > > > > > > yes how to do it :)
>> > > > > > >
>> > > > > > > If you need a timestamp for raw video, then use a proper
>> > container
>> > > > and
>> > > > > > > not raw video. In fact, this patch basically creates new
>> > > > > > > formats
>> > > > > > > different from all the raw formats.
>> > > > > >
>> > > > > > Yes I agree, but I do not want to add too much overhead nor
>> > > > > > computation processing or memory copy to my pipeline just to mux
>> > and
>> > > > > > demux between ffmpeg and my python script.
>> > > > > >
>> > > > > > The idea is to have a very light structure to easily pipe it.
>> > > > > >
>> > > > > > I'm not familiar with audio/video container but it seems to me
>> > > > > > that
>> > > > > > parsing containers are not very light no?
>> > > > > >
>> > > > > >
>> > > > > Containers range from almost no processing like .y4m to complex
>> > monsters
>> > > > > like .mxf
>> > > >
>> > > > .y4m doesn't contain a timestamp either, and I don't want to use a
>> > > > complex container :),
>> > > >
>> > >
>> > > I doubt storing clock time in container for each frame is correct
>> > approach.
>> > > Is this variable frame rate video?
>> >
>> > Why would it not? The python takes as an input a list of frames.
>> > It then runs an inference model on it and could discard some frames if
>> > needed.
>> > Taking the absolute timestamp of each frame avoids relying on a
>> > supposed frame rate (based on a free running clock) that is not
>> > guaranteed.
>> > Also the result gives inference results which are properly timestamped
>> > with the correct data acquisition time and I can easily resynchronize
>> > with other sensor acquisition.
>> >
>> > >
>> > > One can always add another, trivial container with just one field
>> > > having
>> > > whatever you want and with optional magic string in header.
>> >
>> > Yes, if this is acceptable by FFMpeg community I could propose a
>> > trivial container where the format is user defined.
>> > Else I can keep this dirty patch downstream, but I'm not a big fan.
>> >
>>
>> FFmpeg usually supports files found in wild, and not inventing own formats
>> unless there is very good reason for it.
>
> Indeed, It will be hard to find a file in the wild as it's supposed to
> be used when you read from a pipe.
>
> So if I propose a patch to support a new demux where the format is
> user defined is there a chance to be accepted?

If it passes code review and is not blocked by other means, yes.

>
> Thanks,
>>
>>
>> >
>> > Regards,
>> >
>> > >
>> > > Or can try/explore NUT container in FFmpeg.
>> > >
>> > >
>> > > >
>> > > > >
>> > > > > This patch is hack and approach/solution it tries is flawed.
>> > > >
>> > > > 100% agree with you that's why I prefix the patch with "HACK:",
>> > > >
>> > > > Regards,
>> > > > Clement
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > > > Thanks,
>> > > > > > Clement
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > - Andreas
>> > > > > > >
>> > > > > > > ___
>>

Re: [FFmpeg-devel] [PATCH] ptrdiff_t related fixes and negative linesizes

[Andreas Rheinhardt]

Paul B Mahol:
> diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
> index d90e467cac..fb0b335088 100644
> --- a/libavcodec/gifdec.c
> +++ b/libavcodec/gifdec.c
> @@ -86,26 +86,29 @@ static void gif_read_palette(GifState *s, uint32_t *pal, 
> int nb)
>  
>  static void gif_fill(AVFrame *picture, uint32_t color)
>  {
> -uint32_t *p = (uint32_t *)picture->data[0];
> -uint32_t *p_end = p + (picture->linesize[0] / sizeof(uint32_t)) * 
> picture->height;
> -
> -for (; p < p_end; p++)
> -*p = color;
> +const ptrdiff_t linesize = picture->linesize[0];
> +const uint8_t *py = picture->data[0];
> +const int w = picture->width;
> +const int h = picture->height;
> +
> +for (int y = 0; y < h; y++) {
> +uint32_t *px = (uint32_t *)py;
> +for (int x = 0; x < w; x++)
> +px[x] = color;
> +py += linesize;
> +}
>  }
>  
>  static void gif_fill_rect(AVFrame *picture, uint32_t color, int l, int t, 
> int w, int h)
>  {
> -const ptrdiff_t linesize = picture->linesize[0] / sizeof(uint32_t);
> -const uint32_t *py = (uint32_t *)picture->data[0] + t * linesize;
> -const uint32_t *pr, *pb = py + h * linesize;
> -uint32_t *px;
> -
> -for (; py < pb; py += linesize) {
> -px = (uint32_t *)py + l;
> -pr = px + w;
> -
> -for (; px < pr; px++)
> -*px = color;
> +const ptrdiff_t linesize = picture->linesize[0];
> +const uint8_t *py = picture->data[0] + t * linesize;

Don't use const if you cast it away a few lines below.

> +
> +for (int y = 0; y < h; y++) {
> +uint32_t *px = ((uint32_t *)py) + l;
> +for (int x = 0; x < w; x++)
> +px[x] = color;
> +py += linesize;
>  }
>  }

___
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/4] avcodec/evc_ps: Check cpb_cnt_minus1 and propagate error

[Michael Niedermayer]

On Fri, Sep 15, 2023 at 03:11:44PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 
> 60949/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-5959738853294080
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/evc_ps.c | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: PGP signature
___
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 v3] avformat/mxfdec: Remove this_partition

[Michael Niedermayer]

Suggested-by: Tomas Härdin 
Fixes: 
51896/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5130394286817280

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 4846c5d206a..1313f14fa03 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -102,7 +102,6 @@ typedef struct MXFPartition {
 uint64_t previous_partition;
 int index_sid;
 int body_sid;
-int64_t this_partition;
 int64_t essence_offset; ///< absolute offset of essence
 int64_t essence_length;
 int32_t kag_size;
@@ -727,10 +726,13 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 UID op;
 uint64_t footer_partition;
 uint32_t nb_essence_containers;
+uint64_t this_partition;
 
 if (mxf->partitions_count >= INT_MAX / 2)
 return AVERROR_INVALIDDATA;
 
+av_assert0(klv_offset >= mxf->run_in);
+
 tmp_part = av_realloc_array(mxf->partitions, mxf->partitions_count + 1, 
sizeof(*mxf->partitions));
 if (!tmp_part)
 return AVERROR(ENOMEM);
@@ -773,7 +775,13 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 partition->complete = uid[14] > 2;
 avio_skip(pb, 4);
 partition->kag_size = avio_rb32(pb);
-partition->this_partition = avio_rb64(pb);
+this_partition = avio_rb64(pb);
+if (this_partition != klv_offset - mxf->run_in) {
+av_log(mxf->fc, AV_LOG_WARNING,
+   "this_partition %"PRId64" mismatches %"PRId64"\n",
+   this_partition, klv_offset - mxf->run_in);
+}
+this_partition = klv_offset - mxf->run_in;
 partition->previous_partition = avio_rb64(pb);
 footer_partition = avio_rb64(pb);
 partition->header_byte_count = avio_rb64(pb);
@@ -793,8 +801,8 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 av_dict_set(&s->metadata, "operational_pattern_ul", str, 0);
 }
 
-if (partition->this_partition &&
-partition->previous_partition == partition->this_partition) {
+if (this_partition &&
+partition->previous_partition == this_partition) {
 av_log(mxf->fc, AV_LOG_ERROR,
"PreviousPartition equal to ThisPartition %"PRIx64"\n",
partition->previous_partition);
@@ -802,11 +810,11 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 if (!mxf->parsing_backward && mxf->last_forward_partition > 1) {
 MXFPartition *prev =
 mxf->partitions + mxf->last_forward_partition - 2;
-partition->previous_partition = prev->this_partition;
+partition->previous_partition = prev->pack_ofs - mxf->run_in;
 }
 /* if no previous body partition are found point to the header
  * partition */
-if (partition->previous_partition == partition->this_partition)
+if (partition->previous_partition == this_partition)
 partition->previous_partition = 0;
 av_log(mxf->fc, AV_LOG_ERROR,
"Overriding PreviousPartition with %"PRIx64"\n",
@@ -828,7 +836,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 "PartitionPack: ThisPartition = 0x%"PRIX64
 ", PreviousPartition = 0x%"PRIX64", "
 "FooterPartition = 0x%"PRIX64", IndexSID = %i, BodySID = %i\n",
-partition->this_partition,
+this_partition,
 partition->previous_partition, footer_partition,
 partition->index_sid, partition->body_sid);
 
@@ -902,7 +910,7 @@ static uint64_t partition_score(MXFPartition *p)
 score = 3;
 else
 score = 1;
-return (score << 60) | ((uint64_t)p->this_partition >> 4);
+return (score << 60) | ((uint64_t)p->pack_ofs >> 4);
 }
 
 static int mxf_add_metadata_set(MXFContext *mxf, MXFMetadataSet **metadata_set)
@@ -3539,14 +3547,14 @@ static void 
mxf_compute_essence_containers(AVFormatContext *s)
 
 /* essence container spans to the next partition */
 if (x < mxf->partitions_count - 1)
-p->essence_length = mxf->partitions[x+1].this_partition - 
p->essence_offset;
+p->essence_length = mxf->partitions[x+1].pack_ofs - 
mxf->run_in - p->essence_offset;
 
 if (p->essence_length < 0) {
 /* next ThisPartition < essence_offset */
 p->essence_length = 0;
 av_log(mxf->fc, AV_LOG_ERROR,
"partition %i: bad ThisPartition = %"PRIX64"\n",
-   x+1, mxf->partitions[x+1].this_partition);
+   x+1, mxf->partitions[x+1].pack_ofs - mxf->run_in);
 }
 }
 }
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ff

Re: [FFmpeg-devel] [PATCH 1/4] avformat/mov: Avoid cloning encryption info if its unchanged

[Michael Niedermayer]

On Sat, Jun 18, 2022 at 09:16:34PM +0200, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 
> 45834/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5419540462305280
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

It appears this issue is still open
so i will apply this

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


signature.asc
Description: PGP signature
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Michael Niedermayer]

On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/rtv1.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

will apply 1-3 of this patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: PGP signature
___
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/5] avcodec/mv30: Check the input length before allocation

[Michael Niedermayer]

On Mon, Aug 07, 2023 at 10:22:25AM +0200, Paul B Mahol wrote:
> NAK

will apply unless you provide technical comments

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: PGP signature
___
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/celp_math: avoid overflow in shift

[Michael Niedermayer]

On Thu, Sep 07, 2023 at 11:24:42PM +0200, Michael Niedermayer wrote:
> by making gain unsigned we have 1 bit more available
> alternatively we can clip twice as in the g729 reference
> 
> Fixes: left shift of 23404 by 17 places cannot be represented in type 'int'
> Fixes: 
> 61728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ACELP_KELVIN_fuzzer-6280412547383296
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/celp_math.h  | 2 +-
>  libavcodec/g729postfilter.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: PGP signature
___
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/5] avcodec/mv30: Check the input length before allocation

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Mon, Aug 07, 2023 at 10:22:25AM +0200, Paul B Mahol wrote:
>> NAK
>
> will apply unless you provide technical comments

NAK, never provided proof that this hack does not break decoding.
This is not really security fix.

>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
>
___
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/xvididct: Fix integer overflow in idct_row()

[Michael Niedermayer]

On Fri, Sep 08, 2023 at 12:13:11AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 1871429831 + 343006811 cannot be represented 
> in type 'int'
> Fixes: 
> 61784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AIC_fuzzer-5372151001120768
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/xvididct.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


signature.asc
Description: PGP signature
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/rtv1.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> will apply 1-3 of this patchset

Are you sure this does not break decoding?

It would not be first time you intentionally break decoders because of hacks.


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
>
___
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/wavarc: Use unsigned for samples in 1dif, 2slp, 5elp

[Michael Niedermayer]

On Sun, Sep 10, 2023 at 03:09:50AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 141394472 + 2038060365 cannot be represented 
> in type 'int'
> Fixes: 
> 61787/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-5882604925878272
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wavarc.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: PGP signature
___
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] vulkan_h264: fix long-term ref handling

[Benjamin Cheng via ffmpeg-devel]

h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.

Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
 libavcodec/vulkan_h264.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
index 32ef32d640..4135188e7a 100644
--- a/libavcodec/vulkan_h264.c
+++ b/libavcodec/vulkan_h264.c
@@ -406,10 +406,14 @@ static int vk_h264_start_frame(AVCodecContext  
*avctx,
 }
 
 /* Fill in long-term refs */
-for (int r = 0, i = h->short_ref_count; i < h->short_ref_count + 
h->long_ref_count; i++, r++) {
+for (int r = 0, i = h->short_ref_count; r < H264_MAX_DPB_FRAMES &&
+ i < h->short_ref_count + h->long_ref_count; r++) {
+   if (!h->long_ref[r])
+   continue;
+
 dpb_slot_index = 0;
-for (unsigned slot = 0; slot < H264_MAX_PICTURE_COUNT; slot++) {
-if (h->long_ref[i] == &h->DPB[slot]) {
+for (unsigned slot = 0; slot < 16; slot++) {
+if (h->long_ref[r] == &h->DPB[slot]) {
 dpb_slot_index = slot;
 break;
 }
@@ -422,6 +426,7 @@ static int vk_h264_start_frame(AVCodecContext  
*avctx,
 dpb_slot_index);
 if (err < 0)
 return err;
+   i++;
 }
 
 hp->h264pic = (StdVideoDecodeH264PictureInfo) {
-- 
2.42.0

___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
> On 9/22/23, Michael Niedermayer  wrote:
> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  libavcodec/rtv1.c | 6 +-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > will apply 1-3 of this patchset
> 
> Are you sure this does not break decoding?

Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
check looks correct.
There are 2 end of bitstream checks for early exit but they look like
error handling not some normal exit as they leave the frame uninitialized

Do you have some files so i can double check this is not breaking anything ?

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: PGP signature
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
>> On 9/22/23, Michael Niedermayer  wrote:
>> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
>> >> Signed-off-by: Michael Niedermayer 
>> >> ---
>> >>  libavcodec/rtv1.c | 6 +-
>> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > will apply 1-3 of this patchset
>>
>> Are you sure this does not break decoding?
>
> Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
> check looks correct.
> There are 2 end of bitstream checks for early exit but they look like
> error handling not some normal exit as they leave the frame uninitialized
>

FFmpeg default initialization code for AVFrame's buffers does it
twice, so they are always zeroed or previous values of previous
buffers in pool.

> Do you have some files so i can double check this is not breaking anything

Search trac tickets.

> ?
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
>
___
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/5] avcodec/mv30: Check the input length before allocation

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 09:31:39PM +0200, Paul B Mahol wrote:
> On 9/22/23, Michael Niedermayer  wrote:
> > On Mon, Aug 07, 2023 at 10:22:25AM +0200, Paul B Mahol wrote:
> >> NAK
> >
> > will apply unless you provide technical comments
> 
> NAK, never provided proof that this hack does not break decoding.

i think i did in
"[FFmpeg-devel] [PATCH v2] avcodec/mv30: Check the input length before 
allocation"

it seems i replied to the older of these fixes by mistake, but really
they do the same

[...]

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.


signature.asc
Description: PGP signature
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Michael Niedermayer]

On Fri, Sep 22, 2023 at 11:30:37PM +0200, Paul B Mahol wrote:
> On 9/22/23, Michael Niedermayer  wrote:
> > On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
> >> On 9/22/23, Michael Niedermayer  wrote:
> >> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
> >> >> Signed-off-by: Michael Niedermayer 
> >> >> ---
> >> >>  libavcodec/rtv1.c | 6 +-
> >> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >> >
> >> > will apply 1-3 of this patchset
> >>
> >> Are you sure this does not break decoding?
> >
> > Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
> > check looks correct.
> > There are 2 end of bitstream checks for early exit but they look like
> > error handling not some normal exit as they leave the frame uninitialized
> >
> 
> FFmpeg default initialization code for AVFrame's buffers does it
> twice, so they are always zeroed or previous values of previous
> buffers in pool.

its rare that correct frame decoding depends on internal AVFrame buffer
ordering


> 
> > Do you have some files so i can double check this is not breaking anything
> 
> Search trac tickets.

thanks, found a zip with 2 video files
ill check it


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



signature.asc
Description: PGP signature
___
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/5] avcodec/mv30: Check the input length before allocation

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Fri, Sep 22, 2023 at 09:31:39PM +0200, Paul B Mahol wrote:
>> On 9/22/23, Michael Niedermayer  wrote:
>> > On Mon, Aug 07, 2023 at 10:22:25AM +0200, Paul B Mahol wrote:
>> >> NAK
>> >
>> > will apply unless you provide technical comments
>>
>> NAK, never provided proof that this hack does not break decoding.
>
> i think i did in
> "[FFmpeg-devel] [PATCH v2] avcodec/mv30: Check the input length before
> allocation"
>
> it seems i replied to the older of these fixes by mistake, but really
> they do the same

If this one appears to need to be reverted because it breaks decoding
than you should resign from your current role.

>
> [...]
>
> thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Some people wanted to paint the bikeshed green, some blue and some pink.
> People argued and fought, when they finally agreed, only rust was left.
>
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Paul B Mahol]

On 9/22/23, Michael Niedermayer  wrote:
> On Fri, Sep 22, 2023 at 11:30:37PM +0200, Paul B Mahol wrote:
>> On 9/22/23, Michael Niedermayer  wrote:
>> > On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
>> >> On 9/22/23, Michael Niedermayer  wrote:
>> >> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
>> >> >> Signed-off-by: Michael Niedermayer 
>> >> >> ---
>> >> >>  libavcodec/rtv1.c | 6 +-
>> >> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >> >
>> >> > will apply 1-3 of this patchset
>> >>
>> >> Are you sure this does not break decoding?
>> >
>> > Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
>> > check looks correct.
>> > There are 2 end of bitstream checks for early exit but they look like
>> > error handling not some normal exit as they leave the frame
>> > uninitialized
>> >
>>
>> FFmpeg default initialization code for AVFrame's buffers does it
>> twice, so they are always zeroed or previous values of previous
>> buffers in pool.
>
> its rare that correct frame decoding depends on internal AVFrame buffer
> ordering
>

Users are supposed to use error checking. And I think decoder returns
error on missing frame data.

When we lost interest in preserving all decoded frame pixels as much
as possible?

>
>>
>> > Do you have some files so i can double check this is not breaking
>> > anything
>>
>> Search trac tickets.
>
> thanks, found a zip with 2 video files
> ill check it
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "I am not trying to be anyone's saviour, I'm trying to think about the
>  future and not be sad" - Elon Musk
>
>
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Michael Niedermayer]

On Sat, Sep 23, 2023 at 12:01:17AM +0200, Paul B Mahol wrote:
> On 9/22/23, Michael Niedermayer  wrote:
> > On Fri, Sep 22, 2023 at 11:30:37PM +0200, Paul B Mahol wrote:
> >> On 9/22/23, Michael Niedermayer  wrote:
> >> > On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
> >> >> On 9/22/23, Michael Niedermayer  wrote:
> >> >> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer wrote:
> >> >> >> Signed-off-by: Michael Niedermayer 
> >> >> >> ---
> >> >> >>  libavcodec/rtv1.c | 6 +-
> >> >> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >> >> >
> >> >> > will apply 1-3 of this patchset
> >> >>
> >> >> Are you sure this does not break decoding?
> >> >
> >> > Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
> >> > check looks correct.
> >> > There are 2 end of bitstream checks for early exit but they look like
> >> > error handling not some normal exit as they leave the frame
> >> > uninitialized
> >> >
> >>
> >> FFmpeg default initialization code for AVFrame's buffers does it
> >> twice, so they are always zeroed or previous values of previous
> >> buffers in pool.
> >
> > its rare that correct frame decoding depends on internal AVFrame buffer
> > ordering
> >
> 
> Users are supposed to use error checking. And I think decoder returns
> error on missing frame data.

yes, the rtv1 decoder looks a bit sloppy written, not returning error
codes on what looks like error checks.
Its not the only code doing that, ive seen this in other files too


> 
> When we lost interest in preserving all decoded frame pixels as much
> as possible?

when patches using discard_damaged_percentage where getting blocked in review
while simpler but less ideal solutions made all reviewers happy


I can implement this using discard_damaged_percentage, then the user can
decide at which point a frame would be too damaged to decode/return
and also to drop none or all with damage as the user prefers

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


signature.asc
Description: PGP signature
___
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/4] avcodec/rtv1: Check if the minimal size is available in decode_rtv1()

[Paul B Mahol]

On 9/23/23, Michael Niedermayer  wrote:
> On Sat, Sep 23, 2023 at 12:01:17AM +0200, Paul B Mahol wrote:
>> On 9/22/23, Michael Niedermayer  wrote:
>> > On Fri, Sep 22, 2023 at 11:30:37PM +0200, Paul B Mahol wrote:
>> >> On 9/22/23, Michael Niedermayer  wrote:
>> >> > On Fri, Sep 22, 2023 at 09:32:47PM +0200, Paul B Mahol wrote:
>> >> >> On 9/22/23, Michael Niedermayer  wrote:
>> >> >> > On Thu, Jul 27, 2023 at 01:59:13AM +0200, Michael Niedermayer
>> >> >> > wrote:
>> >> >> >> Signed-off-by: Michael Niedermayer 
>> >> >> >> ---
>> >> >> >>  libavcodec/rtv1.c | 6 +-
>> >> >> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >> >> >
>> >> >> > will apply 1-3 of this patchset
>> >> >>
>> >> >> Are you sure this does not break decoding?
>> >> >
>> >> > Well, its a loop over 4x4 blocks, a 16bit "skip" run so the minimum
>> >> > check looks correct.
>> >> > There are 2 end of bitstream checks for early exit but they look
>> >> > like
>> >> > error handling not some normal exit as they leave the frame
>> >> > uninitialized
>> >> >
>> >>
>> >> FFmpeg default initialization code for AVFrame's buffers does it
>> >> twice, so they are always zeroed or previous values of previous
>> >> buffers in pool.
>> >
>> > its rare that correct frame decoding depends on internal AVFrame buffer
>> > ordering
>> >
>>
>> Users are supposed to use error checking. And I think decoder returns
>> error on missing frame data.
>
> yes, the rtv1 decoder looks a bit sloppy written, not returning error
> codes on what looks like error checks.
> Its not the only code doing that, ive seen this in other files too

You are last person here to call some decoder(s) are sloppy written.

>
>
>>
>> When we lost interest in preserving all decoded frame pixels as much
>> as possible?
>
> when patches using discard_damaged_percentage where getting blocked in
> review
> while simpler but less ideal solutions made all reviewers happy
>
>
> I can implement this using discard_damaged_percentage, then the user can
> decide at which point a frame would be too damaged to decode/return
> and also to drop none or all with damage as the user prefers
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Homeopathy is like voting while filling the ballot out with transparent
> ink.
> Sometimes the outcome one wanted occurs. Rarely its worse than filling out
> a ballot properly.
>
___
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 v2] lavc/libaribcaption.c: add MSZ characters related options

[TADANO Tokumei]

This patch add MSZ (Middle Size; half width) characters related
options.

* add `-replace_msz_japanese` option introduced in version 1.0.1
  of libaribcaption.
* add `-replace_msz_glyph` option introduced in version 1.1.0
  of libaribcaption.
* rename `-replace_fullwidth_ascii` option to `-replace_msz_ascii`
  to clarify option meaning.
* FIX: change all the `bool` option variables in `ARIBCaptionContext`
  to `int`.
  On some environments, a `bool` variable is small space than `int`.
  If a `bool` option was specified by command line, following
  variables would be filled and destroyed.
---
 doc/decoders.texi   | 28 --
 libavcodec/libaribcaption.c | 40 -
 2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..27b981b267 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -427,12 +427,6 @@ If your player cannot handle AVSubtitles with multiple ASS 
rectangles properly,
 set this option to @var{true} or define @env{ASS_SINGLE_RECT=1} to change
 default behavior at compilation.
 
-@item -replace_fullwidth_ascii @var{boolean}
-Specify whether to replace MSZ (Middle Size, half width) fullwidth
-alphanumerics with halfwidth alphanumerics.
-
-The default is @var{true}.
-
 @item -force_outline_text @var{boolean}
 Specify whether always render outline text for all characters regardless of
 the indication by charactor style.
@@ -459,6 +453,28 @@ Specify whether to render replaced DRCS characters as 
Unicode characters.
 
 The default is @var{true}.
 
+@item -replace_msz_ascii @var{boolean}
+Specify whether to replace MSZ (Middle Size, half width) fullwidth
+alphanumerics with halfwidth alphanumerics.
+
+The default is @var{true}.
+
+@item -replace_msz_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size, half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
+@item -replace_msz_glyph @var{boolean}
+Specify whether to replace MSZ (Middle Size, half width) characters
+with halfwidth glyphs if the fonts supports it.
+This option works under FreeType or DirectWrite renderer
+with Adobe-Japan1 compliant fonts.
+e.g., IBM Plex Sans JP, Morisawa BIZ UDGothic, Morisawa BIZ UDMincho,
+Yu Gothic, Yu Mincho, and Meiryo.
+
+The default is @var{true}.
+
 @item -canvas_size @var{image_size}
 Specify the resolution of the canvas to render subtitles to; usually, this
 should be frame size of input video.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..ddff47633a 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -68,14 +68,20 @@ typedef struct ARIBCaptionContext {
 
 int subtitle_type;
 int encoding_scheme;
-bool ass_single_rect;
+int ass_single_rect;
 char *font;
-bool replace_fullwidth_ascii;
-bool force_stroke_text;
-bool ignore_background;
-bool ignore_ruby;
+int force_stroke_text;
+int ignore_background;
+int ignore_ruby;
 float stroke_width;
-bool replace_drcs;
+int replace_drcs;
+int replace_msz_ascii;
+#if defined(ARIBCC_VERSION)
+int replace_msz_japanese;
+#  if AV_VERSION_INT(ARIBCC_VERSION_MAJOR, ARIBCC_VERSION_MINOR, 
ARIBCC_VERSION_PATCH) >= AV_VERSION_INT(1, 1, 0)
+int replace_msz_glyph;
+#  endif
+#endif
 
 int64_t pts;
 AVRational time_base;
@@ -1004,7 +1010,11 @@ static int aribcaption_init(AVCodecContext *avctx)
 return AVERROR_EXTERNAL;
 }
 aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
-   
ctx->replace_fullwidth_ascii);
+   ctx->replace_msz_ascii);
+#if defined(ARIBCC_VERSION)
+aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+   ctx->replace_msz_japanese);
+#endif
 
 /* Similar behavior as ffmpeg tool to set canvas size */
 if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1057,6 +1067,10 @@ static int aribcaption_init(AVCodecContext *avctx)
 aribcc_renderer_set_force_no_background(ctx->renderer, 
ctx->ignore_background);
 aribcc_renderer_set_force_no_ruby(ctx->renderer, ctx->ignore_ruby);
 aribcc_renderer_set_stroke_width(ctx->renderer, ctx->stroke_width);
+#if defined(ARIBCC_VERSION) && AV_VERSION_INT(ARIBCC_VERSION_MAJOR, 
ARIBCC_VERSION_MINOR, ARIBCC_VERSION_PATCH) >= AV_VERSION_INT(1, 1, 0)
+aribcc_renderer_set_replace_msz_halfwidth_glyph(ctx->renderer,
+
ctx->replace_msz_glyph);
+#endif
 if (ctx->font) {
 int is_nomem = 0;
 size_t count = 0;
@@ -1132,8 +1146,6 @@ static const AVOption options[] = {
   OFFSET(ass_single_rect), AV_OPT_TYPE_BOOL, { .i64 = ASS_SINGLE_RECT }, 
0, 1, SD },
 { "font", "comma-separated font famil

Re: [FFmpeg-devel] [PATCH v2] lavc/libaribcaption.c: add MSZ characters related options

[TADANO Tokumei]

This is updated patch to "[PATCH] lavc/libaribcaption.c: add -replace_fullwidth_japanese 
option" (Message-Id: <20230908130050.85688-1-aiming...@pc.nifty.jp>).

If specified fonts contain half-width glyphs, it make better rendering with
`-replace_msz_ascii false -replace_msz_japanese false` option for bitmap 
sub_type.

This patch also fix a bug in libaribcaption.c. I prefer to apply this ASAP.

On 2023/09/23 11:00, TADANO Tokumei wrote:

This patch add MSZ (Middle Size; half width) characters related
options.

* add `-replace_msz_japanese` option introduced in version 1.0.1
   of libaribcaption.
* add `-replace_msz_glyph` option introduced in version 1.1.0
   of libaribcaption.
* rename `-replace_fullwidth_ascii` option to `-replace_msz_ascii`
   to clarify option meaning.
* FIX: change all the `bool` option variables in `ARIBCaptionContext`
   to `int`.
   On some environments, a `bool` variable is small space than `int`.
   If a `bool` option was specified by command line, following
   variables would be filled and destroyed.
---
  doc/decoders.texi   | 28 --
  libavcodec/libaribcaption.c | 40 -
  2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..27b981b267 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -427,12 +427,6 @@ If your player cannot handle AVSubtitles with multiple ASS 
rectangles properly,
  set this option to @var{true} or define @env{ASS_SINGLE_RECT=1} to change
  default behavior at compilation.
  
-@item -replace_fullwidth_ascii @var{boolean}

-Specify whether to replace MSZ (Middle Size, half width) fullwidth
-alphanumerics with halfwidth alphanumerics.
-
-The default is @var{true}.
-
  @item -force_outline_text @var{boolean}
  Specify whether always render outline text for all characters regardless of
  the indication by charactor style.
@@ -459,6 +453,28 @@ Specify whether to render replaced DRCS characters as 
Unicode characters.
  
  The default is @var{true}.
  
+@item -replace_msz_ascii @var{boolean}

+Specify whether to replace MSZ (Middle Size, half width) fullwidth
+alphanumerics with halfwidth alphanumerics.
+
+The default is @var{true}.
+
+@item -replace_msz_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size, half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
+@item -replace_msz_glyph @var{boolean}
+Specify whether to replace MSZ (Middle Size, half width) characters
+with halfwidth glyphs if the fonts supports it.
+This option works under FreeType or DirectWrite renderer
+with Adobe-Japan1 compliant fonts.
+e.g., IBM Plex Sans JP, Morisawa BIZ UDGothic, Morisawa BIZ UDMincho,
+Yu Gothic, Yu Mincho, and Meiryo.
+
+The default is @var{true}.
+
  @item -canvas_size @var{image_size}
  Specify the resolution of the canvas to render subtitles to; usually, this
  should be frame size of input video.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..ddff47633a 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -68,14 +68,20 @@ typedef struct ARIBCaptionContext {
  
  int subtitle_type;

  int encoding_scheme;
-bool ass_single_rect;
+int ass_single_rect;
  char *font;
-bool replace_fullwidth_ascii;
-bool force_stroke_text;
-bool ignore_background;
-bool ignore_ruby;
+int force_stroke_text;
+int ignore_background;
+int ignore_ruby;
  float stroke_width;
-bool replace_drcs;
+int replace_drcs;
+int replace_msz_ascii;
+#if defined(ARIBCC_VERSION)
+int replace_msz_japanese;
+#  if AV_VERSION_INT(ARIBCC_VERSION_MAJOR, ARIBCC_VERSION_MINOR, 
ARIBCC_VERSION_PATCH) >= AV_VERSION_INT(1, 1, 0)
+int replace_msz_glyph;
+#  endif
+#endif
  
  int64_t pts;

  AVRational time_base;
@@ -1004,7 +1010,11 @@ static int aribcaption_init(AVCodecContext *avctx)
  return AVERROR_EXTERNAL;
  }
  aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
-   
ctx->replace_fullwidth_ascii);
+   ctx->replace_msz_ascii);
+#if defined(ARIBCC_VERSION)
+aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+   ctx->replace_msz_japanese);
+#endif
  
  /* Similar behavior as ffmpeg tool to set canvas size */

  if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1057,6 +1067,10 @@ static int aribcaption_init(AVCodecContext *avctx)
  aribcc_renderer_set_force_no_background(ctx->renderer, 
ctx->ignore_background);
  aribcc_renderer_set_force_no_ruby(ctx->renderer, ctx->ignore_ruby);
  aribcc_renderer_set_stroke_width(ctx->renderer, ctx->stroke_width);
+#if defined(ARIBCC_VERSION) && AV_VERSION_INT(ARIBCC_VERSION_MAJOR, 
ARIBCC_VERSION_MINOR, ARI

Re: [FFmpeg-devel] [PATCH 1/4] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_v

[Logan.Lyu]

Hi, Martin,

Thanks for your review.

Thanks for the patches. Functionally, they seem to work, and the 
issues i saw in the code are relatively minor. Unfortunately, some of 
the issues are issues that we've been through in many earlier patches, 
so I would hope that you would pay attention to them in the future 
before posting more patches.
Okay, I have noticed the previous issues and made some modifications 
according to the issues, And I have completed the modifications based on 
your comments.


If there are any missing issues that have not been corrected, please let 
me know.




在 2023/9/17 5:46, Martin Storsjö 写道:

On Thu, 14 Sep 2023, Logan.Lyu wrote:


Hi Martin,

You can try the attached patchset. If that doesn't work, My code 
branch address is https://github.com/myais2023/FFmpeg/tree/hevc-aarch64


Thanks for the patches. Functionally, they seem to work, and the 
issues i saw in the code are relatively minor. Unfortunately, some of 
the issues are issues that we've been through in many earlier patches, 
so I would hope that you would pay attention to them in the future 
before posting more patches.



In patch 1, you've got a bunch of sxtw instructions for src/dst stride 
parameters that have the type ptrdiff_t - that shouldn't be necessary?


In patch 2, you're moving the macros calc_epelh, calc_epelh2, 
load_epel_filterh - can you split out the move into a separate commit? 
(This isn't strictly necessary but would make things even clearer.)


In patch 2, you're storing below the stack, then decrementing it 
afterwards - e.g. like this:



+    stp x0, x30, [sp, #-16]
+    stp x1, x2, [sp, #-32]
+    stp x3, x4, [sp, #-48]
+    stp x5, x6, [sp, #-64]!


Please change that so that you're first predecrementing the whole 
area, then storing the other elements above that stack pointer, e.g. 
like this:


stp x0, x30, [sp, #-64]!
stp x1, x2, [sp, #16]
stp x3, x4, [sp, #32]

etc.

The same issue also appears in variouos places within functions like 
this:



+    stp x0, x1, [sp, #-16]
+    stp x4, x6, [sp, #-32]
+    stp xzr, x30, [sp, #-48]!


Please fix all of these cases - you can search through your patches 
for anything related to storing on the stack. Also, storing xzr here 
seems superfluous - if you've got an odd number of registers to store, 
just make one instruction str instead of stp (but keep the stack 
aligned).


Then in patch 4, you've got yet another pattern for doing these 
stores, where you have superfluous consecutive stack decrements like 
this:



+    stp x6, x30, [sp, #-16]!
+    mov x7, #16
+    stp x0, x1, [sp, #-16]!
+    stp x2, x3, [sp, #-16]!
+    stp x4, x5, [sp, #-16]!


Please just do one stack decrement covering all the stack space you need.

I believe these issues have been raised in earlier reviews as well.

// Martin
From 62a59aa1fb7bc684ca0c216fd039dd0f231ad0c0 Mon Sep 17 00:00:00 2001
From: Logan Lyu 
Date: Tue, 15 Aug 2023 16:42:25 +0800
Subject: [PATCH 04/10] lavc/aarch64: new optimization for 8-bit
 hevc_qpel_uni_v

checkasm bench:
put_hevc_qpel_uni_v4_8_c: 146.2
put_hevc_qpel_uni_v4_8_neon: 43.2
put_hevc_qpel_uni_v6_8_c: 303.9
put_hevc_qpel_uni_v6_8_neon: 69.7
put_hevc_qpel_uni_v8_8_c: 495.2
put_hevc_qpel_uni_v8_8_neon: 74.7
put_hevc_qpel_uni_v12_8_c: 1100.9
put_hevc_qpel_uni_v12_8_neon: 222.4
put_hevc_qpel_uni_v16_8_c: 1955.2
put_hevc_qpel_uni_v16_8_neon: 269.2
put_hevc_qpel_uni_v24_8_c: 4571.9
put_hevc_qpel_uni_v24_8_neon: 832.4
put_hevc_qpel_uni_v32_8_c: 8226.4
put_hevc_qpel_uni_v32_8_neon: 1035.7
put_hevc_qpel_uni_v48_8_c: 18324.2
put_hevc_qpel_uni_v48_8_neon: 2321.2
put_hevc_qpel_uni_v64_8_c: 37659.4
put_hevc_qpel_uni_v64_8_neon: 4122.2

Co-Authored-By: J. Dekker 
---
 libavcodec/aarch64/hevcdsp_init_aarch64.c |   5 +
 libavcodec/aarch64/hevcdsp_qpel_neon.S| 221 ++
 2 files changed, 226 insertions(+)

diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c 
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index d78954f440..51d212ff72 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -192,6 +192,10 @@ NEON8_FNPROTO(qpel_h, (int16_t *dst,
 const uint8_t *_src, ptrdiff_t _srcstride,
 int height, intptr_t mx, intptr_t my, int width), _i8mm);
 
+NEON8_FNPROTO(qpel_uni_v, (uint8_t *dst,  ptrdiff_t dststride,
+const uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width),);
+
 NEON8_FNPROTO(qpel_uni_w_h, (uint8_t *_dst,  ptrdiff_t _dststride,
 const uint8_t *_src, ptrdiff_t _srcstride,
 int height, int denom, int wx, int ox,
@@ -295,6 +299,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, 
const int bit_depth)
 NEON8_FNASSIGN(c->put_hevc_epel_uni, 0, 0, pel_uni_pixels,);
 NEON8_FNASSIGN(c->put

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
 wrote:
>
> On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> >
> > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As the 6.1 release is upcoming and as it was previously stated by me that 
> > > sdr
> > > will be part of 6.1. Heres some update of what i intend to do about that.
> > >
> > > People previously agreed to including a SDR input device in libavdevice 
> > > with
> > > SDR in a seperate library.
> > >
> > > If the community and the SDR code are happy with each other before the 
> > > release
> > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > >
> > > OTOH If a majority of people are against the SDR code at the time of
> > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > the SDR code and of course also provide security support
> > What does this mean? Does this mean an FFmpeg release containing code that
> > interfaces with your SDR library? Or does it mean the library fully
> > integrated into FFmpeg?
>
> It depends on the code at the time of release. ATM there is no seperate
> library, just a SDR input device.
> creating a separte library and the related API/ABI needs to be done with
> thought and care not something to rush quickly.
>

What does this code *do*? All these arguments about the SDR code, and
I haven't seen it myself (because the email patch workflow really
makes it hard to track this stuff down, and I assume it was submitted
on list somewhere?)

If it's just taking SDR devices as inputs and allowing you to encode
audio and video streams, I'm not sure why you *wouldn't* have this as
something in libavdevice or extended from it as a separate library.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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".