Re: [FFmpeg-devel] Towards YUVJ removal

[Niklas Haas]

On Fri, 09 Dec 2022 17:50:11 +0100 Michael Niedermayer  
wrote:
> On Fri, Dec 09, 2022 at 12:49:41PM +0100, Niklas Haas wrote:
> > So, as was discussed at the last meeting, we should move towards
> > removing YUVJ. I want to gather feedback on what appears to be to the
> > major hurdle, and possible ways to solve it.
> > 
> > The basic major issue is how to handle the case of combining limited
> > range input with an encoder for a format that only accepts full range
> > data. The common case, for example, would be converting a frame from a
> > typical video file to a JPEG:
> > 
> > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg
> > 
> > Currently, this works because the JPEG encoder only advertises YUVJ
> > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert
> > from limited range to full range. But this depends on conflating color
> > range and pixel formats, which is exactly what has been marked
> > deprecated for an eternity.
> > 
> > Now, there are some solutions I can see for how to handle this case in
> > a non-YUVJ world:
> > 
> > 1. Simply output an error, and rely on the user to insert a conversion
> >filter, e.g.:
> > 
> >$ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg
> >error: inputs to jpeg encoder must be full range
> > 
> >$ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg 
> > output.jpg
> >... works
> > 
> > 2. Have the JPEG encoder take care of range conversion internally, by
> >using sws to convert limited to full range.
> > 
> > 3. Allow filters to start exposing color space metadata as part of
> >filter negotiation, and then auto-insert swscaler whenever colorspace
> >conversion needs to happen as a result of filters not accepting the
> >corresponding color metadata. This would also allow more than just
> >conversion between limited/full range.
> > 
> > 4. Combine approach 1 with an encoder flag for "supports full range
> >only", and have ffmpeg.c auto-insert a scale filter as the last step
> >before the encoder if this flag is set (and input is limited range).
> > 
> > 1 would be the most explicit but would break any existing pipeline that
> > includes conversion to jpeg, which is probably a very large number.
> > 
> > 2 would be the least work, but violates abstraction boundaries.
> > 
> > 3 would be the most work and is, IMO, of questionable gain.
> > 
> > 4 would be both explicit and not break existing workflows.
> 
> 3 is nice but is hard as it draws filter negotiation in and that has
> to do something even for non trivial filter networks.
> 
> 4 with the complexity in jpeg as disscussed elsewhere in this thread
> also may or may not be as clean as it sounds here
> 
> but both 3 and 4 with some amendment sound reasonable to me
> another option would be to either improve 
> 
> A. general "supported value" information
> a encoder should be able to tell the caller what it supports depending
> on some parameter, for example depending on profile and level
> or std compliance. This would mean implementing AVClass.query_ranges()
> and using av_opt_query_ranges() IIRC
> 
> 
> B. error reporting so that 
> failures become machiene readable. 
> aka, "this failed because color range is not X || std complicance is > Y"
> the lib user could then retry by applying the change if that is within what
> the usecase wants
> 
> Both A and B obvioulsy have a much broader use than YUVJ removal
> 
> thx

So, the biggest roadblock I see with regards to making color range etc.
part of filter negotiation is that, currently, color range (and
colorspace and so on) are part of AVFrame, which can (in theory and
possibly also in practice) change suddenly mid-stream.

So we can't somehow *statically* negotiate the appropriate conversion
filter into the filter graph depending on a value that is only known
after filter negotiation is complete. Fortunately, there is not
currently any filter in ffmpeg that only supports one color range, so we
don't actually *need* filter negotiation for YUVJ removal.

It's straight-forward to add a list of supported color ranges (even
depending on compliance level) into `AVCodec`, but of course, this still
relies on API users knowing to check this new field in order to avoid
potential regressions.

How about having a special conversion layer exist only in front of
encoders (e.g. inside avcodec_send_frame) to deal with incoming frames
that have mismatched metadata relative to what the encoder supports?
With an option to turn it on/off in AVCodecContext.

This would NOT take care of pix_fmt conversion (since the filter chain
already handles that), but merely deal with mismatches between sent
AVFrames and AVCodec advertised capabilities.
___
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] Towards YUVJ removal

[Nicolas George]

Niklas Haas (12022-12-13):
> So, the biggest roadblock I see with regards to making color range etc.
> part of filter negotiation is that, currently, color range (and
> colorspace and so on) are part of AVFrame, which can (in theory and
> possibly also in practice) change suddenly mid-stream.

That is not a problem, a lot of properties are part of AVFrame yet are
not supposed to change mid-stream in libavfilter, starting with the
resolution.

The real issue is not a hard one, but an expensive one: the negotiation
code requires a lot of refactoring, and before that testing coverage,
before we can comfortably add new negotiated properties.

I am not familiar with color ranges. Are they orthogonal to pixel
formats or do they depend on them? In other words, should we negotiate
them both at once, like sample rate, sample format and channel layout,
or should we decide the pixel format first and then the color range? The
plan I have for refactoring the negotiation can do both, but the second
one will require more work.

> How about having a special conversion layer exist only in front of
> encoders (e.g. inside avcodec_send_frame) to deal with incoming frames
> that have mismatched metadata relative to what the encoder supports?

I do not like that idea. But since the real negotiation requires a lot
of work, I will not oppose. Just make sure it is unobtrusive and easily
removed later.

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] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

[Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics]

We made some changes in our EVC wrapper implementation and would like to
submit new patches to patchwork, but it's still unclear to me how to deal
with the MAINTAINERS file. 

Should I leave the following lines:
+  libxevd.c Dawid Kozinski
+  libxeve.c,Dawid Kozinski
+  evc.c, evc.hDawid Kozinski
+  evcdec.c Dawid Kozinski
+  evc_parser.c  Dawid Kozinski

or should I remove them?

We are expecting a clear and consistent standpoint on this matter.



-Original Message-
From: ffmpeg-devel  On Behalf Of Lynne
Sent: piątek, 28 października 2022 23:08
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files

Oct 27, 2022, 18:45 by mich...@niedermayer.cc:

> On Tue, Oct 25, 2022 at 01:17:15PM +0200, Lynne wrote:
>
>>
>>
>>
>> Oct 24, 2022, 18:29 by jamr...@gmail.com:
>>
>> > On 10/24/2022 12:56 PM, Lynne wrote:
>> >
>> >> Oct 24, 2022, 09:42 by d.kozin...@samsung.com:
>> >>
>> >>> - Changelog update
>> >>> - MAINTAINERS update
>> >>>
>> >>> Signed-off-by: Dawid Kozinski 
>> >>> ---
>> >>>  Changelog   | 3 ++-
>> >>>  MAINTAINERS | 5 +
>> >>>  2 files changed, 7 insertions(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/Changelog b/Changelog index ec9de1bd85..19e9ae3b1f 
>> >>> 100644
>> >>> --- a/Changelog
>> >>> +++ b/Changelog
>> >>> @@ -45,6 +45,8 @@ version 5.1:
>> >>>  - remap_opencl filter
>> >>>  - added chromakey_cuda filter
>> >>>  - added bilateral_cuda filter
>> >>> +- eXtra-fast Essential Video Encoder (XEVE)
>> >>> +- eXtra-fast Essential Video Decoder (XEVD)
>> >>>  version 5.0:
>> >>> @@ -92,7 +94,6 @@ version 5.0:
>> >>>  - anlmf audio filter
>> >>>  - IMF demuxer (experimental)
>> >>>  -
>> >>>  version 4.4:
>> >>>  - AudioToolbox output device
>> >>>  - MacCaption demuxer
>> >>> diff --git a/MAINTAINERS b/MAINTAINERS index 
>> >>> eebfa5cfb7..df8d8eca73 100644
>> >>> --- a/MAINTAINERS
>> >>> +++ b/MAINTAINERS
>> >>> @@ -200,6 +200,8 @@ Codecs:
>> >>>  libvpx*   James Zern
>> >>>  libxavs.c Stefan Gehrer
>> >>>  libxavs2.cHuiwen Ren
>> >>> +  libxevd.c Dawid Kozinski
>> >>> +  libxeve.c,Dawid Kozinski
>> >>>  libzvbi-teletextdec.c Marton Balint
>> >>>  lzo.h, lzo.c  Reimar Doeffinger
>> >>>  mdec.cMichael Niedermayer
>> >>> @@ -420,6 +422,9 @@ Muxers/Demuxers:
>> >>>  dv.c  Roman Shaposhnik
>> >>>  electronicarts.c  Peter Ross
>> >>>  epafdec.c Paul B Mahol
>> >>> +  evc.c, evc.h  Dawid Kozinski
>> >>> +  evcdec.c  Dawid Kozinski
>> >>> +  evc_parser.c  Dawid Kozinski
>> >>>  ffm*  Baptiste Coudurier
>> >>>  flic.cMike Melanson
>> >>>  flvdec.c  Michael Niedermayer
>> >>>
>> >>
>> >> Nak, that list is only for those with push access, and no other 
>> >> changes may be made in the same patch.
>> >>
>> >
>> > No, it's the other way around. Those in this list may be eligible for
push access.
>> > Being listed here gives them the right to NAK a patch made for a module
they maintain, as well as their approval being (ideally) a requirement
before making changes to it.
>> >
>>
>> Nope. Michael will give anyone on the list push access.
>>
>
> I have the feeling you dont trust me
> if thats the issue, 2 lists will not fix that
>

I trust you more than others. But in this case, I simply don't understand.


> The idea is that each developer who takes care of a bit of the code 
> base (reviewing patches, approving them, fixing issues, adding 
> features, ...) has the same rights as others.
> That is git write, the list is the MAINAINERs list.
>
> Its not really true that everyone in that file has write access 
> because some people where forgotten and never asked, some simply dont 
> know git well enough, some explicitly said they do not want git write, 
> some sent a lot of messy patches and gave me pause so i didnt offer it and
they also didnt ask.
> The list should be pretty close though, these are all exceptions not the
rule.
>

The maintainers list used to be what jamrial said it was - an informal list
of those with good knowledge on a piece of code to make a review,
independent of whether they had push access or not. This is also how
users/casual patch senders treated it as - they added their name if they
felt like they would like to be consulted on.
The list is always a bit outdated, and that's okay.
You started treating it as a formal list of those with commit access, and
it's been somewhat chaotic. Users still think it's an

[FFmpeg-devel] Dev meeting travel cost reimbursement request

[Niklas Haas]

Hi,

As was stated in the invitation to the Dec 2nd Barcelona dev meeting, my
travel costs would be reimbursed by FFmpeg.

My total travel budget (train+plane+hotel) comes to (slightly above) 500
EUR. I am therefore requesting this amount from the SPI fund.

Whom do I contact?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat: Rename IPFS to IPFS gateway

[Derek Buitenhuis]

On 12/12/2022 3:48 PM, Tomas Härdin wrote:
> I agree verbosity is better here

I'll push with the internal symbol renames removed later today
if nobody objects.

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

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

Re: [FFmpeg-devel] [PATCH] avformat: Rename IPFS to IPFS gateway

[Derek Buitenhuis]

On 12/13/2022 12:44 PM, Derek Buitenhuis wrote:
> I'll push with the internal symbol renames removed later today
> if nobody objects.

[...]

> -const URLProtocol ff_ipfs_protocol = {
> -.name   = "ipfs",
> +const URLProtocol ff_ipfs_gateway_protocol = {
> +.name   = "ipfs_gateway",

Actually, would this break ipfs:// urls? Might need to remove this, too.

- Derek
___
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 v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

[Ronald S. Bultje]

Hi David,

On Tue, Dec 13, 2022 at 7:22 AM Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics  wrote:

> Should I leave the following lines:
> +  libxevd.c Dawid Kozinski
> +  libxeve.c,Dawid Kozinski
> +  evc.c, evc.hDawid Kozinski
> +  evcdec.c Dawid Kozinski
> +  evc_parser.c  Dawid Kozinski
>
> or should I remove them?
>

Here's a question for you, and the answer probably becomes self-evident
from that. If you, Dawid, stop working for Samsung, for example because
you're starting your own business or Samsung fires you or Google hires you,
or if Samsung stops sponsoring this new codec called "EVC" or stops
contributing to this new library "libxeve". Will you, Dawid, still maintain
these files?

If the answer is yes, then you can shorten these lines ("evc*.[ch]: Dawid"
& "livxev[ed].c: Dawid") and keep them.

If the answer is no, then I think you should remove (or adjust) these
lines, since they are (in their current form) inaccurate: you are not
maintaining these files, your company is.

> We are expecting a clear and consistent standpoint on this matter.

This makes no sense: our community is a mish-mash of individuals, each
entitled to their own opinion. If we - as a community - can't agree, you
can ask for a formal opinion from the technical committee.

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

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

Re: [FFmpeg-devel] [PATCH 2/2] av1dec: fix typo in logged error

[Ronald S. Bultje]

Hi,

On Mon, Dec 12, 2022 at 7:54 PM Tristan Matthews 
wrote:

> On Mon, Nov 28, 2022 at 10:39 AM Tristan Matthews 
> wrote:
> >
> > ---
> >  libavcodec/av1dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index 80da0943d4..d83c902f1f 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -567,7 +567,7 @@ static int get_pixel_format(AVCodecContext *avctx)
> >   * implemented in the future, need remove this check.
> >   */
> >  if (!avctx->hwaccel) {
> > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't suppport"
> > +av_log(avctx, AV_LOG_ERROR, "Your platform doesn't support"
> > " hardware accelerated AV1 decoding.\n");
> >  return AVERROR(ENOSYS);
> >  }
> > --
> > 2.34.1
> >
>
> Ping
>

Merged.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] av1dec: fix comment typo

[Ronald S. Bultje]

Hi,

On Mon, Nov 28, 2022 at 10:39 AM Tristan Matthews 
wrote:

> ---
>  libavcodec/av1dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index 0c24eac842..80da0943d4 100644
> --- a/libavcodec/av1dec.c
> +++ b/libavcodec/av1dec.c
> @@ -194,7 +194,7 @@ static uint8_t get_shear_params_valid(AV1DecContext
> *s, int idx)
>  }
>
>  /**
> -* update gm type/params, since cbs already implemented part of this
> funcation,
> +* update gm type/params, since cbs already implemented part of this
> function,
>  * so we don't need to full implement spec.
>  */
>  static void global_motion_params(AV1DecContext *s)
> --
> 2.34.1
>

Pushed.

Ronald
___
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/x86/Makefile: Don't build empty files

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Should fix ticket #9909, fixing a regression since
> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
> 
> Thanks to Carl Eugen Hoyos for analyzing the issue.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> This would be my solution. What do you think of it?
> 
>  libavcodec/x86/Makefile | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 4e448623af..41ca864849 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP)  += x86/qpeldsp.o  
>\
>  X86ASM-OBJS-$(CONFIG_RV34DSP)  += x86/rv34dsp.o
>  X86ASM-OBJS-$(CONFIG_VC1DSP)   += x86/vc1dsp_loopfilter.o   \
>x86/vc1dsp_mc.o
> -X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o   \
> -  x86/simple_idct.o
> +ifdef ARCH_X86_64
> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o
> +else
> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct.o
> +endif
>  X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
>  X86ASM-OBJS-$(CONFIG_VP3DSP)   += x86/vp3dsp.o
>  X86ASM-OBJS-$(CONFIG_VP8DSP)   += x86/vp8dsp.o  \

It seems like that there are linkers out there that complain about empty
object files like x86/simple_idct.o ("ranlib: file:
libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
BBB); the above patch is still needed to fix this. I will therefore
apply it tonight (with an updated commit message) unless there are
objections.

- 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] Dev meeting travel cost reimbursement request

[Michael Niedermayer]

On Tue, Dec 13, 2022 at 01:33:28PM +0100, Niklas Haas wrote:
> Hi,
> 
> As was stated in the invitation to the Dec 2nd Barcelona dev meeting, my
> travel costs would be reimbursed by FFmpeg.
> 
> My total travel budget (train+plane+hotel) comes to (slightly above) 500
> EUR. I am therefore requesting this amount from the SPI fund.
> 
> Whom do I contact?

all refund requests are posted to ffmpeg-devel generally with
"[REFUND-REQUEST]" in the subject
then all developers can discuss / agree or object to it.
after a period of 7 days stefano would forward the request to
SPI (with whatever papers needed to proof the expenses match)
then depending on how busy the SPI treassurer is it can be
very quick or take months for the request to be handled.
Iam saying that so there are no unrealistic expectations on speed

thx

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

Avoid a single point of failure, be that a person or equipment.


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] avformat/file: add fd protocol

[Rémi Denis-Courmont]

Le maanantaina 12. joulukuuta 2022, 19.23.52 EET Zhao Zhili a écrit :
> On Mon, 2022-12-12 at 18:31 +0200, Rémi Denis-Courmont wrote:
> > Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit
> > 
> > > > On Nov 19, 2022, at 02:48, Zhao Zhili 
> > > > wrote:
> > > > 
> > > > From: Zhao Zhili 
> > > > 
> > > > Unlike the pipe protocol, fd protocol has seek support if it
> > > > corresponding to a regular file.
> > > > ---
> > > > Sometimes it's the only way to access files via file descriptor,
> > > > e.g.,
> > > > requesting a shared file on Android:
> > > > https://developer.android.com/training/secure-file-sharing/request-fil
> > > > e
> > > > 
> > > > doc/protocols.texi  | 24 +++
> > > > libavformat/Makefile|  1 +
> > > > libavformat/file.c  | 51
> > > > +
> > > > libavformat/protocols.c |  1 +
> > > > libavformat/version.h   |  4 ++--
> > > > 5 files changed, 79 insertions(+), 2 deletions(-)
> > > 
> > > Ping for review.
> > 
> > VLC does this (with a slightly different syntax, i.e. fd://$NUM) and
> > in
> > hindsight, I think that it was a big mistake.
> > 
> > It should not be possible to refer to an opaque handle from within
> > the URL.
> > This leads to all sorts of mischief, bordering on security issue, in
> > the
> > common case that the URL string is untrusted.
> 
> Could you elaborate on the security issue?

Just guess the FD of some critical process resource (.e.g D-Bus, X11 or 
Wayland connection), , and you can easily cause a DoS. It gets potentially 
worse if you can guess the FD that is used to carry sensitive data, such as 
another clients connection if FFmpeg runs inside some kind of network service.

> > To support this use case, IMO, the file descriptor should be passed
> > explicitly
> > via a trusted channel, *not* the URL.
> 
> Does an explicit option works here?
> 
>  static const AVOption pipe_options[] = {
>  { "blocksize", "set I/O operation maximum block size",
> offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX },
> 1, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> +{ "fd", "set file descriptor", offsetof(FileContext, fd),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM
> },
>  { NULL }
>  };

That seems more reasonable, so I cannot comment on the specifics of AVOption 
usage.


-- 
Реми Дёни-Курмон
http://www.remlab.net/



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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/file: add fd protocol

[Rémi Denis-Courmont]

Le sunnuntaina 11. joulukuuta 2022, 17.17.27 EET Zhao Zhili a écrit :
> From: Zhao Zhili 
> 
> Unlike the pipe protocol, fd protocol has seek support if it
> corresponding to a regular file.
> ---
> v2: dup the file descriptor for safety
> 
>  doc/protocols.texi  | 24 ++
>  libavformat/Makefile|  1 +
>  libavformat/file.c  | 55 +
>  libavformat/protocols.c |  1 +
>  libavformat/version.h   |  4 +--
>  5 files changed, 83 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 5e9198e67c..d9f2d2dec3 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -275,6 +275,30 @@ For example, to convert a GIF file given inline with
> @command{ffmpeg}: ffmpeg -i
> "data:image/gif;base64,R0lGODdhCAAIAMIE//8AAP//AP///ywA
> CAAIAAADF0gEDLojDgdGiJdJqUX02iB4E8Q9jUMkADs=" smiley.png @end example
> 
> +@section fd
> +
> +File descriptor access protocol.
> +
> +The accepted syntax is:
> +@example
> +fd:[@var{number}]
> +@end example
> +
> +@var{number} is the number corresponding to a file descriptor. Unlike the
> pipe +protocol, fd protocol has seek support if it corresponding to a
> regular file. +If @var{number} is not specified, by default the stdout file
> descriptor will +be used for writing, stdin for reading.
> +
> +This protocol accepts the following options:
> +
> +@table @option
> +@item blocksize
> +Set I/O operation maximum block size, in bytes. Default value is
> +@code{INT_MAX}, which results in not limiting the requested block size.
> +Setting this value reasonably low improves user termination request
> reaction +time, which is valuable if data transmission is slow.
> +@end table
> +
>  @section file
> 
>  File access protocol.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index d7f198bf39..1452216e29 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -647,6 +647,7 @@ OBJS-$(CONFIG_DATA_PROTOCOL) += data_uri.o
>  OBJS-$(CONFIG_FFRTMPCRYPT_PROTOCOL)  += rtmpcrypt.o rtmpdigest.o
> rtmpdh.o OBJS-$(CONFIG_FFRTMPHTTP_PROTOCOL)   += rtmphttp.o
>  OBJS-$(CONFIG_FILE_PROTOCOL) += file.o
> +OBJS-$(CONFIG_FD_PROTOCOL)   += file.o
>  OBJS-$(CONFIG_FTP_PROTOCOL)  += ftp.o urldecode.o
>  OBJS-$(CONFIG_GOPHER_PROTOCOL)   += gopher.o
>  OBJS-$(CONFIG_GOPHERS_PROTOCOL)  += gopher.o
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 6103c37b34..b8725c1f48 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -109,6 +109,13 @@ static const AVClass pipe_class = {
>  .version= LIBAVUTIL_VERSION_INT,
>  };
> 
> +static const AVClass fd_class = {
> +.class_name = "fd",
> +.item_name  = av_default_item_name,
> +.option = pipe_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
>  static int file_read(URLContext *h, unsigned char *buf, int size)
>  {
>  FileContext *c = h->priv_data;
> @@ -412,3 +419,51 @@ const URLProtocol ff_pipe_protocol = {
>  };
> 
>  #endif /* CONFIG_PIPE_PROTOCOL */
> +
> +#if CONFIG_FD_PROTOCOL
> +
> +static int fd_open(URLContext *h, const char *filename, int flags)
> +{
> +FileContext *c = h->priv_data;
> +int fd;
> +char *final;
> +struct stat st;
> +
> +av_strstart(filename, "fd:", &filename);
> +
> +fd = strtol(filename, &final, 10);
> +if ((filename == final) || *final ) {
> +if (flags & AVIO_FLAG_WRITE) {
> +fd = 1;
> +} else {
> +fd = 0;
> +}
> +}
> +#if HAVE_SETMODE
> +setmode(fd, O_BINARY);
> +#endif
> +if (fstat(fd, &st) < 0)
> +return AVERROR(errno);
> +h->is_streamed = !(S_ISREG(st.st_mode) || S_ISBLK(st.st_mode));
> +c->fd = dup(fd);

This leaks c->fd into child processes. You need atomic close-on-exec.


-- 
Реми Дёни-Курмон
http://www.remlab.net/



___
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 v5 1/2] lavc: convert frame threading to the receive_frame() pattern

[Michael Niedermayer]

On Mon, Dec 12, 2022 at 10:42:09PM +0100, Timo Rothenpieler wrote:
> From: Anton Khirnov 
> 
> Reorganize the code such that the frame threading code does not call the
> decoders directly, but instead calls back into the generic decoding
> code. This avoids duplicating the logic that wraps the decoder
> invocation and will be useful in the following commits.
> ---
>  libavcodec/decode.c|  62 ++---
>  libavcodec/decode.h|   7 +
>  libavcodec/internal.h  |   7 +
>  libavcodec/pthread_frame.c | 265 -
>  libavcodec/thread.h|  18 +--
>  5 files changed, 236 insertions(+), 123 deletions(-)

this breaks some files 
but seems not 100% reproduceable

this is what i see after the patch when it fails:
[ogg @ 0x56170f3d67c0] Broken file, keyframe not correctly marked.peed= 242x
Error while decoding stream #0:1: Operation not permitted
Last message repeated 128784 times
Error while decoding stream #0:1: Operation not permittedate=N/A speed=9.94x
Last message repeated 118013 times
Error while decoding stream #0:1: Operation not permittedate=N/A speed=4.98x
Last message repeated 131881 times
Error while decoding stream #0:1: Operation not permittedate=N/A speed=3.32x
Last message repeated 131490 times
Error while decoding stream #0:1: Operation not permittedate=N/A speed=2.49x
Last message repeated 26968 times
frame=  106 fps= 50 q=-0.0 Lsize=N/A time=00:00:04.98 bitrate=N/A speed=2.37x   
 
video:50kB audio:215kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
Exiting normally, received signal 2.

i will mail you the file privatly

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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".

Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

[Lynne]

Dec 13, 2022, 13:22 by d.kozin...@samsung.com:

> We made some changes in our EVC wrapper implementation and would like to
> submit new patches to patchwork, but it's still unclear to me how to deal
> with the MAINTAINERS file. 
>
> Should I leave the following lines:
> +  libxevd.c Dawid Kozinski
> +  libxeve.c,Dawid Kozinski
> +  evc.c, evc.hDawid Kozinski
> +  evcdec.c Dawid Kozinski
> +  evc_parser.c  Dawid Kozinski
>
> or should I remove them?
>
> We are expecting a clear and consistent standpoint on this matter.
>

Get rid of them. Michael has made it clear anyone on the list
must have commit rights. I'm not for blocking anyone from having
commit rights, but you've made zero contributions to the project
so far, and maintaining requires some level of dedication.

If you want someone to blame for this, blame Michael. He silently
changed to whom he gives out commit rights, without informing
anyone, and without even joining any discussions when this
question is brought up.
___
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/x86/Makefile: Don't build empty files

[Carl Eugen Hoyos]

Am Di., 13. Dez. 2022 um 16:02 Uhr schrieb Andreas Rheinhardt
:
>
> Andreas Rheinhardt:
> > Should fix ticket #9909, fixing a regression since
> > bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
> >
> > Thanks to Carl Eugen Hoyos for analyzing the issue.
> >
> > Signed-off-by: Andreas Rheinhardt 
> > ---
> > This would be my solution. What do you think of it?
> >
> >  libavcodec/x86/Makefile | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> > index 4e448623af..41ca864849 100644
> > --- a/libavcodec/x86/Makefile
> > +++ b/libavcodec/x86/Makefile
> > @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP)  += 
> > x86/qpeldsp.o \
> >  X86ASM-OBJS-$(CONFIG_RV34DSP)  += x86/rv34dsp.o
> >  X86ASM-OBJS-$(CONFIG_VC1DSP)   += x86/vc1dsp_loopfilter.o   \
> >x86/vc1dsp_mc.o
> > -X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o   \
> > -  x86/simple_idct.o
> > +ifdef ARCH_X86_64
> > +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o
> > +else
> > +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct.o
> > +endif
> >  X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
> >  X86ASM-OBJS-$(CONFIG_VP3DSP)   += x86/vp3dsp.o
> >  X86ASM-OBJS-$(CONFIG_VP8DSP)   += x86/vp8dsp.o  \
>
> It seems like that there are linkers out there that complain about empty
> object files like x86/simple_idct.o ("ranlib: file:
> libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
> BBB); the above patch is still needed to fix this. I will therefore
> apply it tonight (with an updated commit message) unless there are
> objections.

(Three hours is not a lot)

Which toolchain broke?

Thank you, Carl Eugen
___
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]configure: Assume target-os=win32 for toolchain msvc

[Carl Eugen Hoyos]

Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos
:
>
> Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes
> :
> >
> > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos  wrote:
> > >
> > > Hi!
> > >
> > > Attached patch slightly simplifies building with MSVC.
> > >
> > > Please comment, Carl Eugen
> >
> > I don't think any toolchain value should make assumptions about the
> > host it is running on, because between WSL and Wine, you can certainly
> > do a bunch of specific things where this is not true.
>
> If this is true, then my patch is of course incorrect.
> But could you give an example?
> I was under the impression that cl.exe can only run
> in win32.

Ping.
Could you give an example where host-os is not win32 when
compiling with msvc?

Thank you, Carl Eugen
___
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/x86/Makefile: Don't build empty files

[Andreas Rheinhardt]

Carl Eugen Hoyos:
> Am Di., 13. Dez. 2022 um 16:02 Uhr schrieb Andreas Rheinhardt
> :
>>
>> Andreas Rheinhardt:
>>> Should fix ticket #9909, fixing a regression since
>>> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
>>>
>>> Thanks to Carl Eugen Hoyos for analyzing the issue.
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>> This would be my solution. What do you think of it?
>>>
>>>  libavcodec/x86/Makefile | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
>>> index 4e448623af..41ca864849 100644
>>> --- a/libavcodec/x86/Makefile
>>> +++ b/libavcodec/x86/Makefile
>>> @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP)  += 
>>> x86/qpeldsp.o \
>>>  X86ASM-OBJS-$(CONFIG_RV34DSP)  += x86/rv34dsp.o
>>>  X86ASM-OBJS-$(CONFIG_VC1DSP)   += x86/vc1dsp_loopfilter.o   \
>>>x86/vc1dsp_mc.o
>>> -X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o   \
>>> -  x86/simple_idct.o
>>> +ifdef ARCH_X86_64
>>> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o
>>> +else
>>> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct.o
>>> +endif
>>>  X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
>>>  X86ASM-OBJS-$(CONFIG_VP3DSP)   += x86/vp3dsp.o
>>>  X86ASM-OBJS-$(CONFIG_VP8DSP)   += x86/vp8dsp.o  \
>>
>> It seems like that there are linkers out there that complain about empty
>> object files like x86/simple_idct.o ("ranlib: file:
>> libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
>> BBB); the above patch is still needed to fix this. I will therefore
>> apply it tonight (with an updated commit message) unless there are
>> objections.
> 
> (Three hours is not a lot)
> 
> Which toolchain broke?
> 

"Broke" is the wrong word; Xcode emits warnings for empty object files.
Said Ronald. I haven't reproduced it myself.

- 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] [REFUND-REQUEST]Travel cost reimbursement request

[Carl Eugen Hoyos]

Hi!

I traveled to Barcelona for the development meeting and request a reimbursement:
Flight Vienna - Barcelona - Vienna: 449,99
Two nights in a hotel in Barcelona: 161,06
Bus to Barcelona center: 5,90

Thank you, Carl Eugen
___
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/x86/Makefile: Don't build empty files

[Carl Eugen Hoyos]

Am Di., 13. Dez. 2022 um 20:03 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Am Di., 13. Dez. 2022 um 16:02 Uhr schrieb Andreas Rheinhardt
> > :
> >>
> >> Andreas Rheinhardt:
> >>> Should fix ticket #9909, fixing a regression since
> >>> bfb28b5ce89f3e950214b67ea95b45e3355c2caf.
> >>>
> >>> Thanks to Carl Eugen Hoyos for analyzing the issue.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>> This would be my solution. What do you think of it?
> >>>
> >>>  libavcodec/x86/Makefile | 7 +--
> >>>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> >>> index 4e448623af..41ca864849 100644
> >>> --- a/libavcodec/x86/Makefile
> >>> +++ b/libavcodec/x86/Makefile
> >>> @@ -140,8 +140,11 @@ X86ASM-OBJS-$(CONFIG_QPELDSP)  += 
> >>> x86/qpeldsp.o \
> >>>  X86ASM-OBJS-$(CONFIG_RV34DSP)  += x86/rv34dsp.o
> >>>  X86ASM-OBJS-$(CONFIG_VC1DSP)   += x86/vc1dsp_loopfilter.o   \
> >>>x86/vc1dsp_mc.o
> >>> -X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o   \
> >>> -  x86/simple_idct.o
> >>> +ifdef ARCH_X86_64
> >>> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct10.o
> >>> +else
> >>> +X86ASM-OBJS-$(CONFIG_IDCTDSP)  += x86/simple_idct.o
> >>> +endif
> >>>  X86ASM-OBJS-$(CONFIG_VIDEODSP) += x86/videodsp.o
> >>>  X86ASM-OBJS-$(CONFIG_VP3DSP)   += x86/vp3dsp.o
> >>>  X86ASM-OBJS-$(CONFIG_VP8DSP)   += x86/vp8dsp.o  \
> >>
> >> It seems like that there are linkers out there that complain about empty
> >> object files like x86/simple_idct.o ("ranlib: file:
> >> libavcodec/libavcodec.a(simple_idct.o) has no symbols" as reported by
> >> BBB); the above patch is still needed to fix this. I will therefore
> >> apply it tonight (with an updated commit message) unless there are
> >> objections.
> >
> > (Three hours is not a lot)
> >
> > Which toolchain broke?
>
> "Broke" is the wrong word; Xcode emits warnings for empty object files.

It does.
(I did not consider this an issue when I saw it.)

I consider this unmaintainable, an argument that in the past was
used to object significantly more important patches (in cases
where maintenance was imo no problem).

Anyway: No objection.

Carl Eugen
___
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]configure: Assume target-os=win32 for toolchain msvc

[Hendrik Leppkes]

On Tue, Dec 13, 2022 at 8:02 PM Carl Eugen Hoyos  wrote:
>
> Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes
> > :
> > >
> > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos  
> > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > Attached patch slightly simplifies building with MSVC.
> > > >
> > > > Please comment, Carl Eugen
> > >
> > > I don't think any toolchain value should make assumptions about the
> > > host it is running on, because between WSL and Wine, you can certainly
> > > do a bunch of specific things where this is not true.
> >
> > If this is true, then my patch is of course incorrect.
> > But could you give an example?
> > I was under the impression that cl.exe can only run
> > in win32.
>
> Ping.
> Could you give an example where host-os is not win32 when
> compiling with msvc?
>

When using wine, your host is linux.

- Hendrik
___
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/x86/Makefile: Don't build empty files

[Ronald S. Bultje]

Hi,

On Tue, Dec 13, 2022 at 2:12 PM Carl Eugen Hoyos  wrote:

> It does.
> (I did not consider this an issue when I saw it.)
>
> I consider this unmaintainable, an argument that in the past was
> used to object significantly more important patches (in cases
> where maintenance was imo no problem).
>
> Anyway: No objection.
>

It's not that it's a big deal, just that it's mildly annoying and there
doesn't appear to be an obvious downside to fixing it.

Ronald
___
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] swscale/output: Use av_sat_add32 in yuv2rgba64 templates to avoid underflow

[Michael Niedermayer]

Hi

On Mon, Dec 12, 2022 at 08:08:28PM +, Drew Dunne wrote:
> Previously I sent this patch to solve an overflow in these templates. That
> patch wasn't used in favor of one that biased the output calculations to
> avoid the double clipping. Now I've found an underflow case, which I've put
> the command below, and I'll attach an input image in a reply.
> 
> ./ffmpeg \
>   -f rawvideo -video_size 64x64 -pixel_format yuva420p10le \
>   -i yuv2rgb_underflow_w64h64.yuva \
>   -filter_complex \
>   
> "scale=flags=bicubic+full_chroma_int+full_chroma_inp+bitexact+accurate_rnd:in_color_matrix=bt2020:out_color_matrix=bt2020:in_range=mpeg:out_range=mpeg,format=rgba64[out]"
>  \
>   -f rawvideo -codec:v:0 rawvideo -pixel_format rgba64 -map '[out]' \
>   -y underflow_w64h64.rgba64

can you trigger a under/overflow with real input ?
I mean something where each pixel has a RGB value that can be represented
or is close to such value

Iam asking because if this never happens with real input then a solution
would be to use unsigend ints

If this happens with real input values then input values from
0.0 to 1.0 would have to generate a -1.5 or +2.5 on output
thats quite a overshoot
your example if iam reading it correctly uses white and black pixls
with which have chroma values maxed out. but white and black in reality
would have all R=G=B and thus no color,

the extra cliping takes time and it does not feel like the correct fix for
this
If someone gives me a pixel that has luma only achievable with R=G=B=0 and
then at  the same time chroma only achievable with G=R=MAX B=0 or something
similar. and then the surrounding pixels also add more overshooting during
scaling then iam not sure in which situation the actually color matters
because this is not a "real" color

That said, if you can make a change that handles such odd fuzzed cases
with cliping i dont mind but i think we should not slow down real input
for cases that are not as long as we correct all undefined behavior
and of course ensure this cannot actually occur with real input

Now as you send a 2nd such patch i thought i explain my view a bit better

also does this atually trigger under/overflows in all teh chnaged components
or just some of teh components ?

thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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]configure: Assume target-os=win32 for toolchain msvc

[Carl Eugen Hoyos]

Am Di., 13. Dez. 2022 um 20:21 Uhr schrieb Hendrik Leppkes
:
>
> On Tue, Dec 13, 2022 at 8:02 PM Carl Eugen Hoyos  wrote:
> >
> > Am So., 27. Nov. 2022 um 18:42 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Hendrik Leppkes
> > > :
> > > >
> > > > On Sun, Nov 27, 2022 at 6:13 PM Carl Eugen Hoyos  
> > > > wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > Attached patch slightly simplifies building with MSVC.
> > > > >
> > > > > Please comment, Carl Eugen
> > > >
> > > > I don't think any toolchain value should make assumptions about the
> > > > host it is running on, because between WSL and Wine, you can certainly
> > > > do a bunch of specific things where this is not true.
> > >
> > > If this is true, then my patch is of course incorrect.
> > > But could you give an example?
> > > I was under the impression that cl.exe can only run
> > > in win32.
> >
> > Ping.
> > Could you give an example where host-os is not win32 when
> > compiling with msvc?
> >
>
> When using wine, your host is linux.

Understood, thank you!

Carl Eugen
___
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]configure: Assume target-os=win32 for toolchain msvc

[Timo Rothenpieler]

On 13.12.2022 20:00, Carl Eugen Hoyos wrote:

Ping.
Could you give an example where host-os is not win32 when
compiling with msvc?


WSL, which I quite regularly use to test MSVC builds.
Just need to launch it from inside an msvc shell.
___
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 v6] lavc: convert frame threading to the receive_frame() pattern

[Timo Rothenpieler]

From: Anton Khirnov 

Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
 libavcodec/decode.c|  62 ++---
 libavcodec/decode.h|   7 +
 libavcodec/internal.h  |   7 +
 libavcodec/pthread_frame.c | 279 -
 libavcodec/thread.h|  18 +--
 5 files changed, 247 insertions(+), 126 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3e5be501b9..5d2b484b66 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -180,6 +180,11 @@ fail:
 return ret;
 }
 
+#if !HAVE_THREADS
+#define ff_thread_get_packet(avctx, pkt) (AVERROR_BUG)
+#define ff_thread_receive_frame(avctx, frame) (AVERROR_BUG)
+#endif
+
 int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
 {
 AVCodecInternal *avci = avctx->internal;
@@ -188,7 +193,14 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket 
*pkt)
 if (avci->draining)
 return AVERROR_EOF;
 
-ret = av_bsf_receive_packet(avci->bsf, pkt);
+/* If we are a worker thread, get the next packet from the threading
+ * context. Otherwise we are the main (user-facing) context, so we get the
+ * next packet from the input filterchain.
+ */
+if (avctx->internal->is_frame_mt)
+ret = ff_thread_get_packet(avctx, pkt);
+else
+ret = av_bsf_receive_packet(avci->bsf, pkt);
 if (ret == AVERROR_EOF)
 avci->draining = 1;
 if (ret < 0)
@@ -273,30 +285,25 @@ static inline int decode_simple_internal(AVCodecContext 
*avctx, AVFrame *frame,
 return AVERROR_EOF;
 
 if (!pkt->data &&
-!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
-  avctx->active_thread_type & FF_THREAD_FRAME))
+!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
 return AVERROR_EOF;
 
 got_frame = 0;
 
-if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
-ret = ff_thread_decode_frame(avctx, frame, &got_frame, pkt);
-} else {
-ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
-
-if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
-frame->pkt_dts = pkt->dts;
-if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if(!avctx->has_b_frames)
-frame->pkt_pos = pkt->pos;
-//FIXME these should be under if(!avctx->has_b_frames)
-/* get_buffer is supposed to set frame parameters */
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
-if (!frame->sample_aspect_ratio.num)  
frame->sample_aspect_ratio = avctx->sample_aspect_ratio;
-if (!frame->width)frame->width 
  = avctx->width;
-if (!frame->height)   frame->height
  = avctx->height;
-if (frame->format == AV_PIX_FMT_NONE) frame->format
  = avctx->pix_fmt;
-}
+ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
+
+if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
+frame->pkt_dts = pkt->dts;
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if(!avctx->has_b_frames)
+frame->pkt_pos = pkt->pos;
+//FIXME these should be under if(!avctx->has_b_frames)
+/* get_buffer is supposed to set frame parameters */
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
+if (!frame->sample_aspect_ratio.num)  frame->sample_aspect_ratio = 
avctx->sample_aspect_ratio;
+if (!frame->width)frame->width   = 
avctx->width;
+if (!frame->height)   frame->height  = 
avctx->height;
+if (frame->format == AV_PIX_FMT_NONE) frame->format  = 
avctx->pix_fmt;
 }
 }
 emms_c();
@@ -546,7 +553,7 @@ static int decode_simple_receive_frame(AVCodecContext 
*avctx, AVFrame *frame)
 return 0;
 }
 
-static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
 {
 AVCodecInternal *avci = avctx->internal;
 const FFCodec *const codec = ffcodec(avctx->codec);
@@ -569,6 +576,17 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 return ok;
 }
 
+return ret;
+}
+
+static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+{
+int ret;
+if (avctx->active_thread_type & FF_THREAD_FRAME)
+ret = ff_thread_receive_frame(avctx, frame);
+else
+ret = ff_decode_receive_frame_internal(avctx, frame);
+
 if (!ret) {
 frame->best_effort_timestamp = guess_correct_pts(avctx,

Re: [FFmpeg-devel] [PATCH v2 01/13] lavc/hevc_ps: remove profile limitation of pps_range_extensions()

[Wang, Fei W]

On Mon, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> Follow spec 7.3.2.3.1.
> 
> Signed-off-by: Fei Wang 
> ---
> update:
> 1. fix uninitialized variable which may cause segment fault.

Ping for review this patchset.

Confirmed with Qemu locally for Loongarch64 with:
https://github.com/sunhaiyong1978/CLFS-for-LoongArch/releases/tag/7.0

The FATE test hevc-conformance-PS_A_VIDYO_3 pass without any error.

Thanks
Fei

> 
>  libavcodec/hevc_ps.c |  2 +-
>  tests/ref/fate/hevc-conformance-PS_A_VIDYO_3 | 50 ++--
> 
>  2 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 5fe62ec35b..537a3ff99b 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -1658,7 +1658,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> AVCodecContext *avctx,
>  if (get_bits1(gb)) { // pps_extension_present_flag
>  pps->pps_range_extensions_flag = get_bits1(gb);
>  skip_bits(gb, 7); // pps_extension_7bits
> -if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT
> && pps->pps_range_extensions_flag) {
> +if (pps->pps_range_extensions_flag) {
>  if ((ret = pps_range_extensions(gb, avctx, pps, sps)) <
> 0)
>  goto err;
>  }
> diff --git a/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> b/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> index 59b82b72bb..d1d86b2dc9 100644
> --- a/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> +++ b/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> @@ -3,28 +3,28 @@
>  #codec_id 0: rawvideo
>  #dimensions 0: 416x240
>  #sar 0: 0/1
> -0,  0,  0,1,   149760, 0x88619f80
> -0,  1,  1,1,   149760, 0x550bdaf0
> -0,  2,  2,1,   149760, 0x4121f7a2
> -0,  3,  3,1,   149760, 0x210b1d07
> -0,  4,  4,1,   149760, 0x731b7758
> -0,  5,  5,1,   149760, 0x17adb789
> -0,  6,  6,1,   149760, 0x98b2f080
> -0,  7,  7,1,   149760, 0xc0be1f2a
> -0,  8,  8,1,   149760, 0xc01e387a
> -0,  9,  9,1,   149760, 0xd932822b
> -0, 10, 10,1,   149760, 0x16c0a1df
> -0, 11, 11,1,   149760, 0x5aa6c005
> -0, 12, 12,1,   149760, 0xd3aab602
> -0, 13, 13,1,   149760, 0x4e6ecab1
> -0, 14, 14,1,   149760, 0x8a86f1f2
> -0, 15, 15,1,   149760, 0x2ed21e1b
> -0, 16, 16,1,   149760, 0x80892f24
> -0, 17, 17,1,   149760, 0xb8a952ef
> -0, 18, 18,1,   149760, 0x557e57fb
> -0, 19, 19,1,   149760, 0x2b825b2c
> -0, 20, 20,1,   149760, 0x30b69b5e
> -0, 21, 21,1,   149760, 0x802ebf08
> -0, 22, 22,1,   149760, 0x95aadc8e
> -0, 23, 23,1,   149760, 0x4d4c02b7
> -0, 24, 24,1,   149760, 0x3fdd1762
> +0,  0,  0,1,   149760, 0x5c4f70f4
> +0,  1,  1,1,   149760, 0xf4628e59
> +0,  2,  2,1,   149760, 0xa28e5bdc
> +0,  3,  3,1,   149760, 0xda0e53d7
> +0,  4,  4,1,   149760, 0x42dd334a
> +0,  5,  5,1,   149760, 0x25ba9dfe
> +0,  6,  6,1,   149760, 0x8854d8ca
> +0,  7,  7,1,   149760, 0xc04505d4
> +0,  8,  8,1,   149760, 0xd3fce146
> +0,  9,  9,1,   149760, 0x8bfd88bd
> +0, 10, 10,1,   149760, 0x33d965b2
> +0, 11, 11,1,   149760, 0x12746b7a
> +0, 12, 12,1,   149760, 0xb7642694
> +0, 13, 13,1,   149760, 0x32b5035f
> +0, 14, 14,1,   149760, 0x7bea0af1
> +0, 15, 15,1,   149760, 0x577d4fc8
> +0, 16, 16,1,   149760, 0x023a9c66
> +0, 17, 17,1,   149760, 0x9abe76c4
> +0, 18, 18,1,   149760, 0x2b14dba5
> +0, 19, 19,1,   149760, 0x7b8affcf
> +0, 20, 20,1,   149760, 0x21e4c323
> +0, 21, 21,1,   149760, 0xf0b7d9cd
> +0, 22, 22,1,   149760, 0x4db0c5bc
> +0, 23, 23,1,   149760, 0xf455f752
> +0, 24, 24,1,   149760, 0x569fec99
___
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] FFMpeg media concatenation issue

[Sagar Upadhyay]

Preview attachment ffmpegerror.PNG
ffmpegerror.PNG
85 KB
Hello,

I am using FFmpeg for concatenating videos, images, background images, and
set background audio.
I have done all things and it's working on my system but while I am using
the same command on another system and on the server, it's showing me
stream related error.

Can you please help me with this issue?

I've attached a screenshot of the error message which I'm getting.

Thanks & Regards
Sagar Upadhyay
*Abbacus Technologies*
Skype: live:.cid.15b5ae379d6c78b7
UK: +44 207 193 3428 <+442071933428> | US: +1 201 204 9318 <+12012049318>
IND: +91 79 400 500 60 <+917940050060>
 WEB 
___
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 media concatenation issue

[jb]

Am 14.12.22 um 07:22 schrieb Sagar Upadhyay:

Preview attachment ffmpegerror.PNG
ffmpegerror.PNG
85 KB
Hello,

I am using FFmpeg for concatenating videos, images, background images, and
set background audio.
I have done all things and it's working on my system but while I am using
the same command on another system and on the server, it's showing me
stream related error.

Can you please help me with this issue?

I've attached a screenshot of the error message which I'm getting.


Hello,

I think is better and more save to specify the streams correctly, with 
[0:v] | [0:a] | [1:v] | [1:a] and so on. This is also the way in the 
documentation: https://ffmpeg.org/ffmpeg-filters.html#concat





Thanks & Regards
Sagar Upadhyay
*Abbacus Technologies*
Skype: live:.cid.15b5ae379d6c78b7
UK: +44 207 193 3428 <+442071933428> | US: +1 201 204 9318 <+12012049318>
IND: +91 79 400 500 60 <+917940050060>
 WEB 

___
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] FFMpeg media concatenation issue

[Sagar Upadhyay]

Hello Jonbae,

Thank you so much for your quick response, I really appreciate it.
Sorry but I am new to ffmpeg and your help is giving me more support on
this.

But can you please help me with my command string as I am using below
string can you please help me with that is that correct or need to change.

"ffmpeg -i files\167100350475.mp4 -loop 1 -framerate 24 -t 10 -i
files\167100350486.jpg -i files\167100350422.mp4 -t 10 -i
files\16710035042.mp3 -filter_complex
"[0]scale=432:432,setsar=1[vid0];[1]scale=432:432,setsar=1[img1];[2]scale=432:432,setsar=1[vid2];[vid0][0][img1][3][vid2][2]concat=n=3:v=1:a=1"
20221214073824lastvideo.mp4"

In this command, there are 3 media 2 videos and 1 image that I need to
concatenate and there is one audio file that I want to set in the
background.
So the sequence is 1)video 2) image 3) video and I am trying to set the
audio in the background.

The same code is working on my local system but while I am trying to
implement this on my server and it's not working and also the same problem
facing on my other system also.

If you or anyone can help me with this?



Thanks & Regards
Sagar Upadhyay
*Abbacus Technologies*
Skype: live:.cid.15b5ae379d6c78b7
UK: +44 207 193 3428 <+442071933428> | US: +1 201 204 9318 <+12012049318>
IND: +91 79 400 500 60 <+917940050060>
 WEB 


On Wed, Dec 14, 2022 at 12:10 PM jb  wrote:

>
> Am 14.12.22 um 07:22 schrieb Sagar Upadhyay:
> > Preview attachment ffmpegerror.PNG
> > ffmpegerror.PNG
> > 85 KB
> > Hello,
> >
> > I am using FFmpeg for concatenating videos, images, background images,
> and
> > set background audio.
> > I have done all things and it's working on my system but while I am using
> > the same command on another system and on the server, it's showing me
> > stream related error.
> >
> > Can you please help me with this issue?
> >
> > I've attached a screenshot of the error message which I'm getting.
>
> Hello,
>
> I think is better and more save to specify the streams correctly, with
> [0:v] | [0:a] | [1:v] | [1:a] and so on. This is also the way in the
> documentation: https://ffmpeg.org/ffmpeg-filters.html#concat
>
>
> >
> > Thanks & Regards
> > Sagar Upadhyay
> > *Abbacus Technologies*
> > Skype: live:.cid.15b5ae379d6c78b7
> > UK: +44 207 193 3428 <+442071933428> | US: +1 201 204 9318 <+12012049318>
> > IND: +91 79 400 500 60 <+917940050060>
> >  WEB <
> http://www.abbacustechnologies.com/>
> >
> > ___
> > 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".