[FFmpeg-devel] decklink 24/32 bit question

[Douglas Marsh]

After digging around in places, made the following changes:

dx@x299:~/git/ffmpeg$ git diff
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 3ce2cab..afd255f 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -937,7 +937,7 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)

 goto error;
 }
 st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id= AV_CODEC_ID_PCM_S16LE;
+st->codecpar->codec_id= AV_CODEC_ID_PCM_S32LE;
 st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
 st->codecpar->channels= cctx->audio_channels;
 avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
@@ -1028,7 +1028,7 @@ av_cold int 
ff_decklink_read_header(AVFormatContext *avctx)

 }

 av_log(avctx, AV_LOG_VERBOSE, "Using %d input audio channels\n", 
ctx->audio_st->codecpar->channels);
-result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType16bitInteger, ctx->audio_st->codecpar->channels);
+result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz, 
bmdAudioSampleType32bitInteger, ctx->audio_st->codecpar->channels);


 if (result != S_OK) {
 av_log(avctx, AV_LOG_ERROR, "Cannot enable audio input\n");


It doesn't work (the audio capture is close but wrong), but believe it 
is a step in the correct direction. Anybody have a clue? Saw several 
names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
Fliegl, Rafaël Carré and Akamai Technologies Inc.


Thanks in advance!

--Doug (dx9s)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFMPEG Quantization

[shailender]

Hello,


I am an expert in the JPEG files processing. I am looking for mechanism where i 
can set customised quantization table for different frames. I understand there 
is an option for bitrate in FFMPEG. However, i am exploring  the option to use 
customized quantization table. Is it feasible in FFMPEG


Thanks

Shailender Jain


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

[FFmpeg-devel] [PATCH] Videotoolbox encoder: Enable Videotoolbox encoder

[pon pon]

I reported that Videotoolbox encoder isn't enabled since commit
9ef5a2f5f30bdc4ac86275ae4b4708ab4681b21

in ticket 6702.
This is a simple patch correcting it.

diff --git a/configure b/configure
index ae0eddac6c..8922303c89 100755
--- a/configure
+++ b/configure
@@ -1652,6 +1652,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
 vda
 vdpau
 videotoolbox
+videotoolbox_encoder
 v4l2_m2m
 xvmc
 "

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

[FFmpeg-devel] decklink rgb10 and 600.0fps ?!

[Douglas Marsh]

Has anybody tested and reported back success (no issues) with the recent 
decklink and rgb support added? In particular rgb10 mode.


I've have good luck in capturing from my 'DeckLink Studio 4K' only when 
RGB (can't seem to capture YUV, perhaps the HDMI data is only RGB -- 
still need to do testing with known YUV over HDMI as well)


-raw_format argb (and bgra) work and fairly well I will add!

-raw_format rgb10 does wierd things

(Sorry in advance for the long post, took most of the information out 
because I was told to not be s long)


dx@x299:~/storage/temp$ ffmpeg10 -format_code Hp59 -f decklink 
-video_input hdmi -audio_input embedded -raw_format rgb10 -i 'DeckLink 
Studio 4K' -acodec copy -vcodec copy -to 4 raw.avi

[...]

dx@x299:~/storage/temp$ mediainfo raw.avi
General
Complete name: raw.avi
Format   : AVI
Format/Info  : Audio Video Interleave
Format profile   : OpenDML
File size: 1.85 GiB
Duration : 4 s 4 ms
Overall bit rate : 3 979 Mb/s
Writing application  : Lavf57.82.102

Video
ID   : 0
Format   : YUV
Codec ID : R210
Codec ID/Info: BlackMagic YUV (Quick Time)
Duration : 4 s 3 ms
Bit rate : 3 978 Mb/s
Width: 1 920 pixels
Height   : 1 080 pixels
Display aspect ratio : 16:9
Frame rate   : 600.000 FPS
Color space  : YUV
Compression mode : Lossless
Bits/(Pixel*Frame)   : 3.198
Stream size  : 1.85 GiB (100%)

Audio
ID   : 1
Format   : PCM
Format settings  : Little / Signed
Format settings, Endianness  : Little
Format settings, Sign: Signed
Codec ID : 1
Duration : 4 s 4 ms
Bit rate mode: Constant
Bit rate : 1 536 kb/s
Channel(s)   : 2 channels
Sampling rate: 48.0 kHz
Bit depth: 16 bits
Stream size  : 751 KiB (0%)
Alignment: Aligned on interleaves
Interleave, duration : 17  ms (10.01 video frames)

dx@x299:~/storage/temp$ ffmpeg10 -i raw.avi -c:a copy -c:v libx264 -crf 
0 -preset ultrafast fromrawavi.mov
ffmpeg version N-87614-g3d4f8b9-dx9s-decklink Copyright (c) 2000-2017 
the FFmpeg developers

[...]

dx@x299:~/storage/temp$ mediainfo fromrawavi.mov
General
Complete name: fromrawavi.mov
Format   : MPEG-4
Format profile   : QuickTime
Codec ID : qt   .02 (qt  )
File size: 4.08 MiB
Duration : 4 s 4 ms
Overall bit rate : 8 548 kb/s
Writing application  : Lavf57.82.102

Video
ID   : 1
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : High 4:4:4 Predictive@L5.2
Format settings  : 1 Ref Frames
Format settings, CABAC   : No
Format settings, RefFrames   : 1 frame
Codec ID : avc1
Codec ID/Info: Advanced Video Coding
Duration : 4 s 2 ms
Bit rate : 6 987 kb/s
Width: 1 920 pixels
Height   : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode  : Constant
Frame rate   : 600.000 FPS
Chroma subsampling   : 4:4:4
Bit depth: 10 bits
Scan type: Progressive
Bits/(Pixel*Frame)   : 0.006
Stream size  : 3.33 MiB (82%)
Writing library  : x264 core 148 r2643 5c65704
Encoding settings: cabac=0 / ref=1 / 
deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / 
psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 
8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=6 / 
threads=24 / lookahead_threads=4 / 

Re: [FFmpeg-devel] [PATCH 5/5] ffmpeg: send EOF pts to filters.

[Thomas Mundt]

Hi Nicolas,

2017-09-07 10:59 GMT+02:00 Nicolas George :

> Signed-off-by: Nicolas George 
> ---
>  ffmpeg.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index b95addd277..1d248bc269 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2223,14 +2223,14 @@ static int ifilter_send_frame(InputFilter
> *ifilter, AVFrame *frame)
>  return 0;
>  }
>
> -static int ifilter_send_eof(InputFilter *ifilter)
> +static int ifilter_send_eof(InputFilter *ifilter, int64_t pts)
>  {
>  int i, j, ret;
>
>  ifilter->eof = 1;
>
>  if (ifilter->filter) {
> -ret = av_buffersrc_add_frame_flags(ifilter->filter, NULL,
> AV_BUFFERSRC_FLAG_PUSH);
> +ret = av_buffersrc_close(ifilter->filter, pts,
> AV_BUFFERSRC_FLAG_PUSH);
>  if (ret < 0)
>  return ret;
>  } else {
> @@ -2581,8 +2581,12 @@ out:
>  static int send_filter_eof(InputStream *ist)
>  {
>  int i, ret;
> +/* TODO keep pts also in stream time base to avoid converting back */
> +int64_t pts = av_rescale_q_rnd(ist->pts, AV_TIME_BASE_Q,
> ist->st->time_base,
> +   AV_ROUND_NEAR_INF |
> AV_ROUND_PASS_MINMAX);
> +
>  for (i = 0; i < ist->nb_filters; i++) {
> -ret = ifilter_send_eof(ist->filters[i]);
> +ret = ifilter_send_eof(ist->filters[i], pts);
>  if (ret < 0)
>  return ret;
>  }
>

The sended pts always seems to refer to the input time base.
When a filter changes the time base, the EOF pts becomes wrong for
subsequent filters in the chain.
E.g. when using vf_fps behind vf_yadif=1 with interlaced input, the sended
EOF pts is only half of the expected pts.

I tried to find a solution, but without success.
Do you have an idea?

Regards,
Thomas



Virenfrei.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_template: Clear tns present flag on error

[Michael Niedermayer]

On Sat, Sep 30, 2017 at 06:54:05PM +0200, Michael Niedermayer wrote:
> Fixes: 3444/clusterfuzz-testcase-minimized-6270352105668608
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacdec_template.c | 44 
> 
>  1 file changed, 28 insertions(+), 16 deletions(-)

pathset applied

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH] mpegdec: fix redundant dummy frames issue of interlaced clips

[Michael Niedermayer]

On Sat, Sep 30, 2017 at 11:22:57AM +0800, Zhong Li wrote:
> It is to fix https://trac.ffmpeg.org/ticket/6677. Actucally it is a
> regression of commit 99e07a4453732058df90885f80b3db3b4f37cb3c which
> always inserts a dummy frame when decode the first key field picture.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/mpegvideo.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

applied

please add a fate test

thanks

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

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: Fix definition of MIDDLE_BITS

[Michael Niedermayer]

On Tue, Oct 03, 2017 at 03:50:37PM +0200, Ingo Brückl wrote:
> The number of bits from bit #m to #n is n - m plus 1.
> 
> Signed-off-by: Ingo Brückl 
> ---
>  libavformat/mp3dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patch

thanks

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH v2] doc: add mailing list faq

[Lou Logan]

On Tue, Oct 3, 2017, at 02:23 PM, Lou Logan wrote:
> On Tue, Oct 3, 2017, at 12:08 AM, Carl Eugen Hoyos wrote:
> > Gmane does not work for a long time.
> 
> Removed.
> 
> > The reason I also use "uncut" is that "complete" was misunderstood
> > by some iirc.
> 
> Added.

Pushed with some additional minor edits.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/blockdsp : add AVX version

[James Almer]

On 10/3/2017 4:47 PM, Martin Vignali wrote:
> Hello,
> 
> 
>> I used GCC 7.2. clear_blocks_mmx is slower than c for me as well, but
>> not the rest.
>> Your compiler seems to have done a much better job than mine. Is it
>> Clang? Does it somehow have vectorization enabled perhaps? Because
>> that's not supposed to happen.
>>
>>
> Yes it's Clang 8.1
> 
> I put the clear_blocks_c function, in a file and run
> clang -S -O1 test_asm_gen.c
> 
> the asm result is
> .section__TEXT,__text,regular,pure_instructions
> .macosx_version_min 10, 12
> .globl_clear_blocks_c
> .p2align4, 0x90
> _clear_blocks_c:## @clear_blocks_c
> .cfi_startproc
> ## BB#0:
> pushq%rbp
> Ltmp0:
> .cfi_def_cfa_offset 16
> Ltmp1:
> .cfi_offset %rbp, -16
> movq%rsp, %rbp
> Ltmp2:
> .cfi_def_cfa_register %rbp
> movl$768, %esi  ## imm = 0x300
> callq___bzero
> popq%rbp
> retq
> .cfi_endproc
> 
> 
> .subsections_via_symbols
> 
> Seems like an optimized function is call for clear_blocks_c

Yeah, the c version uses memset. Guess clang's implementation is good.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-10-04 1:00 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 03, 2017 at 12:02:23AM +0200, Carl Eugen Hoyos wrote:
>> 2017-10-02 23:47 GMT+02:00 Carl Eugen Hoyos :
>> > 2017-10-02 23:02 GMT+02:00 Michael Niedermayer :
>> >> On Sun, Oct 01, 2017 at 06:23:50PM +0200, Carl Eugen Hoyos wrote:
>> >>> 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :
>> >>>
>> >>> > The existing amr demuxer does not allow reading streams,
>> >>> > it requires the 3GPP-conforming file header.
>> >>> > Attached patch allows reading amrnb and amrwb from (live)
>> >>> > streams, fixes ticket #6678.
>> >>>
>> >>> New patch with auto-detection attached, passes probecheck.
>> >>>
>> >>> Please comment, Carl Eugen
>> >>
>> >> breaks mingw64
>> >> libavformat/aviobu
>> >> In file included from src/libavformat/amrnb.c:26:0:
>> >> src/libavcodec/amrnbdata.h:50:5: error: expected identifier before ‘(’ 
>> >> token
>> >>  NO_DATA = 15  ///< no transmission
>> >>  ^
>> >> make: *** [libavformat/amrnb.o] Error 1
>> >> make: *** Waiting for unfinished jobs
>> >> STRIP   libavfilter/x86/vf_yadif.o
>> >> STRIP   libavfilter/x86/vf_removegrain.o
>> >> In file included from src/libavformat/amrwb.c:26:0:
>> >> src/libavcodec/amrwbdata.h:64:5: error: expected identifier before ‘(’ 
>> >> token
>> >>  NO_DATA///< no transmission
>> >>  ^
>> >> make: *** [libavformat/amrwb.o] Error 1
>> >
>> > The errors are apparently caused by the following definitions in a mingw 
>> > header:
>> > #define WSANO_DATA (WSABASEERR + 1004)
>> > #define NO_DATA WSANO_DATA
>>
>> Attached is one possible solution.
>>
>> Please comment, Carl Eugen
>
>>  amrnbdata.h |2 +-
>>  amrnbdec.c  |5 +++--
>>  amrwbdata.h |2 +-
>>  3 files changed, 5 insertions(+), 4 deletions(-)
>> eb545b4abc7d2849db7be8f78abba8a1626a2ba7  
>> 0001-lavc-amr-Rename-NO_DATA-as-AMR_NO_DATA.patch
>> From 317dbccb46a02ac997c8826ef4c31b787fc8ce47 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Tue, 3 Oct 2017 00:00:29 +0200
>> Subject: [PATCH] lavc/amr: Rename NO_DATA as AMR_NO_DATA.
>>
>> mingw64 defines NO_DATA in wsa_errnos.h
>> ---
>>  libavcodec/amrnbdata.h |2 +-
>>  libavcodec/amrnbdec.c  |5 +++--
>>  libavcodec/amrwbdata.h |2 +-
>>  3 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/amrnbdata.h b/libavcodec/amrnbdata.h
>> index 435fd99..b38f955 100644
>> --- a/libavcodec/amrnbdata.h
>> +++ b/libavcodec/amrnbdata.h
>> @@ -47,7 +47,7 @@ enum Mode {
>>  MODE_12k2,///< 12.2 kbit/s
>>  MODE_DTX, ///< silent frame
>>  N_MODES,  ///< number of modes
>> -NO_DATA = 15  ///< no transmission
>> +AMR_NO_DATA = 15  ///< no transmission
>>  };
>>
>>  #define LP_FILTER_ORDER 10///< linear predictive coding filter order
>> diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
>> index ea299ac..ae5be5d 100644
>> --- a/libavcodec/amrnbdec.c
>> +++ b/libavcodec/amrnbdec.c
>> @@ -214,8 +214,9 @@ static enum Mode unpack_bitstream(AMRContext *p, const 
>> uint8_t *buf,
>>  p->bad_frame_indicator = (buf[0] & 0x4) != 0x4; // quality bit
>>
>>  if (mode >= N_MODES || buf_size < frame_sizes_nb[mode] + 1) {
>> -return NO_DATA;
>> +return AMR_NO_DATA;
>>  }
>
>> +printf("mode: %d, size: %ld, bitmaps_per_mode: %d \n", mode, 
>> sizeof(AMRNBFrame), *amr_unpacking_bitmaps_per_mode[mode]);
>
> you missed this line in the patch

(Which crashed the decoder.)

Sorry, fixed patch attached.

Carl Eugen
From 317dbccb46a02ac997c8826ef4c31b787fc8ce47 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 3 Oct 2017 00:00:29 +0200
Subject: [PATCH] lavc/amr: Rename NO_DATA as AMR_NO_DATA.

mingw64 defines NO_DATA in wsa_errnos.h
---
 libavcodec/amrnbdata.h |2 +-
 libavcodec/amrnbdec.c  |5 +++--
 libavcodec/amrwbdata.h |2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/amrnbdata.h b/libavcodec/amrnbdata.h
index 435fd99..b38f955 100644
--- a/libavcodec/amrnbdata.h
+++ b/libavcodec/amrnbdata.h
@@ -47,7 +47,7 @@ enum Mode {
 MODE_12k2,///< 12.2 kbit/s
 MODE_DTX, ///< silent frame
 N_MODES,  ///< number of modes
-NO_DATA = 15  ///< no transmission
+AMR_NO_DATA = 15  ///< no transmission
 };
 
 #define LP_FILTER_ORDER 10///< linear predictive coding filter order
diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
index ea299ac..ae5be5d 100644
--- a/libavcodec/amrnbdec.c
+++ b/libavcodec/amrnbdec.c
@@ -214,7 +214,7 @@ static enum Mode unpack_bitstream(AMRContext *p, const uint8_t *buf,
 

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Michael Niedermayer]

On Tue, Oct 03, 2017 at 12:02:23AM +0200, Carl Eugen Hoyos wrote:
> 2017-10-02 23:47 GMT+02:00 Carl Eugen Hoyos :
> > 2017-10-02 23:02 GMT+02:00 Michael Niedermayer :
> >> On Sun, Oct 01, 2017 at 06:23:50PM +0200, Carl Eugen Hoyos wrote:
> >>> 2017-09-27 18:08 GMT+02:00 Carl Eugen Hoyos :
> >>>
> >>> > The existing amr demuxer does not allow reading streams,
> >>> > it requires the 3GPP-conforming file header.
> >>> > Attached patch allows reading amrnb and amrwb from (live)
> >>> > streams, fixes ticket #6678.
> >>>
> >>> New patch with auto-detection attached, passes probecheck.
> >>>
> >>> Please comment, Carl Eugen
> >>
> >> breaks mingw64
> >> libavformat/aviobu
> >> In file included from src/libavformat/amrnb.c:26:0:
> >> src/libavcodec/amrnbdata.h:50:5: error: expected identifier before ‘(’ 
> >> token
> >>  NO_DATA = 15  ///< no transmission
> >>  ^
> >> make: *** [libavformat/amrnb.o] Error 1
> >> make: *** Waiting for unfinished jobs
> >> STRIP   libavfilter/x86/vf_yadif.o
> >> STRIP   libavfilter/x86/vf_removegrain.o
> >> In file included from src/libavformat/amrwb.c:26:0:
> >> src/libavcodec/amrwbdata.h:64:5: error: expected identifier before ‘(’ 
> >> token
> >>  NO_DATA///< no transmission
> >>  ^
> >> make: *** [libavformat/amrwb.o] Error 1
> >
> > The errors are apparently caused by the following definitions in a mingw 
> > header:
> > #define WSANO_DATA (WSABASEERR + 1004)
> > #define NO_DATA WSANO_DATA
> 
> Attached is one possible solution.
> 
> Please comment, Carl Eugen

>  amrnbdata.h |2 +-
>  amrnbdec.c  |5 +++--
>  amrwbdata.h |2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> eb545b4abc7d2849db7be8f78abba8a1626a2ba7  
> 0001-lavc-amr-Rename-NO_DATA-as-AMR_NO_DATA.patch
> From 317dbccb46a02ac997c8826ef4c31b787fc8ce47 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 3 Oct 2017 00:00:29 +0200
> Subject: [PATCH] lavc/amr: Rename NO_DATA as AMR_NO_DATA.
> 
> mingw64 defines NO_DATA in wsa_errnos.h
> ---
>  libavcodec/amrnbdata.h |2 +-
>  libavcodec/amrnbdec.c  |5 +++--
>  libavcodec/amrwbdata.h |2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/amrnbdata.h b/libavcodec/amrnbdata.h
> index 435fd99..b38f955 100644
> --- a/libavcodec/amrnbdata.h
> +++ b/libavcodec/amrnbdata.h
> @@ -47,7 +47,7 @@ enum Mode {
>  MODE_12k2,///< 12.2 kbit/s
>  MODE_DTX, ///< silent frame
>  N_MODES,  ///< number of modes
> -NO_DATA = 15  ///< no transmission
> +AMR_NO_DATA = 15  ///< no transmission
>  };
>  
>  #define LP_FILTER_ORDER 10///< linear predictive coding filter order
> diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
> index ea299ac..ae5be5d 100644
> --- a/libavcodec/amrnbdec.c
> +++ b/libavcodec/amrnbdec.c
> @@ -214,8 +214,9 @@ static enum Mode unpack_bitstream(AMRContext *p, const 
> uint8_t *buf,
>  p->bad_frame_indicator = (buf[0] & 0x4) != 0x4; // quality bit
>  
>  if (mode >= N_MODES || buf_size < frame_sizes_nb[mode] + 1) {
> -return NO_DATA;
> +return AMR_NO_DATA;
>  }

> +printf("mode: %d, size: %ld, bitmaps_per_mode: %d \n", mode, 
> sizeof(AMRNBFrame), *amr_unpacking_bitmaps_per_mode[mode]);

you missed this line in the patch

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

[FFmpeg-devel] [PATCH] ffmpeg: always init output stream before reaping filters

[Marton Balint]

Otherwise the frame size of the codec is not set in the buffersink.

Fixes ticket #6603 and the following simpler case:

ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1d248bc269..5be8788ea8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4528,6 +4528,15 @@ static int transcode_step(void)
 }
 
 if (ost->filter && ost->filter->graph->graph) {
+if (!ost->initialized) {
+char error[1024] = {0};
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error initializing output stream 
%d:%d -- %s\n",
+   ost->file_index, ost->index, error);
+exit_program(1);
+}
+}
 if ((ret = transcode_from_filter(ost->filter->graph, )) < 0)
 return ret;
 if (!ist)
-- 
2.13.5

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

Re: [FFmpeg-devel] [PATCH v2] doc: add mailing list faq

[Lou Logan]

On Tue, Oct 3, 2017, at 12:08 AM, Carl Eugen Hoyos wrote:
> Gmane does not work for a long time.

Removed.

> The reason I also use "uncut" is that "complete" was misunderstood
> by some iirc.

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

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: support multichannel XMA stream configurations

[Carl Eugen Hoyos]

2017-10-03 23:49 GMT+02:00  :

> -if (size < 40 + num_streams * 4)
> +if (size != (32 + ((version==3)?0:8) + 4*num_streams))

Could be: (32 + (version == 4) * 8) + 4 * num_streams)

Please also provide a sample and a fate test.

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

[FFmpeg-devel] [PATCH] avcodec/wmaprodec: support multichannel XMA stream configurations

[bananaman255]

From: bnnm 

Signed-off-by: bnnm 

Now accepts any combination of 1/2ch streams, described in the RIFF 
chunks/extradata
---
 libavcodec/wmaprodec.c | 151 -
 libavformat/wavdec.c   |  20 ---
 2 files changed, 112 insertions(+), 59 deletions(-)

diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 5c99628c52..77a49c9db8 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -106,6 +106,9 @@
 #define MAX_SUBFRAMES  32///< max number 
of subframes per channel
 #define MAX_BANDS  29///< max number 
of scale factor bands
 #define MAX_FRAMESIZE  32768 ///< maximum 
compressed frame size
+#define XMA_MAX_STREAMS 8
+#define XMA_MAX_CHANNELS8
+#define XMA_MAX_CHANNELS_STREAM 2
 
 #define WMAPRO_BLOCK_MIN_BITS  6   
///< log2 of min block size
 #define WMAPRO_BLOCK_MAX_BITS 13   
///< log2 of max block size
@@ -215,7 +218,7 @@ typedef struct WMAProDecodeCtx {
 uint8_t  drc_gain;  ///< gain for the DRC tool
 int8_t   skip_frame;///< skip output step
 int8_t   parsed_all_subframes;  ///< all subframes decoded?
-uint8_t  skip_packets;
+uint8_t  skip_packets;  ///< packets to skip to 
find next packet in a stream (XMA1/2)
 
 /* subframe/block decode state */
 int16_t  subframe_len;  ///< current subframe 
length
@@ -235,11 +238,13 @@ typedef struct WMAProDecodeCtx {
 } WMAProDecodeCtx;
 
 typedef struct XMADecodeCtx {
-WMAProDecodeCtx xma[4];
-AVFrame *frames[4];
+WMAProDecodeCtx xma[XMA_MAX_STREAMS];
+AVFrame *frames[XMA_MAX_STREAMS];
 int current_stream;
-float samples[8][512 * 64];
-int offset[4];
+int num_streams;
+float samples[XMA_MAX_CHANNELS][512 * 64];
+int offset[XMA_MAX_STREAMS];
+int start_channel[XMA_MAX_STREAMS];
 } XMADecodeCtx;
 
 /**
@@ -306,7 +311,7 @@ static av_cold int get_rate(AVCodecContext *avctx)
  *@param avctx codec context
  *@return 0 on success, -1 otherwise
  */
-static av_cold int decode_init(WMAProDecodeCtx *s, AVCodecContext *avctx)
+static av_cold int decode_init(WMAProDecodeCtx *s, AVCodecContext *avctx, int 
num_stream)
 {
 uint8_t *edata_ptr = avctx->extradata;
 unsigned int channel_mask;
@@ -333,18 +338,30 @@ static av_cold int decode_init(WMAProDecodeCtx *s, 
AVCodecContext *avctx)
 for (i = 0; i < avctx->extradata_size; i++)
 av_log(avctx, AV_LOG_DEBUG, "[%x] ", avctx->extradata[i]);
 av_log(avctx, AV_LOG_DEBUG, "\n");
-if (avctx->codec_id == AV_CODEC_ID_XMA2 && (!avctx->extradata || 
avctx->extradata_size >= 6)) {
+
+if (avctx->codec_id == AV_CODEC_ID_XMA2 && avctx->extradata_size == 34) { 
/* XMA2WAVEFORMATEX */
+s->decode_flags= 0x10d6;
+s->bits_per_sample = 16;
+channel_mask   = 0; //AV_RL32(edata_ptr+2); /* not always in 
expected order */
+if ((num_stream+1) * XMA_MAX_CHANNELS_STREAM > avctx->channels) /* 
stream config is 2ch + 2ch + ... + 1/2ch */
+s->nb_channels = 1;
+else
+s->nb_channels = 2;
+} else if (avctx->codec_id == AV_CODEC_ID_XMA2) { /* XMA2WAVEFORMAT */
 s->decode_flags= 0x10d6;
-channel_mask   = avctx->extradata ? AV_RL32(edata_ptr+2) : 0;
 s->bits_per_sample = 16;
- } else if (avctx->codec_id == AV_CODEC_ID_XMA1) {
+channel_mask   = 0; /* would need to aggregate from all streams */
+s->nb_channels = edata_ptr[32 + ((edata_ptr[0]==3)?0:8) + 4*num_stream 
+ 0]; /* nth stream config */
+} else if (avctx->codec_id == AV_CODEC_ID_XMA1) { /* XMAWAVEFORMAT */
 s->decode_flags= 0x10d6;
 s->bits_per_sample = 16;
-channel_mask   = 0;
- } else if (avctx->codec_id == AV_CODEC_ID_WMAPRO && avctx->extradata_size 
>= 18) {
+channel_mask   = 0; /* would need to aggregate from all streams */
+s->nb_channels = edata_ptr[8 + 20*num_stream + 17]; /* nth stream 
config */
+} else if (avctx->codec_id == AV_CODEC_ID_WMAPRO && avctx->extradata_size 
>= 18) {
 s->decode_flags= AV_RL16(edata_ptr+14);
 channel_mask   = AV_RL32(edata_ptr+2);
 s->bits_per_sample = AV_RL16(edata_ptr);
+s->nb_channels = avctx->channels;
 
 if (s->bits_per_sample > 32 || s->bits_per_sample < 1) {
 avpriv_request_sample(avctx, "bits per sample is %d", 
s->bits_per_sample);
@@ -355,12 +372,6 @@ static av_cold int decode_init(WMAProDecodeCtx *s, 
AVCodecContext *avctx)
 return AVERROR_PATCHWELCOME;
 }
 
-if (avctx->codec_id != AV_CODEC_ID_WMAPRO && avctx->channels > 2) {
-

Re: [FFmpeg-devel] [PATCH}lavf/mxfdec: Search all components of material track for source package

[Carl Eugen Hoyos]

2016-11-05 1:50 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes ticket #5925 here.

Ok'ed by Marton and pushed.

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

Re: [FFmpeg-devel] [PATCH]fate: Add a test for latm-in-dvb autodetection

[Carl Eugen Hoyos]

2017-10-03 0:45 GMT+02:00 Michael Niedermayer :
> On Sat, Sep 30, 2017 at 08:38:36PM +0200, Carl Eugen Hoyos wrote:
>> 2017-09-27 17:12 GMT+02:00 Carl Eugen Hoyos :
>> > Hi!
>> >
>> > Attached patch adds a test for ticket #6657.
>>
>> New patch attached.
>>
>> Carl Eugen
>
>>  Makefile   |1 +
>>  fate/mpegts.mak|   14 ++
>>  ref/fate/mpegts-probe-latm |   14 ++
>>  3 files changed, 29 insertions(+)
>> 96cad0656a5384221bd22113fca6f6b06273fdfe  
>> 0001-fate-Add-a-test-for-latm-in-dvb-auto-detection-ticke.patch
>> From cc022fb1c6398e4dac3ce43b0205908481c07a08 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 30 Sep 2017 20:33:09 +0200
>> Subject: [PATCH] fate: Add a test for latm-in-dvb auto-detection, ticket
>>  #6657.
>
> probably ok

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] avformat/mp3dec: Fix definition of MIDDLE_BITS

[Carl Eugen Hoyos]

2017-10-03 15:50 GMT+02:00 Ingo Brückl :
> The number of bits from bit #m to #n is n - m plus 1.

> -#define MIDDLE_BITS(k, m, n) LAST_BITS((k) >> (m), ((n) - (m)))
> +#define MIDDLE_BITS(k, m, n) LAST_BITS((k) >> (m), ((n) - (m) + 1))

I cannot comment on this patch but if this fixes a sample
of yours, please add a fate test.

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

Re: [FFmpeg-devel] [PATCH 1/7] First pass at fixing paletteuse

[Michael Niedermayer]

On Mon, Oct 02, 2017 at 01:24:33PM -0400, Bjorn Roche wrote:
> From: Bjorn Roche 
> 
> Dithering doesn’t work, and only iterative and brute force color
> mapping work.
> ---
>  libavfilter/vf_paletteuse.c | 265 
> +++-
>  1 file changed, 185 insertions(+), 80 deletions(-)

this breaks make fate, please make sure "make fate" passes after each
patch

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] libavcodec/blockdsp : add AVX version

[Ronald S. Bultje]

Hi,

On Tue, Oct 3, 2017 at 3:47 PM, Martin Vignali 
wrote:

> 2017-10-02 4:05 GMT+02:00 Ronald S. Bultje :
> > On Sun, Oct 1, 2017 at 7:46 PM, Martin Vignali  >
> > wrote:
> > > I also modify several decoder/encoder, in order to fix the
> > DECLARE_ALIGNED
> > > from 16 to 32
> >
> > How did you decide which ones to change?
>
[..]

> using git grep clear_block, i check all the files who use this func
> and change LOCAL_ALIGNED_16 to LOCAL_ALIGNED_32
> or  DECLARE_ALIGNED(16.. to DECLARE_ALIGNED(32...
>

OK, that addresses my potential concern, no more comments from me, thanks.

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

[FFmpeg-devel] [PATCH 2/2] lavc/v4l2: Mark static const tables as such

[Mark Thompson]

---
 libavcodec/v4l2_m2m_enc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index 9f59be6efb..b0d5a3bd15 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -93,7 +93,7 @@ static inline int v4l2_get_ext_ctrl(V4L2m2mContext *s, 
unsigned int id, signed i
 
 static inline unsigned int v4l2_h264_profile_from_ff(int p)
 {
-struct h264_profile  {
+static const struct h264_profile  {
 unsigned int ffmpeg_val;
 unsigned int v4l2_val;
 } profile[] = {
@@ -120,7 +120,7 @@ static inline unsigned int v4l2_h264_profile_from_ff(int p)
 
 static inline int v4l2_mpeg4_profile_from_ff(int p)
 {
-struct mpeg4_profile {
+static const struct mpeg4_profile {
 unsigned int ffmpeg_val;
 unsigned int v4l2_val;
 } profile[] = {
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/2] lavc/v4l2: Remove use of lfind()

[Mark Thompson]

This is not present in older bionic and therefore fails to build there,
and the code is much simpler without it anyway.
---
 libavcodec/v4l2_fmt.c | 73 +++
 libavcodec/v4l2_m2m_enc.c | 32 -
 2 files changed, 28 insertions(+), 77 deletions(-)

diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index a7ce308696..6df47e3f5a 100644
--- a/libavcodec/v4l2_fmt.c
+++ b/libavcodec/v4l2_fmt.c
@@ -109,74 +109,33 @@ static const struct fmt_conversion {
 #endif
 };
 
-static int match_codec(const void *a, const void *b)
-{
-if (*(enum AVCodecID *)a == ((struct fmt_conversion *)b)->avcodec)
-return 0;
-
-return 1;
-}
-
 uint32_t ff_v4l2_format_avcodec_to_v4l2(enum AVCodecID avcodec)
 {
-size_t len = FF_ARRAY_ELEMS(fmt_map);
-struct fmt_conversion *item;
-
-item = lfind(, fmt_map, , sizeof(fmt_map[0]), match_codec);
-if (item)
-return item->v4l2_fmt;
-
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(fmt_map); i++) {
+if (fmt_map[i].avcodec == avcodec)
+return fmt_map[i].v4l2_fmt;
+}
 return 0;
 }
 
-static int match_fmt(const void *a, const void *b)
-{
-if ( *(enum AVPixelFormat *)a == ((struct fmt_conversion *)b)->avfmt)
-return 0;
-
-return 1;
-}
-
 uint32_t ff_v4l2_format_avfmt_to_v4l2(enum AVPixelFormat avfmt)
 {
-size_t len = FF_ARRAY_ELEMS(fmt_map);
-struct fmt_conversion *item;
-
-item = lfind(, fmt_map, , sizeof(fmt_map[0]), match_fmt);
-if (item)
-return item->v4l2_fmt;
-
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(fmt_map); i++) {
+if (fmt_map[i].avfmt == avfmt)
+return fmt_map[i].v4l2_fmt;
+}
 return 0;
 }
 
-struct v4l2fmt_avcodec_pair {
-enum AVCodecID avcodec;
-uint32_t v4l2_fmt;
-};
-
-static int match_codecfmt(const void *a, const void *b)
-{
-struct v4l2fmt_avcodec_pair *key = (struct v4l2fmt_avcodec_pair *) a;
-struct fmt_conversion *item = (struct fmt_conversion *) b;
-
-if (key->avcodec == item->avcodec && key->v4l2_fmt == item->v4l2_fmt)
-return 0;
-
-return 1;
-}
-
 enum AVPixelFormat ff_v4l2_format_v4l2_to_avfmt(uint32_t v4l2_fmt, enum 
AVCodecID avcodec)
 {
-struct v4l2fmt_avcodec_pair const key = {
-.v4l2_fmt = v4l2_fmt,
-.avcodec = avcodec,
-};
-size_t len = FF_ARRAY_ELEMS(fmt_map);
-struct fmt_conversion *item;
-
-item = lfind(, fmt_map, , sizeof(fmt_map[0]), match_codecfmt);
-if (item)
-return item->avfmt;
-
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(fmt_map); i++) {
+if (fmt_map[i].avcodec  == avcodec &&
+fmt_map[i].v4l2_fmt == v4l2_fmt)
+return fmt_map[i].avfmt;
+}
 return AV_PIX_FMT_NONE;
 }
diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index e40a120b53..9f59be6efb 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -91,20 +91,12 @@ static inline int v4l2_get_ext_ctrl(V4L2m2mContext *s, 
unsigned int id, signed i
 return 0;
 }
 
-static int match_profile(const void *a, const void *b)
-{
-if (*(unsigned int *)a == *(unsigned int *)b)
-return 0;
-
-return 1;
-}
-
 static inline unsigned int v4l2_h264_profile_from_ff(int p)
 {
 struct h264_profile  {
 unsigned int ffmpeg_val;
 unsigned int v4l2_val;
-} *val, profile[] = {
+} profile[] = {
 { FF_PROFILE_H264_CONSTRAINED_BASELINE, 
MPEG_VIDEO(H264_PROFILE_CONSTRAINED_BASELINE) },
 { FF_PROFILE_H264_HIGH_444_PREDICTIVE, 
MPEG_VIDEO(H264_PROFILE_HIGH_444_PREDICTIVE) },
 { FF_PROFILE_H264_HIGH_422_INTRA, 
MPEG_VIDEO(H264_PROFILE_HIGH_422_INTRA) },
@@ -117,12 +109,12 @@ static inline unsigned int v4l2_h264_profile_from_ff(int 
p)
 { FF_PROFILE_H264_MAIN, MPEG_VIDEO(H264_PROFILE_MAIN) },
 { FF_PROFILE_H264_HIGH, MPEG_VIDEO(H264_PROFILE_HIGH) },
 };
-size_t len = FF_ARRAY_ELEMS(profile);
-
-val = lfind(, profile, , sizeof(profile[0]), match_profile);
-if (val)
-return val->v4l2_val;
+int i;
 
+for (i = 0; i < FF_ARRAY_ELEMS(profile); i++) {
+if (profile[i].ffmpeg_val == p)
+return profile[i].v4l2_val;
+}
 return AVERROR(ENOENT);
 }
 
@@ -131,19 +123,19 @@ static inline int v4l2_mpeg4_profile_from_ff(int p)
 struct mpeg4_profile {
 unsigned int ffmpeg_val;
 unsigned int v4l2_val;
-} *val, profile[] = {
+} profile[] = {
 { FF_PROFILE_MPEG4_ADVANCED_CODING, 
MPEG_VIDEO(MPEG4_PROFILE_ADVANCED_CODING_EFFICIENCY) },
 { FF_PROFILE_MPEG4_ADVANCED_SIMPLE, 
MPEG_VIDEO(MPEG4_PROFILE_ADVANCED_SIMPLE) },
 { FF_PROFILE_MPEG4_SIMPLE_SCALABLE, 
MPEG_VIDEO(MPEG4_PROFILE_SIMPLE_SCALABLE) },
 { FF_PROFILE_MPEG4_SIMPLE, MPEG_VIDEO(MPEG4_PROFILE_SIMPLE) },
 { FF_PROFILE_MPEG4_CORE, MPEG_VIDEO(MPEG4_PROFILE_CORE) },
 };
-size_t len = FF_ARRAY_ELEMS(profile);
-
-val = 

Re: [FFmpeg-devel] libavcodec/blockdsp : add AVX version

[Martin Vignali]

Hello,


> I used GCC 7.2. clear_blocks_mmx is slower than c for me as well, but
> not the rest.
> Your compiler seems to have done a much better job than mine. Is it
> Clang? Does it somehow have vectorization enabled perhaps? Because
> that's not supposed to happen.
>
>
Yes it's Clang 8.1

I put the clear_blocks_c function, in a file and run
clang -S -O1 test_asm_gen.c

the asm result is
.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 12
.globl_clear_blocks_c
.p2align4, 0x90
_clear_blocks_c:## @clear_blocks_c
.cfi_startproc
## BB#0:
pushq%rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
movl$768, %esi  ## imm = 0x300
callq___bzero
popq%rbp
retq
.cfi_endproc


.subsections_via_symbols

Seems like an optimized function is call for clear_blocks_c

>
> > I also modify several decoder/encoder, in order to fix the
> DECLARE_ALIGNED
> > from 16 to 32
> >
> > I run make fate SAMPLES=fate-suite/
> > i have several errors, but after a check, these errors
> > doesn't seems to be related to this patch
>
> Make sure to clean your build folder if you recently pulled new commits
> from the git repository. Reconfigure if necessary.
>
>
Ok, i rerun it, and pass fate test


2017-10-02 4:05 GMT+02:00 Ronald S. Bultje :

> Hi,
>
> On Sun, Oct 1, 2017 at 7:46 PM, Martin Vignali 
> wrote:
>
> > I also modify several decoder/encoder, in order to fix the
> DECLARE_ALIGNED
> > from 16 to 32
> >
>
> How did you decide which ones to change?
>
> Ronald
>

after running fate test, looks like tests fail when
LOCAL_ALIGNED_16 or DECLARE_ALIGNED(16 is use to declare block variable
not in other case.

using git grep clear_block, i check all the files who use this func
and change LOCAL_ALIGNED_16 to LOCAL_ALIGNED_32
or  DECLARE_ALIGNED(16.. to DECLARE_ALIGNED(32...

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

Re: [FFmpeg-devel] [PATCH] libavformat/nutenc.c: Use ffv1 as default video encoder for NUT muxing

[Michael Niedermayer]

On Mon, Oct 02, 2017 at 11:50:45PM +0200, Carl Eugen Hoyos wrote:
> 2017-10-02 23:18 GMT+02:00 Leo Izen :
> > On 09/28/2017 04:51 PM, Michael Niedermayer wrote:
> >>
> >> On Wed, Sep 27, 2017 at 07:14:50PM -0400, Leo Izen wrote:
> 
> >>> -.video_codec= AV_CODEC_ID_MPEG4,
> >>> +.video_codec= AV_CODEC_ID_FFV1,
> >>>   .write_header   = nut_write_header,
> >>>   .write_packet   = nut_write_packet,
> >>>   .write_trailer  = nut_write_trailer,
> >>
> >> Why?
> >>
> >> also this breaks existing code and command lines
> >> which expect mpeg4 as default
> >
> > This was a patch I submitted as suggested by Mark
> > Thompson on IRC, 2017-09-27:
> >
> > [18:47:51]  while we're on automatic order, for NUT,
> > mpeg4 gets picked by default rather than ffv1
> 
> (The irc paste imo contradicts your claim above)
> 
> I don't think ffv1 is a useful default video encoder for nut.

yes
ffv1 is a great choice as default for lossless encoding.
but if lossless is not the goal then a lossless codec is not a good
default.


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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Michael Niedermayer]

On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote:
> From: Anton Khirnov 
> 

> Use the AVFrame.opaque_ref field. The original user's opaque_ref is
> wrapped in the lavc struct and then unwrapped before the frame is
> returned to the caller.

this is a ugly hack

one and the same field should not be used to hold both the
users opaque_ref as well as a structure which is itself not a user
opaque_ref

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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/3] avcodec/proresdec2: Use LAST_SKIP_BITS where possible

[Michael Niedermayer]

On Sun, Oct 01, 2017 at 11:54:22PM -0300, James Almer wrote:
> On 10/1/2017 11:18 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/proresdec2.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> > index 22dc70eeb4..9647aa7ebc 100644
> > --- a/libavcodec/proresdec2.c
> > +++ b/libavcodec/proresdec2.c
> > @@ -250,7 +250,7 @@ static int decode_picture_header(AVCodecContext *avctx, 
> > const uint8_t *buf, cons
> >  return pic_data_size;
> >  }
> >  
> > -#define DECODE_CODEWORD(val, codebook)  \
> > +#define DECODE_CODEWORD(val, codebook, SKIP_BITSf)  \
> 
> Nit: SKIP.
> 
> SKIP_BITSf is kinda ugly.

will change it to SKIP and apply

will also apply the rest of the set

thanks


[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 2:11 PM, wm4 wrote:
> On Tue, 3 Oct 2017 13:27:21 -0300
> James Almer  wrote:
> 
>> I don't really agree with this, seeing almost every other project out
>> there does pretty much what this patch is trying to achieve and don't
>> seem to have issues handling bug reports, but if both you and Carl
>> consider this behavior as important for the sake of bug reporting and
>> nobody else chimes in in favor, then I'll withdraw this patch.
> 
> Sad...

I don't have strong feelings for this patch. It's mean to free space
(seeing some clients in fate.ffmpeg.org keep running out of it) and
reduce building time. But if it ruins some people's workflow then I'm
not going to fight to get it in.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[wm4]

On Tue, 3 Oct 2017 13:27:21 -0300
James Almer  wrote:

> I don't really agree with this, seeing almost every other project out
> there does pretty much what this patch is trying to achieve and don't
> seem to have issues handling bug reports, but if both you and Carl
> consider this behavior as important for the sake of bug reporting and
> nobody else chimes in in favor, then I'll withdraw this patch.

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

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[Marton Balint]

On Tue, 3 Oct 2017, James Almer wrote:


On 10/3/2017 1:01 PM, Michael Niedermayer wrote:

On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:

On 10/2/2017 4:34 PM, Michael Niedermayer wrote:

On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:

Do it during install instead, like with the libraries.

There's no benefit making a stripped copy of the CLI tools in the
build folder. Doing it during install saves build time and storage
space.

Signed-off-by: James Almer 


Iam not sure this is a good idea

the build binaries and installed binaries would differ, thats bound
to lead to some confusion and problems


What kind of confusion will removing "ffmpeg_g" from the build folder
bring? It's never installed, and what does get installed by "make
install" will not change with this patch in form or name.
This patch does for the binaries the same thing we're doing for the
libraries: Strip during install, instead of making a stripped duplicate
in the build folder.


The ffmpeg in the build folder will be a different binary than the
one installed, they will look the same from the output, same
configure flags and so on.
But because they are different binaries they can and will behave
differently. Bugs in the past occuring with ffmpeg did sometimes not
reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
together with its command line output which contains revission and
build flags it was clear what version was used.



With this change its indistingishable if a "ffmpeg" is stripped or non
stripped the printed build flags will no longer provide this
information together with the excuatble name


If the build flags have "--disable-stripping", then "ffmpeg" will not be
stripped, regardless of this being the build folder or an installation
target. So, in short, you're arguing that in builds with stripping
enabled, ffmpeg in the build folder being different than the one in the
install folder will make getting users to provide useful reports harder?

I don't really agree with this, seeing almost every other project out
there does pretty much what this patch is trying to achieve and don't
seem to have issues handling bug reports, but if both you and Carl
consider this behavior as important for the sake of bug reporting and
nobody else chimes in in favor, then I'll withdraw this patch.


The only argument against this patch that I find mildly convincing is that 
we should do tests (fate tests) with stripped binaries in order to be able 
to detect bugs when stripping.


But I always hated the fact that the build process is copying huge 
binaries.


Question: why don't we use strip -o ffmpeg ffmpeg_g instead of copying 
first?


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

Re: [FFmpeg-devel] [PATCH] avcodec/encode: don't return immediately on failure

[James Almer]

On 10/3/2017 5:23 AM, wm4 wrote:
> On Tue,  3 Oct 2017 01:55:44 -0300
> James Almer  wrote:
> 
>> Fixes memleaks introduced by skipping cleanup at the end of the
>> functions.
>>
>> Regression since a22c6a4796ca1f2cbee6784262515da876fbec22.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/encode.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
>> index c152228c92..841a185738 100644
>> --- a/libavcodec/encode.c
>> +++ b/libavcodec/encode.c
>> @@ -225,10 +225,10 @@ int attribute_align_arg 
>> avcodec_encode_audio2(AVCodecContext *avctx,
>>  } else if (!avpkt->buf) {
>>  AVPacket tmp = { 0 };
>>  ret = av_packet_ref(, avpkt);
>> -if (ret < 0)
>> -return ret;
>> -av_packet_unref(avpkt);
>> -*avpkt = tmp;
>> +if (!ret) {
>> +av_packet_unref(avpkt);
>> +*avpkt = tmp;
>> +}
>>  }
>>  }
>>  
>> @@ -324,10 +324,10 @@ int attribute_align_arg 
>> avcodec_encode_video2(AVCodecContext *avctx,
>>  } else if (!avpkt->buf) {
>>  AVPacket tmp = { 0 };
>>  ret = av_packet_ref(, avpkt);
>> -if (ret < 0)
>> -return ret;
>> -av_packet_unref(avpkt);
>> -*avpkt = tmp;
>> +if (!ret) {
>> +av_packet_unref(avpkt);
>> +*avpkt = tmp;
>> +}
>>  }
>>  }
>>  
> 
> Seems ok if ret is actually checked in the code below. Something like
> "goto cleanup;" on error would be less confusing though.

Did that instead and pushed. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: Add IEC DV25

[Michael Niedermayer]

On Mon, Oct 02, 2017 at 12:38:28PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)

patchset applied

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 1:01 PM, Michael Niedermayer wrote:
> On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
>> On 10/2/2017 4:34 PM, Michael Niedermayer wrote:
>>> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:
 Do it during install instead, like with the libraries.

 There's no benefit making a stripped copy of the CLI tools in the
 build folder. Doing it during install saves build time and storage
 space.

 Signed-off-by: James Almer 
>>>
>>> Iam not sure this is a good idea
>>>
>>> the build binaries and installed binaries would differ, thats bound
>>> to lead to some confusion and problems
>>
>> What kind of confusion will removing "ffmpeg_g" from the build folder
>> bring? It's never installed, and what does get installed by "make
>> install" will not change with this patch in form or name.
>> This patch does for the binaries the same thing we're doing for the
>> libraries: Strip during install, instead of making a stripped duplicate
>> in the build folder.
> 
> The ffmpeg in the build folder will be a different binary than the
> one installed, they will look the same from the output, same
> configure flags and so on.
> But because they are different binaries they can and will behave
> differently. Bugs in the past occuring with ffmpeg did sometimes not
> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
> together with its command line output which contains revission and
> build flags it was clear what version was used.

> With this change its indistingishable if a "ffmpeg" is stripped or non
> stripped the printed build flags will no longer provide this
> information together with the excuatble name

If the build flags have "--disable-stripping", then "ffmpeg" will not be
stripped, regardless of this being the build folder or an installation
target. So, in short, you're arguing that in builds with stripping
enabled, ffmpeg in the build folder being different than the one in the
install folder will make getting users to provide useful reports harder?

I don't really agree with this, seeing almost every other project out
there does pretty much what this patch is trying to achieve and don't
seem to have issues handling bug reports, but if both you and Carl
consider this behavior as important for the sake of bug reporting and
nobody else chimes in in favor, then I'll withdraw this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[wm4]

On Tue, 3 Oct 2017 18:01:14 +0200
Michael Niedermayer  wrote:

> differently. Bugs in the past occuring with ffmpeg did sometimes not
> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
> together with its command line output which contains revission and
> build flags it was clear what version was used.

There are lots of factors that can make ffmpeg behave different on
every _invocation_. Like dynamic memory allocation or ASLR, or even the
ffmpeg binary path.

Should we remove all these features?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[Michael Niedermayer]

On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
> On 10/2/2017 4:34 PM, Michael Niedermayer wrote:
> > On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:
> >> Do it during install instead, like with the libraries.
> >>
> >> There's no benefit making a stripped copy of the CLI tools in the
> >> build folder. Doing it during install saves build time and storage
> >> space.
> >>
> >> Signed-off-by: James Almer 
> > 
> > Iam not sure this is a good idea
> > 
> > the build binaries and installed binaries would differ, thats bound
> > to lead to some confusion and problems
> 
> What kind of confusion will removing "ffmpeg_g" from the build folder
> bring? It's never installed, and what does get installed by "make
> install" will not change with this patch in form or name.
> This patch does for the binaries the same thing we're doing for the
> libraries: Strip during install, instead of making a stripped duplicate
> in the build folder.

The ffmpeg in the build folder will be a different binary than the
one installed, they will look the same from the output, same
configure flags and so on.
But because they are different binaries they can and will behave
differently. Bugs in the past occuring with ffmpeg did sometimes not
reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
together with its command line output which contains revission and
build flags it was clear what version was used.
With this change its indistingishable if a "ffmpeg" is stripped or non
stripped the printed build flags will no longer provide this
information together with the excuatble name


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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec: allow multiple hwaccels for the same codec/pixfmt

[wm4]

On Tue, 3 Oct 2017 15:58:32 +0200
Timo Rothenpieler  wrote:

> > -static AVHWAccel *find_hwaccel(enum AVCodecID codec_id,
> > +static AVHWAccel *find_hwaccel(AVCodecContext *avctx,
> >  enum AVPixelFormat pix_fmt)
> >   {
> >   AVHWAccel *hwaccel = NULL;
> > +const AVClass *av_class =
> > +(avctx->codec->caps_internal & FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS)
> > +? avctx->av_class : NULL;

Also this is actually completely broken. It's trivially fixed, but if
anyone actually wants to try the patches, here's an updated set:

https://github.com/wm4/FFmpeg/tree/libav-cuvid
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/7] h264dec: add a CUVID hwaccel

[Philip Langdale]

On Tue,  3 Oct 2017 15:15:18 +0200
wm4  wrote:

> From: Anton Khirnov 
> 
> Some parts of the code are based on a patch by
> Timo Rothenpieler 
> 
> Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.
> 
> As a complication, all the names conflict. Add a _hwaccel suffix to
> the merged code where needed.
> 
> This commit also changes the Libav code to dynamic loading of the
> cuda/cuvid libraries. (I wouldn't be able to test with the fixed SDK
> anyway, because installing the CUDA SDK on Linux is hell.)
> 
> Signed-off-by: wm4 
> ---
>  Changelog   |   1 +
>  configure   |   9 +-
>  fftools/ffmpeg.h|   1 +
>  fftools/ffmpeg_opt.c|   4 +
>  libavcodec/Makefile |   3 +-
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/cuvid.c  | 431
> 
> libavcodec/cuvid.h  |  62 +++ libavcodec/cuvid_h264.c | 176
>  libavcodec/h264_slice.c |   6 +-
>  10 files changed, 690 insertions(+), 4 deletions(-)
>  create mode 100644 libavcodec/cuvid.c
>  create mode 100644 libavcodec/cuvid.h
>  create mode 100644 libavcodec/cuvid_h264.c
> 
> diff --git a/Changelog b/Changelog
> index 03686acef6..6c23d40760 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -88,6 +88,7 @@ version 3.3:
>  - Removed asyncts filter (use af_aresample instead)
>  - Intel QSV-accelerated VP8 video decoding
>  - VAAPI-accelerated deinterlacing
> +- NVIDIA CUVID-accelerated H.264 hwaccel decoding
>  
>  
>  version 3.2:
> diff --git a/configure b/configure
> index ae0eddac6c..3ced5f9466 100755
> --- a/configure
> +++ b/configure
> @@ -307,6 +307,7 @@ External library support:
>--disable-cuda   disable dynamically linked Nvidia CUDA
> code [autodetect] --enable-cuda-sdkenable CUDA features that
> require the CUDA SDK [no] --disable-cuvid  disable Nvidia
> CUVID support [autodetect]
> +  --disable-cuvid-hwaccel  Nvidia CUVID video decode acceleration
> (via hwaccel) [autodetect] --disable-d3d11vadisable Microsoft
> Direct3D 11 video acceleration code [autodetect]
> --disable-dxva2  disable Microsoft DirectX 9 video
> acceleration code [autodetect] --enable-libdrm  enable DRM
> code (Linux) [no] @@ -2664,6 +2665,8 @@
> h263_videotoolbox_hwaccel_deps="videotoolbox"
> h263_videotoolbox_hwaccel_select="h263_decoder"
> h264_cuvid_hwaccel_deps="cuda cuvid"
> h264_cuvid_hwaccel_select="h264_cuvid_decoder"
> +h264_cuvid_hwaccel_hwaccel_deps="cuda cuvid"
> +h264_cuvid_hwaccel_hwaccel_select="h264_decoder"
> h264_d3d11va_hwaccel_deps="d3d11va"
> h264_d3d11va_hwaccel_select="h264_decoder"
> h264_d3d11va2_hwaccel_deps="d3d11va" @@ -5909,6 +5912,8 @@ done
> enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate
> -lcuda enabled cuvid && { enabled cuda || die "ERROR:
> CUVID requires CUDA"; } +enabled cuvid_hwaccel && { enabled cuda
> ||
> +   die "ERROR: CUVID hwaccel requires
> CUDA"; } enabled chromaprint   && require chromaprint
> chromaprint.h chromaprint_get_version -lchromaprint enabled
> decklink  && { require_header DeckLinkAPI.h &&
> { check_cpp_condition DeckLinkAPIVersion.h
> "BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR:
> Decklink API version must be >= 10.6.1."; } } @@ -6266,11 +6271,11 @@
> if enabled x86; then mingw32*|mingw64*|win32|win64|linux|cygwin*) ;;
> *)
> -disable cuda cuvid nvenc
> +disable cuda cuvid cuvid_hwaccel nvenc
>  ;;
>  esac
>  else
> -disable cuda cuvid nvenc
> +disable cuda cuvid cuvid_hwaccel nvenc
>  fi
>  
>  enabled nvenc &&
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index f6c76bcc55..7deb82af51 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -69,6 +69,7 @@ enum HWAccelID {
>  HWACCEL_VAAPI,
>  HWACCEL_CUVID,
>  HWACCEL_D3D11VA,
> +HWACCEL_CUVID_HWACCEL,
>  };
>  
>  typedef struct HWAccel {
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 100fa76e46..1dd21ab591 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -97,6 +97,10 @@ const HWAccel hwaccels[] = {
>  #if CONFIG_CUVID
>  { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
>AV_HWDEVICE_TYPE_NONE },
> +#endif
> +#if CONFIG_CUVID_HWACCEL
> +{ "cuvid_hwaccel", hwaccel_decode_init, HWACCEL_CUVID_HWACCEL,
> AV_PIX_FMT_CUDA,
> +   AV_HWDEVICE_TYPE_CUDA },
>  #endif
>  { 0 },
>  };
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3e0d654541..2367d3144e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -820,7 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   +=
> adpcm.o adpcm_data.o OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   +=
> adpcmenc.o adpcm_data.o 
>  # hardware accelerators
> -OBJS-$(CONFIG_CUVID)  += cuvid.o
> 

Re: [FFmpeg-devel] [PATCH 5/7] avcodec/cuvid: rename cuvid.c to cuviddec.c

[Philip Langdale]

On Tue,  3 Oct 2017 15:15:16 +0200
wm4  wrote:

> cuvid.c is used by Libav's CUVID hwaccel. Resolve the conflict and
> avoid future merge problems by renaming our decoder.
> ---
>  libavcodec/Makefile| 10 +-
>  libavcodec/{cuvid.c => cuviddec.c} |  0
>  2 files changed, 5 insertions(+), 5 deletions(-)
>  rename libavcodec/{cuvid.c => cuviddec.c} (100%)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index c4ec09b1c4..fa3ab8f08a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -331,7 +331,7 @@ OBJS-$(CONFIG_H264_DECODER)+=
> h264dec.o h264_cabac.o h264_cavlc.o \ h264_mb.o h264_picture.o \
>h264_refs.o h264_sei.o \
>h264_slice.o h264data.o
> -OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuvid.o
> +OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
>  OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
>  OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
>  OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
> @@ -351,7 +351,7 @@ OBJS-$(CONFIG_HAP_ENCODER) +=
> hapenc.o hap.o OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o
> hevc_mvs.o \ hevc_cabac.o hevc_refs.o hevcpred.o\
>hevcdsp.o hevc_filter.o
> hevc_data.o -OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuvid.o
> +OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
>  OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
>  OBJS-$(CONFIG_HEVC_NVENC_ENCODER)  += nvenc_hevc.o
>  OBJS-$(CONFIG_NVENC_HEVC_ENCODER)  += nvenc_hevc.o
> @@ -616,7 +616,7 @@ OBJS-$(CONFIG_VC1_DECODER) +=
> vc1dec.o vc1_block.o vc1_loopfilter.o vc1_mc.o vc1_pred.o vc1.o
> vc1data.o \ msmpeg4dec.o msmpeg4.o msmpeg4data.o \
>wmv2dsp.o wmv2data.o
> -OBJS-$(CONFIG_VC1_CUVID_DECODER)   += cuvid.o
> +OBJS-$(CONFIG_VC1_CUVID_DECODER)   += cuviddec.o
>  OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
>  OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec_other.o
>  OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
> @@ -635,7 +635,7 @@ OBJS-$(CONFIG_VP6_DECODER) += vp6.o
> vp56.o vp56data.o \ vp6dsp.o vp56rac.o
>  OBJS-$(CONFIG_VP7_DECODER) += vp8.o vp56rac.o
>  OBJS-$(CONFIG_VP8_DECODER) += vp8.o vp56rac.o
> -OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuvid.o
> +OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuviddec.o
>  OBJS-$(CONFIG_VP8_MEDIACODEC_DECODER)  += mediacodecdec.o
>  OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec_other.o
>  OBJS-$(CONFIG_VP8_RKMPP_DECODER)   += rkmppdec.o
> @@ -645,7 +645,7 @@ OBJS-$(CONFIG_VP8_V4L2M2M_ENCODER) +=
> v4l2_m2m_enc.o OBJS-$(CONFIG_VP9_DECODER) += vp9.o
> vp9data.o vp9dsp.o vp9lpf.o vp9recon.o \ vp9block.o vp9prob.o
> vp9mvs.o vp56rac.o \ vp9dsp_8bpp.o vp9dsp_10bpp.o vp9dsp_12bpp.o
> -OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
> +OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuviddec.o
>  OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
>  OBJS-$(CONFIG_VP9_RKMPP_DECODER)   += rkmppdec.o
>  OBJS-$(CONFIG_VP9_VAAPI_ENCODER)   += vaapi_encode_vp9.o
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuviddec.c
> similarity index 100%
> rename from libavcodec/cuvid.c
> rename to libavcodec/cuviddec.c

Ship it


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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec: allow multiple hwaccels for the same codec/pixfmt

[Philip Langdale]

On Tue,  3 Oct 2017 15:15:17 +0200
wm4  wrote:

> Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
> This means it's impossible to have 2 decoders for the same codec and
> using the same opaque hardware pixel format.
> 
> This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
> support, but it's a full stream decoder, using NVIDIA's codec parser.
> The Libav one is a true hwaccel, which is based on the builtin
> software decoders.
> 
> Fix this by introducing another field to disambiguate AVHWAccels, and
> use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS
> makes this mechanism backwards compatible and optional.
> ---
>  libavcodec/Makefile   |  1 +
>  libavcodec/avcodec.h  |  5 +
>  libavcodec/cuviddec.c |  2 ++
>  libavcodec/decode.c   | 12 
>  libavcodec/internal.h |  5 +
>  5 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index fa3ab8f08a..3e0d654541 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -820,6 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   +=
> adpcm.o adpcm_data.o OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   +=
> adpcmenc.o adpcm_data.o 
>  # hardware accelerators
> +OBJS-$(CONFIG_CUVID)  += cuvid.o
>  OBJS-$(CONFIG_D3D11VA)+= dxva2.o
>  OBJS-$(CONFIG_DXVA2)  += dxva2.o
>  OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 52cc5b0ca0..ecc49e5643 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4000,6 +4000,11 @@ typedef struct AVHWAccel {
>   * Internal hwaccel capabilities.
>   */
>  int caps_internal;
> +
> +/**
> + * Some hwaccels are ambiguous if only
> + */
> +const AVClass *decoder_class;
>  } AVHWAccel;
>  
>  /**
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 2ba8e00c6a..6370348639 100644
> --- a/libavcodec/cuviddec.c
> +++ b/libavcodec/cuviddec.c
> @@ -1106,6 +1106,7 @@ static const AVOption options[] = {
>  .type   = AVMEDIA_TYPE_VIDEO, \
>  .id = AV_CODEC_ID_##X, \
>  .pix_fmt= AV_PIX_FMT_CUDA, \
> +.decoder_class  = ##_cuvid_class, \
>  }; \
>  AVCodec ff_##x##_cuvid_decoder = { \
>  .name   = #x "_cuvid", \
> @@ -1120,6 +1121,7 @@ static const AVOption options[] = {
>  .receive_frame  = cuvid_output_frame, \
>  .flush  = cuvid_flush, \
>  .capabilities   = AV_CODEC_CAP_DELAY |
> AV_CODEC_CAP_AVOID_PROBING, \
> +.caps_internal  = FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS, \
>  .pix_fmts   = (const enum
> AVPixelFormat[]){ AV_PIX_FMT_CUDA, \ AV_PIX_FMT_NV12, \
>  AV_PIX_FMT_P010,
> \ diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 668ef9667f..7060f6a3b7 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1152,15 +1152,19 @@ enum AVPixelFormat
> avcodec_default_get_format(struct AVCodecContext *s, const en return
> fmt[0]; }
>  
> -static AVHWAccel *find_hwaccel(enum AVCodecID codec_id,
> +static AVHWAccel *find_hwaccel(AVCodecContext *avctx,
> enum AVPixelFormat pix_fmt)
>  {
>  AVHWAccel *hwaccel = NULL;
> +const AVClass *av_class =
> +(avctx->codec->caps_internal &
> FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS)
> +? avctx->av_class : NULL;
>  
> -while ((hwaccel = av_hwaccel_next(hwaccel)))
> -if (hwaccel->id == codec_id
> +while ((hwaccel = av_hwaccel_next(hwaccel))) {
> +if (hwaccel->decoder_class == av_class && hwaccel->id ==
> avctx->codec_id && hwaccel->pix_fmt == pix_fmt)
>  return hwaccel;
> +}
>  return NULL;
>  }
>  
> @@ -1168,7 +1172,7 @@ static int setup_hwaccel(AVCodecContext *avctx,
>   const enum AVPixelFormat fmt,
>   const char *name)
>  {
> -AVHWAccel *hwa = find_hwaccel(avctx->codec_id, fmt);
> +AVHWAccel *hwa = find_hwaccel(avctx, fmt);
>  int ret= 0;
>  
>  if (!hwa) {
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index faa923c11f..0177ea6521 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -69,6 +69,11 @@
>   */
>  #define FF_CODEC_CAP_SLICE_THREAD_HAS_MF(1 << 5)
>  
> +/**
> + * Allow only AVHWAccels which have a matching decoder_class field.
> + */
> +#define FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS  (1 << 6)
> +
>  #ifdef TRACE
>  #   define ff_tlog(ctx, ...) av_log(ctx, AV_LOG_TRACE, __VA_ARGS__)
>  #else

Looks fine. Nothing beyond what Timo said.


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

Re: [FFmpeg-devel] [PATCH 7/7] h264dec: add a CUVID hwaccel

[Philip Langdale]

On Tue, 3 Oct 2017 16:08:32 +0200
Timo Rothenpieler  wrote:

> Am 03.10.2017 um 15:15 schrieb wm4:
> > From: Anton Khirnov 
> > 
> > Some parts of the code are based on a patch by
> > Timo Rothenpieler 
> > 
> > Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.
> > 
> > As a complication, all the names conflict. Add a _hwaccel suffix to
> > the merged code where needed.
> > 
> > This commit also changes the Libav code to dynamic loading of the
> > cuda/cuvid libraries. (I wouldn't be able to test with the fixed SDK
> > anyway, because installing the CUDA SDK on Linux is hell.)
> > 
> > Signed-off-by: wm4 
> > ---
> >   Changelog   |   1 +
> >   configure   |   9 +-
> >   fftools/ffmpeg.h|   1 +
> >   fftools/ffmpeg_opt.c|   4 +
> >   libavcodec/Makefile |   3 +-
> >   libavcodec/allcodecs.c  |   1 +
> >   libavcodec/cuvid.c  | 431
> > 
> > libavcodec/cuvid.h  |  62 +++ libavcodec/cuvid_h264.c | 176
> >  libavcodec/h264_slice.c |   6 +-
> >   10 files changed, 690 insertions(+), 4 deletions(-)
> >   create mode 100644 libavcodec/cuvid.c
> >   create mode 100644 libavcodec/cuvid.h
> >   create mode 100644 libavcodec/cuvid_h264.c
> > 
> > diff --git a/Changelog b/Changelog
> > index 03686acef6..6c23d40760 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -88,6 +88,7 @@ version 3.3:
> >   - Removed asyncts filter (use af_aresample instead)
> >   - Intel QSV-accelerated VP8 video decoding
> >   - VAAPI-accelerated deinterlacing
> > +- NVIDIA CUVID-accelerated H.264 hwaccel decoding
> >   
> >   
> >   version 3.2:
> > diff --git a/configure b/configure
> > index ae0eddac6c..3ced5f9466 100755
> > --- a/configure
> > +++ b/configure
> > @@ -307,6 +307,7 @@ External library support:
> > --disable-cuda   disable dynamically linked Nvidia CUDA
> > code [autodetect] --enable-cuda-sdkenable CUDA features
> > that require the CUDA SDK [no] --disable-cuvid  disable
> > Nvidia CUVID support [autodetect]
> > +  --disable-cuvid-hwaccel  Nvidia CUVID video decode acceleration
> > (via hwaccel) [autodetect] --disable-d3d11vadisable
> > Microsoft Direct3D 11 video acceleration code [autodetect]
> > --disable-dxva2  disable Microsoft DirectX 9 video
> > acceleration code [autodetect] --enable-libdrm  enable DRM
> > code (Linux) [no] @@ -2664,6 +2665,8 @@
> > h263_videotoolbox_hwaccel_deps="videotoolbox"
> > h263_videotoolbox_hwaccel_select="h263_decoder"
> > h264_cuvid_hwaccel_deps="cuda cuvid"
> > h264_cuvid_hwaccel_select="h264_cuvid_decoder"
> > +h264_cuvid_hwaccel_hwaccel_deps="cuda cuvid"
> > +h264_cuvid_hwaccel_hwaccel_select="h264_decoder"
> > h264_d3d11va_hwaccel_deps="d3d11va"
> > h264_d3d11va_hwaccel_select="h264_decoder"
> > h264_d3d11va2_hwaccel_deps="d3d11va" @@ -5909,6 +5912,8 @@ done
> > enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate
> > -lcuda enabled cuvid && { enabled cuda || die "ERROR:
> > CUVID requires CUDA"; } +enabled cuvid_hwaccel && { enabled
> > cuda ||
> > +   die "ERROR: CUVID hwaccel requires
> > CUDA"; } enabled chromaprint   && require chromaprint
> > chromaprint.h chromaprint_get_version -lchromaprint enabled
> > decklink  && { require_header DeckLinkAPI.h &&
> > { check_cpp_condition DeckLinkAPIVersion.h
> > "BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR:
> > Decklink API version must be >= 10.6.1."; } } @@ -6266,11 +6271,11
> > @@ if enabled x86; then
> > mingw32*|mingw64*|win32|win64|linux|cygwin*) ;; *)
> > -disable cuda cuvid nvenc
> > +disable cuda cuvid cuvid_hwaccel nvenc
> >   ;;
> >   esac
> >   else
> > -disable cuda cuvid nvenc
> > +disable cuda cuvid cuvid_hwaccel nvenc
> >   fi
> >   
> >   enabled nvenc &&
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index f6c76bcc55..7deb82af51 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -69,6 +69,7 @@ enum HWAccelID {
> >   HWACCEL_VAAPI,
> >   HWACCEL_CUVID,
> >   HWACCEL_D3D11VA,
> > +HWACCEL_CUVID_HWACCEL,
> >   };
> >   
> >   typedef struct HWAccel {
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 100fa76e46..1dd21ab591 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -97,6 +97,10 @@ const HWAccel hwaccels[] = {
> >   #if CONFIG_CUVID
> >   { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
> > AV_HWDEVICE_TYPE_NONE },
> > +#endif
> > +#if CONFIG_CUVID_HWACCEL
> > +{ "cuvid_hwaccel", hwaccel_decode_init, HWACCEL_CUVID_HWACCEL,
> > AV_PIX_FMT_CUDA,
> > +   AV_HWDEVICE_TYPE_CUDA },
> >   #endif
> >   { 0 },
> >   };
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 3e0d654541..2367d3144e 

Re: [FFmpeg-devel] [PATCH 7/7] h264dec: add a CUVID hwaccel

[wm4]

On Tue, 3 Oct 2017 16:08:32 +0200
Timo Rothenpieler  wrote:

> I'm not a fan of there being cuvid and cuvid_hwaccel now, meaning 
> potentially multiple things. It seems super confusing to me.

Yes, that's a pretty annoying situation.

> I'd propose to use this as a chance to get in line with nvidias new 
> naming, and call the new cuvid decoder/hwaccel nvdec. This is quite a 
> deviation from libav, but we need to rename it anyways, so might as well 
> pick an entirely different name.

I wouldn't be opposed. Will wait for more opinions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/7] h264dec: add a CUVID hwaccel

[Timo Rothenpieler]

Am 03.10.2017 um 15:15 schrieb wm4:

From: Anton Khirnov 

Some parts of the code are based on a patch by
Timo Rothenpieler 

Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.

As a complication, all the names conflict. Add a _hwaccel suffix to the
merged code where needed.

This commit also changes the Libav code to dynamic loading of the
cuda/cuvid libraries. (I wouldn't be able to test with the fixed SDK
anyway, because installing the CUDA SDK on Linux is hell.)

Signed-off-by: wm4 
---
  Changelog   |   1 +
  configure   |   9 +-
  fftools/ffmpeg.h|   1 +
  fftools/ffmpeg_opt.c|   4 +
  libavcodec/Makefile |   3 +-
  libavcodec/allcodecs.c  |   1 +
  libavcodec/cuvid.c  | 431 
  libavcodec/cuvid.h  |  62 +++
  libavcodec/cuvid_h264.c | 176 
  libavcodec/h264_slice.c |   6 +-
  10 files changed, 690 insertions(+), 4 deletions(-)
  create mode 100644 libavcodec/cuvid.c
  create mode 100644 libavcodec/cuvid.h
  create mode 100644 libavcodec/cuvid_h264.c

diff --git a/Changelog b/Changelog
index 03686acef6..6c23d40760 100644
--- a/Changelog
+++ b/Changelog
@@ -88,6 +88,7 @@ version 3.3:
  - Removed asyncts filter (use af_aresample instead)
  - Intel QSV-accelerated VP8 video decoding
  - VAAPI-accelerated deinterlacing
+- NVIDIA CUVID-accelerated H.264 hwaccel decoding
  
  
  version 3.2:

diff --git a/configure b/configure
index ae0eddac6c..3ced5f9466 100755
--- a/configure
+++ b/configure
@@ -307,6 +307,7 @@ External library support:
--disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
--enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
--disable-cuvid  disable Nvidia CUVID support [autodetect]
+  --disable-cuvid-hwaccel  Nvidia CUVID video decode acceleration (via 
hwaccel) [autodetect]
--disable-d3d11vadisable Microsoft Direct3D 11 video acceleration 
code [autodetect]
--disable-dxva2  disable Microsoft DirectX 9 video acceleration 
code [autodetect]
--enable-libdrm  enable DRM code (Linux) [no]
@@ -2664,6 +2665,8 @@ h263_videotoolbox_hwaccel_deps="videotoolbox"
  h263_videotoolbox_hwaccel_select="h263_decoder"
  h264_cuvid_hwaccel_deps="cuda cuvid"
  h264_cuvid_hwaccel_select="h264_cuvid_decoder"
+h264_cuvid_hwaccel_hwaccel_deps="cuda cuvid"
+h264_cuvid_hwaccel_hwaccel_select="h264_decoder"
  h264_d3d11va_hwaccel_deps="d3d11va"
  h264_d3d11va_hwaccel_select="h264_decoder"
  h264_d3d11va2_hwaccel_deps="d3d11va"
@@ -5909,6 +5912,8 @@ done
  enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate -lcuda
  enabled cuvid && { enabled cuda ||
 die "ERROR: CUVID requires CUDA"; }
+enabled cuvid_hwaccel && { enabled cuda ||
+   die "ERROR: CUVID hwaccel requires CUDA"; }
  enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
  enabled decklink  && { require_header DeckLinkAPI.h &&
 { check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API version 
must be >= 10.6.1."; } }
@@ -6266,11 +6271,11 @@ if enabled x86; then
  mingw32*|mingw64*|win32|win64|linux|cygwin*)
  ;;
  *)
-disable cuda cuvid nvenc
+disable cuda cuvid cuvid_hwaccel nvenc
  ;;
  esac
  else
-disable cuda cuvid nvenc
+disable cuda cuvid cuvid_hwaccel nvenc
  fi
  
  enabled nvenc &&

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f6c76bcc55..7deb82af51 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -69,6 +69,7 @@ enum HWAccelID {
  HWACCEL_VAAPI,
  HWACCEL_CUVID,
  HWACCEL_D3D11VA,
+HWACCEL_CUVID_HWACCEL,
  };
  
  typedef struct HWAccel {

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 100fa76e46..1dd21ab591 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -97,6 +97,10 @@ const HWAccel hwaccels[] = {
  #if CONFIG_CUVID
  { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
AV_HWDEVICE_TYPE_NONE },
+#endif
+#if CONFIG_CUVID_HWACCEL
+{ "cuvid_hwaccel", hwaccel_decode_init, HWACCEL_CUVID_HWACCEL, 
AV_PIX_FMT_CUDA,
+   AV_HWDEVICE_TYPE_CUDA },
  #endif
  { 0 },
  };
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3e0d654541..2367d3144e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -820,7 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   += adpcm.o 
adpcm_data.o
  OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o adpcm_data.o
  
  # hardware accelerators

-OBJS-$(CONFIG_CUVID)  += cuvid.o


Shouldn't this have been gone in a previous patch, as old cuvid.c renamed?

Re: [FFmpeg-devel] [PATCH 6/7] avcodec: allow multiple hwaccels for the same codec/pixfmt

[wm4]

On Tue, 3 Oct 2017 15:58:32 +0200
Timo Rothenpieler  wrote:

> Am 03.10.2017 um 15:15 schrieb wm4:
> > Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
> > This means it's impossible to have 2 decoders for the same codec and
> > using the same opaque hardware pixel format.
> > 
> > This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
> > support, but it's a full stream decoder, using NVIDIA's codec parser.
> > The Libav one is a true hwaccel, which is based on the builtin software
> > decoders.
> > 
> > Fix this by introducing another field to disambiguate AVHWAccels, and
> > use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS makes
> > this mechanism backwards compatible and optional.
> > ---
> >   libavcodec/Makefile   |  1 +
> >   libavcodec/avcodec.h  |  5 +
> >   libavcodec/cuviddec.c |  2 ++
> >   libavcodec/decode.c   | 12 
> >   libavcodec/internal.h |  5 +
> >   5 files changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index fa3ab8f08a..3e0d654541 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -820,6 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   += adpcm.o 
> > adpcm_data.o
> >   OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o adpcm_data.o
> >   
> >   # hardware accelerators
> > +OBJS-$(CONFIG_CUVID)  += cuvid.o
> >   OBJS-$(CONFIG_D3D11VA)+= dxva2.o
> >   OBJS-$(CONFIG_DXVA2)  += dxva2.o
> >   OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 52cc5b0ca0..ecc49e5643 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -4000,6 +4000,11 @@ typedef struct AVHWAccel {
> >* Internal hwaccel capabilities.
> >*/
> >   int caps_internal;
> > +
> > +/**
> > + * Some hwaccels are ambiguous if only  
> 
> This seems to be truncated?

Fixed locally with:

/**
 * Some hwaccels are ambiguous if only the id and pix_fmt fields are used.
 * If non-NULL, the associated AVCodec must have
 * FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS set.
 */
const AVClass *decoder_class;

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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec: allow multiple hwaccels for the same codec/pixfmt

[Timo Rothenpieler]

Am 03.10.2017 um 15:15 schrieb wm4:

Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
This means it's impossible to have 2 decoders for the same codec and
using the same opaque hardware pixel format.

This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
support, but it's a full stream decoder, using NVIDIA's codec parser.
The Libav one is a true hwaccel, which is based on the builtin software
decoders.

Fix this by introducing another field to disambiguate AVHWAccels, and
use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS makes
this mechanism backwards compatible and optional.
---
  libavcodec/Makefile   |  1 +
  libavcodec/avcodec.h  |  5 +
  libavcodec/cuviddec.c |  2 ++
  libavcodec/decode.c   | 12 
  libavcodec/internal.h |  5 +
  5 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fa3ab8f08a..3e0d654541 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -820,6 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   += adpcm.o 
adpcm_data.o
  OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o adpcm_data.o
  
  # hardware accelerators

+OBJS-$(CONFIG_CUVID)  += cuvid.o
  OBJS-$(CONFIG_D3D11VA)+= dxva2.o
  OBJS-$(CONFIG_DXVA2)  += dxva2.o
  OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0ca0..ecc49e5643 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4000,6 +4000,11 @@ typedef struct AVHWAccel {
   * Internal hwaccel capabilities.
   */
  int caps_internal;
+
+/**
+ * Some hwaccels are ambiguous if only


This seems to be truncated?


+ */
+const AVClass *decoder_class;
  } AVHWAccel;
  
  /**

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 2ba8e00c6a..6370348639 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -1106,6 +1106,7 @@ static const AVOption options[] = {
  .type   = AVMEDIA_TYPE_VIDEO, \
  .id = AV_CODEC_ID_##X, \
  .pix_fmt= AV_PIX_FMT_CUDA, \
+.decoder_class  = ##_cuvid_class, \
  }; \
  AVCodec ff_##x##_cuvid_decoder = { \
  .name   = #x "_cuvid", \
@@ -1120,6 +1121,7 @@ static const AVOption options[] = {
  .receive_frame  = cuvid_output_frame, \
  .flush  = cuvid_flush, \
  .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING, \
+.caps_internal  = FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS, \
  .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_CUDA, \
  AV_PIX_FMT_NV12, \
  AV_PIX_FMT_P010, \
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 668ef9667f..7060f6a3b7 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1152,15 +1152,19 @@ enum AVPixelFormat avcodec_default_get_format(struct 
AVCodecContext *s, const en
  return fmt[0];
  }
  
-static AVHWAccel *find_hwaccel(enum AVCodecID codec_id,

+static AVHWAccel *find_hwaccel(AVCodecContext *avctx,
 enum AVPixelFormat pix_fmt)
  {
  AVHWAccel *hwaccel = NULL;
+const AVClass *av_class =
+(avctx->codec->caps_internal & FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS)
+? avctx->av_class : NULL;
  
-while ((hwaccel = av_hwaccel_next(hwaccel)))

-if (hwaccel->id == codec_id
+while ((hwaccel = av_hwaccel_next(hwaccel))) {
+if (hwaccel->decoder_class == av_class && hwaccel->id == 
avctx->codec_id
  && hwaccel->pix_fmt == pix_fmt)
  return hwaccel;
+}
  return NULL;
  }
  
@@ -1168,7 +1172,7 @@ static int setup_hwaccel(AVCodecContext *avctx,

   const enum AVPixelFormat fmt,
   const char *name)
  {
-AVHWAccel *hwa = find_hwaccel(avctx->codec_id, fmt);
+AVHWAccel *hwa = find_hwaccel(avctx, fmt);
  int ret= 0;
  
  if (!hwa) {

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index faa923c11f..0177ea6521 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -69,6 +69,11 @@
   */
  #define FF_CODEC_CAP_SLICE_THREAD_HAS_MF(1 << 5)
  
+/**

+ * Allow only AVHWAccels which have a matching decoder_class field.
+ */
+#define FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS  (1 << 6)
+
  #ifdef TRACE
  #   define ff_tlog(ctx, ...) av_log(ctx, AV_LOG_TRACE, __VA_ARGS__)
  #else





smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/7] avcodec/cuvid: rename cuvid.c to cuviddec.c

[Timo Rothenpieler]

LGTM



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mp3dec: Fix definition of MIDDLE_BITS

[Ingo Brückl]

The number of bits from bit #m to #n is n - m plus 1.

Signed-off-by: Ingo Brückl 
---
 libavformat/mp3dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 0924a57843..a5c4f2ea12 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -142,7 +142,7 @@ static void mp3_parse_info_tag(AVFormatContext *s, AVStream 
*st,
MPADecodeHeader *c, uint32_t spf)
 {
 #define LAST_BITS(k, n) ((k) & ((1 << (n)) - 1))
-#define MIDDLE_BITS(k, m, n) LAST_BITS((k) >> (m), ((n) - (m)))
+#define MIDDLE_BITS(k, m, n) LAST_BITS((k) >> (m), ((n) - (m) + 1))

 uint16_t crc;
 uint32_t v;
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 10:27 AM, wm4 wrote:
> On Tue, 3 Oct 2017 10:23:08 -0300
> James Almer  wrote:
> 
>> On 10/3/2017 5:18 AM, wm4 wrote:
>>> On Mon, 2 Oct 2017 21:34:18 +0200
>>> Michael Niedermayer  wrote:
>>>   
 On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:  
> Do it during install instead, like with the libraries.
>
> There's no benefit making a stripped copy of the CLI tools in the
> build folder. Doing it during install saves build time and storage
> space.
>
> Signed-off-by: James Almer 

 Iam not sure this is a good idea

 the build binaries and installed binaries would differ, thats bound
 to lead to some confusion and problems  
>>>
>>> Uh, doing stripping on installing is pretty common.
>>>
>>> You know what I find confusing? That it's literally impossible to use a
>>> debugger on FFmpeg. There are a bunch of obscure flags which actually
>>> stop the damn build script from stripping the libs and which bring down
>>> the optimization level, but even then the forced DCE requirement fucks
>>> with debugging.  
>>
>> This has nothing to do with the patch and it's a discussion for another
>> thread.
> 
> The second part, sure. The first part not. autotools for example
> generates an install-strip target. AFAIK debug infos are always
> generated? In any case, that means it doesn't strip them in-tree.

Debug symbols are always generated and stripping always happens unless
--disable-debug and --disable-stripping are used respectively during
configure.

And yes, that's the point of this patch. Strip binaries on install and
keep the build folder free of duplicates, same as we do with shared
libraries. What gets installed is not affected.

> 
>> I'd like to focus specifically on the patch and its effects, as I'm
>> still trying to understand why two people say it would confuse users or
>> lead to problems.
> 
> At this point I think Michael is going to argue any change in behavior
> will be "confusing". With that attitude you can't fix anything.

I'd rather have him explain and not others guess or interpret, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[wm4]

On Tue, 3 Oct 2017 10:23:08 -0300
James Almer  wrote:

> On 10/3/2017 5:18 AM, wm4 wrote:
> > On Mon, 2 Oct 2017 21:34:18 +0200
> > Michael Niedermayer  wrote:
> >   
> >> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:  
> >>> Do it during install instead, like with the libraries.
> >>>
> >>> There's no benefit making a stripped copy of the CLI tools in the
> >>> build folder. Doing it during install saves build time and storage
> >>> space.
> >>>
> >>> Signed-off-by: James Almer 
> >>
> >> Iam not sure this is a good idea
> >>
> >> the build binaries and installed binaries would differ, thats bound
> >> to lead to some confusion and problems  
> > 
> > Uh, doing stripping on installing is pretty common.
> > 
> > You know what I find confusing? That it's literally impossible to use a
> > debugger on FFmpeg. There are a bunch of obscure flags which actually
> > stop the damn build script from stripping the libs and which bring down
> > the optimization level, but even then the forced DCE requirement fucks
> > with debugging.  
> 
> This has nothing to do with the patch and it's a discussion for another
> thread.

The second part, sure. The first part not. autotools for example
generates an install-strip target. AFAIK debug infos are always
generated? In any case, that means it doesn't strip them in-tree.

> I'd like to focus specifically on the patch and its effects, as I'm
> still trying to understand why two people say it would confuse users or
> lead to problems.

At this point I think Michael is going to argue any change in behavior
will be "confusing". With that attitude you can't fix anything.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 5:18 AM, wm4 wrote:
> On Mon, 2 Oct 2017 21:34:18 +0200
> Michael Niedermayer  wrote:
> 
>> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:
>>> Do it during install instead, like with the libraries.
>>>
>>> There's no benefit making a stripped copy of the CLI tools in the
>>> build folder. Doing it during install saves build time and storage
>>> space.
>>>
>>> Signed-off-by: James Almer   
>>
>> Iam not sure this is a good idea
>>
>> the build binaries and installed binaries would differ, thats bound
>> to lead to some confusion and problems
> 
> Uh, doing stripping on installing is pretty common.
> 
> You know what I find confusing? That it's literally impossible to use a
> debugger on FFmpeg. There are a bunch of obscure flags which actually
> stop the damn build script from stripping the libs and which bring down
> the optimization level, but even then the forced DCE requirement fucks
> with debugging.

This has nothing to do with the patch and it's a discussion for another
thread.

I'd like to focus specifically on the patch and its effects, as I'm
still trying to understand why two people say it would confuse users or
lead to problems.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/7] decode: add a per-frame private data for hwaccel use

[wm4]

From: Anton Khirnov 

This will be useful in the CUVID hwaccel. It should also eventually
replace current decoder-specific mechanisms used by various other
hwaccels.

Merges Libav commit 704311b2946d74a80f65906961cd9baaa18683a3.
---
 libavcodec/decode.c | 3 +++
 libavcodec/decode.h | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a2d3d6a3d6..668ef9667f 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1649,6 +1649,9 @@ static void decode_data_free(void *opaque, uint8_t *data)
 if (fdd->post_process_opaque_free)
 fdd->post_process_opaque_free(fdd->post_process_opaque);
 
+if (fdd->hwaccel_priv_free)
+fdd->hwaccel_priv_free(fdd->hwaccel_priv);
+
 av_freep();
 }
 
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 7ca0a2799f..ab5260e641 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -49,6 +49,12 @@ typedef struct FrameDecodeData {
 int (*post_process)(void *logctx, AVFrame *frame);
 void *post_process_opaque;
 void (*post_process_opaque_free)(void *opaque);
+
+/**
+ * Per-frame private data for hwaccels.
+ */
+void *hwaccel_priv;
+void (*hwaccel_priv_free)(void *priv);
 } FrameDecodeData;
 
 /**
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[wm4]

From: Anton Khirnov 

Use the AVFrame.opaque_ref field. The original user's opaque_ref is
wrapped in the lavc struct and then unwrapped before the frame is
returned to the caller.

This new struct will be useful in the following commits.

Merges Libav commit 359a8a3e2d1194b52b6c386f94fd0929567dfb67.
---
 libavcodec/decode.c | 61 +++--
 libavcodec/decode.h | 13 
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 437b848248..04f7156154 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -640,6 +640,26 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 if (ret == AVERROR_EOF)
 avci->draining_done = 1;
 
+/* unwrap the per-frame decode data and restore the original opaque_ref*/
+if (!ret) {
+/* the only case where decode data is not set should be decoders
+ * that do not call ff_get_buffer() */
+av_assert0((frame->opaque_ref && frame->opaque_ref->size == 
sizeof(FrameDecodeData)) ||
+   !(avctx->codec->capabilities & AV_CODEC_CAP_DR1));
+
+if (frame->opaque_ref) {
+FrameDecodeData *fdd;
+AVBufferRef *user_opaque_ref;
+
+fdd = (FrameDecodeData*)frame->opaque_ref->data;
+
+user_opaque_ref = fdd->user_opaque_ref;
+fdd->user_opaque_ref = NULL;
+av_buffer_unref(>opaque_ref);
+frame->opaque_ref = user_opaque_ref;
+}
+}
+
 return ret;
 }
 
@@ -1612,6 +1632,37 @@ static void validate_avframe_allocation(AVCodecContext 
*avctx, AVFrame *frame)
 }
 }
 
+static void decode_data_free(void *opaque, uint8_t *data)
+{
+FrameDecodeData *fdd = (FrameDecodeData*)data;
+
+av_buffer_unref(>user_opaque_ref);
+
+av_freep();
+}
+
+static int attach_decode_data(AVFrame *frame)
+{
+AVBufferRef *fdd_buf;
+FrameDecodeData *fdd;
+
+fdd = av_mallocz(sizeof(*fdd));
+if (!fdd)
+return AVERROR(ENOMEM);
+
+fdd_buf = av_buffer_create((uint8_t*)fdd, sizeof(*fdd), decode_data_free,
+   NULL, AV_BUFFER_FLAG_READONLY);
+if (!fdd_buf) {
+av_freep();
+return AVERROR(ENOMEM);
+}
+
+fdd->user_opaque_ref = frame->opaque_ref;
+frame->opaque_ref= fdd_buf;
+
+return 0;
+}
+
 static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int 
flags)
 {
 const AVHWAccel *hwaccel = avctx->hwaccel;
@@ -1648,8 +1699,14 @@ static int get_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame, int flags)
 avctx->sw_pix_fmt = avctx->pix_fmt;
 
 ret = avctx->get_buffer2(avctx, frame, flags);
-if (ret >= 0)
-validate_avframe_allocation(avctx, frame);
+if (ret < 0)
+goto end;
+
+validate_avframe_allocation(avctx, frame);
+
+ret = attach_decode_data(frame);
+if (ret < 0)
+goto end;
 
 end:
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions &&
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index c9630228dc..ab8327f95c 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -21,8 +21,21 @@
 #ifndef AVCODEC_DECODE_H
 #define AVCODEC_DECODE_H
 
+#include "libavutil/buffer.h"
+
 #include "avcodec.h"
 
+/**
+ * This struct stores per-frame lavc-internal data and is attached to it via
+ * opaque_ref.
+ */
+typedef struct FrameDecodeData {
+/**
+ * The original user-set opaque_ref.
+ */
+AVBufferRef *user_opaque_ref;
+} FrameDecodeData;
+
 /**
  * Called by decoders to get the next packet for decoding.
  *
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 5/7] avcodec/cuvid: rename cuvid.c to cuviddec.c

[wm4]

cuvid.c is used by Libav's CUVID hwaccel. Resolve the conflict and
avoid future merge problems by renaming our decoder.
---
 libavcodec/Makefile| 10 +-
 libavcodec/{cuvid.c => cuviddec.c} |  0
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename libavcodec/{cuvid.c => cuviddec.c} (100%)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c4ec09b1c4..fa3ab8f08a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -331,7 +331,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
h264_cabac.o h264_cavlc.o \
   h264_mb.o h264_picture.o \
   h264_refs.o h264_sei.o \
   h264_slice.o h264data.o
-OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuvid.o
+OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
@@ -351,7 +351,7 @@ OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
 OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
   hevc_cabac.o hevc_refs.o hevcpred.o  
  \
   hevcdsp.o hevc_filter.o hevc_data.o
-OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuvid.o
+OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_HEVC_NVENC_ENCODER)  += nvenc_hevc.o
 OBJS-$(CONFIG_NVENC_HEVC_ENCODER)  += nvenc_hevc.o
@@ -616,7 +616,7 @@ OBJS-$(CONFIG_VC1_DECODER) += vc1dec.o 
vc1_block.o vc1_loopfilter.o
   vc1_mc.o vc1_pred.o vc1.o vc1data.o \
   msmpeg4dec.o msmpeg4.o msmpeg4data.o 
\
   wmv2dsp.o wmv2data.o
-OBJS-$(CONFIG_VC1_CUVID_DECODER)   += cuvid.o
+OBJS-$(CONFIG_VC1_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
 OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec_other.o
 OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
@@ -635,7 +635,7 @@ OBJS-$(CONFIG_VP6_DECODER) += vp6.o vp56.o 
vp56data.o \
   vp6dsp.o vp56rac.o
 OBJS-$(CONFIG_VP7_DECODER) += vp8.o vp56rac.o
 OBJS-$(CONFIG_VP8_DECODER) += vp8.o vp56rac.o
-OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuvid.o
+OBJS-$(CONFIG_VP8_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VP8_MEDIACODEC_DECODER)  += mediacodecdec.o
 OBJS-$(CONFIG_VP8_QSV_DECODER) += qsvdec_other.o
 OBJS-$(CONFIG_VP8_RKMPP_DECODER)   += rkmppdec.o
@@ -645,7 +645,7 @@ OBJS-$(CONFIG_VP8_V4L2M2M_ENCODER) += v4l2_m2m_enc.o
 OBJS-$(CONFIG_VP9_DECODER) += vp9.o vp9data.o vp9dsp.o vp9lpf.o 
vp9recon.o \
   vp9block.o vp9prob.o vp9mvs.o 
vp56rac.o \
   vp9dsp_8bpp.o vp9dsp_10bpp.o 
vp9dsp_12bpp.o
-OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuvid.o
+OBJS-$(CONFIG_VP9_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VP9_MEDIACODEC_DECODER)  += mediacodecdec.o
 OBJS-$(CONFIG_VP9_RKMPP_DECODER)   += rkmppdec.o
 OBJS-$(CONFIG_VP9_VAAPI_ENCODER)   += vaapi_encode_vp9.o
diff --git a/libavcodec/cuvid.c b/libavcodec/cuviddec.c
similarity index 100%
rename from libavcodec/cuvid.c
rename to libavcodec/cuviddec.c
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/7] decode: avoid leaks on failure in ff_get_buffer()

[wm4]

From: Anton Khirnov 

If the get_buffer() call fails, the frame might have some side data
already set. Make sure it gets freed.

CC: libav-sta...@libav.org

Merges Libav commit de77671438c24ffea93398c8dc885d4dd04477de.
---
 libavcodec/decode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 1337ffb527..437b848248 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1658,6 +1658,9 @@ end:
 frame->height = avctx->height;
 }
 
+if (ret < 0)
+av_frame_unref(frame);
+
 return ret;
 }
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 6/7] avcodec: allow multiple hwaccels for the same codec/pixfmt

[wm4]

Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
This means it's impossible to have 2 decoders for the same codec and
using the same opaque hardware pixel format.

This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
support, but it's a full stream decoder, using NVIDIA's codec parser.
The Libav one is a true hwaccel, which is based on the builtin software
decoders.

Fix this by introducing another field to disambiguate AVHWAccels, and
use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS makes
this mechanism backwards compatible and optional.
---
 libavcodec/Makefile   |  1 +
 libavcodec/avcodec.h  |  5 +
 libavcodec/cuviddec.c |  2 ++
 libavcodec/decode.c   | 12 
 libavcodec/internal.h |  5 +
 5 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fa3ab8f08a..3e0d654541 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -820,6 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   += adpcm.o 
adpcm_data.o
 OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o adpcm_data.o
 
 # hardware accelerators
+OBJS-$(CONFIG_CUVID)  += cuvid.o
 OBJS-$(CONFIG_D3D11VA)+= dxva2.o
 OBJS-$(CONFIG_DXVA2)  += dxva2.o
 OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0ca0..ecc49e5643 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4000,6 +4000,11 @@ typedef struct AVHWAccel {
  * Internal hwaccel capabilities.
  */
 int caps_internal;
+
+/**
+ * Some hwaccels are ambiguous if only
+ */
+const AVClass *decoder_class;
 } AVHWAccel;
 
 /**
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 2ba8e00c6a..6370348639 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -1106,6 +1106,7 @@ static const AVOption options[] = {
 .type   = AVMEDIA_TYPE_VIDEO, \
 .id = AV_CODEC_ID_##X, \
 .pix_fmt= AV_PIX_FMT_CUDA, \
+.decoder_class  = ##_cuvid_class, \
 }; \
 AVCodec ff_##x##_cuvid_decoder = { \
 .name   = #x "_cuvid", \
@@ -1120,6 +1121,7 @@ static const AVOption options[] = {
 .receive_frame  = cuvid_output_frame, \
 .flush  = cuvid_flush, \
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING, \
+.caps_internal  = FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS, \
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_CUDA, \
 AV_PIX_FMT_NV12, \
 AV_PIX_FMT_P010, \
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 668ef9667f..7060f6a3b7 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1152,15 +1152,19 @@ enum AVPixelFormat avcodec_default_get_format(struct 
AVCodecContext *s, const en
 return fmt[0];
 }
 
-static AVHWAccel *find_hwaccel(enum AVCodecID codec_id,
+static AVHWAccel *find_hwaccel(AVCodecContext *avctx,
enum AVPixelFormat pix_fmt)
 {
 AVHWAccel *hwaccel = NULL;
+const AVClass *av_class =
+(avctx->codec->caps_internal & FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS)
+? avctx->av_class : NULL;
 
-while ((hwaccel = av_hwaccel_next(hwaccel)))
-if (hwaccel->id == codec_id
+while ((hwaccel = av_hwaccel_next(hwaccel))) {
+if (hwaccel->decoder_class == av_class && hwaccel->id == 
avctx->codec_id
 && hwaccel->pix_fmt == pix_fmt)
 return hwaccel;
+}
 return NULL;
 }
 
@@ -1168,7 +1172,7 @@ static int setup_hwaccel(AVCodecContext *avctx,
  const enum AVPixelFormat fmt,
  const char *name)
 {
-AVHWAccel *hwa = find_hwaccel(avctx->codec_id, fmt);
+AVHWAccel *hwa = find_hwaccel(avctx, fmt);
 int ret= 0;
 
 if (!hwa) {
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index faa923c11f..0177ea6521 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -69,6 +69,11 @@
  */
 #define FF_CODEC_CAP_SLICE_THREAD_HAS_MF(1 << 5)
 
+/**
+ * Allow only AVHWAccels which have a matching decoder_class field.
+ */
+#define FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS  (1 << 6)
+
 #ifdef TRACE
 #   define ff_tlog(ctx, ...) av_log(ctx, AV_LOG_TRACE, __VA_ARGS__)
 #else
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 0/7] Merge Libav cuvid hwaccel

[wm4]

Some complications due to the clash with our own implementation, which
is very different and conceptually incompatible.

Anton Khirnov (5):
  decode: avoid leaks on failure in ff_get_buffer()
  decode: add a method for attaching lavc-internal data to frames
  decode: add a mechanism for performing delayed processing on the
decoded frames
  decode: add a per-frame private data for hwaccel use
  h264dec: add a CUVID hwaccel

wm4 (2):
  avcodec/cuvid: rename cuvid.c to cuviddec.c
  avcodec: allow multiple hwaccels for the same codec/pixfmt

 Changelog   |1 +
 configure   |9 +-
 fftools/ffmpeg.h|1 +
 fftools/ffmpeg_opt.c|4 +
 libavcodec/Makefile |   12 +-
 libavcodec/allcodecs.c  |1 +
 libavcodec/avcodec.h|5 +
 libavcodec/cuvid.c  | 1321 +++
 libavcodec/cuvid.h  |   62 +++
 libavcodec/cuvid_h264.c |  176 +++
 libavcodec/cuviddec.c   | 1166 +
 libavcodec/decode.c |   90 +++-
 libavcodec/decode.h |   34 ++
 libavcodec/h264_slice.c |6 +-
 libavcodec/internal.h   |5 +
 15 files changed, 1852 insertions(+), 1041 deletions(-)
 create mode 100644 libavcodec/cuvid.h
 create mode 100644 libavcodec/cuvid_h264.c
 create mode 100644 libavcodec/cuviddec.c

-- 
2.14.1

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

[FFmpeg-devel] [PATCH 3/7] decode: add a mechanism for performing delayed processing on the decoded frames

[wm4]

From: Anton Khirnov 

This will be useful in the CUVID hwaccel.

Merges Libav commit badf0951f54c1332e77455dc40398f3512540c1b.
---
 libavcodec/decode.c | 11 +++
 libavcodec/decode.h | 15 +++
 2 files changed, 26 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 04f7156154..a2d3d6a3d6 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -653,6 +653,14 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 
 fdd = (FrameDecodeData*)frame->opaque_ref->data;
 
+if (fdd->post_process) {
+ret = fdd->post_process(avctx, frame);
+if (ret < 0) {
+av_frame_unref(frame);
+return ret;
+}
+}
+
 user_opaque_ref = fdd->user_opaque_ref;
 fdd->user_opaque_ref = NULL;
 av_buffer_unref(>opaque_ref);
@@ -1638,6 +1646,9 @@ static void decode_data_free(void *opaque, uint8_t *data)
 
 av_buffer_unref(>user_opaque_ref);
 
+if (fdd->post_process_opaque_free)
+fdd->post_process_opaque_free(fdd->post_process_opaque);
+
 av_freep();
 }
 
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index ab8327f95c..7ca0a2799f 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -22,6 +22,7 @@
 #define AVCODEC_DECODE_H
 
 #include "libavutil/buffer.h"
+#include "libavutil/frame.h"
 
 #include "avcodec.h"
 
@@ -34,6 +35,20 @@ typedef struct FrameDecodeData {
  * The original user-set opaque_ref.
  */
 AVBufferRef *user_opaque_ref;
+
+/**
+ * The callback to perform some delayed processing on the frame right
+ * before it is returned to the caller.
+ *
+ * @note This code is called at some unspecified point after the frame is
+ * returned from the decoder's decode/receive_frame call. Therefore it 
cannot rely
+ * on AVCodecContext being in any specific state, so it does not get to
+ * access AVCodecContext directly at all. All the state it needs must be
+ * stored in the post_process_opaque object.
+ */
+int (*post_process)(void *logctx, AVFrame *frame);
+void *post_process_opaque;
+void (*post_process_opaque_free)(void *opaque);
 } FrameDecodeData;
 
 /**
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 7/7] h264dec: add a CUVID hwaccel

[wm4]

From: Anton Khirnov 

Some parts of the code are based on a patch by
Timo Rothenpieler 

Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.

As a complication, all the names conflict. Add a _hwaccel suffix to the
merged code where needed.

This commit also changes the Libav code to dynamic loading of the
cuda/cuvid libraries. (I wouldn't be able to test with the fixed SDK
anyway, because installing the CUDA SDK on Linux is hell.)

Signed-off-by: wm4 
---
 Changelog   |   1 +
 configure   |   9 +-
 fftools/ffmpeg.h|   1 +
 fftools/ffmpeg_opt.c|   4 +
 libavcodec/Makefile |   3 +-
 libavcodec/allcodecs.c  |   1 +
 libavcodec/cuvid.c  | 431 
 libavcodec/cuvid.h  |  62 +++
 libavcodec/cuvid_h264.c | 176 
 libavcodec/h264_slice.c |   6 +-
 10 files changed, 690 insertions(+), 4 deletions(-)
 create mode 100644 libavcodec/cuvid.c
 create mode 100644 libavcodec/cuvid.h
 create mode 100644 libavcodec/cuvid_h264.c

diff --git a/Changelog b/Changelog
index 03686acef6..6c23d40760 100644
--- a/Changelog
+++ b/Changelog
@@ -88,6 +88,7 @@ version 3.3:
 - Removed asyncts filter (use af_aresample instead)
 - Intel QSV-accelerated VP8 video decoding
 - VAAPI-accelerated deinterlacing
+- NVIDIA CUVID-accelerated H.264 hwaccel decoding
 
 
 version 3.2:
diff --git a/configure b/configure
index ae0eddac6c..3ced5f9466 100755
--- a/configure
+++ b/configure
@@ -307,6 +307,7 @@ External library support:
   --disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
   --enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
   --disable-cuvid  disable Nvidia CUVID support [autodetect]
+  --disable-cuvid-hwaccel  Nvidia CUVID video decode acceleration (via 
hwaccel) [autodetect]
   --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration 
code [autodetect]
   --disable-dxva2  disable Microsoft DirectX 9 video acceleration code 
[autodetect]
   --enable-libdrm  enable DRM code (Linux) [no]
@@ -2664,6 +2665,8 @@ h263_videotoolbox_hwaccel_deps="videotoolbox"
 h263_videotoolbox_hwaccel_select="h263_decoder"
 h264_cuvid_hwaccel_deps="cuda cuvid"
 h264_cuvid_hwaccel_select="h264_cuvid_decoder"
+h264_cuvid_hwaccel_hwaccel_deps="cuda cuvid"
+h264_cuvid_hwaccel_hwaccel_select="h264_decoder"
 h264_d3d11va_hwaccel_deps="d3d11va"
 h264_d3d11va_hwaccel_select="h264_decoder"
 h264_d3d11va2_hwaccel_deps="d3d11va"
@@ -5909,6 +5912,8 @@ done
 enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate -lcuda
 enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
+enabled cuvid_hwaccel && { enabled cuda ||
+   die "ERROR: CUVID hwaccel requires CUDA"; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled decklink  && { require_header DeckLinkAPI.h &&
{ check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API 
version must be >= 10.6.1."; } }
@@ -6266,11 +6271,11 @@ if enabled x86; then
 mingw32*|mingw64*|win32|win64|linux|cygwin*)
 ;;
 *)
-disable cuda cuvid nvenc
+disable cuda cuvid cuvid_hwaccel nvenc
 ;;
 esac
 else
-disable cuda cuvid nvenc
+disable cuda cuvid cuvid_hwaccel nvenc
 fi
 
 enabled nvenc &&
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f6c76bcc55..7deb82af51 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -69,6 +69,7 @@ enum HWAccelID {
 HWACCEL_VAAPI,
 HWACCEL_CUVID,
 HWACCEL_D3D11VA,
+HWACCEL_CUVID_HWACCEL,
 };
 
 typedef struct HWAccel {
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 100fa76e46..1dd21ab591 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -97,6 +97,10 @@ const HWAccel hwaccels[] = {
 #if CONFIG_CUVID
 { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
   AV_HWDEVICE_TYPE_NONE },
+#endif
+#if CONFIG_CUVID_HWACCEL
+{ "cuvid_hwaccel", hwaccel_decode_init, HWACCEL_CUVID_HWACCEL, 
AV_PIX_FMT_CUDA,
+   AV_HWDEVICE_TYPE_CUDA },
 #endif
 { 0 },
 };
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3e0d654541..2367d3144e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -820,7 +820,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_DECODER)   += adpcm.o 
adpcm_data.o
 OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)   += adpcmenc.o adpcm_data.o
 
 # hardware accelerators
-OBJS-$(CONFIG_CUVID)  += cuvid.o
+OBJS-$(CONFIG_CUVID_HWACCEL)  += cuvid.o
 OBJS-$(CONFIG_D3D11VA)+= dxva2.o
 OBJS-$(CONFIG_DXVA2)  += dxva2.o
 OBJS-$(CONFIG_VAAPI)  += 

Re: [FFmpeg-devel] [PATCH] avcodec/encode: don't return immediately on failure

[wm4]

On Tue,  3 Oct 2017 01:55:44 -0300
James Almer  wrote:

> Fixes memleaks introduced by skipping cleanup at the end of the
> functions.
> 
> Regression since a22c6a4796ca1f2cbee6784262515da876fbec22.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/encode.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index c152228c92..841a185738 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -225,10 +225,10 @@ int attribute_align_arg 
> avcodec_encode_audio2(AVCodecContext *avctx,
>  } else if (!avpkt->buf) {
>  AVPacket tmp = { 0 };
>  ret = av_packet_ref(, avpkt);
> -if (ret < 0)
> -return ret;
> -av_packet_unref(avpkt);
> -*avpkt = tmp;
> +if (!ret) {
> +av_packet_unref(avpkt);
> +*avpkt = tmp;
> +}
>  }
>  }
>  
> @@ -324,10 +324,10 @@ int attribute_align_arg 
> avcodec_encode_video2(AVCodecContext *avctx,
>  } else if (!avpkt->buf) {
>  AVPacket tmp = { 0 };
>  ret = av_packet_ref(, avpkt);
> -if (ret < 0)
> -return ret;
> -av_packet_unref(avpkt);
> -*avpkt = tmp;
> +if (!ret) {
> +av_packet_unref(avpkt);
> +*avpkt = tmp;
> +}
>  }
>  }
>  

Seems ok if ret is actually checked in the code below. Something like
"goto cleanup;" on error would be less confusing though.

Also why did you essentially change "!(ret<0)" to "!ret"? In theory, all
positive return values indicate success.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[wm4]

On Mon, 2 Oct 2017 21:34:18 +0200
Michael Niedermayer  wrote:

> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:
> > Do it during install instead, like with the libraries.
> > 
> > There's no benefit making a stripped copy of the CLI tools in the
> > build folder. Doing it during install saves build time and storage
> > space.
> > 
> > Signed-off-by: James Almer   
> 
> Iam not sure this is a good idea
> 
> the build binaries and installed binaries would differ, thats bound
> to lead to some confusion and problems

Uh, doing stripping on installing is pretty common.

You know what I find confusing? That it's literally impossible to use a
debugger on FFmpeg. There are a bunch of obscure flags which actually
stop the damn build script from stripping the libs and which bring down
the optimization level, but even then the forced DCE requirement fucks
with debugging.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] doc: add mailing list faq

[Carl Eugen Hoyos]

2017-10-03 3:14 GMT+02:00 Lou Logan :

> +Some users prefer the third-party Nabble or Gmane interfaces which
> +present the mailing lists in a typical forum layout.

Gmane does not work for a long time.

The reason I also use "uncut" is that "complete" was misunderstood
by some iirc.

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

Re: [FFmpeg-devel] [PATCH 3/7] Removing some debugging

[Carl Eugen Hoyos]

2017-10-03 1:52 GMT+02:00 Bjorn Roche :

> Attached is a patch for paletteuse only.

I tested the following with and without your patch:
$ ffmpeg -i fate-suite/lena.pnm -vf palettegen pal.png
$ ffmpeg -i fate-suite/lena.pnm -i pal.png -lavfi paletteuse out.png

out.png changes with your patch: Is that intended?
The input frame contains no transparency.

Your patch still contains printfs that should be removed
(change them to av_log(DEBUG) if you think they are
useful) and a new warning is shown at compilation:
libavfilter/vf_paletteuse.c: In function ‘colormap_nearest_recursive’:
libavfilter/vf_paletteuse.c:242:5: warning: ISO C90 forbids mixed
declarations and code

Please fix the style: Space after "if", no space after "if ("

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