Re: [FFmpeg-devel] APNG encoder can work incorrectly

[Dmitriy]

Yes of course

> On 3/31/16, Dmitriy  wrote:
>> I create a special video. You can download it using the link
>>
>> https://drive.google.com/file/d/0B8rMLdq9Vq55QmwwcVJDVkZoM1E/view?usp=sharing
>>
>> Convert it to .apng format with
>> ffmpeg -i apng_test.avi apng_test.apng
>>
>> The result file will be empty.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>

> Could you provide patch?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Disha Singh]

Somehow I am not getting these warnings when I compile. (not all)
Should I remove the functions which are defined but not used. They may be
needed sometime later.
I have removed the error in line 1888.
I do not get any error in line 2462. What should I add in my code that the
compiler you used does not show this error?

On Wed, Mar 30, 2016 at 8:04 AM, Michael Niedermayer  wrote:

> On Wed, Mar 30, 2016 at 06:38:33AM +0530, Disha Singh wrote:
> > The most recent patch has been attached. The lpc error persists.
> > I have removed some patcheck errors.
> >
>
> [...]
>
> >
> +/
> > + *** Functions that process the data in some way
> 
> > +
> /
> > +
> > +#define INT24_MAX ((1 << 23) - 1)
> > +#define INT24_MIN (~INT24_MAX)
> > +
> > +#define MSB_MASK(bits)  (-1u << bits)
> > +
> > +/** Applies the filter to the current samples, and saves the residual
> back
> > + *  into the samples buffer. If the filter is too bad and overflows the
> > + *  maximum amount of bits allowed (24), the samples buffer is left as
> is and
> > + *  the function returns -1.
> > + */
> > +static int apply_filter(MLPEncodeContext *ctx, unsigned int channel)
> > +{
> > +FilterParams *fp[NUM_FILTERS] = {
> &ctx->cur_channel_params[channel].filter_params[FIR],
> > +
> &ctx->cur_channel_params[channel].filter_params[IIR], };
> > +int32_t **filter_state_buffer =
> (av_malloc((NUM_FILTERS)*sizeof(int32_t*));
>
> doesnt build
>
> CC  libavcodec/mlpenc.o
> libavcodec/mlpenc.c: In function ‘mlp_encode_init’:
> libavcodec/mlpenc.c:577:5: warning: ‘coded_frame’ is deprecated (declared
> at libavcodec/avcodec.h:2967) [-Wdeprecated-declarations]
> libavcodec/mlpenc.c: In function ‘set_filter_params’:
> libavcodec/mlpenc.c:1480:35: warning: passing argument 3 of
> ‘ff_lpc_calc_coefs’ makes integer from pointer without a cast [enabled by
> default]
> libavcodec/lpc.h:93:5: note: expected ‘int’ but argument is of type
> ‘unsigned int *’
> libavcodec/mlpenc.c: In function ‘apply_filter’:
> libavcodec/mlpenc.c:1888:69: error: expected ‘)’ before ‘;’ token
> libavcodec/mlpenc.c:2462:1: error: expected declaration or statement at
> end of input
> libavcodec/mlpenc.c:1888:15: warning: unused variable
> ‘filter_state_buffer’ [-Wunused-variable]
> libavcodec/mlpenc.c:1886:19: warning: unused variable ‘fp’
> [-Wunused-variable]
> libavcodec/mlpenc.c:2462:1: error: no return statement in function
> returning non-void [-Werror=return-type]
> libavcodec/mlpenc.c: At top level:
> libavcodec/mlpenc.c:205:19: warning: ‘restart_best_offset’ defined but not
> used [-Wunused-variable]
> libavcodec/mlpenc.c:283:12: warning: ‘compare_decoding_params’ defined but
> not used [-Wunused-function]
> libavcodec/mlpenc.c:377:13: warning: ‘copy_restart_frame_params’ defined
> but not used [-Wunused-function]
> libavcodec/mlpenc.c:438:13: warning: ‘default_decoding_params’ defined but
> not used [-Wunused-function]
> libavcodec/mlpenc.c:486:34: warning: ‘mlp_encode_init’ defined but not
> used [-Wunused-function]
> libavcodec/mlpenc.c:702:21: warning: ‘bitcount_restart_header’ defined but
> not used [-Wunused-function]
> libavcodec/mlpenc.c:746:21: warning: ‘bitcount_decoding_params’ defined
> but not used [-Wunused-function]
> libavcodec/mlpenc.c:1242:21: warning: ‘write_access_unit’ defined but not
> used [-Wunused-function]
> libavcodec/mlpenc.c:1338:13: warning: ‘input_data’ defined but not used
> [-Wunused-function]
> libavcodec/mlpenc.c:1347:13: warning: ‘input_to_sample_buffer’ defined but
> not used [-Wunused-function]
> libavcodec/mlpenc.c:1388:13: warning: ‘determine_quant_step_size’ defined
> but not used [-Wunused-function]
> libavcodec/mlpenc.c:1496:13: warning: ‘determine_filters’ defined but not
> used [-Wunused-function]
> libavcodec/mlpenc.c:1563:13: warning: ‘lossless_matrix_coeffs’ defined but
> not used [-Wunused-function]
> libavcodec/mlpenc.c:1812:13: warning: ‘determine_bits’ defined but not
> used [-Wunused-function]
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From 39a1a0faf0755f581a64c7d0148f33f839213ed2 Mon Sep 17 00:00:00 2001
From: dinux5 
Date: Sun, 27 Mar 2016 17:39:57 +0530 git apply -v --index path/file.patch
Subject: [PATCH] MLP encoder addition.

---
 Changelog  |1 +
 configure  |1 +
 libavcodec/Makefile|1 +
 libavcodec/allcodecs.c |2 +-
 libavcodec/mlp.h   |4 +
 libavcodec/mlpenc.c| 2462 
 5 files changed, 2470 insertions(+), 1 deletion(-)
 create mode 10

Re: [FFmpeg-devel] [PATCH 1/2] lavc/audiotoolboxdec: fix a number of config and timestamp issues

[pon pon]

it seems you are correct. i can't playback the ac3 files with afplay and
afconvert, though @constant  kAudioFormatAC3 is described in
CoreAudioType.h and i can playback them  with quicktime player(not 7 and
without perian). the results are attached.

i did some tests.

decoding test(gsm_ms_at and ilbc_at not done)
2ch and 51ch, aac_at ac3_at gsm_ms_at adpcm_ima_qt_at ilbc_at alac_at
mp1_at mp2_at mp3_at pcm_alaw_at pcm_mulaw_at
1ch, amr_nb_at
there are errors for pcm_alaw_at  pcm_mulaw_at.
the results are attached.

ponpon



2016-03-31 11:00 GMT+09:00 Rodger Combs :

> - ADTS-formatted AAC didn't work
> - Channel layouts were never exported
> - Channel mappings were incorrect beyond stereo
> - Channel counts weren't updated after packets were decoded
> - Timestamps were exported incorrectly
> ---
>  libavcodec/audiotoolboxdec.c | 286
> +--
>  1 file changed, 221 insertions(+), 65 deletions(-)
>
> diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
> index 1fa6f16..4ff46ea 100644
> --- a/libavcodec/audiotoolboxdec.c
> +++ b/libavcodec/audiotoolboxdec.c
> @@ -38,8 +38,9 @@ typedef struct ATDecodeContext {
>  AVPacket in_pkt;
>  AVPacket new_in_pkt;
>  AVBitStreamFilterContext *bsf;
> +char *decoded_data;
> +int channel_map[64];
>
> -unsigned pkt_size;
>  int64_t last_pts;
>  int eof;
>  } ATDecodeContext;
> @@ -81,20 +82,127 @@ static UInt32 ffat_get_format_id(enum AVCodecID
> codec, int profile)
>  }
>  }
>
> -static void ffat_update_ctx(AVCodecContext *avctx)
> +static int ffat_get_channel_id(AudioChannelLabel label)
> +{
> +if (label == 0)
> +return -1;
> +else if (label <= kAudioChannelLabel_LFEScreen)
> +return label - 1;
> +else if (label <= kAudioChannelLabel_RightSurround)
> +return label + 4;
> +else if (label <= kAudioChannelLabel_CenterSurround)
> +return label + 1;
> +else if (label <= kAudioChannelLabel_RightSurroundDirect)
> +return label + 23;
> +else if (label <= kAudioChannelLabel_TopBackRight)
> +return label - 1;
> +else if (label < kAudioChannelLabel_RearSurroundLeft)
> +return -1;
> +else if (label <= kAudioChannelLabel_RearSurroundRight)
> +return label - 29;
> +else if (label <= kAudioChannelLabel_RightWide)
> +return label - 4;
> +else if (label == kAudioChannelLabel_LFE2)
> +return ff_ctzll(AV_CH_LOW_FREQUENCY_2);
> +else if (label == kAudioChannelLabel_Mono)
> +return ff_ctzll(AV_CH_FRONT_CENTER);
> +else
> +return -1;
> +}
> +
> +static int ffat_compare_channel_descriptions(const void* a, const void* b)
> +{
> +const AudioChannelDescription* da = a;
> +const AudioChannelDescription* db = b;
> +return ffat_get_channel_id(da->mChannelLabel) -
> ffat_get_channel_id(db->mChannelLabel);
> +}
> +
> +static AudioChannelLayout *ffat_convert_layout(AudioChannelLayout
> *layout, UInt32* size)
> +{
> +AudioChannelLayoutTag tag = layout->mChannelLayoutTag;
> +AudioChannelLayout *new_layout;
> +if (tag == kAudioChannelLayoutTag_UseChannelDescriptions)
> +return layout;
> +else if (tag == kAudioChannelLayoutTag_UseChannelBitmap)
> +
> AudioFormatGetPropertyInfo(kAudioFormatProperty_ChannelLayoutForBitmap,
> +   sizeof(UInt32),
> &layout->mChannelBitmap, size);
> +else
> +
> AudioFormatGetPropertyInfo(kAudioFormatProperty_ChannelLayoutForTag,
> +   sizeof(AudioChannelLayoutTag), &tag,
> size);
> +new_layout = av_malloc(*size);
> +if (!new_layout) {
> +av_free(layout);
> +return NULL;
> +}
> +if (tag == kAudioChannelLayoutTag_UseChannelBitmap)
> +
> AudioFormatGetProperty(kAudioFormatProperty_ChannelLayoutForBitmap,
> +   sizeof(UInt32), &layout->mChannelBitmap,
> size, new_layout);
> +else
> +AudioFormatGetProperty(kAudioFormatProperty_ChannelLayoutForTag,
> +   sizeof(AudioChannelLayoutTag), &tag, size,
> new_layout);
> +new_layout->mChannelLayoutTag =
> kAudioChannelLayoutTag_UseChannelDescriptions;
> +av_free(layout);
> +return new_layout;
> +}
> +
> +static int ffat_update_ctx(AVCodecContext *avctx)
>  {
>  ATDecodeContext *at = avctx->priv_data;
> -AudioStreamBasicDescription in_format;
> -UInt32 size = sizeof(in_format);
> +AudioStreamBasicDescription format;
> +UInt32 size = sizeof(format);
>  if (!AudioConverterGetProperty(at->converter,
>
> kAudioConverterCurrentInputStreamDescription,
> -   &size, &in_format)) {
> -avctx->channels = in_format.mChannelsPerFrame;
> -at->pkt_size = in_format.mFramesPerPacket;
> +   &size, &format)) {
> +if (format.mSampleRate)
> +avctx->sample_rate = format.mSampleRate;
> +avct

Re: [FFmpeg-devel] [PATCH 2/6] lavc/audiotoolboxenc: fix a number of config issues

[pon pon]

i did some tests inclluding profiles under osx1095.

encoding test
51ch->2ch and 51ch->51ch, aac_at, alac_at, pcm_alaw_at, pcm_mulaw_at
there is message "Trying to remove 2048 samples, but the queue is empty" in
encoding aac_at with profile aac_he and 51ch->2ch and 51ch->51ch and
encoding aac_at with profile aac_he_v2 and 51ch->2ch. is it normal?
can't encode aac_at with profile aac_he_v2 and 51ch->51ch. is 51ch
supported?

51ch->1ch, 51ch->2ch, and 51ch->51ch, ilbc_at
can't encode all.

for your further work
codecs supported by afconvert of osx1095 for encoding
aac aace aacf aach aacl aacp alac alaw ima4 I8 BEI16 BEI24 BEI32 BEF32
BEF64 LEI16 LEI24 LEI32 LEF32 LEF64 ulaw

ponpon


2016-03-28 2:20 GMT+09:00 Rodger Combs :

> - size variables were used in a confusing way
> - incorrect size var use led to channel layouts not being set properly
> - channel layouts were incorrectly mapped for >2-channel AAC
> - bitrates not accepted by the encoder were discarded instead of being
> clamped
> - some minor style/indentation fixes
> ---
>  libavcodec/audiotoolboxenc.c | 198
> ++-
>  1 file changed, 176 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
> index 4797b2a..22352da 100644
> --- a/libavcodec/audiotoolboxenc.c
> +++ b/libavcodec/audiotoolboxenc.c
> @@ -146,6 +146,86 @@ static int get_ilbc_mode(AVCodecContext *avctx)
>  return 30;
>  }
>
> +static av_cold int get_channel_label(int channel)
> +{
> +uint64_t map = 1 << channel;
> +if (map <= AV_CH_LOW_FREQUENCY)
> +return channel + 1;
> +else if (map <= AV_CH_BACK_RIGHT)
> +return channel + 29;
> +else if (map <= AV_CH_BACK_CENTER)
> +return channel - 1;
> +else if (map <= AV_CH_SIDE_RIGHT)
> +return channel - 4;
> +else if (map <= AV_CH_TOP_BACK_RIGHT)
> +return channel + 1;
> +else if (map <= AV_CH_STEREO_RIGHT)
> +return -1;
> +else if (map <= AV_CH_WIDE_RIGHT)
> +return channel + 4;
> +else if (map <= AV_CH_SURROUND_DIRECT_RIGHT)
> +return channel - 23;
> +else if (map == AV_CH_LOW_FREQUENCY_2)
> +return kAudioChannelLabel_LFE2;
> +else
> +return -1;
> +}
> +
> +static int remap_layout(AudioChannelLayout *layout, uint64_t in_layout,
> int count)
> +{
> +int i;
> +int c = 0;
> +layout->mChannelLayoutTag =
> kAudioChannelLayoutTag_UseChannelDescriptions;
> +layout->mNumberChannelDescriptions = count;
> +for (i = 0; i < count; i++) {
> +int label;
> +while (!(in_layout & (1 << c)) && c < 64)
> +c++;
> +if (c == 64)
> +return AVERROR(EINVAL); // This should never happen
> +label = get_channel_label(c);
> +layout->mChannelDescriptions[i].mChannelLabel = label;
> +if (label < 0)
> +return AVERROR(EINVAL);
> +c++;
> +}
> +return 0;
> +}
> +
> +static int get_aac_tag(uint64_t in_layout)
> +{
> +switch (in_layout) {
> +case AV_CH_LAYOUT_MONO:
> +return kAudioChannelLayoutTag_Mono;
> +case AV_CH_LAYOUT_STEREO:
> +return kAudioChannelLayoutTag_Stereo;
> +case AV_CH_LAYOUT_QUAD:
> +return kAudioChannelLayoutTag_AAC_Quadraphonic;
> +case AV_CH_LAYOUT_OCTAGONAL:
> +return kAudioChannelLayoutTag_AAC_Octagonal;
> +case AV_CH_LAYOUT_SURROUND:
> +return kAudioChannelLayoutTag_AAC_3_0;
> +case AV_CH_LAYOUT_4POINT0:
> +return kAudioChannelLayoutTag_AAC_4_0;
> +case AV_CH_LAYOUT_5POINT0:
> +return kAudioChannelLayoutTag_AAC_5_0;
> +case AV_CH_LAYOUT_5POINT1:
> +return kAudioChannelLayoutTag_AAC_5_1;
> +case AV_CH_LAYOUT_6POINT0:
> +return kAudioChannelLayoutTag_AAC_6_0;
> +case AV_CH_LAYOUT_6POINT1:
> +return kAudioChannelLayoutTag_AAC_6_1;
> +case AV_CH_LAYOUT_7POINT0:
> +return kAudioChannelLayoutTag_AAC_7_0;
> +case AV_CH_LAYOUT_7POINT1_WIDE_BACK:
> +return kAudioChannelLayoutTag_AAC_7_1;
> +case AV_CH_LAYOUT_7POINT1:
> +return kAudioChannelLayoutTag_MPEG_7_1_C;
> +default:
> +return 0;
> +}
> +}
> +
>  static av_cold int ffat_init_encoder(AVCodecContext *avctx)
>  {
>  ATDecodeContext *at = avctx->priv_data;
> @@ -170,11 +250,12 @@ static av_cold int ffat_init_encoder(AVCodecContext
> *avctx)
>  .mFormatID = ffat_get_format_id(avctx->codec_id, avctx->profile),
>  .mChannelsPerFrame = in_format.mChannelsPerFrame,
>  };
> -AudioChannelLayout channel_layout = {
> -.mChannelLayoutTag = kAudioChannelLayoutTag_UseChannelBitmap,
> -.mChannelBitmap = avctx->channel_layout,
> -};
> -UInt32 size = sizeof(channel_layout);
> +UInt32 layout_size = sizeof(AudioChannelLayout) +
> + sizeof(AudioChannelDescription) *
> avctx->channels;
> +AudioChannelLayout *channel_layout = av_malloc(layo

Re: [FFmpeg-devel] [PATCH v2 1/8] lavu: improve documentation of some AVFrame functions

[wm4]

On Wed, 23 Mar 2016 13:47:08 + (UTC)
Carl Eugen Hoyos  wrote:

> wm4  googlemail.com> writes:
> 
> > + * warning: if frame already has been allocated, calling this function will
> > + * leak memory. In addition, undefined behavior can occur in certain
> > + * cases.  
> 
> If this is correct, I believe the following is a slightly 
> better wording:
> if frame already has been allocated undefined behaviour including 
> memory leaks can occur.

Pushed, with the suggested wording approximately applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/8] lavc: factor apply_param_change() AV_EF_EXPLODE handling

[wm4]

On Wed, 23 Mar 2016 16:34:57 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 23, 2016 at 02:02:09PM +0100, wm4 wrote:
> > Remove the duplicated code for handling failure of apply_param_change().
> > ---
> >  libavcodec/utils.c | 34 +++---
> >  1 file changed, 19 insertions(+), 15 deletions(-)  
> 
> still LGTM
> 
> thx
> 
> [...]

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

[FFmpeg-devel] [PATCH 1/2] avcodec: properly initialize AVCodecParameters profile/level

[Hendrik Leppkes]

---
 libavcodec/utils.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f991135..df30d57 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3713,6 +3713,8 @@ static void codec_parameters_reset(AVCodecParameters *par)
 par->color_space = AVCOL_SPC_UNSPECIFIED;
 par->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
 par->sample_aspect_ratio = (AVRational){ 0, 1 };
+par->profile = FF_PROFILE_UNKNOWN;
+par->level   = FF_LEVEL_UNKNOWN;
 }
 
 AVCodecParameters *avcodec_parameters_alloc(void)
-- 
2.7.2.windows.1

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

[FFmpeg-devel] [PATCH 2/2] exif: take a generic log context

[Hendrik Leppkes]

The AVCodecContext is only used for logging, so instead take any valid log 
context.
This allows reusing the exif functions more easily in avformat.
---
 libavcodec/exif.c | 16 
 libavcodec/exif.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/exif.c b/libavcodec/exif.c
index fa30f05..07ce174 100644
--- a/libavcodec/exif.c
+++ b/libavcodec/exif.c
@@ -41,14 +41,14 @@ static const char *exif_get_tag_name(uint16_t id)
 }
 
 
-static int exif_add_metadata(AVCodecContext *avctx, int count, int type,
+static int exif_add_metadata(void *logctx, int count, int type,
  const char *name, const char *sep,
  GetByteContext *gb, int le,
  AVDictionary **metadata)
 {
 switch(type) {
 case 0:
-av_log(avctx, AV_LOG_WARNING,
+av_log(logctx, AV_LOG_WARNING,
"Invalid TIFF tag type 0 found for %s with size %d\n",
name, count);
 return 0;
@@ -64,13 +64,13 @@ static int exif_add_metadata(AVCodecContext *avctx, int 
count, int type,
 case TIFF_SLONG:
 case TIFF_LONG : return ff_tadd_long_metadata(count, name, sep, gb, 
le, metadata);
 default:
-avpriv_request_sample(avctx, "TIFF tag type (%u)", type);
+avpriv_request_sample(logctx, "TIFF tag type (%u)", type);
 return 0;
 };
 }
 
 
-static int exif_decode_tag(AVCodecContext *avctx, GetByteContext *gbytes, int 
le,
+static int exif_decode_tag(void *logctx, GetByteContext *gbytes, int le,
int depth, AVDictionary **metadata)
 {
 int ret, cur_pos;
@@ -92,7 +92,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
GetByteContext *gbytes, int le
 // store metadata or proceed with next IFD
 ret = ff_tis_ifd(id);
 if (ret) {
-ret = avpriv_exif_decode_ifd(avctx, gbytes, le, depth + 1, metadata);
+ret = avpriv_exif_decode_ifd(logctx, gbytes, le, depth + 1, metadata);
 } else {
 const char *name = exif_get_tag_name(id);
 char *use_name   = (char*) name;
@@ -105,7 +105,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
GetByteContext *gbytes, int le
 snprintf(use_name, 7, "0x%04X", id);
 }
 
-ret = exif_add_metadata(avctx, count, type, use_name, NULL,
+ret = exif_add_metadata(logctx, count, type, use_name, NULL,
 gbytes, le, metadata);
 
 if (!name) {
@@ -119,7 +119,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
GetByteContext *gbytes, int le
 }
 
 
-int avpriv_exif_decode_ifd(AVCodecContext *avctx, GetByteContext *gbytes, int 
le,
+int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
int depth, AVDictionary **metadata)
 {
 int i, ret;
@@ -132,7 +132,7 @@ int avpriv_exif_decode_ifd(AVCodecContext *avctx, 
GetByteContext *gbytes, int le
 }
 
 for (i = 0; i < entries; i++) {
-if ((ret = exif_decode_tag(avctx, gbytes, le, depth, metadata)) < 0) {
+if ((ret = exif_decode_tag(logctx, gbytes, le, depth, metadata)) < 0) {
 return ret;
 }
 }
diff --git a/libavcodec/exif.h b/libavcodec/exif.h
index 2f509ba..5f09208 100644
--- a/libavcodec/exif.h
+++ b/libavcodec/exif.h
@@ -164,7 +164,7 @@ static const struct exif_tag tag_list[] = { // JEITA 
CP-3451 EXIF specification:
 
 /** Recursively decodes all IFD's and
  *  adds included TAGS into the metadata dictionary. */
-int avpriv_exif_decode_ifd(AVCodecContext *avctx, GetByteContext *gbytes, int 
le,
+int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
int depth, AVDictionary **metadata);
 
 #endif /* AVCODEC_EXIF_H */
-- 
2.7.2.windows.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: properly initialize AVCodecParameters profile/level

[wm4]

On Fri,  1 Apr 2016 13:13:02 +0200
Hendrik Leppkes  wrote:

> ---
>  libavcodec/utils.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index f991135..df30d57 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -3713,6 +3713,8 @@ static void codec_parameters_reset(AVCodecParameters 
> *par)
>  par->color_space = AVCOL_SPC_UNSPECIFIED;
>  par->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
>  par->sample_aspect_ratio = (AVRational){ 0, 1 };
> +par->profile = FF_PROFILE_UNKNOWN;
> +par->level   = FF_LEVEL_UNKNOWN;
>  }
>  
>  AVCodecParameters *avcodec_parameters_alloc(void)

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

Re: [FFmpeg-devel] [PATCH 2/2] exif: take a generic log context

[wm4]

On Fri,  1 Apr 2016 13:13:03 +0200
Hendrik Leppkes  wrote:

> The AVCodecContext is only used for logging, so instead take any valid log 
> context.
> This allows reusing the exif functions more easily in avformat.
> ---
>  libavcodec/exif.c | 16 
>  libavcodec/exif.h |  2 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/libavcodec/exif.c b/libavcodec/exif.c
> index fa30f05..07ce174 100644
> --- a/libavcodec/exif.c
> +++ b/libavcodec/exif.c
> @@ -41,14 +41,14 @@ static const char *exif_get_tag_name(uint16_t id)
>  }
>  
>  
> -static int exif_add_metadata(AVCodecContext *avctx, int count, int type,
> +static int exif_add_metadata(void *logctx, int count, int type,
>   const char *name, const char *sep,
>   GetByteContext *gb, int le,
>   AVDictionary **metadata)
>  {
>  switch(type) {
>  case 0:
> -av_log(avctx, AV_LOG_WARNING,
> +av_log(logctx, AV_LOG_WARNING,
> "Invalid TIFF tag type 0 found for %s with size %d\n",
> name, count);
>  return 0;
> @@ -64,13 +64,13 @@ static int exif_add_metadata(AVCodecContext *avctx, int 
> count, int type,
>  case TIFF_SLONG:
>  case TIFF_LONG : return ff_tadd_long_metadata(count, name, sep, gb, 
> le, metadata);
>  default:
> -avpriv_request_sample(avctx, "TIFF tag type (%u)", type);
> +avpriv_request_sample(logctx, "TIFF tag type (%u)", type);
>  return 0;
>  };
>  }
>  
>  
> -static int exif_decode_tag(AVCodecContext *avctx, GetByteContext *gbytes, 
> int le,
> +static int exif_decode_tag(void *logctx, GetByteContext *gbytes, int le,
> int depth, AVDictionary **metadata)
>  {
>  int ret, cur_pos;
> @@ -92,7 +92,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
> GetByteContext *gbytes, int le
>  // store metadata or proceed with next IFD
>  ret = ff_tis_ifd(id);
>  if (ret) {
> -ret = avpriv_exif_decode_ifd(avctx, gbytes, le, depth + 1, metadata);
> +ret = avpriv_exif_decode_ifd(logctx, gbytes, le, depth + 1, 
> metadata);
>  } else {
>  const char *name = exif_get_tag_name(id);
>  char *use_name   = (char*) name;
> @@ -105,7 +105,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
> GetByteContext *gbytes, int le
>  snprintf(use_name, 7, "0x%04X", id);
>  }
>  
> -ret = exif_add_metadata(avctx, count, type, use_name, NULL,
> +ret = exif_add_metadata(logctx, count, type, use_name, NULL,
>  gbytes, le, metadata);
>  
>  if (!name) {
> @@ -119,7 +119,7 @@ static int exif_decode_tag(AVCodecContext *avctx, 
> GetByteContext *gbytes, int le
>  }
>  
>  
> -int avpriv_exif_decode_ifd(AVCodecContext *avctx, GetByteContext *gbytes, 
> int le,
> +int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
> int depth, AVDictionary **metadata)
>  {
>  int i, ret;
> @@ -132,7 +132,7 @@ int avpriv_exif_decode_ifd(AVCodecContext *avctx, 
> GetByteContext *gbytes, int le
>  }
>  
>  for (i = 0; i < entries; i++) {
> -if ((ret = exif_decode_tag(avctx, gbytes, le, depth, metadata)) < 0) 
> {
> +if ((ret = exif_decode_tag(logctx, gbytes, le, depth, metadata)) < 
> 0) {
>  return ret;
>  }
>  }
> diff --git a/libavcodec/exif.h b/libavcodec/exif.h
> index 2f509ba..5f09208 100644
> --- a/libavcodec/exif.h
> +++ b/libavcodec/exif.h
> @@ -164,7 +164,7 @@ static const struct exif_tag tag_list[] = { // JEITA 
> CP-3451 EXIF specification:
>  
>  /** Recursively decodes all IFD's and
>   *  adds included TAGS into the metadata dictionary. */
> -int avpriv_exif_decode_ifd(AVCodecContext *avctx, GetByteContext *gbytes, 
> int le,
> +int avpriv_exif_decode_ifd(void *logctx, GetByteContext *gbytes, int le,
> int depth, AVDictionary **metadata);
>  
>  #endif /* AVCODEC_EXIF_H */

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

Re: [FFmpeg-devel] [PATCH 2/2] exif: take a generic log context

[Thilo Borgmann]

Am 01.04.16 um 13:13 schrieb Hendrik Leppkes:
> The AVCodecContext is only used for logging, so instead take any valid log 
> context.
> This allows reusing the exif functions more easily in avformat.
> ---
>  libavcodec/exif.c | 16 
>  libavcodec/exif.h |  2 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)

ok

-Thilo

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: properly initialize AVCodecParameters profile/level

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 01:13:02PM +0200, Hendrik Leppkes wrote:
> ---
>  libavcodec/utils.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index f991135..df30d57 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -3713,6 +3713,8 @@ static void codec_parameters_reset(AVCodecParameters 
> *par)
>  par->color_space = AVCOL_SPC_UNSPECIFIED;
>  par->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
>  par->sample_aspect_ratio = (AVRational){ 0, 1 };
> +par->profile = FF_PROFILE_UNKNOWN;
> +par->level   = FF_LEVEL_UNKNOWN;
>  }
>  
>  AVCodecParameters *avcodec_parameters_alloc(void)

LGTM

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 02:27:43PM +0530, Disha Singh wrote:
> Somehow I am not getting these warnings when I compile. (not all)
> Should I remove the functions which are defined but not used. They may be
> needed sometime later.
> I have removed the error in line 1888.

theres now an error in line 1898
all errors must be fixed so compilation passes

all warnings about pointer / integer mismatches and pointer types
must be fixed too


> I do not get any error in line 2462. What should I add in my code that the
> compiler you used does not show this error?

you can try gcc and clang but they both should display warnings
about pointer type issues


[...]

> +/** Applies the filter to the current samples, and saves the residual back
> + *  into the samples buffer. If the filter is too bad and overflows the
> + *  maximum amount of bits allowed (24), the samples buffer is left as is and
> + *  the function returns -1.
> + */
> +static int apply_filter(MLPEncodeContext *ctx, unsigned int channel)
> +{
> +FilterParams *fp[NUM_FILTERS] = { 
> &ctx->cur_channel_params[channel].filter_params[FIR],
> +  
> &ctx->cur_channel_params[channel].filter_params[IIR], };
> +int32_t **filter_state_buffer = 
> av_malloc((NUM_FILTERS)*sizeof(int32_t*));
> +int32_t mask = 
> MSB_MASK(ctx->cur_decoding_params->quant_step_size[channel]);
> +int32_t *sample_buffer = ctx->sample_buffer + channel;
> +unsigned int number_of_samples = ctx->number_of_samples;
> +unsigned int filter_shift = fp[FIR]->shift;
> +int filter;
> +int i;
> +
> +for (i = 0; i < NUM_FILTERS; i++) {
> +filter_state_buffer[i] = 
> (av_malloc((ctx->number_of_samples)*sizeof(int32_t));

libavcodec/mlpenc.c: In function ‘apply_filter’:
libavcodec/mlpenc.c:1897:86: error: expected ‘)’ before ‘;’ token
libavcodec/mlpenc.c:1898:5: error: expected ‘;’ before ‘}’ token


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[wm4]

On Wed, 23 Mar 2016 22:15:12 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 23, 2016 at 09:51:46PM +0100, wm4 wrote:
> > On Wed, 23 Mar 2016 21:36:35 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:  
> > > > On Wed, 23 Mar 2016 18:37:25 +0100
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > > > > > On Wed, 23 Mar 2016 17:51:11 +0100
> > > > > > Michael Niedermayer  wrote:
> > > > > >   
> > > > > > > On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:  
> > > > > > > > It's not practical to keep this with the new decode API.
> > > > > > > > ---
> > > > > > > >  ffmpeg.c | 7 ---
> > > > > > > >  ffmpeg.h | 1 -
> > > > > > > >  2 files changed, 8 deletions(-)
> > > > > > > 
> > > > > > > its not practical in ffmpeg.c but libavcodec should be able to 
> > > > > > > easily
> > > > > > > check that a decoder which doesnt declare AV_CODEC_CAP_SUBFRAMES
> > > > > > > doesnt decode "subframes"
> > > > > > > Can you move this check into libavcodec ?
> > > > > > > i think otherwise nothing would be checking for missing
> > > > > > > AV_CODEC_CAP_SUBFRAMES anymore
> > > > > > >   
> > > > > > 
> > > > > > What's the point of this check?  
> > > > > 
> > > > > to keep track of / detect the cases that put multiple decodable frames
> > > > > in a packet.
> > > > > 
> > > > > Whats the point of that?
> > > > > there where several IIRC
> > > > > one is that when too many frames are put in a packet 
> > > > > latency increases, another is that seeking granularity is worse
> > > > > (if its not even one packet for the whole file ...)
> > > > 
> > > > It's true that too many frames in a packet isn't ideal, but that's not
> > > > what the code checks.
> > > > 
> > > > It checks if an audio decoder not marked with AV_CODEC_CAP_SUBFRAMES
> > > > consumes partial packets.
> > > 
> > > yes, but a check that checks "if a decoder not marked with
> > > AV_CODEC_CAP_SUBFRAMES consumes partial packets". Is a simple and
> > > zero overhead way of detecting some (not all) cases where there are
> > > multiple frames in a packet. One cant look at a sequence of bytes
> > > that could be any arbitrary format/codec and say
> > > "thats more than 1 frame" it requires codec specific code,
> > > the decoders already do what is needed for some cases, for the others
> > > there is (please correct me if iam wrong which might be) no easy
> > > way except maybe running the parser if one exists over it but that
> > > would not be zero overhead
> > > 
> > >   
> > > > That might be useful as debug check in
> > > > libavcodec or so, or by properly reviewing patches for new decoders.
> > > 
> > > Iam not sure if i understand what you mean exactly but this somehow
> > > sounds like an implication that people would not review patches
> > > properly.
> > > Thats a serious accusation if thats what was meant. Either there is
> > > a problem then it should be pointed to very specifically so it can be
> > > solved or such implications shouldnt be made at all.  
> > 
> > Well, I'm not sure what else this check is useful for. A new audio
> > decoder will need explicit code to handle multiframe audio by returning
> > the exact number of bytes parsed, instead of e.g.
> > "return avpkt->size;". So it should be pretty obvious whether a decoder
> > does this?  
> 
> yes, though there may be corner cases where it has to do that
> and it might be more robust.
> 
> 
> 
> > 
> > Anyway, I could move this check to avcodec_decode_audio4(), would that
> > be ok?  
> 
> yes and thanks!
> 

So I actually tried this, and it turns out at least shorten (and maybe
many more codecs) raises this warning, because it doesn't set
AV_CODEC_CAP_SUBFRAMES. And nobody ever cared.

Give me a reason why I should, instead of sending a patch to deprecate
AV_CODEC_CAP_SUBFRAMES?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Ronald S. Bultje]

Hi,

On Fri, Apr 1, 2016 at 4:57 AM, Disha Singh 
wrote:

> Somehow I am not getting these warnings when I compile. (not all)


OK, so we should stop here and fix this. Why is the encoder not being
compiled for you? This back-and-forth on compiler warnings/errors is
ridiculous. Please figure out how to compile this code (ask on IRC if
you're not sure) and let's not use the mailinglist as a distributed
compiler.

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

Re: [FFmpeg-devel] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part

[Matthieu Bouron]

On Mon, Mar 28, 2016 at 9:12 PM, Matthieu Bouron 
wrote:

>
>
> On Sun, Mar 27, 2016 at 5:58 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 25, 2016 at 11:45 PM, Matthieu Bouron <
>> matthieu.bou...@gmail.com> wrote:
>>
>>> The following patchset aims to make bitexact the yuv->rgba armv7 neon
>>> code path
>>> with the aarch64 one. It also aims to make the two code bases as close as
>>> possible.
>>>
>>> [PATCH 01/10] swscale/arm/yuv2rgb: remove 32bit code path
>>>
>>> The current 32bit code path which is unused is removed.
>>>
>>> [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time
>>>
>>> The code process only one line at a time for the yuv420p,nv12 and nv21
>>> formats
>>> with no regression in performance observed on a rpi2 (I've even observed
>>> a
>>> slight increase of performance for the nv12 and nv21 formats).
>>>
>>> [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its
>>>
>>> The last patch of the serie makes the code bitexact with the aarch64
>>> version.
>>> The increase of precision (which introduces a performance loss) is
>>> compensated
>>> by a refactor/optimisation that saves quite a few mov,vdup and vqdmulh.
>>>
>>> ./ffmpeg_g -nostats -f lavfi -i
>>> testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f
>>> null -
>>>
>>> without patchset :
>>> [bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399 min:0.020605
>>>
>>> with patchset:
>>> [bench @ 0xe5f6a0] t:0.018924 avg:0.019075 max:0.037472 min:0.01884
>>
>>
>> I've managed tu run the code on a beagle bone black board, here are the
>> results:
>>
>> nv12->bgra
>> without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743
>> max:0.032600 min:0.011513
>> with patches 01-06/10 applied: [bench @ 0x8052d0] t:0.013438 avg:0.013659
>> max:0.034427 min:0.013411
>> with patches 01-10/10 applied: [bench @ 0x1fbb2d0] t:0.012554
>> avg:0.012751 max:0.034288 min:0.012523
>>
>> yuv420p->bgra
>> without patchset: [bench @ 0x6d42d0] t:0.012954 avg:0.013159 max:0.033866
>> min:0.012945
>> with patches 01-06/10 applied: [bench @ 0x20172d0] t:0.015154
>> avg:0.015358 max:0.036186 min:0.015134
>> with patches 01-10/10 applied: [bench @ 0x1d162d0] t:0.014623
>> avg:0.014784 max:0.035487 min:0.014568
>>
>> So it looks like processing one line at a time as negative effect on
>> performance on this board (as opposed to the rpi2). I'll try to keep the
>> two line processing code and post some result (so we can decide, which
>> version to choose).
>>
>
> I've managed to update the patchset to keep processing two line at a time
> for the nv12,nv21 and yuv420p formats, here are the results:
>
> ./ffmpeg_g -nostats -f lavfi -i
> testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f
> null -
>
> Beagle bone black:
> without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743 max:0.032600
> min:0.011513
> with patchset v1: [bench @ 0x1fbb2d0] t:0.012554 avg:0.012751 max:0.034288
> min:0.012523
> with patchset v2: [bench @ 0x10f92d0] t:0.011239 avg:0.011408 max:0.032124
> min:0.011202
>
> Nexus5:
> without patchset: avg: ~2,869ms
> with patchset v1: avg: ~3,008ms
> with patchset v2: avg: ~2,702ms
>
> RPI2:
> without patchset: [bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399
> min:0.020605
> with patchset v1:  [bench @ 0xe5f6a0] t:0.018924 avg:0.019075
> max:0.037472 min:0.01884
> with patchset v2: [bench @ 0xc1b6a0] t:0.020999 avg:0.021203 max:0.052184
> min:0.020768
>
> Given the following the results, i will drop the current patchset and
> submit another one (which keeps processing two lines at a time).
>

I will push the updated patchset (which takes into account Benoit's
comments) in one hour~.

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

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[Paul B Mahol]

Dana 1. 4. 2016. 15:43 osoba "wm4"  napisala je:
>
> On Wed, 23 Mar 2016 22:15:12 +0100
> Michael Niedermayer  wrote:
>
> > On Wed, Mar 23, 2016 at 09:51:46PM +0100, wm4 wrote:
> > > On Wed, 23 Mar 2016 21:36:35 +0100
> > > Michael Niedermayer  wrote:
> > >
> > > > On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:
> > > > > On Wed, 23 Mar 2016 18:37:25 +0100
> > > > > Michael Niedermayer  wrote:
> > > > >
> > > > > > On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > > > > > > On Wed, 23 Mar 2016 17:51:11 +0100
> > > > > > > Michael Niedermayer  wrote:
> > > > > > >
> > > > > > > > On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:
> > > > > > > > > It's not practical to keep this with the new decode API.
> > > > > > > > > ---
> > > > > > > > >  ffmpeg.c | 7 ---
> > > > > > > > >  ffmpeg.h | 1 -
> > > > > > > > >  2 files changed, 8 deletions(-)
> > > > > > > >
> > > > > > > > its not practical in ffmpeg.c but libavcodec should be able
to easily
> > > > > > > > check that a decoder which doesnt declare
AV_CODEC_CAP_SUBFRAMES
> > > > > > > > doesnt decode "subframes"
> > > > > > > > Can you move this check into libavcodec ?
> > > > > > > > i think otherwise nothing would be checking for missing
> > > > > > > > AV_CODEC_CAP_SUBFRAMES anymore
> > > > > > > >
> > > > > > >
> > > > > > > What's the point of this check?
> > > > > >
> > > > > > to keep track of / detect the cases that put multiple decodable
frames
> > > > > > in a packet.
> > > > > >
> > > > > > Whats the point of that?
> > > > > > there where several IIRC
> > > > > > one is that when too many frames are put in a packet
> > > > > > latency increases, another is that seeking granularity is worse
> > > > > > (if its not even one packet for the whole file ...)
> > > > >
> > > > > It's true that too many frames in a packet isn't ideal, but
that's not
> > > > > what the code checks.
> > > > >
> > > > > It checks if an audio decoder not marked with
AV_CODEC_CAP_SUBFRAMES
> > > > > consumes partial packets.
> > > >
> > > > yes, but a check that checks "if a decoder not marked with
> > > > AV_CODEC_CAP_SUBFRAMES consumes partial packets". Is a simple and
> > > > zero overhead way of detecting some (not all) cases where there are
> > > > multiple frames in a packet. One cant look at a sequence of bytes
> > > > that could be any arbitrary format/codec and say
> > > > "thats more than 1 frame" it requires codec specific code,
> > > > the decoders already do what is needed for some cases, for the
others
> > > > there is (please correct me if iam wrong which might be) no easy
> > > > way except maybe running the parser if one exists over it but that
> > > > would not be zero overhead
> > > >
> > > >
> > > > > That might be useful as debug check in
> > > > > libavcodec or so, or by properly reviewing patches for new
decoders.
> > > >
> > > > Iam not sure if i understand what you mean exactly but this somehow
> > > > sounds like an implication that people would not review patches
> > > > properly.
> > > > Thats a serious accusation if thats what was meant. Either there is
> > > > a problem then it should be pointed to very specifically so it can
be
> > > > solved or such implications shouldnt be made at all.
> > >
> > > Well, I'm not sure what else this check is useful for. A new audio
> > > decoder will need explicit code to handle multiframe audio by
returning
> > > the exact number of bytes parsed, instead of e.g.
> > > "return avpkt->size;". So it should be pretty obvious whether a
decoder
> > > does this?
> >
> > yes, though there may be corner cases where it has to do that
> > and it might be more robust.
> >
> >
> >
> > >
> > > Anyway, I could move this check to avcodec_decode_audio4(), would that
> > > be ok?
> >
> > yes and thanks!
> >
>
> So I actually tried this, and it turns out at least shorten (and maybe
> many more codecs) raises this warning, because it doesn't set
> AV_CODEC_CAP_SUBFRAMES. And nobody ever cared.
>
> Give me a reason why I should, instead of sending a patch to deprecate
> AV_CODEC_CAP_SUBFRAMES?

It should set it because it is not sane format.

> ___
> 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 v2 4/8] ffmpeg: remove sub-frame warning

[wm4]

On Fri, 1 Apr 2016 16:44:42 +0200
Paul B Mahol  wrote:

> It should set it because it is not sane format.

I mean, why do we want to keep this message, if it obviously didn't
help with anything?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 04:53:55PM +0200, wm4 wrote:
> On Fri, 1 Apr 2016 16:44:42 +0200
> Paul B Mahol  wrote:
> 
> > It should set it because it is not sane format.
> 
> I mean, why do we want to keep this message, if it obviously didn't
> help with anything?

it is useful for debuging and to prevent invalid files from being
created


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

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


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

Re: [FFmpeg-devel] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part

[Matthieu Bouron]

On Fri, Apr 1, 2016 at 4:15 PM, Matthieu Bouron 
wrote:

>
>
> On Mon, Mar 28, 2016 at 9:12 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com> wrote:
>
>>
>>
>> On Sun, Mar 27, 2016 at 5:58 PM, Matthieu Bouron <
>> matthieu.bou...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 25, 2016 at 11:45 PM, Matthieu Bouron <
>>> matthieu.bou...@gmail.com> wrote:
>>>
 The following patchset aims to make bitexact the yuv->rgba armv7 neon
 code path
 with the aarch64 one. It also aims to make the two code bases as close
 as
 possible.

 [PATCH 01/10] swscale/arm/yuv2rgb: remove 32bit code path

 The current 32bit code path which is unused is removed.

 [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time

 The code process only one line at a time for the yuv420p,nv12 and nv21
 formats
 with no regression in performance observed on a rpi2 (I've even
 observed a
 slight increase of performance for the nv12 and nv21 formats).

 [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its

 The last patch of the serie makes the code bitexact with the aarch64
 version.
 The increase of precision (which introduces a performance loss) is
 compensated
 by a refactor/optimisation that saves quite a few mov,vdup and vqdmulh.

 ./ffmpeg_g -nostats -f lavfi -i
 testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f
 null -

 without patchset :
 [bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399 min:0.020605

 with patchset:
 [bench @ 0xe5f6a0] t:0.018924 avg:0.019075 max:0.037472 min:0.01884
>>>
>>>
>>> I've managed tu run the code on a beagle bone black board, here are the
>>> results:
>>>
>>> nv12->bgra
>>> without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743
>>> max:0.032600 min:0.011513
>>> with patches 01-06/10 applied: [bench @ 0x8052d0] t:0.013438
>>> avg:0.013659 max:0.034427 min:0.013411
>>> with patches 01-10/10 applied: [bench @ 0x1fbb2d0] t:0.012554
>>> avg:0.012751 max:0.034288 min:0.012523
>>>
>>> yuv420p->bgra
>>> without patchset: [bench @ 0x6d42d0] t:0.012954 avg:0.013159
>>> max:0.033866 min:0.012945
>>> with patches 01-06/10 applied: [bench @ 0x20172d0] t:0.015154
>>> avg:0.015358 max:0.036186 min:0.015134
>>> with patches 01-10/10 applied: [bench @ 0x1d162d0] t:0.014623
>>> avg:0.014784 max:0.035487 min:0.014568
>>>
>>> So it looks like processing one line at a time as negative effect on
>>> performance on this board (as opposed to the rpi2). I'll try to keep the
>>> two line processing code and post some result (so we can decide, which
>>> version to choose).
>>>
>>
>> I've managed to update the patchset to keep processing two line at a time
>> for the nv12,nv21 and yuv420p formats, here are the results:
>>
>> ./ffmpeg_g -nostats -f lavfi -i
>> testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f
>> null -
>>
>> Beagle bone black:
>> without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743
>> max:0.032600 min:0.011513
>> with patchset v1: [bench @ 0x1fbb2d0] t:0.012554 avg:0.012751
>> max:0.034288 min:0.012523
>> with patchset v2: [bench @ 0x10f92d0] t:0.011239 avg:0.011408
>> max:0.032124 min:0.011202
>>
>> Nexus5:
>> without patchset: avg: ~2,869ms
>> with patchset v1: avg: ~3,008ms
>> with patchset v2: avg: ~2,702ms
>>
>> RPI2:
>> without patchset: [bench @ 0x3eb6a0] t:0.020660 avg:0.020813
>> max:0.039399 min:0.020605
>> with patchset v1:  [bench @ 0xe5f6a0] t:0.018924 avg:0.019075
>> max:0.037472 min:0.01884
>> with patchset v2: [bench @ 0xc1b6a0] t:0.020999 avg:0.021203 max:0.052184
>> min:0.020768
>>
>> Given the following the results, i will drop the current patchset and
>> submit another one (which keeps processing two lines at a time).
>>
>
> I will push the updated patchset (which takes into account Benoit's
> comments) in one hour~.
>

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

Re: [FFmpeg-devel] [PATCH] add attribution to OpenJPEG code in FFmpeg encoder j2kenc.c file

[Michael Niedermayer]

On Thu, Mar 31, 2016 at 04:06:01PM -0400, Aaron Boxer wrote:
> Hi Folks,
> 
> Here is a patch to reference the OpenJPEG license from j2kenc.c,
> as per earlier discussion.
> 
> Cheers,
> Aaron

>  j2kenc.c |   38 ++
>  1 file changed, 38 insertions(+)
> 67a21d362e28fb05b083d128ddd615dc89ff6929  
> 0001-Add-attribution-to-OpenJPEG-project.patch
> From 145ca23d181598200afe52870024b995b8a589ad Mon Sep 17 00:00:00 2001
> From: Aaron Boxer 
> Date: Thu, 31 Mar 2016 16:02:14 -0400
> Subject: [PATCH] Add attribution to OpenJPEG project:

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 05:27:11PM +0200, Michael Niedermayer wrote:
> On Fri, Apr 01, 2016 at 04:53:55PM +0200, wm4 wrote:
> > On Fri, 1 Apr 2016 16:44:42 +0200
> > Paul B Mahol  wrote:
> > 
> > > It should set it because it is not sane format.
> > 
> > I mean, why do we want to keep this message, if it obviously didn't
> > help with anything?
> 
> it is useful for debuging and to prevent invalid files from being
> created

to elaborate on this
If a demuxer returns an AVPacket with multiple frames in it and that
gets stored in a output file then the output file is invalid with
no indication that it is. Such file would likely play fine on some
players and fail on others. Thats a really serious problem for the
user as even if he tests the output file by playing it he possibly
wont notice a problem

With the multiple subframes message decoding both the original file
with the buggy demuxer as well as playing the newly created output
file would likely show warnings that would point at the problem
(which might be a forgotten needs_parsing in the demuxer)

I belive its important to keep some means to detect this kind of
problem. Also as it is easy to set the parsing stuff up wrongly
a reverse engeneered container might appear to store 1 mp3 frame per
packet but that might then turn out false on analysis of a wider
range of files ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH v2 7/8] lavf: use new decode API

[Michael Niedermayer]

On Wed, Mar 23, 2016 at 02:02:14PM +0100, wm4 wrote:
> ---
>  libavformat/utils.c | 29 -
>  1 file changed, 12 insertions(+), 17 deletions(-)

btw, ill test 7 & 8 when 1-6 are working/updated. Or should i try to
test these already ?

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH 1/2] swscale: fix bt709 yuv2rgb coefficients.

[Michael Niedermayer]

On Thu, Mar 31, 2016 at 04:01:16PM -0400, Ronald S. Bultje wrote:
> They were derived from incorrect values cr=0.2125 (should be cr=0.2126)
> and cb=0.0721 (should be cb=0.0722).
> ---
>  libswscale/yuv2rgb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
> index 62abb7d..a0242bf 100644
> --- a/libswscale/yuv2rgb.c
> +++ b/libswscale/yuv2rgb.c
> @@ -47,8 +47,8 @@
>   * where Y = cr * R + cg * G + cb * B and cr + cg + cb = 1.
>   */
>  const int32_t ff_yuv2rgb_coeffs[8][4] = {
> -{ 117504, 138453, 13954, 34903 }, /* no sequence_display_extension */
> -{ 117504, 138453, 13954, 34903 }, /* ITU-R Rec. 709 (1990) */
> +{ 117489, 138438, 13975, 34925 }, /* no sequence_display_extension */
> +{ 117489, 138438, 13975, 34925 }, /* ITU-R Rec. 709 (1990) */

it seems nothing in fate is using these
but if you checked the values and theye where wrong then this should
be ok

I do remember though that i was finetuning some SIMD yuv-rgb values
by +-1 to maximize PSNR for combinations of rgb-yuv and yuv-rgb
so keep that in mind if you find errors in them too :)



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

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


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

Re: [FFmpeg-devel] [PATCH v2 7/8] lavf: use new decode API

[wm4]

On Fri, 1 Apr 2016 18:18:17 +0200
Michael Niedermayer  wrote:

> On Wed, Mar 23, 2016 at 02:02:14PM +0100, wm4 wrote:
> > ---
> >  libavformat/utils.c | 29 -
> >  1 file changed, 12 insertions(+), 17 deletions(-)  
> 
> btw, ill test 7 & 8 when 1-6 are working/updated. Or should i try to
> test these already ?
> 
> [...]

5/8 still has the unsolved problem with how ffmpeg.c tries to set DTS
on flush packets (and multithreading). The rest should be orthogonal.

These patches also miss the deprecation of the "old" APIs, which was
done in Libav, and APIchanges updates.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[wm4]

On Fri, 1 Apr 2016 17:47:45 +0200
Michael Niedermayer  wrote:

> On Fri, Apr 01, 2016 at 05:27:11PM +0200, Michael Niedermayer wrote:
> > On Fri, Apr 01, 2016 at 04:53:55PM +0200, wm4 wrote:  
> > > On Fri, 1 Apr 2016 16:44:42 +0200
> > > Paul B Mahol  wrote:
> > >   
> > > > It should set it because it is not sane format.  
> > > 
> > > I mean, why do we want to keep this message, if it obviously didn't
> > > help with anything?  
> > 
> > it is useful for debuging and to prevent invalid files from being
> > created  
> 
> to elaborate on this
> If a demuxer returns an AVPacket with multiple frames in it and that
> gets stored in a output file then the output file is invalid with
> no indication that it is. Such file would likely play fine on some
> players and fail on others. Thats a really serious problem for the
> user as even if he tests the output file by playing it he possibly
> wont notice a problem
> 
> With the multiple subframes message decoding both the original file
> with the buggy demuxer as well as playing the newly created output
> file would likely show warnings that would point at the problem
> (which might be a forgotten needs_parsing in the demuxer)
> 
> I belive its important to keep some means to detect this kind of
> problem. Also as it is easy to set the parsing stuff up wrongly
> a reverse engeneered container might appear to store 1 mp3 frame per
> packet but that might then turn out false on analysis of a wider
> range of files ...
> 
> [...]
> 

Anyway, the attached patch probably works. I didn't bother with
silencing subsequent warnings. Spams log messages when playing shorten.
>From 784c19cfae60be3ef0cab78bf0b0333d36ec4c32 Mon Sep 17 00:00:00 2001
From: wm4 
Date: Fri, 1 Apr 2016 14:08:17 +0200
Subject: ffmpeg: move subframe warning to libavcodec

With the new decode API, doing this in ffmpeg.c is impractical. There
was resistance against removing the warning, so put it into libavcodec.

Not bothering with reducing the warning to verbose log level for
subsequent wanrings. The warning should be rare, and only happen when
developing new codecs for the old API.

diff --git a/ffmpeg.c b/ffmpeg.c
index 9a14294..bdb0e5e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2316,13 +2316,6 @@ static int process_input_packet(InputStream *ist, const AVPacket *pkt, int no_eo
 ist->pts = ist->next_pts;
 ist->dts = ist->next_dts;
 
-if (avpkt.size && avpkt.size != pkt->size &&
-!(ist->dec->capabilities & AV_CODEC_CAP_SUBFRAMES)) {
-av_log(NULL, ist->showed_multi_packet_warning ? AV_LOG_VERBOSE : AV_LOG_WARNING,
-   "Multiple frames in a packet from stream %d\n", pkt->stream_index);
-ist->showed_multi_packet_warning = 1;
-}
-
 switch (ist->dec_ctx->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
 ret = decode_audio(ist, &avpkt, &got_output);
diff --git a/ffmpeg.h b/ffmpeg.h
index 403b098..377822c 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -283,7 +283,6 @@ typedef struct InputStream {
 
 double ts_scale;
 int saw_first_ts;
-int showed_multi_packet_warning;
 AVDictionary *decoder_opts;
 AVRational framerate;   /* framerate forced with -r */
 int top_field_first;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 27c1123..937148a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2416,6 +2416,9 @@ fail:
 av_frame_unref(frame);
 }
 
+if (ret >= 0 && ret != avpkt->size && !(avctx->codec->capabilities & AV_CODEC_CAP_SUBFRAMES))
+av_log(avctx, AV_LOG_WARNING, "Multiple frames in a packet.\n");
+
 return ret;
 }
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] According to SMPTE 370M (rev.2002), page 15 : "FS: First/second field flag",

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

quoting:
FS indicates a field which is delivered during the field one period 
(see table 16)

now quoting table 16:

FF  FS   Output field
---
1   1Field 1 and field 2 are output in this order (1,2 sequence).
---
1   0Field 2 and field 1 are output in this order (2,1 sequence).
---
0   1Field 1 is output twice.
---
0   0Field 2 is output twice.

this actually means, that:

AVFrame->top_field_first = FS .

But in today's FFmpeg's dv encoding and decoding realisation it's inverted:

AVFrame->top_field_first = !FS .

I tried to ask question about it by sending an email "DV frame field order" to 
ffmpeg-devel@ffmpeg.org ,
but got no answer, and actually even didn't got this email from the mailing 
list (no idea is it normal).

I've found this case from practice, where DVCProHD coded video (by Matrox 
device) with image, recorded as "top_field_first"
got AVFrame->top_field_first == 0 (with interlaced_frame == 1 ofcource).

I'm not really sure of this commit's correctness, because DV SD stream is 
decoded as AVFrame->top_field_first == 0 , and people say
this is right. Checked it with gdb while decoding 
http://samples.ffmpeg.org/V-codecs/DVSD/pond.dv
---
 libavcodec/dvdec.c | 2 +-
 libavcodec/dvenc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 0b4c1bc..23757fc 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -546,7 +546,7 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, void 
*data,
 
 /* Determine the codec's field order from the packet */
 if ( *vsc_pack == dv_video_control ) {
-frame->top_field_first = !(vsc_pack[3] & 0x40);
+frame->top_field_first = vsc_pack[3] & 0x40;
 }
 
 s->buf = buf;
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index 5de12cc..9b5938f 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -574,7 +574,7 @@ static inline int dv_write_pack(enum dv_pack_type pack_id, 
DVVideoContext *c,
  *  compression scheme (if any).
  */
 int apt = (c->sys->pix_fmt == AV_PIX_FMT_YUV420P ? 0 : 1);
-int fs  = c->frame->top_field_first ? 0x00 : 0x40;
+int fs  = c->frame->top_field_first ? 0x40 : 0x00;
 
 uint8_t aspect = 0;
 if ((int) (av_q2d(c->avctx->sample_aspect_ratio) *
-- 
2.7.1.windows.1


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

Re: [FFmpeg-devel] [PATCH] fate: Test for Ticket4560

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 01:02:56AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/filter-video.mak |9 ++
>  tests/ref/fate/filter-meta-4560-rotate0 |  259 
> +++
>  2 files changed, 268 insertions(+)
>  create mode 100644 tests/ref/fate/filter-meta-4560-rotate0

applied

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] fate: Add regression test for Ticket 1239

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 12:34:04AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/real.mak  |3 ++
>  tests/ref/fate/rv20-1239 |   91 
> ++
>  2 files changed, 94 insertions(+)
>  create mode 100644 tests/ref/fate/rv20-1239

applied

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

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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

Re: [FFmpeg-devel] [PATCH] fate: add demux test for TS with AC3 (Ticket 4864)

[Michael Niedermayer]

On Wed, Mar 30, 2016 at 09:41:10PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/demux.mak|3 +++
>  tests/ref/fate/ts-demux |   23 +++
>  2 files changed, 26 insertions(+)
>  create mode 100644 tests/ref/fate/ts-demux

applied

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH v2 7/8] lavf: use new decode API

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 06:51:39PM +0200, wm4 wrote:
> On Fri, 1 Apr 2016 18:18:17 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 23, 2016 at 02:02:14PM +0100, wm4 wrote:
> > > ---
> > >  libavformat/utils.c | 29 -
> > >  1 file changed, 12 insertions(+), 17 deletions(-)  
> > 
> > btw, ill test 7 & 8 when 1-6 are working/updated. Or should i try to
> > test these already ?
> > 
> > [...]
> 
> 5/8 still has the unsolved problem with how ffmpeg.c tries to set DTS
> on flush packets (and multithreading). The rest should be orthogonal.

ok, testing this without 5&6, there are alot of files that get stuck
exmaple:
./ffmpeg -i tickets/574/Issue200Regression.latm

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 06:52:53PM +0200, wm4 wrote:
> On Fri, 1 Apr 2016 17:47:45 +0200
> Michael Niedermayer  wrote:
> 
> > On Fri, Apr 01, 2016 at 05:27:11PM +0200, Michael Niedermayer wrote:
> > > On Fri, Apr 01, 2016 at 04:53:55PM +0200, wm4 wrote:  
> > > > On Fri, 1 Apr 2016 16:44:42 +0200
> > > > Paul B Mahol  wrote:
> > > >   
> > > > > It should set it because it is not sane format.  
> > > > 
> > > > I mean, why do we want to keep this message, if it obviously didn't
> > > > help with anything?  
> > > 
> > > it is useful for debuging and to prevent invalid files from being
> > > created  
> > 
> > to elaborate on this
> > If a demuxer returns an AVPacket with multiple frames in it and that
> > gets stored in a output file then the output file is invalid with
> > no indication that it is. Such file would likely play fine on some
> > players and fail on others. Thats a really serious problem for the
> > user as even if he tests the output file by playing it he possibly
> > wont notice a problem
> > 
> > With the multiple subframes message decoding both the original file
> > with the buggy demuxer as well as playing the newly created output
> > file would likely show warnings that would point at the problem
> > (which might be a forgotten needs_parsing in the demuxer)
> > 
> > I belive its important to keep some means to detect this kind of
> > problem. Also as it is easy to set the parsing stuff up wrongly
> > a reverse engeneered container might appear to store 1 mp3 frame per
> > packet but that might then turn out false on analysis of a wider
> > range of files ...
> > 
> > [...]
> > 
> 
> Anyway, the attached patch probably works. I didn't bother with
> silencing subsequent warnings. Spams log messages when playing shorten.

please add the diff below (LGTM with it)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index ac17196..8491647 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -173,6 +173,7 @@ typedef struct AVCodecInternal {
 int buffer_pkt_valid; // encoding: packet without data can be valid
 AVFrame *buffer_frame;
 int draining_done;
+int showed_multi_packet_warning;
 } AVCodecInternal;

 struct AVCodecDefault {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e5033d5..f97921d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2416,8 +2416,11 @@ fail:
 av_frame_unref(frame);
 }

-if (ret >= 0 && ret != avpkt->size && !(avctx->codec->capabilities & 
AV_CODEC_CAP_SUBFRAMES))
+if (!avci->showed_multi_packet_warning &&
+ret >= 0 && ret != avpkt->size && !(avctx->codec->capabilities & 
AV_CODEC_CAP_SUBFRAMES)) {
 av_log(avctx, AV_LOG_WARNING, "Multiple frames in a packet.\n");
+avci->showed_multi_packet_warning = 1;
+}

 return ret;
 }

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH] lavfi: new colorspace conversion filter.

[Michael Niedermayer]

On Thu, Mar 31, 2016 at 08:29:37PM -0400, Ronald S. Bultje wrote:
> The intent here is similar to colormatrix, but it's LGPLv2.1-or-later
> (instead of GPLv2.0) and supports gamma/chromaticity correction.
> ---
>  doc/filters.texi | 183 +++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/colorspacedsp.c  | 130 +
>  libavfilter/colorspacedsp.h  |  51 ++
>  libavfilter/colorspacedsp_template.c | 256 ++
>  libavfilter/vf_colorspace.c  | 909 
> +++
>  7 files changed, 1531 insertions(+)
>  create mode 100644 libavfilter/colorspacedsp.c
>  create mode 100644 libavfilter/colorspacedsp.h
>  create mode 100644 libavfilter/colorspacedsp_template.c
>  create mode 100644 libavfilter/vf_colorspace.c
[...]

> +#define supported_depth(d) (d == 8 || d == 10 || d == 12)
> +#define supported_subsampling(lcw, lch) \
> +((lcw == 0 && lch == 0) || (lcw == 1 && lch == 0) || (lcw == 1 && lch == 
> 1))
> +#define supported_format(d) \
> +(d != NULL && d->nb_components == 3 && \
> + !(d->flags & AV_PIX_FMT_FLAG_RGB) && \
> + supported_depth(d->comp[0].depth) && \
> + supported_subsampling(d->log2_chroma_w, d->log2_chroma_h))

the macro arguments should be protected by ()
its maybe unlikely with the private macros to hit issues but these
kind of issues can be fun to debug
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix crash when closing codec after error

[Richard Kern]

> On Mar 24, 2016, at 12:46 PM, Richard Kern  wrote:
> 
>> 
>> On Mar 25, 2016, at 12:37 AM, wm4  wrote:
>> 
>> On Mon, 21 Mar 2016 00:55:56 +0800
>> Rick Kern  wrote:
>> 
>>> Fixes crash in #5352. VTCompressionSessionInvalidate() crashes if the 
>>> internal encoder hasn't completed, but hasn't experienced an error. The 
>>> function call isn't needed since the encoder is invalidated when the 
>>> reference count reaches 0 anyway.
>>> 
>>> Signed-off-by: Rick Kern 
>>> ---
>>> libavcodec/videotoolboxenc.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>> 
>>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>>> index 3ed1f64..0791146 100644
>>> --- a/libavcodec/videotoolboxenc.c
>>> +++ b/libavcodec/videotoolboxenc.c
>>> @@ -1275,7 +1275,6 @@ static av_cold int vtenc_close(AVCodecContext *avctx)
>>> 
>>>if(!vtctx->session) return 0;
>>> 
>>> -VTCompressionSessionInvalidate(vtctx->session);
>>>pthread_cond_destroy(&vtctx->cv_sample_sent);
>>>pthread_mutex_destroy(&vtctx->lock);
>>>CFRelease(vtctx->session);
>> 
>> Seems fine. So if we don't need it, what is
>> VTCompressionSessionInvalidate intended for in general?
> It could be used to tear down the encoder without the session being 
> deallocated.
Can this be pushed?

> 
>> ___
>> 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 v2] lavc/videotoolboxenc: Workaround encoder error

[Richard Kern]

> On Mar 24, 2016, at 1:56 PM, Rick Kern  wrote:
> 
> CMVideoFormatDescriptionGetH264ParameterSetAtIndex() fails on some 
> hardware/OS versions when retrieving the parameter set count alone.
> 
> Signed-off-by: Rick Kern 
> ---
> libavcodec/videotoolboxenc.c | 43 ---
> 1 file changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 0791146..3177074 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -194,6 +194,7 @@ static int get_params_size(
> {
> size_t total_size = 0;
> size_t ps_count;
> +int is_count_bad = 0;
> size_t i;
> int status;
> status = CMVideoFormatDescriptionGetH264ParameterSetAtIndex(vid_fmt,
> @@ -203,11 +204,12 @@ static int get_params_size(
> &ps_count,
> NULL);
> if (status) {
> -av_log(avctx, AV_LOG_ERROR, "Error getting parameter set count: 
> %d\n", status);
> -return AVERROR_EXTERNAL;
> +is_count_bad = 1;
> +ps_count = 0;
> +status   = 0;
> }
> 
> -for(i = 0; i < ps_count; i++){
> +for (i = 0; i < ps_count || is_count_bad; i++) {
> const uint8_t *ps;
> size_t ps_size;
> status = CMVideoFormatDescriptionGetH264ParameterSetAtIndex(vid_fmt,
> @@ -216,14 +218,24 @@ static int get_params_size(
> &ps_size,
> NULL,
> NULL);
> -if(status){
> -av_log(avctx, AV_LOG_ERROR, "Error getting parameter set size 
> for index %zd: %d\n", i, status);
> -return AVERROR_EXTERNAL;
> +if (status) {
> +/*
> + * When ps_count is invalid, status != 0 ends the loop normally
> + * unless we didn't get any parameter sets.
> + */
> +if (i > 0 && is_count_bad) status = 0;
> +
> +break;
> }
> 
> total_size += ps_size + sizeof(start_code);
> }
> 
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error getting parameter set sizes: 
> %d\n", status);
> +return AVERROR_EXTERNAL;
> +}
> +
> *size = total_size;
> return 0;
> }
> @@ -235,6 +247,7 @@ static int copy_param_sets(
> size_t  dst_size)
> {
> size_t ps_count;
> +int is_count_bad = 0;
> int status;
> size_t offset = 0;
> size_t i;
> @@ -246,11 +259,13 @@ static int copy_param_sets(
> &ps_count,
> NULL);
> if (status) {
> -av_log(avctx, AV_LOG_ERROR, "Error getting parameter set count for 
> copying: %d\n", status);
> -return AVERROR_EXTERNAL;
> +is_count_bad = 1;
> +ps_count = 0;
> +status   = 0;
> }
> 
> -for (i = 0; i < ps_count; i++) {
> +
> +for (i = 0; i < ps_count || is_count_bad; i++) {
> const uint8_t *ps;
> size_t ps_size;
> size_t next_offset;
> @@ -262,8 +277,9 @@ static int copy_param_sets(
> NULL,
> NULL);
> if (status) {
> -av_log(avctx, AV_LOG_ERROR, "Error getting parameter set data 
> for index %zd: %d\n", i, status);
> -return AVERROR_EXTERNAL;
> +if (i > 0 && is_count_bad) status = 0;
> +
> +break;
> }
> 
> next_offset = offset + sizeof(start_code) + ps_size;
> @@ -279,6 +295,11 @@ static int copy_param_sets(
> offset = next_offset;
> }
> 
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error getting parameter set data: 
> %d\n", status);
> +return AVERROR_EXTERNAL;
> +}
> +
> return 0;
> }
> 
> -- 
> 2.7.4
> 
Ping - does anyone else want to review? The logic is clearer and the commit 
message is better.

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

Re: [FFmpeg-devel] codecpar regressions

[Michael Niedermayer]

On Fri, Apr 01, 2016 at 01:53:45AM +0200, Michael Niedermayer wrote:
> Hi
> 
> from #ffmpeg-devel
>  im not doing any fixes today though, im beat.
> ...
>  michaelni, if im not around mail me them, or putthem on github or 
> something
> 
> i found another regression, thought "here" is a good "something"
> that way more people can search for and fix regressions
> 
> heres one regression:
> ./ffmpeg -i Broadway-5.1-48khz-448kbit.ac3 -t 10 out.wav
> ./ffmpeg-codecpar-2016-0331-23 -i Broadway-5.1-48khz-448kbit.ac3 -t 10 
> out-codecpar.wav
> 
>  ls -alF out-codecpar.wav out.wav
> -rw-r- 1 michael michael 6681702 Apr  1 01:38 out-codecpar.wav
> -rw-r- 1 michael michael 5760102 Apr  1 01:38 out.wav
> 
> the codecpar case also fills the screen with
> Non-monotonous DTS in output stream 0:0; previous: 75264, current: 66048; 
> changing to 75264. This may result in incorrect timestamps in the output file
> warnings
> 
> not yet rebased onto origin tree used for the testing:
> https://github.com/dwbuiten/FFmpeg/tree/codecpar
> 
> PS: i suggest to wait at least 48h with no new regressions being found
> before this is pushed, its a exceptionally large merge

another regression:
./ffmpeg -i ~/tickets/2397/242_4.mkv -filter_complex '[0:v][0:s:1]overlay' 
out.avi

  Duration: 00:00:08.07, start: 0.067000, bitrate: 2535 kb/s
Stream #0:0: Video: h264 (High), yuv420p, 720x480, SAR 1:1 DAR 3:2, 29.97 
fps, 29.97 tbr, 1k tbn (default)
Stream #0:1: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s 
(default)
Stream #0:2(fre): Subtitle: dvd_subtitle, 720x480 (default)
Stream #0:3(chi): Subtitle: dvd_subtitle, 720x480
Stream #0:4(chi): Subtitle: dvd_subtitle, 720x480
==22373== Invalid read of size 8
==22373==at 0x6E8BA4: avformat_match_stream_specifier (utils.c:4551)
==22373==by 0x41856B: check_stream_specifier (cmdutils.c:1964)
==22373==by 0x426648: init_input_filter (ffmpeg_filter.c:259)
==22373==by 0x4269AB: init_complex_filtergraph (ffmpeg_filter.c:317)
==22373==by 0x421170: init_complex_filters (ffmpeg_opt.c:1881)
==22373==by 0x4257DE: ffmpeg_parse_options (ffmpeg_opt.c:3047)
==22373==by 0x43AC01: main (ffmpeg.c:4309)
==22373==  Address 0x10b46848 is 0 bytes after a block of size 40 alloc'd
==22373==at 0x4C2C861: realloc (vg_replace_malloc.c:662)
==22373==by 0xFC3D98: av_realloc (mem.c:168)
==22373==by 0xFC3EE6: av_realloc_array (mem.c:212)
==22373==by 0x6E72A0: avformat_new_stream (utils.c:3940)
==22373==by 0x5F0500: matroska_parse_tracks (matroskadec.c:1853)
==22373==by 0x5F23DA: matroska_read_header (matroskadec.c:2294)
==22373==by 0x6DA6B8: avformat_open_input (utils.c:544)
==22373==by 0x41C7DE: open_input_file (ffmpeg_opt.c:949)
==22373==by 0x42562E: open_files (ffmpeg_opt.c:3003)
==22373==by 0x4257AC: ffmpeg_parse_options (ffmpeg_opt.c:3040)
==22373==by 0x43AC01: main (ffmpeg.c:4309)
==22373==
==22373== Invalid read of size 8
==22373==at 0x6E8BA7: avformat_match_stream_specifier (utils.c:4551)
==22373==by 0x41856B: check_stream_specifier (cmdutils.c:1964)
==22373==by 0x426648: init_input_filter (ffmpeg_filter.c:259)
==22373==by 0x4269AB: init_complex_filtergraph (ffmpeg_filter.c:317)
==22373==by 0x421170: init_complex_filters (ffmpeg_opt.c:1881)
==22373==by 0x4257DE: ffmpeg_parse_options (ffmpeg_opt.c:3047)
==22373==by 0x43AC01: main (ffmpeg.c:4309)
==22373==  Address 0xd8 is not stack'd, malloc'd or (recently) free'd
==22373==
==22373==
==22373== Process terminating with default action of signal 11 (SIGSEGV)
==22373==  Access not within mapped region at address 0xD8
==22373==at 0x6E8BA7: avformat_match_stream_specifier (utils.c:4551)
==22373==by 0x41856B: check_stream_specifier (cmdutils.c:1964)
==22373==by 0x426648: init_input_filter (ffmpeg_filter.c:259)
==22373==by 0x4269AB: init_complex_filtergraph (ffmpeg_filter.c:317)
==22373==by 0x421170: init_complex_filters (ffmpeg_opt.c:1881)
==22373==by 0x4257DE: ffmpeg_parse_options (ffmpeg_opt.c:3047)
==22373==by 0x43AC01: main (ffmpeg.c:4309)



[...]


-- 
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

[FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397

[Michael Niedermayer]

If someone can create a smaller test file (its 2.5Mb) that still has the same 
coverage that is welcome.
otherwise ill upload the sample attached to the ticket

Signed-off-by: Michael Niedermayer 
---
 tests/fate/filter-video.mak|4 +
 tests/filtergraphs/overlay-2397|2 +
 tests/ref/fate/filter-overlay-2397 |  848 
 3 files changed, 854 insertions(+)
 create mode 100644 tests/filtergraphs/overlay-2397
 create mode 100644 tests/ref/fate/filter-overlay-2397

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 7fb7677..5fd6ae0 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -304,6 +304,10 @@ FATE_FILTER-$(call ALLYES, SMJPEG_DEMUXER MJPEG_DECODER 
PERMS_FILTER HQDN3D_FILT
 fate-filter-hqdn3d-sample: tests/data/filtergraphs/hqdn3d
 fate-filter-hqdn3d-sample: CMD = framecrc -idct simple -i 
$(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/hqdn3d -an
 
+FATE_FILTER-$(call ALLYES, MATROSKA_DEMUXER OVERLAY_FILTER H264_DECODER 
DVDSUB_DECODER) += fate-filter-overlay-2397
+fate-filter-overlay-2397: tests/data/filtergraphs/overlay-2397
+fate-filter-overlay-2397: CMD = framecrc -flags bitexact -i 
$(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/overlay-2397 -c:a copy
+
 FATE_FILTER_HQX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER HQX_FILTER) = 
fate-filter-hq2x fate-filter-hq3x fate-filter-hq4x
 FATE_FILTER-yes += $(FATE_FILTER_HQX-yes)
 fate-filter-hq2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf hqx=2 -pix_fmt bgra
diff --git a/tests/filtergraphs/overlay-2397 b/tests/filtergraphs/overlay-2397
new file mode 100644
index 000..b0c923a
--- /dev/null
+++ b/tests/filtergraphs/overlay-2397
@@ -0,0 +1,2 @@
+sws_flags=+accurate_rnd+bitexact;
+[0:v][0:s:1]overlay
\ No newline at end of file
diff --git a/tests/ref/fate/filter-overlay-2397 
b/tests/ref/fate/filter-overlay-2397
new file mode 100644
index 000..318f739
--- /dev/null
+++ b/tests/ref/fate/filter-overlay-2397
@@ -0,0 +1,848 @@
+#tb 0: 100/2997
+#tb 1: 1/1000
+0,  0,  0,1,   518400, 0x6b05d48a
+1, 27, 27,   10, 2013, 0x68e7b03a
+0,  1,  1,1,   518400, 0x2c2219cd
+1, 37, 37,   10, 2013, 0x0b1d88d3
+1, 47, 47,   10, 2013, 0x65febc94
+1, 57, 57,   10, 2013, 0x1bb4b445
+0,  2,  2,1,   518400, 0xa71638c3
+1, 67, 67,   10, 2013, 0x88819a72
+1, 77, 77,   10, 2013, 0x35b89574
+1, 87, 87,   10, 2013, 0x1f08c7e3
+1, 97, 97,   10, 2013, 0x0afc948f
+0,  3,  3,1,   518400, 0x54bda463
+1,112,112,   10, 2013, 0x1d14a693
+1,122,122,   10, 2013, 0x53acb554
+1,132,132,   10, 2013, 0x71d0a075
+0,  4,  4,1,   518400, 0xd1e00574
+1,142,142,   10, 2013, 0xdcc8a88a
+1,152,152,   10, 2013, 0xd1b6a8a2
+1,162,162,   10, 2013, 0x46bba243
+0,  5,  5,1,   518400, 0x53b07f2d
+1,172,172,   10, 2013, 0xdcbe9933
+1,182,182,   10, 2013, 0xdef5ab52
+1,198,198,   10, 2013, 0xd16e8245
+0,  6,  6,1,   518400, 0x4d19c80b
+1,208,208,   10, 2013, 0x5567acd7
+1,218,218,   10, 2013, 0xfb129919
+1,228,228,   10, 2013, 0x26f8b101
+0,  7,  7,1,   518400, 0xd34866a2
+1,238,238,   10, 2013, 0xa903aff2
+1,248,248,   10, 2013, 0x056ba445
+1,258,258,   10, 2013, 0xd30ab214
+0,  8,  8,1,   518400, 0x0321c3db
+1,268,268,   10, 2013, 0x35409ef0
+1,283,283,   10, 2013, 0xa01b99a8
+1,293,293,   10, 2013, 0x776da122
+0,  9,  9,1,   518400, 0x3f460a79
+1,303,303,   10, 2013, 0x411ea855
+1,313,313,   10, 2013, 0x0f199df4
+1,323,323,   10, 2013, 0xb0598e93
+1,333,333,   10, 2013, 0xc63a905a
+0, 10, 10,1,   518400, 0x71202482
+1,343,343,   10, 2013, 0x3fbabd24
+1,353,353,   10, 2013, 0xfd55ba5c
+0, 11, 11,1,   518400, 0x2f7df36e
+1,368,368,   10, 2013, 0xf260b04e
+1,378,378,   10, 2013, 0xa1f6a1cf
+1,388,388,   10, 2013, 0x3559a529
+1,398,398,   10, 2013, 0x956e95ed

Re: [FFmpeg-devel] [PATCH] avformat/framehash: Add more information to the output

[James Almer]

On 3/30/2016 6:16 PM, wm4 wrote:
> Please wait with this after TEP2 is merged.

The TEP2 wip branch needs to be rebased to current master before it
can be merged, and the amount of ref files it modified was relatively
small, so this commit shouldn't generate many conflicts.
This adds a bunch of new fields to framehash, which may potentially
reveal new regressions by codecpar once fate is run post rebase if
this was committed beforehand.

Just my 2 cents.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/framehash: Add more information to the output

[James Almer]

On 3/30/2016 5:54 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/framehash.c|   13 +

Since you're pretty much rewriting every ref file, this may be a good chance
to turn framecrc into an alias for framemd5, hardcoding its AVHash context to
adler32.

framecrc is using zero as initial value for the checksum, and i recall you once
saying that it should be non-zero. AVHash and thus framemd5's adler32 uses 1 as
initial value.
It would also allow us to move the framecrc stream extradata checksum code to
ff_framehash_write_header() to be used by framemd5 without having to duplicate
code. Same with the packet side data checks.

Somebody recently sent a patch to rename framemd5 and probably also framecrc
into framehash (keeping the old names as aliases for compat reason). Maybe the
efforts could be combined.

For that matter, would this require MD5Context.format_version to be bumped? Be
it your patch as is or with any of the above suggestions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] According to SMPTE 370M (rev.2002), page 15 : "FS: First/second field flag",

[Carl Eugen Hoyos]

Александр Слободенюк  bramtech.ru> writes:

> I've found this case from practice, where DVCProHD coded 
> video (by Matrox device) with image, recorded as "top_field_first"
> got AVFrame->top_field_first == 0

Please upload a sample that shows this issue.

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

[FFmpeg-devel] Seeking dev for simple loudness app

[Daniel J. Lewis]

Hi! I'm Daniel J. Lewis, host of The Audacity to Podcast.

I'm interested in hiring a developer to create a simple cross-platform GUI
that uses ffmpeg for measuring integrated loudness, loudness range, and
true peak.

The command is simple:

ffmpeg -nostats -i SOURCE-FILE.wav -filter_complex ebur128=peak=true -f
null -

I envision a simple app for Windows, OS X, and maybe even Linux, packaged
with ffmpeg (if that's allowed). Launching the app would give drag-and-drop
target for audio files. After it processes the audio with the above
command, it would display the information for that file.

Ideally, this would allow batch processing and display a row for each file.
That would make it easy for comparisons.

My plan would be to either offer this app for free, or maybe as a part of a
podcasting community I run.

Please reply if you're interested and what you would charge for this.

Faithfully,

Daniel J. Lewis
Speaker, consultant, and award-winning host, The Audacity to Podcast

™
Get your international podcast reviews emailed to you automatically with My
Podcast Reviews

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