Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.

[Steven Liu]

hwren  于2018年7月19日周四 上午10:38写道：
>
> Ping, any comments for following patches?
will push after one week if there have no objections.
>
>
>
>
>
>
>
> At 2018-07-16 15:24:54, "hwren"  wrote:
> >hwren (3):
> >  lavc: add avs2 parser
> >  lavf: add avs2 fourcc
> >  lavc,doc,configure: add avs2 video decoder wrapper
> >
> > Changelog|   1 +
> > configure|   4 ++
> > doc/decoders.texi|   6 ++
> > doc/general.texi |  14 
> > libavcodec/Makefile  |   2 +
> > libavcodec/allcodecs.c   |   1 +
> > libavcodec/avcodec.h |   1 +
> > libavcodec/avs2_parser.c |  95 +
> > libavcodec/codec_desc.c  |   7 ++
> > libavcodec/libdavs2.c| 177 
> > +++
> > libavcodec/parser.c  |   1 +
> > libavcodec/version.h |   4 +-
> > libavformat/riff.c   |   1 +
> > 13 files changed, 312 insertions(+), 2 deletions(-)
> > create mode 100644 libavcodec/avs2_parser.c
> > create mode 100644 libavcodec/libdavs2.c
> >
> >--
> >2.7.4
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings for DolbyVision

[James Almer]

On 7/19/2018 9:18 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch silences several warnings shown for each frame in
> DolbyVision streams, this time checking the whole separator as
> suggested by Hendrik.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavc-hevcdec-Silence-warnings-when-decoding-DolbyVis.patch
> 
> 
> From 9276b75de767dbccabb39d8dcaf5d373a1daa0ef Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 20 Jul 2018 02:16:04 +0200
> Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.
> 
> ---
>  libavcodec/hevcdec.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 409e77f..4a047b8 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -3000,6 +3000,10 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  case HEVC_NAL_AUD:
>  case HEVC_NAL_FD_NUT:
>  break;
> +case 62:
> +case 63:
> +if (!s->temporal_id) // DolbyVision
> +break;
>  default:
>  av_log(s->avctx, AV_LOG_INFO,
> "Skipping NAL unit %d\n", s->nal_unit_type);

This message could also (or instead) be changed to verbose.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext

[James Almer]

Certain AVCodecParameters, like the contents of the extradata, may be changed
by the init() function of any of the bitstream filters in the chain.

Signed-off-by: James Almer 
---
Things worked fine without this until now by pure chance. vp9_superframe_split
doesn't use extradata, and those hardware decoders inserting h264_mp4toannexb
and hevc_mp4toannexb passed the extradata to functions that could handle it
unfiltered.

 libavcodec/decode.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6a3a4df179..0c8cdd5bd2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -246,6 +246,10 @@ static int bsfs_init(AVCodecContext *avctx)
 goto fail;
 }
 
+ret = avcodec_parameters_to_context(avctx, s->bsfs[s->nb_bsfs - 
1]->par_out);
+if (ret < 0)
+return ret;
+
 return 0;
 fail:
 ff_decode_bsfs_uninit(avctx);
-- 
2.18.0

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

[FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings for DolbyVision

[Carl Eugen Hoyos]

Hi!

Attached patch silences several warnings shown for each frame in
DolbyVision streams, this time checking the whole separator as
suggested by Hendrik.

Please comment, Carl Eugen
From 9276b75de767dbccabb39d8dcaf5d373a1daa0ef Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 20 Jul 2018 02:16:04 +0200
Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.

---
 libavcodec/hevcdec.c |4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 409e77f..4a047b8 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3000,6 +3000,10 @@ static int decode_nal_unit(HEVCContext *s, const H2645NAL *nal)
 case HEVC_NAL_AUD:
 case HEVC_NAL_FD_NUT:
 break;
+case 62:
+case 63:
+if (!s->temporal_id) // DolbyVision
+break;
 default:
 av_log(s->avctx, AV_LOG_INFO,
"Skipping NAL unit %d\n", s->nal_unit_type);
-- 
1.7.10.4

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

[FFmpeg-devel] Sponsoring request

[Paul B Mahol]

Hi,

I want that FFmpeg community sponsor addition of new code I gonna
develop in following days/months.

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

Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined

[Tobias Rapp]

On 18.07.2018 19:31, Marcin Gorzel wrote:

Rematrixing supports up to 64 channels. However, there is only a limited number 
of channel layouts defined. Since the in/out channel count is obtained from the 
channel layout, for undefined layouts (e.g. for 9, 10, 11 channels etc.) the 
rematrixing fails.

In ticket #6790 the problem has been partially addressed by applying a patch to 
swr_set_matrix() in rematrix.c:72.
However, a similar change must be also applied to swri_rematrix_init() in 
rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
---
  libswresample/rematrix.c  | 6 --
  libswresample/x86/rematrix_init.c | 6 --
  2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..d1a0cfe7f8 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -384,8 +384,10 @@ av_cold static int auto_matrix(SwrContext *s)
  
  av_cold int swri_rematrix_init(SwrContext *s){

  int i, j;
-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
+av_get_channel_layout_nb_channels(s->in_ch_layout);
+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
+av_get_channel_layout_nb_channels(s->out_ch_layout);
  
  s->mix_any_f = NULL;
  
diff --git a/libswresample/x86/rematrix_init.c b/libswresample/x86/rematrix_init.c

index d71b41a73e..4f9c92e4ab 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,10 @@ D(int16, sse2)
  av_cold int swri_rematrix_init_x86(struct SwrContext *s){
  #if HAVE_X86ASM
  int mm_flags = av_get_cpu_flags();
-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
+av_get_channel_layout_nb_channels(s->in_ch_layout);
+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
+av_get_channel_layout_nb_channels(s->out_ch_layout);
  int num= nb_in * nb_out;
  int i,j;
  



Patch looks good to me, except that the title should be updated to 
reflect the new logic. I suggest something like "swresample: Use channel 
count for rematrix initialization if defined".


If nobody objects within the next days I will amend the title, push the 
patch to master and backport the fix to release branches.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined

[Marcin Gorzel]

Hi Tobias,

Sounds good, thanks a lot!

Regards,

Marcin

On Thu, Jul 19, 2018 at 12:53 PM Tobias Rapp  wrote:

> On 18.07.2018 19:31, Marcin Gorzel wrote:
> > Rematrixing supports up to 64 channels. However, there is only a limited
> number of channel layouts defined. Since the in/out channel count is
> obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
> channels etc.) the rematrixing fails.
> >
> > In ticket #6790 the problem has been partially addressed by applying a
> patch to swr_set_matrix() in rematrix.c:72.
> > However, a similar change must be also applied to swri_rematrix_init()
> in rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
> > ---
> >   libswresample/rematrix.c  | 6 --
> >   libswresample/x86/rematrix_init.c | 6 --
> >   2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> > index 8227730056..d1a0cfe7f8 100644
> > --- a/libswresample/rematrix.c
> > +++ b/libswresample/rematrix.c
> > @@ -384,8 +384,10 @@ av_cold static int auto_matrix(SwrContext *s)
> >
> >   av_cold int swri_rematrix_init(SwrContext *s){
> >   int i, j;
> > -int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > +int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> > +av_get_channel_layout_nb_channels(s->in_ch_layout);
> > +int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> > +av_get_channel_layout_nb_channels(s->out_ch_layout);
> >
> >   s->mix_any_f = NULL;
> >
> > diff --git a/libswresample/x86/rematrix_init.c
> b/libswresample/x86/rematrix_init.c
> > index d71b41a73e..4f9c92e4ab 100644
> > --- a/libswresample/x86/rematrix_init.c
> > +++ b/libswresample/x86/rematrix_init.c
> > @@ -33,8 +33,10 @@ D(int16, sse2)
> >   av_cold int swri_rematrix_init_x86(struct SwrContext *s){
> >   #if HAVE_X86ASM
> >   int mm_flags = av_get_cpu_flags();
> > -int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > +int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> > +av_get_channel_layout_nb_channels(s->in_ch_layout);
> > +int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> > +av_get_channel_layout_nb_channels(s->out_ch_layout);
> >   int num= nb_in * nb_out;
> >   int i,j;
> >
> >
>
> Patch looks good to me, except that the title should be updated to
> reflect the new logic. I suggest something like "swresample: Use channel
> count for rematrix initialization if defined".
>
> If nobody objects within the next days I will amend the title, push the
> patch to master and backport the fix to release branches.
>
> Regards,
> Tobias
>
>

-- 

Marcin Gorzel |  Software Engineer |  gor...@google.com |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Sponsoring request

[Kieran O Leary]

Hi

On Thu, 19 Jul 2018, 14:04 Paul B Mahol,  wrote:

> Hi,
>
> I want that FFmpeg community sponsor addition of new code I gonna
> develop in following days/months.
>

Are you suggesting a patreon type payment?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Sponsoring request

[Paul B Mahol]

On 7/19/18, Kieran O Leary  wrote:
> Hi
>
> On Thu, 19 Jul 2018, 14:04 Paul B Mahol,  wrote:
>
>> Hi,
>>
>> I want that FFmpeg community sponsor addition of new code I gonna
>> develop in following days/months.
>>
>
> Are you suggesting a patreon type payment?

It could be, but it doesn't need to be.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/bink: add 'k' version support

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/bink.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/libavcodec/bink.c b/libavcodec/bink.c
index c4cf617a8b..b3136b763c 100644
--- a/libavcodec/bink.c
+++ b/libavcodec/bink.c
@@ -371,11 +371,19 @@ static const uint8_t bink_rlelens[4] = { 4, 8, 12, 32 };
 
 static int read_block_types(AVCodecContext *avctx, GetBitContext *gb, Bundle 
*b)
 {
+BinkContext * const c = avctx->priv_data;
 int t, v;
 int last = 0;
 const uint8_t *dec_end;
 
 CHECK_READ_VAL(gb, b, t);
+if (c->version == 'k') {
+t ^= 0xBBu;
+if (t == 0) {
+b->cur_dec = NULL;
+return 0;
+}
+}
 dec_end = b->cur_dec + t;
 if (dec_end > b->data_end) {
 av_log(avctx, AV_LOG_ERROR, "Too many block type values\n");
@@ -994,6 +1002,17 @@ static int bink_decode_plane(BinkContext *c, AVFrame 
*frame, GetBitContext *gb,
 int bw = is_chroma ? (c->avctx->width  + 15) >> 4 : (c->avctx->width  + 7) 
>> 3;
 int bh = is_chroma ? (c->avctx->height + 15) >> 4 : (c->avctx->height + 7) 
>> 3;
 int width = c->avctx->width >> is_chroma;
+int height = c->avctx->height >> is_chroma;
+
+if (c->version == 'k' && get_bits1(gb)) {
+int fill = get_bits(gb, 8);
+
+dst = frame->data[plane_idx];
+
+for (i = 0; i < height; i++)
+memset(dst + i * stride, fill, width);
+goto end;
+}
 
 init_lengths(c, FFMAX(width, 8), bw);
 for (i = 0; i < BINK_NB_SRC; i++)
@@ -1190,6 +1209,8 @@ static int bink_decode_plane(BinkContext *c, AVFrame 
*frame, GetBitContext *gb,
 }
 }
 }
+
+end:
 if (get_bits_count(gb) & 0x1F) //next plane data starts at 32-bit boundary
 skip_bits_long(gb, 32 - (get_bits_count(gb) & 0x1F));
 
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH 4/5] avformat/mov: add support for AV1 streams

[Francois Cartegnie]

Hi,

Sorry, can't reply to thread.

> +if (version != 0) {
> +av_log(c->fc, AV_LOG_WARNING, "Unknown AV1 Codec Configuration Box 
> version %d\n", version);
> +return 0;
> +}
> +avio_skip(pb, 3); /* flags */
> +
> +avio_skip(pb, 1); /* reserved, initial_presentation_delay_present, 
> initial_presentation_delay_minus_one */
> +
> +ret = ff_get_extradata(c->fc, st->codecpar, pb, atom.size - 5);

Seems to me that using OBU only as internal extradata, unlike h264 or
hevc, will only cause issues.

There's no version as a guarantee on which OBU should be found, and it
implies parsing OBU just like with AnnexB.
Parsing might also not be possible without accessing samples data when
there's potentially zero OBU in DCR.

I've raised the issue on the spec, as the DCR itself does not seems to
contain enough extracted information, like profile for routing to a
proper decoder.

-- 
Francois Cartegnie
VideoLAN - VLC Developer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reimbursement request

[Thilo Borgmann]

> Am 01.07.2018 um 23:27 schrieb Thomas Volkert :
> 
> 
>> On 23.03.2018 22:12, Thilo Borgmann wrote:
>>> Am 18.03.18 um 20:57 schrieb Thilo Borgmann:
>>> Hi,
>>> 
 As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in
 addition, Thilo and I went to Brussels for FOSDEM where we attended
 the talks in the multimedia room kindly (co-) organized by Kieran and
 answered some questions. I would like to request reimbursement for the
 travel costs, that's flights-only, Thilo payed the gasoline and the
 hotel.
>>> from my side there are hotel & gas for Chemnitz, and flight & hotel for 
>>> Brussels that I'd like to ask to reimburse for. For Chemnitz it is the 
>>> usual drive by car Carl Eugen and me do from Berlin, which are around 290 
>>> km one way as well as a shared hotel room (they did not manage to put all 
>>> of us into one suite this time, so we had to stick to two rooms for all 
>>> four of us):
>>> 
 Chemnitz: 125,85
>>> Hotel: 194.00 EUR
>>> Gas:   36.62 + 21.67 + 39.51 =  97.80 EUR
>>> -
>>> Total: 291,80 EUR
>>> 
>>> 
 Brussels: 192,41
>>> Flight:111.81 EUR
>>> Hotel: 186.69 EUR
>>> -
>>> Total: 298,50 EUR
>>> 
>>> 
>>> BTW, on both events some of our T-Shirts have found their way to some 
>>> users, forgot to mention this in the CLT report. Also, we ran out of stock 
>>> of our stickers during CLT, so I will order new ones asap. I also forgot to 
>>> mention that we have met the organizers of a similar event in Prague in 
>>> October (LinuxDays) [1]. I'll try to have us there with a booth, too!
>>> 
>>> Also, regarding FOSDEM, I'd really like to have a booth there from next 
>>> year on. In contrast to Chemnitz (and possibly Prague), Brussels is an 
>>> expensive place in general though I could get an AirBNB near the price of 
>>> an actual hotel in Chemnitz. FOSDEM of course is the biggest event with a 
>>> bigger audience of technical knowledge in our field, so we really should 
>>> consider a booth at FOSDEM, IMHO. (However this is almost a year in the 
>>> future)
>>> 
>>> If there are no objections, I'll send all the invoices to Stefano privately 
>>> (like I almost always do...;)
>>> 
> 
> My expenses contained:
> - 184 € for 1080 km of traveling from the area of Stuttgart to Chemnitz
> (transporting monitor and other equipment, stopped midway again)
> - 194€ for the hotel double room during the weekend for Alexander
> Strasser and me.
> => 378 €
> 
> I will send the invoice to Stefano.
> 
> (pictures are already on our Facebook page)

Ping. I guess it‘s not for an attendee to ok Thomas request but someone else 
please do. 

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

[FFmpeg-devel] [PATCH] libavcodec/escape130: fixes and improvements

[Michael Chaban]

Hi!

Recently I completely decompiled original Eidos Escape codecs, and I wanted to 
fix and improve Escape130 code of ffmpeg.
Here are three sequential commits and very short (few frames) RPL-video file 
sample. 

Please review, Michael Chaban

- - - Image links to compare - - -
Original Eidos decoder: https://ibb.co/mvLUby
FFmpeg before my commits: https://ibb.co/k8GP9J
FFmpeg after 1/3 commit: thttps://ibb.co/dUavGy
FFmpeg after 2/3 commit: https://ibb.co/cgLj9J
FFmpeg after 3/3 commit: https://ibb.co/isTFGy



0001-libavcodec-escape130-fixed-wrong-Y-copy-block-decodi.patch
Description: Binary data


0002-libavcodec-escape130-the-default-YUV-colorspace-repl.patch
Description: Binary data


0003-libavcodec-escape130-The-original-decoder-blockiness.patch
Description: Binary data


short_sample.rpl
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy

[Thilo Borgmann]

> Am 16.07.2018 um 13:41 schrieb Mina :
> 
> Hi,
> 
>   This patch introduces Grey-Edge algorithm as part of the Color Constancy 
> Filter project in GSOC.
> 
> V4 changes:
> - Fixed error in filter.texi that resulted in breaking "make 
> doc/ffprobe-all.html"

If there are no more comments coming in I‘ll push this in a couple of days. 

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

[FFmpeg-devel] [PATCH 1/2] avformat/bink: move code for skipping unknown fields to correct place

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/bink.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavformat/bink.c b/libavformat/bink.c
index 8a05082fcd..567a38cd73 100644
--- a/libavformat/bink.c
+++ b/libavformat/bink.c
@@ -92,6 +92,8 @@ static int read_header(AVFormatContext *s)
 uint16_t flags;
 int keyframe;
 int ret;
+uint32_t signature;
+uint8_t revision;
 
 vst = avformat_new_stream(s, NULL);
 if (!vst)
@@ -160,14 +162,14 @@ static int read_header(AVFormatContext *s)
 return AVERROR(EIO);
 }
 
-if (bink->num_audio_tracks) {
-uint32_t signature = (vst->codecpar->codec_tag & 0xFF);
-uint8_t revision = ((vst->codecpar->codec_tag >> 24) % 0xFF);
+signature = (vst->codecpar->codec_tag & 0xFF);
+revision = ((vst->codecpar->codec_tag >> 24) % 0xFF);
 
-if ((signature == AV_RL32("BIK") && (revision == 0x6b)) || /* k */
-(signature == AV_RL32("KB2") && (revision == 0x69 || revision == 
0x6a || revision == 0x6b))) /* i,j,k */
-avio_skip(pb, 4); /* unknown new field */
+if ((signature == AV_RL32("BIK") && (revision == 'k')) ||
+(signature == AV_RL32("KB2") && (revision == 'i' || revision == 'j' || 
revision == 'k')))
+avio_skip(pb, 4); /* unknown new field */
 
+if (bink->num_audio_tracks) {
 avio_skip(pb, 4 * bink->num_audio_tracks); /* max decoded size */
 
 for (i = 0; i < bink->num_audio_tracks; i++) {
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] mistake in Patch: Fix segmentation fault with decoding on android oreo

[Peter Bennett]

There is an error in this patch. I will submit a corrected version. 
Please disregard this one.


Peter


On 07/19/2018 11:57 AM, Peter Bennett wrote:

avcodec_receive_frame consistently causes a seg fault when decoding 1080i mpeg2
on android version oreo. When copying the frame, the second plane in the buffer
follows on immediately after 1080 lines of the first plane, but the code assumes
it is after 1088 lines of the first plane, based on slice_height. It crashes on
copying data for the second plane when it hits the actual end of the data and
starts accessing addresses beyond that.

Instead of using slice_height here, change to use use height. slice_height is
used at other places in this module and I do not know if they also need to be
changed. I have confirmed that with this change, decoding works correctly
on android oreo as well as on the prior version, android nougat.
---
  libavcodec/mediacodec_sw_buffer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodec_sw_buffer.c 
b/libavcodec/mediacodec_sw_buffer.c
index 92428e85f0..3b80e1fb59 100644
--- a/libavcodec/mediacodec_sw_buffer.c
+++ b/libavcodec/mediacodec_sw_buffer.c
@@ -100,7 +100,7 @@ void 
ff_mediacodec_sw_buffer_copy_yuv420_planar(AVCodecContext *avctx,
  src += s->slice_height * s->stride;
  
  if (i == 2) {

-src += ((s->slice_height + 1) / 2) * stride;
+src += ((s->height + 1) / 2) * stride;
  }
  
  src += s->crop_top * stride;


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

[FFmpeg-devel] [PATCH 5/6] diracdec: avx2 dd97

[James Darnley]

---
 libavcodec/x86/dirac_dwt_10bit.asm|  3 ++-
 libavcodec/x86/dirac_dwt_init_10bit.c | 13 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
index ae110d2945..2e039e11ea 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -25,7 +25,7 @@ SECTION_RODATA
 
 cextern pd_1
 pd_2: times 8 dd 2
-pd_8: times 4 dd 8
+pd_8: times 8 dd 8
 
 SECTION .text
 
@@ -202,6 +202,7 @@ HAAR_HORIZONTAL
 HAAR_VERTICAL
 
 INIT_YMM avx2
+DD97_VERTICAL_HI
 HAAR_HORIZONTAL
 HAAR_VERTICAL
 LEGALL53_VERTICAL_HI
diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c 
b/libavcodec/x86/dirac_dwt_init_10bit.c
index 51d6eeae93..f103a56176 100644
--- a/libavcodec/x86/dirac_dwt_init_10bit.c
+++ b/libavcodec/x86/dirac_dwt_init_10bit.c
@@ -24,6 +24,7 @@
 #include "libavcodec/dirac_dwt.h"
 
 void ff_dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int32_t 
*b3, int32_t *b4, int width);
+void ff_dd97_vertical_hi_avx2(int32_t *b0, int32_t *b1, int32_t *b2, int32_t 
*b3, int32_t *b4, int width);
 
 void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
 void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
@@ -137,7 +138,15 @@ static void dd97_vertical_hi_sse2(int32_t *b0, int32_t 
*b1, int32_t *b2,
 ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
 for(; ivertical_compose_h0 = (void*)dd97_vertical_hi_avx2;
+d->vertical_compose_l0 = (void*)legall53_vertical_lo_avx2;
+break;
 case DWT_DIRAC_LEGALL5_3:
 d->vertical_compose_h0 = (void*)legall53_vertical_hi_avx2;
 d->vertical_compose_l0 = (void*)legall53_vertical_lo_avx2;
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[James Darnley]

Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 84fps
SSE2: 111fps
AVX2: 115fps
---
 libavcodec/x86/dirac_dwt_10bit.asm| 38 +++
 libavcodec/x86/dirac_dwt_init_10bit.c | 16 +++
 2 files changed, 54 insertions(+)

diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
index c00de32bfe..681de5e1df 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -25,6 +25,7 @@ SECTION_RODATA
 
 cextern pd_1
 pd_2: times 4 dd 2
+pd_8: times 4 dd 8
 
 SECTION .text
 
@@ -153,7 +154,44 @@ RET
 
 %endmacro
 
+%macro DD97_VERTICAL_HI 0
+
+cglobal dd97_vertical_hi, 6, 6, 8, b0, b1, b2, b3, b4, w
+mova m7, [pd_8]
+shl wd, 2
+add b0q, wq
+add b1q, wq
+add b2q, wq
+add b3q, wq
+add b4q, wq
+neg wq
+
+ALIGN 16
+.loop:
+mova m0, [b0q + wq]
+mova m1, [b1q + wq]
+mova m2, [b2q + wq]
+mova m3, [b3q + wq]
+mova m4, [b4q + wq]
+pslld m5, m1, 3
+pslld m6, m3, 3
+paddd m5, m1
+paddd m6, m3
+psubd m5, m0
+psubd m6, m4
+paddd m5, m7
+paddd m5, m6
+psrad m5, 4
+paddd m2, m5
+mova [b2q + wq], m2
+add wq, mmsize
+jl .loop
+RET
+
+%endmacro
+
 INIT_XMM sse2
+DD97_VERTICAL_HI
 HAAR_HORIZONTAL
 HAAR_VERTICAL
 LEGALL53_VERTICAL_HI
diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c 
b/libavcodec/x86/dirac_dwt_init_10bit.c
index 88cf267d14..e7e7534050 100644
--- a/libavcodec/x86/dirac_dwt_init_10bit.c
+++ b/libavcodec/x86/dirac_dwt_init_10bit.c
@@ -23,6 +23,8 @@
 #include "libavutil/x86/cpu.h"
 #include "libavcodec/dirac_dwt.h"
 
+void ff_dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int32_t 
*b3, int32_t *b4, int width);
+
 void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
 void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
 
@@ -110,6 +112,16 @@ static void legall53_vertical_hi_sse2(int32_t *b0, int32_t 
*b1, int32_t *b2, int
 b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
 }
 
+static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
+  int32_t *b3, int32_t *b4, int width)
+{
+int i = width & ~3;
+ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
+for(; ivertical_compose_h0 = (void*)dd97_vertical_hi_sse2;
+d->vertical_compose_l0 = (void*)legall53_vertical_lo_sse2;
+break;
 case DWT_DIRAC_LEGALL5_3:
 d->vertical_compose_h0 = (void*)legall53_vertical_hi_sse2;
 d->vertical_compose_l0 = (void*)legall53_vertical_lo_sse2;
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/6] diracdec: add 10-bit Haar SIMD functions

[James Darnley]

Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C:119fps
SSE2: 204fps
AVX:  206fps
AVX2: 221fps
---
 libavcodec/dirac_dwt.c|   7 +-
 libavcodec/dirac_dwt.h|   1 +
 libavcodec/x86/Makefile   |   6 +-
 libavcodec/x86/dirac_dwt_10bit.asm| 113 +
 libavcodec/x86/dirac_dwt_init_10bit.c | 136 ++
 5 files changed, 260 insertions(+), 3 deletions(-)
 create mode 100644 libavcodec/x86/dirac_dwt_10bit.asm
 create mode 100644 libavcodec/x86/dirac_dwt_init_10bit.c

diff --git a/libavcodec/dirac_dwt.c b/libavcodec/dirac_dwt.c
index cc08f8865a..86bee5bb9b 100644
--- a/libavcodec/dirac_dwt.c
+++ b/libavcodec/dirac_dwt.c
@@ -59,8 +59,13 @@ int ff_spatial_idwt_init(DWTContext *d, DWTPlane *p, enum 
dwt_type type,
 return AVERROR_INVALIDDATA;
 }
 
-if (ARCH_X86 && bit_depth == 8)
+#if ARCH_X86
+if (bit_depth == 8)
 ff_spatial_idwt_init_x86(d, type);
+else if (bit_depth == 10)
+ff_spatial_idwt_init_10bit_x86(d, type);
+#endif
+
 return 0;
 }
 
diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index 994dc21d70..1ad7b9a821 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -88,6 +88,7 @@ enum dwt_type {
 int ff_spatial_idwt_init(DWTContext *d, DWTPlane *p, enum dwt_type type,
  int decomposition_count, int bit_depth);
 void ff_spatial_idwt_init_x86(DWTContext *d, enum dwt_type type);
+void ff_spatial_idwt_init_10bit_x86(DWTContext *d, enum dwt_type type);
 
 void ff_spatial_idwt_slice2(DWTContext *d, int y);
 
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 2350c8bbee..590d83c167 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -7,7 +7,8 @@ OBJS-$(CONFIG_BLOCKDSP)+= x86/blockdsp_init.o
 OBJS-$(CONFIG_BSWAPDSP)+= x86/bswapdsp_init.o
 OBJS-$(CONFIG_DCT) += x86/dct_init.o
 OBJS-$(CONFIG_DIRAC_DECODER)   += x86/diracdsp_init.o   \
-  x86/dirac_dwt_init.o
+  x86/dirac_dwt_init.o \
+  x86/dirac_dwt_init_10bit.o
 OBJS-$(CONFIG_FDCTDSP) += x86/fdctdsp_init.o
 OBJS-$(CONFIG_FFT) += x86/fft_init.o
 OBJS-$(CONFIG_FLACDSP) += x86/flacdsp_init.o
@@ -153,7 +154,8 @@ X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
 X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
 X86ASM-OBJS-$(CONFIG_DCA_DECODER)  += x86/dcadsp.o x86/synth_filter.o
 X86ASM-OBJS-$(CONFIG_DIRAC_DECODER)+= x86/diracdsp.o\
-  x86/dirac_dwt.o
+  x86/dirac_dwt.o \
+  x86/dirac_dwt_10bit.o
 X86ASM-OBJS-$(CONFIG_DNXHD_ENCODER)+= x86/dnxhdenc.o
 X86ASM-OBJS-$(CONFIG_EXR_DECODER)  += x86/exrdsp.o
 X86ASM-OBJS-$(CONFIG_FLAC_DECODER) += x86/flacdsp.o
diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
new file mode 100644
index 00..dc3830615e
--- /dev/null
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -0,0 +1,113 @@
+;**
+;* x86 optimized discrete 10-bit wavelet trasnform
+;* Copyright (c) 2018 James Darnley
+;*
+;* This file is part of FFmpeg.
+;*
+;* FFmpeg is free software; you can redistribute it and/or
+;* modify it under the terms of the GNU Lesser General Public
+;* License as published by the Free Software Foundation; either
+;* version 2.1 of the License, or (at your option) any later version.
+;*
+;* FFmpeg is distributed in the hope that it will be useful,
+;* but WITHOUT ANY WARRANTY; without even the implied warranty of
+;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;* Lesser General Public License for more details.
+;*
+;* You should have received a copy of the GNU Lesser General Public
+;* License along with FFmpeg; if not, write to the Free Software
+;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION_RODATA
+
+cextern pd_1
+
+SECTION .text
+
+%macro HAAR_VERTICAL 0
+
+cglobal vertical_compose_haar_10bit, 3, 3, 4, b0, b1, w
+mova m2, [pd_1]
+shl wd, 2
+add b0q, wq
+add b1q, wq
+neg wq
+
+ALIGN 16
+.loop:
+mova m0, [b0q + wq]
+mova m1, [b1q + wq]
+paddd m3, m1, m2
+psrad m3, 1
+psubd m0, m3
+paddd m1, m0
+mova [b0q + wq], m0
+mova [b1q + wq], m1
+add wq, mmsize
+jl .loop
+RET
+
+%endmacro
+
+%macro HAAR_HORIZONTAL 0
+
+cglobal horizontal_compose_haar_10bit, 3, 6, 4, b, temp_, w, x, b2
+mova m2, 

[FFmpeg-devel] [PATCH 4/6] diracdec: avx2 legall

[James Darnley]

---
 libavcodec/x86/dirac_dwt_10bit.asm|  4 +++-
 libavcodec/x86/dirac_dwt_init_10bit.c | 22 ++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
index 681de5e1df..ae110d2945 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -24,7 +24,7 @@
 SECTION_RODATA
 
 cextern pd_1
-pd_2: times 4 dd 2
+pd_2: times 8 dd 2
 pd_8: times 4 dd 8
 
 SECTION .text
@@ -204,3 +204,5 @@ HAAR_VERTICAL
 INIT_YMM avx2
 HAAR_HORIZONTAL
 HAAR_VERTICAL
+LEGALL53_VERTICAL_HI
+LEGALL53_VERTICAL_LO
diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c 
b/libavcodec/x86/dirac_dwt_init_10bit.c
index e7e7534050..51d6eeae93 100644
--- a/libavcodec/x86/dirac_dwt_init_10bit.c
+++ b/libavcodec/x86/dirac_dwt_init_10bit.c
@@ -27,6 +27,8 @@ void ff_dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, 
int32_t *b2, int32_t *b3
 
 void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
 void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
+void ff_legall53_vertical_hi_avx2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
+void ff_legall53_vertical_lo_avx2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
 
 void ff_horizontal_compose_haar_10bit_sse2(int32_t *b0, int32_t *b1, int 
width_align);
 void ff_horizontal_compose_haar_10bit_avx(int32_t *b0, int32_t *b1, int 
width_align);
@@ -112,6 +114,22 @@ static void legall53_vertical_hi_sse2(int32_t *b0, int32_t 
*b1, int32_t *b2, int
 b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
 }
 
+static void legall53_vertical_lo_avx2(int32_t *b0, int32_t *b1, int32_t *b2, 
int width)
+{
+int i = width & ~7;
+ff_legall53_vertical_lo_avx2(b0, b1, b2, i);
+for(; ivertical_compose_h0 = (void*)legall53_vertical_hi_avx2;
+d->vertical_compose_l0 = (void*)legall53_vertical_lo_avx2;
+break;
 case DWT_DIRAC_HAAR0:
 d->vertical_compose = (void*)vertical_compose_haar_avx2;
 break;
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

[Aman Gupta]

On Fri, Jul 6, 2018 at 10:55 PM Thomas Guillem  wrote:

>
>
> On Thu, Jul 5, 2018, at 20:49, Aman Gupta wrote:
> > On Wed, Jul 4, 2018 at 3:05 AM Thomas Guillem  wrote:
> >
> > > On macOS, a zero rc_max_rate cause an error from
> > > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> > >
> > > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > > arguments from the vtenc_output_callback after few frames and then a
> crash
> > > within the VideoToolbox library.
> > > ---
> > >  libavcodec/videotoolboxenc.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/videotoolboxenc.c
> b/libavcodec/videotoolboxenc.c
> > > index ac847358ab..aa9aae7e05 100644
> > > --- a/libavcodec/videotoolboxenc.c
> > > +++ b/libavcodec/videotoolboxenc.c
> > > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> > >  *avctx,
> > >
> > >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> > >  // kVTCompressionPropertyKey_DataRateLimits is not available
> for
> > > HEVC
> > > +if (max_rate > 0) {
> >
> >
> > I think it would be better to add this condition to the existing if block
> > above so we can avoid another level of indentation.
>
> That's what I first wanted to do but there is a also a profile level in
> this code block.
>

I split the profile block into another conditional, and added max_rate to
this one. Applied to master and release/4.0

Aman


>
> >
> > Patch looks fine to me otherwise. I can make this change and commit this
> > week.
> >
> > Aman
> >
> >
> > >  bytes_per_second_value = max_rate >> 3;
> > >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> > >kCFNumberSInt64Type,
> > > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> > >  *avctx,
> > >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > > property: %d\n", status);
> > >  return AVERROR_EXTERNAL;
> > >  }
> > > +}
> > >
> > >  if (profile_level) {
> > >  status = VTSessionSetProperty(vtctx->session,
> > > --
> > > 2.18.0
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mediacodec_sw_buffer: Fix segmentation fault with decoding on android oreo (corrected)

[Peter Bennett]

This is a correction of the earlier submission of this patch.

avcodec_receive_frame consistently causes a seg fault when decoding 1080i mpeg2
on android version oreo. When copying the frame, the second plane in the buffer
follows on immediately after 1080 lines of the first plane, but the code assumes
it is after 1088 lines of the first plane, based on slice_height. It crashes on
copying data for the second plane when it hits the actual end of the data and
starts accessing addresses beyond that.

Instead of using slice_height here, change to use use height. slice_height is
used at other places in this module and I do not know if they also need to be
changed. I have confirmed that with this change, decoding works correctly
on android oreo as well as on the prior version, android nougat.
---
 libavcodec/mediacodec_sw_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodec_sw_buffer.c 
b/libavcodec/mediacodec_sw_buffer.c
index 92428e85f0..30a53f05b3 100644
--- a/libavcodec/mediacodec_sw_buffer.c
+++ b/libavcodec/mediacodec_sw_buffer.c
@@ -150,7 +150,7 @@ void 
ff_mediacodec_sw_buffer_copy_yuv420_semi_planar(AVCodecContext *avctx,
 } else if (i == 1) {
 height = avctx->height / 2;
 
-src += s->slice_height * s->stride;
+src += s->height * s->stride;
 src += s->crop_top * s->stride;
 src += s->crop_left;
 }
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Aman Gupta]

On Wed, Jul 18, 2018 at 6:38 PM James Almer  wrote:

> On 7/18/2018 3:57 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
>
> avcodec/decode: parse options from AVCodec.bsfs
>
> > Fixes a bug that would prevent using multiple comma-separated filters,
> > and allows options to be passed to each filter.
> >
> > Based on similar loop in ffmpeg_opt.c's new_output_stream().
> >
> > Signed-off-by: Aman Gupta 
> > ---
> >  libavcodec/decode.c | 47 ---
> >  1 file changed, 40 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 6a3a4df179..67b7443b9d 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -36,6 +36,7 @@
> >  #include "libavutil/imgutils.h"
> >  #include "libavutil/internal.h"
> >  #include "libavutil/intmath.h"
> > +#include "libavutil/opt.h"
> >
> >  #include "avcodec.h"
> >  #include "bytestream.h"
> > @@ -195,27 +196,33 @@ static int bsfs_init(AVCodecContext *avctx)
> >  while (bsfs_str && *bsfs_str) {
> >  AVBSFContext **tmp;
> >  const AVBitStreamFilter *filter;
> > -char *bsf;
> > +char *bsf, *bsf_options_str, *bsf_name;
> >
> >  bsf = av_get_token(_str, ",");
> >  if (!bsf) {
> >  ret = AVERROR(ENOMEM);
> >  goto fail;
> >  }
> > +bsf_name = av_strtok(bsf, "=", _options_str);
> > +if (!bsf_name) {
> > +av_freep();
> > +ret = AVERROR(ENOMEM);
> > +goto fail;
> > +}
> >
> > -filter = av_bsf_get_by_name(bsf);
> > +filter = av_bsf_get_by_name(bsf_name);
> >  if (!filter) {
> >  av_log(avctx, AV_LOG_ERROR, "A non-existing bitstream
> filter %s "
> > "requested by a decoder. This is a bug, please
> report it.\n",
> > -   bsf);
> > -ret = AVERROR_BUG;
> > +   bsf_name);
> >  av_freep();
> > +ret = AVERROR_BUG;
> >  goto fail;
> >  }
> > -av_freep();
> >
> >  tmp = av_realloc_array(s->bsfs, s->nb_bsfs + 1,
> sizeof(*s->bsfs));
> >  if (!tmp) {
> > +av_freep();
> >  ret = AVERROR(ENOMEM);
> >  goto fail;
> >  }
> > @@ -223,8 +230,10 @@ static int bsfs_init(AVCodecContext *avctx)
> >  s->nb_bsfs++;
> >
> >  ret = av_bsf_alloc(filter, >bsfs[s->nb_bsfs - 1]);
> > -if (ret < 0)
> > +if (ret < 0) {
> > +av_freep();
> >  goto fail;
> > +}
> >
> >  if (s->nb_bsfs == 1) {
> >  /* We do not currently have an API for passing the input
> timebase into decoders,
> > @@ -238,12 +247,36 @@ static int bsfs_init(AVCodecContext *avctx)
> >  ret = avcodec_parameters_copy(s->bsfs[s->nb_bsfs -
> 1]->par_in,
> >s->bsfs[s->nb_bsfs -
> 2]->par_out);
> >  }
> > -if (ret < 0)
> > +if (ret < 0) {
> > +av_freep();
> >  goto fail;
> > +}
> > +
> > +if (bsf_options_str && filter->priv_class) {
> > +const AVOption *opt = av_opt_next(s->bsfs[s->nb_bsfs -
> 1]->priv_data, NULL);
> > +const char * shorthand[2] = {NULL};
> > +
> > +if (opt)
> > +shorthand[0] = opt->name;
> > +
> > +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs -
> 1]->priv_data, bsf_options_str, shorthand, "=", ":");
> > +if (ret < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Invalid options for
> bitstream filter %s "
> > +   "requested by the decoder. This is a bug, please
> report it.\n",
> > +   bsf_name);
> > +av_freep();
> > +ret = AVERROR_BUG;
> > +goto fail;
> > +}
>
> As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
> not a bug in the string contents, so do something like
>
> if (ret < 0) {
>   if (ret != AVERROR(ENOMEM)) {
> av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s "
>"requested by the decoder. This is a bug, please report it.\n",
>bsf_name);
> ret = AVERROR_BUG;
>   }
>   av_freep();
>   goto fail;
> }
>

Thanks, fixed and applied.


>
> > +}
> > +av_freep();
> >
> >  ret = av_bsf_init(s->bsfs[s->nb_bsfs - 1]);
> >  if (ret < 0)
> >  goto fail;
> > +
> > +if (*bsfs_str)
> > +bsfs_str++;
> >  }
> >
> >  return 0;
> >
>
> Should be ok otherwise.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] aes-ni detection is wrong

[Alexander Schmid]

0001-fix-aesni-detection.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffv1dec: Ensure that pixel format constraints are respected

[Vittorio Giovara]

On Wed, Jul 18, 2018 at 10:37 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> On Wed, Jul 18, 2018 at 11:03:47AM -0400, Derek Buitenhuis wrote:
> > On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara
> >  wrote:
> > >> this does not follow from what you write below. But more so this is
> not
> > >> how pixel formats were implemented in FFmpeg.
> > >> Where does this idea come from ?
> > >
> > > I found the following description of this pixel format pretty accurate:
> > > https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv410.html
> > >
> > > I am not sure how non-mod4 sizes work, but probably codecs within
> ffmpeg
> > > take into account more alignment than necessary and make things work
> >
> > To expand on this (and other replies): The behavior in FFmpeg is very
> unexpected
> > for an API user who may wish to actually use the returned yuv410p data
> with an
> > application or other library that is *not* from FFmpeg, such as a
> renderer, or
> > external encoder lib, resizer, etc. Everything else on the planet
> > assumes that if
> > you have a buffer of a specific chroma subsampling type, you actually
> > have enough
> > data for it to be valid, with width/height that make it so. It's very
> > surprising when
> > you get back a set of buffers/width/height that don't make sense for a
> > given pixel
> > format, and is little to no documentation about why/how.
>
> I think i see what you mean.
> But iam not sure i understand how the proposed changes would be the ideal
> solution.
>

The change would guarantee that the received buffer respects the pixel
format constraints, and informs the users that there are some lines and
columns that ought to be cropped away in order to display the desired (or
valid) output.


> For example:
> lets assume we have a 3x3 image of 420 or 410 (be that from a jpeg or
> whatever)
>
> If we want to use this with software that that does support odd resolutions
> then it should just work. Theres no 4th column or row in the logic image
> that
> could be used.
>
> OTOH if we want to use this with softwate that does not support odd
> resolutions
> then its not going to work with a 3x3 (as odd) or 2x2 (looses a column and
> row)
> or a 4x4 (which has a column and a row that is uninitialized or black)
>

The problem with this reasoning is that things "happen" to work only
because ffmpeg decoders always over-allocate the output buffers and make
sure that there is addressable data. So as long as you stay "within" the
ffmpeg APIs, everything is perfect, however when you use such data in third
party libraries you risk running in these issues.


> what i mean is that the API by which one exports the width and height
> doesnt
> really affect this. To get from a 3x3 to something that actually works with
> external code which only supports even resolutions, something somewhere has
> to make it even and either scale, crop or fill in.
>

Well, IMO the API is low level enough that it would make sense to always
return the coded sizes and let the user crop to the desired resolution.
Yes several filters/encoders and user apps would need some tweaks, but
since this is the n-th case in which cropping produces broken results maybe
it's worth it.


> More specifically, saying that this 3x3 is a 4x4 image with crop is not
> really
> true as theres not neccesarily any data in the last column and row. And a
> filter or encoder using that anyway could produce bad output
>

There is always data in the last column and row, or it would have been
impossible to encode the buffer.
Whether it contains visible data or garbage is another story.

> I don't think "logic guarantees the buffer is mod4/aligned" is a
> > reasonable thing
> > to tell an API user in lieu of documentation for unexpected behavior.
>
> just posted a small patch to document this
>

I added some padding/cropping code to my program, so that's enough for now,
but i think a more thorough solution should be found.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[Rostislav Pehlivanov]

On 19 July 2018 at 15:52, James Darnley  wrote:

> I tested the speed gains by using ffmpeg to decode a 720p yuv422p10 file
> encoded
> with the relevant transform.  The summary is below.
>
> Haar
> C:119fps
> SSE2: 204fps
> AVX:  206fps
> AVX2: 221fps
>
> 5_3
> C: 94fps
> SSE2: 118fps
> AVX2: 121fps
>
> 9_7
> C: 84fps
> SSE2: 111fps
> AVX2: 115fps
>
> Is the AVX worth it in Haar?  Is the AVX2 worth it in the latter two?  I
> added
> those later which is why they are separate patches.  I will squash them
> before
> pushing if I keep them.
>
> James Darnley (6):
>   diracdec: add 10-bit Haar SIMD functions
>   diracdec: add 10-bit Legall 5,3 (5_3) SIMD functions
>   diracdec: add 10-bit Deslauriers-Dubuc 9,7 (9_7) vertical high-pass
> function
>   diracdec: avx2 legall
>   diracdec: avx2 dd97
>   diracdec: increase rodata alignment for avx2
>
>  libavcodec/dirac_dwt.c|   7 +-
>  libavcodec/dirac_dwt.h|   1 +
>  libavcodec/x86/Makefile   |   6 +-
>  libavcodec/x86/dirac_dwt_10bit.asm| 209 +
>  libavcodec/x86/dirac_dwt_init_10bit.c | 210 ++
>  5 files changed, 430 insertions(+), 3 deletions(-)
>  create mode 100644 libavcodec/x86/dirac_dwt_10bit.asm
>  create mode 100644 libavcodec/x86/dirac_dwt_init_10bit.c
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Could you provide standard overall transform results using START/STOP_TIMER
rather than overall decoding speed?
Coefficients sizes and therefore golomb unpacking speed changes with
respect to the transform so potentially there could be somewhat of a
bottleneck on decoding before the inverse transform.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 08/12] avformat/mxfenc: fix muxing when audio tracks are longer than video track

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavformat/mxfenc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

Will apply.

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

Re: [FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[James Darnley]

On 2018-07-19 17:26, Rostislav Pehlivanov wrote:
> On 19 July 2018 at 15:52, James Darnley  wrote:
> 
>> int32_t *b1, int32_t *b2, int
>>  b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
>>  }
>>
>> +static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
>> +  int32_t *b3, int32_t *b4, int width)
>> +{
>> +int i = width & ~3;
>> +ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
>> +for(; i> +b2[i] = COMPOSE_DD97iH0(b0[i], b1[i], b2[i], b3[i], b4[i]);
>> +
>> +}
>>
> 
> 
> This, along with the rest of the patchset: what's up with the hybrid
> implementations? Couldn't you put the second part in the asm code as well?
> Now there are 2 function calls instead of 1.

The 8-bit code does this and I just followed it lead.  I believe this is
done because we cannot write junk data beyond what we think is the end
of the line because this might be one of the higher depths and the
coeffs for the next level sit beyond the end of the line.

But now it has just occurred to me that maybe you meant "why didn't you
do the scalar operations in SIMD?", is that what you meant?  Answer is
because it didn't occur to me at the time.  Aside from that I always
write do-while loops in assembly because I can usually guarantee 1 run
of the block.

I can certainly look at making that change.

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

Re: [FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[Rostislav Pehlivanov]

On 19 July 2018 at 16:52, James Darnley  wrote:

> On 2018-07-19 17:26, Rostislav Pehlivanov wrote:
> > On 19 July 2018 at 15:52, James Darnley  wrote:
> >
> >> int32_t *b1, int32_t *b2, int
> >>  b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
> >>  }
> >>
> >> +static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t
> *b2,
> >> +  int32_t *b3, int32_t *b4, int width)
> >> +{
> >> +int i = width & ~3;
> >> +ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
> >> +for(; i >> +b2[i] = COMPOSE_DD97iH0(b0[i], b1[i], b2[i], b3[i], b4[i]);
> >> +
> >> +}
> >>
> >
> >
> > This, along with the rest of the patchset: what's up with the hybrid
> > implementations? Couldn't you put the second part in the asm code as
> well?
> > Now there are 2 function calls instead of 1.
>
> The 8-bit code does this and I just followed it lead.  I believe this is
> done because we cannot write junk data beyond what we think is the end
> of the line because this might be one of the higher depths and the
> coeffs for the next level sit beyond the end of the line.
>
> But now it has just occurred to me that maybe you meant "why didn't you
> do the scalar operations in SIMD?", is that what you meant?  Answer is
> because it didn't occur to me at the time.  Aside from that I always
> write do-while loops in assembly because I can usually guarantee 1 run
> of the block.
>
> I can certainly look at making that change.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yep, I think you ought to put the scalar code in the asm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[James Darnley]

I tested the speed gains by using ffmpeg to decode a 720p yuv422p10 file encoded
with the relevant transform.  The summary is below.

Haar
C:119fps
SSE2: 204fps
AVX:  206fps
AVX2: 221fps

5_3
C: 94fps
SSE2: 118fps
AVX2: 121fps

9_7
C: 84fps
SSE2: 111fps
AVX2: 115fps

Is the AVX worth it in Haar?  Is the AVX2 worth it in the latter two?  I added
those later which is why they are separate patches.  I will squash them before
pushing if I keep them.

James Darnley (6):
  diracdec: add 10-bit Haar SIMD functions
  diracdec: add 10-bit Legall 5,3 (5_3) SIMD functions
  diracdec: add 10-bit Deslauriers-Dubuc 9,7 (9_7) vertical high-pass
function
  diracdec: avx2 legall
  diracdec: avx2 dd97
  diracdec: increase rodata alignment for avx2

 libavcodec/dirac_dwt.c|   7 +-
 libavcodec/dirac_dwt.h|   1 +
 libavcodec/x86/Makefile   |   6 +-
 libavcodec/x86/dirac_dwt_10bit.asm| 209 +
 libavcodec/x86/dirac_dwt_init_10bit.c | 210 ++
 5 files changed, 430 insertions(+), 3 deletions(-)
 create mode 100644 libavcodec/x86/dirac_dwt_10bit.asm
 create mode 100644 libavcodec/x86/dirac_dwt_init_10bit.c

-- 
2.17.1

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

[FFmpeg-devel] [PATCH 2/6] diracdec: add 10-bit Legall 5, 3 (5_3) SIMD functions

[James Darnley]

Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 94fps
SSE2: 118fps
AVX2: 121fps
---
 libavcodec/x86/dirac_dwt_10bit.asm| 55 +++
 libavcodec/x86/dirac_dwt_init_10bit.c | 23 +++
 2 files changed, 78 insertions(+)

diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
index dc3830615e..c00de32bfe 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -24,6 +24,7 @@
 SECTION_RODATA
 
 cextern pd_1
+pd_2: times 4 dd 2
 
 SECTION .text
 
@@ -100,9 +101,63 @@ REP_RET
 
 %endmacro
 
+%macro LEGALL53_VERTICAL_LO 0
+
+cglobal legall53_vertical_lo, 4, 4, 4, b0, b1, b2, w
+mova m3, [pd_2]
+shl wd, 2
+add b0q, wq
+add b1q, wq
+add b2q, wq
+neg wq
+
+ALIGN 16
+.loop:
+mova m0, [b0q + wq]
+mova m1, [b1q + wq]
+mova m2, [b2q + wq]
+paddd m0, m2
+paddd m0, m3
+psrad m0, 2
+psubd m1, m0
+mova [b1q + wq], m1
+add wq, mmsize
+jl .loop
+RET
+
+%endmacro
+
+%macro LEGALL53_VERTICAL_HI 0
+
+cglobal legall53_vertical_hi, 4, 4, 4, b0, b1, b2, w
+mova m3, [pd_1]
+shl wd, 2
+add b0q, wq
+add b1q, wq
+add b2q, wq
+neg wq
+
+ALIGN 16
+.loop:
+mova m0, [b0q + wq]
+mova m1, [b1q + wq]
+mova m2, [b2q + wq]
+paddd m0, m2
+paddd m0, m3
+psrad m0, 1
+paddd m1, m0
+mova [b1q + wq], m1
+add wq, mmsize
+jl .loop
+RET
+
+%endmacro
+
 INIT_XMM sse2
 HAAR_HORIZONTAL
 HAAR_VERTICAL
+LEGALL53_VERTICAL_HI
+LEGALL53_VERTICAL_LO
 
 INIT_XMM avx
 HAAR_HORIZONTAL
diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c 
b/libavcodec/x86/dirac_dwt_init_10bit.c
index 939950e3ff..88cf267d14 100644
--- a/libavcodec/x86/dirac_dwt_init_10bit.c
+++ b/libavcodec/x86/dirac_dwt_init_10bit.c
@@ -23,6 +23,9 @@
 #include "libavutil/x86/cpu.h"
 #include "libavcodec/dirac_dwt.h"
 
+void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
+void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2, int 
width);
+
 void ff_horizontal_compose_haar_10bit_sse2(int32_t *b0, int32_t *b1, int 
width_align);
 void ff_horizontal_compose_haar_10bit_avx(int32_t *b0, int32_t *b1, int 
width_align);
 void ff_horizontal_compose_haar_10bit_avx2(int32_t *b0, int32_t *b1, int 
width_align);
@@ -91,6 +94,22 @@ static void horizontal_compose_haar_avx2(int32_t *b, int32_t 
*tmp, int width)
 }
 }
 
+static void legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2, 
int width)
+{
+int i = width & ~3;
+ff_legall53_vertical_lo_sse2(b0, b1, b2, i);
+for(; ivertical_compose_h0 = (void*)legall53_vertical_hi_sse2;
+d->vertical_compose_l0 = (void*)legall53_vertical_lo_sse2;
+break;
 case DWT_DIRAC_HAAR0:
 d->vertical_compose = (void*)vertical_compose_haar_sse2;
 break;
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 6/6] diracdec: increase rodata alignment for avx2

[James Darnley]

---
 libavcodec/x86/dirac_dwt_10bit.asm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/x86/dirac_dwt_10bit.asm 
b/libavcodec/x86/dirac_dwt_10bit.asm
index 2e039e11ea..d0da822a81 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
@@ -21,7 +21,7 @@
 
 %include "libavutil/x86/x86util.asm"
 
-SECTION_RODATA
+SECTION_RODATA 32
 
 cextern pd_1
 pd_2: times 8 dd 2
-- 
2.17.1

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

Re: [FFmpeg-devel] Sponsoring request

[Kieran Kunhya]

On Thu, 19 Jul 2018 at 14:04 Paul B Mahol  wrote:

> Hi,
>
> I want that FFmpeg community sponsor addition of new code I gonna
> develop in following days/months.
>
> Thanks.
>

What code?
I am happy to sponsor cleanup of libavfilter to be usable outside of
ffmpeg.c and in a realtime environment.

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

Re: [FFmpeg-devel] [PATCH 06/12] avformat/audiointerleave: pad last audio frame

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavformat/audiointerleave.c | 10 +++---
>  tests/ref/lavf/mxf|  4 ++--
>  2 files changed, 9 insertions(+), 5 deletions(-)
>

Will apply.

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

Re: [FFmpeg-devel] [PATCH 05/12] avformat/mxfenc: correctly set content package rate in system element

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavformat/mxf.c| 17 +
>  libavformat/mxf.h|  2 ++
>  libavformat/mxfenc.c |  4 +++-
>  tests/ref/lavf/mxf   |  2 +-
>  4 files changed, 23 insertions(+), 2 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[Rostislav Pehlivanov]

On 19 July 2018 at 15:52, James Darnley  wrote:

> Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
> relevant transform.
> C: 84fps
> SSE2: 111fps
> AVX2: 115fps
> ---
>  libavcodec/x86/dirac_dwt_10bit.asm| 38 +++
>  libavcodec/x86/dirac_dwt_init_10bit.c | 16 +++
>  2 files changed, 54 insertions(+)
>
> diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
> b/libavcodec/x86/dirac_dwt_10bit.asm
> index c00de32bfe..681de5e1df 100644
> --- a/libavcodec/x86/dirac_dwt_10bit.asm
> +++ b/libavcodec/x86/dirac_dwt_10bit.asm
> @@ -25,6 +25,7 @@ SECTION_RODATA
>
>  cextern pd_1
>  pd_2: times 4 dd 2
> +pd_8: times 4 dd 8
>
>  SECTION .text
>
> @@ -153,7 +154,44 @@ RET
>
>  %endmacro
>
> +%macro DD97_VERTICAL_HI 0
> +
> +cglobal dd97_vertical_hi, 6, 6, 8, b0, b1, b2, b3, b4, w
> +mova m7, [pd_8]
> +shl wd, 2
> +add b0q, wq
> +add b1q, wq
> +add b2q, wq
> +add b3q, wq
> +add b4q, wq
> +neg wq
> +
> +ALIGN 16
> +.loop:
> +mova m0, [b0q + wq]
> +mova m1, [b1q + wq]
> +mova m2, [b2q + wq]
> +mova m3, [b3q + wq]
> +mova m4, [b4q + wq]
> +pslld m5, m1, 3
> +pslld m6, m3, 3
> +paddd m5, m1
> +paddd m6, m3
> +psubd m5, m0
> +psubd m6, m4
> +paddd m5, m7
> +paddd m5, m6
> +psrad m5, 4
> +paddd m2, m5
> +mova [b2q + wq], m2
> +add wq, mmsize
> +jl .loop
> +RET
> +
> +%endmacro
> +
>  INIT_XMM sse2
> +DD97_VERTICAL_HI
>  HAAR_HORIZONTAL
>  HAAR_VERTICAL
>  LEGALL53_VERTICAL_HI
> diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c
> b/libavcodec/x86/dirac_dwt_init_10bit.c
> index 88cf267d14..e7e7534050 100644
> --- a/libavcodec/x86/dirac_dwt_init_10bit.c
> +++ b/libavcodec/x86/dirac_dwt_init_10bit.c
> @@ -23,6 +23,8 @@
>  #include "libavutil/x86/cpu.h"
>  #include "libavcodec/dirac_dwt.h"
>
> +void ff_dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int32_t *b3, int32_t *b4, int width);
> +
>  void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int width);
>  void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int width);
>
> @@ -110,6 +112,16 @@ static void legall53_vertical_hi_sse2(int32_t *b0,
> int32_t *b1, int32_t *b2, int
>  b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
>  }
>
> +static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> +  int32_t *b3, int32_t *b4, int width)
> +{
> +int i = width & ~3;
> +ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
> +for(; i +b2[i] = COMPOSE_DD97iH0(b0[i], b1[i], b2[i], b3[i], b4[i]);
> +
> +}
>


This, along with the rest of the patchset: what's up with the hybrid
implementations? Couldn't you put the second part in the asm code as well?
Now there are 2 function calls instead of 1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/12] avformat/mxfenc: add mpeg-2 specific metadata, fix compatibility with sony content browser

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavformat/mxfenc.c| 46 ++---
>  tests/ref/lavf/mxf  |  6 ++---
>  tests/ref/lavf/mxf_d10  |  2 +-
>  tests/ref/lavf/mxf_dv25 |  2 +-
>  tests/ref/lavf/mxf_dvcpro50 |  2 +-
>  tests/ref/lavf/mxf_opatom   |  2 +-
>  tests/ref/lavf/mxf_opatom_audio |  2 +-
>  7 files changed, 50 insertions(+), 12 deletions(-)
>

Will apply.

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

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

[Baptiste Coudurier]

Hi Marton,

Yes, changed.
Michael, are you OK with the utils.c changes ? To be able to remux data
tracks.

Thanks!

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

[FFmpeg-devel] [PATCH] avcodec/mediacodec_sw_buffer: Fix segmentation fault with decoding on android oreo

[Peter Bennett]

avcodec_receive_frame consistently causes a seg fault when decoding 1080i mpeg2
on android version oreo. When copying the frame, the second plane in the buffer
follows on immediately after 1080 lines of the first plane, but the code assumes
it is after 1088 lines of the first plane, based on slice_height. It crashes on
copying data for the second plane when it hits the actual end of the data and
starts accessing addresses beyond that.

Instead of using slice_height here, change to use use height. slice_height is
used at other places in this module and I do not know if they also need to be
changed. I have confirmed that with this change, decoding works correctly
on android oreo as well as on the prior version, android nougat.
---
 libavcodec/mediacodec_sw_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodec_sw_buffer.c 
b/libavcodec/mediacodec_sw_buffer.c
index 92428e85f0..3b80e1fb59 100644
--- a/libavcodec/mediacodec_sw_buffer.c
+++ b/libavcodec/mediacodec_sw_buffer.c
@@ -100,7 +100,7 @@ void 
ff_mediacodec_sw_buffer_copy_yuv420_planar(AVCodecContext *avctx,
 src += s->slice_height * s->stride;
 
 if (i == 2) {
-src += ((s->slice_height + 1) / 2) * stride;
+src += ((s->height + 1) / 2) * stride;
 }
 
 src += s->crop_top * stride;
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH 4/5] avformat/mov: add support for AV1 streams

[James Almer]

On 7/19/2018 9:57 AM, Francois Cartegnie wrote:
> Hi,
> 
> Sorry, can't reply to thread.
> 
>> +if (version != 0) {
>> +av_log(c->fc, AV_LOG_WARNING, "Unknown AV1 Codec Configuration Box 
>> version %d\n", version);
>> +return 0;
>> +}
>> +avio_skip(pb, 3); /* flags */
>> +
>> +avio_skip(pb, 1); /* reserved, initial_presentation_delay_present, 
>> initial_presentation_delay_minus_one */
>> +
>> +ret = ff_get_extradata(c->fc, st->codecpar, pb, atom.size - 5);
> 
> Seems to me that using OBU only as internal extradata, unlike h264 or
> hevc, will only cause issues.
> 
> There's no version as a guarantee on which OBU should be found, and it
> implies parsing OBU just like with AnnexB.

Unlike avcc and hvcc, the spec didn't define a custom encapsulation for
av1c, but it does state which types should be found:

"The configOBUs field is expected to contain only OBU_SEQUENCE_HEADER
and OBU_METADATA when the metadata OBU is applicable to all the
associated samples"

Matroska has the same requirements.

> Parsing might also not be possible without accessing samples data when
> there's potentially zero OBU in DCR.

Steve Lhomme opened a issue[1] about it. The spec states "zero or more
OBUs" in av1c, whereas In Matroska the Sequence Header is guaranteed to
be present as they say "one or more OBUs".

Fwiw, in ffmpeg's case at least, libavformat will generate the internal
extradata on its own by extracting the first Sequence Header from the
bitstream if the demuxer didn't allocate it itself. This is what's done
for ivf and such containers.

> 
> I've raised the issue on the spec, as the DCR itself does not seems to
> contain enough extracted information, like profile for routing to a
> proper decoder.

Like you said, you're clearly expected to parse the Sequence Header OBU
in configOBUs. Profile is the very first value in it after the OBU header.

[1] https://github.com/AOMediaCodec/av1-isobmff/issues/46
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[James Darnley]

On 2018-07-19 17:23, Rostislav Pehlivanov wrote:
> 
> Could you provide standard overall transform results using START/STOP_TIMER
> rather than overall decoding speed?
> Coefficients sizes and therefore golomb unpacking speed changes with
> respect to the transform so potentially there could be somewhat of a
> bottleneck on decoding before the inverse transform.

Ah, you are right about that.  Should I limit the depth to 1 so that the
functions operate on the same width all the time?  Anyway, I will get
the timers in there.

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

Re: [FFmpeg-devel] [PATCH] lavf/mxfdec: only call mxf_free_metadataset when ctx_size is != 0, otherwise ctx == mxf

[Baptiste Coudurier]

On Fri, Jul 6, 2018 at 5:42 PM, Michael Niedermayer 
wrote:

> On Fri, Jul 06, 2018 at 12:08:07PM -0700, Baptiste Coudurier wrote:
> > ---
> >  libavformat/mxfdec.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
>
> should be ok
>
> thanks
>

Applied.

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

Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfenc: update body partition with footer offset

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavformat/mxfenc.c| 9 +++--
>  tests/ref/lavf/mxf  | 6 +++---
>  tests/ref/lavf/mxf_d10  | 2 +-
>  tests/ref/lavf/mxf_dv25 | 2 +-
>  tests/ref/lavf/mxf_dvcpro50 | 2 +-
>  tests/ref/lavf/mxf_opatom   | 2 +-
>  tests/ref/lavf/mxf_opatom_audio | 2 +-
>  7 files changed, 15 insertions(+), 10 deletions(-)


Will apply.

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

Re: [FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[Rostislav Pehlivanov]

On 19 July 2018 at 16:29, James Darnley  wrote:

> On 2018-07-19 17:23, Rostislav Pehlivanov wrote:
> >
> > Could you provide standard overall transform results using
> START/STOP_TIMER
> > rather than overall decoding speed?
> > Coefficients sizes and therefore golomb unpacking speed changes with
> > respect to the transform so potentially there could be somewhat of a
> > bottleneck on decoding before the inverse transform.
>
> Ah, you are right about that.  Should I limit the depth to 1 so that the
> functions operate on the same width all the time?  Anyway, I will get
> the timers in there.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yep, use depth 1 for all transforms and use the biggest slices possible.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Carl Eugen Hoyos]

2018-07-19 3:37 GMT+02:00, James Almer :
> On 7/18/2018 3:57 PM, Aman Gupta wrote:

>> +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs -
>> 1]->priv_data, bsf_options_str, shorthand, "=", ":");
>> +if (ret < 0) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid options for
>> bitstream filter %s "
>> +   "requested by the decoder. This is a bug, please
>> report it.\n",
>> +   bsf_name);
>> +av_freep();
>> +ret = AVERROR_BUG;
>> +goto fail;
>> +}
>
> As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
> not a bug in the string contents, so do something like
>
> if (ret < 0) {
>   if (ret != AVERROR(ENOMEM)) {
> av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s "
>"requested by the decoder. This is a bug, please report it.\n",
>bsf_name);
> ret = AVERROR_BUG;

av_assert(ret == AVERROR(ENOMEM)); ?

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

Re: [FFmpeg-devel] [PATCH]lavfi/af_aiir, af_afir: Remove a variable that is always -1

[Paul B Mahol]

On 7/19/18, Carl Eugen Hoyos  wrote:
> Hi!
>
> Two very similar conditions in af_aiir.c and af_afir.c can never be true
> afaict.
>
> Please review, Carl Eugen
>

Should be ok if properly tested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] aes-ni detection is wrong

[Carl Eugen Hoyos]

2018-07-19 19:17 GMT+02:00, Alexander Schmid :

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Carl Eugen Hoyos]

2018-07-19 21:00 GMT+02:00, Aman Gupta :
> On Thu, Jul 19, 2018 at 11:44 AM Carl Eugen Hoyos 
> wrote:
>
>> 2018-07-19 3:37 GMT+02:00, James Almer :
>> > On 7/18/2018 3:57 PM, Aman Gupta wrote:
>>
>> >> +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs -
>> >> 1]->priv_data, bsf_options_str, shorthand, "=", ":");
>> >> +if (ret < 0) {
>> >> +av_log(avctx, AV_LOG_ERROR, "Invalid options for
>> >> bitstream filter %s "
>> >> +   "requested by the decoder. This is a bug,
>> >> please
>> >> report it.\n",
>> >> +   bsf_name);
>> >> +av_freep();
>> >> +ret = AVERROR_BUG;
>> >> +goto fail;
>> >> +}
>> >
>> > As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
>> > not a bug in the string contents, so do something like
>> >
>> > if (ret < 0) {
>> >   if (ret != AVERROR(ENOMEM)) {
>> > av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s
>> "
>> >"requested by the decoder. This is a bug, please report
>> it.\n",
>> >bsf_name);
>> > ret = AVERROR_BUG;
>>
>> av_assert(ret == AVERROR(ENOMEM)); ?
>>
>
> I think it's preferable to show the custom error message, since it will
> include the name of the filter and also the name of the codec (via avctx),
> and suggest to the user that they report the bug with both of those details.

Apart from the fact that I fear the message will not trigger the
necessary report (as opposed to the assert): Iirc, you can
convince av_assert to print all this information, no?

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

Re: [FFmpeg-devel] [PATCH] libavcodec/escape130: fixes and improvements

[Carl Eugen Hoyos]

2018-07-19 8:39 GMT+02:00, Michael Chaban :

> Recently I completely decompiled original Eidos Escape codecs,
> and I wanted to fix and improve Escape130 code of ffmpeg.
> Here are three sequential commits and very short (few frames)
> RPL-video file sample.

The first commit breaks fate, you have to (confirm the fix and)
change the reference values in the same patch.

Is there an alternative to the second patch? Like setting the
range correctly?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Aman Gupta]

On Thu, Jul 19, 2018 at 11:44 AM Carl Eugen Hoyos 
wrote:

> 2018-07-19 3:37 GMT+02:00, James Almer :
> > On 7/18/2018 3:57 PM, Aman Gupta wrote:
>
> >> +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs -
> >> 1]->priv_data, bsf_options_str, shorthand, "=", ":");
> >> +if (ret < 0) {
> >> +av_log(avctx, AV_LOG_ERROR, "Invalid options for
> >> bitstream filter %s "
> >> +   "requested by the decoder. This is a bug, please
> >> report it.\n",
> >> +   bsf_name);
> >> +av_freep();
> >> +ret = AVERROR_BUG;
> >> +goto fail;
> >> +}
> >
> > As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
> > not a bug in the string contents, so do something like
> >
> > if (ret < 0) {
> >   if (ret != AVERROR(ENOMEM)) {
> > av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s
> "
> >"requested by the decoder. This is a bug, please report
> it.\n",
> >bsf_name);
> > ret = AVERROR_BUG;
>
> av_assert(ret == AVERROR(ENOMEM)); ?
>

I think it's preferable to show the custom error message, since it will
include the name of the filter and also the name of the codec (via avctx),
and suggest to the user that they report the bug with both of those details.

Aman


>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[James Almer]

On 7/19/2018 3:44 PM, Carl Eugen Hoyos wrote:
> 2018-07-19 3:37 GMT+02:00, James Almer :
>> On 7/18/2018 3:57 PM, Aman Gupta wrote:
> 
>>> +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs -
>>> 1]->priv_data, bsf_options_str, shorthand, "=", ":");
>>> +if (ret < 0) {
>>> +av_log(avctx, AV_LOG_ERROR, "Invalid options for
>>> bitstream filter %s "
>>> +   "requested by the decoder. This is a bug, please
>>> report it.\n",
>>> +   bsf_name);
>>> +av_freep();
>>> +ret = AVERROR_BUG;
>>> +goto fail;
>>> +}
>>
>> As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
>> not a bug in the string contents, so do something like
>>
>> if (ret < 0) {
>>   if (ret != AVERROR(ENOMEM)) {
>> av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s "
>>"requested by the decoder. This is a bug, please report it.\n",
>>bsf_name);
>> ret = AVERROR_BUG;
> 
> av_assert(ret == AVERROR(ENOMEM)); ?
> 
> Carl Eugen

This is more in line with the similar error above. Aborting gracefully
by printing a message and returning an error value instead of a hard
abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was expected.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Nicolas George]

James Almer (2018-07-19):
> This is more in line with the similar error above. Aborting gracefully
> by printing a message and returning an error value instead of a hard
> abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was expected.

Explaining to whom? If it is a consistency bug within lavc, notifying
the user is worthless, the correct thing to do is to prevent the
inconsistency from getting committed, hence assert and FATE test.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Make the user help mailing lists subscription only

[Lou Logan]

On Wed, Jul 18, 2018, at 3:32 AM, Gyan Doshi wrote:
>
> What's the volume of messages from non-subscribers relative to subscribers?

I'm not sure. I never did keep a running tally. I may be able to figure it out 
via the logs if I were motivated enough.

However, I can provide some limited info between 28 June - 17 July. I believe 
these were the messages I approved:

[FFmpeg-user] How to have ffmpeg use parallel processing when searching through 
a single video
Reply by Carl. No response by OP.
[FFmpeg-user] Multi-Channel Audio Limitations?
Reply by Carl. No response by OP.
[FFmpeg-user] Decoding frames as fast as possible
Reply by Carl. No response by OP.
[FFmpeg-user] need help on making ffmpeg x64 for UWP
Reply by Carl. No response by OP.
[FFmpeg-user] ffmpeg automation
Reply by Cley. No response by OP.
[FFmpeg-user] Attempting to hardcode subtitles - no subtitles are present
Reply by Carl. No response by OP.
[FFmpeg-user] Question regarding FFmpeg copyright
Multiple replies. No response by OP.
[FFmpeg-user] Need old version ffmpeg win32 shared of Windows 32-bit Builds
Reply by Moritz. No response by OP.
[FFmpeg-user] Output file #0 does not contain any stream
Reply by Moritz. No response by OP.
[FFmpeg-user] Running out of RAM when copying 1080p H264 stream
Send-subscribe-resend duplicate.
[FFmpeg-user] FFMPEG- Buffers
[FFmpeg-user] how to use Intel qsv codec for ffmpeg 4.0 
Re: [FFmpeg-user] FFserver doesn't work with HLS
Non-verbatim duplicate.
[FFmpeg-user] [Add sei_user_data while encoding a h264 stream]
Re: [FFmpeg-user] Send audio to Axis encoder and change http_post header
An "I'm having the same issue" reply to an old message.
[FFmpeg-user] Input from FIFO for Multiple Video Track
[FFmpeg-user] using ffmpeg launcher

Out of 17 approved messages 9 got a reply or replies. Out of those 9 there were 
0 followup replies by the original posters. Not encouraging.

If these users received all messages they would be more likely to see replies 
to their messages.

> One issue I see with subscriptions is that the typical 'customer' of 
> *-users is someone only interested in solving their problem. Receiving a 
> bunch of unrelated messages every day, when one has only a narrow and 
> temporary concern with ffmpeg, is annoying.

Yes, it may be annoying, but it can easily be managed by simple client-side 
email filtering which should be an accessible and perhaps even familiar option 
for most users these days (filtering is recommended by the Mailing List FAQ), 
and they can easily unsubscribe/suspend delivery at will.

More annoying, in my opinion, is spending time answering a message that will 
likely never be read. There always are more questions than answers. We are just 
volunteers and only have limited time to answer an unending stream of questions 
across various resources (mailing lists, IRC, various third party forums, Stack 
Exchange, etc), as I'm sure you are familiar with.

> When the list receives a message from a first-time non-subscriber user, 
> can Mailman either auto-subscribe them or send out an email with a link 
> to a pre-filled subscription page ? Just thinking of ways to reduce 
> friction or annoyance for someone who's just discovered the ML and wants 
> to post a query.

I appreciate the suggestions, but the problem is spam. There is lots of it 
every day. If an address is auto-subscribed we would be inundated. As for the 
link, users do get a reply telling them their message is in the queue and 
requires approval. Don't know about a pre-filled subscription page.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[James Almer]

On 7/19/2018 4:31 PM, Nicolas George wrote:
> James Almer (2018-07-19):
>> This is more in line with the similar error above. Aborting gracefully
>> by printing a message and returning an error value instead of a hard
>> abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was expected.
> 
> Explaining to whom? If it is a consistency bug within lavc, notifying
> the user is worthless, the correct thing to do is to prevent the
> inconsistency from getting committed, hence assert and FATE test.
> 
> Regards,

AVOptions available in bitstream filters, or even the range of accepted
values, may depend on configure time options (external or internal
dependencies). A simple ./configure could enable all that's needed for
the option to be available as required by the decoder auto inserting the
bsf, but ./configure --disable-everything --enable-decoder=foo may not.
It may not enable the bsf (checked earlier in this same function and
also reported as a bug), or it may not enable an optional dependency
required to have the AVOption the decoder in question wants to use
available (checked by this new code).
See commit 5a366f9770. A fate test will not suffice to detect this kind
of issue.

I don't mind if we change it into a hard av_assert0(), but it will not
prevent inconsistencies from being committed any more than what was
committed. It will only give a less helpful error message to the user.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Make the user help mailing lists subscription only

[Thilo Borgmann]

Hi,

> Am 19.07.2018 um 21:41 schrieb Lou Logan :
> 
>> On Wed, Jul 18, 2018, at 3:32 AM, Gyan Doshi wrote:
>> 
>> What's the volume of messages from non-subscribers relative to subscribers?
> 
> I'm not sure. I never did keep a running tally. I may be able to figure it 
> out via the logs if I were motivated enough.
> 
> However, I can provide some limited info between 28 June - 17 July. I believe 
> these were the messages I approved:
> 
> [FFmpeg-user] How to have ffmpeg use parallel processing when searching 
> through a single video
>Reply by Carl. No response by OP.
> [FFmpeg-user] Multi-Channel Audio Limitations?
>Reply by Carl. No response by OP.
> [FFmpeg-user] Decoding frames as fast as possible
>Reply by Carl. No response by OP.
> [FFmpeg-user] need help on making ffmpeg x64 for UWP
>Reply by Carl. No response by OP.
> [FFmpeg-user] ffmpeg automation
>Reply by Cley. No response by OP.
> [FFmpeg-user] Attempting to hardcode subtitles - no subtitles are present
>Reply by Carl. No response by OP.
> [FFmpeg-user] Question regarding FFmpeg copyright
>Multiple replies. No response by OP.
> [FFmpeg-user] Need old version ffmpeg win32 shared of Windows 32-bit Builds
>Reply by Moritz. No response by OP.
> [FFmpeg-user] Output file #0 does not contain any stream
>Reply by Moritz. No response by OP.
> [FFmpeg-user] Running out of RAM when copying 1080p H264 stream
>Send-subscribe-resend duplicate.
> [FFmpeg-user] FFMPEG- Buffers
> [FFmpeg-user] how to use Intel qsv codec for ffmpeg 4.0 
> Re: [FFmpeg-user] FFserver doesn't work with HLS
>Non-verbatim duplicate.
> [FFmpeg-user] [Add sei_user_data while encoding a h264 stream]
> Re: [FFmpeg-user] Send audio to Axis encoder and change http_post header
>An "I'm having the same issue" reply to an old message.
> [FFmpeg-user] Input from FIFO for Multiple Video Track
> [FFmpeg-user] using ffmpeg launcher
> 
> Out of 17 approved messages 9 got a reply or replies. Out of those 9 there 
> were 0 followup replies by the original posters. Not encouraging.
> 
> If these users received all messages they would be more likely to see replies 
> to their messages.
> 
>> One issue I see with subscriptions is that the typical 'customer' of 
>> *-users is someone only interested in solving their problem. Receiving a 
>> bunch of unrelated messages every day, when one has only a narrow and 
>> temporary concern with ffmpeg, is annoying.
> 
> Yes, it may be annoying, but it can easily be managed by simple client-side 
> email filtering which should be an accessible and perhaps even familiar 
> option for most users these days (filtering is recommended by the Mailing 
> List FAQ), and they can easily unsubscribe/suspend delivery at will.
> 
> More annoying, in my opinion, is spending time answering a message that will 
> likely never be read. There always are more questions than answers. We are 
> just volunteers and only have limited time to answer an unending stream of 
> questions across various resources (mailing lists, IRC, various third party 
> forums, Stack Exchange, etc), as I'm sure you are familiar with.
> 
>> When the list receives a message from a first-time non-subscriber user, 
>> can Mailman either auto-subscribe them or send out an email with a link 
>> to a pre-filled subscription page ? Just thinking of ways to reduce 
>> friction or annoyance for someone who's just discovered the ML and wants 
>> to post a query.
> 
> I appreciate the suggestions, but the problem is spam. There is lots of it 
> every day. If an address is auto-subscribed we would be inundated. As for the 
> link, users do get a reply telling them their message is in the queue and 
> requires approval. Don't know about a pre-filled subscription page.

As long as we can‘t configure it to send thread-only replies to unsubscribed 
users there is hardly an option at hand IMHO.

Having users to subscribe to mailing lists is a burden but I think the 
impression the non-subscribers get (no replies even if there are some) is even 
worse - feeling ignored...

So basically I support to make the lists subscribe only. 

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

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[James Almer]

On 7/19/2018 6:16 PM, Carl Eugen Hoyos wrote:
> 2018-07-19 21:47 GMT+02:00, James Almer :
>> On 7/19/2018 4:31 PM, Nicolas George wrote:
>>> James Almer (2018-07-19):
 This is more in line with the similar error above. Aborting gracefully
 by printing a message and returning an error value instead of a hard
 abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was
 expected.
>>>
>>> Explaining to whom? If it is a consistency bug within lavc, notifying
>>> the user is worthless, the correct thing to do is to prevent the
>>> inconsistency from getting committed, hence assert and FATE test.
>>>
>>> Regards,
>>
>> AVOptions available in bitstream filters, or even the range of accepted
>> values, may depend on configure time options (external or internal
>> dependencies). A simple ./configure could enable all that's needed for
>> the option to be available as required by the decoder auto inserting the
>> bsf, but ./configure --disable-everything --enable-decoder=foo may not.
> 
> Then I believe BUG is not the correct error value as users are allowed
> not to enable all features.
> 
> Carl Eugen

We're talking about dependencies pulled in by components. mlp_decoder
needs mlp_parser, so if the former is enabled then the latter will be
automatically enabled as well as per the configure rules. The user can't
forcefully disable the latter in that case as the decoder depends on it,
either to build or to run.
vp9_decoder needs vp9_superframe_split_bsf, and the same thing happens.
If you could disable the latter, the decoder would not work. The
earlier, older AVERROR_BUG in the function would be triggered in that
case, because it means there's a missing dependency in configure.

With AVOptions the same logic applies. If some bsf option needs a
certain module so a value may become available, and a decoder
autoinserts that bsf setting that value for the option in question, then
that module becomes a dependency for the decoder that needs to be set in
configure.

When normally a missing dependency results in build time failures
because some object wasn't compiled, in here it results in run time
failures because a call to function failed in a way it was not supposed to.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reimbursement request

[Michael Niedermayer]

On Sun, Jul 01, 2018 at 11:27:05PM +0200, Thomas Volkert wrote:
> 
> On 23.03.2018 22:12, Thilo Borgmann wrote:
> > Am 18.03.18 um 20:57 schrieb Thilo Borgmann:
> >> Hi,
> >>
> >>> As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in
> >>> addition, Thilo and I went to Brussels for FOSDEM where we attended
> >>> the talks in the multimedia room kindly (co-) organized by Kieran and
> >>> answered some questions. I would like to request reimbursement for the
> >>> travel costs, that's flights-only, Thilo payed the gasoline and the
> >>> hotel.
> >> from my side there are hotel & gas for Chemnitz, and flight & hotel for 
> >> Brussels that I'd like to ask to reimburse for. For Chemnitz it is the 
> >> usual drive by car Carl Eugen and me do from Berlin, which are around 290 
> >> km one way as well as a shared hotel room (they did not manage to put all 
> >> of us into one suite this time, so we had to stick to two rooms for all 
> >> four of us):
> >>
> >>> Chemnitz: 125,85
> >> Hotel: 194.00 EUR
> >> Gas:   36.62 + 21.67 + 39.51 =  97.80 EUR
> >> -
> >> Total: 291,80 EUR
> >>
> >>
> >>> Brussels: 192,41
> >> Flight:111.81 EUR
> >> Hotel: 186.69 EUR
> >> -
> >> Total: 298,50 EUR
> >>
> >>
> >> BTW, on both events some of our T-Shirts have found their way to some 
> >> users, forgot to mention this in the CLT report. Also, we ran out of stock 
> >> of our stickers during CLT, so I will order new ones asap. I also forgot 
> >> to mention that we have met the organizers of a similar event in Prague in 
> >> October (LinuxDays) [1]. I'll try to have us there with a booth, too!
> >>
> >> Also, regarding FOSDEM, I'd really like to have a booth there from next 
> >> year on. In contrast to Chemnitz (and possibly Prague), Brussels is an 
> >> expensive place in general though I could get an AirBNB near the price of 
> >> an actual hotel in Chemnitz. FOSDEM of course is the biggest event with a 
> >> bigger audience of technical knowledge in our field, so we really should 
> >> consider a booth at FOSDEM, IMHO. (However this is almost a year in the 
> >> future)
> >>
> >> If there are no objections, I'll send all the invoices to Stefano 
> >> privately (like I almost always do...;)
> >>
> 
> My expenses contained:
> - 184 € for 1080 km of traveling from the area of Stuttgart to Chemnitz
> (transporting monitor and other equipment, stopped midway again)
> - 194€ for the hotel double room during the weekend for Alexander
> Strasser and me.
> => 378 €

LGTM

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs

[Carl Eugen Hoyos]

2018-07-19 21:47 GMT+02:00, James Almer :
> On 7/19/2018 4:31 PM, Nicolas George wrote:
>> James Almer (2018-07-19):
>>> This is more in line with the similar error above. Aborting gracefully
>>> by printing a message and returning an error value instead of a hard
>>> abort() with no explanation as to why "ret == AVERROR(ENOMEM)" was
>>> expected.
>>
>> Explaining to whom? If it is a consistency bug within lavc, notifying
>> the user is worthless, the correct thing to do is to prevent the
>> inconsistency from getting committed, hence assert and FATE test.
>>
>> Regards,
>
> AVOptions available in bitstream filters, or even the range of accepted
> values, may depend on configure time options (external or internal
> dependencies). A simple ./configure could enable all that's needed for
> the option to be available as required by the decoder auto inserting the
> bsf, but ./configure --disable-everything --enable-decoder=foo may not.

Then I believe BUG is not the correct error value as users are allowed
not to enable all features.

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

Re: [FFmpeg-devel] [PATCH]lavfi/af_aiir, af_afir: Remove a variable that is always -1

[Carl Eugen Hoyos]

2018-07-19 21:36 GMT+02:00, Paul B Mahol :
> On 7/19/18, Carl Eugen Hoyos  wrote:

>> Two very similar conditions in af_aiir.c and af_afir.c can
>> never be true afaict.
>>
>> Please review, Carl Eugen
>>
>
> Should be ok if properly tested.

Tested and applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]tools/qt-faststart: Allow free atoms after moov atom

[Carl Eugen Hoyos]

2018-07-12 1:28 GMT+02:00, Carl Eugen Hoyos :

> Attached patch allows to fast-start mov files with free atoms after
> the moov atom.
> Tested with the sample from ticket #7277.

Ping.

As this is not trivial to test, I would prefer not to "improve" the patch
until another sample appears.

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

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

[Michael Niedermayer]

On Wed, Jul 04, 2018 at 03:06:54PM -0700, Baptiste Coudurier wrote:
> ---
>  libavformat/mxf.c|  1 +
>  libavformat/mxfdec.c |  2 ++
>  libavformat/mxfenc.c | 41 +
>  libavformat/utils.c  |  6 +-
>  4 files changed, 45 insertions(+), 5 deletions(-)
[...]
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c9cdd2b470..36a32ad9c2 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1003,6 +1003,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  *pnum = frame_size;
>  *pden = sample_rate;
>  break;
> +case AVMEDIA_TYPE_DATA:
> +*pnum = st->time_base.num;
> +*pden = st->time_base.den;
> +break;
>  default:
>  break;
>  }
> @@ -1405,7 +1409,7 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  presentation_delayed, delay, av_ts2str(pkt->pts), 
> av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
>  
>  /* update flags */
> -if (is_intra_only(st->codecpar->codec_id))
> +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || 
> is_intra_only(st->codecpar->codec_id))
>  pkt->flags |= AV_PKT_FLAG_KEY;
>  #if FF_API_CONVERGENCE_DURATION
>  FF_DISABLE_DEPRECATION_WARNINGS

This should be a seperate patch.
Also i think forcing duration=1 is not correct for all AVMEDIA_TYPE_DATA
for example there are ID3 and fonts. These would i guess if they have a
timebase set apply to more than 1 "unit"

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined

[Michael Niedermayer]

On Thu, Jul 19, 2018 at 01:53:09PM +0200, Tobias Rapp wrote:
> On 18.07.2018 19:31, Marcin Gorzel wrote:
> >Rematrixing supports up to 64 channels. However, there is only a limited 
> >number of channel layouts defined. Since the in/out channel count is 
> >obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11 
> >channels etc.) the rematrixing fails.
> >
> >In ticket #6790 the problem has been partially addressed by applying a patch 
> >to swr_set_matrix() in rematrix.c:72.
> >However, a similar change must be also applied to swri_rematrix_init() in 
> >rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
> >---
> >  libswresample/rematrix.c  | 6 --
> >  libswresample/x86/rematrix_init.c | 6 --
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> >
> >diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> >index 8227730056..d1a0cfe7f8 100644
> >--- a/libswresample/rematrix.c
> >+++ b/libswresample/rematrix.c
> >@@ -384,8 +384,10 @@ av_cold static int auto_matrix(SwrContext *s)
> >  av_cold int swri_rematrix_init(SwrContext *s){
> >  int i, j;
> >-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
> >-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> >+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> >+av_get_channel_layout_nb_channels(s->in_ch_layout);
> >+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> >+av_get_channel_layout_nb_channels(s->out_ch_layout);
> >  s->mix_any_f = NULL;
> >diff --git a/libswresample/x86/rematrix_init.c 
> >b/libswresample/x86/rematrix_init.c
> >index d71b41a73e..4f9c92e4ab 100644
> >--- a/libswresample/x86/rematrix_init.c
> >+++ b/libswresample/x86/rematrix_init.c
> >@@ -33,8 +33,10 @@ D(int16, sse2)
> >  av_cold int swri_rematrix_init_x86(struct SwrContext *s){
> >  #if HAVE_X86ASM
> >  int mm_flags = av_get_cpu_flags();
> >-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
> >-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> >+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> >+av_get_channel_layout_nb_channels(s->in_ch_layout);
> >+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> >+av_get_channel_layout_nb_channels(s->out_ch_layout);
> >  int num= nb_in * nb_out;
> >  int i,j;
> >
> 
> Patch looks good to me, except that the title should be updated to reflect
> the new logic. I suggest something like "swresample: Use channel count for
> rematrix initialization if defined".

The patch does not look good to me
There should be a field that represents the count of channels.
No conditional should be needed

please check that every field is wrong in at least some case.
If true a new field must be added or a existing one needs to be set
differently
But there should be a field that represents the channel count.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Make the user help mailing lists subscription only

[Michael Niedermayer]

On Thu, Jul 19, 2018 at 10:12:49PM +0200, Thilo Borgmann wrote:
> Hi,
> 
> > Am 19.07.2018 um 21:41 schrieb Lou Logan :
> > 
> >> On Wed, Jul 18, 2018, at 3:32 AM, Gyan Doshi wrote:
> >> 
> >> What's the volume of messages from non-subscribers relative to subscribers?
> > 
> > I'm not sure. I never did keep a running tally. I may be able to figure it 
> > out via the logs if I were motivated enough.
> > 
> > However, I can provide some limited info between 28 June - 17 July. I 
> > believe these were the messages I approved:
> > 
> > [FFmpeg-user] How to have ffmpeg use parallel processing when searching 
> > through a single video
> >Reply by Carl. No response by OP.
> > [FFmpeg-user] Multi-Channel Audio Limitations?
> >Reply by Carl. No response by OP.
> > [FFmpeg-user] Decoding frames as fast as possible
> >Reply by Carl. No response by OP.
> > [FFmpeg-user] need help on making ffmpeg x64 for UWP
> >Reply by Carl. No response by OP.
> > [FFmpeg-user] ffmpeg automation
> >Reply by Cley. No response by OP.
> > [FFmpeg-user] Attempting to hardcode subtitles - no subtitles are present
> >Reply by Carl. No response by OP.
> > [FFmpeg-user] Question regarding FFmpeg copyright
> >Multiple replies. No response by OP.
> > [FFmpeg-user] Need old version ffmpeg win32 shared of Windows 32-bit Builds
> >Reply by Moritz. No response by OP.
> > [FFmpeg-user] Output file #0 does not contain any stream
> >Reply by Moritz. No response by OP.
> > [FFmpeg-user] Running out of RAM when copying 1080p H264 stream
> >Send-subscribe-resend duplicate.
> > [FFmpeg-user] FFMPEG- Buffers
> > [FFmpeg-user] how to use Intel qsv codec for ffmpeg 4.0 
> > Re: [FFmpeg-user] FFserver doesn't work with HLS
> >Non-verbatim duplicate.
> > [FFmpeg-user] [Add sei_user_data while encoding a h264 stream]
> > Re: [FFmpeg-user] Send audio to Axis encoder and change http_post header
> >An "I'm having the same issue" reply to an old message.
> > [FFmpeg-user] Input from FIFO for Multiple Video Track
> > [FFmpeg-user] using ffmpeg launcher
> > 
> > Out of 17 approved messages 9 got a reply or replies. Out of those 9 there 
> > were 0 followup replies by the original posters. Not encouraging.
> > 
> > If these users received all messages they would be more likely to see 
> > replies to their messages.
> > 
> >> One issue I see with subscriptions is that the typical 'customer' of 
> >> *-users is someone only interested in solving their problem. Receiving a 
> >> bunch of unrelated messages every day, when one has only a narrow and 
> >> temporary concern with ffmpeg, is annoying.
> > 
> > Yes, it may be annoying, but it can easily be managed by simple client-side 
> > email filtering which should be an accessible and perhaps even familiar 
> > option for most users these days (filtering is recommended by the Mailing 
> > List FAQ), and they can easily unsubscribe/suspend delivery at will.
> > 
> > More annoying, in my opinion, is spending time answering a message that 
> > will likely never be read. There always are more questions than answers. We 
> > are just volunteers and only have limited time to answer an unending stream 
> > of questions across various resources (mailing lists, IRC, various third 
> > party forums, Stack Exchange, etc), as I'm sure you are familiar with.
> > 
> >> When the list receives a message from a first-time non-subscriber user, 
> >> can Mailman either auto-subscribe them or send out an email with a link 
> >> to a pre-filled subscription page ? Just thinking of ways to reduce 
> >> friction or annoyance for someone who's just discovered the ML and wants 
> >> to post a query.
> > 
> > I appreciate the suggestions, but the problem is spam. There is lots of it 
> > every day. If an address is auto-subscribed we would be inundated. As for 
> > the link, users do get a reply telling them their message is in the queue 
> > and requires approval. Don't know about a pre-filled subscription page.
> 

> As long as we can‘t configure it to send thread-only replies to unsubscribed 
> users there is hardly an option at hand IMHO.

This would be the ideal solution


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

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel