[FFmpeg-devel] [PATCH 3/3] avcodec/mpeg2_metadata_bsf: fix the AVClass version number

[James Almer]

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

diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index f1f84e6cd9..b9a49ab943 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -294,7 +294,7 @@ static const AVClass mpeg2_metadata_class = {
 .class_name = "mpeg2_metadata_bsf",
 .item_name  = av_default_item_name,
 .option = mpeg2_metadata_options,
-.version= LIBAVCODEC_VERSION_MAJOR,
+.version= LIBAVUTIL_VERSION_INT,
 };
 
 static const enum AVCodecID mpeg2_metadata_codec_ids[] = {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/3] avcodec/h264_metadata_bsf: fix the AVClass version number

[James Almer]

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

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 73e73e96e4..ada40a57c7 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -506,7 +506,7 @@ static const AVClass h264_metadata_class = {
 .class_name = "h264_metadata_bsf",
 .item_name  = av_default_item_name,
 .option = h264_metadata_options,
-.version= LIBAVCODEC_VERSION_MAJOR,
+.version= LIBAVUTIL_VERSION_INT,
 };
 
 static const enum AVCodecID h264_metadata_codec_ids[] = {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/3] avcodec/h265_metadata_bsf: fix the AVClass version number

[James Almer]

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

diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
index 9af5cc256f..67dbe288e3 100644
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -440,7 +440,7 @@ static const AVClass h265_metadata_class = {
 .class_name = "h265_metadata_bsf",
 .item_name  = av_default_item_name,
 .option = h265_metadata_options,
-.version= LIBAVCODEC_VERSION_MAJOR,
+.version= LIBAVUTIL_VERSION_INT,
 };
 
 static const enum AVCodecID h265_metadata_codec_ids[] = {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/videotoolboxenc: add hevc_videotoolbox encoder

[Aman Gupta]

From: Aman Gupta 

---
 configure|   2 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/videotoolboxenc.c | 296 ++-
 3 files changed, 214 insertions(+), 85 deletions(-)

diff --git a/configure b/configure
index 2cf18ecc12..39b9d4cb0c 100755
--- a/configure
+++ b/configure
@@ -2928,6 +2928,8 @@ pcm_mulaw_at_encoder_select="audio_frame_queue"
 chromaprint_muxer_deps="chromaprint"
 h264_videotoolbox_encoder_deps="pthreads"
 h264_videotoolbox_encoder_select="videotoolbox_encoder"
+hevc_videotoolbox_encoder_deps="pthreads"
+hevc_videotoolbox_encoder_select="videotoolbox_encoder"
 libcelt_decoder_deps="libcelt"
 libfdk_aac_decoder_deps="libfdk_aac"
 libfdk_aac_encoder_deps="libfdk_aac"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c817003693..d8be53a52a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -670,6 +670,7 @@ static void register_all(void)
 REGISTER_ENCODER(HEVC_QSV,  hevc_qsv);
 REGISTER_ENCODER(HEVC_V4L2M2M,  hevc_v4l2m2m);
 REGISTER_ENCODER(HEVC_VAAPI,hevc_vaapi);
+REGISTER_ENCODER(HEVC_VIDEOTOOLBOX, hevc_videotoolbox);
 REGISTER_ENCODER(LIBKVAZAAR,libkvazaar);
 REGISTER_DECODER(MJPEG_CUVID,   mjpeg_cuvid);
 REGISTER_ENCODER(MJPEG_QSV, mjpeg_qsv);
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index eba6cc672f..9725964e87 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -35,6 +35,17 @@
 #include "h264_sei.h"
 #include 
 
+#if !HAVE_KCMVIDEOCODECTYPE_HEVC
+enum { kCMVideoCodecType_HEVC = 'hvc1' };
+#endif
+
+typedef OSStatus (*getParameterSetAtIndex)(CMFormatDescriptionRef videoDesc,
+   size_t parameterSetIndex,
+   const uint8_t * _Nullable 
*parameterSetPointerOut,
+   size_t *parameterSetSizeOut,
+   size_t *parameterSetCountOut,
+   int *NALUnitHeaderLengthOut);
+
 //These symbols may not be present
 static struct{
 CFStringRef kCVImageBufferColorPrimaries_ITU_R_2020;
@@ -65,10 +76,15 @@ static struct{
 CFStringRef kVTProfileLevel_H264_High_5_2;
 CFStringRef kVTProfileLevel_H264_High_AutoLevel;
 
+CFStringRef kVTProfileLevel_HEVC_Main_AutoLevel;
+CFStringRef kVTProfileLevel_HEVC_Main10_AutoLevel;
+
 CFStringRef kVTCompressionPropertyKey_RealTime;
 
 CFStringRef 
kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder;
 CFStringRef 
kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder;
+
+getParameterSetAtIndex CMVideoFormatDescriptionGetHEVCParameterSetAtIndex;
 } compat_keys;
 
 #define GET_SYM(symbol, defaultVal) \
@@ -83,6 +99,12 @@ do{  
   \
 static pthread_once_t once_ctrl = PTHREAD_ONCE_INIT;
 
 static void loadVTEncSymbols(){
+compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex =
+(getParameterSetAtIndex)dlsym(
+RTLD_DEFAULT,
+"CMVideoFormatDescriptionGetHEVCParameterSetAtIndex"
+);
+
 GET_SYM(kCVImageBufferColorPrimaries_ITU_R_2020,   "ITU_R_2020");
 GET_SYM(kCVImageBufferTransferFunction_ITU_R_2020, "ITU_R_2020");
 GET_SYM(kCVImageBufferYCbCrMatrix_ITU_R_2020,  "ITU_R_2020");
@@ -111,6 +133,9 @@ static void loadVTEncSymbols(){
 GET_SYM(kVTProfileLevel_H264_High_5_2,   "H264_High_5_2");
 GET_SYM(kVTProfileLevel_H264_High_AutoLevel, "H264_High_AutoLevel");
 
+GET_SYM(kVTProfileLevel_HEVC_Main_AutoLevel, "HEVC_Main_AutoLevel");
+GET_SYM(kVTProfileLevel_HEVC_Main10_AutoLevel,   "HEVC_Main10_AutoLevel");
+
 GET_SYM(kVTCompressionPropertyKey_RealTime, "RealTime");
 
 GET_SYM(kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder,
@@ -133,6 +158,13 @@ typedef enum VTH264Entropy{
 VT_CABAC
 } VTH264Entropy;
 
+typedef enum VT_HEVCProfile {
+HEVC_PROF_AUTO,
+HEVC_PROF_MAIN,
+HEVC_PROF_MAIN10,
+HEVC_PROF_COUNT
+} VT_HEVCProfile;
+
 static const uint8_t start_code[] = { 0, 0, 0, 1 };
 
 typedef struct ExtraSEI {
@@ -149,10 +181,12 @@ typedef struct BufNode {
 
 typedef struct VTEncContext {
 AVClass *class;
+enum AVCodecID codec_id;
 VTCompressionSessionRef session;
 CFStringRef ycbcr_matrix;
 CFStringRef color_primaries;
 CFStringRef transfer_function;
+getParameterSetAtIndex get_param_set_func;
 
 pthread_mutex_t lock;
 pthread_cond_t  cv_sample_sent;
@@ -348,6 +382,7 @@ static CMVideoCodecType get_cm_codec_type(enum AVCodecID id)
 {
 switch (id) {
 case AV_CODEC_ID_H264: return kCMVideoCodecType_H264;
+case AV_CODEC_ID_HEVC: return kCMVideoCodecType_HEVC;
 default:   return 0;
 }
 }
@@ -365,17 

Re: [FFmpeg-devel] [PATCH v4 06/14] avcodec: add decode_params callback to AVHWAccel struct

[Aman Gupta]

On Fri, Nov 10, 2017 at 5:45 PM, James Almer  wrote:

> On 11/10/2017 6:40 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  libavcodec/avcodec.h | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index c4134424f0..2bd46faa50 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3459,6 +3459,20 @@ typedef struct AVHWAccel {
> >   */
> >  int (*start_frame)(AVCodecContext *avctx, const uint8_t *buf,
> uint32_t buf_size);
> >
> > +/**
> > + * Callback for parameter data (SPS/PPS/VPS etc).
> > + *
> > + * Useful for hardware decoders which keep persistent state about
> the
> > + * video parameters, and need to receive any changes to update that
> state.
> > + *
> > + * @param avctx the codec context
> > + * @param type the parameter type
> > + * @param buf the slice data buffer base
> > + * @param buf_size the size of the slice in bytes
> > + * @return zero if successful, a negative value otherwise
> > + */
> > +int (*decode_params)(AVCodecContext *avctx, int type, const
> uint8_t *buf, uint32_t buf_size);
> > +
> >  /**
> >   * Callback for each slice.
> >   *
> >
>
> There's
> https://git.libav.org/?p=libav.git;a=commitdiff;h=
> b46a77f19ddc4b2b5fa3187835ceb602a5244e24s
> in the merge queue, and it would be great if we can make sure we're not
> duplicating efforts or writing incompatible API for the same purpose.
>
> Are these related, and can they coexist?
>

I don't think they're related, and they should be able to coexist without
issues (I already tested my patches against a libav based tree earlier
today).

For the purposes of VideoToolbox, I need the raw SPS/PPS/VPS/SEI_* NALUs so
that they can be fed into the decoder. I've submitted multiple variations
of this patch to the list over the past year. The first simply added a
pix_fmt==VIDEOTOOLBOX check, and it was suggested that I re-implement with
a more generic callback so I added this one in later revisions.

I will say that I'm not fully sold on the callback name "decode_params", so
if anyone has better suggestions I'm all ears.

Aman



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

Re: [FFmpeg-devel] [PATCH v4 06/14] avcodec: add decode_params callback to AVHWAccel struct

[James Almer]

On 11/10/2017 6:40 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/avcodec.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c4134424f0..2bd46faa50 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3459,6 +3459,20 @@ typedef struct AVHWAccel {
>   */
>  int (*start_frame)(AVCodecContext *avctx, const uint8_t *buf, uint32_t 
> buf_size);
>  
> +/**
> + * Callback for parameter data (SPS/PPS/VPS etc).
> + *
> + * Useful for hardware decoders which keep persistent state about the
> + * video parameters, and need to receive any changes to update that 
> state.
> + *
> + * @param avctx the codec context
> + * @param type the parameter type
> + * @param buf the slice data buffer base
> + * @param buf_size the size of the slice in bytes
> + * @return zero if successful, a negative value otherwise
> + */
> +int (*decode_params)(AVCodecContext *avctx, int type, const uint8_t 
> *buf, uint32_t buf_size);
> +
>  /**
>   * Callback for each slice.
>   *
> 

There's
https://git.libav.org/?p=libav.git;a=commitdiff;h=b46a77f19ddc4b2b5fa3187835ceb602a5244e24s
in the merge queue, and it would be great if we can make sure we're not
duplicating efforts or writing incompatible API for the same purpose.

Are these related, and can they coexist?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Fri, Nov 10, 2017 at 05:03:15PM +0100, Timo Rothenpieler wrote:
> From: Anton Khirnov 
> 
> Use the AVFrame.private_ref field.
> 
> This new struct will be useful in the following commits.
> 
> Merges Libav commit 359a8a3e2d1194b52b6c386f94fd0929567dfb67.
> ---
>  libavcodec/decode.c  | 51 
> ++--
>  libavcodec/decode.h  | 11 ++
>  libavcodec/wrapped_avframe.c |  7 ++
>  3 files changed, 67 insertions(+), 2 deletions(-)

this causes assertion failures
ill send you the input file

[wmavoice @ 0x116bdbe0] Superframe encodes > 480 samples (3919), not allowed
==19367==at 0x11B304C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4550)
==19367==by 0x11B3ABC: av_log_default_callback (log.c:355)
==19367==by 0x11B3C5B: av_vlog (log.c:383)
==19367==by 0x11B3C1B: av_log (log.c:375)
==19367==by 0xCFC25F: synth_superframe (wmavoice.c:1731)
==19367==by 0xCFCE23: wmavoice_decode_packet (wmavoice.c:1950)
==19367==by 0x86BD5B: decode_simple_internal (decode.c:397)
==19367==by 0x86C9E2: decode_simple_receive_frame (decode.c:593)
==19367==by 0x86CAAD: decode_receive_frame_internal (decode.c:611)
==19367==by 0x86CF8E: avcodec_receive_frame (decode.c:725)
==19367==by 0x4335A4: decode (ffmpeg.c:2238)
==19367==by 0x433801: decode_audio (ffmpeg.c:2288)
==19367==by 0x434DC2: process_input_packet (ffmpeg.c:2612)
==19367==by 0x43BF5A: process_input (ffmpeg.c:4422)
==19367==by 0x43C503: transcode_step (ffmpeg.c:4542)
==19367==by 0x43C67F: transcode (ffmpeg.c:4596)
==19367==by 0x43CE50: main (ffmpeg.c:4802)
Error while decoding stream #0:0: Invalid data found when processing input
==19367==at 0x11B304C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4550)
==19367==by 0x11B3ABC: av_log_default_callback (log.c:355)
==19367==by 0x11B3C5B: av_vlog (log.c:383)
==19367==by 0x11B3C1B: av_log (log.c:375)
==19367==by 0x435169: process_input_packet (ffmpeg.c:2660)
==19367==by 0x43BF5A: process_input (ffmpeg.c:4422)
==19367==by 0x43C503: transcode_step (ffmpeg.c:4542)
==19367==by 0x43C67F: transcode (ffmpeg.c:4596)
==19367==by 0x43CE50: main (ffmpeg.c:4802)
[wmavoice @ 0x116bdbe0] Invalid frame type VLC code, skipping
==19367==at 0x11B304C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4550)
==19367==by 0x11B3ABC: av_log_default_callback (log.c:355)
==19367==by 0x11B3C5B: av_vlog (log.c:383)
==19367==by 0x11B3C1B: av_log (log.c:375)
==19367==by 0xCFB3E4: synth_frame (wmavoice.c:1486)
==19367==by 0xCFC7FD: synth_superframe (wmavoice.c:1781)
==19367==by 0xCFCCE7: wmavoice_decode_packet (wmavoice.c:1927)
==19367==by 0x86BD5B: decode_simple_internal (decode.c:397)
==19367==by 0x86C9E2: decode_simple_receive_frame (decode.c:593)
==19367==by 0x86CAAD: decode_receive_frame_internal (decode.c:611)
==19367==by 0x86CD25: avcodec_send_packet (decode.c:673)
==19367==by 0x43357A: decode (ffmpeg.c:2231)
==19367==by 0x433801: decode_audio (ffmpeg.c:2288)
==19367==by 0x434DC2: process_input_packet (ffmpeg.c:2612)
==19367==by 0x43BF5A: process_input (ffmpeg.c:4422)
==19367==by 0x43C503: transcode_step (ffmpeg.c:4542)
==19367==by 0x43C67F: transcode (ffmpeg.c:4596)
==19367==by 0x43CE50: main (ffmpeg.c:4802)
[wmavoice @ 0x116bdbe0] WMAPro-in-WMAVoice is not implemented. Update your 
FFmpeg version to the newest one from Git. If the problem still occurs, it 
means that your file has a feature which has not been implemented.
[wmavoice @ 0x116bdbe0] If you want to help, upload a sample of this file to 
ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. 
(ffmpeg-devel@ffmpeg.org)
Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
==19367==at 0x11B304C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4550)
==19367==by 0x11B3ABC: av_log_default_callback (log.c:355)
==19367==by 0x11B3C5B: av_vlog (log.c:383)
==19367==by 0x11B3C1B: av_log (log.c:375)
==19367==by 0x435169: process_input_packet (ffmpeg.c:2660)
==19367==by 0x43BF5A: process_input (ffmpeg.c:4422)
==19367==by 0x43C503: transcode_step (ffmpeg.c:4542)
==19367==by 0x43C67F: transcode (ffmpeg.c:4596)
==19367==by 0x43CE50: main (ffmpeg.c:4802)
Assertion !frame->private_ref failed at libavcodec/decode.c:1599
==19367==at 0x11B304C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4550)
==19367==by 0x11B3ABC: av_log_default_callback (log.c:355)
==19367==by 0x11B3C5B: av_vlog (log.c:383)
==19367==by 0x11B3C1B: av_log (log.c:375)
==19367==by 0x86F7AC: ff_attach_decode_data (decode.c:1599)
==19367==by 0x86FA68: get_buffer_internal (decode.c:1659)
==19367==by 0x86FAF4: ff_get_buffer (decode.c:1678)
==19367==by 0xCFC579: synth_superframe (wmavoice.c:1761)
==19367==by 0xCFCE23: wmavoice_decode_packet (wmavoice.c:1950)
==19367==by 0x86BD5B: decode_simple_internal (decode.c:397)

Re: [FFmpeg-devel] [DEVEL][PATCH v2] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 11/11/2017 à 1:07 AM, Michael Niedermayer a écrit :

On Fri, Nov 10, 2017 at 10:27:48PM +0100, pkv.stream wrote:

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?

just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case

ok I fixed that by using the flag AV_DICT_IGNORE_SUFFIX ; now
-channel_layout:a works as expected.
I fixed also all the styling issues you spotted (mixed declarations,
{} for if etc).

Still not understanding your initial comment though :
'why is the channel_layout option per file and not per stream?'

do you mean o->g->codec_opts is not where I should retrieve the
channel_layout ? if not where from ?

Thanks


[...]


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


  ffmpeg_opt.c |   12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)
849898d28e989ffa5cc598c6fe4d43847b636132  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 6d4f1c14135f9473b77e1c649d0e7bbaeba00a50 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  fftools/ffmpeg_opt.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ca6f10d..cb25d7b 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1785,6 +1785,7 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  AVStream *st;
  OutputStream *ost;
  AVCodecContext *audio_enc;
+AVDictionaryEntry *output_layout;
  
  ost = new_output_stream(o, oc, AVMEDIA_TYPE_AUDIO, source_index);

  st  = ost->st;
@@ -1799,7 +1800,10 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  char *sample_fmt = NULL;
  
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);

-
+output_layout = av_dict_get(o->g->codec_opts,"channel_layout", NULL, 
AV_DICT_IGNORE_SUFFIX);

i didnt try but i assume
this would fail if there are 2 audio streams each with 

Re: [FFmpeg-devel] [DEVEL][PATCH v2] ffmpeg: fix channel_layout bug on non-default layout

[Michael Niedermayer]

On Fri, Nov 10, 2017 at 10:27:48PM +0100, pkv.stream wrote:
> Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :
> >On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:
> >>Hi Michael,
> >>
>   ffmpeg_opt.c |   11 ++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 2af07f4366efdfaf1018bb2ea29be672befe0823  
> 0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
>  From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Mon, 2 Oct 2017 11:14:31 +0200
> Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout
> 
> Fix for ticket 6706.
> The -channel_layout option was not working when the channel layout was not
> a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
> the default layout for 4 channels; or octagonal interpreted as 7.1).
> This led to the spurious auto-insertion of an auto-resampler filter
> remapping the channels even if input and output had identical channel
> layouts.
> The fix operates by directly calling the channel layout if defined in
> options. If the layout is undefined, the default layout is selected as
> before the fix.
> ---
>   ffmpeg_opt.c | 11 ++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 100fa76..cf5a63c 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -1804,6 +1804,12 @@ static OutputStream 
> *new_audio_stream(OptionsContext *o, AVFormatContext *oc, in
>   MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, 
>  oc, st);
> +AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
> +   "channel_layout",
> +   NULL, 
> AV_DICT_MATCH_CASE);
> >>>This doesnt look right
> >>>
> >>>not an issue of the patch as such but
> >>>why is the channel_layout option per file and not per stream?
> >>
> >>just my ignorance; do you mean this is not the right way to retrieve
> >>the channel_layout option from an audio stream ?
> >I think there is more buggy with how the channel_layout is handled
> >
> >try this:
> >./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
> >and this:
> >./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav
> >
> >while it may appear that the are both working this is deceiving.
> >I think only the channel number gets actually used in the 2nd case
> >
> >Look at what your code with av_dict_get() reads.
> >It does not obtain the 5 in the 2nd case
> 
> ok I fixed that by using the flag AV_DICT_IGNORE_SUFFIX ; now
> -channel_layout:a works as expected.
> I fixed also all the styling issues you spotted (mixed declarations,
> {} for if etc).
> 
> Still not understanding your initial comment though :
> 'why is the channel_layout option per file and not per stream?'
> 
> do you mean o->g->codec_opts is not where I should retrieve the
> channel_layout ? if not where from ?
> 
> Thanks
> 
> >[...]
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 

>  ffmpeg_opt.c |   12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 849898d28e989ffa5cc598c6fe4d43847b636132  
> 0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
> From 6d4f1c14135f9473b77e1c649d0e7bbaeba00a50 Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Mon, 2 Oct 2017 11:14:31 +0200
> Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout
> 
> Fix for ticket 6706.
> The -channel_layout option was not working when the channel layout was not
> a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
> the default layout for 4 channels; or octagonal interpreted as 7.1).
> This led to the spurious auto-insertion of an auto-resampler filter
> remapping the channels even if input and output had identical channel
> layouts.
> The fix operates by directly calling the channel layout if defined in
> options. If the layout is undefined, the default layout is selected as
> before the fix.
> ---
>  fftools/ffmpeg_opt.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index ca6f10d..cb25d7b 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -1785,6 +1785,7 @@ static OutputStream *new_audio_stream(OptionsContext 
> *o, AVFormatContext *oc, in
>  AVStream *st;
>  OutputStream *ost;
>  AVCodecContext *audio_enc;
> +AVDictionaryEntry *output_layout;
>  
>  ost = new_output_stream(o, oc, AVMEDIA_TYPE_AUDIO, source_index);
>  st  = ost->st;

> @@ -1799,7 +1800,10 @@ static OutputStream 

[FFmpeg-devel] [PATCH] avformat/utils: preserve AV_PKT_FLAG_DISCARD in parse_packet

[John Stebbins]

---
 libavformat/utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 2b2411ffe7..93a5a00105 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1457,6 +1457,7 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 out_pkt.pts  = st->parser->pts;
 out_pkt.dts  = st->parser->dts;
 out_pkt.pos  = st->parser->pos;
+out_pkt.flags   |= pkt->flags & AV_PKT_FLAG_DISCARD;
 
 if (st->need_parsing == AVSTREAM_PARSE_FULL_RAW)
 out_pkt.pos = st->parser->frame_offset;
-- 
2.13.6

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

[FFmpeg-devel] [RFC] H264 Error Resilience

[Michael Niedermayer]

Hi all

Kieran asked me about h264 ER TODO 

so here are some ideas

H264 features:
Redundant pictures. It would be possible to encode a low bitrate image
for each access unit and use it when the primary picture has lost
slices. This can be limited to slices which would be concealed poorly
if lost. This would increase the bitrate of the h264 stream

Data partitioning. We support data partitioning for MPEG4(-ASP) and
it provided there useful quality gains. This would seperate the
high bitrate textures from low bitrate motion vectors. The later is
much more important for maitaining ok looking images


Error concealment features:
Interlacing support is basically missing, this is obviously
important when the input is interlaced

Future frames are currently only used with B frames, but it would
certainly improve other frames too. For example knowing the next P
frame would mean we know the next frames motion vectors and the previous
frames motion vectors which would help in estimating the motion
vectors any lost area. This would require redecoding the next frame
and thus possibly that is tricky

Finer grained detection of initial error position, currently errors
are detected during decoding and a heuristic is used to cover
several previous MBs so as to cover the whole damaged area.
But it would be possible to analyze the MBs itself  to detect
mismatches accorss MB edges and use this to better estimate
from where concealing must start to maximize quality. Also if
outside information as lost packets is known this too if it does
not 1:1 match slices could be used to make the concealed area
tighter

Testing:
We have little error concealment testing. A few more fate tests to
cover various videos (high/low complexity motion/ no motion) with
different errors (lost slices, reordered slices, damaged bytes/bits)
and comparing (PSNR) vs undamaged input would be usefull.
These could also be usefull to evaluate any changes done to the error
concealment code.


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v4 14/14] avcodec/videotoolbox: fix whitespace

[Rodger Combs]

Patchset LGTM.

> On Nov 10, 2017, at 15:40, Aman Gupta  wrote:
> 
> From: Aman Gupta 
> 
> ---
> libavcodec/videotoolbox.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 9eb06e619f..04c558935d 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -88,7 +88,7 @@ int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, 
> AVFrame *frame)
> 
> CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
> {
> -H264Context *h = avctx->priv_data;
> +H264Context *h = avctx->priv_data;
> CFDataRef data = NULL;
> uint8_t *p;
> int vt_extradata_size = 6 + 2 + h->ps.sps->data_size + 3 + 
> h->ps.pps->data_size;
> @@ -897,7 +897,7 @@ static int videotoolbox_start(AVCodecContext *avctx)
> case kVTVideoDecoderMalfunctionErr:
> av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox malfunction.\n");
> return AVERROR(EINVAL);
> -case kVTVideoDecoderBadDataErr :
> +case kVTVideoDecoderBadDataErr:
> av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox reported invalid 
> data.\n");
> return AVERROR_INVALIDDATA;
> case 0:
> -- 
> 2.14.2
> 

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

[FFmpeg-devel] [PATCH v4 10/14] avcodec/videotoolbox: remove unnecessary if statement

[Aman Gupta]

From: Aman Gupta 

Cosmetic change only.
---
 libavcodec/videotoolbox.c | 68 +++
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index ff8ba41821..fc33dce608 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -702,45 +702,43 @@ static CFDictionaryRef 
videotoolbox_decoder_config_create(CMVideoCodecType codec
  
kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
  kCFBooleanTrue);
 
-if (1) {
-CFMutableDictionaryRef avc_info;
-CFDataRef data = NULL;
-
-avc_info = CFDictionaryCreateMutable(kCFAllocatorDefault,
- 1,
- ,
- );
-
-switch (codec_type) {
-case kCMVideoCodecType_MPEG4Video :
-if (avctx->extradata_size)
-data = videotoolbox_esds_extradata_create(avctx);
-if (data)
-CFDictionarySetValue(avc_info, CFSTR("esds"), data);
-break;
-case kCMVideoCodecType_H264 :
-data = ff_videotoolbox_avcc_extradata_create(avctx);
-if (data)
-CFDictionarySetValue(avc_info, CFSTR("avcC"), data);
-break;
-case kCMVideoCodecType_HEVC :
-data = ff_videotoolbox_hvcc_extradata_create(avctx);
-if (data)
-CFDictionarySetValue(avc_info, CFSTR("hvcC"), data);
-break;
-default:
-break;
-}
+CFMutableDictionaryRef avc_info;
+CFDataRef data = NULL;
 
-CFDictionarySetValue(config_info,
-kCMFormatDescriptionExtension_SampleDescriptionExtensionAtoms,
-avc_info);
+avc_info = CFDictionaryCreateMutable(kCFAllocatorDefault,
+ 1,
+ ,
+ );
 
+switch (codec_type) {
+case kCMVideoCodecType_MPEG4Video :
+if (avctx->extradata_size)
+data = videotoolbox_esds_extradata_create(avctx);
 if (data)
-CFRelease(data);
-
-CFRelease(avc_info);
+CFDictionarySetValue(avc_info, CFSTR("esds"), data);
+break;
+case kCMVideoCodecType_H264 :
+data = ff_videotoolbox_avcc_extradata_create(avctx);
+if (data)
+CFDictionarySetValue(avc_info, CFSTR("avcC"), data);
+break;
+case kCMVideoCodecType_HEVC :
+data = ff_videotoolbox_hvcc_extradata_create(avctx);
+if (data)
+CFDictionarySetValue(avc_info, CFSTR("hvcC"), data);
+break;
+default:
+break;
 }
+
+CFDictionarySetValue(config_info,
+kCMFormatDescriptionExtension_SampleDescriptionExtensionAtoms,
+avc_info);
+
+if (data)
+CFRelease(data);
+
+CFRelease(avc_info);
 return config_info;
 }
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 14/14] avcodec/videotoolbox: fix whitespace

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 9eb06e619f..04c558935d 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -88,7 +88,7 @@ int ff_videotoolbox_alloc_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
 {
-H264Context *h = avctx->priv_data;
+H264Context *h = avctx->priv_data;
 CFDataRef data = NULL;
 uint8_t *p;
 int vt_extradata_size = 6 + 2 + h->ps.sps->data_size + 3 + 
h->ps.pps->data_size;
@@ -897,7 +897,7 @@ static int videotoolbox_start(AVCodecContext *avctx)
 case kVTVideoDecoderMalfunctionErr:
 av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox malfunction.\n");
 return AVERROR(EINVAL);
-case kVTVideoDecoderBadDataErr :
+case kVTVideoDecoderBadDataErr:
 av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox reported invalid data.\n");
 return AVERROR_INVALIDDATA;
 case 0:
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 07/14] avcodec/h264: implement new decode_params callback for PPS/SPS

[Aman Gupta]

From: Aman Gupta 

This callback will be used by the VideoToolbox H264 hwaccel so that it
can receive SPS and PPS NALUs. VideoToolbox requires PPS changes to be
fed into the decoder session, and for the session to be recreated when
the SPS changes.
---
 libavcodec/h264dec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 517f6acc13..be187eb5f4 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -713,6 +713,14 @@ static int decode_nal_units(H264Context *h, const uint8_t 
*buf, int buf_size)
 break;
 case H264_NAL_SPS: {
 GetBitContext tmp_gb = nal->gb;
+if (avctx->hwaccel && avctx->hwaccel->decode_params) {
+ret = avctx->hwaccel->decode_params(avctx,
+nal->type,
+nal->raw_data,
+nal->raw_size);
+if (ret < 0)
+goto end;
+}
 if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 0) >= 
0)
 break;
 av_log(h->avctx, AV_LOG_DEBUG,
@@ -724,6 +732,14 @@ static int decode_nal_units(H264Context *h, const uint8_t 
*buf, int buf_size)
 break;
 }
 case H264_NAL_PPS:
+if (avctx->hwaccel && avctx->hwaccel->decode_params) {
+ret = avctx->hwaccel->decode_params(avctx,
+nal->type,
+nal->raw_data,
+nal->raw_size);
+if (ret < 0)
+goto end;
+}
 ret = ff_h264_decode_picture_parameter_set(>gb, avctx, >ps,
nal->size_bits);
 if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 09/14] avcodec/videotoolbox: create avcC even when h264 extradata is missing

[Aman Gupta]

From: Aman Gupta 

Removes the avctx->extradata_size requirement when creating avcC/hvcC, since
avctx->extradata is only used in the esds code path.

This fixes an issue where the VideoToolbox decoder would not work unless
avformat_find_stream_info() was called.
---
 libavcodec/videotoolbox.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 2496e4969c..ff8ba41821 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -702,7 +702,7 @@ static CFDictionaryRef 
videotoolbox_decoder_config_create(CMVideoCodecType codec
  
kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
  kCFBooleanTrue);
 
-if (avctx->extradata_size) {
+if (1) {
 CFMutableDictionaryRef avc_info;
 CFDataRef data = NULL;
 
@@ -713,7 +713,8 @@ static CFDictionaryRef 
videotoolbox_decoder_config_create(CMVideoCodecType codec
 
 switch (codec_type) {
 case kCMVideoCodecType_MPEG4Video :
-data = videotoolbox_esds_extradata_create(avctx);
+if (avctx->extradata_size)
+data = videotoolbox_esds_extradata_create(avctx);
 if (data)
 CFDictionarySetValue(avc_info, CFSTR("esds"), data);
 break;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 13/14] avcodec/videotoolboxenc: remove spurious warning

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/videotoolboxenc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index eba6cc672f..a7bef72da8 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1853,8 +1853,6 @@ static int get_cv_pixel_info(
"Color range not set for %s. Using MPEG range.\n",
av_get_pix_fmt_name(av_format));
 }
-
-av_log(avctx, AV_LOG_WARNING, "");
 }
 
 switch (av_format) {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 08/14] avcodec/videotoolbox: use decode_params to propagate H264 PPS changes and restart on SPS changes

[Aman Gupta]

From: Aman Gupta 

This fixes decoding of H264 video samples with SPS and PPS changes.

See for example https://s3.amazonaws.com/tmm1/videotoolbox/spschange.ts,
which previously stalled the decoder and failed to produce any new frames
after the SPS change.

If the VideoToolbox session needs to be restarted, and
videotoolbox_start() fails for some reason (for instance, if the video
is interlaced and the decoder is running on iOS), avcodec will return
AVERROR_EXTERNAL. This can be used by the API user to switch to another
decoder.
---
 libavcodec/videotoolbox.c | 43 +--
 libavcodec/vt_internal.h  |  6 ++
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 9db2e1116b..2496e4969c 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -42,6 +42,9 @@ enum { kCMVideoCodecType_HEVC = 'hvc1' };
 
 #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
 
+static void videotoolbox_stop(AVCodecContext *avctx);
+static int videotoolbox_start(AVCodecContext *avctx);
+
 static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
 {
 CVPixelBufferRef cv_buffer = (CVImageBufferRef)data;
@@ -307,6 +310,27 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext *avctx,
 return 0;
 }
 
+static int videotoolbox_h264_decode_params(AVCodecContext *avctx,
+   int type,
+   const uint8_t *buffer,
+   uint32_t size)
+{
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+
+if (type == H264_NAL_SPS) {
+if (!vtctx->sps || vtctx->sps_len != size || memcmp(buffer, 
vtctx->sps, size) != 0) {
+vtctx->sps = av_fast_realloc(vtctx->sps, >sps_capa, size);
+if (vtctx->sps)
+memcpy(vtctx->sps, buffer, size);
+vtctx->reconfig_needed = true;
+vtctx->sps_len = size;
+}
+}
+
+// pass-through new PPS to the decoder
+return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
+}
+
 int ff_videotoolbox_h264_decode_slice(AVCodecContext *avctx,
   const uint8_t *buffer,
   uint32_t size)
@@ -339,6 +363,7 @@ int ff_videotoolbox_uninit(AVCodecContext *avctx)
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 if (vtctx) {
 av_freep(>bitstream);
+av_freep(>sps);
 if (vtctx->frame)
 CVPixelBufferRelease(vtctx->frame);
 }
@@ -591,17 +616,30 @@ static int videotoolbox_common_end_frame(AVCodecContext 
*avctx, AVFrame *frame)
 AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 
-if (!videotoolbox->session || !vtctx->bitstream)
+if (vtctx->reconfig_needed == true) {
+vtctx->reconfig_needed = false;
+av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox decoder needs reconfig, 
restarting..\n");
+videotoolbox_stop(avctx);
+if (videotoolbox_start(avctx) != 0) {
+return AVERROR_EXTERNAL;
+}
+}
+
+if (!videotoolbox->session || !vtctx->bitstream || !vtctx->bitstream_size)
 return AVERROR_INVALIDDATA;
 
 status = videotoolbox_session_decode_frame(avctx);
 if (status != noErr) {
+if (status == kVTVideoDecoderMalfunctionErr || status == 
kVTInvalidSessionErr)
+vtctx->reconfig_needed = true;
 av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%s, %d)\n", 
videotoolbox_error_string(status), (int)status);
 return AVERROR_UNKNOWN;
 }
 
-if (!vtctx->frame)
+if (!vtctx->frame) {
+vtctx->reconfig_needed = true;
 return AVERROR_UNKNOWN;
+}
 
 return videotoolbox_buffer_create(avctx, frame);
 }
@@ -1003,6 +1041,7 @@ AVHWAccel ff_h264_videotoolbox_hwaccel = {
 .alloc_frame= ff_videotoolbox_alloc_frame,
 .start_frame= ff_videotoolbox_h264_start_frame,
 .decode_slice   = ff_videotoolbox_h264_decode_slice,
+.decode_params  = videotoolbox_h264_decode_params,
 .end_frame  = videotoolbox_h264_end_frame,
 .init   = videotoolbox_common_init,
 .uninit = videotoolbox_uninit,
diff --git a/libavcodec/vt_internal.h b/libavcodec/vt_internal.h
index 607dd7a6d0..fc27dad9f9 100644
--- a/libavcodec/vt_internal.h
+++ b/libavcodec/vt_internal.h
@@ -38,6 +38,12 @@ typedef struct VTContext {
 // Non-NULL if the new hwaccel API is used. This is only a separate struct
 // to ease compatibility with the old API.
 struct AVVideotoolboxContext *vt_ctx;
+
+// Current H264 parameters (used to trigger decoder restart on SPS 
changes).
+uint8_t *sps;
+uint32_tsps_len;
+unsigned intsps_capa;
+boolreconfig_needed;
 

[FFmpeg-devel] [PATCH v4 12/14] avcodec/videotoolbox: pass through hevc param changes to the decoder

[Aman Gupta]

From: Aman Gupta 

This includes the SEI_PREFIX/SEI_SUFFIX NALUs, which can contain
updates like HEVC_SEI_TYPE_ACTIVE_PARAMETER_SETS. Previously, hevc
samples with this SEI present would not playback correctly.

See for example https://github.com/lhc7/iina/issues/1123
---
 libavcodec/videotoolbox.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index fc33dce608..9eb06e619f 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -654,6 +654,14 @@ static int videotoolbox_h264_end_frame(AVCodecContext 
*avctx)
 return ret;
 }
 
+static int videotoolbox_hevc_decode_params(AVCodecContext *avctx,
+   int type,
+   const uint8_t *buffer,
+   uint32_t size)
+{
+return ff_videotoolbox_h264_decode_slice(avctx, buffer, size);
+}
+
 static int videotoolbox_hevc_end_frame(AVCodecContext *avctx)
 {
 HEVCContext *h = avctx->priv_data;
@@ -1026,6 +1034,7 @@ AVHWAccel ff_hevc_videotoolbox_hwaccel = {
 .alloc_frame= ff_videotoolbox_alloc_frame,
 .start_frame= ff_videotoolbox_h264_start_frame,
 .decode_slice   = ff_videotoolbox_h264_decode_slice,
+.decode_params  = videotoolbox_hevc_decode_params,
 .end_frame  = videotoolbox_hevc_end_frame,
 .init   = videotoolbox_common_init,
 .uninit = ff_videotoolbox_uninit,
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 11/14] avcodec/hevc: implement new decode_params callback for VideoToolbox

[Aman Gupta]

From: Aman Gupta 

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

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 675025b211..501ee6a55e 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2816,23 +2816,55 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 
 switch (s->nal_unit_type) {
 case HEVC_NAL_VPS:
+if (s->avctx->hwaccel && s->avctx->hwaccel->decode_params) {
+ret = s->avctx->hwaccel->decode_params(s->avctx,
+   nal->type,
+   nal->raw_data,
+   nal->raw_size);
+if (ret < 0)
+goto fail;
+}
 ret = ff_hevc_decode_nal_vps(gb, s->avctx, >ps);
 if (ret < 0)
 goto fail;
 break;
 case HEVC_NAL_SPS:
+if (s->avctx->hwaccel && s->avctx->hwaccel->decode_params) {
+ret = s->avctx->hwaccel->decode_params(s->avctx,
+   nal->type,
+   nal->raw_data,
+   nal->raw_size);
+if (ret < 0)
+goto fail;
+}
 ret = ff_hevc_decode_nal_sps(gb, s->avctx, >ps,
  s->apply_defdispwin);
 if (ret < 0)
 goto fail;
 break;
 case HEVC_NAL_PPS:
+if (s->avctx->hwaccel && s->avctx->hwaccel->decode_params) {
+ret = s->avctx->hwaccel->decode_params(s->avctx,
+   nal->type,
+   nal->raw_data,
+   nal->raw_size);
+if (ret < 0)
+goto fail;
+}
 ret = ff_hevc_decode_nal_pps(gb, s->avctx, >ps);
 if (ret < 0)
 goto fail;
 break;
 case HEVC_NAL_SEI_PREFIX:
 case HEVC_NAL_SEI_SUFFIX:
+if (s->avctx->hwaccel && s->avctx->hwaccel->decode_params) {
+ret = s->avctx->hwaccel->decode_params(s->avctx,
+   nal->type,
+   nal->raw_data,
+   nal->raw_size);
+if (ret < 0)
+goto fail;
+}
 ret = ff_hevc_decode_nal_sei(gb, s->avctx, >sei, >ps, 
s->nal_unit_type);
 if (ret < 0)
 goto fail;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 02/14] avcodec/videotoolbox: extract videotoolbox_{start, stop} helpers

[Aman Gupta]

From: Aman Gupta 

These helpers will be used in later commits to automatically restart
the decoder session when SPS changes are encountered.
---
 libavcodec/videotoolbox.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index f5a282f72c..24f74ee86e 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -756,7 +756,7 @@ static CMVideoFormatDescriptionRef 
videotoolbox_format_desc_create(CMVideoCodecT
 return cm_fmt_desc;
 }
 
-static int videotoolbox_default_init(AVCodecContext *avctx)
+static int videotoolbox_start(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
 OSStatus status;
@@ -794,6 +794,11 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 
 decoder_spec = 
videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
 
+if (!decoder_spec) {
+av_log(avctx, AV_LOG_ERROR, "decoder specification creation failed\n");
+return -1;
+}
+
 videotoolbox->cm_fmt_desc = 
videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
 decoder_spec,
 avctx->width,
@@ -846,18 +851,21 @@ static int videotoolbox_default_init(AVCodecContext 
*avctx)
 }
 }
 
-static void videotoolbox_default_free(AVCodecContext *avctx)
+static void videotoolbox_stop(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
 if (!videotoolbox)
 return;
 
-if (videotoolbox->cm_fmt_desc)
+if (videotoolbox->cm_fmt_desc) {
 CFRelease(videotoolbox->cm_fmt_desc);
+videotoolbox->cm_fmt_desc = NULL;
+}
 
 if (videotoolbox->session) {
 VTDecompressionSessionInvalidate(videotoolbox->session);
 CFRelease(videotoolbox->session);
+videotoolbox->session = NULL;
 }
 }
 
@@ -870,7 +878,7 @@ static int videotoolbox_uninit(AVCodecContext *avctx)
 ff_videotoolbox_uninit(avctx);
 
 if (vtctx->vt_ctx)
-videotoolbox_default_free(avctx);
+videotoolbox_stop(avctx);
 
 av_buffer_unref(>cached_hw_frames_ctx);
 av_freep(>vt_ctx);
@@ -936,7 +944,7 @@ static int videotoolbox_common_init(AVCodecContext *avctx)
 goto fail;
 }
 
-err = videotoolbox_default_init(avctx);
+err = videotoolbox_start(avctx);
 if (err < 0)
 goto fail;
 
@@ -1053,13 +1061,13 @@ int av_videotoolbox_default_init2(AVCodecContext 
*avctx, AVVideotoolboxContext *
 avctx->hwaccel_context = vtctx ?: av_videotoolbox_alloc_context();
 if (!avctx->hwaccel_context)
 return AVERROR(ENOMEM);
-return videotoolbox_default_init(avctx);
+return videotoolbox_start(avctx);
 }
 
 void av_videotoolbox_default_free(AVCodecContext *avctx)
 {
 
-videotoolbox_default_free(avctx);
+videotoolbox_stop(avctx);
 av_freep(>hwaccel_context);
 }
 #endif /* CONFIG_VIDEOTOOLBOX */
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 03/14] avcodec/videotoolbox: reset bitstream_size in end_frame

[Aman Gupta]

From: Aman Gupta 

This allows decode_slice to be invoked multiple times before end_frame,
causing slices to accumulate before being fed into the VT decoder.

An upcoming commit will re-use decode_slice for SPS and PPS nalus, so
they can be propagated into the VT decoder session along with slide
data.
---
 libavcodec/videotoolbox.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 24f74ee86e..a4a282c33a 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -300,8 +300,6 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext *avctx,
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 H264Context *h  = avctx->priv_data;
 
-vtctx->bitstream_size = 0;
-
 if (h->is_avc == 1) {
 return videotoolbox_buffer_copy(vtctx, buffer, size);
 }
@@ -600,8 +598,10 @@ static int videotoolbox_h264_end_frame(AVCodecContext 
*avctx)
 {
 H264Context *h = avctx->priv_data;
 AVFrame *frame = h->cur_pic_ptr->f;
-
-return videotoolbox_common_end_frame(avctx, frame);
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+int ret = videotoolbox_common_end_frame(avctx, frame);
+vtctx->bitstream_size = 0;
+return ret;
 }
 
 static int videotoolbox_hevc_end_frame(AVCodecContext *avctx)
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 04/14] avcodec/videotoolbox: print descriptive errors on decode failures

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/videotoolbox.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index a4a282c33a..9db2e1116b 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -572,9 +572,22 @@ static OSStatus 
videotoolbox_session_decode_frame(AVCodecContext *avctx)
 return status;
 }
 
+static const char *videotoolbox_error_string(OSStatus status)
+{
+switch (status) {
+case kVTVideoDecoderBadDataErr:
+return "bad data";
+case kVTVideoDecoderMalfunctionErr:
+return "decoder malfunction";
+case kVTInvalidSessionErr:
+return "invalid session";
+}
+return "unknown";
+}
+
 static int videotoolbox_common_end_frame(AVCodecContext *avctx, AVFrame *frame)
 {
-int status;
+OSStatus status;
 AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
 
@@ -582,9 +595,8 @@ static int videotoolbox_common_end_frame(AVCodecContext 
*avctx, AVFrame *frame)
 return AVERROR_INVALIDDATA;
 
 status = videotoolbox_session_decode_frame(avctx);
-
-if (status) {
-av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%d)\n", status);
+if (status != noErr) {
+av_log(avctx, AV_LOG_ERROR, "Failed to decode frame (%s, %d)\n", 
videotoolbox_error_string(status), (int)status);
 return AVERROR_UNKNOWN;
 }
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 05/14] avcodec/h264, videotoolbox: return AVERROR_INVALIDDATA when no frames are produced

[Aman Gupta]

From: Aman Gupta 

The only reason videotoolbox wouldn't produce frames is if the data fed
to it was invalid, so returning AVERROR_INVALIDDATA makes sense here.

Further, it means AVERROR_EXTERNAL can be used in further commits to signal
fatal VideoToolbox errors, letting the user know that they need to fallback to
another decoder.
---
 libavcodec/h264dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index aed23c4fba..517f6acc13 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -824,7 +824,7 @@ static int output_frame(H264Context *h, AVFrame *dst, 
H264Picture *srcp)
 int ret;
 
 if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1)
-return AVERROR_EXTERNAL;
+return AVERROR_INVALIDDATA;
 
 ret = av_frame_ref(dst, src);
 if (ret < 0)
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 06/14] avcodec: add decode_params callback to AVHWAccel struct

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/avcodec.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c4134424f0..2bd46faa50 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3459,6 +3459,20 @@ typedef struct AVHWAccel {
  */
 int (*start_frame)(AVCodecContext *avctx, const uint8_t *buf, uint32_t 
buf_size);
 
+/**
+ * Callback for parameter data (SPS/PPS/VPS etc).
+ *
+ * Useful for hardware decoders which keep persistent state about the
+ * video parameters, and need to receive any changes to update that state.
+ *
+ * @param avctx the codec context
+ * @param type the parameter type
+ * @param buf the slice data buffer base
+ * @param buf_size the size of the slice in bytes
+ * @return zero if successful, a negative value otherwise
+ */
+int (*decode_params)(AVCodecContext *avctx, int type, const uint8_t *buf, 
uint32_t buf_size);
+
 /**
  * Callback for each slice.
  *
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v4 01/14] avcodec/videotoolbox: use early return in videotoolbox_default_free

[Aman Gupta]

From: Aman Gupta 

Cosmetic change only.
---
 libavcodec/videotoolbox.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index ecb2502c1f..f5a282f72c 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -849,15 +849,15 @@ static int videotoolbox_default_init(AVCodecContext 
*avctx)
 static void videotoolbox_default_free(AVCodecContext *avctx)
 {
 AVVideotoolboxContext *videotoolbox = videotoolbox_get_context(avctx);
+if (!videotoolbox)
+return;
 
-if (videotoolbox) {
-if (videotoolbox->cm_fmt_desc)
-CFRelease(videotoolbox->cm_fmt_desc);
+if (videotoolbox->cm_fmt_desc)
+CFRelease(videotoolbox->cm_fmt_desc);
 
-if (videotoolbox->session) {
-VTDecompressionSessionInvalidate(videotoolbox->session);
-CFRelease(videotoolbox->session);
-}
+if (videotoolbox->session) {
+VTDecompressionSessionInvalidate(videotoolbox->session);
+CFRelease(videotoolbox->session);
 }
 }
 
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 10 November 2017 at 21:09, Aurelien Jacobs  wrote:

> The encoder was reverse engineered from binary library and from
> EP0398973B1 patent (long expired).
> The decoder was simply deduced from the encoder.
> ---
>  doc/general.texi|   2 +
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/aptx.c   | 860 ++
> ++
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  6 files changed, 873 insertions(+)
>  create mode 100644 libavcodec/aptx.c
>
> diff --git a/doc/general.texi b/doc/general.texi
> index e6ae277d23..de4efee913 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -993,6 +993,8 @@ following image formats are supported:
>  @item Amazing Studio PAF Audio @tab @tab  X
>  @item Apple lossless audio   @tab  X  @tab  X
>  @tab QuickTime fourcc 'alac'
> +@item aptX   @tab  X  @tab  X
> +@tab Used in Bluetooth A2DP
>  @item ATRAC1 @tab @tab  X
>  @item ATRAC3 @tab @tab  X
>  @item ATRAC3+@tab @tab  X
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 45f4db5939..95c843dee7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -188,6 +188,8 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o
> mjpegenc_common.o \
>  OBJS-$(CONFIG_ANM_DECODER) += anm.o
>  OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
>  OBJS-$(CONFIG_APE_DECODER) += apedec.o
> +OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
> +OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
>  OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
>  OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
>  OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index d96e499ba7..463f7ed64e 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -406,6 +406,7 @@ static void register_all(void)
>  REGISTER_DECODER(AMRNB, amrnb);
>  REGISTER_DECODER(AMRWB, amrwb);
>  REGISTER_DECODER(APE,   ape);
> +REGISTER_ENCDEC (APTX,  aptx);
>  REGISTER_DECODER(ATRAC1,atrac1);
>  REGISTER_DECODER(ATRAC3,atrac3);
>  REGISTER_DECODER(ATRAC3AL,  atrac3al);
> diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
> new file mode 100644
> index 00..d09ce8f838
> --- /dev/null
> +++ b/libavcodec/aptx.c
> @@ -0,0 +1,860 @@
> +/*
> + * Audio Processing Technology codec for Bluetooth (aptX)
> + *
> + * Copyright (C) 2017  Aurelien Jacobs 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +#include "avcodec.h"
> +#include "internal.h"
> +#include "mathops.h"
> +#include "audio_frame_queue.h"
> +
> +
> +enum channels {
> +LEFT,
> +RIGHT,
> +NB_CHANNELS
> +};
> +
> +enum subbands {
> +LF,  // Low Frequency (0-5.5 kHz)
> +MLF, // Medium-Low Frequency (5.5-11kHz)
> +MHF, // Medium-High Frequency (11-16.5kHz)
> +HF,  // High Frequency (16.5-22kHz)
> +NB_SUBBANDS
> +};
> +
> +#define NB_FILTERS 2
> +#define FILTER_TAPS 16
> +
> +typedef struct {
> +int pos;
> +int32_t buffer[2*FILTER_TAPS];
> +} FilterSignal;
> +
> +typedef struct {
> +FilterSignal outer_filter_signal[NB_FILTERS];
> +FilterSignal inner_filter_signal[NB_FILTERS][NB_FILTERS];
> +} QMFAnalysis;
> +
> +typedef struct {
> +int32_t quantized_sample;
> +int32_t quantized_sample_parity_change;
> +int32_t error;
> +} Quantize;
> +
> +typedef struct {
> +int32_t quantization_factor;
> +int32_t factor_select;
> +int32_t reconstructed_difference;
> +} InvertQuantize;
> +
> +typedef struct {
> +int32_t prev_sign[2];
> +int32_t s_weight[2];
> +int32_t d_weight[24];
> +int32_t pos;
> +int32_t reconstructed_differences[48];
> +int32_t previous_reconstructed_sample;
> +int32_t predicted_difference;
> +int32_t predicted_sample;
> +} Prediction;
> +
> +typedef struct {
> +int32_t codeword_history;
> +int32_t 

Re: [FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Rostislav Pehlivanov]

On 10 November 2017 at 21:09, Aurelien Jacobs  wrote:

> ---
>  doc/general.texi |  1 +
>  libavformat/Makefile |  2 ++
>  libavformat/allformats.c |  1 +
>  libavformat/aptxdec.c| 78 ++
> ++
>  libavformat/rawenc.c | 13 
>  libavformat/utils.c  |  1 +
>  6 files changed, 96 insertions(+)
>  create mode 100644 libavformat/aptxdec.c
>
> diff --git a/doc/general.texi b/doc/general.texi
> index de4efee913..efd4a92495 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -441,6 +441,7 @@ library:
>  @item raw AC-3  @tab X @tab X
>  @item raw AMR-NB@tab   @tab X
>  @item raw AMR-WB@tab   @tab X
> +@item raw aptX  @tab X @tab X
>  @item raw Chinese AVS video @tab X @tab X
>  @item raw CRI ADX   @tab X @tab X
>  @item raw Dirac @tab X @tab X
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 146a4656f2..b1e7b193f4 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -94,6 +94,8 @@ OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
>  OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
>  OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
>  OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
> +OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
> +OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
>  OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
>  OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
>  avlanguage.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 1896d50e9e..9213af9301 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -69,6 +69,7 @@ static void register_all(void)
>  REGISTER_DEMUXER (APC,  apc);
>  REGISTER_DEMUXER (APE,  ape);
>  REGISTER_MUXDEMUX(APNG, apng);
> +REGISTER_MUXDEMUX(APTX, aptx);
>  REGISTER_DEMUXER (AQTITLE,  aqtitle);
>  REGISTER_MUXDEMUX(ASF,  asf);
>  REGISTER_DEMUXER (ASF_O,asf_o);
> diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
> new file mode 100644
> index 00..3b8fae1b55
> --- /dev/null
> +++ b/libavformat/aptxdec.c
> @@ -0,0 +1,78 @@
> +/*
> + * RAW aptX demuxer
> + *
> + * Copyright (C) 2017  Aurelien Jacobs 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "avformat.h"
> +#include "rawdec.h"
> +
> +#define APTX_BLOCK_SIZE   4
> +#define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
> +
> +typedef struct AptXDemuxerContext {
> +AVClass *class;
> +int sample_rate;
> +} AptXDemuxerContext;
> +
> +static int aptx_read_header(AVFormatContext *s)
> +{
> +AptXDemuxerContext *s1 = s->priv_data;
> +AVStream *st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> +st->codecpar->codec_id = AV_CODEC_ID_APTX;
> +st->codecpar->format = AV_SAMPLE_FMT_S32P;
> +st->codecpar->channels = 2;
> +st->codecpar->sample_rate = s1->sample_rate;
> +st->codecpar->bits_per_coded_sample = 4;
> +st->codecpar->block_align = APTX_BLOCK_SIZE;
> +st->codecpar->frame_size = APTX_PACKET_SIZE;
> +st->start_time = 0;
> +return 0;
> +}
> +
> +static int aptx_read_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +return av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
> +}
> +
> +static const AVOption aptx_options[] = {
> +{ "sample_rate", "", offsetof(AptXDemuxerContext, sample_rate),
> AV_OPT_TYPE_INT, {.i64 = 48000}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM },
> +{ NULL },
> +};
> +
> +static const AVClass aptx_demuxer_class = {
> +.class_name = "aptx demuxer",
> +.item_name  = av_default_item_name,
> +.option = aptx_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +AVInputFormat ff_aptx_demuxer = {
> +.name   = "aptx",
> +.long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
> +.extensions = "aptx",
> +

[FFmpeg-devel] [DEVEL][PATCH v2] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?


just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case


ok I fixed that by using the flag AV_DICT_IGNORE_SUFFIX ; now 
-channel_layout:a works as expected.
I fixed also all the styling issues you spotted (mixed declarations, {} 
for if etc).


Still not understanding your initial comment though :
'why is the channel_layout option per file and not per stream?'

do you mean o->g->codec_opts is not where I should retrieve the 
channel_layout ? if not where from ?


Thanks


[...]


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



From 6d4f1c14135f9473b77e1c649d0e7bbaeba00a50 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
 fftools/ffmpeg_opt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ca6f10d..cb25d7b 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1785,6 +1785,7 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
 AVStream *st;
 OutputStream *ost;
 AVCodecContext *audio_enc;
+AVDictionaryEntry *output_layout;
 
 ost = new_output_stream(o, oc, AVMEDIA_TYPE_AUDIO, source_index);
 st  = ost->st;
@@ -1799,7 +1800,10 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
 char *sample_fmt = NULL;
 
 MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
-
+output_layout = av_dict_get(o->g->codec_opts,"channel_layout", NULL, 
AV_DICT_IGNORE_SUFFIX);
+if (output_layout) {
+audio_enc->channel_layout = strtoull(output_layout->value, NULL, 
10);
+}
 MATCH_PER_STREAM_OPT(sample_fmts, str, sample_fmt, oc, st);
 if (sample_fmt &&
 (audio_enc->sample_fmt = av_get_sample_fmt(sample_fmt)) == 
AV_SAMPLE_FMT_NONE) {
@@ -2523,7 +2527,11 @@ loop_end:
(count + 1) * 

[FFmpeg-devel] [PATCH] ffmpeg: use explicitly requested hwaccel only

[Timo Rothenpieler]

With there being two hwaccels that use the CUDA pix_fmt now, just
relying on the pix_fmt to identify the selected hwaccel is not enough
anymore.

So this checks if the user explicitly selected a hwaccel, and only
accepts that one.
---
 fftools/ffmpeg.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 679929cfc4..d430353b56 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2782,11 +2782,12 @@ fail:
 av_freep();
 }
 
-static const HWAccel *get_hwaccel(enum AVPixelFormat pix_fmt)
+static const HWAccel *get_hwaccel(enum AVPixelFormat pix_fmt, enum HWAccelID 
selected_hwaccel_id)
 {
 int i;
 for (i = 0; hwaccels[i].name; i++)
-if (hwaccels[i].pix_fmt == pix_fmt)
+if (hwaccels[i].pix_fmt == pix_fmt &&
+(!selected_hwaccel_id || selected_hwaccel_id == HWACCEL_AUTO || 
hwaccels[i].id == selected_hwaccel_id))
 return [i];
 return NULL;
 }
@@ -2804,7 +2805,7 @@ static enum AVPixelFormat get_format(AVCodecContext *s, 
const enum AVPixelFormat
 if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
 break;
 
-hwaccel = get_hwaccel(*p);
+hwaccel = get_hwaccel(*p, ist->hwaccel_id);
 if (!hwaccel ||
 (ist->active_hwaccel_id && ist->active_hwaccel_id != hwaccel->id) 
||
 (ist->hwaccel_id != HWACCEL_AUTO && ist->hwaccel_id != 
hwaccel->id))
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 08/11] avcodec/v210enc: add AVX-512 10-bit line pack function

[James Darnley]

On 2017-11-10 14:32, James Darnley wrote:
> I mentioned previously that using ZMM registers will cause the CPU to
> reduce its frequency.
> 
> Gramner said on IRC that a user should spend 20-30% of time in
> AVX-512/ZMM code for it to be a net gain in speed.
> From ffmpeg-devel IRC on 2017-10-26
>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-October/004622.html
>> [18:49:26 CEST]  J_Darnley: be aware that using zmm registers 
>> induces significant frequency drops which reduces performance of everything 
>> else, so if you want to use 512-bit vectors you better go all in on it to 
>> make up for it. you probably want to spend at least 20-30% of overall 
>> runtime in avx-512 code
>> [18:50:00 CEST]  the alternative is to stay in 256-bit mode and 
>> just leverage new instructions and opmasks
> 
> This means any cycles you might save by using longer registers, fewer
> instructions, better instructions, whatever, will be lost because the
> frequency drops meaning it takes longer to execute overall.

Some details about this can be found in one of Intel's documents: Intel®
64 and IA-32 Architectures Optimization Reference Manual
Order Number: 248966-038
October 2017
> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf
Specifically section 15.26 "SKYLAKE SERVER POWER MANAGEMENT"

Earlier on the ffmpeg-devel IRC channel I posted a link to Cloudflare's
blog in which they discuss the effects of running just a few (my words)
AVX-512/ZMM instructions.
> https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/

In the worst cases on some of the new processors the frequency drop can
be 1GHz.  In Cloudflare's case just spending about 2.5% of time in a
cryptography function using AVX-512 was causing a 10% drop in their
overall performance (requests served per second).

After seeing this and the discussion on IRC I won't commit any of the
function patches.  The functions are not very impressive and are likely
to make everything else slower.

The IRC log should appear at the link below.
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-November/004651.html

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

[FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Aurelien Jacobs]

---
 doc/general.texi |  1 +
 libavformat/Makefile |  2 ++
 libavformat/allformats.c |  1 +
 libavformat/aptxdec.c| 78 
 libavformat/rawenc.c | 13 
 libavformat/utils.c  |  1 +
 6 files changed, 96 insertions(+)
 create mode 100644 libavformat/aptxdec.c

diff --git a/doc/general.texi b/doc/general.texi
index de4efee913..efd4a92495 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -441,6 +441,7 @@ library:
 @item raw AC-3  @tab X @tab X
 @item raw AMR-NB@tab   @tab X
 @item raw AMR-WB@tab   @tab X
+@item raw aptX  @tab X @tab X
 @item raw Chinese AVS video @tab X @tab X
 @item raw CRI ADX   @tab X @tab X
 @item raw Dirac @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 146a4656f2..b1e7b193f4 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -94,6 +94,8 @@ OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
+OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
+OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
 avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 1896d50e9e..9213af9301 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -69,6 +69,7 @@ static void register_all(void)
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
 REGISTER_MUXDEMUX(APNG, apng);
+REGISTER_MUXDEMUX(APTX, aptx);
 REGISTER_DEMUXER (AQTITLE,  aqtitle);
 REGISTER_MUXDEMUX(ASF,  asf);
 REGISTER_DEMUXER (ASF_O,asf_o);
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
new file mode 100644
index 00..3b8fae1b55
--- /dev/null
+++ b/libavformat/aptxdec.c
@@ -0,0 +1,78 @@
+/*
+ * RAW aptX demuxer
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+
+#define APTX_BLOCK_SIZE   4
+#define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
+
+typedef struct AptXDemuxerContext {
+AVClass *class;
+int sample_rate;
+} AptXDemuxerContext;
+
+static int aptx_read_header(AVFormatContext *s)
+{
+AptXDemuxerContext *s1 = s->priv_data;
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_APTX;
+st->codecpar->format = AV_SAMPLE_FMT_S32P;
+st->codecpar->channels = 2;
+st->codecpar->sample_rate = s1->sample_rate;
+st->codecpar->bits_per_coded_sample = 4;
+st->codecpar->block_align = APTX_BLOCK_SIZE;
+st->codecpar->frame_size = APTX_PACKET_SIZE;
+st->start_time = 0;
+return 0;
+}
+
+static int aptx_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+return av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
+}
+
+static const AVOption aptx_options[] = {
+{ "sample_rate", "", offsetof(AptXDemuxerContext, sample_rate), 
AV_OPT_TYPE_INT, {.i64 = 48000}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM },
+{ NULL },
+};
+
+static const AVClass aptx_demuxer_class = {
+.class_name = "aptx demuxer",
+.item_name  = av_default_item_name,
+.option = aptx_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVInputFormat ff_aptx_demuxer = {
+.name   = "aptx",
+.long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
+.extensions = "aptx",
+.priv_data_size = sizeof(AptXDemuxerContext),
+.read_header= aptx_read_header,
+.read_packet= aptx_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+.priv_class = _demuxer_class,
+};
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index f640121cb4..aa3ef76fbf 100644
--- 

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

On Fri, Nov 10, 2017 at 12:25:12AM +, Rostislav Pehlivanov wrote:
> On 9 November 2017 at 22:48, Aurelien Jacobs  wrote:
> 
> > On Thu, Nov 09, 2017 at 02:32:44PM +, Rostislav Pehlivanov wrote:
> > > On 9 November 2017 at 13:37, Aurelien Jacobs  wrote:
> > >
> > > > On Thu, Nov 09, 2017 at 12:52:34AM +, Rostislav Pehlivanov wrote:
> > > > > On 8 November 2017 at 22:41, Aurelien Jacobs 
> > wrote:
> > > > >
> > > > > > On Wed, Nov 08, 2017 at 06:26:03PM +0100, Michael Niedermayer
> > wrote:
> > > > > > > On Wed, Nov 08, 2017 at 02:06:09PM +0100, Aurelien Jacobs wrote:
> > > > > > > [...]
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * Compute the convolution of the signal with the
> > coefficients,
> > > > and
> > > > > > reduce
> > > > > > > > + * to 24 bits by applying the specified right shifting.
> > > > > > > > + */
> > > > > > > > +av_always_inline
> > > > > > > > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > > > > > > > +const int32_t
> > > > coeffs[FILTER_TAPS],
> > > > > > > > +int shift)
> > > > > > > > +{
> > > > > > > > +int32_t *sig = >buffer[signal->pos];
> > > > > > > > +int64_t e = 0;
> > > > > > > > +
> > > > > > >
> > > > > > > > +for (int i = 0; i < FILTER_TAPS; i++)
> > > > > > >
> > > > > > > "for (int" is something we avoided as some comilers didnt like
> > it,
> > > > > > > iam not sure if this is still true but there are none in the
> > codebase
> > > > > >
> > > > > > If you insist on this I will of course change it, but hey, we
> > require
> > > > > > a C99 compiler since a long time and we use so many features of C99
> > > > > > that I really don't get why we couldn't use "for (int".
> > > > > > I can't imagine that any relevant C compiler would not support this
> > > > > > nowadays !
> > > > > > What I propose is to get this in as is, and see if anyone encounter
> > > > > > issue with any compiler. If any issue arise, I will of course send
> > a
> > > > > > patch to fix it.
> > > > > >
> > > > > > Here is an updated patch.
> > > > > >
> > > > > >
> > > > > Send another patch because some people are beyond convincing and its
> > > > really
> > > > > pissing me off. Really. In particular maybe those compiler writers at
> > > > > Microsoft who seem to think shipping something that doesn't support
> > such
> > > > a
> > > > > simple yet important feature is important.
> > > > > Or maybe users who don't want to update a 6 year old version of msvc.
> > > > > Or maybe us because we support compiling with msvc at all when its
> > > > clearly
> > > > > _not_ a C compiler and this project is written in C.
> > > >
> > > > Here you go.
> > > >
> > > > Just for reference, splitting the déclaration out of the for loop added
> > > > 19 lines in this file, which is a 2.3 % increase of the line count.
> > > > (I'm not sure this file is representative of the rest of the code base)
> > > >
> > > > ___
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@ffmpeg.org
> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >
> > > >
> > > Still some issues:
> > >
> > > 1.) You need to set AVCodec->supported_samplerates for the encoder, since
> > > in the raw aptx muxer you always set the samplerate as 44100. Does the
> > > codec/container support other samplerates?
> >
> > The codec is actually samplerate agnostic.
> > It only convert each group of 4 samples to a 16 bit integer.
> > There is no other information than the samples themselves in the
> > encoded stream. No header, no frame size, no samplerate.
> > And there is no standard container used to store aptX along with
> > the needed metadata such as the samplerate. It is meant to be streamed
> > thru bluetooth using the A2DP "protocol" which includes its own metadata
> > signaling with samplerate.
> > The raw muxer/demuxer that I implemented is mostly for testing purpose,
> > not really for practical use.
> > So with this in mind, I don't think that it make any sense to set
> > AVCodec->supported_samplerates.
> > I don't think I set the samplerate anywhere in the encoder.
> > I only set it in the demuxer to a default 44100 just to be able to
> > playback test files even though there is no way to know its actual
> > samplerate.
> >
> >
> Ah, I see.
> In this case set the allowed samplerate to 48000 on the encoder side and
> the output samplerate in the demuxer to the same. Pretty much all systems,
> be it bluetooth, I2S or some other interface run at 48khz so that's what we
> should set it so its as compatible as possible. Nothing but systems which
> handle redbook cds use 44100hz.

I found a list of supported samplerate in an aptX commercial
documentation, so I think it makes sense to list them in the encoder.
Regarding the demuxer, I set it 48000 by default, but I added an
AVOption to allow user to 

[FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

The encoder was reverse engineered from binary library and from
EP0398973B1 patent (long expired).
The decoder was simply deduced from the encoder.
---
 doc/general.texi|   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/aptx.c   | 860 
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 6 files changed, 873 insertions(+)
 create mode 100644 libavcodec/aptx.c

diff --git a/doc/general.texi b/doc/general.texi
index e6ae277d23..de4efee913 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -993,6 +993,8 @@ following image formats are supported:
 @item Amazing Studio PAF Audio @tab @tab  X
 @item Apple lossless audio   @tab  X  @tab  X
 @tab QuickTime fourcc 'alac'
+@item aptX   @tab  X  @tab  X
+@tab Used in Bluetooth A2DP
 @item ATRAC1 @tab @tab  X
 @item ATRAC3 @tab @tab  X
 @item ATRAC3+@tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 45f4db5939..95c843dee7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -188,6 +188,8 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o 
mjpegenc_common.o \
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
+OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
+OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d96e499ba7..463f7ed64e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -406,6 +406,7 @@ static void register_all(void)
 REGISTER_DECODER(AMRNB, amrnb);
 REGISTER_DECODER(AMRWB, amrwb);
 REGISTER_DECODER(APE,   ape);
+REGISTER_ENCDEC (APTX,  aptx);
 REGISTER_DECODER(ATRAC1,atrac1);
 REGISTER_DECODER(ATRAC3,atrac3);
 REGISTER_DECODER(ATRAC3AL,  atrac3al);
diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
new file mode 100644
index 00..d09ce8f838
--- /dev/null
+++ b/libavcodec/aptx.c
@@ -0,0 +1,860 @@
+/*
+ * Audio Processing Technology codec for Bluetooth (aptX)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "internal.h"
+#include "mathops.h"
+#include "audio_frame_queue.h"
+
+
+enum channels {
+LEFT,
+RIGHT,
+NB_CHANNELS
+};
+
+enum subbands {
+LF,  // Low Frequency (0-5.5 kHz)
+MLF, // Medium-Low Frequency (5.5-11kHz)
+MHF, // Medium-High Frequency (11-16.5kHz)
+HF,  // High Frequency (16.5-22kHz)
+NB_SUBBANDS
+};
+
+#define NB_FILTERS 2
+#define FILTER_TAPS 16
+
+typedef struct {
+int pos;
+int32_t buffer[2*FILTER_TAPS];
+} FilterSignal;
+
+typedef struct {
+FilterSignal outer_filter_signal[NB_FILTERS];
+FilterSignal inner_filter_signal[NB_FILTERS][NB_FILTERS];
+} QMFAnalysis;
+
+typedef struct {
+int32_t quantized_sample;
+int32_t quantized_sample_parity_change;
+int32_t error;
+} Quantize;
+
+typedef struct {
+int32_t quantization_factor;
+int32_t factor_select;
+int32_t reconstructed_difference;
+} InvertQuantize;
+
+typedef struct {
+int32_t prev_sign[2];
+int32_t s_weight[2];
+int32_t d_weight[24];
+int32_t pos;
+int32_t reconstructed_differences[48];
+int32_t previous_reconstructed_sample;
+int32_t predicted_difference;
+int32_t predicted_sample;
+} Prediction;
+
+typedef struct {
+int32_t codeword_history;
+int32_t dither_parity;
+int32_t dither[NB_SUBBANDS];
+
+QMFAnalysis qmf;
+Quantize quantize[NB_SUBBANDS];
+InvertQuantize invert_quantize[NB_SUBBANDS];
+Prediction prediction[NB_SUBBANDS];
+} Channel;
+
+typedef struct {
+int32_t sync_idx;
+Channel channels[NB_CHANNELS];
+AudioFrameQueue afq;
+} AptXContext;
+
+
+static const int32_t 

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Hello,

here is a new version of the patch with further fixes.

Greetings,
Felix



0001-avdevice-add-android_camera-indev.patch
Description: Binary data


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

Re: [FFmpeg-devel] [PATCH] h264dec: h264_select_output_frame() - fill correctly has_b_frames based on the level

[Jaroslav Kysela]

Dne 9.11.2017 v 21:38 Jaroslav Kysela napsal(a):
> The current code does not handle correctly the situation when 
> sps->num_reoder_frames
> was set using the level. The incorrect has_b_frames results in the wrong DTS 
> guess and
> malformed output (wrong 'Non-monotonous DTS' fixup).
> 
> sps->num_reorder_frames is set in the function 
> ff_h264_decode_seq_parameter_set(),
> see comment: 'if the maximum delay is not stored in the SPS, derive it based 
> on the
> level'.
> 
> Issue: #6810
> ---
>  libavcodec/h264_slice.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 35dcabd611..04b10656e0 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1287,6 +1287,7 @@ static int h264_select_output_frame(H264Context *h)
>  h->mmco_reset = 0;
>  
>  if (sps->bitstream_restriction_flag ||
> +sps->ref_frame_count ||
>  h->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
>  h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames, 
> sps->num_reorder_frames);
>  }
> 

Hendrik Leppkes wrote:

> This behavior has actually been intentional in the past to keep the
> decode delay lower.

The source of this check is:

  commit fb19e1443bc45e192545d3485ddb9c76e7d77855
  Author: Michael Niedermayer 
  Date:   Sat Jul 19 16:16:00 2008 +

Take the brain amputated spec literally if the user asks for it
(-strict 1).
That is, add 16 frames delay, cache trashing and av desync.
fixes at least the following reference bitstreams:
CABA3_Sony_C.jsv
CACQP3_Sony_D.jsv
CAMANL1_TOSHIBA_B.264
CANL3_Sony_C.jsv
CVBS3_Sony_C.jsv
CVMANL1_TOSHIBA_B.264

Originally committed as revision 14308 to
svn://svn.ffmpeg.org/ffmpeg/trun

But it does not take in account the level based num_reorder_frames (when
ref_frame_count is available). I think that the original idea was to
avoid to set has_b_frames unconditionally to 16. With the proposed
change, has_b_frames are 4 for my problematic input stream.

Again, the output stream is broken (timestamps) when the source stream
has those parameters, so I think that the default behavior of ffmpeg
should be changed.

> If this is supposed to be changed (which needs to be discussed first),
> the std_compliance value should probably be adjusted to NORMAL instead
> of strict, instead of adding the additional condition here
> (num_reorder_frames is only set from the profile if ref_frame_count is
> > 0 in the first place).

Perhaps, my original patch in issue #6810 is better then - remove all
conditions and keep only:

  h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames,
sps->num_reorder_frames);

Please CC: me, I'm not subscribed to the list.

Thanks,
Jaroslav


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

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?


just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case

[...]

ok finally got what you meant with the second case; I had not realized 
that stream specifiers could be applied also to -channel_layout option.

thanks



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



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

Re: [FFmpeg-devel] [DEVEL][PATCH] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  
0001-ffmpeg-fix-channel_layout-bug-on-non-default-layout.patch
 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was not
a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
  MATCH_PER_STREAM_OPT(audio_channels, i, audio_enc->channels, oc, st);
+AVDictionaryEntry *output_layout = av_dict_get(o->g->codec_opts,
+   "channel_layout",
+   NULL, 
AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?


just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case

[...]



on second thought, for the first of your commands with my av_dict_get() 
patch, it's expected behaviour when downmixing  that an error is issued 
if a non standard layout is used; swr_build_matrix can't possibly know 
how to downmix for layout 0x5. So end-users should use a pan filter.


in order for the second command to be passed correctly, I haven't found 
yet a solution





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



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

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

[Timo Rothenpieler]

From: Anton Khirnov 

This will be useful in the CUVID hwaccel.

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

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 0f215d6915..e76be7bd95 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -620,6 +620,18 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 av_assert0((frame->private_ref && frame->private_ref->size == 
sizeof(FrameDecodeData)) ||
!(avctx->codec->capabilities & AV_CODEC_CAP_DR1));
 
+if (frame->private_ref) {
+FrameDecodeData *fdd = (FrameDecodeData*)frame->private_ref->data;
+
+if (fdd->post_process) {
+ret = fdd->post_process(avctx, frame);
+if (ret < 0) {
+av_frame_unref(frame);
+return ret;
+}
+}
+}
+
 av_buffer_unref(>private_ref);
 }
 
@@ -1566,6 +1578,9 @@ static void decode_data_free(void *opaque, uint8_t *data)
 {
 FrameDecodeData *fdd = (FrameDecodeData*)data;
 
+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 519f875c98..51947b9ec0 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"
 
@@ -30,6 +31,19 @@
  * private_ref.
  */
 typedef struct FrameDecodeData {
+/**
+ * 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.15.0

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

[FFmpeg-devel] [PATCH 1/4] avutil/frame: Add private_ref to AVFrame

[Timo Rothenpieler]

From: Michael Niedermayer 

This gives FFmpeg libs a field that they can freely and safely use.
Avoiding the need of wrapping of a users opaque_ref field and its issues.

Signed-off-by: Michael Niedermayer 
---
 libavutil/frame.c |  8 +++-
 libavutil/frame.h | 13 +
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 982fbb5c81..662a7e5ab5 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -383,12 +383,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 av_buffer_unref(>opaque_ref);
+av_buffer_unref(>private_ref);
 if (src->opaque_ref) {
 dst->opaque_ref = av_buffer_ref(src->opaque_ref);
 if (!dst->opaque_ref)
 return AVERROR(ENOMEM);
 }
-
+if (src->private_ref) {
+dst->private_ref = av_buffer_ref(src->private_ref);
+if (!dst->private_ref)
+return AVERROR(ENOMEM);
+}
 return 0;
 }
 
@@ -524,6 +529,7 @@ void av_frame_unref(AVFrame *frame)
 av_buffer_unref(>hw_frames_ctx);
 
 av_buffer_unref(>opaque_ref);
+av_buffer_unref(>private_ref);
 
 get_frame_defaults(frame);
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 0c6aab1c02..d54bd9a354 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -563,6 +563,19 @@ typedef struct AVFrame {
 /**
  * @}
  */
+
+/**
+ * AVBufferRef for internal use by a single libav* library.
+ * Must not be used to transfer data between libraries.
+ * Has to be NULL when ownership of the frame leaves the respective 
library.
+ *
+ * Code outside the FFmpeg libs should never check or change the contents 
of the buffer ref.
+ *
+ * FFmpeg calls av_buffer_unref() on it when the frame is unreferenced.
+ * av_frame_copy_props() calls create a new reference with av_buffer_ref()
+ * for the target frame's private_ref field.
+ */
+AVBufferRef *private_ref;
 } AVFrame;
 
 #if FF_API_FRAME_GET_SET
-- 
2.15.0

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

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

[Timo Rothenpieler]

From: Anton Khirnov 

Use the AVFrame.private_ref field.

This new struct will be useful in the following commits.

Merges Libav commit 359a8a3e2d1194b52b6c386f94fd0929567dfb67.
---
 libavcodec/decode.c  | 51 ++--
 libavcodec/decode.h  | 11 ++
 libavcodec/wrapped_avframe.c |  7 ++
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 86fe5aef52..0f215d6915 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -613,6 +613,16 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 if (ret == AVERROR_EOF)
 avci->draining_done = 1;
 
+/* free the per-frame decode data */
+if (!ret) {
+/* the only case where decode data is not set should be decoders
+ * that do not call ff_get_buffer() */
+av_assert0((frame->private_ref && frame->private_ref->size == 
sizeof(FrameDecodeData)) ||
+   !(avctx->codec->capabilities & AV_CODEC_CAP_DR1));
+
+av_buffer_unref(>private_ref);
+}
+
 return ret;
 }
 
@@ -1552,6 +1562,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_freep();
+}
+
+int ff_attach_decode_data(AVFrame *frame)
+{
+AVBufferRef *fdd_buf;
+FrameDecodeData *fdd;
+
+av_assert1(!frame->private_ref);
+av_buffer_unref(>private_ref);
+
+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);
+}
+
+frame->private_ref = fdd_buf;
+
+return 0;
+}
+
 static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int 
flags)
 {
 const AVHWAccel *hwaccel = avctx->hwaccel;
@@ -1588,8 +1629,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 = ff_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..519f875c98 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -21,8 +21,17 @@
 #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
+ * private_ref.
+ */
+typedef struct FrameDecodeData {
+} FrameDecodeData;
+
 /**
  * Called by decoders to get the next packet for decoding.
  *
@@ -36,4 +45,6 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket 
*pkt);
 
 void ff_decode_bsfs_uninit(AVCodecContext *avctx);
 
+int ff_attach_decode_data(AVFrame *frame);
+
 #endif /* AVCODEC_DECODE_H */
diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
index 5f88a668b9..85ff32d13a 100644
--- a/libavcodec/wrapped_avframe.c
+++ b/libavcodec/wrapped_avframe.c
@@ -25,6 +25,7 @@
  */
 
 #include "avcodec.h"
+#include "decode.h"
 #include "internal.h"
 
 #include "libavutil/internal.h"
@@ -98,6 +99,12 @@ static int wrapped_avframe_decode(AVCodecContext *avctx, 
void *data,
 
 av_frame_move_ref(out, in);
 
+err = ff_attach_decode_data(out);
+if (err < 0) {
+av_frame_unref(out);
+return err;
+}
+
 *got_frame = 1;
 return 0;
 }
-- 
2.15.0

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

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

[Timo Rothenpieler]

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 e76be7bd95..248e02aaca 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1581,6 +1581,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 51947b9ec0..03fc783bba 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -44,6 +44,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.15.0

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

Re: [FFmpeg-devel] [PATCH 10/11] avcodec/blockdsp: add AVX-512 version of clear_block(s)

[James Almer]

On 11/10/2017 10:28 AM, James Darnley wrote:
> On 2017-11-09 20:35, Martin Vignali wrote:
>> 2017-11-09 12:58 GMT+01:00 James Darnley :
>>
>>> From: James Darnley 
>>>
>>> Also adjust alignment requirements where nessecary.
>>> ---
>>> Whether this patch is committed or not the change to 4xm.c should be
>>> picked to
>>> master because the alignment is wrong for the AVX version of this
>>> function.  I
>>> assume it hasn't been noticed yet because it manages to be 32-byte aligned
>>> without intervention.
>>>
>>>
>> Thanks for fixing, the 4xm, i miss it in the avx patch
>>
>> Just by curiosity : can you post the checkasm result (i can't test AVX512) ?
> 
> I certainly can.
> 
>> $ ./tests/checkasm/checkasm --bench --test=blockdsp
>> benchmarking with native FFmpeg timers
>> nop: 26.0
>> checkasm: using random seed 402373647
>> MMX:
>>  - blockdsp.blockdsp [OK]
>> SSE:
>>  - blockdsp.blockdsp [OK]
>> AVX:
>>  - blockdsp.blockdsp [OK]
>> AVX-512:
>>  - blockdsp.blockdsp [OK]
>> checkasm: all 8 tests passed
>> blockdsp.clear_block_c: 23.5
>> blockdsp.clear_block_mmx: 11.5
>> blockdsp.clear_block_sse: 5.5
>> blockdsp.clear_block_avx: 3.0
>> blockdsp.clear_block_avx512: 5.0

This sounds like it's not worth adding.

>> blockdsp.clear_blocks_c: 48.0
>> blockdsp.clear_blocks_mmx: 77.0
>> blockdsp.clear_blocks_sse: 38.0
>> blockdsp.clear_blocks_avx: 18.5
>> blockdsp.clear_blocks_avx512: 11.0

This one is better, but a perf run to check how much CPU time is spent
in this function is needed, because I'm not sure it's important enough
to justify having the CPU throttled just to run avx512 code...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/11] avcodec: add stride alignment needed for AVX-512

[James Almer]

On 11/10/2017 10:58 AM, James Darnley wrote:
> On 2017-11-10 02:38, James Almer wrote:
>> On 11/9/2017 8:58 AM, James Darnley wrote:
>>> ---
>>>  configure | 2 ++
>>>  libavcodec/internal.h | 4 +++-
>>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 146a87324c..fce8030d91 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1886,6 +1886,7 @@ ARCH_FEATURES="
>>>  local_aligned
>>>  simd_align_16
>>>  simd_align_32
>>> +simd_align_64
>>>  "
>>>  
>>>  BUILTIN_LIST="
>>> @@ -2385,6 +2386,7 @@ fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
>>>  fast_unaligned_if_any="aarch64 ppc x86"
>>>  simd_align_16_if_any="altivec neon sse"
>>>  simd_align_32_if_any="avx"
>>> +simd_align_64_if_any="avx512"
>>>  
>>>  # system capabilities
>>>  symver_if_any="symver_asm_label symver_gnu_asm"
>>> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>>> index 7748f09f54..84070431ed 100644
>>> --- a/libavcodec/internal.h
>>> +++ b/libavcodec/internal.h
>>> @@ -87,7 +87,9 @@
>>>  
>>>  #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
>>>  
>>> -#if HAVE_SIMD_ALIGN_32
>>> +#if HAVE_SIMD_ALIGN_64
>>> +#   define STRIDE_ALIGN 64 /* AVX-512 */
>>> +#elif HAVE_SIMD_ALIGN_32
>>>  #   define STRIDE_ALIGN 32
>>>  #elif HAVE_SIMD_ALIGN_16
>>>  #   define STRIDE_ALIGN 16
>>>
>>
>> LGTM, but I'd really like to find a way to start using
>> av_get_cpu_max_align() as it was meant to be done when it was
>> introduced, instead of keeping hardcoding alignment based on configure
>> time options.
> 
> That sounds like a good idea to me.  If time allows I will try to start
> a discussion about it.  It sounds ripe for a lot of bikeshedding :)
> 
>> Maybe adding a line to the av_force_cpu_flags() and
>> av_set_cpu_flags_mask() doxy stating you should reinit all your decoder
>> and encoder contexts after calling them or similar.
> 
> Did you want me to add that one of my patches?

No, it's unrelated to this set. It was a suggestion to solve the above
issue. this patch is good as is while that's discussed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/11] avcodec: add stride alignment needed for AVX-512

[James Darnley]

On 2017-11-10 02:38, James Almer wrote:
> On 11/9/2017 8:58 AM, James Darnley wrote:
>> ---
>>  configure | 2 ++
>>  libavcodec/internal.h | 4 +++-
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 146a87324c..fce8030d91 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1886,6 +1886,7 @@ ARCH_FEATURES="
>>  local_aligned
>>  simd_align_16
>>  simd_align_32
>> +simd_align_64
>>  "
>>  
>>  BUILTIN_LIST="
>> @@ -2385,6 +2386,7 @@ fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
>>  fast_unaligned_if_any="aarch64 ppc x86"
>>  simd_align_16_if_any="altivec neon sse"
>>  simd_align_32_if_any="avx"
>> +simd_align_64_if_any="avx512"
>>  
>>  # system capabilities
>>  symver_if_any="symver_asm_label symver_gnu_asm"
>> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>> index 7748f09f54..84070431ed 100644
>> --- a/libavcodec/internal.h
>> +++ b/libavcodec/internal.h
>> @@ -87,7 +87,9 @@
>>  
>>  #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
>>  
>> -#if HAVE_SIMD_ALIGN_32
>> +#if HAVE_SIMD_ALIGN_64
>> +#   define STRIDE_ALIGN 64 /* AVX-512 */
>> +#elif HAVE_SIMD_ALIGN_32
>>  #   define STRIDE_ALIGN 32
>>  #elif HAVE_SIMD_ALIGN_16
>>  #   define STRIDE_ALIGN 16
>>
> 
> LGTM, but I'd really like to find a way to start using
> av_get_cpu_max_align() as it was meant to be done when it was
> introduced, instead of keeping hardcoding alignment based on configure
> time options.

That sounds like a good idea to me.  If time allows I will try to start
a discussion about it.  It sounds ripe for a lot of bikeshedding :)

> Maybe adding a line to the av_force_cpu_flags() and
> av_set_cpu_flags_mask() doxy stating you should reinit all your decoder
> and encoder contexts after calling them or similar.

Did you want me to add that one of my patches?

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

Re: [FFmpeg-devel] [PATCH 08/11] avcodec/v210enc: add AVX-512 10-bit line pack function

[James Darnley]

On 2017-11-09 20:42, Martin Vignali wrote:
> I doesn't want to block this patch, but
> like you say (in your previous version), that this version is not faster,
> i'm not sure, it's interesting to apply it.
> You already made "real" avx512 version for other funcs, in order to check
> the rest of yours patchs.

I will not apply any of the new AVX-512/ZMM function patches because
they need proper testing in a real world situation.  Sorry but I don't
have time to see whether these few naive length extensions are better.
I have my own work to see whether AVX-512/ZMM provides a speed-up.  If
that pans out then FFmpeg will benefit because some of the work will
trickle back to it.

I mentioned previously that using ZMM registers will cause the CPU to
reduce its frequency.

Gramner said on IRC that a user should spend 20-30% of time in
AVX-512/ZMM code for it to be a net gain in speed.
From ffmpeg-devel IRC on 2017-10-26
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-October/004622.html
> [18:49:26 CEST]  J_Darnley: be aware that using zmm registers 
> induces significant frequency drops which reduces performance of everything 
> else, so if you want to use 512-bit vectors you better go all in on it to 
> make up for it. you probably want to spend at least 20-30% of overall runtime 
> in avx-512 code
> [18:50:00 CEST]  the alternative is to stay in 256-bit mode and just 
> leverage new instructions and opmasks

This means any cycles you might save by using longer registers, fewer
instructions, better instructions, whatever, will be lost because the
frequency drops meaning it takes longer to execute overall.

I don't have time to perform that sort of in-depth testing.

I will post the checkasm benchmark results for the 3 patches though.

> $ ./tests/checkasm/checkasm --bench --test=v210enc
> benchmarking with native FFmpeg timers
> nop: 26.0
> checkasm: using random seed 3018512312
> SSSE3:
>  - v210enc.planar_pack [OK]
> AVX:
>  - v210enc.planar_pack [OK]
> AVX2:
>  - v210enc.planar_pack [OK]
> AVX-512:
>  - v210enc.planar_pack [OK]
> checkasm: all 6 tests passed
> v210_planar_pack_8_c: 1726.5
> v210_planar_pack_8_ssse3: 308.5
> v210_planar_pack_8_avx: 313.5
> v210_planar_pack_8_avx2: 213.5
> v210_planar_pack_10_c: 1424.0
> v210_planar_pack_10_ssse3: 301.0
> v210_planar_pack_10_avx2: 227.5
> v210_planar_pack_10_avx512: 229.5

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

Re: [FFmpeg-devel] [PATCH 11/11] avcodec/lossless_videodsp: add AVX-512 version of add_bytes

[James Darnley]

On 2017-11-09 20:43, Martin Vignali wrote:
> 2017-11-09 20:37 GMT+01:00 Martin Vignali :
>> lgtm
>>
>> Can you post your checkasm benchmark result for this ?

Yep

> $ ./tests/checkasm/checkasm --bench --test=llviddsp
> benchmarking with native FFmpeg timers
> nop: 26.0
> checkasm: using random seed 3684557040
> SSE2:
>  - llviddsp.add_bytes [OK]
>  - llviddsp.add_median_pred   [OK]
> SSSE3:
>  - llviddsp.add_left_pred_zero[OK]
>  - llviddsp.add_left_pred_rnd_acc [OK]
>  - llviddsp.add_left_pred_int16   [OK]
> SSE4.1:
>  - llviddsp.add_left_pred_int16   [OK]
> AVX2:
>  - llviddsp.add_bytes [OK]
> AVX-512:
>  - llviddsp.add_bytes [OK]
> checkasm: all 8 tests passed
> add_bytes_c: 701.0
> add_bytes_sse2: 19.0
> add_bytes_avx2: 78.0
> add_bytes_avx512: 10.0
> add_left_pred_int16_c: 3324.5
> add_left_pred_int16_ssse3: 2360.5
> add_left_pred_int16_sse4: 797.5
> add_left_pred_rnd_acc_c: 2074.0
> add_left_pred_rnd_acc_ssse3: 461.5
> add_left_pred_zero_c: 1987.0
> add_left_pred_zero_ssse3: 461.5
> add_median_pred_c: 15809.5
> add_median_pred_sse2: 1113.5

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

Re: [FFmpeg-devel] [PATCH 10/11] avcodec/blockdsp: add AVX-512 version of clear_block(s)

[James Darnley]

On 2017-11-09 20:35, Martin Vignali wrote:
> 2017-11-09 12:58 GMT+01:00 James Darnley :
> 
>> From: James Darnley 
>>
>> Also adjust alignment requirements where nessecary.
>> ---
>> Whether this patch is committed or not the change to 4xm.c should be
>> picked to
>> master because the alignment is wrong for the AVX version of this
>> function.  I
>> assume it hasn't been noticed yet because it manages to be 32-byte aligned
>> without intervention.
>>
>>
> Thanks for fixing, the 4xm, i miss it in the avx patch
> 
> Just by curiosity : can you post the checkasm result (i can't test AVX512) ?

I certainly can.

> $ ./tests/checkasm/checkasm --bench --test=blockdsp
> benchmarking with native FFmpeg timers
> nop: 26.0
> checkasm: using random seed 402373647
> MMX:
>  - blockdsp.blockdsp [OK]
> SSE:
>  - blockdsp.blockdsp [OK]
> AVX:
>  - blockdsp.blockdsp [OK]
> AVX-512:
>  - blockdsp.blockdsp [OK]
> checkasm: all 8 tests passed
> blockdsp.clear_block_c: 23.5
> blockdsp.clear_block_mmx: 11.5
> blockdsp.clear_block_sse: 5.5
> blockdsp.clear_block_avx: 3.0
> blockdsp.clear_block_avx512: 5.0
> blockdsp.clear_blocks_c: 48.0
> blockdsp.clear_blocks_mmx: 77.0
> blockdsp.clear_blocks_sse: 38.0
> blockdsp.clear_blocks_avx: 18.5
> blockdsp.clear_blocks_avx512: 11.0

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

[FFmpeg-devel] [PATCH] avcodec: fix wrong duration of packets (dvd, bluray)

[Александр Слободенюк]

Fixing very little bug for blu ray pcm in .mts files:

The nature of bug: duration of blu ray packets is little bit wrong.
How to reproduce:
./ffprobe -i bluray-pcm-file.mts -show_packets -select_streams a:0 | head -n 50
...
Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, 
s16, 1536 kb/s
...
[PACKET]
codec_type=audio
stream_index=1
pts=118350
pts_time=1.315000
dts=118350
dts_time=1.315000
duration=451
duration_time=0.005011
convergence_duration=N/A
convergence_duration_time=N/A
size=964
pos=1035456
flags=K_
[SIDE_DATA]
side_data_type=MPEGTS Stream ID
[/SIDE_DATA]
[/PACKET]
[PACKET]
codec_type=audio
stream_index=1
pts=118800
pts_time=1.32
dts=118800
dts_time=1.32
duration=451
duration_time=0.005011
convergence_duration=N/A
convergence_duration_time=N/A
size=964
pos=1048704
flags=K_
[SIDE_DATA]
side_data_type=MPEGTS Stream ID
[/SIDE_DATA]
[/PACKET]


Between the packets you can see that dts increments by "450", not "451":

dts=118350 
=> 
dts=118800

We can compute the duration by ourself from the size: 
size = 964 .
 BDPCM Header length is 4 bytes.
 => samples size = 960
 size of one sample = 16 bits/8 * 2 channels = 4
 then number of samples = 960/4 = 240 samples
 
 duration = 240 * 9 / 48000 = 450
 
 so, the duration in packet
 "duration=451"
 is incorrect
 
 
 Following the code in avcodec:utilc.c get_audio_frame_duration(),
 we can see, that header sizes were not excluded from the frame size.
 
 P.S. The bug is the same for dvd pcm, but it doesn't affect on anything. 
 
 How to make sure, that "magic constants" 3 and 4 for the streams are constant 
for all cases:
 see the decoding code:
 
 pcm-bluray.c : 144
 pcm-dvd.c : 250
 s302m.c : 108 (yes, s302m case is not modified)
 
 P.P.S.
 1. It looks like for s302m the exclusion of 4 bytes happens (in a hackish way, 
splitted with protection from division by zero)
 2. You can see that code around the patch contains 3 different ways of 
protection from dividing by zero. 
 And actually for all this streams we can check bps > 8 (isn't it?).

0001-avcodec-fix-wrong-duration-of-packets-dvd-bluray.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

[Kv Pham]

> Hi atomnuker,
>
> that's wonderful;
>
> there are two things also:
>
> 1) there are changes to make to the list of channel layouts not requiring
> PCE
>
> ==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK since the previous
> is 5.0(side) while the latter is 5.0 which is what is in spec (table 1.19
> ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )
>
> see patch in attachment (can't be applied directly due to rebasing issues
> from your initial patch)
>
>
Checked the spec, you're right, fixed.


Great, you're right also about side being better than back in the commit
message.




> 2) for everything to work I had to also apply the patch from here:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217357.html
>
> If you ffmpeg -loglevel debug , you will see that on non-default channel
> layouts, there is an auto insertion of a resampler filter : the
> channel_layout option is not passed correctly in the chain.
>
> for instance: ffmpeg -channel_layout octagonal -i input.wav -c:a aac
> -channel_layout octagonal out.mkv will matrix the input from octagonal to
> 7.1 before the encoding.
>
> Check ticket 6706 for details of the issue.
>
> I am not knowledgeable enough to be sure my fix is correct; it's working
> for sure, but I've had very few feedback (only Michael and Moritz about
> styling issues).
>


Pining Michael to take a look at it.



Discussing this with Michael.
My patch fails when there is down or upmixing.
I think there are at least two bugs hiding one behind another within the
filter chain.
It's a pity because this cripples your PCE implementation to ffmpeg default
channel layouts only (2.1 4.0 5.0 5.1 6.1 7.1 hexadecagonal), where 4.0 5.0
5.1 7.1 do not require PCE anyway.
I'll try to find a solution but senior dev help might be needed because
this is quite convoluted.

Best


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Nicolas George]

Le decadi 20 brumaire, an CCXXVI, Paul B Mahol a écrit :
> Yes.

Ok, I will look at the code with that in mind.

> What if user sets overlap to same or greater than nb_frames, just error out?

That seems reasonable. Clamping the value with a warning would be ok
too, I think. Both of these solutions allow extension.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Paul B Mahol]

On 11/10/17, Nicolas George  wrote:
> Le septidi 17 brumaire, an CCXXVI, Paul B Mahol a ecrit :
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi  |  5 +
>>  libavfilter/vf_tile.c | 53
>> ++-
>>  2 files changed, 49 insertions(+), 9 deletions(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 2ba6e04166..a6d537485b 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -14439,6 +14439,11 @@ refer to the pad video filter.
>>  Specify the color of the unused area. For the syntax of this option,
>> check the
>>  "Color" section in the ffmpeg-utils manual. The default value of
>> @var{color}
>>  is "black".
>> +
>
>> +@item skip
>> +Set the number of frames to skip from input before rendering output
>> frame.
>> +The default value is @code{0}, meaning skip @var{nb_frames} frames. If it
>> is more
>> +than @var{nb_frames} its is set to @var{nb_frames}.
>
> I had trouble understanding the logic of the code, until I realized the
> problem was here: I think the documentation does not explain well what
> the option is meant to do.
>
> If I understand correctly, using an example: if a 5x4 tile, the normal
> mapping is:
>
> out  0 <- in  0 .. in 19
> out  1 <- in 20 .. in 39
> out  2 <- in 40 .. in 59
> out  3 <- in 60 .. in 79
>
> But if "skip" is set to 15, it becomes:
>
> out  0 <- in  0 .. in 19
> out  1 <- in 15 .. in 34
> out  2 <- in 30 .. in 49
> out  3 <- in 45 .. in 64
>
> In other words, the output frames overlap by nb_frames - skip input
> frames.
>
> Is it what you intended?

Yes.

>
> If so, then the doc needs to be clarified. And I think the name of the
> option is misleading. What about "step"? Or maybe "period"?

It could be...

>
> Or possibly even better: reverse the direction of the option "overlap=5"
> instead of "step=15".

What if user sets overlap to same or greater than nb_frames, just error out?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Nicolas George]

Le septidi 17 brumaire, an CCXXVI, Paul B Mahol a écrit :
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  5 +
>  libavfilter/vf_tile.c | 53 
> ++-
>  2 files changed, 49 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 2ba6e04166..a6d537485b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -14439,6 +14439,11 @@ refer to the pad video filter.
>  Specify the color of the unused area. For the syntax of this option, check 
> the
>  "Color" section in the ffmpeg-utils manual. The default value of @var{color}
>  is "black".
> +

> +@item skip
> +Set the number of frames to skip from input before rendering output frame.
> +The default value is @code{0}, meaning skip @var{nb_frames} frames. If it is 
> more
> +than @var{nb_frames} its is set to @var{nb_frames}.

I had trouble understanding the logic of the code, until I realized the
problem was here: I think the documentation does not explain well what
the option is meant to do.

If I understand correctly, using an example: if a 5x4 tile, the normal
mapping is:

out  0 <- in  0 .. in 19
out  1 <- in 20 .. in 39
out  2 <- in 40 .. in 59
out  3 <- in 60 .. in 79

But if "skip" is set to 15, it becomes:

out  0 <- in  0 .. in 19
out  1 <- in 15 .. in 34
out  2 <- in 30 .. in 49
out  3 <- in 45 .. in 64

In other words, the output frames overlap by nb_frames - skip input
frames.

Is it what you intended?

If so, then the doc needs to be clarified. And I think the name of the
option is misleading. What about "step"? Or maybe "period"?

Or possibly even better: reverse the direction of the option "overlap=5"
instead of "step=15".

Regards,

-- 
  Nicolas George


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