Re: [FFmpeg-devel] [PATCH] avutil: [LA] use getauxval to do runtime check.

[Steven Liu]

Shiyou Yin  于2023年2月14日周二 20:26写道：
>
> Replace cpucfg with getauxval to avoid crash in case of
> some processor capabilities are not supportted by kernel used.
> ---
>  libavutil/loongarch/cpu.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/libavutil/loongarch/cpu.c b/libavutil/loongarch/cpu.c
> index e4b240bc44..cad8504fde 100644
> --- a/libavutil/loongarch/cpu.c
> +++ b/libavutil/loongarch/cpu.c
> @@ -21,26 +21,18 @@
>
>  #include 
>  #include "cpu.h"
> +#include 
>
> -#define LOONGARCH_CFG2 0x2
> -#define LOONGARCH_CFG2_LSX(1 << 6)
> -#define LOONGARCH_CFG2_LASX   (1 << 7)
> -
> -static int cpu_flags_cpucfg(void)
> +#define LA_HWCAP_LSX(1<<4)
> +#define LA_HWCAP_LASX   (1<<5)
> +static int cpu_flags_getauxval(void)
>  {
>  int flags = 0;
> -uint32_t cfg2 = 0;
> -
> -__asm__ volatile(
> -"cpucfg %0, %1 \n\t"
> -: "+"(cfg2)
> -: "r"(LOONGARCH_CFG2)
> -);
> +int flag  = (int)getauxval(AT_HWCAP);
>
> -if (cfg2 & LOONGARCH_CFG2_LSX)
> +if (flag & LA_HWCAP_LSX)
>  flags |= AV_CPU_FLAG_LSX;
> -
> -if (cfg2 & LOONGARCH_CFG2_LASX)
> +if (flag & LA_HWCAP_LASX)
>  flags |= AV_CPU_FLAG_LASX;
>
>  return flags;
> @@ -49,7 +41,7 @@ static int cpu_flags_cpucfg(void)
>  int ff_get_cpu_flags_loongarch(void)
>  {
>  #if defined __linux__
> -return cpu_flags_cpucfg();
> +return cpu_flags_getauxval();
>  #else
>  /* Assume no SIMD ASE supported */
>  return 0;
> --
> 2.20.1
>
> ___
> 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".


LGTM

Thanks
Steven
___
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] Chromium 110 and ffmpeg 5.1.2

[Neal Gompa]

On Wed, Feb 22, 2023 at 7:28 PM Hendrik Leppkes  wrote:
>
> On Wed, Feb 22, 2023 at 9:42 PM Drew Abbott  wrote:
> >
> > Hello,
> >
> > I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of
> > the errors I get while building has to do with the API for accessing
> > first_dts. It looks like previously it was just a member of AVStream,
> > but now it can only be accessed with av_stream_get_first_dts:
> > https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd
> > I can see now first_dts is a member of FFStream, but I don't know how
> > to go from an AVStream to an FFStream without using internals of
> > libavformat, if that is even possible. How was first_dts accessed in
> > 5.1.2 from an AVStream?
>
> Chrome hacks their ffmpeg rather then fixing their code. You can't
> build it with anything but their canned version.
>

There's an upstream bug for it:
https://bugs.chromium.org/p/chromium/issues/detail?id=1306560

There was an attempt by Andreas Schneider to fix this, but the fix
wasn't complete enough for their testsuite:
https://chromium-review.googlesource.com/c/chromium/src/+/3525614

The Chromium people don't seem to engage with upstream projects (in
particular ffmpeg) based on this lovely gem:
https://bugs.chromium.org/p/chromium/issues/detail?id=1306560#c8

In Fedora, we're carrying the patch, as it seems to work for us. I
hope the fix lands upstream someday.




--
真実はいつも一つ！/ 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".

Re: [FFmpeg-devel] [PATCH v3 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats

[Wu, Tong1]

> On 2/13/2023 11:45 PM, Tong Wu wrote:
> > Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
> >
> > The added formats work with qsv acceleration and will not have impact
> > on d3d11va acceleration(-hwaccel d3d11va) since so far these formats
> > are still not supported by using d3d11va acceleration.
> >
> > Hwupload and hwdownload can work with the added formats.
> >
> > Signed-off-by: Tong Wu 
> > ---
> >   libavutil/hwcontext_d3d11va.c | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_d3d11va.c
> > b/libavutil/hwcontext_d3d11va.c index 363ec6a47d..aa50538d64 100644
> > --- a/libavutil/hwcontext_d3d11va.c
> > +++ b/libavutil/hwcontext_d3d11va.c
> > @@ -89,6 +89,13 @@ static const struct {
> >   { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
> >   { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
> >   { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
> > +{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
> 
> Shouldn't this be VUYA?

Please refer to 
https://learn.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format

According to the doc, The mapping to the view channel is 
V->R8, 
U->G8, 
Y->B8, 
and A->A8.

It is equivalent to AV_PIX_FMT_VUYX in FFmpeg. Thanks.

> 
> > +{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
> > +{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
> > +{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
> > +{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
> > +{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
> > +{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
> >   // Special opaque formats. The pix_fmt is merely a place holder, as 
> > the
> >   // opaque format cannot be accessed directly.
> >   { DXGI_FORMAT_420_OPAQUE,   AV_PIX_FMT_YUV420P },
> ___
> 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] [PATCH] dash metadata: Added other supported fields besides title only

[Davy Durham]

Now metadata fields for source, copyright, lang and moreInformationURL 
are supported too.  Evidence for the need of such support: 
https://docs.rs/dash-mpd/0.6.3/dash_mpd/struct.ProgramInformation.html 
and 
https://github.com/DroidFreak32/myjio_unrestrict/blob/805a8b48d02c5618608bf6fb2bfc2b450f1f057a/smali_classes2/com/google/android/exoplayer2/source/dash/manifest/ProgramInformation.smali#L19


Signed-off-by: Davy Durham 
---
 libavformat/dashenc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 295b01e225..e45eca3468 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1141,6 +1141,10 @@ static int write_manifest(AVFormatContext *s, int 
final)

 int use_rename = proto && !strcmp(proto, "file");
 static unsigned int warned_non_file = 0;
 AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
+AVDictionaryEntry *source = av_dict_get(s->metadata, "source", 
NULL, 0);
+AVDictionaryEntry *copyright = av_dict_get(s->metadata, 
"copyright", NULL, 0);

+AVDictionaryEntry *lang = av_dict_get(s->metadata, "lang", NULL, 0);
+AVDictionaryEntry *moreInformationURL = av_dict_get(s->metadata, 
"moreInformationURL", NULL, 0);

 AVDictionary *opts = NULL;
  if (!use_rename && !warned_non_file++)
@@ -1203,6 +1207,26 @@ static int write_manifest(AVFormatContext *s, int 
final)

 avio_printf(out, "\t\t%s\n", escaped);
 av_free(escaped);
 }
+if (source) {
+char *escaped = xmlescape(source->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (copyright) {
+char *escaped = xmlescape(copyright->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (lang) {
+char *escaped = xmlescape(lang->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (moreInformationURL) {
+char *escaped = xmlescape(moreInformationURL->value);
+avio_printf(out, 
"\t\t%s\n", escaped);

+av_free(escaped);
+}
 avio_printf(out, "\t\n");
  avio_printf(out, "\t\n");
--
2.25.1

___
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] Chromium 110 and ffmpeg 5.1.2

[Hendrik Leppkes]

On Wed, Feb 22, 2023 at 9:42 PM Drew Abbott  wrote:
>
> Hello,
>
> I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of
> the errors I get while building has to do with the API for accessing
> first_dts. It looks like previously it was just a member of AVStream,
> but now it can only be accessed with av_stream_get_first_dts:
> https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd
> I can see now first_dts is a member of FFStream, but I don't know how
> to go from an AVStream to an FFStream without using internals of
> libavformat, if that is even possible. How was first_dts accessed in
> 5.1.2 from an AVStream?

Chrome hacks their ffmpeg rather then fixing their code. You can't
build it with anything but their canned version.

- 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] Chromium 110 and ffmpeg 5.1.2

[Timo Rothenpieler]

On 22.02.2023 21:41, Drew Abbott wrote:

Hello,

I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of
the errors I get while building has to do with the API for accessing
first_dts. It looks like previously it was just a member of AVStream,
but now it can only be accessed with av_stream_get_first_dts:
https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd
I can see now first_dts is a member of FFStream, but I don't know how
to go from an AVStream to an FFStream without using internals of
libavformat, if that is even possible. How was first_dts accessed in
5.1.2 from an AVStream?


first_dts is a purely internal field of libavformat, you can't access it 
from outside of it.
av_stream_get_first_dts() is not a function I see anywhere in the ffmpeg 
codebase.

___
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] Chromium 110 and ffmpeg 5.1.2

[Drew Abbott]

Hello,

I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of
the errors I get while building has to do with the API for accessing
first_dts. It looks like previously it was just a member of AVStream,
but now it can only be accessed with av_stream_get_first_dts:
https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd
I can see now first_dts is a member of FFStream, but I don't know how
to go from an AVStream to an FFStream without using internals of
libavformat, if that is even possible. How was first_dts accessed in
5.1.2 from an AVStream?

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Jonathan Gee]

I had noticed fdk is specifically looking for the qscale flag, and
otherwise does not do anything with global_quality.  I suppose the change
is risky for anyone who is setting both global quality and qscale, but with
the current code, it seems incorrect to have a conditional based on the
scaled option and not account for the scaling.

if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
int mode = s->vbr ? s->vbr : avctx->global_quality;

On Wed, Feb 22, 2023 at 9:16 AM Timo Rothenpieler 
wrote:

> On 22.02.2023 17:46, Gyan Doshi wrote:
> >
> >
> > On 2023-02-22 10:12 pm, Timo Rothenpieler wrote:
> >> On 22.02.2023 17:33, Gyan Doshi wrote:
> >>> From
> >>>
> >>> fftools\ffmpeg_mux_init.c
> >>> 619:ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale
> >>>
> >>> Regards,
> >>> Gyan
> >>
> >> But that's only if you set the old qscale CLI options.
> >> If you set the global_quality option directly, there is no factor
> >> applied.
> >>
> >> By dividing by FF_QP2LAMBDA you break setting this value via
> >> global_quality, and instead add support for setting it via the old and
> >> pretty much abandoned qscale interface.
> >
> > FWIW, that's what LAME does.
> >
> > libavcodec\libmp3lame.c
> > 119:lame_set_VBR_quality(s->gfp, avctx->global_quality /
> > (float)FF_QP2LAMBDA);
> >
> > global_quality semantics seem overloaded. Maybe we should just redirect
> > user to priv vbr  and error out in fdk init.
> >
> > Regards,
> > Gyan
>
> It's pretty much a matter of "what did this code always do in the past".
> It then got to stick to it, cause otherwise we break downstream API and
> CLI consumers.
>
> The mp3lame code is probably old enough that qscale was still the
> default at the time.
> Nowadays it's global_quality.
>
> Both of those options mapping to the same field in avctx, one with a
> magic factor applies, is definitely and oddity.
> ___
> 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] How to implement pcap ffmpeg format?

[sonntex]

> On Wed, Feb 22, 2023 at 6:00 PM Zhao Zhili  wrote:
>
> You missed the point. Use any (streaming) container which supports the
codec, e.g., webm.

I've already discussed solutions with ivf and h264 byte stream which are
the same as webm but even easier in implementation. They are not applicable.
___
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] How to implement pcap ffmpeg format?

[Zhao Zhili]

> 在 2023年2月23日，01:22，sonntex  写道：
> 
> Are you sure that vp8 and vp9 can be put to mpeg-ts?

You missed the point. Use any (streaming) container which supports the codec, 
e.g., webm.

Please don’t top post.

> 
> On Wed, Feb 22, 2023 at 3:25 PM Zhao Zhili  wrote:
> 
>>> -Original Message-
>>> From: ffmpeg-devel  On Behalf Of
>> sonntex
>>> Sent: 2023年2月22日 21:59
>>> To: FFmpeg development discussions and patches 
>>> Subject: Re: [FFmpeg-devel] How to implement pcap ffmpeg format?
>>> 
>>> So, if I have an rtp stream inside my application and want to save it
>>> somehow to a playable media container, I have to wrap this stream to
>>> something that could be transferred by pipe to ffmpeg, for instance to
>> ivf
>>> or to h264 byte stream. The first format requires deep codec parsing to
>> 
>> Why not remux RTP to something like TS at the first replace, instead of
>> deal with pcap?
>> 
>>> extract at least width and height, perhaps other properties. Seems easy
>> but
>>> non-unified. Another approach is to pass the stream to a local udp
>> socket,
>>> simultaneously execute and control the ffmpeg process. It could lead to
>>> data loss and requires socket coding in such a simple application.
>>> 
>>> I understand why ffmpeg developers don't want to include pcap support to
>>> ffmpeg but it could be implemented as an external code by somebody else
>> for
>>> whom it seems to be useful. I can't really find any blockers to do that
>>> except that all the code inside rtpdec is encapsulated in its *.c file
>> and
>>> is not accessible from a hypothetical new pcap format. What I found is
>> that
>>> udp.c derives url protocol interface and does the same as pcap format
>>> should do - extract rtp packets from a source and pass it further to
>>> rtpdec. The problem is that pcap format is a format, not a protocol,
>> which
>>> reads data from ffmpeg file protocol. And the question was how to build
>> the
>>> chain of  ->  -> ?
>>> 
>>> On Wed, Feb 22, 2023 at 12:54 PM Rémi Denis-Courmont 
>>> wrote:
>>> 
 Hi,
 
 I agree with Kieran that this doesn't look like it belongs in FFmpeg
>> or in
 any media framework. In fact, Wireshark has some support for extracting
 media from RTP, and that seems like the right place for it.
 
 With that said, you can't realistically pass RTP packets on the
>> standard
 input. RTP is datagram-based. Packet boundaries are relevant; it can't
>> go
 over a pipe. Unless you use a Unix datagram socket as standard input,
>> but
 that would be very weird.
 
 Besides, there may be multiple streams on different ports, with
>> different
 payload maps, and the receiver needs to know which port which packet
>> came
 on.
 
 Note: Unfortunately, earlier attempts to standardise a container for
 RTP/RTCP packets have failed.
 ___
 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] FFmpeg 6.0

[Michael Niedermayer]

On Tue, Feb 21, 2023 at 04:48:41AM -0800, RADSL wrote:
> 
> On 2/21/2023 4:31 AM, Kieran Kunhya wrote:
> > On Tue, 21 Feb 2023, 11:38 Michael Niedermayer, 
> > wrote:
> > 
> > > On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote:
> > > > Hi all
> > > > 
> > > > i plan to branch off release/6.0 from master in the next days
> > > > If theres something blocking and i should wait, please reply here
> > > > 
> > > > 6.0 release will be maybe 1 week after the branch point
> > > > once it has branched all important fixes should be backported of course
> > > What name shall 6.0 bear ?
> > > 
> > > ill pick what has the highest number of votes
> > > 
> > > Here are some previously suggested names:
> > > Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell,
> > > Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von 
> > > Neumann
> > > 
> > > thx.
> > > 
> > I would like to propose "Jemison" after Mae Jemison, the first female
> > African-American in space or Katherine Johnson, mathematician on the Apollo
> > programme.
> > 
> > Kieran
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> suggestion:
> 
> Heavens

Can you clarify who that refers to ? google seems not point to anything clear
like one would get with Ramanujan

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] How to implement pcap ffmpeg format?

[sonntex]

Are you sure that vp8 and vp9 can be put to mpeg-ts?

On Wed, Feb 22, 2023 at 3:25 PM Zhao Zhili  wrote:

> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> sonntex
> > Sent: 2023年2月22日 21:59
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] How to implement pcap ffmpeg format?
> >
> > So, if I have an rtp stream inside my application and want to save it
> > somehow to a playable media container, I have to wrap this stream to
> > something that could be transferred by pipe to ffmpeg, for instance to
> ivf
> > or to h264 byte stream. The first format requires deep codec parsing to
>
> Why not remux RTP to something like TS at the first replace, instead of
> deal with pcap?
>
> > extract at least width and height, perhaps other properties. Seems easy
> but
> > non-unified. Another approach is to pass the stream to a local udp
> socket,
> > simultaneously execute and control the ffmpeg process. It could lead to
> > data loss and requires socket coding in such a simple application.
> >
> > I understand why ffmpeg developers don't want to include pcap support to
> > ffmpeg but it could be implemented as an external code by somebody else
> for
> > whom it seems to be useful. I can't really find any blockers to do that
> > except that all the code inside rtpdec is encapsulated in its *.c file
> and
> > is not accessible from a hypothetical new pcap format. What I found is
> that
> > udp.c derives url protocol interface and does the same as pcap format
> > should do - extract rtp packets from a source and pass it further to
> > rtpdec. The problem is that pcap format is a format, not a protocol,
> which
> > reads data from ffmpeg file protocol. And the question was how to build
> the
> > chain of  ->  -> ?
> >
> > On Wed, Feb 22, 2023 at 12:54 PM Rémi Denis-Courmont 
> > wrote:
> >
> > > Hi,
> > >
> > > I agree with Kieran that this doesn't look like it belongs in FFmpeg
> or in
> > > any media framework. In fact, Wireshark has some support for extracting
> > > media from RTP, and that seems like the right place for it.
> > >
> > > With that said, you can't realistically pass RTP packets on the
> standard
> > > input. RTP is datagram-based. Packet boundaries are relevant; it can't
> go
> > > over a pipe. Unless you use a Unix datagram socket as standard input,
> but
> > > that would be very weird.
> > >
> > > Besides, there may be multiple streams on different ports, with
> different
> > > payload maps, and the receiver needs to know which port which packet
> came
> > > on.
> > >
> > > Note: Unfortunately, earlier attempts to standardise a container for
> > > RTP/RTCP packets have failed.
> > > ___
> > > 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] [PATCH] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Timo Rothenpieler]

On 22.02.2023 17:46, Gyan Doshi wrote:



On 2023-02-22 10:12 pm, Timo Rothenpieler wrote:

On 22.02.2023 17:33, Gyan Doshi wrote:

From

fftools\ffmpeg_mux_init.c
619:    ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale

Regards,
Gyan


But that's only if you set the old qscale CLI options.
If you set the global_quality option directly, there is no factor 
applied.


By dividing by FF_QP2LAMBDA you break setting this value via 
global_quality, and instead add support for setting it via the old and 
pretty much abandoned qscale interface.


FWIW, that's what LAME does.

libavcodec\libmp3lame.c
119:    lame_set_VBR_quality(s->gfp, avctx->global_quality / 
(float)FF_QP2LAMBDA);


global_quality semantics seem overloaded. Maybe we should just redirect 
user to priv vbr  and error out in fdk init.


Regards,
Gyan


It's pretty much a matter of "what did this code always do in the past".
It then got to stick to it, cause otherwise we break downstream API and 
CLI consumers.


The mp3lame code is probably old enough that qscale was still the 
default at the time.

Nowadays it's global_quality.

Both of those options mapping to the same field in avctx, one with a 
magic factor applies, is definitely and oddity.

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Gyan Doshi]

On 2023-02-22 10:12 pm, Timo Rothenpieler wrote:

On 22.02.2023 17:33, Gyan Doshi wrote:

From

fftools\ffmpeg_mux_init.c
619:    ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale

Regards,
Gyan


But that's only if you set the old qscale CLI options.
If you set the global_quality option directly, there is no factor 
applied.


By dividing by FF_QP2LAMBDA you break setting this value via 
global_quality, and instead add support for setting it via the old and 
pretty much abandoned qscale interface.


FWIW, that's what LAME does.

libavcodec\libmp3lame.c
119:    lame_set_VBR_quality(s->gfp, avctx->global_quality / 
(float)FF_QP2LAMBDA);


global_quality semantics seem overloaded. Maybe we should just redirect 
user to priv vbr  and error out in fdk init.


Regards,
Gyan

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Timo Rothenpieler]

On 22.02.2023 17:33, Gyan Doshi wrote:

From

fftools\ffmpeg_mux_init.c
619:    ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale

Regards,
Gyan


But that's only if you set the old qscale CLI options.
If you set the global_quality option directly, there is no factor applied.

By dividing by FF_QP2LAMBDA you break setting this value via 
global_quality, and instead add support for setting it via the old and 
pretty much abandoned qscale interface.

Which is an API break.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Gyan Doshi]

On 2023-02-22 09:39 pm, Timo Rothenpieler wrote:

On 22.02.2023 03:12, JonHGee wrote:
libavcodec/libfdk-aacenc: VBR mode currently does not account for 
scaling when using -aq options with libfdk, resulting in clamping to 
vbr mode 5 whenever a value >0 is provided.  Adjusting for the 
scaling factor for proper VBR support.


---
  libavcodec/libfdk-aacenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 54549de473..da211baf51 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -230,7 +230,7 @@ static av_cold int aac_encode_init(AVCodecContext 
*avctx)

  }
    if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
-    int mode = s->vbr ? s->vbr : avctx->global_quality;
+    int mode = s->vbr ? s->vbr : avctx->global_quality / 
FF_QP2LAMBDA;

  if (mode <  1 || mode > 5) {
  av_log(avctx, AV_LOG_WARNING,
 "VBR quality %d out of range, should be 1-5\n", 
mode);


Won't this break every existing command line and API client that has 
passed a value according to the current scale?


Also, what binds stronger here?
It this "(s->vbr ? s->vbr : avctx->global_quality) / FF_QP2LAMBDA" or 
"s->vbr ? s->vbr : (avctx->global_quality / FF_QP2LAMBDA)"?


In any case, this does not look correct to me.
Where would the sudden multiplication with FF_QP2LAMBDA come from in 
the first place?


From

fftools\ffmpeg_mux_init.c
619:    ost->enc_ctx->global_quality = FF_QP2LAMBDA * qscale

Regards,
Gyan

___
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 v4] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL

[Ronald S. Bultje]

On Wed, Feb 22, 2023 at 8:49 AM Leo Izen  wrote:

> On 2/21/23 20:42, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Feb 21, 2023 at 5:36 PM Leo Izen  > > wrote:
> >
> > These chunks are lightweight and it's useful information to have when
> > running ffmpeg -i or ffprobe, for example.
> >
> >
> > I disagree conceptually with this. If we want to skip "all" decoding, we
> > should also skip metadata for said frames.
> >
> > I think what we're looking for here is a partial decoding stage, e.g.
> > "header-only" or similar, instead of "including framedata", for some or
> > all frames. That's orthogonal to AVDISCARD_*.
> >
> > Ronald
>
> The issue is that libavformat and ffmpeg.c obtain metadata by calling
> the decoder with AVDISCARD_ALL. What you're proposing would require a
> structural change elsewhere, and I'm not sure it makes sense to block a
> patch like this one based on a hypothetical change elsewhere.


That’s fair. I’ll put this in the long term wishlist bucket.

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] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA

[Timo Rothenpieler]

On 22.02.2023 03:12, JonHGee wrote:

libavcodec/libfdk-aacenc: VBR mode currently does not account for scaling when 
using -aq options with libfdk, resulting in clamping to vbr mode 5 whenever a 
value >0 is provided.  Adjusting for the scaling factor for proper VBR support.

---
  libavcodec/libfdk-aacenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 54549de473..da211baf51 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -230,7 +230,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
  }
  
  if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {

-int mode = s->vbr ? s->vbr : avctx->global_quality;
+int mode = s->vbr ? s->vbr : avctx->global_quality / FF_QP2LAMBDA;
  if (mode <  1 || mode > 5) {
  av_log(avctx, AV_LOG_WARNING,
 "VBR quality %d out of range, should be 1-5\n", mode);


Won't this break every existing command line and API client that has 
passed a value according to the current scale?


Also, what binds stronger here?
It this "(s->vbr ? s->vbr : avctx->global_quality) / FF_QP2LAMBDA" or 
"s->vbr ? s->vbr : (avctx->global_quality / FF_QP2LAMBDA)"?


In any case, this does not look correct to me.
Where would the sudden multiplication with FF_QP2LAMBDA come from in the 
first place?

___
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] How to implement pcap ffmpeg format?

[Zhao Zhili]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of sonntex
> Sent: 2023年2月22日 21:59
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] How to implement pcap ffmpeg format?
> 
> So, if I have an rtp stream inside my application and want to save it
> somehow to a playable media container, I have to wrap this stream to
> something that could be transferred by pipe to ffmpeg, for instance to ivf
> or to h264 byte stream. The first format requires deep codec parsing to

Why not remux RTP to something like TS at the first replace, instead of deal 
with pcap?

> extract at least width and height, perhaps other properties. Seems easy but
> non-unified. Another approach is to pass the stream to a local udp socket,
> simultaneously execute and control the ffmpeg process. It could lead to
> data loss and requires socket coding in such a simple application.
> 
> I understand why ffmpeg developers don't want to include pcap support to
> ffmpeg but it could be implemented as an external code by somebody else for
> whom it seems to be useful. I can't really find any blockers to do that
> except that all the code inside rtpdec is encapsulated in its *.c file and
> is not accessible from a hypothetical new pcap format. What I found is that
> udp.c derives url protocol interface and does the same as pcap format
> should do - extract rtp packets from a source and pass it further to
> rtpdec. The problem is that pcap format is a format, not a protocol, which
> reads data from ffmpeg file protocol. And the question was how to build the
> chain of  ->  -> ?
> 
> On Wed, Feb 22, 2023 at 12:54 PM Rémi Denis-Courmont 
> wrote:
> 
> > Hi,
> >
> > I agree with Kieran that this doesn't look like it belongs in FFmpeg or in
> > any media framework. In fact, Wireshark has some support for extracting
> > media from RTP, and that seems like the right place for it.
> >
> > With that said, you can't realistically pass RTP packets on the standard
> > input. RTP is datagram-based. Packet boundaries are relevant; it can't go
> > over a pipe. Unless you use a Unix datagram socket as standard input, but
> > that would be very weird.
> >
> > Besides, there may be multiple streams on different ports, with different
> > payload maps, and the receiver needs to know which port which packet came
> > on.
> >
> > Note: Unfortunately, earlier attempts to standardise a container for
> > RTP/RTCP packets have failed.
> > ___
> > 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] How to implement pcap ffmpeg format?

[sonntex]

So, if I have an rtp stream inside my application and want to save it
somehow to a playable media container, I have to wrap this stream to
something that could be transferred by pipe to ffmpeg, for instance to ivf
or to h264 byte stream. The first format requires deep codec parsing to
extract at least width and height, perhaps other properties. Seems easy but
non-unified. Another approach is to pass the stream to a local udp socket,
simultaneously execute and control the ffmpeg process. It could lead to
data loss and requires socket coding in such a simple application.

I understand why ffmpeg developers don't want to include pcap support to
ffmpeg but it could be implemented as an external code by somebody else for
whom it seems to be useful. I can't really find any blockers to do that
except that all the code inside rtpdec is encapsulated in its *.c file and
is not accessible from a hypothetical new pcap format. What I found is that
udp.c derives url protocol interface and does the same as pcap format
should do - extract rtp packets from a source and pass it further to
rtpdec. The problem is that pcap format is a format, not a protocol, which
reads data from ffmpeg file protocol. And the question was how to build the
chain of  ->  -> ?

On Wed, Feb 22, 2023 at 12:54 PM Rémi Denis-Courmont 
wrote:

> Hi,
>
> I agree with Kieran that this doesn't look like it belongs in FFmpeg or in
> any media framework. In fact, Wireshark has some support for extracting
> media from RTP, and that seems like the right place for it.
>
> With that said, you can't realistically pass RTP packets on the standard
> input. RTP is datagram-based. Packet boundaries are relevant; it can't go
> over a pipe. Unless you use a Unix datagram socket as standard input, but
> that would be very weird.
>
> Besides, there may be multiple streams on different ports, with different
> payload maps, and the receiver needs to know which port which packet came
> on.
>
> Note: Unfortunately, earlier attempts to standardise a container for
> RTP/RTCP packets have failed.
> ___
> 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] How to implement pcap ffmpeg format?

[Devin Heitmueller]

On Wed, Feb 22, 2023 at 7:54 AM Rémi Denis-Courmont  wrote:
> I agree with Kieran that this doesn't look like it belongs in FFmpeg or in 
> any media framework. In fact, Wireshark has some support for extracting media 
> from RTP, and that seems like the right place for it.
>
> With that said, you can't realistically pass RTP packets on the standard 
> input. RTP is datagram-based. Packet boundaries are relevant; it can't go 
> over a pipe. Unless you use a Unix datagram socket as standard input, but 
> that would be very weird.
>
> Besides, there may be multiple streams on different ports, with different 
> payload maps, and the receiver needs to know which port which packet came on.

I generally use tcpreplay for this sort of use case (it replays pcap
files back onto the network and then ffmpeg can receive them).  It
would support the use case with multiple streams.  The timing isn't
perfect though, so if you play files that are many Mbps you might find
the stream is being played out +/- 1% of realtime, which can have some
annoying effects with certain applications.  Also its important to
note that this does mean streams can't be processed faster than
realtime (i.e. you can't process five minutes of RTP packets in a few
seconds).

One other thing worth noting is there can be some unexpected
side-effects of tcpreplay that require you to rewrite MAC addresses if
playing back on a different host than captured on, and rewriting UDP
checksums if the NIC is doing hardware offloading.  As a result I
typically have to preprocess my pcap files (using tcprewrite) prior to
playing them back out.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.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".

Re: [FFmpeg-devel] [PATCH v4] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL

[Leo Izen]

On 2/21/23 20:42, Ronald S. Bultje wrote:

Hi,

On Tue, Feb 21, 2023 at 5:36 PM Leo Izen > wrote:


These chunks are lightweight and it's useful information to have when
running ffmpeg -i or ffprobe, for example.


I disagree conceptually with this. If we want to skip "all" decoding, we 
should also skip metadata for said frames.


I think what we're looking for here is a partial decoding stage, e.g. 
"header-only" or similar, instead of "including framedata", for some or 
all frames. That's orthogonal to AVDISCARD_*.


Ronald


The issue is that libavformat and ffmpeg.c obtain metadata by calling 
the decoder with AVDISCARD_ALL. What you're proposing would require a 
structural change elsewhere, and I'm not sure it makes sense to block a 
patch like this one based on a hypothetical change elsewhere.


- Leo Izen (thebombzen)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] lavc/assenc: set AV_CODEC_CAP_SINGLE_SUB_RECT

[Nicolas George]

Ridley Combs (12023-02-21):
> Fair enough, if we're fine with breaking the existing case further.
> Should I simply drop rectangles after a first, or return an error?

You have to ask? Between reporting an error and silently corrupting
data, the answer is never in doubt.

> This is only true for audio/video encoders; subtitle encoders still
> use a different API, which does not have M:N support. There's some
> long-ongoing work to change that, but for now, this seems like the
> only way to deal with this case before that API overhaul.

Oh, I had forgotten this. In that cas, I would suggest to keep API
changes to a minimum:

- Have assenc print and return an error if there are several rectangles.

- Add a special case in the command-line tool ffmpeg based on the
  encoding codec. Or probably even better, for all text subtitles.

This will not interfere with overhauling the subtitles encoding API.

Of course, other developers might disagree, give it a few days.

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] How to implement pcap ffmpeg format?

[Rémi Denis-Courmont]

Hi,

I agree with Kieran that this doesn't look like it belongs in FFmpeg or in any 
media framework. In fact, Wireshark has some support for extracting media from 
RTP, and that seems like the right place for it.

With that said, you can't realistically pass RTP packets on the standard input. 
RTP is datagram-based. Packet boundaries are relevant; it can't go over a pipe. 
Unless you use a Unix datagram socket as standard input, but that would be very 
weird.

Besides, there may be multiple streams on different ports, with different 
payload maps, and the receiver needs to know which port which packet came on.

Note: Unfortunately, earlier attempts to standardise a container for RTP/RTCP 
packets have failed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats

[James Almer]

On 2/13/2023 11:45 PM, Tong Wu wrote:

Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.

The added formats work with qsv acceleration and will not have
impact on d3d11va acceleration(-hwaccel d3d11va) since so far
these formats are still not supported by using d3d11va acceleration.

Hwupload and hwdownload can work with the added formats.

Signed-off-by: Tong Wu 
---
  libavutil/hwcontext_d3d11va.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 363ec6a47d..aa50538d64 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -89,6 +89,13 @@ static const struct {
  { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
  { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
  { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
+{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },


Shouldn't this be VUYA?


+{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
+{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
+{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
+{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
  // Special opaque formats. The pix_fmt is merely a place holder, as the
  // opaque format cannot be accessed directly.
  { DXGI_FORMAT_420_OPAQUE,   AV_PIX_FMT_YUV420P },

___
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] src/template_head2: Make "community" a seperate page containing Organisation and Code of Conduct.

[Thilo Borgmann]

Am 08.02.23 um 16:48 schrieb Thilo Borgmann:

Forgot to put this in the subject, this patch is for ffmpeg-web, of course.

-Thilo

Am 08.02.23 um 16:47 schrieb Thilo Borgmann:

---
  src/template_head2 | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Pushing soon.

-Thilo

___
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] doc/dev_community: add the addresses of the committees

[Thilo Borgmann]

Am 08.02.23 um 16:57 schrieb Thilo Borgmann:

From: Nicolas George 

Omitting the .org from the address should be protection enough
against spam spiders.

Signed-off-by: Nicolas George 
---
  doc/dev_community/community.md | 4 
  1 file changed, 4 insertions(+)

diff --git a/doc/dev_community/community.md b/doc/dev_community/community.md
index 21e08e20e3..59519393e2 100644
--- a/doc/dev_community/community.md
+++ b/doc/dev_community/community.md
@@ -55,6 +55,8 @@ Candidates for election can either be suggested or 
self-nominated.
  
  The conflict resolution process is detailed in the [resolution process](resolution_process.md) document.
  
+The TC can be contacted at .

+
  ## Community committee
  
  The Community Committee (CC) is here to arbitrage and make decisions when

@@ -77,3 +79,5 @@ The members of the CC can be elected from outside of the GA.
  Candidates for election can either be suggested or self-nominated.
  
  The CC is governed by and responsible for enforcing the Code of Conduct.

+
+The CC can be contacted at .


Pushing both soon.

-Thilo
___
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 4/6] avformat/wavdec: s337m support

[Tomas Härdin]

tis 2023-02-21 klockan 12:30 + skrev Nicolas Gaullier:
> > This is why it is better to demand that these things be explicitly
> > signalled. At the same time a lot of users expect ffmpeg to Just
> > Work, but that is not always possible. Perhaps we should should put
> > this in the manual and tell >spdif/s377m/dolby-e users to RTFM?
> > 
> > > And another point here in this latest edition on my patch serie
> > > is 
> > > that the use of an existing AVOption makes it possible for users
> > > to 
> > > upgrade their command lines just now by adding the option :
> > > ignored in previous version, it will take effect the day they
> > > upgrade 
> > > their ffmpeg version, so the transition can be smooth...
> > 
> > Assuming users read the documentation of course..
> 
> Yes, definitely, at the end, I don't see an option other than RTFM.
> Documentation : I could insert a "dolby_e" section between ac3 and
> flac in decoders.texi.
> But there is nothing specific to dolby_e for real.
> Maybe an overall "stream probing" chapter would be better in
> decoders.texi between "Decoders" and "Video Decoders" chapters; with
> a specific paragraph about the non_pcm_mode option for wav/s337 (and
> later for s302) ?

Hmm. Perhaps. This also touches demuxers to an extent, so perhaps a
section for wavdec with a link to the dolby-e section in the decoder
documentation in that case?

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

Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution

[Tomas Härdin]

tis 2023-02-21 klockan 10:43 + skrev Nicolas Gaullier:
> > I haven't worked enough with S377m to really know, but I do know
> > it's a mess. Is there a way to differentiate "regular" packed 20-
> > bit audio from S377m in wav?
> > 
> > /Tomas
> 
> There is a relevant overview of S337m in this dolby paper:
> https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-tech-doc_1.2.pdf
> Page 25, one can read:
> SMPTE 337M is the primary method by which Dolby E is able to work in
> existing
> facilities and with existing devices. The standard is written such
> that the same AES3
> interface can be shared with the normal PCM audio usage either by
> treating the AES3
> channels independently or by alternating between data and linear PCM
> usage.
> Devices that are specifically designed for SMPTE 337M/Dolby E
> compatibility
> should be able to transition easily between both usages.
> 
> The whole design is to not signal, not differentiate "normal PCM
> audio usage" from s337m.
> And indeed, manufacturers have implemented probing in all their
> hardware/software (be it linear/SDI input, or mxf/wav files input
> etc.).

Right, it's a deliberate mess.

> Note: ARD/ZDF mxf file format being "the" world exception here, as
> dolby_e/non-pcm must be signaled, made explicit:
>  
> https://www.ard.de/ard/die-ard/ARD-ZDF-HDF02a-AVC-I-100-1080i-25-8-Audio-Tracks-100.pdf

This is the correct approach and precisely what I would expect in the
MXF space. You make it possible to probe in case you have stupid
hardware, but you also explicitly signal it in the container for
systems that are capable of carrying that over.

I will note that Dolby-E support in mxfdec seems to have been in
Baptiste's mind when he first committed the code:

>   //{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x02,0x03,0x02
> ,0x1C,0x00 }, 15,AV_CODEC_ID_DOLBY_E }, /* Dolby-E */

Since ccba07d12c. It remains commented out to this day.

Anyway I don't think this has to hold up this patchset. If it works it
works. We can always improve this later if necessary.

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

[FFmpeg-devel] [PATCH] Fix broken build on Android due to broken asm-generic/termbits.h include

[copypaste]

 
 
 
Best,
 
Fred Brennan (copypaste.wtf)
 

 

 

 
 
 From e9a889bfbf38bda7855792edd8248f4f4a56af7e Mon Sep 17 00:00:00 2001
From: Fredrick Brennan 
Date: Tue, 21 Feb 2023 12:58:38 -0500
Subject: [PATCH 1/2] Fix build on Android due to termbits.h collision!

Applied to libavcodec/aaccoder.c:
:%s/\([*]\)\?\([ \t]\{-}\)\?\(\<[BD-Z]\([0-9]*\)\)\>/\1\2_\3/g

This stops B0 and B1 from colliding with a define in
/usr/include/asm-generic/termbits.h:

```c
```

Because of other defines in the file I used a more inclusive regex as
there's a warning at top that it's autogenerated and may be expanded.
---
 libavcodec/aaccoder.c | 62 +--
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index 6291c16123..35791c3040 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -83,8 +83,8 @@ static av_always_inline float quantize_and_encode_band_cost_template(
 const float ROUNDING)
 {
 const int q_idx = POW_SF2_ZERO - scale_idx + SCALE_ONE_POS - SCALE_DIV_512;
-const float Q   = ff_aac_pow2sf_tab [q_idx];
-const float Q34 = ff_aac_pow34sf_tab[q_idx];
+const float _Q   = ff_aac_pow2sf_tab [q_idx];
+const float _Q34 = ff_aac_pow34sf_tab[q_idx];
 const float IQ  = ff_aac_pow2sf_tab [POW_SF2_ZERO + scale_idx - SCALE_ONE_POS + SCALE_DIV_512];
 const float CLIPPED_ESCAPE = 165140.0f*IQ;
 float cost = 0;
@@ -111,7 +111,7 @@ static av_always_inline float quantize_and_encode_band_cost_template(
 s->abs_pow34(s->scoefs, in, size);
 scaled = s->scoefs;
 }
-s->quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, aac_cb_maxval[cb], Q34, ROUNDING);
+s->quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, aac_cb_maxval[cb], _Q34, ROUNDING);
 if (BT_UNSIGNED) {
 off = 0;
 } else {
@@ -138,7 +138,7 @@ static av_always_inline float quantize_and_encode_band_cost_template(
 quantized = CLIPPED_ESCAPE;
 curbits += 21;
 } else {
-int c = av_clip_uintp2(quant(t, Q, ROUNDING), 13);
+int c = av_clip_uintp2(quant(t, _Q, ROUNDING), 13);
 quantized = c*cbrtf(c)*IQ;
 curbits += av_log2(c)*2 - 4 + 1;
 }
@@ -175,7 +175,7 @@ static av_always_inline float quantize_and_encode_band_cost_template(
 if (BT_ESC) {
 for (int j = 0; j < 2; j++) {
 if (ff_aac_codebook_vectors[cb-1][curidx*2+j] == 64.0f) {
-int coef = av_clip_uintp2(quant(fabsf(in[i+j]), Q, ROUNDING), 13);
+int coef = av_clip_uintp2(quant(fabsf(in[i+j]), _Q, ROUNDING), 13);
 int len = av_log2(coef);
 
 put_bits(pb, len - 4 + 1, (1 << (len - 4 + 1)) - 2);
@@ -979,9 +979,9 @@ static void search_for_ms(AACEncContext *s, ChannelElement *cpe)
 {
 int start = 0, i, w, w2, g, sid_sf_boost, prev_mid, prev_side;
 uint8_t nextband0[128], nextband1[128];
-float *M   = s->scoefs + 128*0, *S   = s->scoefs + 128*1;
-float *L34 = s->scoefs + 128*2, *R34 = s->scoefs + 128*3;
-float *M34 = s->scoefs + 128*4, *S34 = s->scoefs + 128*5;
+float *_M   = s->scoefs + 128*0, *_S   = s->scoefs + 128*1;
+float *_L34 = s->scoefs + 128*2, *_R34 = s->scoefs + 128*3;
+float *_M34 = s->scoefs + 128*4, *_S34 = s->scoefs + 128*5;
 const float lambda = s->lambda;
 const float mslambda = FFMIN(1.0f, lambda / 120.f);
 SingleChannelElement *sce0 = >ch[0];
@@ -1007,22 +1007,22 @@ static void search_for_ms(AACEncContext *s, ChannelElement *cpe)
 /* Must compute mid/side SF and book for the whole window group */
 for (w2 = 0; w2 < sce0->ics.group_len[w]; w2++) {
 for (i = 0; i < sce0->ics.swb_sizes[g]; i++) {
-M[i] = (sce0->coeffs[start+(w+w2)*128+i]
+_M[i] = (sce0->coeffs[start+(w+w2)*128+i]
   + sce1->coeffs[start+(w+w2)*128+i]) * 0.5;
-S[i] =  M[i]
+_S[i] =  _M[i]
   - sce1->coeffs[start+(w+w2)*128+i];
 }
-s->abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
-s->abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
+s->abs_pow34(_M34, _M, sce0->ics.swb_sizes[g]);
+s->abs_pow34(_S34, _S, sce0->ics.swb_sizes[g]);
 for (i = 0; i < sce0->ics.swb_sizes[g]; i++ ) {
-Mmax = FFMAX(Mmax, M34[i]);
-Smax = FFMAX(Smax, S34[i]);
+Mmax = FFMAX(Mmax, _M34[i]);
+Smax = FFMAX(Smax, _S34[i]);
 }
 }
 
 for (sid_sf_boost = 

Re: [FFmpeg-devel] How to implement pcap ffmpeg format?

[sonntex]

It might be interesting. I didn’t find how to pass rtp to ffmpeg stdin.
That is why I started thinking about pcap.

Could you please show an example?

On Wed, 22 Feb 2023 at 08:04, Gijs Peskens  wrote:

> Wouldn't the simplest solution just be a tiny tool that unwraps the pcap
> stuff and just passes the packet data out on stdout?
> That's assuming ffmpeg allows receiving RTP packets on stdin.
>
> On 21-02-2023 23:55, sonntex wrote:
> > New pcap ffmpeg format can have all options rtpdec requires.
> >
> > Anyway, I don't suggest you implement this feature. I just want to find a
> > good entry point to start coding personally.
> >
> > I need to create a development tool for rtp tracing, and pcap files seem
> a
> > good idea because I can grab rtp using tcpdump, or create pcap files
> > directly in my application, or whatever. It's better then wrap vp8/vp9 to
> > ivf or h264 to byte stream and pass it to ffmpeg via pipe because it
> > doesn't require coding of new solutions for every video and audio formats
> > transferring over rtp.
> >
> > On Tue, Feb 21, 2023 at 10:38 PM Kieran Kunhya  wrote:
> >
> >> On Tue, 21 Feb 2023, 22:33 sonntex,  wrote:
> >>
> >>> I want to implement something which helps me to play rtp stored in pcap
> >>> files.
> >>>
> >>> tcpdump -i lo udp port 5 -s0 -w - | ffplay  -i -
> >>>
> >>> The specification of pcap files is really simple and I could create a
> new
> >>> ffmpeg format, but don't know how to process rtp packets extracted from
> >>> pcap, because it seems that all functions for rtp parsing are private.
> >>>
> >>> Need a good example of inner ffmpeg formats processing.
> >>>
> >> How is ffmpeg meant to know the meaning of the contents of a pcap and
> the
> >> format inside?
> >>
> >> This is a very bad idea.
> >>
> >> What's next, ffmpeg implementing userspace TCP? Are we going to add
> support
> >> for parsing filesystems as well?
> >>
> >> Regards,
> >> Kieran Kunhya
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >>
> > ___
> > 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] P1204.3 video quality metrics ?

[Alexandre Buisson]

Hi,
I would like to know if there is any project about an integration of a 3rd
party (opens source) lib to compute P1204.3 score from input video ?

-- 
Regards,
Alexandre
___
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] How to implement pcap ffmpeg format?

[Gijs Peskens]

Wouldn't the simplest solution just be a tiny tool that unwraps the pcap 
stuff and just passes the packet data out on stdout?

That's assuming ffmpeg allows receiving RTP packets on stdin.

On 21-02-2023 23:55, sonntex wrote:

New pcap ffmpeg format can have all options rtpdec requires.

Anyway, I don't suggest you implement this feature. I just want to find a
good entry point to start coding personally.

I need to create a development tool for rtp tracing, and pcap files seem a
good idea because I can grab rtp using tcpdump, or create pcap files
directly in my application, or whatever. It's better then wrap vp8/vp9 to
ivf or h264 to byte stream and pass it to ffmpeg via pipe because it
doesn't require coding of new solutions for every video and audio formats
transferring over rtp.

On Tue, Feb 21, 2023 at 10:38 PM Kieran Kunhya  wrote:


On Tue, 21 Feb 2023, 22:33 sonntex,  wrote:


I want to implement something which helps me to play rtp stored in pcap
files.

tcpdump -i lo udp port 5 -s0 -w - | ffplay  -i -

The specification of pcap files is really simple and I could create a new
ffmpeg format, but don't know how to process rtp packets extracted from
pcap, because it seems that all functions for rtp parsing are private.

Need a good example of inner ffmpeg formats processing.


How is ffmpeg meant to know the meaning of the contents of a pcap and the
format inside?

This is a very bad idea.

What's next, ffmpeg implementing userspace TCP? Are we going to add support
for parsing filesystems as well?

Regards,
Kieran Kunhya

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

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


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