Re: [FFmpeg-devel] [PATCH v2] avformat/mpegtsenc: support DVB 6A descriptor for AC-3
On Sat, Aug 15, 2020 at 11:38:29PM +0800, Guangxin Xu wrote:
> On Sat, Aug 15, 2020 at 10:28 PM wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > configure | 2 +-
> > libavformat/mpegts.h| 16 ++
> > libavformat/mpegtsenc.c | 84
> > +++--
> > 3 files changed, 99 insertions(+), 3 deletions(-)
> >
> > diff --git a/configure b/configure
> > index d4a1fea..a9d87b2 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3324,7 +3324,7 @@ mp3_demuxer_select="mpegaudio_parser"
> > mp3_muxer_select="mpegaudioheader"
> > mp4_muxer_select="mov_muxer"
> > mpegts_demuxer_select="iso_media"
> > -mpegts_muxer_select="adts_muxer latm_muxer h264_mp4toannexb_bsf
> > hevc_mp4toannexb_bsf"
> > +mpegts_muxer_select="ac3_parser adts_muxer latm_muxer
> > h264_mp4toannexb_bsf hevc_mp4toannexb_bsf"
> > mpegtsraw_demuxer_select="mpegts_demuxer"
> > mxf_muxer_select="golomb pcm_rechunk_bsf"
> > mxf_d10_muxer_select="mxf_muxer"
> > diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> > index fe10b38..d70b25d 100644
> > --- a/libavformat/mpegts.h
> > +++ b/libavformat/mpegts.h
> > @@ -175,6 +175,22 @@ typedef struct Mp4Descr {
> > SLConfigDescr sl;
> > } Mp4Descr;
> >
> > +/*
> > + * ETSI 300 468 descriptor 0x6A(AC-3)
> > + * Refer to: ETSI EN 300 468 V1.11.1 (2010-04) (SI in DVB systems)
> > + */
> > +typedef struct DVBAC3Descriptor {
> > +uint8_t component_type_flag;
> > +uint8_t bsid_flag;
> > +uint8_t mainid_flag;
> > +uint8_t asvc_flag;
> > +uint8_t reserved_flags;
> > +uint8_t component_type;
> > +uint8_t bsid;
> > +uint8_t mainid;
> > +uint8_t asvc;
> > +} DVBAC3Descriptor;
> > +
> > /**
> > * Parse an MPEG-2 descriptor
> > * @param[in] fcFormat context (used for logging only)
> > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> > index 718ddab..876ba99 100644
> > --- a/libavformat/mpegtsenc.c
> > +++ b/libavformat/mpegtsenc.c
> > @@ -27,6 +27,7 @@
> > #include "libavutil/mathematics.h"
> > #include "libavutil/opt.h"
> >
> > +#include "libavcodec/ac3_parser_internal.h"
> > #include "libavcodec/internal.h"
> >
> > #include "avformat.h"
> > @@ -244,6 +245,8 @@ typedef struct MpegTSWriteStream {
> > /* For Opus */
> > int opus_queued_samples;
> > int opus_pending_trim_start;
> > +
> > +DVBAC3Descriptor *dvb_ac3_desc;
> > } MpegTSWriteStream;
> >
> > static void mpegts_write_pat(AVFormatContext *s)
> > @@ -486,9 +489,28 @@ static int mpegts_write_pmt(AVFormatContext *s,
> > MpegTSService *service)
> > case AVMEDIA_TYPE_AUDIO:
> > if (ts->flags & MPEGTS_FLAG_SYSTEM_B) {
> > if (codec_id == AV_CODEC_ID_AC3) {
> > +DVBAC3Descriptor *dvb_ac3_desc = ts_st->dvb_ac3_desc;
> >
> need check ts_st->dvb_ac3_desc?
Yes, the folloing code will check dvb_ac3_desc, if it's NULL, use the old
default.
>
>
> +
> > *q++=0x6a; // AC3 descriptor see A038 DVB SI
> > -*q++=1; // 1 byte, all flags sets to 0
> > -*q++=0; // omit all fields...
> > +if (dvb_ac3_desc) {
> > +int len = 1 +
> > + !!(dvb_ac3_desc->component_type_flag) +
> > + !!(dvb_ac3_desc->bsid_flag) +
> > + !!(dvb_ac3_desc->mainid_flag) +
> > + !!(dvb_ac3_desc->asvc_flag);
> > +
> > +*q++ = len;
> > +*q++ = dvb_ac3_desc->component_type_flag << 7 |
> > dvb_ac3_desc->bsid_flag << 6 |
> > + dvb_ac3_desc->mainid_flag << 5 |
> > dvb_ac3_desc->asvc_flag << 4;
> > +
> > +if (dvb_ac3_desc->component_type_flag) *q++ =
> > dvb_ac3_desc->component_type;
> > +if (dvb_ac3_desc->bsid_flag) *q++ =
> > dvb_ac3_desc->bsid;
> > +if (dvb_ac3_desc->mainid_flag) *q++ =
> > dvb_ac3_desc->mainid;
> > +if (dvb_ac3_desc->asvc_flag) *q++ =
> > dvb_ac3_desc->asvc;
> > +} else {
> > +*q++=1; // 1 byte, all flags sets to 0
> > +*q++=0; // omit all fields...
> > +}
> > } else if (codec_id == AV_CODEC_ID_EAC3) {
> > *q++=0x7a; // EAC3 descriptor see A038 DVB SI
> > *q++=1; // 1 byte, all flags sets to 0
> > @@ -1843,6 +1865,63 @@ static int
> > mpegts_write_packet_internal(AVFormatContext *s, AVPacket *pkt)
> > * need to count the samples of that too! */
> > av_log(s, AV_LOG_WARNING, "Got MPEG-TS formatted Opus data,
> > unhandled");
> > }
> > +} else if (st->codecpar->codec_id == AV_CODEC_ID_AC3 &&
> >
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On Sat, Aug 15, 2020 at 07:29:40PM +0200, Paul B Mahol wrote: > On 8/15/20, Michael Niedermayer wrote: > > On Fri, Aug 14, 2020 at 02:24:25PM +0200, Paul B Mahol wrote: > >> On 8/14/20, Paul B Mahol wrote: > >> > On 8/13/20, Paul B Mahol wrote: > >> >> Hi, > >> >> > >> >> patch attached. > >> >> > >> >> Please review and/or benchmark, especially .asm file. > >> >> > >> > > >> > Updated patch attached. > >> > > >> > >> Sorry, wrong patch. > >> > >> New patch attached. > > > >> Makefile |2 > >> cfhd.c | 271 > >> +++-- > >> cfhd.h |3 > >> cfhddsp.c | 110 + > >> cfhddsp.h | 42 > >> x86/Makefile |2 > >> x86/cfhddsp.asm| 227 > >> x86/cfhddsp_init.c | 44 > >> 8 files changed, 488 insertions(+), 213 deletions(-) > >> 9312085fc5971774cdc8511019fa4023cf269100 > >> 0001-avcodec-cfhd-add-x86-SIMD.patch > >> From 874fd9e604a6dcd55cca77c7256a633e5739da77 Mon Sep 17 00:00:00 2001 > >> From: Paul B Mahol > >> Date: Sun, 9 Aug 2020 17:47:34 +0200 > >> Subject: [PATCH] avcodec/cfhd: add x86 SIMD > > > > This changes the fate checksums here > > > > Are you sure you tested latest patch? iam sure i tested the patch i replied to. I assumed that to be the latest just retried: --- ./tests/ref/fate/cfhd-3 2020-08-15 19:24:32.857427918 +0200 +++ tests/data/fate/cfhd-3 2020-08-16 01:29:09.398576303 +0200 @@ -3,13 +3,13 @@ #codec_id 0: rawvideo #dimensions 0: 496x241 #sar 0: 0/1 -0, 0, 0,1, 478144, 0x1e5a0d6c -0, 1, 1,1, 478144, 0x1e5a0d6c -0, 2, 2,1, 478144, 0x1e5a0d6c -0, 3, 3,1, 478144, 0x88788c7d -0, 4, 4,1, 478144, 0x78643db8 -0, 5, 5,1, 478144, 0x84303909 -0, 6, 6,1, 478144, 0x8ddd4828 -0, 7, 7,1, 478144, 0xc0845d58 -0, 8, 8,1, 478144, 0xc0845d58 -0, 9, 9,1, 478144, 0xc0845d58 +0, 0, 0,1, 478144, 0x3a16bf21 +0, 1, 1,1, 478144, 0x3a16bf21 +0, 2, 2,1, 478144, 0x3a16bf21 +0, 3, 3,1, 478144, 0xcdf5a9e0 +0, 4, 4,1, 478144, 0xd463374a +0, 5, 5,1, 478144, 0x3efe52f9 +0, 6, 6,1, 478144, 0xdabe +0, 7, 7,1, 478144, 0xa242ae7b +0, 8, 8,1, 478144, 0xa242ae7b +0, 9, 9,1, 478144, 0xa242ae7b Test cfhd-3 failed. Look at tests/data/fate/cfhd-3.err for details. tests/Makefile:255: recipe for target 'fate-cfhd-3' failed make: *** [fate-cfhd-3] Error 1 make: *** Waiting for unfinished jobs TESTfilm-cvid TESTflic-af11-palette-change --- ./tests/ref/fate/cfhd-1 2020-08-15 19:24:32.857427918 +0200 +++ tests/data/fate/cfhd-1 2020-08-16 01:29:09.434576844 +0200 @@ -3,13 +3,13 @@ #codec_id 0: rawvideo #dimensions 0: 720x480 #sar 0: 0/1 -0, 0, 0,1, 1382400, 0xa3e49817 -0, 1, 1,1, 1382400, 0x544fdfac -0, 2, 2,1, 1382400, 0x84964e11 -0, 3, 3,1, 1382400, 0xc608c8d1 -0, 4, 4,1, 1382400, 0xf2f1404f -0, 5, 5,1, 1382400, 0x5a3100ba -0, 6, 6,1, 1382400, 0x3727baa9 -0, 7, 7,1, 1382400, 0x894f07db -0, 8, 8,1, 1382400, 0x3ef27d46 -0, 9, 9,1, 1382400, 0x1f90880d +0, 0, 0,1, 1382400, 0x7267a5b0 +0, 1, 1,1, 1382400, 0xe9fec998 +0, 2, 2,1, 1382400, 0xd8883a69 +0, 3, 3,1, 1382400, 0x756dce7c +0, 4, 4,1, 1382400, 0x349b63a2 +0, 5, 5,1, 1382400, 0x0fa92a41 +0, 6, 6,1, 1382400, 0x1d21d79c +0, 7, 7,1, 1382400, 0x327d17af +0, 8, 8,1, 1382400, 0xaa987c63 +0, 9, 9,1, 1382400, 0xab136e70 Test cfhd-1 failed. Look at tests/data/fate/cfhd-1.err for details. tests/Makefile:255: recipe for target 'fate-cfhd-1' failed make: *** [fate-cfhd-1] Error 1 --- ./tests/ref/fate/cfhd-2 2020-08-15 19:24:32.857427918 +0200 +++ tests/data/fate/cfhd-2 2020-08-16 01:29:09.470577386 +0200 @@ -3,13 +3,13 @@ #codec_id 0: rawvideo #dimensions 0: 720x480 #sar 0: 0/1 -0, 0, 0,1, 2073600, 0x53fab433 -0, 1, 1,1, 2073600, 0x0d2b3f64 -0, 2, 2,1, 2073600, 0x857d1d48 -0,
Re: [FFmpeg-devel] [PATCH 7/7] avcodec/aacdec_template: add support for 22.2 / channel_config 13
On Sat, Aug 01, 2020 at 02:07:30PM +0300, Jan Ekström wrote:
> ---
> libavcodec/aacdec_template.c | 89 +++-
> 1 file changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 21db12fdab..8c5048cc13 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -387,17 +387,77 @@ static uint64_t sniff_channel_order(uint8_t
> (*layout_map)[3], int tags)
> i++;
> }
>
> -// Must choose a stable sort
> +// The previous checks would end up at 8 at this point for 22.2
> +if (tags == 16 && i == 8) {
> +e2c_vec[i] = (struct elem_to_channel) {
> +.av_position = AV_CH_TOP_FRONT_CENTER,
> +.syn_ele = layout_map[i][0],
> +.elem_id = layout_map[i][1],
> +.aac_position = layout_map[i][2]
> +}; i++;
> +i += assign_pair(e2c_vec, layout_map, i,
> + AV_CH_TOP_FRONT_LEFT,
> + AV_CH_TOP_FRONT_RIGHT,
> + AAC_CHANNEL_FRONT);
> +i += assign_pair(e2c_vec, layout_map, i,
> + AV_CH_TOP_SIDE_LEFT,
> + AV_CH_TOP_SIDE_RIGHT,
> + AAC_CHANNEL_SIDE);
> +e2c_vec[i] = (struct elem_to_channel) {
> +.av_position = AV_CH_TOP_CENTER,
> +.syn_ele = layout_map[i][0],
> +.elem_id = layout_map[i][1],
> +.aac_position = layout_map[i][2]
> +}; i++;
> +i += assign_pair(e2c_vec, layout_map, i,
> + AV_CH_TOP_BACK_LEFT,
> + AV_CH_TOP_BACK_RIGHT,
> + AAC_CHANNEL_BACK);
> +e2c_vec[i] = (struct elem_to_channel) {
> +.av_position = AV_CH_TOP_BACK_CENTER,
> +.syn_ele = layout_map[i][0],
Does this code assume all types are CPE ?
because if thats not true i can exceed the tags
> +.elem_id = layout_map[i][1],
> +.aac_position = layout_map[i][2]
> +}; i++;
> +e2c_vec[i] = (struct elem_to_channel) {
> +.av_position = AV_CH_BOTTOM_FRONT_CENTER,
> +.syn_ele = layout_map[i][0],
> +.elem_id = layout_map[i][1],
> +.aac_position = layout_map[i][2]
> +}; i++;
> +i += assign_pair(e2c_vec, layout_map, i,
> + AV_CH_BOTTOM_FRONT_LEFT,
> + AV_CH_BOTTOM_FRONT_RIGHT,
> + AAC_CHANNEL_FRONT);
> +}
> +
> total_non_cc_elements = n = i;
> -do {
> -int next_n = 0;
> -for (i = 1; i < n; i++)
> -if (e2c_vec[i - 1].av_position > e2c_vec[i].av_position) {
> -FFSWAP(struct elem_to_channel, e2c_vec[i - 1], e2c_vec[i]);
> -next_n = i;
> -}
> -n = next_n;
> -} while (n > 0);
> +
> +if (tags == 16 && total_non_cc_elements == 16) {
> +// For 22.2 reorder the result as needed
> +FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[0]); // FL & FR
> first (final), FC third
> +FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[1]); // FC
> second (final), FLc & FRc third
> +FFSWAP(struct elem_to_channel, e2c_vec[6], e2c_vec[2]); // LFE1
> third (final), FLc & FRc seventh
> +FFSWAP(struct elem_to_channel, e2c_vec[4], e2c_vec[3]); // BL & BR
> fourth (final), SiL & SiR fifth
> +FFSWAP(struct elem_to_channel, e2c_vec[6], e2c_vec[4]); // FLc &
> FRc fifth (final), SiL & SiR seventh
> +FFSWAP(struct elem_to_channel, e2c_vec[7], e2c_vec[6]); // LFE2
> seventh (final), SiL & SiR eight (final)
> +FFSWAP(struct elem_to_channel, e2c_vec[9], e2c_vec[8]); // TpFL &
> TpFR ninth (final), TFC tenth (final)
> +FFSWAP(struct elem_to_channel, e2c_vec[11], e2c_vec[10]); // TC
> eleventh (final), TpSiL & TpSiR twelth
> +FFSWAP(struct elem_to_channel, e2c_vec[12], e2c_vec[11]); // TpBL &
> TpBR twelth (final), TpSiL & TpSiR thirteenth (final)
Does this not need to check the assumtations from the comments ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: add disable_all_auto_conversion_filters option.
On 15/08/2020 16:03, Nicolas George wrote:
Mark Thompson (12020-08-14):
The relation to the existing -autorotate and -autoscale options is
confusing - those aren't disabled by this (because they are applied
differently), but it sounds like they would be.
I updated the doc to:
Disable automatically inserting format conversion filters in all filter
graphs, including those defined by @option{-vf}, @option{-af},
@option{-filter_complex} and @option{-lavfi}. If filter format negotiation
requires a conversion, the initialization of the filters will fail.
Conversions can still be performed by inserting the relevant conversion
filter (scale, aresample) in the graph.
I'm not sure how to make this better. Maybe it should be called "-autoconvert"
to match and then override the others?
I disagree: auto rotation and auto scaling are options for normal users,
to control the output. This is for very advanced users, only for
technical use by somebody who knows the inner workings of lavfi. They
should not be merged, and also this is why I chose a very long and
explicit name.
Thank you for the clarification; I'm happy with that answer.
The help strings here looks suspiciously similar to the -filter_complex ones...
Oops. Locally changed to:
"disable all automatic conversion filters" },
Sounds good to me with those changes.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/v4l2_context: return EAGAIN to signal full buffers
On 17/07/2020 03:09, Andriy Gelman wrote: From: Andriy Gelman Return proper error when a frame buffers are full. This path is triggered on the DragonBoard 410c since the encoding API change in commit 827d6fe73d2f5472c1c2. Signed-off-by: Andriy Gelman --- libavcodec/v4l2_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c index 29b144ed73e..ff1ea8e57b0 100644 --- a/libavcodec/v4l2_context.c +++ b/libavcodec/v4l2_context.c @@ -599,7 +599,7 @@ int ff_v4l2_context_enqueue_frame(V4L2Context* ctx, const AVFrame* frame) avbuf = v4l2_getfree_v4l2buf(ctx); if (!avbuf) -return AVERROR(ENOMEM); +return AVERROR(EAGAIN); ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf); if (ret) Yep, LGTM. (And, importantly, it now matches the corresponding enqueue_packet behaviour in the function immediately below.) Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@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 v6] avdevice/xcbgrab: check return values of xcb query functions
On Thu, 13. Aug 23:43, Andriy Gelman wrote:
> On Sat, 08. Aug 09:55, Andriy Gelman wrote:
> > On Wed, 05. Aug 14:37, Moritz Barsnick wrote:
> > > On Mon, Jul 20, 2020 at 09:18:55 +0200, Alexander Strasser wrote:
> > > > On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> > > > > > > This check seems dead code. Looking at xcb sources, cursor is
> > > > > > > just an offset in
> > > > > > > memory from ci so I don't think it can be null here.
> > >
> > > > > But anyway, this part of the patch doesn't really have anything to do
> > > > > with
> > > > > ticket #7312, and should be in a separate patch.
> > > >
> > > > Yes, it's definitely something that was changed in this patch
> > > > at all. So it's better not to touch it in this patch.
> > >
> > > Okay, so I "fixed" dead code. You guys can remove the dead code
> > > yourselves then, if you like. ;-)
> > >
> > > New patch for the original issue attached, not touching the dead code.
> > >
> > > Thanks,
> > > Moritz
> >
> > > From e44b7f03354add2272a2739e04aafb38b7ce027f Mon Sep 17 00:00:00 2001
> > > From: Moritz Barsnick
> > > Date: Wed, 5 Aug 2020 14:06:53 +0200
> > > Subject: [PATCH] avdevice/xcbgrab: check return values of xcb query
> > > functions
> > >
> > > Fixes #7312, segmentation fault on close of X11 server
> > >
> > > xcb_query_pointer_reply() and xcb_get_geometry_reply() can return NULL
> > > if e.g. the X server closes or the connection is lost. This needs to
> > > be checked in order to cleanly exit, because the returned pointers are
> > > dereferenced later.
> > >
> > > Signed-off-by: Moritz Barsnick
> > > ---
> > > libavdevice/xcbgrab.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> > > index 6f6b2dbf15..8ef2a30d02 100644
> > > --- a/libavdevice/xcbgrab.c
> > > +++ b/libavdevice/xcbgrab.c
> > > @@ -425,7 +425,16 @@ static int xcbgrab_read_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > pc = xcb_query_pointer(c->conn, c->screen->root);
> > > gc = xcb_get_geometry(c->conn, c->screen->root);
> > > p = xcb_query_pointer_reply(c->conn, pc, NULL);
> > > +if (!p) {
> > > +av_log(s, AV_LOG_ERROR, "Failed to query xcb pointer\n");
> > > +return AVERROR_EXTERNAL;
> > > +}
> > > geo = xcb_get_geometry_reply(c->conn, gc, NULL);
> > > +if (!geo) {
> > > +av_log(s, AV_LOG_ERROR, "Failed to get xcb geometry\n");
> > > +free(p);
> > > +return AVERROR_EXTERNAL;
> > > +}
> > > }
> > >
> > > if (c->follow_mouse && p->same_screen)
> > > --
> > > 2.26.2
> > >
> >
> > lgtm
> >
>
> Will apply this tomorrow if no one objects.
>
Applied.
Thanks,
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/v4l2_context: return EAGAIN to signal full buffers
On Fri, 24. Jul 15:49, Andriy Gelman wrote: > On Thu, 16. Jul 22:09, Andriy Gelman wrote: > > From: Andriy Gelman > > > > Return proper error when a frame buffers are full. This path is > > triggered on the DragonBoard 410c since the encoding API change in > > commit 827d6fe73d2f5472c1c2. > > > > Signed-off-by: Andriy Gelman > > --- > > libavcodec/v4l2_context.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c > > index 29b144ed73e..ff1ea8e57b0 100644 > > --- a/libavcodec/v4l2_context.c > > +++ b/libavcodec/v4l2_context.c > > @@ -599,7 +599,7 @@ int ff_v4l2_context_enqueue_frame(V4L2Context* ctx, > > const AVFrame* frame) > > > > avbuf = v4l2_getfree_v4l2buf(ctx); > > if (!avbuf) > > -return AVERROR(ENOMEM); > > +return AVERROR(EAGAIN); > > > > ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf); > > if (ret) > > ping > ping Will apply this soon if no one objects. -- Andriy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On 8/15/20, Michael Niedermayer wrote: > On Fri, Aug 14, 2020 at 02:24:25PM +0200, Paul B Mahol wrote: >> On 8/14/20, Paul B Mahol wrote: >> > On 8/13/20, Paul B Mahol wrote: >> >> Hi, >> >> >> >> patch attached. >> >> >> >> Please review and/or benchmark, especially .asm file. >> >> >> > >> > Updated patch attached. >> > >> >> Sorry, wrong patch. >> >> New patch attached. > >> Makefile |2 >> cfhd.c | 271 >> +++-- >> cfhd.h |3 >> cfhddsp.c | 110 + >> cfhddsp.h | 42 >> x86/Makefile |2 >> x86/cfhddsp.asm| 227 >> x86/cfhddsp_init.c | 44 >> 8 files changed, 488 insertions(+), 213 deletions(-) >> 9312085fc5971774cdc8511019fa4023cf269100 >> 0001-avcodec-cfhd-add-x86-SIMD.patch >> From 874fd9e604a6dcd55cca77c7256a633e5739da77 Mon Sep 17 00:00:00 2001 >> From: Paul B Mahol >> Date: Sun, 9 Aug 2020 17:47:34 +0200 >> Subject: [PATCH] avcodec/cfhd: add x86 SIMD > > This changes the fate checksums here > Are you sure you tested latest patch? > --- ./tests/ref/fate/cfhd-1 2020-08-11 11:19:05.927726152 +0200 > +++ tests/data/fate/cfhd-12020-08-15 19:23:24.709365401 +0200 > @@ -3,13 +3,13 @@ > #codec_id 0: rawvideo > #dimensions 0: 720x480 > #sar 0: 0/1 > -0, 0, 0,1, 1382400, 0xa3e49817 > -0, 1, 1,1, 1382400, 0x544fdfac > -0, 2, 2,1, 1382400, 0x84964e11 > -0, 3, 3,1, 1382400, 0xc608c8d1 > -0, 4, 4,1, 1382400, 0xf2f1404f > -0, 5, 5,1, 1382400, 0x5a3100ba > -0, 6, 6,1, 1382400, 0x3727baa9 > -0, 7, 7,1, 1382400, 0x894f07db > -0, 8, 8,1, 1382400, 0x3ef27d46 > -0, 9, 9,1, 1382400, 0x1f90880d > +0, 0, 0,1, 1382400, 0x7267a5b0 > +0, 1, 1,1, 1382400, 0xe9fec998 > +0, 2, 2,1, 1382400, 0xd8883a69 > +0, 3, 3,1, 1382400, 0x756dce7c > +0, 4, 4,1, 1382400, 0x349b63a2 > +0, 5, 5,1, 1382400, 0x0fa92a41 > +0, 6, 6,1, 1382400, 0x1d21d79c > +0, 7, 7,1, 1382400, 0x327d17af > +0, 8, 8,1, 1382400, 0xaa987c63 > +0, 9, 9,1, 1382400, 0xab136e70 > Test cfhd-1 failed. Look at tests/data/fate/cfhd-1.err for details. > tests/Makefile:255: recipe for target 'fate-cfhd-1' failed > make: *** [fate-cfhd-1] Error 1 > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Modern terrorism, a quick summary: Need oil, start war with country that > has oil, kill hundread thousand in war. Let country fall into chaos, > be surprised about raise of fundamantalists. Drop more bombs, kill more > people, be surprised about them taking revenge and drop even more bombs > and strip your own citizens of their rights and freedoms. to be continued > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On Fri, Aug 14, 2020 at 02:24:25PM +0200, Paul B Mahol wrote: > On 8/14/20, Paul B Mahol wrote: > > On 8/13/20, Paul B Mahol wrote: > >> Hi, > >> > >> patch attached. > >> > >> Please review and/or benchmark, especially .asm file. > >> > > > > Updated patch attached. > > > > Sorry, wrong patch. > > New patch attached. > Makefile |2 > cfhd.c | 271 > +++-- > cfhd.h |3 > cfhddsp.c | 110 + > cfhddsp.h | 42 > x86/Makefile |2 > x86/cfhddsp.asm| 227 > x86/cfhddsp_init.c | 44 > 8 files changed, 488 insertions(+), 213 deletions(-) > 9312085fc5971774cdc8511019fa4023cf269100 0001-avcodec-cfhd-add-x86-SIMD.patch > From 874fd9e604a6dcd55cca77c7256a633e5739da77 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Sun, 9 Aug 2020 17:47:34 +0200 > Subject: [PATCH] avcodec/cfhd: add x86 SIMD This changes the fate checksums here --- ./tests/ref/fate/cfhd-1 2020-08-11 11:19:05.927726152 +0200 +++ tests/data/fate/cfhd-1 2020-08-15 19:23:24.709365401 +0200 @@ -3,13 +3,13 @@ #codec_id 0: rawvideo #dimensions 0: 720x480 #sar 0: 0/1 -0, 0, 0,1, 1382400, 0xa3e49817 -0, 1, 1,1, 1382400, 0x544fdfac -0, 2, 2,1, 1382400, 0x84964e11 -0, 3, 3,1, 1382400, 0xc608c8d1 -0, 4, 4,1, 1382400, 0xf2f1404f -0, 5, 5,1, 1382400, 0x5a3100ba -0, 6, 6,1, 1382400, 0x3727baa9 -0, 7, 7,1, 1382400, 0x894f07db -0, 8, 8,1, 1382400, 0x3ef27d46 -0, 9, 9,1, 1382400, 0x1f90880d +0, 0, 0,1, 1382400, 0x7267a5b0 +0, 1, 1,1, 1382400, 0xe9fec998 +0, 2, 2,1, 1382400, 0xd8883a69 +0, 3, 3,1, 1382400, 0x756dce7c +0, 4, 4,1, 1382400, 0x349b63a2 +0, 5, 5,1, 1382400, 0x0fa92a41 +0, 6, 6,1, 1382400, 0x1d21d79c +0, 7, 7,1, 1382400, 0x327d17af +0, 8, 8,1, 1382400, 0xaa987c63 +0, 9, 9,1, 1382400, 0xab136e70 Test cfhd-1 failed. Look at tests/data/fate/cfhd-1.err for details. tests/Makefile:255: recipe for target 'fate-cfhd-1' failed make: *** [fate-cfhd-1] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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/av1dec: inline obu_read_data() and obu_prefetch() into obu_get_packet()
On 8/15/2020 12:39 PM, Guangxin Xu wrote: > On Fri, Aug 14, 2020 at 10:30 PM James Almer wrote: > >> They don't really help making the demuxer more readable. >> >> Signed-off-by: James Almer >> --- >> libavformat/av1dec.c | 56 +--- >> 1 file changed, 21 insertions(+), 35 deletions(-) >> > Good improvment, > LGTM Applied. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@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/av1dec: inline obu_read_data() and obu_prefetch() into obu_get_packet()
On Fri, Aug 14, 2020 at 10:30 PM James Almer wrote:
> They don't really help making the demuxer more readable.
>
> Signed-off-by: James Almer
> ---
> libavformat/av1dec.c | 56 +---
> 1 file changed, 21 insertions(+), 35 deletions(-)
>
Good improvment,
LGTM
>
> diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
> index 0693e40ac1..c06f5303f5 100644
> --- a/libavformat/av1dec.c
> +++ b/libavformat/av1dec.c
> @@ -382,60 +382,46 @@ static int obu_read_header(AVFormatContext *s)
> return read_header(s, >framerate, >bsf, c);
> }
>
> -static int obu_prefetch(AVFormatContext *s, uint8_t* dest)
> +static int obu_get_packet(AVFormatContext *s, AVPacket *pkt)
> {
> ObuContext *c = s->priv_data;
> +uint8_t header[MAX_OBU_HEADER_SIZE];
> +int64_t obu_size;
> int size = av_fifo_space(c->fifo);
> +int ret, len, type;
> +
> av_fifo_generic_write(c->fifo, s->pb, size,
>(int (*)(void*, void*, int))avio_read);
> size = av_fifo_size(c->fifo);
> -if (size > 0) {
> -av_fifo_generic_peek(c->fifo, dest, size, NULL);
> +if (!size)
> +return 0;
> +
> +av_fifo_generic_peek(c->fifo, header, size, NULL);
> +
> +len = read_obu_with_size(header, size, _size, );
> +if (len < 0) {
> +av_log(c, AV_LOG_ERROR, "Failed to read obu\n");
> +return len;
> }
> -return size;
> -}
>
> -static int obu_read_data(AVFormatContext *s, AVPacket *pkt, int len)
> -{
> -int size, left;
> -ObuContext *c = s->priv_data;
> -int ret = av_new_packet(pkt, len);
> +ret = av_new_packet(pkt, len);
> if (ret < 0) {
> av_log(c, AV_LOG_ERROR, "Failed to allocate packet for obu\n");
> return ret;
> }
> -size = FFMIN(av_fifo_size(c->fifo), len);
> +size = FFMIN(size, len);
> av_fifo_generic_read(c->fifo, pkt->data, size, NULL);
> -left = len - size;
> -if (left > 0) {
> -ret = avio_read(s->pb, pkt->data + size, left);
> -if (ret != left) {
> -av_log(c, AV_LOG_ERROR, "Failed to read %d frome file\n",
> left);
> +len -= size;
> +if (len > 0) {
> +ret = avio_read(s->pb, pkt->data + size, len);
> +if (ret != len) {
> +av_log(c, AV_LOG_ERROR, "Failed to read %d frome file\n",
> len);
> return ret < 0 ? ret : AVERROR_INVALIDDATA;
> }
> }
> return 0;
> }
>
> -static int obu_get_packet(AVFormatContext *s, AVPacket *pkt)
> -{
> -ObuContext *c = s->priv_data;
> -int64_t obu_size;
> -int ret, type;
> -uint8_t header[MAX_OBU_HEADER_SIZE];
> -
> -ret = obu_prefetch(s, header);
> -if (!ret)
> -return 0;
> -
> -ret = read_obu_with_size(header, ret, _size, );
> -if (ret < 0) {
> -av_log(c, AV_LOG_ERROR, "Failed to read obu\n");
> -return ret;
> -}
> -return obu_read_data(s, pkt, ret);
> -}
> -
> static int obu_read_packet(AVFormatContext *s, AVPacket *pkt)
> {
> ObuContext *c = s->priv_data;
> --
> 2.27.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/mpegtsenc: support DVB 6A descriptor for AC-3
On Sat, Aug 15, 2020 at 10:28 PM wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> configure | 2 +-
> libavformat/mpegts.h| 16 ++
> libavformat/mpegtsenc.c | 84
> +++--
> 3 files changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index d4a1fea..a9d87b2 100755
> --- a/configure
> +++ b/configure
> @@ -3324,7 +3324,7 @@ mp3_demuxer_select="mpegaudio_parser"
> mp3_muxer_select="mpegaudioheader"
> mp4_muxer_select="mov_muxer"
> mpegts_demuxer_select="iso_media"
> -mpegts_muxer_select="adts_muxer latm_muxer h264_mp4toannexb_bsf
> hevc_mp4toannexb_bsf"
> +mpegts_muxer_select="ac3_parser adts_muxer latm_muxer
> h264_mp4toannexb_bsf hevc_mp4toannexb_bsf"
> mpegtsraw_demuxer_select="mpegts_demuxer"
> mxf_muxer_select="golomb pcm_rechunk_bsf"
> mxf_d10_muxer_select="mxf_muxer"
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> index fe10b38..d70b25d 100644
> --- a/libavformat/mpegts.h
> +++ b/libavformat/mpegts.h
> @@ -175,6 +175,22 @@ typedef struct Mp4Descr {
> SLConfigDescr sl;
> } Mp4Descr;
>
> +/*
> + * ETSI 300 468 descriptor 0x6A(AC-3)
> + * Refer to: ETSI EN 300 468 V1.11.1 (2010-04) (SI in DVB systems)
> + */
> +typedef struct DVBAC3Descriptor {
> +uint8_t component_type_flag;
> +uint8_t bsid_flag;
> +uint8_t mainid_flag;
> +uint8_t asvc_flag;
> +uint8_t reserved_flags;
> +uint8_t component_type;
> +uint8_t bsid;
> +uint8_t mainid;
> +uint8_t asvc;
> +} DVBAC3Descriptor;
> +
> /**
> * Parse an MPEG-2 descriptor
> * @param[in] fcFormat context (used for logging only)
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index 718ddab..876ba99 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -27,6 +27,7 @@
> #include "libavutil/mathematics.h"
> #include "libavutil/opt.h"
>
> +#include "libavcodec/ac3_parser_internal.h"
> #include "libavcodec/internal.h"
>
> #include "avformat.h"
> @@ -244,6 +245,8 @@ typedef struct MpegTSWriteStream {
> /* For Opus */
> int opus_queued_samples;
> int opus_pending_trim_start;
> +
> +DVBAC3Descriptor *dvb_ac3_desc;
> } MpegTSWriteStream;
>
> static void mpegts_write_pat(AVFormatContext *s)
> @@ -486,9 +489,28 @@ static int mpegts_write_pmt(AVFormatContext *s,
> MpegTSService *service)
> case AVMEDIA_TYPE_AUDIO:
> if (ts->flags & MPEGTS_FLAG_SYSTEM_B) {
> if (codec_id == AV_CODEC_ID_AC3) {
> +DVBAC3Descriptor *dvb_ac3_desc = ts_st->dvb_ac3_desc;
>
need check ts_st->dvb_ac3_desc?
+
> *q++=0x6a; // AC3 descriptor see A038 DVB SI
> -*q++=1; // 1 byte, all flags sets to 0
> -*q++=0; // omit all fields...
> +if (dvb_ac3_desc) {
> +int len = 1 +
> + !!(dvb_ac3_desc->component_type_flag) +
> + !!(dvb_ac3_desc->bsid_flag) +
> + !!(dvb_ac3_desc->mainid_flag) +
> + !!(dvb_ac3_desc->asvc_flag);
> +
> +*q++ = len;
> +*q++ = dvb_ac3_desc->component_type_flag << 7 |
> dvb_ac3_desc->bsid_flag << 6 |
> + dvb_ac3_desc->mainid_flag << 5 |
> dvb_ac3_desc->asvc_flag << 4;
> +
> +if (dvb_ac3_desc->component_type_flag) *q++ =
> dvb_ac3_desc->component_type;
> +if (dvb_ac3_desc->bsid_flag) *q++ =
> dvb_ac3_desc->bsid;
> +if (dvb_ac3_desc->mainid_flag) *q++ =
> dvb_ac3_desc->mainid;
> +if (dvb_ac3_desc->asvc_flag) *q++ =
> dvb_ac3_desc->asvc;
> +} else {
> +*q++=1; // 1 byte, all flags sets to 0
> +*q++=0; // omit all fields...
> +}
> } else if (codec_id == AV_CODEC_ID_EAC3) {
> *q++=0x7a; // EAC3 descriptor see A038 DVB SI
> *q++=1; // 1 byte, all flags sets to 0
> @@ -1843,6 +1865,63 @@ static int
> mpegts_write_packet_internal(AVFormatContext *s, AVPacket *pkt)
> * need to count the samples of that too! */
> av_log(s, AV_LOG_WARNING, "Got MPEG-TS formatted Opus data,
> unhandled");
> }
> +} else if (st->codecpar->codec_id == AV_CODEC_ID_AC3 &&
> !ts_st->dvb_ac3_desc) {
> + AC3HeaderInfo *hdr = NULL;
> +
> +if (avpriv_ac3_parse_header(, pkt->data, pkt->size) >= 0) {
> +uint8_t number_of_channels_flag;
> +uint8_t service_type_flag;
> +uint8_t full_service_flag = 1;
> +DVBAC3Descriptor *dvb_ac3_desc;
> +
> +dvb_ac3_desc = av_mallocz(sizeof(*dvb_ac3_desc));
> +
Re: [FFmpeg-devel] [PATCH 2/2] fate: disable automatic conversions on most filter tests.
Mark Thompson (12020-08-14): > Adding this variable to the command line of large numbers of tests is > not very fun, because it's not relevant to the test definition itself. > > Is it possible that it might be better to split some of the commands > into multiple forms if there are some tests which still want > autoconversion? Depending on which variant is more common, > "framecrc_autoconv" or "framecrc_noconv". > > (Alternatively: how many tests /do/ want autoconversion? The option > could be added in the top-level ffmpeg() function and then disabled > selectively in tests.) I agree, the other direction would be better. I am trying this approach, but it gives me ~850 failing tests, but some fail the same way and can be fixed as a bunch. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: add disable_all_auto_conversion_filters option.
Mark Thompson (12020-08-14):
> The relation to the existing -autorotate and -autoscale options is
> confusing - those aren't disabled by this (because they are applied
> differently), but it sounds like they would be.
I updated the doc to:
Disable automatically inserting format conversion filters in all filter
graphs, including those defined by @option{-vf}, @option{-af},
@option{-filter_complex} and @option{-lavfi}. If filter format negotiation
requires a conversion, the initialization of the filters will fail.
Conversions can still be performed by inserting the relevant conversion
filter (scale, aresample) in the graph.
> I'm not sure how to make this better. Maybe it should be called
> "-autoconvert" to match and then override the others?
I disagree: auto rotation and auto scaling are options for normal users,
to control the output. This is for very advanced users, only for
technical use by somebody who knows the inner workings of lavfi. They
should not be merged, and also this is why I chose a very long and
explicit name.
> The help strings here looks suspiciously similar to the -filter_complex
> ones...
Oops. Locally changed to:
"disable all automatic conversion filters" },
Thanks.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/mpegtsenc: support DVB 6A descriptor for AC-3
From: Limin Wang
Signed-off-by: Limin Wang
---
configure | 2 +-
libavformat/mpegts.h| 16 ++
libavformat/mpegtsenc.c | 84 +++--
3 files changed, 99 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index d4a1fea..a9d87b2 100755
--- a/configure
+++ b/configure
@@ -3324,7 +3324,7 @@ mp3_demuxer_select="mpegaudio_parser"
mp3_muxer_select="mpegaudioheader"
mp4_muxer_select="mov_muxer"
mpegts_demuxer_select="iso_media"
-mpegts_muxer_select="adts_muxer latm_muxer h264_mp4toannexb_bsf
hevc_mp4toannexb_bsf"
+mpegts_muxer_select="ac3_parser adts_muxer latm_muxer h264_mp4toannexb_bsf
hevc_mp4toannexb_bsf"
mpegtsraw_demuxer_select="mpegts_demuxer"
mxf_muxer_select="golomb pcm_rechunk_bsf"
mxf_d10_muxer_select="mxf_muxer"
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index fe10b38..d70b25d 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -175,6 +175,22 @@ typedef struct Mp4Descr {
SLConfigDescr sl;
} Mp4Descr;
+/*
+ * ETSI 300 468 descriptor 0x6A(AC-3)
+ * Refer to: ETSI EN 300 468 V1.11.1 (2010-04) (SI in DVB systems)
+ */
+typedef struct DVBAC3Descriptor {
+uint8_t component_type_flag;
+uint8_t bsid_flag;
+uint8_t mainid_flag;
+uint8_t asvc_flag;
+uint8_t reserved_flags;
+uint8_t component_type;
+uint8_t bsid;
+uint8_t mainid;
+uint8_t asvc;
+} DVBAC3Descriptor;
+
/**
* Parse an MPEG-2 descriptor
* @param[in] fcFormat context (used for logging only)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 718ddab..876ba99 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -27,6 +27,7 @@
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
+#include "libavcodec/ac3_parser_internal.h"
#include "libavcodec/internal.h"
#include "avformat.h"
@@ -244,6 +245,8 @@ typedef struct MpegTSWriteStream {
/* For Opus */
int opus_queued_samples;
int opus_pending_trim_start;
+
+DVBAC3Descriptor *dvb_ac3_desc;
} MpegTSWriteStream;
static void mpegts_write_pat(AVFormatContext *s)
@@ -486,9 +489,28 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
case AVMEDIA_TYPE_AUDIO:
if (ts->flags & MPEGTS_FLAG_SYSTEM_B) {
if (codec_id == AV_CODEC_ID_AC3) {
+DVBAC3Descriptor *dvb_ac3_desc = ts_st->dvb_ac3_desc;
+
*q++=0x6a; // AC3 descriptor see A038 DVB SI
-*q++=1; // 1 byte, all flags sets to 0
-*q++=0; // omit all fields...
+if (dvb_ac3_desc) {
+int len = 1 +
+ !!(dvb_ac3_desc->component_type_flag) +
+ !!(dvb_ac3_desc->bsid_flag) +
+ !!(dvb_ac3_desc->mainid_flag) +
+ !!(dvb_ac3_desc->asvc_flag);
+
+*q++ = len;
+*q++ = dvb_ac3_desc->component_type_flag << 7 |
dvb_ac3_desc->bsid_flag << 6 |
+ dvb_ac3_desc->mainid_flag << 5 |
dvb_ac3_desc->asvc_flag << 4;
+
+if (dvb_ac3_desc->component_type_flag) *q++ =
dvb_ac3_desc->component_type;
+if (dvb_ac3_desc->bsid_flag) *q++ =
dvb_ac3_desc->bsid;
+if (dvb_ac3_desc->mainid_flag) *q++ =
dvb_ac3_desc->mainid;
+if (dvb_ac3_desc->asvc_flag) *q++ =
dvb_ac3_desc->asvc;
+} else {
+*q++=1; // 1 byte, all flags sets to 0
+*q++=0; // omit all fields...
+}
} else if (codec_id == AV_CODEC_ID_EAC3) {
*q++=0x7a; // EAC3 descriptor see A038 DVB SI
*q++=1; // 1 byte, all flags sets to 0
@@ -1843,6 +1865,63 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
* need to count the samples of that too! */
av_log(s, AV_LOG_WARNING, "Got MPEG-TS formatted Opus data,
unhandled");
}
+} else if (st->codecpar->codec_id == AV_CODEC_ID_AC3 &&
!ts_st->dvb_ac3_desc) {
+ AC3HeaderInfo *hdr = NULL;
+
+if (avpriv_ac3_parse_header(, pkt->data, pkt->size) >= 0) {
+uint8_t number_of_channels_flag;
+uint8_t service_type_flag;
+uint8_t full_service_flag = 1;
+DVBAC3Descriptor *dvb_ac3_desc;
+
+dvb_ac3_desc = av_mallocz(sizeof(*dvb_ac3_desc));
+if (!dvb_ac3_desc) {
+av_free(hdr);
+return AVERROR(ENOMEM);
+}
+
+service_type_flag = hdr->bitstream_mode;
+switch (hdr->channel_mode) {
+case AC3_CHMODE_DUALMONO:
+number_of_channels_flag = 1;
+
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mpegtsenc: support DVB 6A descriptor for AC-3
On Fri, Aug 14, 2020 at 10:29:45PM +0200, Marton Balint wrote:
>
>
> On Fri, 14 Aug 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > Sorry, fix for the patch order for fate test
> >
> > libavformat/mpegts.h| 16 +++
> > libavformat/mpegtsenc.c | 76
> > +
>
> I think the ac3_parser dependency of the mpegts muxer should be added to
> configure.
sure, will add the dependency to configure
>
> > 2 files changed, 92 insertions(+)
> >
> > diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> > index fe10b38..951aa61 100644
> > --- a/libavformat/mpegts.h
> > +++ b/libavformat/mpegts.h
> > @@ -175,6 +175,22 @@ typedef struct Mp4Descr {
> > SLConfigDescr sl;
> > } Mp4Descr;
> >
> > +/*
> > + * ETSI 300 468 descriptor 0x6A(AC-3)
> > + * Refer to: ETSI EN 300 468 V1.11.1 (2010-04) (SI in DVB systems)
> > + */
> > +typedef struct AVDVBAC3Descriptor {
> > +uint8_t component_type_flag;
> > +uint8_t bsid_flag;
> > +uint8_t mainid_flag;
> > +uint8_t asvc_flag;
> > +uint8_t reserved_flags;
> > +uint8_t component_type;
> > +uint8_t bsid;
> > +uint8_t mainid;
> > +uint8_t asvc;
> > +} AVDVBAC3Descriptor;
>
> As others suggested, remove AV prefix.
OK
>
> > +
> > /**
> > * Parse an MPEG-2 descriptor
> > * @param[in] fcFormat context (used for logging only)
> > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> > index 718ddab..e9ac08d 100644
> > --- a/libavformat/mpegtsenc.c
> > +++ b/libavformat/mpegtsenc.c
> > @@ -27,6 +27,7 @@
> > #include "libavutil/mathematics.h"
> > #include "libavutil/opt.h"
> >
> > +#include "libavcodec/ac3_parser_internal.h"
> > #include "libavcodec/internal.h"
> >
> > #include "avformat.h"
> > @@ -244,6 +245,8 @@ typedef struct MpegTSWriteStream {
> > /* For Opus */
> > int opus_queued_samples;
> > int opus_pending_trim_start;
> > +
> > +AVDVBAC3Descriptor *desc6a;
>
> Sorry, can you name the variable dvb_ac3_desc or something? This 6a still
> does not speak for itself...
sure, will fix it.
>
> > } MpegTSWriteStream;
> >
> > static void mpegts_write_pat(AVFormatContext *s)
> > @@ -486,9 +489,28 @@ static int mpegts_write_pmt(AVFormatContext *s,
> > MpegTSService *service)
> > case AVMEDIA_TYPE_AUDIO:
> > if (ts->flags & MPEGTS_FLAG_SYSTEM_B) {
> > if (codec_id == AV_CODEC_ID_AC3) {
> > +AVDVBAC3Descriptor *desc6a = ts_st->desc6a;
> > +
> > *q++=0x6a; // AC3 descriptor see A038 DVB SI
> > +if (desc6a) {
> > +int len = 1 +
> > + !!(desc6a->component_type_flag) +
> > + !!(desc6a->bsid_flag) +
> > + !!(desc6a->mainid_flag) +
> > + !!(desc6a->asvc_flag);
> > +
> > +*q++ = len;
> > +*q++ = desc6a->component_type_flag << 7 |
> > desc6a->bsid_flag << 6 |
> > + desc6a->mainid_flag << 5 |
> > desc6a->asvc_flag << 4;
> > +
> > +if (desc6a->component_type_flag) *q++ =
> > desc6a->component_type;
> > +if (desc6a->bsid_flag) *q++ =
> > desc6a->bsid;
> > +if (desc6a->mainid_flag) *q++ =
> > desc6a->mainid;
> > +if (desc6a->asvc_flag) *q++ =
> > desc6a->asvc;
> > +} else {
> > *q++=1; // 1 byte, all flags sets to 0
> > *q++=0; // omit all fields...
>
> I think these two lines are small enough to reindent in the same patch.
OK, will fix it
>
> > +}
> > } else if (codec_id == AV_CODEC_ID_EAC3) {
> > *q++=0x7a; // EAC3 descriptor see A038 DVB SI
> > *q++=1; // 1 byte, all flags sets to 0
> > @@ -1843,6 +1865,59 @@ static int
> > mpegts_write_packet_internal(AVFormatContext *s, AVPacket *pkt)
> > * need to count the samples of that too! */
> > av_log(s, AV_LOG_WARNING, "Got MPEG-TS formatted Opus data,
> > unhandled");
> > }
> > +} else if (st->codecpar->codec_id == AV_CODEC_ID_AC3 &&
> > !ts_st->desc6a) {
> > +uint8_t number_of_channels_flag;
> > +uint8_t service_type_flag;
> > +uint8_t full_service_flag = 1;
> > +AC3HeaderInfo *hdr = NULL;
> > +AVDVBAC3Descriptor *desc6a;
>
> push most of these initializers one level down
OK
>
> > +
> > +if (avpriv_ac3_parse_header(, pkt->data, pkt->size) >= 0) {
>
> Aren't you leaking hdr in the return path and at the end of this block?
Haven't notice the hdr will allocate memory, will fix it.
>
> > +desc6a = av_mallocz(sizeof(*desc6a));
>
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On 8/15/20, Alexander Strasser wrote: > Hi Derek, > hi all! > > On 2020-08-14 20:22 +0100, Derek Buitenhuis wrote: >> On 14/08/2020 20:13, Paul B Mahol wrote: >> >> Resending because I accidentally replied to James instead of the list. >> >> Woops. >> >> >> >> I guess it was not clear to me this is not the initial thread, since it >> >> is >> >> not >> >> a v2 patch, and no other thread is titled this, or seems to include >> >> SIMD? >> >> Perhaps >> >> I missed it. >> >> >> >> I still cannot actually locate any benchmarks in the various CFHD >> >> threads. >> >> If any were >> >> done, as would be needed, to, like... test ones own SIMD code, they >> >> should >> >> be included >> >> in the commit messages. >> > Results differs between various CPUs and environments and also depends >> > on >> > encoded file resolution and quality. >> >> Well, yes. That never stopped anyone from providing information. >> >> > With my local patch I get overall several percent speed increase with >> > only horiz_filter SSE2 applied. >> > I also work on vert_filter SSE2 code, which currently give big speedup >> > with lowest quality encodings and higher resolutions. >> > >> > For example: >> > >> > best quality 1080 60fps progressive yuv422p10 with additonal WIP >> > vertical filter: >> > cpuflags 0 speed : 0x243x realtime >> > cpuflags sse2 speed: 0x353x realtime >> > >> > worst quality 1080 60fps progressive yuv422p10 with additional WIP >> > vertical filter: >> > cpuflags 0 speed: 0x348x realtime >> > cpuflags sse2 speed: 0x811x realtime >> >> Thanks for finally providing some numbers. They should be in the commit >> messgae. >> >> > Also I want reviews to be technical as possible, i have not sent this >> > patch >> > to listen to bad remarks but to get more improvements in assembly code >> > if possible. >> >> Reviews of commit messages and methodolody or lack there of are valid >> reviews. >> >> > If you are not assembly developer and are not willing to test patches >> > better to >> > stay away from this thread. >> >> See below >> >> >> > >> >> (Nice that we still silently ignore various insults from Paul thrown >> >> around >> >> by the way.) >> > What specific insults in this thread? >> >> You wrote one just in this email, calling an ask for a better commit >> message and >> actual benchmarks "bad remarks", and previous wrote "You are not being >> helpful at all.". >> >> See also above: "If you are not assembly developer and are not willing to >> test patches better to >> stay away from this thread." >> >> Frankly, it's disgusting that this community prefers to silently ignore >> your (and others, >> but lately, mostly your) abusive and unfriendly conduct. > > I have just read this thread. > > Derek's initial comment was clearly valid I would say: > > I would expect any SIMD patch to include benchmarks showing it > is actually faster. I "insulted" Derek only after he called me troll. > > IMHO what followed was way too much back and forth and not really > nice at all. IMHO this kind of conversations are not for the good > of the community and probably neither for the individuals having > the conversation. > > So a better reply to Derek's concern would have been: > > Here are my (preliminary) benchmarks on my not so > representative CPU. > > or > > I will add benchmarks later and publish them before pushing. > > > Not really related to this in general is the reproducibility of > the benchmarks. That could be improved I think, but having some > benchmarks included is rather a must have and better than having > none. > > > [...] > > Best regards, > Alexander > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Read alternative frame rate from television header
On Fri, Aug 14, 2020 at 01:30:24AM -0700, Harry Mallon wrote:
> Signed-off-by: Harry Mallon
> ---
> libavcodec/dpx.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index b1833ed9ef..694deb27c5 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -216,10 +216,22 @@ static int decode_frame(AVCodecContext *avctx,
> else
> avctx->sample_aspect_ratio = (AVRational){ 0, 1 };
>
> +/* preferred frame rate from Motion-picture film header */
> if (offset >= 1724 + 4) {
> buf = avpkt->data + 1724;
> i = read32(, endian);
> -if(i) {
> +if(i && i != 0x) {
> +AVRational q = av_d2q(av_int2float(i), 4096);
> +if (q.num > 0 && q.den > 0)
> +avctx->framerate = q;
> +}
> +}
> +
> +/* alternative frame rate from television header */
> +if (!(avctx->framerate.num && avctx->framerate.den) && offset >=
> 1940 + 4) {
> +buf = avpkt->data + 1940;
Theres a linebreak which will break the diff (possibly from the used editor or
mail user agent)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
On Fri, Aug 14, 2020 at 08:20:28PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Thu, Aug 13, 2020 at 12:41:26PM +0100, Jack Haughton wrote: > >> Commit a500b975 removed NULL input handling from this function, > >> moving the check higher up the call tree in one branch. However, > >> there is another call to set_string_video_rate() which may pass > >> NULL, and future users of the function may not be clear that > >> a NULL check is required. This patch restores the NULL check to > >> avoid these problems. > >> --- > >> libavutil/opt.c | 5 - > >> 1 file changed, 4 insertions(+), 1 deletion(-) > > > > will apply > > > > thx > > > But is a NULL default value actually invalid/nonsense? I think not. See > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267444.html replied there thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swresample/rematrix: handle 22.2 as a 9 channel layout
On Fri, Aug 14, 2020 at 8:36 PM Michael Niedermayer wrote: > > On Thu, Aug 13, 2020 at 01:26:58AM +0300, Jan Ekström wrote: > > This is as far as 22.2 follows the same channel order as > > WaveFormatExtensible's channel mask (and the AV_CH_* defines). > > > > After LFE2 the side channels would follow, but that offset of > > one stops us from utilizing them without further tweaks. > > > > This change was verified by using swresample to downmix to 5.1, > > and then feeding that to WASAPI. > > --- > > libswresample/rematrix.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > probably ok > Thanks for taking a look. I originally planned on sending a link to a test sample I created somewhere during the time attempting to validate the AAC decoder, which I then also utilized to check the result of this: https://megumin.fushizen.eu/samples/22.2_input_test_sample.wav ...but alas then I never got to it afterwards. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@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] swresample/rematrix: handle 22.2 as a 9 channel layout
On Sat, Aug 15, 2020 at 12:29 PM Jan Ekström wrote: > > On Fri, Aug 14, 2020 at 8:36 PM Michael Niedermayer > wrote: > > > > On Thu, Aug 13, 2020 at 01:26:58AM +0300, Jan Ekström wrote: > > > This is as far as 22.2 follows the same channel order as > > > WaveFormatExtensible's channel mask (and the AV_CH_* defines). > > > > > > After LFE2 the side channels would follow, but that offset of > > > one stops us from utilizing them without further tweaks. > > > > > > This change was verified by using swresample to downmix to 5.1, > > > and then feeding that to WASAPI. > > > --- > > > libswresample/rematrix.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > probably ok > > > > Thanks for taking a look. I originally planned on sending a link to a > test sample I created somewhere during the time attempting to validate > the AAC decoder, which I then also utilized to check the result of > this: > https://megumin.fushizen.eu/samples/22.2_input_test_sample.wav > > ...but alas then I never got to it afterwards. > Aand once again hit the send button a bit too soon. For context, the reason why I started poking at this a bit more is because a friendly person elsewhere who implemented 22.2 to X downmix on his side pointed out that https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2159-8-2019-PDF-E.pdf contained the downmix matrix to 5.1 (TABLE11, System H is 22.2). So I planned on taking the same shortcut of doing 22.2->5.1->X, since 5.1 was already implemented or could be pushed to most audio output systems, but after looking at rematrix for a bit I got that no such shortcuts would be possible. So now the plan is to attempt to see if: 1) I can work around the +1 offset for side left/right, thus creating the base level 10.1 that seems to be implemented in rematrix. 2) Mix top/bottom channels into their matching base level, adding support for them being mixed in. 3) Mix LFE2 into LFE1. If this would work, we could get a downmix going by means of 22.2->10.1->X . Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats
On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson wrote:
>
> On 26/07/2020 13:26, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > Export choosen pict_type and qp.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/libkvazaar.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> > index 71c9c8f..9032547 100644
> > --- a/libavcodec/libkvazaar.c
> > +++ b/libavcodec/libkvazaar.c
> > @@ -37,6 +37,7 @@
> >
> > #include "avcodec.h"
> > #include "internal.h"
> > +#include "packet_internal.h"
> >
> > typedef struct LibkvazaarContext {
> > const AVClass *class;
> > @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> > kvz_data_chunk *data_out = NULL;
> > uint32_t len_out = 0;
> > int retval = 0;
> > +int pict_type;
> >
> > *got_packet_ptr = 0;
> >
> > @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> > avpkt->flags |= AV_PKT_FLAG_KEY;
> > }
> >
> > +switch (frame_info.slice_type) {
> > +case KVZ_SLICE_I:
> > +pict_type = AV_PICTURE_TYPE_I;
> > +break;
> > +case KVZ_SLICE_P:
> > +pict_type = AV_PICTURE_TYPE_P;
> > +break;
> > +case KVZ_SLICE_B:
> > +pict_type = AV_PICTURE_TYPE_B;
> > +break;
> > +default:
> > +av_log(avctx, AV_LOG_ERROR, "Unknown picture type
> > encountered.\n");
> > +return AVERROR_EXTERNAL;
> > +}
> > +#if FF_API_CODED_FRAME
> > +FF_DISABLE_DEPRECATION_WARNINGS
> > +avctx->coded_frame->pict_type = pict_type;
> > +FF_ENABLE_DEPRECATION_WARNINGS
> > +#endif
>
> Is there some value to setting the deprecated fields? They will disappear on
> the next version bump, which probably isn't very far away.
>
I think we can keep this part, if we want to remove the
avctx->coded_frame->pict_type from next version bump, we can drop this
part from all codec one-time
> > +
> > +ff_side_data_set_encoder_stats(avpkt, frame_info.qp *
> > FF_QP2LAMBDA, NULL, 0, pict_type);
>
> I'm not familiar with kvazaar - is the QP value here actually reflective of
> the global quality in a useful way? The documentation is not very good...
>
Yes, it's a global quality based on Frame in kvazaar
> (Your following patch for OpenH264 uses a field "AverageFrameQP", which has
> an much more usefully-suggestive name.)
>
> Zero is a valid QP value, but you shouldn't be passing it here. Possibly it
> needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
>
I know vpx encoder wrapper used the zero QP value in side data, maybe
we can keep the same action
> > +
> > +#if FF_API_CODED_FRAME
> > +FF_DISABLE_DEPRECATION_WARNINGS
> > +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> > +FF_ENABLE_DEPRECATION_WARNINGS
> > +#endif
> > +
> > *got_packet_ptr = 1;
> > }
> >
> >
> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutil/opt: Restore NULL input handling to set_string_video_rate()
On Thu, Aug 06, 2020 at 02:43:08PM +0200, Andreas Rheinhardt wrote:
> Jack Haughton:
> > Commit a500b975 removed NULL input handling from this function,
> > moving the check higher up the call tree in one branch. However,
> > there is another call to set_string_video_rate() which may pass
> > NULL, and future users of the function may not be clear that
> > a NULL check is required. This patch restores the NULL check to
> > avoid these problems.
> > ---
> > libavutil/opt.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/opt.c b/libavutil/opt.c
> > index c8413fa5e1..9f36dc89a9 100644
> > --- a/libavutil/opt.c
> > +++ b/libavutil/opt.c
> > @@ -333,7 +333,13 @@ static int set_string_image_size(void *obj, const
> > AVOption *o, const char *val,
> >
> > static int set_string_video_rate(void *obj, const AVOption *o, const char
> > *val, AVRational *dst)
> > {
> > -int ret = av_parse_video_rate(dst, val);
> > +int ret;
> > +
> > +if (!val) {
> > +av_log(obj, AV_LOG_ERROR, "NULL passed as video rate\n");
> > +return AVERROR(EINVAL);
> > +}
> > +ret = av_parse_video_rate(dst, val);
> > if (ret < 0)
> > av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
> > video rate\n", val);
> > return ret;
> >
> I pondered this other caller back then [1] and thought that a NULL
> default value for a framerate was illegal and that therefore the
> function should fail hard in such a case to force the programmer to fix
> the code. But upon rereading the doc I couldn't find any documentation
> that actually said that a default value of NULL is illegal. I have
> probably misunderstood the "offset must point to AVRational" comment in
> opt.h (which only says how the value will be stored and says nothing
> about the default value)).
>
> There is even a usecase for allowing a NULL as default value: When one
> wants to know whether the user has set a value or not. (Right now this
> is not possible (at least not without a second option that says that the
> other framerate option is to be used), because av_parse_video_rate()
> does not allow illegal values (numerator or denumerator <= 0) for the
> framerate.) So a possible usecase could be as follows: If a file
> contains a framerate, but if one wants to allow the user to override the
> framerate, then not using a default value is natural.
>
> Of course in this case set_string_video_rate() should not be called at
> all; instead the case should be handled in av_opt_set_default2() which
> should set the value explicitly to (AVRational){ 0, 0 } in this case.
>
> What do others think about this?
I think the handling of "not set" should be consistent between types
and should follow a few properties
For example Value <-> String should maintain that "not set"
for Rationals, 0/0 is the natural mathetmatical way of saying not set.
There is also the aspect that we may not want to allow every AVOption
to be "not set"
For integers a valid value has to be used for a not set form and that
can then easily be bounded by the min/max so as to specify it as (not)allowed
but for oters based on AVRational or floats the support for NaN is not so
natural to specify.
So we should probably add a AV_OPT_FLAG_ALLOW_NAN or equivalent
[...]
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- 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] avcodec/cfhd: add x86 SIMD
Hi Derek, hi all! On 2020-08-14 20:22 +0100, Derek Buitenhuis wrote: > On 14/08/2020 20:13, Paul B Mahol wrote: > >> Resending because I accidentally replied to James instead of the list. > >> Woops. > >> > >> I guess it was not clear to me this is not the initial thread, since it is > >> not > >> a v2 patch, and no other thread is titled this, or seems to include SIMD? > >> Perhaps > >> I missed it. > >> > >> I still cannot actually locate any benchmarks in the various CFHD threads. > >> If any were > >> done, as would be needed, to, like... test ones own SIMD code, they should > >> be included > >> in the commit messages. > > Results differs between various CPUs and environments and also depends on > > encoded file resolution and quality. > > Well, yes. That never stopped anyone from providing information. > > > With my local patch I get overall several percent speed increase with > > only horiz_filter SSE2 applied. > > I also work on vert_filter SSE2 code, which currently give big speedup > > with lowest quality encodings and higher resolutions. > > > > For example: > > > > best quality 1080 60fps progressive yuv422p10 with additonal WIP > > vertical filter: > > cpuflags 0 speed : 0x243x realtime > > cpuflags sse2 speed: 0x353x realtime > > > > worst quality 1080 60fps progressive yuv422p10 with additional WIP > > vertical filter: > > cpuflags 0 speed: 0x348x realtime > > cpuflags sse2 speed: 0x811x realtime > > Thanks for finally providing some numbers. They should be in the commit > messgae. > > > Also I want reviews to be technical as possible, i have not sent this patch > > to listen to bad remarks but to get more improvements in assembly code > > if possible. > > Reviews of commit messages and methodolody or lack there of are valid reviews. > > > If you are not assembly developer and are not willing to test patches > > better to > > stay away from this thread. > > See below > > > > > >> (Nice that we still silently ignore various insults from Paul thrown around > >> by the way.) > > What specific insults in this thread? > > You wrote one just in this email, calling an ask for a better commit message > and > actual benchmarks "bad remarks", and previous wrote "You are not being > helpful at all.". > > See also above: "If you are not assembly developer and are not willing to > test patches better to > stay away from this thread." > > Frankly, it's disgusting that this community prefers to silently ignore your > (and others, > but lately, mostly your) abusive and unfriendly conduct. I have just read this thread. Derek's initial comment was clearly valid I would say: I would expect any SIMD patch to include benchmarks showing it is actually faster. IMHO what followed was way too much back and forth and not really nice at all. IMHO this kind of conversations are not for the good of the community and probably neither for the individuals having the conversation. So a better reply to Derek's concern would have been: Here are my (preliminary) benchmarks on my not so representative CPU. or I will add benchmarks later and publish them before pushing. Not really related to this in general is the reproducibility of the benchmarks. That could be improved I think, but having some benchmarks included is rather a must have and better than having none. [...] Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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-cvslog] lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose().
On 2020-08-13 00:13 +0200, Nicolas George wrote: > Alexander Strasser (12020-08-12): > > Stupid question: Why do we transform relative URLs at all? > > > > Isn't it normally supposed to work for HTTP on the server-side too? > > > > Many clients seem to do it. Just curious why... > > At the very least, we need to be able to combine: > > http://site.com/contents/text/index.html + ../media/file.mp4 > > into > > http://site.com/contents/text/../media/file.mp4 > > and > > http://site.com/contents/text/index.html + //media.site.com/file.mp4 > > into > > http://media.site.com/file.mp4 > > because that is what we need to contact the relevant server and generate > the request. Eliminating double-dots components is just an easy bonus. Thanks for the quick answers Nicolas and Marton! First I must apologize, my wording was wrong. I didn't mean relative URL but relatives paths in URLs. I was just curious in general and because it seemed on a glance that the referenced tickets only had problems with removing-dot-segments-gone-wrong . That seems to be kind of confirmed by Nicolas answer, but I guess the initial prompt for Nicolas to rewrite that stuff didn't come from the referenced tickets. It was another thing he noticed while looking at ff_make_absolute_url. IIRC that was something concerning the handling of relative URLs (not their dot-segments). If I'm not mistaken that reason for the rewrite didn't make it into the commit message: lavf/url: rewrite ff_make_absolute_url() using ff_url_decompose(). Also add and update some tests. Change the semantic a little, because for filesytem paths symlinks complicate things. See the comments in the code for detail. Fix trac tickets #8813 and 8814. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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] doc/developer: origin of tables should be documented.
On 2020-08-14 11:34 +0200, Jean-Baptiste Kempf wrote: > On Wed, 12 Aug 2020, at 14:38, Alexander Strasser wrote: > > On 2020-08-12 12:32 +0200, Jean-Baptiste Kempf wrote: > > > On Wed, 12 Aug 2020, at 00:29, Alexander Strasser wrote: > > > > Definitions of non-obvious data should have a short comment > > > > explaining their origin. > > > > > > > > If the data is of mathematical origin, you can document that > > > > or use code snippets or pseudo-code. If the data was gained > > > > empirically, describe the methods used. If the data was taken > > > > from a document like a specification, reference the section > > > > and/or table number. A link can also be used, if there is a > > > > stable source and there are no better ways. > > > > > > > > If you generated the data with a program, consider including > > > > the source code in FFmpeg and reference it in the comment. > > > > > > > > Typical examples are tables of numbers. Here is one: > > > > > > > > > > > > > > > > > > > > I feel it could well be improved, though I wasn't able to do it > > > > myself :( Maybe others can help. > > > > > > What about RE values? > > > > All in all it's same as Nicolas' proposal: The convention is to > > document the origin of the data. It says should, which is not must. > > SHOULD can mean "really mandatory, besides exceptions", so I would soften it, > to explain common sense must be shared, like "if origin is mathematical or > specification", or similar. > > But I like your version. Maybe instead of Definitions of non-obvious data should have a short comment explaining their origin. changing the first paragraph to Consider documenting the origin of non-obvious data in a short commment above its definition. would help? It sounds less like a "formal should" and probably doesn't change the "effective adoption rate" at all. What do you think? Thanks for your feedback! Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
