Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Jerome Martinez]

On 09/02/2018 02:19, Carl Eugen Hoyos wrote:

2018-02-08 11:28 GMT+01:00 Jerome Martinez :

Currently RGB and RGBA 12-bit are supported by DPX decoder only if component
values are padded (packing "Filled to 32-bit words, method A").
This patch adds decoding of RGB
and RGBA 12-bit with no padding (packing "Packed into 32-bit words").

I suggest we wait with this patch until we verified if RGBA dpx decoding
is broken (I suspect so, I believe you have a sample to verify).


Sorry, I see a line was missing in my first post, the one with the link 
to the RGBA test file.

Test file for RGBA 12-bit packed:
https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE

Regression test done on 
checkerboard_1080p_nuke_bigendian_12bit_alpha.dpx and 
checkerboard_1080p_nuke_littleendian_12bit_alpha.dpx in 
https://samples.ffmpeg.org/image-samples/dpx_samples.zip





As-is, we wouldn't do anybody a favour.

Thank you, 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

[FFmpeg-devel] [PATCH] avcodec/vp3: Check eob_run

[Michael Niedermayer]

Fixes: out of array access
Fixes: 5919/clusterfuzz-testcase-minimized-5859311382167552

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index cf9c57f5fa..120c20f349 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -978,6 +978,9 @@ static int unpack_vlcs(Vp3DecodeContext *s, GetBitContext 
*gb,
 if (eob_run_get_bits[token])
 eob_run += get_bits(gb, eob_run_get_bits[token]);
 
+if (!eob_run)
+return AVERROR_INVALIDDATA;
+
 // record only the number of blocks ended in this plane,
 // any spill will be recorded in the next plane.
 if (eob_run > num_coeffs - coeff_i) {
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH] dashdec: Support SegmentTimeline inside Period

[Steven Liu]

>> 在 2018年2月7日，上午5:30，Stefan _  写道：
>>
>>
>> <0001-dashdec-Support-SegmentTimeline-inside-Period.patch>
> LGTM


Pushed

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

Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures

[Nekopanda]

> From: Carl Eugen Hoyos 

> 
> 2018-02-09 3:07 GMT+01:00 Nekopanda 
> :
>>>  How did you find this bug ?
>>> 
>>>  do you have a testcase / file which shows artifacts without this change 
> ?
>> 
>>  Yes, I have files that show artifacts without this change. Recently,
>>  Japanese satellite television started to use field pictures widely,
>>  and many of that show artifacts. We need this change to remove
>>  the artifacts.
> 
> Could you provide a sample with visible artefacts?

Sorry, all of them are copyrighted materials and difficult to share.

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

Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures

[Carl Eugen Hoyos]

2018-02-09 3:07 GMT+01:00 Nekopanda :
>> How did you find this bug ?
>>
>> do you have a testcase / file which shows artifacts without this change ?
>
> Yes, I have files that show artifacts without this change. Recently,
> Japanese satellite television started to use field pictures widely,
> and many of that show artifacts. We need this change to remove
> the artifacts.

Could you provide a sample with visible artefacts?

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: sort codec_descriptors

[Michael Niedermayer]

On Sat, Feb 03, 2018 at 01:35:34AM +0700, Muhammad Faiz wrote:
> Use bsearch on avcodec_descriptor_get().
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavcodec/codec_desc.c | 1103 
> ---
>  1 file changed, 563 insertions(+), 540 deletions(-)

probably ok

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures

[Nekopanda]

> How did you find this bug ?
> 
> do you have a testcase / file which shows artifacts without this change ?

Yes, I have files that show artifacts without this change. Recently, Japanese 
satellite television started to use field pictures widely, and many of that 
show artifacts. We need this change to remove the artifacts.

> assuming the change is correct then the patch needs to update several fate
> checksums. As is it would break make fate

currently the following tests fail with this change.

filter-w3fdif-complex
filter-w3fdif-simple
filter-yadif10
filter-yadif16
filter-yadif-mode0
filter-yadif-mode1
mpeg2-field-enc
mpeg2-ticket186
mpeg2-ticket6677



- Original Message -
> From: Michael Niedermayer 
> To: FFmpeg development discussions and patches 
> Cc: 
> Date: 2018/2/9, Fri 09:55
> Subject: Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures
> 
> On Fri, Feb 09, 2018 at 02:03:24AM +0900, Nekopanda wrote:
>>  - Fix field selection for skipped macroblocks
>> 
>>  For B field pictures, the spec says,
>> 
>>  > The prediction shall be made from the field of the same parity as the 
> field being predicted.
>> 
>>  I did it.
>> 
>>  - Fix motion vector rounding for chroma components
>> 
>>  In 16x8 motion compensation, for lower 16x8 region, the input to 
> mpeg_motion() for motion_y was "motion_y + 16", which causes wrong 
> rounding. For 4:2:0, chroma scaling for y is dividing by two and rounding 
> toward 
> zero. When motion_y < 0 and motion_y + 16 > 0, the rounding direction of 
> "motion_y" and "motion_y + 16" is different and rounding 
> "motion_y + 16" would be incorrect.
>> 
>>  We should input "motion_y" as is to round correctly. I add 
> "is_16x8" flag to do that.
>>  ---
>>   libavcodec/mpeg12dec.c        |  2 ++
>>   libavcodec/mpegvideo_motion.c | 30 --
>>   2 files changed, 18 insertions(+), 14 deletions(-)
> 
> How did you find this bug ?
> 
> do you have a testcase / file which shows artifacts without this change ?
> 
> assuming the change is correct then the patch needs to update several fate
> checksums. As is it would break make fate
> 
> thanks
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> "Nothing to hide" only works if the folks in power share the values of
> you and everyone you know entirely and always will -- Tom Scott
> 
> 
> ___
> 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] avformat/opensrt: add Haivision Open SRT protocol

[Michael Niedermayer]

On Tue, Jan 30, 2018 at 04:11:03PM -0500, Nablet Developer wrote:
> protocol requires libsrt (https://github.com/Haivision/srt) to be
> installed
> 
> Signed-off-by: Nablet Developer 
> ---
>  MAINTAINERS |   1 +
>  configure   |   9 +
>  doc/protocols.texi  | 116 +
>  libavformat/Makefile|   1 +
>  libavformat/opensrt.c   | 621 
> 
>  libavformat/protocols.c |   1 +
>  6 files changed, 749 insertions(+)
>  create mode 100644 libavformat/opensrt.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba7a728..0317f24 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -498,6 +498,7 @@ Protocols:
>http.cRonald S. Bultje
>libssh.c  Lukasz Marek
>mms*.cRonald S. Bultje
> +  opensrt.c Nablet Developer
>udp.c Luca Abeni
>icecast.c Marvin Scholz

Is "Nablet Developer" identifying a single person ?
if not this is not ok as the MAINTAINERS files gives one also the right to
have git write access and that would not work with a unspecified group


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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] examples: Don't call deprecated functions which don't do anything

[James Almer]

On 2/8/2018 10:41 PM, Jun Zhao wrote:
> 
> 
> On 2018/2/8 3:44, Mark Thompson wrote:
>> ---
>>  doc/examples/avio_dir_cmd.c  | 2 --
>>  doc/examples/avio_reading.c  | 3 ---
>>  doc/examples/decode_audio.c  | 3 ---
>>  doc/examples/decode_video.c  | 2 --
>>  doc/examples/demuxing_decoding.c | 3 ---
>>  doc/examples/encode_audio.c  | 3 ---
>>  doc/examples/encode_video.c  | 2 --
>>  doc/examples/extract_mvs.c   | 2 --
>>  doc/examples/filtering_audio.c   | 1 -
>>  doc/examples/filtering_video.c   | 1 -
>>  doc/examples/http_multiclient.c  | 1 -
>>  doc/examples/hw_decode.c | 2 --
>>  doc/examples/metadata.c  | 1 -
>>  doc/examples/muxing.c| 3 ---
>>  doc/examples/qsvdec.c| 2 --
>>  doc/examples/remuxing.c  | 2 --
>>  doc/examples/transcode_aac.c | 2 --
>>  doc/examples/transcoding.c   | 1 -
>>  doc/examples/vaapi_encode.c  | 2 --
>>  doc/examples/vaapi_transcode.c   | 2 --
>>  20 files changed, 40 deletions(-)
>>
>> diff --git a/doc/examples/avio_dir_cmd.c b/doc/examples/avio_dir_cmd.c
>> index 50c435cf8f..0722bd9ab1 100644
>> --- a/doc/examples/avio_dir_cmd.c
>> +++ b/doc/examples/avio_dir_cmd.c
>> @@ -143,8 +143,6 @@ int main(int argc, char *argv[])
>>  return 1;
>>  }
>>  
>> -/* register codecs and formats and other lavf/lavc components*/
>> -av_register_all();
>>  avformat_network_init();
>>  
>>  op = argv[1];
>> diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
>> index 7860fd5e2f..cbfeb174b8 100644
>> --- a/doc/examples/avio_reading.c
>> +++ b/doc/examples/avio_reading.c
>> @@ -74,9 +74,6 @@ int main(int argc, char *argv[])
>>  }
>>  input_filename = argv[1];
>>  
>> -/* register codecs and formats and other lavf/lavc components*/
>> -av_register_all();
>> -
>>  /* slurp file content into buffer */
>>  ret = av_file_map(input_filename, , _size, 0, NULL);
>>  if (ret < 0)
>> diff --git a/doc/examples/decode_audio.c b/doc/examples/decode_audio.c
>> index fb9a9af2f6..19dcafd2c8 100644
>> --- a/doc/examples/decode_audio.c
>> +++ b/doc/examples/decode_audio.c
>> @@ -94,9 +94,6 @@ int main(int argc, char **argv)
>>  filename= argv[1];
>>  outfilename = argv[2];
>>  
>> -/* register all the codecs */
>> -avcodec_register_all();
>> -
>>  pkt = av_packet_alloc();
>>  
>>  /* find the MPEG audio decoder */
>> diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
>> index 4377fd49e0..5a9d43f689 100644
>> --- a/doc/examples/decode_video.c
>> +++ b/doc/examples/decode_video.c
>> @@ -101,8 +101,6 @@ int main(int argc, char **argv)
>>  filename= argv[1];
>>  outfilename = argv[2];
>>  
>> -avcodec_register_all();
>> -
>>  pkt = av_packet_alloc();
>>  if (!pkt)
>>  exit(1);
>> diff --git a/doc/examples/demuxing_decoding.c 
>> b/doc/examples/demuxing_decoding.c
>> index b1a216abb4..69a31a8935 100644
>> --- a/doc/examples/demuxing_decoding.c
>> +++ b/doc/examples/demuxing_decoding.c
>> @@ -252,9 +252,6 @@ int main (int argc, char **argv)
>>  video_dst_filename = argv[2];
>>  audio_dst_filename = argv[3];
>>  
>> -/* register all formats and codecs */
>> -av_register_all();
>> -
>>  /* open input file, and allocate format context */
>>  if (avformat_open_input(_ctx, src_filename, NULL, NULL) < 0) {
>>  fprintf(stderr, "Could not open source file %s\n", src_filename);
>> diff --git a/doc/examples/encode_audio.c b/doc/examples/encode_audio.c
>> index d1ef105d9d..ab3586be7f 100644
>> --- a/doc/examples/encode_audio.c
>> +++ b/doc/examples/encode_audio.c
>> @@ -138,9 +138,6 @@ int main(int argc, char **argv)
>>  }
>>  filename = argv[1];
>>  
>> -/* register all the codecs */
>> -avcodec_register_all();
>> -
>>  /* find the MP2 encoder */
>>  codec = avcodec_find_encoder(AV_CODEC_ID_MP2);
>>  if (!codec) {
>> diff --git a/doc/examples/encode_video.c b/doc/examples/encode_video.c
>> index 8cd13219bb..6731b2ad19 100644
>> --- a/doc/examples/encode_video.c
>> +++ b/doc/examples/encode_video.c
>> @@ -84,8 +84,6 @@ int main(int argc, char **argv)
>>  filename = argv[1];
>>  codec_name = argv[2];
>>  
>> -avcodec_register_all();
>> -
>>  /* find the mpeg1video encoder */
>>  codec = avcodec_find_encoder_by_name(codec_name);
>>  if (!codec) {
>> diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
>> index 7ae934ead3..de31ccd2b9 100644
>> --- a/doc/examples/extract_mvs.c
>> +++ b/doc/examples/extract_mvs.c
>> @@ -129,8 +129,6 @@ int main(int argc, char **argv)
>>  }
>>  src_filename = argv[1];
>>  
>> -av_register_all();
>> -
>>  if (avformat_open_input(_ctx, src_filename, NULL, NULL) < 0) {
>>  fprintf(stderr, "Could not open source file %s\n", src_filename);
>>  exit(1);
>> diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
>> index 

Re: [FFmpeg-devel] [PATCH] examples: Don't call deprecated functions which don't do anything

[Jun Zhao]

On 2018/2/8 3:44, Mark Thompson wrote:
> ---
>  doc/examples/avio_dir_cmd.c  | 2 --
>  doc/examples/avio_reading.c  | 3 ---
>  doc/examples/decode_audio.c  | 3 ---
>  doc/examples/decode_video.c  | 2 --
>  doc/examples/demuxing_decoding.c | 3 ---
>  doc/examples/encode_audio.c  | 3 ---
>  doc/examples/encode_video.c  | 2 --
>  doc/examples/extract_mvs.c   | 2 --
>  doc/examples/filtering_audio.c   | 1 -
>  doc/examples/filtering_video.c   | 1 -
>  doc/examples/http_multiclient.c  | 1 -
>  doc/examples/hw_decode.c | 2 --
>  doc/examples/metadata.c  | 1 -
>  doc/examples/muxing.c| 3 ---
>  doc/examples/qsvdec.c| 2 --
>  doc/examples/remuxing.c  | 2 --
>  doc/examples/transcode_aac.c | 2 --
>  doc/examples/transcoding.c   | 1 -
>  doc/examples/vaapi_encode.c  | 2 --
>  doc/examples/vaapi_transcode.c   | 2 --
>  20 files changed, 40 deletions(-)
>
> diff --git a/doc/examples/avio_dir_cmd.c b/doc/examples/avio_dir_cmd.c
> index 50c435cf8f..0722bd9ab1 100644
> --- a/doc/examples/avio_dir_cmd.c
> +++ b/doc/examples/avio_dir_cmd.c
> @@ -143,8 +143,6 @@ int main(int argc, char *argv[])
>  return 1;
>  }
>  
> -/* register codecs and formats and other lavf/lavc components*/
> -av_register_all();
>  avformat_network_init();
>  
>  op = argv[1];
> diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
> index 7860fd5e2f..cbfeb174b8 100644
> --- a/doc/examples/avio_reading.c
> +++ b/doc/examples/avio_reading.c
> @@ -74,9 +74,6 @@ int main(int argc, char *argv[])
>  }
>  input_filename = argv[1];
>  
> -/* register codecs and formats and other lavf/lavc components*/
> -av_register_all();
> -
>  /* slurp file content into buffer */
>  ret = av_file_map(input_filename, , _size, 0, NULL);
>  if (ret < 0)
> diff --git a/doc/examples/decode_audio.c b/doc/examples/decode_audio.c
> index fb9a9af2f6..19dcafd2c8 100644
> --- a/doc/examples/decode_audio.c
> +++ b/doc/examples/decode_audio.c
> @@ -94,9 +94,6 @@ int main(int argc, char **argv)
>  filename= argv[1];
>  outfilename = argv[2];
>  
> -/* register all the codecs */
> -avcodec_register_all();
> -
>  pkt = av_packet_alloc();
>  
>  /* find the MPEG audio decoder */
> diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
> index 4377fd49e0..5a9d43f689 100644
> --- a/doc/examples/decode_video.c
> +++ b/doc/examples/decode_video.c
> @@ -101,8 +101,6 @@ int main(int argc, char **argv)
>  filename= argv[1];
>  outfilename = argv[2];
>  
> -avcodec_register_all();
> -
>  pkt = av_packet_alloc();
>  if (!pkt)
>  exit(1);
> diff --git a/doc/examples/demuxing_decoding.c 
> b/doc/examples/demuxing_decoding.c
> index b1a216abb4..69a31a8935 100644
> --- a/doc/examples/demuxing_decoding.c
> +++ b/doc/examples/demuxing_decoding.c
> @@ -252,9 +252,6 @@ int main (int argc, char **argv)
>  video_dst_filename = argv[2];
>  audio_dst_filename = argv[3];
>  
> -/* register all formats and codecs */
> -av_register_all();
> -
>  /* open input file, and allocate format context */
>  if (avformat_open_input(_ctx, src_filename, NULL, NULL) < 0) {
>  fprintf(stderr, "Could not open source file %s\n", src_filename);
> diff --git a/doc/examples/encode_audio.c b/doc/examples/encode_audio.c
> index d1ef105d9d..ab3586be7f 100644
> --- a/doc/examples/encode_audio.c
> +++ b/doc/examples/encode_audio.c
> @@ -138,9 +138,6 @@ int main(int argc, char **argv)
>  }
>  filename = argv[1];
>  
> -/* register all the codecs */
> -avcodec_register_all();
> -
>  /* find the MP2 encoder */
>  codec = avcodec_find_encoder(AV_CODEC_ID_MP2);
>  if (!codec) {
> diff --git a/doc/examples/encode_video.c b/doc/examples/encode_video.c
> index 8cd13219bb..6731b2ad19 100644
> --- a/doc/examples/encode_video.c
> +++ b/doc/examples/encode_video.c
> @@ -84,8 +84,6 @@ int main(int argc, char **argv)
>  filename = argv[1];
>  codec_name = argv[2];
>  
> -avcodec_register_all();
> -
>  /* find the mpeg1video encoder */
>  codec = avcodec_find_encoder_by_name(codec_name);
>  if (!codec) {
> diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
> index 7ae934ead3..de31ccd2b9 100644
> --- a/doc/examples/extract_mvs.c
> +++ b/doc/examples/extract_mvs.c
> @@ -129,8 +129,6 @@ int main(int argc, char **argv)
>  }
>  src_filename = argv[1];
>  
> -av_register_all();
> -
>  if (avformat_open_input(_ctx, src_filename, NULL, NULL) < 0) {
>  fprintf(stderr, "Could not open source file %s\n", src_filename);
>  exit(1);
> diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
> index 18d6ca275c..73a00e814c 100644
> --- a/doc/examples/filtering_audio.c
> +++ b/doc/examples/filtering_audio.c
> @@ -228,7 +228,6 @@ int main(int argc, char **argv)
>  

Re: [FFmpeg-devel] [FFmpeng-devel] Dose ffmpeg plan to support FMO decode in h264

[Wei Gao]

2018-02-08 6:59 GMT+08:00 Michael Niedermayer :

> On Wed, Feb 07, 2018 at 02:15:26PM +0800, Wei Gao wrote:
> > 2018-02-07 6:57 GMT+08:00 Michael Niedermayer :
> >
> > > On Tue, Feb 06, 2018 at 11:14:49AM +0800, Wei Gao wrote:
> > > > Hi
> > > >
> > > > I have a question.
> > > >
> > > > Does ffmpeg plan to support FMO(Flexible Macroblock Ordering)?
> > >
> > > when someone sends a patch that implements it
> > >
> > Hi
> > OK, thanks.
> > I saw there is a FMO macro, but it define to 0.
>
> yes, there was partial FMO support in some functions i wrote but it was
> never completed.
>
> lack of interrest, lack of anything out there using it and lack of anyone
> funding the work probably are the reasons why noone implemented FMO support
>
Hi

Thanks
Best regards

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite
> number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> 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/dpx: Support for RGB and RGBA 12-bit packed decoding

[Carl Eugen Hoyos]

2018-02-08 11:28 GMT+01:00 Jerome Martinez :
> Currently RGB and RGBA 12-bit are supported by DPX decoder only if component
> values are padded (packing "Filled to 32-bit words, method A").
> This patch adds decoding of RGB

> and RGBA 12-bit with no padding (packing "Packed into 32-bit words").

I suggest we wait with this patch until we verified if RGBA dpx decoding
is broken (I suspect so, I believe you have a sample to verify).

As-is, we wouldn't do anybody a favour.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add support for low-power encoding

[Xiang, Haihao]

> On 06/02/18 08:17, Haihao Xiang wrote:
> > Although VAEntrypointEncSliceLP was added in old version of VAAPI, we
> > never implemented it for VAAPI H265 encoder before. so it is reasonable
> > to require VAAPI 1.0
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vaapi_encode_h265.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> > index f3b4f6c7e26..efe1148127f 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -65,6 +65,7 @@ typedef struct VAAPIEncodeH265Options {
> >  int aud;
> >  int profile;
> >  int level;
> > +int low_power;
> >  } VAAPIEncodeH265Options;
> >  
> >  
> > @@ -914,7 +915,18 @@ static av_cold int
> > vaapi_encode_h265_init(AVCodecContext *avctx)
> > avctx->profile);
> >  return AVERROR(EINVAL);
> >  }
> > -ctx->va_entrypoint = VAEntrypointEncSlice;
> > +
> > +if (opt->low_power) {
> > +#if VA_CHECK_VERSION(1, 0, 0)
> > +ctx->va_entrypoint = VAEntrypointEncSliceLP;
> > +#else
> > +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
> > +   "supported with this VAAPI version.\n");
> > +return AVERROR(EINVAL);
> > +#endif
> > +} else {
> > +ctx->va_entrypoint = VAEntrypointEncSlice;
> > +}
> >  
> >  if (avctx->bit_rate > 0) {
> >  if (avctx->rc_max_rate == avctx->bit_rate)
> > @@ -986,6 +998,10 @@ static const AVOption vaapi_encode_h265_options[] = {
> >  { LEVEL("6.2", 186) },
> >  #undef LEVEL
> >  
> > +{ "low_power", "Use low-power encoding mode (experimental: only
> > supported "
> 
> Do you want to copy this comment?
> 

Actually I want to delete the comments in (), but the limitation for HEVC low
power encoding still exist. It would be better to add some VAAPI attributes to
query the capability/limitation etc.


> > +  "on some platforms, does not support all features)",
> > +  OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
> > +
> >  { NULL },
> >  };
> >  
> > 
> 
> How can I test this (and the following patch)?  It doesn't appear to exist on
> any current platform/driver.
> 

Cannon Lake support HEVC low power encoding, do you have this platform?  https:/
/github.com/intel/media-driver/ should support this feature but it isn't ready
in https://github.com/intel/intel-vaapi-driver. 

> I don't like how this code is being copied around, but I guess it would work
> for now.  I'll look into doing something more sensible here.
> 

I also dislike duplicated code. I wanted to add some common options for VAAPI
encoder in FFmpeg, such as QP. However low power encoding is not available for
some codecs, such as VP8, so I copied the code here. 

Another thing is a driver may not support both VAEntrypointEncSliceLP and
VAEntrypointEncSlice, so I want to change the value range of low_power to -1, 0,
1. -1 means auto mode, FFmpeg-vaapi will select the first applicable entrypoint,
what is your comment for this proposal?

Thanks
Haihao


> - Mark
> ___
> 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] mpeg2dec: fix decoding field pictures

[Michael Niedermayer]

On Fri, Feb 09, 2018 at 02:03:24AM +0900, Nekopanda wrote:
> - Fix field selection for skipped macroblocks
> 
> For B field pictures, the spec says,
> 
> > The prediction shall be made from the field of the same parity as the field 
> > being predicted.
> 
> I did it.
> 
> - Fix motion vector rounding for chroma components
> 
> In 16x8 motion compensation, for lower 16x8 region, the input to 
> mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. 
> For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. 
> When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" 
> and "motion_y + 16" is different and rounding "motion_y + 16" would be 
> incorrect.
> 
> We should input "motion_y" as is to round correctly. I add "is_16x8" flag to 
> do that.
> ---
>  libavcodec/mpeg12dec.c|  2 ++
>  libavcodec/mpegvideo_motion.c | 30 --
>  2 files changed, 18 insertions(+), 14 deletions(-)

How did you find this bug ?

do you have a testcase / file which shows artifacts without this change ?

assuming the change is correct then the patch needs to update several fate
checksums. As is it would break make fate

thanks

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

[Michael Niedermayer]

On Thu, Feb 08, 2018 at 06:09:46PM +0100, Paul B Mahol wrote:
> On 2/5/18, Michael Niedermayer  wrote:
> > On Mon, Feb 05, 2018 at 10:04:47AM +0100, Paul B Mahol wrote:
> >> On 2/5/18, Michael Niedermayer  wrote:
> >> > On Thu, Feb 01, 2018 at 02:36:16AM +0100, Michael Niedermayer wrote:
> >> >> On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote:
> >> >> > On 1/31/18, Michael Niedermayer  wrote:
> >> >> > > Fixes: Timeout
> >> >> > > Fixes: 5487/clusterfuzz-testcase-4696837035393024
> >> >> > >
> >> >> > > Found-by: continuous fuzzing process
> >> >> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> >> > > Signed-off-by: Michael Niedermayer 
> >> >> > > ---
> >> >> > >  libavcodec/huffyuvdec.c | 3 +++
> >> >> > >  1 file changed, 3 insertions(+)
> >> >> > >
> >> >> > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
> >> >> > > index 979c4b9d5c..66357bfb40 100644
> >> >> > > --- a/libavcodec/huffyuvdec.c
> >> >> > > +++ b/libavcodec/huffyuvdec.c
> >> >> > > @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx,
> >> >> > > void
> >> >> > > *data, int *got_frame,
> >> >> > >  AVFrame *const p = data;
> >> >> > >  int table_size = 0, ret;
> >> >> > >
> >> >> > > +if (buf_size < (width * height + 7)/8)
> >> >> > > +return AVERROR_INVALIDDATA;
> >> >> > > +
> >> >> >
> >> >> > Are you sure this is enough?
> >> >>
> >> >> I dont know if thats the only way the decoder can be made to waste
> >> >> large amounts of CPU with little input data
> >> >>
> >> >> I do belive it stops this specific class of issues though
> >> >>
> >> >>
> >> >> >
> >> >> > Something similar you had already posted long ago.
> >> >>
> >> >> for other decoders, yes. Did i forget a patch for huffyuv ?
> >> >
> >> > i will apply this in a few days unless someone has objections or
> >> > sees some possible imrpovment
> >>
> >> Are you sure this does not break decoding of valid files?
> >
> > huffyuv encodes samples using huffman codes, the smallest is 1 bit so
> > w*h bits should be the minimum
> >
> >
> 
> ok

will apply

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Michael Niedermayer]

On Thu, Feb 08, 2018 at 06:21:06PM +0100, wm4 wrote:
> On Thu, 8 Feb 2018 12:34:07 -0300
> James Almer  wrote:
> 
> > On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> > > On 8 February 2018 at 10:06, Nicolas George  wrote:
> > >   
> > >> Michael Niedermayer (2018-02-08):  
> > >>> +1  
> > >>
> > >> I agree too.
> > >>
> > >> And maybe, since we are reverting something, revert the whole series.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >>   Nicolas George
> > >>
> > >> ___
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >>  
> > > 
> > > -1, I object to reverting anything.
> > > We should fix what we have right now. The API looks good too except some
> > > people here feel like they haven't bikeshedded enough and want to cause
> > > even more chaos.
> > > One bad commit and you all go screaming revert with your pitchforks 
> > > instead
> > > of trying to fix it.  
> > 
> > A set of seven patches was pushed before any of them got a full review
> > or even an ok, which unsurprisingly introduced a plethora of issues, and
> > all while there were discussions going about implementing the API in a
> > different way by more than one developer.
> > I do not, under any circumstance, support this strategy of pushing
> > unfinished things and then argue that since it's already committed it
> > can't be touched. I have no idea how you or anyone could support this
> > kind of thing.
> > 
> > The entire set should be reverted if only to make it clear that this is
> > not how development should work, yet everyone so far, including myself,
> > has suggested to only revert the one non-API commit that badly broke a
> > lot of things, then work on top of the already introduced API to
> > effectively finalize it, and then fix and reapply any implementation bits.
> 

> The author spent weeks on fixing all the issues, updating the patch set
> multiple times, and so on. In the end, he didn't get much helpful
> reviews, but tons of bikeshedding that was unproductive as hell. Also
> it seems he formally didn't violate any rules, because he fixed the
> issues and waited long enough.

Theres no need to polarize the discussion any further.
neither attacking anyone nor glorifying the author of a patchset
with a inprecisse statement where a correction would likely insult the author.
iam sure he is already stressed from having pushed a patchset that introduced
some issues.

We are one team, if WE have a bug in the code we should fix it or revert the
patch causing it. If a issue is trivial to fix then fixing is better. If it
is complex and one works under pressure its likely better to revert so as not
to introduce more mistakes and have a clean known to work basis ...

Thanks

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mpegenc - accept PCM_DVD streams

[Michael Niedermayer]

On Thu, Feb 08, 2018 at 02:04:57PM +0530, Gyan Doshi wrote:
> 
> 
> On 2/3/2018 3:59 AM, Michael Niedermayer wrote:
> 
> >>PCM_S16BE stream packets in MPEG-PS have a 3-byte header
> >>and recognized as PCM_DVD by the demuxer which prevents
> >>their proper remuxing in MPEG-1/2 PS.
> >
> >its probably a good idea to add a fate test for this too.
> >(could be in a seperate patch)
> 
> What type of test do you recommend?
> We'll need to check the decoded packets, so framecrc?

framecrc as well as the md5 of the muxed file or something like that
seems a possibility, yes

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] avfilter/vf_blend : add 16 bit simd version for basic blend mode

[Martin Vignali]

>
> breaks build on x86-32 linux
>
> X86ASM  libavfilter/x86/vf_blend.o
> src/libavfilter/x86/vf_blend.asm:389: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:390: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:391: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:392: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:393: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:399: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:400: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:421: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:422: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:423: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:424: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:425: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:426: error: invalid combination of
> opcode and operands
> src/libavfilter/x86/vf_blend.asm:427: error: invalid combination of
> opcode and operands
> make: *** [libavfilter/x86/vf_blend.o] Error 1
>
>
Ok, find a way to reproduce it on x86_32 osX

The problem is inside this macro :

%macro BLEND_INIT 2-3
%if ARCH_X86_64
cglobal blend_%1, 6, 9, %2, top, top_linesize, bottom, bottom_linesize,
dst, dst_linesize, width, end, x
movwidthd, dword widthm
%else
cglobal blend_%1, 5, 7, %2, top, top_linesize, bottom, bottom_linesize,
dst, end, x
%define dst_linesizeq r5mp
%define widthq r6mp
%endif
%if %0 == 3; is 16 bit
addwidthq, widthq ; < This new line doesn't compile on x86_32
%endif
mov  endd, dword r7m
add  topq, widthq
add   bottomq, widthq
add  dstq, widthq
negwidthq
%endmacro


Anyone have an idea ?
Otherwise, i can limit the 16 bit asm version to x86_64.

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

Re: [FFmpeg-devel] [PATCH]lavc/exr: Ignore long names flag

[Martin Vignali]

>
> Until now, two types of files are supported:
> Files with flags==0 and files with flags&0x02.
> The specification requires that (flags&0x02)
> implies flags==2 or possibly flags==6: "if bit
> 9 is 1, bits 11 and 12 must be 0"
>
> After my patch, the following values are
> accepted for flags: 0, 2, 4, 6
>
>
Hello,

Don't have a strong opinion about this.
But like deep data is not supported, and multipart file output is not
correct
Maybe we can be more explicit about unsupported features, and ignore long
name bit

Like in patch in attach

Martin


0008-avcodec-exr-add-support-for-long-name-flag.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[wm4]

On Thu, 8 Feb 2018 12:34:07 -0300
James Almer  wrote:

> On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> > On 8 February 2018 at 10:06, Nicolas George  wrote:
> >   
> >> Michael Niedermayer (2018-02-08):  
> >>> +1  
> >>
> >> I agree too.
> >>
> >> And maybe, since we are reverting something, revert the whole series.
> >>
> >> Regards,
> >>
> >> --
> >>   Nicolas George
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >>  
> > 
> > -1, I object to reverting anything.
> > We should fix what we have right now. The API looks good too except some
> > people here feel like they haven't bikeshedded enough and want to cause
> > even more chaos.
> > One bad commit and you all go screaming revert with your pitchforks instead
> > of trying to fix it.  
> 
> A set of seven patches was pushed before any of them got a full review
> or even an ok, which unsurprisingly introduced a plethora of issues, and
> all while there were discussions going about implementing the API in a
> different way by more than one developer.
> I do not, under any circumstance, support this strategy of pushing
> unfinished things and then argue that since it's already committed it
> can't be touched. I have no idea how you or anyone could support this
> kind of thing.
> 
> The entire set should be reverted if only to make it clear that this is
> not how development should work, yet everyone so far, including myself,
> has suggested to only revert the one non-API commit that badly broke a
> lot of things, then work on top of the already introduced API to
> effectively finalize it, and then fix and reapply any implementation bits.

The author spent weeks on fixing all the issues, updating the patch set
multiple times, and so on. In the end, he didn't get much helpful
reviews, but tons of bikeshedding that was unproductive as hell. Also
it seems he formally didn't violate any rules, because he fixed the
issues and waited long enough.

And now that some breakages occurred (which is not that surprising
since the patch changes so much), most mails on this topic are STILL
unhelpful bikeshedding.

Keeping patches in bikeshed hell while not giving good reviews (like
Michael just posting a specific command line and then saying "it broke"
while not saying anything actually helpful, or certain other devs who
came up with almost equivalent ideas how the components should be
iterated but which they have unusually strong opinions about), is a
good way to make developers leave and to make the mood of the project
worse.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

[Paul B Mahol]

On 2/5/18, Michael Niedermayer  wrote:
> On Mon, Feb 05, 2018 at 10:04:47AM +0100, Paul B Mahol wrote:
>> On 2/5/18, Michael Niedermayer  wrote:
>> > On Thu, Feb 01, 2018 at 02:36:16AM +0100, Michael Niedermayer wrote:
>> >> On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote:
>> >> > On 1/31/18, Michael Niedermayer  wrote:
>> >> > > Fixes: Timeout
>> >> > > Fixes: 5487/clusterfuzz-testcase-4696837035393024
>> >> > >
>> >> > > Found-by: continuous fuzzing process
>> >> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> >> > > Signed-off-by: Michael Niedermayer 
>> >> > > ---
>> >> > >  libavcodec/huffyuvdec.c | 3 +++
>> >> > >  1 file changed, 3 insertions(+)
>> >> > >
>> >> > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
>> >> > > index 979c4b9d5c..66357bfb40 100644
>> >> > > --- a/libavcodec/huffyuvdec.c
>> >> > > +++ b/libavcodec/huffyuvdec.c
>> >> > > @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx,
>> >> > > void
>> >> > > *data, int *got_frame,
>> >> > >  AVFrame *const p = data;
>> >> > >  int table_size = 0, ret;
>> >> > >
>> >> > > +if (buf_size < (width * height + 7)/8)
>> >> > > +return AVERROR_INVALIDDATA;
>> >> > > +
>> >> >
>> >> > Are you sure this is enough?
>> >>
>> >> I dont know if thats the only way the decoder can be made to waste
>> >> large amounts of CPU with little input data
>> >>
>> >> I do belive it stops this specific class of issues though
>> >>
>> >>
>> >> >
>> >> > Something similar you had already posted long ago.
>> >>
>> >> for other decoders, yes. Did i forget a patch for huffyuv ?
>> >
>> > i will apply this in a few days unless someone has objections or
>> > sees some possible imrpovment
>>
>> Are you sure this does not break decoding of valid files?
>
> huffyuv encodes samples using huffman codes, the smallest is 1 bit so
> w*h bits should be the minimum
>
>

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

[FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures

[Nekopanda]

- Fix field selection for skipped macroblocks

For B field pictures, the spec says,

> The prediction shall be made from the field of the same parity as the field 
> being predicted.

I did it.

- Fix motion vector rounding for chroma components

In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion() 
for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0, 
chroma scaling for y is dividing by two and rounding toward zero. When motion_y 
< 0 and motion_y + 16 > 0, the rounding direction of "motion_y" and "motion_y + 
16" is different and rounding "motion_y + 16" would be incorrect.

We should input "motion_y" as is to round correctly. I add "is_16x8" flag to do 
that.
---
 libavcodec/mpeg12dec.c|  2 ++
 libavcodec/mpegvideo_motion.c | 30 --
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index f5f2c69..9e076e8 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1969,6 +1969,8 @@ static int mpeg_decode_slice(MpegEncContext *s, int mb_y,
 s->mv[0][0][1] = s->last_mv[0][0][1];
 s->mv[1][0][0] = s->last_mv[1][0][0];
 s->mv[1][0][1] = s->last_mv[1][0][1];
+s->field_select[0][0] = (s->picture_structure - 1) & 1;
+s->field_select[1][0] = (s->picture_structure - 1) & 1;
 }
 }
 }
diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
index c913504..5624c10 100644
--- a/libavcodec/mpegvideo_motion.c
+++ b/libavcodec/mpegvideo_motion.c
@@ -239,20 +239,22 @@ void mpeg_motion_internal(MpegEncContext *s,
   int motion_y,
   int h,
   int is_mpeg12,
+  int is_16x8,
   int mb_y)
 {
 uint8_t *ptr_y, *ptr_cb, *ptr_cr;
 int dxy, uvdxy, mx, my, src_x, src_y,
-uvsrc_x, uvsrc_y, v_edge_pos;
+uvsrc_x, uvsrc_y, v_edge_pos, block_y_half;
 ptrdiff_t uvlinesize, linesize;
 
 v_edge_pos = s->v_edge_pos >> field_based;
 linesize   = s->current_picture.f->linesize[0] << field_based;
 uvlinesize = s->current_picture.f->linesize[1] << field_based;
+block_y_half = (field_based | is_16x8);
 
 dxy   = ((motion_y & 1) << 1) | (motion_x & 1);
 src_x = s->mb_x * 16 + (motion_x >> 1);
-src_y = (mb_y << (4 - field_based)) + (motion_y >> 1);
+src_y = (mb_y << (4 - block_y_half)) + (motion_y >> 1);
 
 if (!is_mpeg12 && s->out_format == FMT_H263) {
 if ((s->workaround_bugs & FF_BUG_HPEL_CHROMA) && field_based) {
@@ -260,7 +262,7 @@ void mpeg_motion_internal(MpegEncContext *s,
 my  = motion_y >> 1;
 uvdxy   = ((my & 1) << 1) | (mx & 1);
 uvsrc_x = s->mb_x * 8 + (mx >> 1);
-uvsrc_y = (mb_y << (3 - field_based)) + (my >> 1);
+uvsrc_y = (mb_y << (3 - block_y_half)) + (my >> 1);
 } else {
 uvdxy   = dxy | (motion_y & 2) | ((motion_x & 2) >> 1);
 uvsrc_x = src_x >> 1;
@@ -279,7 +281,7 @@ void mpeg_motion_internal(MpegEncContext *s,
 my  = motion_y / 2;
 uvdxy   = ((my & 1) << 1) | (mx & 1);
 uvsrc_x = s->mb_x * 8 + (mx >> 1);
-uvsrc_y = (mb_y << (3 - field_based)) + (my >> 1);
+uvsrc_y = (mb_y << (3 - block_y_half)) + (my >> 1);
 } else {
 if (s->chroma_x_shift) {
 // Chroma422
@@ -370,18 +372,18 @@ static void mpeg_motion(MpegEncContext *s,
 uint8_t *dest_y, uint8_t *dest_cb, uint8_t *dest_cr,
 int field_select, uint8_t **ref_picture,
 op_pixels_func (*pix_op)[4],
-int motion_x, int motion_y, int h, int mb_y)
+int motion_x, int motion_y, int h, int is_16x8, int 
mb_y)
 {
 #if !CONFIG_SMALL
 if (s->out_format == FMT_MPEG1)
 mpeg_motion_internal(s, dest_y, dest_cb, dest_cr, 0, 0,
  field_select, ref_picture, pix_op,
- motion_x, motion_y, h, 1, mb_y);
+ motion_x, motion_y, h, 1, is_16x8, mb_y);
 else
 #endif
 mpeg_motion_internal(s, dest_y, dest_cb, dest_cr, 0, 0,
  field_select, ref_picture, pix_op,
- motion_x, motion_y, h, 0, mb_y);
+ motion_x, motion_y, h, 0, is_16x8, mb_y);
 }
 
 static void mpeg_motion_field(MpegEncContext *s, uint8_t *dest_y,
@@ -395,12 +397,12 @@ static void mpeg_motion_field(MpegEncContext *s, uint8_t 
*dest_y,
 if (s->out_format == FMT_MPEG1)
 mpeg_motion_internal(s, dest_y, dest_cb, dest_cr, 1,
  bottom_field, field_select, ref_picture, pix_op,
- motion_x, motion_y, 

Re: [FFmpeg-devel] [PATCH] cmdutils: Do not unconditionally define functions using avdevice's API

[Derek Buitenhuis]

On 2/8/2018 4:34 PM, James Almer wrote:
> I just reverted that commit, but in any case this patch needs to be
> taken into account for when (and if) it's reapplied.

Sounds good.

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

Re: [FFmpeg-devel] [PATCH] cmdutils: Do not unconditionally define functions using avdevice's API

[James Almer]

On 2/8/2018 12:21 PM, Derek Buitenhuis wrote:
> avdevice is not a hard requiremnet for any of the fftools, and this was
> broken in cdc78058c78dfa4966758a342acd2c1f3b282c46.

I just reverted that commit, but in any case this patch needs to be
taken into account for when (and if) it's reapplied.

> 
> Fixes build with --disable-avdevice.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> I see you guys can't decide on whether to revert or not, but in
> the meantime, there is a fix for build breakage. Please don't
> reply with something like "we can't push until we finish
> bikeshedding over reverting or not".
> 
> Quite a lot of people build without avdevice.
> ---
>  fftools/cmdutils.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 0b06ccc..4f482d6 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -1281,9 +1281,11 @@ static int show_formats_devices(void *optctx, const 
> char *opt, const char *arg,
>  } } while(0)
>  
>  x(av_muxer_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS && 
> !device_only);
> -x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
>  x(av_demuxer_iterate, ifmt, muxdemuxers != SHOW_MUXERS && 
> !device_only);
> +#if CONFIG_AVDEVICE
> +x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
>  x(av_indev_iterate, ifmt, muxdemuxers != SHOW_MUXERS);
> +#endif
>  #undef x
>  if (!name)
>  break;
> 

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

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[James Almer]

On 2/8/2018 1:16 PM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 13:19, James Almer  wrote:
> 
>> On 2/8/2018 9:52 AM, wm4 wrote:
>>> On Thu, 8 Feb 2018 10:29:11 +
>>> Rostislav Pehlivanov  wrote:
>>>
 On 8 February 2018 at 01:08, Muhammad Faiz  wrote:

> On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:
>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
>>> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:
 Yes, my bad. It looked like it worked initially (was more
 worried about getting a fix out quickly), but it didnt. Try this
>> one.

 ---
  fftools/cmdutils.c | 104 +-
> ---
  1 file changed, 58 insertions(+), 46 deletions(-)
>>>
>>> I dont know if this is supposed to fix the other lists
>>> but
>>> ./ffmpeg -demuxers
>>> still returns nonsense with this patch
>>>
>>> File formats:
>>>  D. = Demuxing supported
>>>  .E = Muxing supported
>>>  --
>>>   E 3dostr  3DO STR
>>>   E 4xm 4X Technologies
>>> ...
>>> a while ago this was returned:
>>>
>>> File formats:
>>>  D. = Demuxing supported
>>>  .E = Muxing supported
>>>  --
>>>  D  3dostr  3DO STR
>>>  D  4xm 4X Technologies
>>
>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>> then. If the new API may actually get changed in the coming days once
>> some consensus is reached then there's no point trying to get this
>> working with things as is.
>
> +1.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

 -1, there's no point in reverting this and then arguing for 3 weeks with
 people who will never use the API in the first place, don't understand
>> the
 problem this patchset solved and just want to see their way be the only
>> way
 things are done.
 We should fix this patch, fix another one if there's any and it'll be
>> fine.
>>>
>>> +1 to this, but on the other hand this patch is just for code that
>>> _uses_ the new API, not the API itself.
>>
>> Precisely. This is code implementing API that may or may not change, so
>> there's no point trying to fix it if it may eventually have to be
>> reverted anyway if we decide to use a different API.
>>
>> So revert this patch now, finalize and fix the new functions, then re
>> apply it in a working way if needed afterwards.
>>
> 
> Seems reasonable. The author won't revert for some reason so could you go
> ahead and do it?

Done. Thanks.

This most assuredly does not fix the issues introduced by the other
patches that Michael reported, so those do need to be fixed, regardless
of what's done with the API.

> 
> 
>>
>>>
>>> I seriously hope nobody is arguing for reverting the API as is. It
>>> didn't please everyone, but it's good and sufficient enough, and we
>>> were in a bikeshed stalemate.
>>
>> No, the idea is to work on top of what's already committed, but do it ASAP.
>> ___
>> 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] cmdutils: fix printing of codecs

[Rostislav Pehlivanov]

On 8 February 2018 at 13:19, James Almer  wrote:

> On 2/8/2018 9:52 AM, wm4 wrote:
> > On Thu, 8 Feb 2018 10:29:11 +
> > Rostislav Pehlivanov  wrote:
> >
> >> On 8 February 2018 at 01:08, Muhammad Faiz  wrote:
> >>
> >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:
>  On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> > On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:
> >> Yes, my bad. It looked like it worked initially (was more
> >> worried about getting a fix out quickly), but it didnt. Try this
> one.
> >>
> >> ---
> >>  fftools/cmdutils.c | 104 +-
> >>> ---
> >>  1 file changed, 58 insertions(+), 46 deletions(-)
> >
> > I dont know if this is supposed to fix the other lists
> > but
> > ./ffmpeg -demuxers
> > still returns nonsense with this patch
> >
> > File formats:
> >  D. = Demuxing supported
> >  .E = Muxing supported
> >  --
> >   E 3dostr  3DO STR
> >   E 4xm 4X Technologies
> > ...
> > a while ago this was returned:
> >
> > File formats:
> >  D. = Demuxing supported
> >  .E = Muxing supported
> >  --
> >  D  3dostr  3DO STR
> >  D  4xm 4X Technologies
> 
>  Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>  then. If the new API may actually get changed in the coming days once
>  some consensus is reached then there's no point trying to get this
>  working with things as is.
> >>>
> >>> +1.
> >>> ___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>
> >>
> >> -1, there's no point in reverting this and then arguing for 3 weeks with
> >> people who will never use the API in the first place, don't understand
> the
> >> problem this patchset solved and just want to see their way be the only
> way
> >> things are done.
> >> We should fix this patch, fix another one if there's any and it'll be
> fine.
> >
> > +1 to this, but on the other hand this patch is just for code that
> > _uses_ the new API, not the API itself.
>
> Precisely. This is code implementing API that may or may not change, so
> there's no point trying to fix it if it may eventually have to be
> reverted anyway if we decide to use a different API.
>
> So revert this patch now, finalize and fix the new functions, then re
> apply it in a working way if needed afterwards.
>

Seems reasonable. The author won't revert for some reason so could you go
ahead and do it?


>
> >
> > I seriously hope nobody is arguing for reverting the API as is. It
> > didn't please everyone, but it's good and sufficient enough, and we
> > were in a bikeshed stalemate.
>
> No, the idea is to work on top of what's already committed, but do it ASAP.
> ___
> 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] cmdutils: fix printing of codecs

[James Almer]

On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 10:06, Nicolas George  wrote:
> 
>> Michael Niedermayer (2018-02-08):
>>> +1
>>
>> I agree too.
>>
>> And maybe, since we are reverting something, revert the whole series.
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
> 
> -1, I object to reverting anything.
> We should fix what we have right now. The API looks good too except some
> people here feel like they haven't bikeshedded enough and want to cause
> even more chaos.
> One bad commit and you all go screaming revert with your pitchforks instead
> of trying to fix it.

A set of seven patches was pushed before any of them got a full review
or even an ok, which unsurprisingly introduced a plethora of issues, and
all while there were discussions going about implementing the API in a
different way by more than one developer.
I do not, under any circumstance, support this strategy of pushing
unfinished things and then argue that since it's already committed it
can't be touched. I have no idea how you or anyone could support this
kind of thing.

The entire set should be reverted if only to make it clear that this is
not how development should work, yet everyone so far, including myself,
has suggested to only revert the one non-API commit that badly broke a
lot of things, then work on top of the already introduced API to
effectively finalize it, and then fix and reapply any implementation bits.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] cmdutils: Do not unconditionally define functions using avdevice's API

[Derek Buitenhuis]

avdevice is not a hard requiremnet for any of the fftools, and this was
broken in cdc78058c78dfa4966758a342acd2c1f3b282c46.

Fixes build with --disable-avdevice.

Signed-off-by: Derek Buitenhuis 
---
I see you guys can't decide on whether to revert or not, but in
the meantime, there is a fix for build breakage. Please don't
reply with something like "we can't push until we finish
bikeshedding over reverting or not".

Quite a lot of people build without avdevice.
---
 fftools/cmdutils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b06ccc..4f482d6 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1281,9 +1281,11 @@ static int show_formats_devices(void *optctx, const char 
*opt, const char *arg,
 } } while(0)
 
 x(av_muxer_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS && 
!device_only);
-x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
 x(av_demuxer_iterate, ifmt, muxdemuxers != SHOW_MUXERS && 
!device_only);
+#if CONFIG_AVDEVICE
+x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
 x(av_indev_iterate, ifmt, muxdemuxers != SHOW_MUXERS);
+#endif
 #undef x
 if (!name)
 break;
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Kieran O Leary]

Hi Jerome,

Thank you so much for this patch.

I ran a quick test and ffmpeg and ffplay seems to decode these files
just fine. I noticed that taking a short 12-bit sequence (i didn't
even realise that they were big endian actually) from the Blackmagic
Cintel Scanner turned into FFV1 version 3 in Matroska with identical
framemd5s. I did get some past duration errors in the terminal though:

Here's a few frames that I used in this example. It seems to happen at
the 16th frame..
https://www.dropbox.com/sh/imaasud6yora8me/AAAXXGIQ9w6fFfvx9qigizyVa?dl=0https://www.dropbox.com/sh/imaasud6yora8me/AAAXXGIQ9w6fFfvx9qigizyVa?dl=0

./ffmpeg -start_number 00086400 -i
first_frames/99075c82-2770-4020-a289-d191dab0b852_1_%08d.dpx -c:v ffv1
-level 3 out.mkv

ffmpeg version N-89977-gddd851f Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56.  7.100 / 56.  7.100

  libavcodec 58. 10.100 / 58. 10.100

  libavformat58.  9.100 / 58.  9.100

  libavdevice58.  1.100 / 58.  1.100

  libavfilter 7. 11.101 /  7. 11.101

  libswscale  5.  0.101 /  5.  0.101

  libswresample   3.  0.101 /  3.  0.101

Input #0, image2, from
'first_frames/99075c82-2770-4020-a289-d191dab0b852_1_%08d.dpx':

  Duration: 00:00:00.92, start: 0.00, bitrate: N/A

Stream #0:0: Video: dpx, gbrp12le, 2160x1702 [SAR 1:1 DAR
1080:851], 24 tbr, 25 tbn, 24 tbc

Stream mapping:

  Stream #0:0 -> #0:0 (dpx (native) -> ffv1 (native))

Press [q] to stop, [?] for help

[ffv1 @ 0x7fd89c013800] bits_per_raw_sample > 8, forcing range coder

Output #0, matroska, to 'out.mkv':

  Metadata:

encoder : Lavf58.9.100

Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp12le, 2160x1702
[SAR 1:1 DAR 1080:851], q=2-31, 200 kb/s, 24 fps, 1k tbn, 24 tbc

Metadata:

  encoder : Lavc58.10.100 ffv1

frame=2 fps=0.0 q=-0.0 size=   11653kB time=00:00:00.04
bitrate=2220121.7kbiframe=4 fps=3.4 q=-0.0 size=   34930kB
time=00:00:00.12 bitrate=2270993.5kbiframe=6 fps=3.4 q=-0.0 size=
 58259kB time=00:00:00.20 bitrate=2283544.4kbiframe=8 fps=3.3
q=-0.0 size=   81588kB time=00:00:00.29 bitrate=2281121.4kbiframe=
10 fps=3.3 q=-0.0 size=  104852kB
time=00:00:00.37bitrate=2284434.3kbiframe=   12 fps=3.3 q=-0.0 size=
128130kB time=00:00:00.45 bitrate=2286805.8kbiframe=   14 fps=3.3
q=-0.0 size=  151452kB time=00:00:00.54 bitrate=2284891.4kbiframe=
16 fps=3.3 q=-0.0 size=  174741kB time=00:00:00.62
bitrate=2286710.7kbiPast duration 0.639992 too large

Past duration 0.679985 too large

frame=   18 fps=3.2 q=-0.0 size=  198043kB time=00:00:00.70
bitrate=2288247.4kbiPast duration 0.719994 too large

Past duration 0.759987 too large

frame=   20 fps=3.2 q=-0.0 size=  221335kB time=00:00:00.79
bitrate=2286478.6kbiPast duration 0.75 too large

Past duration 0.839989 too large

frame=   22 fps=3.2 q=-0.0 size=  244648kB time=00:00:00.87
bitrate=2287850.0kbiPast duration 0.879997 too large

frame=   23 fps=3.1 q=-0.0 size=  256309kB time=00:00:00.91
bitrate=2287235.2kbiframe=   23 fps=3.1 q=-0.0 Lsize=  267948kB
time=00:00:00.91 bitrate=2391103.3kbits/s speed=0.123x

video:267947kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.000610%

Best,

Kieran O'Leary
IFI Irish Film Archive
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[James Almer]

On 2/8/2018 9:52 AM, wm4 wrote:
> On Thu, 8 Feb 2018 10:29:11 +
> Rostislav Pehlivanov  wrote:
> 
>> On 8 February 2018 at 01:08, Muhammad Faiz  wrote:
>>
>>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:  
 On 2/7/2018 9:32 PM, Michael Niedermayer wrote:  
> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:  
>> Yes, my bad. It looked like it worked initially (was more
>> worried about getting a fix out quickly), but it didnt. Try this one.
>>
>> ---
>>  fftools/cmdutils.c | 104 +-  
>>> ---  
>>  1 file changed, 58 insertions(+), 46 deletions(-)  
>
> I dont know if this is supposed to fix the other lists
> but
> ./ffmpeg -demuxers
> still returns nonsense with this patch
>
> File formats:
>  D. = Demuxing supported
>  .E = Muxing supported
>  --
>   E 3dostr  3DO STR
>   E 4xm 4X Technologies
> ...
> a while ago this was returned:
>
> File formats:
>  D. = Demuxing supported
>  .E = Muxing supported
>  --
>  D  3dostr  3DO STR
>  D  4xm 4X Technologies  

 Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
 then. If the new API may actually get changed in the coming days once
 some consensus is reached then there's no point trying to get this
 working with things as is.  
>>>
>>> +1.
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>  
>>
>> -1, there's no point in reverting this and then arguing for 3 weeks with
>> people who will never use the API in the first place, don't understand the
>> problem this patchset solved and just want to see their way be the only way
>> things are done.
>> We should fix this patch, fix another one if there's any and it'll be fine.
> 
> +1 to this, but on the other hand this patch is just for code that
> _uses_ the new API, not the API itself.

Precisely. This is code implementing API that may or may not change, so
there's no point trying to fix it if it may eventually have to be
reverted anyway if we decide to use a different API.

So revert this patch now, finalize and fix the new functions, then re
apply it in a working way if needed afterwards.

> 
> I seriously hope nobody is arguing for reverting the API as is. It
> didn't please everyone, but it's good and sufficient enough, and we
> were in a bikeshed stalemate.

No, the idea is to work on top of what's already committed, but do it ASAP.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[wm4]

On Thu, 8 Feb 2018 12:03:22 +
Rostislav Pehlivanov  wrote:

> On 8 February 2018 at 10:35, Nicolas George  wrote:
> 
> > Rostislav Pehlivanov (2018-02-08):  
> > > We should fix what we have right now. The API looks good too except some
> > > people here feel like they haven't bikeshedded enough and want to cause
> > > even more chaos.  
> >
> > Do you realize that sentence accuses Michael, Muhammad and me of
> > pursuing a personal power trip instead of seeking the good of the
> > project? Do you realize how incredibly insulting you are?
> >
> > Regards,
> >
> > --
> >   Nicolas George
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >  
> No, I was referring to you and you alone.
> You've been more insulting towards the people who do hard work and submit
> patches by going out of your way to block them and saying "The burden of
> proof is on you!". And by saying this you're basically not even wanting to
> review anything - you'd rather be spoonfed some facts than look at the
> code, figure out what it does, what it changes and seeing whether it's
> doing what its meant to do or not.
> If you want to be taken seriously and not be seen as someone as insulting
> as you think I was here then you should provide constructive criticism, use
> quotes, provide some information where you think there's an issue and
> finally propose an alternative. So far you've only done "I don't like this
> API and I can't be convinced otherwise!" and act surprised when your
> rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all
> I just said and michaelni provided objective testing, so don't even compare
> yourself to them.
> Instead, why don't you send a patch or even a WIP of what you think ought
> to be done to the API?

You can add that his attitude sometimes leads to worse results too
(instead of better ones, as he argues). Like the UDP EOF change, that
ended in changing the libavformat API away from POSIX-like semantics in
a way that caused tons of bugs (and some are still unfixed). Now I
don't want to insult Nicolas or make him look incompetent in any way,
but this is an attitude problem that needs to be fixed somehow. (I know
he'll feel insulted by these words anyway - nothing you can do I guess.)

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

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[wm4]

On Thu, 8 Feb 2018 10:29:11 +
Rostislav Pehlivanov  wrote:

> On 8 February 2018 at 01:08, Muhammad Faiz  wrote:
> 
> > On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:  
> > > On 2/7/2018 9:32 PM, Michael Niedermayer wrote:  
> > >> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:  
> > >>> Yes, my bad. It looked like it worked initially (was more
> > >>> worried about getting a fix out quickly), but it didnt. Try this one.
> > >>>
> > >>> ---
> > >>>  fftools/cmdutils.c | 104 +-  
> > ---  
> > >>>  1 file changed, 58 insertions(+), 46 deletions(-)  
> > >>
> > >> I dont know if this is supposed to fix the other lists
> > >> but
> > >> ./ffmpeg -demuxers
> > >> still returns nonsense with this patch
> > >>
> > >> File formats:
> > >>  D. = Demuxing supported
> > >>  .E = Muxing supported
> > >>  --
> > >>   E 3dostr  3DO STR
> > >>   E 4xm 4X Technologies
> > >> ...
> > >> a while ago this was returned:
> > >>
> > >> File formats:
> > >>  D. = Demuxing supported
> > >>  .E = Muxing supported
> > >>  --
> > >>  D  3dostr  3DO STR
> > >>  D  4xm 4X Technologies  
> > >
> > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> > > then. If the new API may actually get changed in the coming days once
> > > some consensus is reached then there's no point trying to get this
> > > working with things as is.  
> >
> > +1.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> -1, there's no point in reverting this and then arguing for 3 weeks with
> people who will never use the API in the first place, don't understand the
> problem this patchset solved and just want to see their way be the only way
> things are done.
> We should fix this patch, fix another one if there's any and it'll be fine.

+1 to this, but on the other hand this patch is just for code that
_uses_ the new API, not the API itself.

I seriously hope nobody is arguing for reverting the API as is. It
didn't please everyone, but it's good and sufficient enough, and we
were in a bikeshed stalemate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/avio: NULL check for URLContext in ffurl_write().

[Nicolas George]

Patagar, Ravindra (2018-02-08):
> We observed NULL pointer during HLS/DASH streaming when we simulated
> network congestion and disconnects with persistent HTTP connection. 
> That is why added this check to handle segmentation fault.

Please investigate further: find who is calling this function with NULL,
since they should not be doing it.

> On 2/7/18, 4:52 PM, "wm4"  wrote:

Also, please remember not to top-quote on this list.

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] [PATCH] libavformat/avio: NULL check for URLContext in ffurl_write().

[Patagar, Ravindra]

Hi,
We observed NULL pointer during HLS/DASH streaming when we simulated network 
congestion and disconnects with persistent HTTP connection. 
That is why added this check to handle segmentation fault.

On 2/7/18, 4:52 PM, "wm4"  wrote:

On Wed,  7 Feb 2018 08:57:26 +0530
rpata...@akamai.com wrote:

> From: Ravindra 
> 
> Signed-off-by: Ravindra 
> ---
>  libavformat/avio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 63e8287..18e58ae 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -420,7 +420,7 @@ int ffurl_read_complete(URLContext *h, unsigned char 
*buf, int size)
>  
>  int ffurl_write(URLContext *h, const unsigned char *buf, int size)
>  {
> -if (!(h->flags & AVIO_FLAG_WRITE))
> +if (!h || !(h->flags & AVIO_FLAG_WRITE))
>  return AVERROR(EIO);
>  /* avoid sending too big packets */
>  if (h->max_packet_size && size > h->max_packet_size)

Why would this ever be NULL? It looks like a caller error to me, not
something the function should handle.
___
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] cmdutils: fix printing of codecs

[James Almer]

On 2/8/2018 7:29 AM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 01:08, Muhammad Faiz  wrote:
> 
>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:
>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
 On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:
> Yes, my bad. It looked like it worked initially (was more
> worried about getting a fix out quickly), but it didnt. Try this one.
>
> ---
>  fftools/cmdutils.c | 104 +-
>> ---
>  1 file changed, 58 insertions(+), 46 deletions(-)

 I dont know if this is supposed to fix the other lists
 but
 ./ffmpeg -demuxers
 still returns nonsense with this patch

 File formats:
  D. = Demuxing supported
  .E = Muxing supported
  --
   E 3dostr  3DO STR
   E 4xm 4X Technologies
 ...
 a while ago this was returned:

 File formats:
  D. = Demuxing supported
  .E = Muxing supported
  --
  D  3dostr  3DO STR
  D  4xm 4X Technologies
>>>
>>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>>> then. If the new API may actually get changed in the coming days once
>>> some consensus is reached then there's no point trying to get this
>>> working with things as is.
>>
>> +1.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> -1, there's no point in reverting this and then arguing for 3 weeks with
> people who will never use the API in the first place, don't understand the
> problem this patchset solved and just want to see their way be the only way
> things are done.
> We should fix this patch, fix another one if there's any and it'll be fine.

So you fix it now, then after discussing, we decide that we prefer to
keep the _next style of API instead of _iterate. What happens then? This
patch plus your fix will get reverted as they don't apply anymore.

So i insist, revert this patch, finalize (and fix the issues in) the
actual API, then start implementing it across the codebase.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Rostislav Pehlivanov]

On 8 February 2018 at 10:35, Nicolas George  wrote:

> Rostislav Pehlivanov (2018-02-08):
> > We should fix what we have right now. The API looks good too except some
> > people here feel like they haven't bikeshedded enough and want to cause
> > even more chaos.
>
> Do you realize that sentence accuses Michael, Muhammad and me of
> pursuing a personal power trip instead of seeking the good of the
> project? Do you realize how incredibly insulting you are?
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
No, I was referring to you and you alone.
You've been more insulting towards the people who do hard work and submit
patches by going out of your way to block them and saying "The burden of
proof is on you!". And by saying this you're basically not even wanting to
review anything - you'd rather be spoonfed some facts than look at the
code, figure out what it does, what it changes and seeing whether it's
doing what its meant to do or not.
If you want to be taken seriously and not be seen as someone as insulting
as you think I was here then you should provide constructive criticism, use
quotes, provide some information where you think there's an issue and
finally propose an alternative. So far you've only done "I don't like this
API and I can't be convinced otherwise!" and act surprised when your
rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all
I just said and michaelni provided objective testing, so don't even compare
yourself to them.
Instead, why don't you send a patch or even a WIP of what you think ought
to be done to the API?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] tinterlace license

[Vasile Toncu]

Shall I start a new thread for the patch with the new filter, or can I 
use this one?


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

Re: [FFmpeg-devel] tinterlace license

[Vasile Toncu]

 From the git history I figured out that they wrote a quite big part of
tinterlace. Other parts are written mainly by the maintainers of ffmpeg
project.

Look at the first commit:

lavfi: port tinterlace filter from MPlayer

That means you need to look at the MPlayer history too to know all the
authors.


Yes, you are right.

It is Mr. Michael Zucchi  who holds the authorship 
for tinterlace in MPlayer. The ximian company is dead/acquired since 2003.


I'll try to get in touch with Michael.

Thanks,
-Vasile Toncu

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

Re: [FFmpeg-devel] tinterlace license

[Nicolas George]

Vasile Toncu (2018-02-08):
> From the git history I figured out that they wrote a quite big part of
> tinterlace. Other parts are written mainly by the maintainers of ffmpeg
> project.

Look at the first commit:

lavfi: port tinterlace filter from MPlayer

That means you need to look at the MPlayer history too to know all the
authors.

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] tinterlace license

[Vasile Toncu]

Hello,



Then the best solution - imo! - is that you send a patch that adds your
new filter that uses the existing asm optimizations if FFmpeg was
configured for GPL.
First send one patch only adding a new filter (with a new name) to
get some technical review


I'll send a patch with my new filter, to have some review.


One possible procedure for a change that can actually be committed
is that you send two patches:
One that removes the existing filter (but not the asm code) and one
that adds your new filter.


If everything goes well, I'll go on with this step too.

At this moment, two people agreed to change the license of the 
tinterlace -  Thomas Mundt and Stefano Sabatini.
From the git history I figured out that they wrote a quite big part of 
tinterlace. Other parts are written mainly by the maintainers of ffmpeg 
project.


That being said, will it be possible to change the tinterlace to LGPL?



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

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Nicolas George]

Rostislav Pehlivanov (2018-02-08):
> We should fix what we have right now. The API looks good too except some
> people here feel like they haven't bikeshedded enough and want to cause
> even more chaos.

Do you realize that sentence accuses Michael, Muhammad and me of
pursuing a personal power trip instead of seeking the good of the
project? Do you realize how incredibly insulting you are?

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] [PATCH] cmdutils: fix printing of codecs

[Rostislav Pehlivanov]

On 8 February 2018 at 10:06, Nicolas George  wrote:

> Michael Niedermayer (2018-02-08):
> > +1
>
> I agree too.
>
> And maybe, since we are reverting something, revert the whole series.
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>

-1, I object to reverting anything.
We should fix what we have right now. The API looks good too except some
people here feel like they haven't bikeshedded enough and want to cause
even more chaos.
One bad commit and you all go screaming revert with your pitchforks instead
of trying to fix it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Jerome Martinez]

Currently RGB and RGBA 12-bit are supported by DPX decoder only if 
component values are padded (packing "Filled to 32-bit words, method A").
This patch adds decoding of RGB and RGBA 12-bit with no padding (packing 
"Packed into 32-bit words").


As I have no file with line boundaries not aligned on 32-bit, I can not 
have good tests about the stride computing (so code about non aligned 
boundaries is theory) so I preferred to limit risks by decoding only if 
line boundaries are aligned on 32-bit words:
- 8 pixels for RGB (8 pixels x 3 components x 12 bits = 288 bits = 9 x 
32-bit words)

- 2 pixels for RGBA (2 pixels x 4 components x 12 bits = 3 x 32-bit words)

I think Little Endian parsing is fine thanks to the generic code about 
Big vs Little endian but I have no Little Endian test file so I also 
limited the decoding to Big Endian files.


Would be happy to check with cases I was not able to check if someone 
provides files.


I kept "Packing to 16bit required\n" message but interested in any 
suggestion about a better wording due to exceptions.


My test files:
https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGB_12_Packed_BE

Regression tests done on 12-bit content "Filled to 32-bit words, method 
A" in:

https://samples.ffmpeg.org/image-samples/dpx_samples.zip

From bf95371e3964e198e22dc545fc75706dedf9029b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Thu, 8 Feb 2018 09:22:08 +0100
Subject: [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

Limited to widths multiple of 8 (RGB) and 2 (RGBA) due to lack of test files 
for such corner case
---
 libavcodec/dpx.c | 70 +---
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 1aa2cbd1c8..aaacd243c9 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -65,6 +65,38 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t * 
lbuf,
 return *lbuf & 0x3FF;
 }
 
+static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf,
+  int * n_datum, int is_big)
+{
+if (*n_datum)
+(*n_datum)--;
+else {
+*lbuf = read32(ptr, is_big);
+*n_datum = 7;
+}
+
+switch (*n_datum){
+case 7: return *lbuf & 0xFFF;
+case 6: return (*lbuf >> 12) & 0xFFF;
+case 5: {
+uint32_t c = *lbuf >> 24;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 8;
+return c & 0xFFF;
+}
+case 4: return (*lbuf >> 4) & 0xFFF;
+case 3: return (*lbuf >> 16) & 0xFFF;
+case 2: {
+uint32_t c = *lbuf >> 28;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 4;
+return c & 0xFFF;
+}
+case 1: return (*lbuf >> 8) & 0xFFF;
+default: return *lbuf >> 20;
+}
+}
+
 static int decode_frame(AVCodecContext *avctx,
 void *data,
 int *got_frame,
@@ -201,10 +233,29 @@ static int decode_frame(AVCodecContext *avctx,
 break;
 case 12:
 if (!packing) {
-av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
-return -1;
+int tested = 0;
+if (endian && descriptor == 50 && (avctx->width%8) == 0) // Little 
endian and widths not a multiple of 8 need tests
+tested = 1;
+if (endian && descriptor == 51 && (avctx->width%2) == 0) // Little 
endian and widths not a multiple of 2 need tests
+tested = 1;
+if (!tested) {
+av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
+return -1;
+}
+}
+stride = avctx->width * elements;
+if (packing)
+stride *= 2;
+else {
+stride *= 3; // 12 bits are 1.5 byte so multiplied by 3 then 
divided by 2
+if (stride % 8) {
+// Align to 32-bit boundaries (not tested)
+stride /= 8;
+stride++;
+stride *= 8;
+}
+stride /= 2;
 }
-stride = 2 * avctx->width * elements;
 break;
 case 16:
 stride = 2 * avctx->width * elements;
@@ -349,6 +400,7 @@ static int decode_frame(AVCodecContext *avctx,
 (uint16_t*)ptr[2],
 (uint16_t*)ptr[3]};
 for (y = 0; y < avctx->width; y++) {
+if (packing) {
 if (elements >= 3)
 *dst[2]++ = read16(, endian) >> 4;
 *dst[0] = read16(, endian) >> 4;
@@ -357,6 +409,18 @@ static int decode_frame(AVCodecContext *avctx,
 *dst[1]++ = read16(, endian) >> 4;
 if (elements == 4)
 *dst[3]++ = read16(, endian) >> 4;
+}
+

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Rostislav Pehlivanov]

On 8 February 2018 at 01:08, Muhammad Faiz  wrote:

> On Thu, Feb 8, 2018 at 7:35 AM, James Almer  wrote:
> > On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> >> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote:
> >>> Yes, my bad. It looked like it worked initially (was more
> >>> worried about getting a fix out quickly), but it didnt. Try this one.
> >>>
> >>> ---
> >>>  fftools/cmdutils.c | 104 +-
> ---
> >>>  1 file changed, 58 insertions(+), 46 deletions(-)
> >>
> >> I dont know if this is supposed to fix the other lists
> >> but
> >> ./ffmpeg -demuxers
> >> still returns nonsense with this patch
> >>
> >> File formats:
> >>  D. = Demuxing supported
> >>  .E = Muxing supported
> >>  --
> >>   E 3dostr  3DO STR
> >>   E 4xm 4X Technologies
> >> ...
> >> a while ago this was returned:
> >>
> >> File formats:
> >>  D. = Demuxing supported
> >>  .E = Muxing supported
> >>  --
> >>  D  3dostr  3DO STR
> >>  D  4xm 4X Technologies
> >
> > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> > then. If the new API may actually get changed in the coming days once
> > some consensus is reached then there's no point trying to get this
> > working with things as is.
>
> +1.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

-1, there's no point in reverting this and then arguing for 3 weeks with
people who will never use the API in the first place, don't understand the
problem this patchset solved and just want to see their way be the only way
things are done.
We should fix this patch, fix another one if there's any and it'll be fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Nicolas George]

Michael Niedermayer (2018-02-08):
> +1

I agree too.

And maybe, since we are reverting something, revert the whole series.

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] [PATCH 3/4] avformat/mpegenc - accept PCM_DVD streams

[Gyan Doshi]

On 2/3/2018 3:59 AM, Michael Niedermayer wrote:


PCM_S16BE stream packets in MPEG-PS have a 3-byte header
and recognized as PCM_DVD by the demuxer which prevents
their proper remuxing in MPEG-1/2 PS.


its probably a good idea to add a fate test for this too.
(could be in a seperate patch)


What type of test do you recommend?
We'll need to check the decoded packets, so framecrc?


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

Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

[Nablet Developer]

On 1/31/2018 4:11 AM, Nablet Developer wrote:

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Nablet Developer 
---

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