Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-16 Thread Michael Niedermayer 
On Thu, Jun 16, 2016 at 05:26:14PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> Fixes packet pts of samples which contain ctts entries with count=0.
> ---
> 
> Hello,
> 
> The following patch fixes packet pts of samples which contain ctts values with
> count=0 (so the ctts entry does not apply to any sample if I understand
> correctly). Such samples are produced by a LG G4 phone. I don't have any
> sample I can share at the moment (and thus no fate test following this patch
> yet).
> 
> An alternative to this patch is to remove directly the entry when the ctts 
> atom
> is parsed. Would you prefer this alternative ?

i dont know what is preferred but i agree about either solution

removing them on load would avoid any issues with ctts_count > 0
and no real entries, i dont know though if that ever matters

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

No snowflake in an avalanche ever feels responsible. -- 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 1/2] swresample: fix phase_count calculation

2016-06-16 Thread Muhammad Faiz 
On Thu, Jun 16, 2016 at 10:03 PM, Michael Niedermayer
 wrote:
> On Thu, Jun 16, 2016 at 12:31:03AM +0700, Muhammad Faiz wrote:
>> support odd phase_count
>> stick to low phase_count until set_compensation is called
>
> can you split these in 2 seperate patches ?
>
>
> [...]
>> @@ -382,6 +382,9 @@ static ResampleContext *resample_init(ResampleContext 
>> *c, int out_rate, int in_r
>>  c->index= -phase_count*((c->filter_length-1)/2);
>>  c->frac= 0;
>>
>> +/*av_log(NULL, AV_LOG_ERROR, "phase_count = %d, dst_incr = %d (%d + 
>> %d/%d)\n",
>> +   c->phase_count, c->dst_incr, c->dst_incr_div, c->dst_incr_mod, 
>> c->src_incr);*/
>> +
>>  swri_resample_dsp_init(c);
>>
>>  return c;
> [...]
>> +/*av_log(NULL, AV_LOG_ERROR, "phase_count = %d, dst_incr = %d (%d + 
>> %d/%d)\n",
>> +   c->phase_count, c->dst_incr, c->dst_incr_div, c->dst_incr_mod, 
>> c->src_incr);*/
>
> these disabled debug av_log() should probably not be pushed
>

OK, patches attached

Thank's
From 8cb201c678337dbf7c73545919e183f24ada2269 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Fri, 17 Jun 2016 05:30:37 +0700
Subject: [PATCH 1/2] swresample/resample: add support for odd phase_count

because exact_rational does not guarantee
that phase_count is even

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 1b1d83e..16c2a39 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -144,9 +144,10 @@ static double bessel(double x) {
 static int build_filter(ResampleContext *c, void *filter, double factor, int tap_count, int alloc, int phase_count, int scale,
 int filter_type, double kaiser_beta){
 int ph, i;
+int ph_nb = phase_count % 2 ? phase_count : phase_count / 2 + 1;
 double x, y, w, t, s;
 double *tab = av_malloc_array(tap_count+1,  sizeof(*tab));
-double *sin_lut = av_malloc_array(phase_count / 2 + 1, sizeof(*sin_lut));
+double *sin_lut = av_malloc_array(ph_nb, sizeof(*sin_lut));
 const int center= (tap_count-1)/2;
 
 if (!tab || !sin_lut)
@@ -156,13 +157,11 @@ static int build_filter(ResampleContext *c, void *filter, double factor, int tap
 if (factor > 1.0)
 factor = 1.0;
 
-av_assert0(phase_count == 1 || phase_count % 2 == 0);
-
 if (factor == 1.0) {
-for (ph = 0; ph <= phase_count / 2; ph++)
+for (ph = 0; ph < ph_nb; ph++)
 sin_lut[ph] = sin(M_PI * ph / phase_count);
 }
-for(ph = 0; ph <= phase_count / 2; ph++) {
+for(ph = 0; ph < ph_nb; ph++) {
 double norm = 0;
 s = sin_lut[ph];
 for(i=0;i<=tap_count;i++) {
@@ -203,6 +202,7 @@ static int build_filter(ResampleContext *c, void *filter, double factor, int tap
 case AV_SAMPLE_FMT_S16P:
 for(i=0;i

[FFmpeg-devel] [PATCH 2/2] avformat/oggparsevorbis: free base64 encoded data immediately after decoding it

2016-06-16 Thread James Almer 
It has no use afterwards and freeing it before calling ff_flac_parse_picture()
may help prevent OOM issues on memory constrained scenarios.

Signed-off-by: James Almer 
---
 libavformat/oggparsevorbis.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index c168718..89f40f6 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -161,10 +161,11 @@ int ff_vorbis_comment(AVFormatContext *as, AVDictionary 
**m,
 av_freep();
 continue;
 }
-if ((ret = av_base64_decode(pict, ct, len)) > 0)
-ret = ff_flac_parse_picture(as, pict, ret);
+ret = av_base64_decode(pict, ct, len);
 av_freep();
 av_freep();
+if (ret > 0)
+ret = ff_flac_parse_picture(as, pict, ret);
 av_freep();
 if (ret < 0) {
 av_log(as, AV_LOG_WARNING, "Failed to parse cover art 
block.\n");
-- 
2.8.2

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

[FFmpeg-devel] [PATCH 1/2] avformat/oggparsevorbis: use the base64 decode size macro

2016-06-16 Thread James Almer 
Allocate the memory needed for the decoded data rather than the
encoded data.

Signed-off-by: James Almer 
---
 libavformat/oggparsevorbis.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index a8cd6c9..c168718 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -152,8 +152,8 @@ int ff_vorbis_comment(AVFormatContext *as, AVDictionary **m,
  * recommended way of embedding cover art within VorbisComments."
  */
 if (!strcmp(tt, "METADATA_BLOCK_PICTURE") && parse_picture) {
-int ret;
-char *pict = av_malloc(vl);
+int ret, len = AV_BASE64_DECODE_SIZE(vl);
+char *pict = av_malloc(len);
 
 if (!pict) {
 av_log(as, AV_LOG_WARNING, "out-of-memory error. Skipping 
cover art block.\n");
@@ -161,7 +161,7 @@ int ff_vorbis_comment(AVFormatContext *as, AVDictionary **m,
 av_freep();
 continue;
 }
-if ((ret = av_base64_decode(pict, ct, vl)) > 0)
+if ((ret = av_base64_decode(pict, ct, len)) > 0)
 ret = ff_flac_parse_picture(as, pict, ret);
 av_freep();
 av_freep();
-- 
2.8.2

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

[FFmpeg-devel] [PATCH v3] avformat/tee: Support arbitrary number of slaves

2016-06-16 Thread sebechlebskyjan 
From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 I've missed that - sorry, should be fixed in this patch.

 libavformat/tee.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index 806beaa..421623d 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -27,8 +27,6 @@
 #include "avformat.h"
 #include "avio_internal.h"
 
-#define MAX_SLAVES 16
-
 typedef enum {
 ON_SLAVE_FAILURE_ABORT  = 1,
 ON_SLAVE_FAILURE_IGNORE = 2
@@ -52,7 +50,7 @@ typedef struct TeeContext {
 const AVClass *class;
 unsigned nb_slaves;
 unsigned nb_alive;
-TeeSlave slaves[MAX_SLAVES];
+TeeSlave *slaves;
 } TeeContext;
 
 static const char *const slave_delim = "|";
@@ -203,6 +201,7 @@ static void close_slaves(AVFormatContext *avf)
 for (i = 0; i < tee->nb_slaves; i++) {
 close_slave(>slaves[i]);
 }
+av_freep(>slaves);
 }
 
 static int open_slave(AVFormatContext *avf, char *slave, TeeSlave *tee_slave)
@@ -443,24 +442,26 @@ static int tee_write_header(AVFormatContext *avf)
 TeeContext *tee = avf->priv_data;
 unsigned nb_slaves = 0, i;
 const char *filename = avf->filename;
-char *slaves[MAX_SLAVES];
+char **slaves = NULL;
 int ret;
 
 while (*filename) {
-if (nb_slaves == MAX_SLAVES) {
-av_log(avf, AV_LOG_ERROR, "Maximum %d slave muxers reached.\n",
-   MAX_SLAVES);
-ret = AVERROR_PATCHWELCOME;
-goto fail;
-}
-if (!(slaves[nb_slaves++] = av_get_token(, slave_delim))) {
+char *slave = av_get_token(, slave_delim);
+if (!slave) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
+ret = av_dynarray_add_nofree(, _slaves, slave);
+if (ret < 0)
+goto fail;
 if (strspn(filename, slave_delim))
 filename++;
 }
 
+if (!(tee->slaves = av_mallocz_array(nb_slaves, sizeof(*tee->slaves {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 tee->nb_slaves = tee->nb_alive = nb_slaves;
 
 for (i = 0; i < nb_slaves; i++) {
@@ -483,12 +484,14 @@ static int tee_write_header(AVFormatContext *avf)
 av_log(avf, AV_LOG_WARNING, "Input stream #%d is not mapped "
"to any slave.\n", i);
 }
+av_free(slaves);
 return 0;
 
 fail:
 for (i = 0; i < nb_slaves; i++)
 av_freep([i]);
 close_slaves(avf);
+av_free(slaves);
 return ret;
 }
 
@@ -505,6 +508,7 @@ static int tee_write_trailer(AVFormatContext *avf)
 ret_all = ret;
 }
 }
+av_freep(>slaves);
 return ret_all;
 }
 
-- 
1.9.1

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

Re: [FFmpeg-devel] fix http to seek with int64 offset

2016-06-16 Thread Michael Niedermayer 
On Thu, Jun 16, 2016 at 02:00:26PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Jun 16, 2016 at 12:10 AM, Yuri Zats  wrote:
> 
> > I found that ffmpeg http seek fails when attempting to seek to offsets >
> > 0x8000 due to seek_ret being int32, and this patch addresses it.
> > Thanks for merging it in!
> 
> 
> That looks about right, LGTM - thanks.

applied

thanks

[...]
-- 
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] avutil/threadmessage.h: Fix swapped comments

2016-06-16 Thread Marton Balint 


On Thu, 16 Jun 2016, Jan Sebechlebsky wrote:


Ping :)

On 06/10/2016 07:11 PM, sebechlebsky...@gmail.com wrote:

From: Jan Sebechlebsky 

Fix swapped descriptions of av_thread_message_queue_set_err_send
and av_thread_message_queue_set_err_recv.

Signed-off-by: Jan Sebechlebsky 


Thanks, pushed.

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

Re: [FFmpeg-devel] [PATCH v2] avformat/tee: Support arbitrary number of slaves

2016-06-16 Thread Marton Balint 



On Thu, 16 Jun 2016, Jan Sebechlebsky wrote:


-char *slaves[MAX_SLAVES];
+char **slaves = NULL;
  int ret;

  while (*filename) {
-if (nb_slaves == MAX_SLAVES) {
-av_log(avf, AV_LOG_ERROR, "Maximum %d slave muxers 

reached.\n",

-   MAX_SLAVES);
-ret = AVERROR_PATCHWELCOME;
+char *slave = av_get_token(, slave_delim);
+if (!slave) {
+ret = AVERROR(ENOMEM);
  goto fail;
  }
-if (!(slaves[nb_slaves++] = av_get_token(, slave_delim))) 

{

+dynarray_add(, _slaves, slave);
+if (!slaves) {
  ret = AVERROR(ENOMEM);


How are you freeing individual slaves? Aren't those pointers get lost when 
dynarray returns NULL?


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

Re: [FFmpeg-devel] [PATCH] fate: add test for agate

2016-06-16 Thread Michael Niedermayer 
On Thu, Jun 16, 2016 at 04:03:18PM +, Petru Rares Sincraian wrote:
> 
> Hi there,
> 
> Here is a patch for the agate filter.
> 
> 
> Regards,
> Petru.

>  fate/filter-audio.mak |5 
>  ref/fate/filter-agate |  264 
> ++
>  2 files changed, 269 insertions(+)
> 4a8d7fbbfe806df6691920ca17b7635f6cbdda0c  0001-fate-add-test-for-agate.patch
> From 06678918311817e6b8d08780a594fb72b2a0fdbb Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Thu, 16 Jun 2016 17:12:29 +0200
> Subject: [PATCH] fate: add test for agate
> 
> ---
>  tests/fate/filter-audio.mak |   5 +
>  tests/ref/fate/filter-agate | 264 
> 
>  2 files changed, 269 insertions(+)
>  create mode 100644 tests/ref/fate/filter-agate

applied

thanks


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

[FFmpeg-devel] [PATCH 3/3] ffmpeg: copy trailing_padding when using -acodec copy

2016-06-16 Thread Jon Toohill 
---
 ffmpeg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index 652774f..442f818 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3001,6 +3001,7 @@ static int transcode_init(void)
 enc_ctx->audio_service_type = dec_ctx->audio_service_type;
 enc_ctx->block_align= dec_ctx->block_align;
 enc_ctx->initial_padding= dec_ctx->delay;
+enc_ctx->trailing_padding   = dec_ctx->trailing_padding;
 enc_ctx->profile= dec_ctx->profile;
 #if FF_API_AUDIOENC_DELAY
 enc_ctx->delay  = dec_ctx->delay;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 1/3] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters

2016-06-16 Thread Jon Toohill 
Also removes decoder delay compensation from libmp3lame and mp3enc.
initial_padding specifies only encoder delay, decoder delay is
handled by start_skip_samples.
---
 libavcodec/libmp3lame.c | 2 +-
 libavformat/mp3dec.c| 2 ++
 libavformat/mp3enc.c| 9 ++---
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5642264..198ac94 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -137,7 +137,7 @@ static av_cold int mp3lame_encode_init(AVCodecContext 
*avctx)
 }
 
 /* get encoder delay */
-avctx->initial_padding = lame_get_encoder_delay(s->gfp) + 528 + 1;
+avctx->initial_padding = lame_get_encoder_delay(s->gfp);
 ff_af_queue_init(avctx, >afq);
 
 avctx->frame_size  = lame_get_framesize(s->gfp);
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 56c7f8c..345fa88 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -239,6 +239,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, AVStream 
*st,
 
 mp3->start_pad = v>>12;
 mp3->  end_pad = v&4095;
+st->codecpar->initial_padding = mp3->start_pad;
+st->codecpar->trailing_padding = mp3->end_pad;
 st->start_skip_samples = mp3->start_pad + 528 + 1;
 if (mp3->frames) {
 st->first_discard_sample = -mp3->end_pad + 528 + 1 + mp3->frames * 
(int64_t)spf;
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index de63401..da70d13 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -248,11 +248,14 @@ static int mp3_write_xing(AVFormatContext *s)
 avio_w8(dyn_ctx, 0);  // unknown encoding flags
 avio_w8(dyn_ctx, 0);  // unknown abr/minimal bitrate
 
-// encoder delay
-if (par->initial_padding - 528 - 1 >= 1 << 12) {
+// encoder delay/padding
+if (par->initial_padding >= 1 << 12) {
 av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
 }
-avio_wb24(dyn_ctx, FFMAX(par->initial_padding - 528 - 1, 0)<<12);
+if (par->trailing_padding >= 1 << 12) {
+av_log(s, AV_LOG_WARNING, "Too many samples of trailing padding.\n");
+}
+avio_wb24(dyn_ctx, (par->initial_padding << 12) | (par->trailing_padding & 
0xFFF));
 
 avio_w8(dyn_ctx,   0); // misc
 avio_w8(dyn_ctx,   0); // mp3gain
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 2/3] lavc: show gapless info in stream summary

2016-06-16 Thread Jon Toohill 
Also adds trailing_padding to AVCodecContext to match
AVCodecParameters so that it doesn't get lost when mapping
between them.
---
 doc/APIchanges   |  4 
 libavcodec/avcodec.h | 11 +++
 libavcodec/utils.c   | 40 +++-
 libavcodec/version.h |  2 +-
 4 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index d777dc0..6092419 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-05-25 - xxx - lavc 57.47.100 - avcodec.h
+  Add trailing_padding to AVCodecContext to match the corresponding
+  field in AVCodecParameters.
+
 2016-04-27 - xxx - lavu 55.23.100 - log.h
   Add a new function av_log_format_line2() which returns number of bytes
   written to the target buffer.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0181eb1..700c9b8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3504,6 +3504,17 @@ typedef struct AVCodecContext {
 #define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1
 #endif
 
+/**
+ * Audio only. The amount of padding (in samples) appended by the encoder 
to
+ * the end of the audio. I.e. this number of decoded samples must be
+ * discarded by the caller from the end of the stream to get the original
+ * audio without any trailing padding.
+ *
+ * - decoding: unused
+ * - encoding: unused
+ */
+int trailing_padding;
+
 } AVCodecContext;
 
 AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 402a9d8..481e09c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3252,6 +3252,10 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 && enc->bits_per_raw_sample != 
av_get_bytes_per_sample(enc->sample_fmt) * 8)
 snprintf(buf + strlen(buf), buf_size - strlen(buf),
  " (%d bit)", enc->bits_per_raw_sample);
+if (enc->initial_padding || enc->trailing_padding) {
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ ", delay %d, padding %d", enc->initial_padding, 
enc->trailing_padding);
+}
 break;
 case AVMEDIA_TYPE_DATA:
 if (av_log_get_level() >= AV_LOG_DEBUG) {
@@ -4097,14 +4101,15 @@ int avcodec_parameters_from_context(AVCodecParameters 
*par,
 par->video_delay = codec->has_b_frames;
 break;
 case AVMEDIA_TYPE_AUDIO:
-par->format  = codec->sample_fmt;
-par->channel_layout  = codec->channel_layout;
-par->channels= codec->channels;
-par->sample_rate = codec->sample_rate;
-par->block_align = codec->block_align;
-par->frame_size  = codec->frame_size;
-par->initial_padding = codec->initial_padding;
-par->seek_preroll= codec->seek_preroll;
+par->format   = codec->sample_fmt;
+par->channel_layout   = codec->channel_layout;
+par->channels = codec->channels;
+par->sample_rate  = codec->sample_rate;
+par->block_align  = codec->block_align;
+par->frame_size   = codec->frame_size;
+par->initial_padding  = codec->initial_padding;
+par->trailing_padding = codec->trailing_padding;
+par->seek_preroll = codec->seek_preroll;
 break;
 case AVMEDIA_TYPE_SUBTITLE:
 par->width  = codec->width;
@@ -4151,15 +4156,16 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 codec->has_b_frames   = par->video_delay;
 break;
 case AVMEDIA_TYPE_AUDIO:
-codec->sample_fmt  = par->format;
-codec->channel_layout  = par->channel_layout;
-codec->channels= par->channels;
-codec->sample_rate = par->sample_rate;
-codec->block_align = par->block_align;
-codec->frame_size  = par->frame_size;
-codec->delay   =
-codec->initial_padding = par->initial_padding;
-codec->seek_preroll= par->seek_preroll;
+codec->sample_fmt   = par->format;
+codec->channel_layout   = par->channel_layout;
+codec->channels = par->channels;
+codec->sample_rate  = par->sample_rate;
+codec->block_align  = par->block_align;
+codec->frame_size   = par->frame_size;
+codec->delay=
+codec->initial_padding  = par->initial_padding;
+codec->trailing_padding = par->trailing_padding;
+codec->seek_preroll = par->seek_preroll;
 break;
 case AVMEDIA_TYPE_SUBTITLE:
 codec->width  = par->width;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 0852b43..37a6e17 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define

Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi

2016-06-16 Thread Aman Gupta 
The patchset that was merged into libav is now available in ffmpeg as well:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/omx.c

You can compile ffmpeg from the master branch
with --enable-omx --enable-omx-rpi

Aman

On Thu, Jun 16, 2016 at 2:16 AM, Amancio Hasty  wrote:

>
> > On May 9, 2016, at 7:55 AM, Amancio Hasty  wrote:
> >
> > Hi,
> >
> > So what is the next step?
> >
> > If you want testers I suggest posting to ccrisan’s motionpie mailing
> list.
> > Cheers
> > Amancio
> >
> >
> >> On Mar 31, 2016, at 7:27 PM, Amancio Hasty  wrote:
> >>
> >> I am not a lawyer…
> >>
> >>
> >> I updated the patch.  vc264.c now has a the copyright notice embedded in
> >> a volatile global so if a binary is compiled against vc264.o , the
> copyright notice
> >> can be displayed by:
> >> strings ffmpeg | grep -i copyright
> >>
> >> LICENSE.md has been updated to include Broadcom’s copyright notice.
> >>
> >> A distribution of a  binary that includes vc264.o should include
> LICENSE.md and if
> >> that is missing,  the copyright notice can be displayed via the shell
> >> command ‘strings’ .
> >>
> >> Amancio
> >> 
> >>> On Mar 22, 2016, at 12:12 PM, Lou Logan  wrote:
> >>>
> >>> On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote:
> >>>
>  From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001
>  From: Amancio Hasty 
>  Date: Mon, 21 Mar 2016 18:56:05 -0700
>  Subject: [PATCH] added support for hardware assist H264  video
> encoding for
>  the Raspberry Pi
> 
>  ---
>  configure  |  12 ++
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   2 +
>  libavcodec/vc264.c | 387
> +
>  4 files changed, 402 insertions(+)
>  create mode 100644 libavcodec/vc264.c
> 
> >>> [...]
>  diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>  index 2a25d66..3c7bd9b 100644
>  --- a/libavcodec/allcodecs.c
>  +++ b/libavcodec/allcodecs.c
>  @@ -74,6 +74,7 @@ void avcodec_register_all(void)
>    initialized = 1;
> 
> >>>
> >>> Nit: Whitespace on the line above should be removed.
> >>>
> >>> [...]
>  --- /dev/null
>  +++ b/libavcodec/vc264.c
>  @@ -0,0 +1,387 @@
>  +/*  H.264 hardware assist video encoding code taken from
>  + * raspberry's os :
>  + *   /opt/vc/src/hello_pi/hello_encode/encode.c
>  + */
>  +
>  +/*
>  +Copyright (c) 2012, Broadcom Europe Ltd
>  +Copyright (c) 2012, Kalle Vahlman 
>  +Tuomas Kulve 
>  +All rights reserved.
>  +
>  +Redistribution and use in source and binary forms, with or without
>  +modification, are permitted provided that the following conditions
> are met:
>  +* Redistributions of source code must retain the above copyright
>  +  notice, this list of conditions and the following disclaimer.
>  +  * Redistributions in binary form must reproduce the above
> copyright
>  +  notice, this list of conditions and the following disclaimer
> in the
>  +  documentation and/or other materials provided with the
> distribution.
>  +  * Neither the name of the copyright holder nor the
>  +  names of its contributors may be used to endorse or promote
> products
>  +  derived from this software without specific prior written
> permission.
>  +
>  +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND
>  +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE IMPLIED
>  +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> ARE
>  +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE LIABLE FOR ANY
>  +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES
>  +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
>  +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> CAUSED AND
>  +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> OR TORT
>  +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> USE OF THIS
>  +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >>>
> >>> I wonder if any of the above legalese is compatible. Granted, I see a
> >>> similar paragraph in "libavformat/aadec.c".
> >>>
>  + * ffmpeg driver for hardware assist video H.264 encoding using
> Broadcom's GPU
>  + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com
>  + *
>  + *
>  + * 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

[FFmpeg-devel] [PATCH 0/3] Pass Xing gapless metadata to users during mp3 parsing

2016-06-16 Thread Jon Toohill 
These patches expose the encoder delay/padding parsed from an mp3's Xing header 
to users of lavc/lavf, and show gapless info in the stream summary string. They 
also change ffmpeg to pass Xing gapless metadata from input to output when 
using -acodec copy.

trailing_padding is still not set properly when encoding with libmp3lame, 
causing an encode/decode round trip to add trailing silence. This is not a 
regression from current behavior, and will be addressed in a separate patch set.

Jon Toohill (3):
  lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters
  lavc: show gapless info in stream summary
  ffmpeg: copy trailing_padding when using -acodec copy

 doc/APIchanges  |  4 
 ffmpeg.c|  1 +
 libavcodec/avcodec.h| 11 +++
 libavcodec/libmp3lame.c |  2 +-
 libavcodec/utils.c  | 40 +++-
 libavcodec/version.h|  2 +-
 libavformat/mp3dec.c|  2 ++
 libavformat/mp3enc.c|  9 ++---
 8 files changed, 49 insertions(+), 22 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] fix http to seek with int64 offset

2016-06-16 Thread Ronald S. Bultje 
Hi,

On Thu, Jun 16, 2016 at 12:10 AM, Yuri Zats  wrote:

> I found that ffmpeg http seek fails when attempting to seek to offsets >
> 0x8000 due to seek_ret being int32, and this patch addresses it.
> Thanks for merging it in!


That looks about right, LGTM - thanks.

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

[FFmpeg-devel] fix http to seek with int64 offset

2016-06-16 Thread Yuri Zats 
I found that ffmpeg http seek fails when attempting to seek to offsets > 
0x8000 due to seek_ret being int32, and this patch addresses it.
Thanks for merging it in!



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

Re: [FFmpeg-devel] [PATCH v2] avformat/tee: Support arbitrary number of slaves

2016-06-16 Thread Jan Sebechlebsky 

Ping :)

On 06/12/2016 08:17 PM, sebechlebsky...@gmail.com wrote:

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
  libavformat/tee.c | 24 +++-
  1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index 806beaa..bf7438c 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -27,8 +27,6 @@
  #include "avformat.h"
  #include "avio_internal.h"
  
-#define MAX_SLAVES 16

-
  typedef enum {
  ON_SLAVE_FAILURE_ABORT  = 1,
  ON_SLAVE_FAILURE_IGNORE = 2
@@ -52,7 +50,7 @@ typedef struct TeeContext {
  const AVClass *class;
  unsigned nb_slaves;
  unsigned nb_alive;
-TeeSlave slaves[MAX_SLAVES];
+TeeSlave *slaves;
  } TeeContext;
  
  static const char *const slave_delim = "|";

@@ -203,6 +201,7 @@ static void close_slaves(AVFormatContext *avf)
  for (i = 0; i < tee->nb_slaves; i++) {
  close_slave(>slaves[i]);
  }
+av_freep(>slaves);
  }
  
  static int open_slave(AVFormatContext *avf, char *slave, TeeSlave *tee_slave)

@@ -443,17 +442,17 @@ static int tee_write_header(AVFormatContext *avf)
  TeeContext *tee = avf->priv_data;
  unsigned nb_slaves = 0, i;
  const char *filename = avf->filename;
-char *slaves[MAX_SLAVES];
+char **slaves = NULL;
  int ret;
  
  while (*filename) {

-if (nb_slaves == MAX_SLAVES) {
-av_log(avf, AV_LOG_ERROR, "Maximum %d slave muxers reached.\n",
-   MAX_SLAVES);
-ret = AVERROR_PATCHWELCOME;
+char *slave = av_get_token(, slave_delim);
+if (!slave) {
+ret = AVERROR(ENOMEM);
  goto fail;
  }
-if (!(slaves[nb_slaves++] = av_get_token(, slave_delim))) {
+dynarray_add(, _slaves, slave);
+if (!slaves) {
  ret = AVERROR(ENOMEM);
  goto fail;
  }
@@ -461,6 +460,10 @@ static int tee_write_header(AVFormatContext *avf)
  filename++;
  }
  
+if (!(tee->slaves = av_mallocz_array(nb_slaves, sizeof(*tee->slaves {

+ret = AVERROR(ENOMEM);
+goto fail;
+}
  tee->nb_slaves = tee->nb_alive = nb_slaves;
  
  for (i = 0; i < nb_slaves; i++) {

@@ -483,12 +486,14 @@ static int tee_write_header(AVFormatContext *avf)
  av_log(avf, AV_LOG_WARNING, "Input stream #%d is not mapped "
 "to any slave.\n", i);
  }
+av_free(slaves);
  return 0;
  
  fail:

  for (i = 0; i < nb_slaves; i++)
  av_freep([i]);
  close_slaves(avf);
+av_free(slaves);
  return ret;
  }
  
@@ -505,6 +510,7 @@ static int tee_write_trailer(AVFormatContext *avf)

  ret_all = ret;
  }
  }
+av_freep(>slaves);
  return ret_all;
  }
  


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

Re: [FFmpeg-devel] [PATCH] avutil/threadmessage.h: Fix swapped comments

2016-06-16 Thread Jan Sebechlebsky 

Ping :)

On 06/10/2016 07:11 PM, sebechlebsky...@gmail.com wrote:

From: Jan Sebechlebsky 

Fix swapped descriptions of av_thread_message_queue_set_err_send
and av_thread_message_queue_set_err_recv.

Signed-off-by: Jan Sebechlebsky 
---
  libavutil/threadmessage.h | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
index e256cae..8480a0a 100644
--- a/libavutil/threadmessage.h
+++ b/libavutil/threadmessage.h
@@ -69,10 +69,10 @@ int av_thread_message_queue_recv(AVThreadMessageQueue *mq,
  /**
   * Set the sending error code.
   *
- * If the error code is set to non-zero, av_thread_message_queue_recv() will
- * return it immediately when there are no longer available messages.
- * Conventional values, such as AVERROR_EOF or AVERROR(EAGAIN), can be used
- * to cause the receiving thread to stop or suspend its operation.
+ * If the error code is set to non-zero, av_thread_message_queue_send() will
+ * return it immediately. Conventional values, such as AVERROR_EOF or
+ * AVERROR(EAGAIN), can be used to cause the sending thread to stop or
+ * suspend its operation.
   */
  void av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
int err);
@@ -80,10 +80,10 @@ void 
av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
  /**
   * Set the receiving error code.
   *
- * If the error code is set to non-zero, av_thread_message_queue_send() will
- * return it immediately. Conventional values, such as AVERROR_EOF or
- * AVERROR(EAGAIN), can be used to cause the sending thread to stop or
- * suspend its operation.
+ * If the error code is set to non-zero, av_thread_message_queue_recv() will
+ * return it immediately when there are no longer available messages.
+ * Conventional values, such as AVERROR_EOF or AVERROR(EAGAIN), can be used
+ * to cause the receiving thread to stop or suspend its operation.
   */
  void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
int err);


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

[FFmpeg-devel] [PATCH] fate: add test for agate

2016-06-16 Thread Petru Rares Sincraian 

Hi there,

Here is a patch for the agate filter.


Regards,
Petru.From 06678918311817e6b8d08780a594fb72b2a0fdbb Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Thu, 16 Jun 2016 17:12:29 +0200
Subject: [PATCH] fate: add test for agate

---
 tests/fate/filter-audio.mak |   5 +
 tests/ref/fate/filter-agate | 264 
 2 files changed, 269 insertions(+)
 create mode 100644 tests/ref/fate/filter-agate

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 575a7bf..7c903b7 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -58,6 +58,11 @@ fate-filter-acrossfade: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-acrossfade: SRC2 = $(TARGET_SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav
 fate-filter-acrossfade: CMD = framecrc -i $(SRC) -i $(SRC2) -filter_complex acrossfade=d=2:c1=log:c2=exp
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, AFADE, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-agate
+fate-filter-agate: tests/data/asynth-44100-2.wav
+fate-filter-agate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-agate: CMD = framecrc -i $(SRC) -af agate=level_in=10:range=0:threshold=1:ratio=1:attack=1:knee=1:makeup=4
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-agate b/tests/ref/fate/filter-agate
new file mode 100644
index 000..4f7b10e
--- /dev/null
+++ b/tests/ref/fate/filter-agate
@@ -0,0 +1,264 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x1af20090
+0,   1024,   1024, 1024, 4096, 0x0b05ef2d
+0,   2048,   2048, 1024, 4096, 0x574bf11d
+0,   3072,   3072, 1024, 4096, 0x774af5d3
+0,   4096,   4096, 1024, 4096, 0x7b51ff33
+0,   5120,   5120, 1024, 4096, 0xf610f9bf
+0,   6144,   6144, 1024, 4096, 0x3c20ef79
+0,   7168,   7168, 1024, 4096, 0x427bef59
+0,   8192,   8192, 1024, 4096, 0x8773fa99
+0,   9216,   9216, 1024, 4096, 0xbf1dfe89
+0,  10240,  10240, 1024, 4096, 0x462df4dd
+0,  11264,  11264, 1024, 4096, 0x1170f169
+0,  12288,  12288, 1024, 4096, 0xcb9cf633
+0,  13312,  13312, 1024, 4096, 0x7e8c01da
+0,  14336,  14336, 1024, 4096, 0x93c202d0
+0,  15360,  15360, 1024, 4096, 0xd882ec6d
+0,  16384,  16384, 1024, 4096, 0x03fbec6d
+0,  17408,  17408, 1024, 4096, 0x73f400d4
+0,  18432,  18432, 1024, 4096, 0xea8c01da
+0,  19456,  19456, 1024, 4096, 0x23cbf82f
+0,  20480,  20480, 1024, 4096, 0x85cdf169
+0,  21504,  21504, 1024, 4096, 0x8e27f2e1
+0,  22528,  22528, 1024, 4096, 0x91bffe89
+0,  23552,  23552, 1024, 4096, 0xc31afd95
+0,  24576,  24576, 1024, 4096, 0x5c23ee59
+0,  25600,  25600, 1024, 4096, 0x58d0ef79
+0,  26624,  26624, 1024, 4096, 0xfccff7c3
+0,  27648,  27648, 1024, 4096, 0x7084ff33
+0,  28672,  28672, 1024, 4096, 0x7f1bf7cf
+0,  29696,  29696, 1024, 4096, 0x8037f11d
+0,  30720,  30720, 1024, 4096, 0xd106ed31
+0,  31744,  31744, 1024, 4096, 0xaf820090
+0,  32768,  32768, 1024, 4096, 0x1af20090
+0,  33792,  33792, 1024, 4096, 0x0b05ef2d
+0,  34816,  34816, 1024, 4096, 0x574bf11d
+0,  35840,  35840, 1024, 4096, 0x774af5d3
+0,  36864,  36864, 1024, 4096, 0x7b51ff33
+0,  37888,  37888, 1024, 4096, 0xf610f9bf
+0,  38912,  38912, 1024, 4096, 0x3c20ef79
+0,  39936,  39936, 1024, 4096, 0x427bef59
+0,  40960,  40960, 1024, 4096, 0x8773fa99
+0,  41984,  41984, 1024, 4096, 0xbf1dfe89
+0,  43008,  43008, 1024, 4096, 0x462df4dd
+0,  44032,  44032, 1024, 4096, 0x41650472
+0,  45056,  45056, 1024, 4096, 0x1081f133
+0,  46080,  46080, 1024, 4096, 0x9da3e58b
+0,  47104,  47104, 1024, 4096, 0x752614ac
+0,  48128,  48128, 1024, 4096, 0x0f23034c
+0,  49152,  49152, 1024, 4096, 0x768fe8a1
+0,  50176,  50176, 1024, 4096, 0xf0f9079e
+0,  51200,  51200, 1024, 4096, 0x8543ed93
+0,  52224,  52224, 1024, 4096, 0x9f96fe9d
+0,  53248,  53248, 1024, 4096, 0x94f3facf
+0,  54272,  54272, 1024, 4096, 0xc0defe4d
+0,  55296,  55296, 1024, 4096, 0x4e22f5ff
+0,  56320,  56320,

[FFmpeg-devel] [PATCH] lavf/mov: ignore ctts entries that do not apply to a least one sample

2016-06-16 Thread Matthieu Bouron 
From: Matthieu Bouron 

Fixes packet pts of samples which contain ctts entries with count=0.
---

Hello,

The following patch fixes packet pts of samples which contain ctts values with
count=0 (so the ctts entry does not apply to any sample if I understand
correctly). Such samples are produced by a LG G4 phone. I don't have any
sample I can share at the moment (and thus no fate test following this patch
yet).

An alternative to this patch is to remove directly the entry when the ctts atom
is parsed. Would you prefer this alternative ?

What happens without the patch is that the ctts_index is never incremented if
the current ctts entry count is 0.

Matthieu

---
 libavformat/mov.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 57a0354..7fbad22 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5175,6 +5175,11 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 pkt->stream_index = sc->ffindex;
 pkt->dts = sample->timestamp;
+
+if (sc->ctts_data && sc->ctts_index < sc->ctts_count &&
+sc->ctts_data[sc->ctts_index].count == 0)
+sc->ctts_index++;
+
 if (sc->ctts_data && sc->ctts_index < sc->ctts_count) {
 pkt->pts = pkt->dts + sc->dts_shift + 
sc->ctts_data[sc->ctts_index].duration;
 /* update ctts context */
-- 
2.8.3

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

Re: [FFmpeg-devel] [PATCH 1/2] swresample: fix phase_count calculation

2016-06-16 Thread Michael Niedermayer 
On Thu, Jun 16, 2016 at 12:31:03AM +0700, Muhammad Faiz wrote:
> support odd phase_count
> stick to low phase_count until set_compensation is called

can you split these in 2 seperate patches ?


[...]
> @@ -382,6 +382,9 @@ static ResampleContext *resample_init(ResampleContext *c, 
> int out_rate, int in_r
>  c->index= -phase_count*((c->filter_length-1)/2);
>  c->frac= 0;
>  
> +/*av_log(NULL, AV_LOG_ERROR, "phase_count = %d, dst_incr = %d (%d + 
> %d/%d)\n",
> +   c->phase_count, c->dst_incr, c->dst_incr_div, c->dst_incr_mod, 
> c->src_incr);*/
> +
>  swri_resample_dsp_init(c);
>  
>  return c;
[...]
> +/*av_log(NULL, AV_LOG_ERROR, "phase_count = %d, dst_incr = %d (%d + 
> %d/%d)\n",
> +   c->phase_count, c->dst_incr, c->dst_incr_div, c->dst_incr_mod, 
> c->src_incr);*/

these disabled debug av_log() should probably not be pushed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] lavd/v4l2: allow devices not implementing VIDIOC_G_PARM

2016-06-16 Thread Michael Niedermayer 
On Thu, Jun 16, 2016 at 10:16:54AM +0200, Benoit Fouet wrote:
> Hi,
> 
> 
> On 15/06/2016 17:21, Niklas Söderlund wrote:
> >Not all v4l2 devices implement the VIDIOC_G_PARM ioctl. This patch allow
> >ffmpeg to open such device and treat it the same as devices that do
> >implement the ioctl but returns that it do not implement the
> >V4L2_CAP_TIMEPERFRAME capability.
> >
> >Signed-off-by: Niklas Söderlund 
> >---
> >  libavdevice/v4l2.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> >diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> >index 103fb10..c8915e0 100644
> >--- a/libavdevice/v4l2.c
> >+++ b/libavdevice/v4l2.c
> >@@ -715,11 +715,8 @@ static int v4l2_set_parameters(AVFormatContext *ctx)
> >  streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> >  if (v4l2_ioctl(s->fd, VIDIOC_G_PARM, ) < 0) {
> >  ret = AVERROR(errno);
> >-av_log(ctx, AV_LOG_ERROR, "ioctl(VIDIOC_G_PARM): %s\n", 
> >av_err2str(ret));
> >-return ret;
> >-}
> >-
> >-if (framerate_q.num && framerate_q.den) {
> >+av_log(ctx, AV_LOG_WARNING, "ioctl(VIDIOC_G_PARM): %s\n", 
> >av_err2str(ret));
> >+} else if (framerate_q.num && framerate_q.den) {
> >  if (streamparm.parm.capture.capability & V4L2_CAP_TIMEPERFRAME) {
> >  tpf = 
> 
> LGTM

applied

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] bans

2016-06-16 Thread Ivan Kalvachev 
On 6/16/16, Michael Niedermayer  wrote:
> On Wed, Jun 15, 2016 at 10:50:51AM -0300, James Almer wrote:
>> On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
>> > Hi all
>> >
>> > As noone is doing anything about the situation and what is being
>> > done will not lead anywhere (the vote likely wont lead anywhere as
>> > likely few would ban a active developer 4 month and then if not
>> > some will feel injustice prevailed thus
>> >
>> > After writing this mail i will
>> >
>> > 1. ban carl for 24h from the ML due to
>> > causing  derek to leave the project. (24h was suggested in the IRC
>> > meeting)
>>
>> This is useless IMO. While four months is too much, 24 hours is
>> insignificant.
>>
>
>> Let's not implement bans without a discussion and a vote first.
>
> I agree but if i do nothing people are unhappy that i did nothing,
> if i talk with people trying to resolve a conflict well, it did not
> work this time. and if i do something else people complain too.
> and its 4 weeks since the incident.
> Doing some symbolic action seemed to make sense until the people
> finish discussions and votes.
> I believe i do not have the authority to hand out real (week+) bans,
> nor would i want that authority. Also i will stay away
> from symbolic bans too, this was intended to improve the situation,
> and i believe it did not achieve that.

One way to resolve the matter as mature people would be
asking Carl to explain his words and actions in civilized manner,
then apologize for going over the board.

It is completely counterproductive to escalate the issue with
attempts for public humiliation and punishment,
without making attempts for addressing the bad behavior
they are supposed to stop.



>> The current vote will probably go nowhere, so a proper discussion thread
>> followed by a vote will have to be made.
>
> Yes,
> its up to the vote committee and the community to decide what should
> be done.
>
>
>>
>> > I suspect carl saw the merges done by derek as causing more bugs than
>> > good so he attacked until derek stoped doing the merges.
>>
>> Which is the shitty behavior that's being discussed about. When you find
>> problems you report them, or help fix them. You don't attack the person
>> working on them.
>>
>> > The correct course of action would have been a vote about stoping the
>> > merges or a change to the procedure to reduce the amount of bugs.
>> > Like maybe a seperate branch where merges can be tested for ~24h before
>> > being pushed to master ...
>> > Or maybe more people working on fixing regressions
>> > As a sidenote, most of the regressions should be fixed by now.
>> >
>> > 2. ban derek for ~24h from the ML due to causing lukasz to leave the
>> > project last year, and due to personal insults on the ML and IRC
>> > to lukasz and carl.
>> > As derek is not subscribed to the list ATM, this will be implemented
>> > by moving him from the accept_these_nonmembers list to the
>> > reject_these_nonmembers list for ~24h
>> >
>> > 3. ban myself for ~24h from the ML because i wrote offensive mails too
>> > years ago and i doubt none was pivotal in causing someone to leave
>>
>> And this is silly. It's old history and nobody requested such action in
>> any what whatsoever. It will only derail the discussion and again, bans
>> without discussion or vote are a big no.
>
> It may be unimportant but the "ban" would never have stopped derek from
> subscribing or subsequently posting a message.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] bans

2016-06-16 Thread compn 
On Thu, 16 Jun 2016 15:21:47 +0200
Michael Niedermayer  wrote:

> I agree but if i do nothing people are unhappy that i did nothing,
> if i talk with people trying to resolve a conflict well, it did not
> work this time. and if i do something else people complain too.

you tried. thanks for trying.

why is no one happy?

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

Re: [FFmpeg-devel] bans

2016-06-16 Thread compn 
On Thu, 16 Jun 2016 00:56:28 -0300
James Almer  wrote:

> I don't think i called him names but if you think i did and violated

>>You'll get inside a spiral of bullshit with no
>>end until you decide to stop feeding the troll disguised as worried
>>contributor.

you did call him a troll. :D

> the CoC then you're welcome to call a vote for whatever action you

nah, i actually dont give a shit. i'm for free speech, not nonsense
censorship. :)

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add myself for videotoolbox.c, remove vda* maintainer

2016-06-16 Thread compn 
On Thu, 16 Jun 2016 09:12:39 -0400
Rick Kern  wrote:

> Person in MAINTAINERS hasn't responded to a patch on the ML or private
> email, and doesn't maintain the files according to git.

LGTM

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

[FFmpeg-devel] [PATCH] tests/api/api-codec-param-test: Do not directly access caps_internal

2016-06-16 Thread Michael Niedermayer 
The caps_internal field has moved without major bump and direct
access causes crashes, found when testing 3.1

Signed-off-by: Michael Niedermayer 
---
 tests/api/api-codec-param-test.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/api/api-codec-param-test.c b/tests/api/api-codec-param-test.c
index fa51964..377a5e9 100644
--- a/tests/api/api-codec-param-test.c
+++ b/tests/api/api-codec-param-test.c
@@ -50,7 +50,7 @@ static int try_decode_video_frame(AVCodecContext *codec_ctx, 
AVPacket *pkt, int
 goto end;
 }
 
-if (!decode && codec_ctx->codec->caps_internal & 
FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
+if (!decode && 
avpriv_codec_get_cap_skip_frame_fill_param(codec_ctx->codec)) {
 codec_ctx->skip_frame = AVDISCARD_ALL;
 }
 
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] MAINTAINERS: Add myself for videotoolbox.c, remove vda* maintainer

2016-06-16 Thread Rick Kern 
Person in MAINTAINERS hasn't responded to a patch on the ML or private
email, and doesn't maintain the files according to git.

Signed-off-by: Rick Kern 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4fe999d..ef23967 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -306,9 +306,8 @@ Hardware acceleration:
   mediacodec*   Matthieu Bouron
   vaapi*Gwenole Beauchesne
   vaapi_encode* Mark Thompson
-  vda*  Sebastien Zwickert
   vdpau*Philip Langdale, Carl Eugen Hoyos
-  videotoolbox* Sebastien Zwickert
+  videotoolbox* Rick Kern
 
 
 libavdevice
-- 
2.7.4

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

Re: [FFmpeg-devel] bans

2016-06-16 Thread Michael Niedermayer 
On Wed, Jun 15, 2016 at 10:50:51AM -0300, James Almer wrote:
> On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
> > Hi all
> > 
> > As noone is doing anything about the situation and what is being
> > done will not lead anywhere (the vote likely wont lead anywhere as
> > likely few would ban a active developer 4 month and then if not
> > some will feel injustice prevailed thus
> > 
> > After writing this mail i will
> > 
> > 1. ban carl for 24h from the ML due to
> > causing  derek to leave the project. (24h was suggested in the IRC
> > meeting)
> 
> This is useless IMO. While four months is too much, 24 hours is
> insignificant.
> 

> Let's not implement bans without a discussion and a vote first.

I agree but if i do nothing people are unhappy that i did nothing,
if i talk with people trying to resolve a conflict well, it did not
work this time. and if i do something else people complain too.
and its 4 weeks since the incident.
Doing some symbolic action seemed to make sense until the people
finish discussions and votes.
I belive i do not have the authority to hand out real (week+) bans,
nor would i want that authorithy. Also i will stay away
from symbolic bans too, this was intended to improve the situation,
and i belive it did not achive that.


> The current vote will probably go nowhere, so a proper discussion thread
> followed by a vote will have to be made.

Yes,
its up to the vote comittee and the community to decide what should
be done.


> 
> > I suspect carl saw the merges done by derek as causing more bugs than
> > good so he attacked until derek stoped doing the merges.
> 
> Which is the shitty behavior that's being discussed about. When you find
> problems you report them, or help fix them. You don't attack the person
> working on them.
> 
> > The correct course of action would have been a vote about stoping the
> > merges or a change to the procedure to reduce the amount of bugs.
> > Like maybe a seperate branch where merges can be tested for ~24h before
> > being pushed to master ...
> > Or maybe more people working on fixing regressions
> > As a sidenote, most of the regressions should be fixed by now.
> > 
> > 2. ban derek for ~24h from the ML due to causing lukasz to leave the
> > project last year, and due to personal insults on the ML and IRC
> > to lukasz and carl.
> > As derek is not subscribed to the list ATM, this will be implemented
> > by moving him from the accept_these_nonmembers list to the
> > reject_these_nonmembers list for ~24h
> > 
> > 3. ban myself for ~24h from the ML because i wrote offensive mails too
> > years ago and i doubt none was pivotal in causing someone to leave
> 
> And this is silly. It's old history and nobody requested such action in
> any what whatsoever. It will only derail the discussion and again, bans
> without discussion or vote are a big no.

It may be uninportant but the "ban" would never have stoped derek from
subscribing or subsequently posting a message.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH v7] Add experimental support for vp9 in iso-bmff

2016-06-16 Thread Ronald S. Bultje 
Hi,

On Wed, Jun 15, 2016 at 7:22 PM, KongQun Yang  wrote:

>
>
> -- KongQun Yang (KQ)
>
> On Wed, Jun 15, 2016 at 3:08 PM, Ronald S. Bultje 
> wrote:
>
>> Hi,
>>
>> On Wed, Jun 15, 2016 at 4:53 PM, Kongqun Yang 
>> wrote:
>>
>>> Implemented according to the draft specification
>>> "VP Codec ISO Media File Format Binding":
>>>
>>> http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
>>>
>>> '-strict -2' is required to use this feature.
>>>
>>> Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
>>> ---
>>>  libavformat/Makefile |   2 +-
>>>  libavformat/isom.c   |   3 ++
>>>  libavformat/movenc.c |  26 +
>>>  libavformat/vpcc.c   | 148
>>> +++
>>>  libavformat/vpcc.h   |  47 
>>>  5 files changed, 225 insertions(+), 1 deletion(-)
>>>  create mode 100644 libavformat/vpcc.c
>>>  create mode 100644 libavformat/vpcc.h
>>
>>
>> No further comments from me, LGTM but I'd wait a day before push to give
>> others a day to re-review also.
>>
>
> Sure, thanks for reviewing and all the helpful comments! Btw, are you
> going to help commit the change?
>

Yes. (Poke me if I haven't by tomorrow.)

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

[FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers

2016-06-16 Thread Clément Bœsch 
From: Clément Bœsch 

---
Still unsure about the FATE changes.
Also couldn't test pgm vs pgmyuv due to a crash
---
 libavformat/Makefile|  5 +
 libavformat/allformats.c|  5 +
 libavformat/img2dec.c   | 55 +
 tests/ref/seek/lavf-pbmpipe | 50 ++---
 tests/ref/seek/lavf-pgmpipe | 50 ++---
 tests/ref/seek/lavf-ppmpipe | 50 ++---
 6 files changed, 146 insertions(+), 69 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 481f3b1..12d8f6b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -226,9 +226,14 @@ OBJS-$(CONFIG_IMAGE_EXR_PIPE_DEMUXER) += img2dec.o 
img2.o
 OBJS-$(CONFIG_IMAGE_J2K_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER)  += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PAM_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PBM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PGMYUV_PIPE_DEMUXER)  += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PGM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER)  += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER)   += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..d490cc4 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -356,9 +356,14 @@ void av_register_all(void)
 REGISTER_DEMUXER (IMAGE_J2K_PIPE,image_j2k_pipe);
 REGISTER_DEMUXER (IMAGE_JPEG_PIPE,   image_jpeg_pipe);
 REGISTER_DEMUXER (IMAGE_JPEGLS_PIPE, image_jpegls_pipe);
+REGISTER_DEMUXER (IMAGE_PAM_PIPE,image_pam_pipe);
+REGISTER_DEMUXER (IMAGE_PBM_PIPE,image_pbm_pipe);
 REGISTER_DEMUXER (IMAGE_PCX_PIPE,image_pcx_pipe);
+REGISTER_DEMUXER (IMAGE_PGMYUV_PIPE, image_pgmyuv_pipe);
+REGISTER_DEMUXER (IMAGE_PGM_PIPE,image_pgm_pipe);
 REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
 REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
+REGISTER_DEMUXER (IMAGE_PPM_PIPE,image_ppm_pipe);
 REGISTER_DEMUXER (IMAGE_QDRAW_PIPE,  image_qdraw_pipe);
 REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
 REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 1b0e608..9cbc9dc 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -862,6 +862,56 @@ static int webp_probe(AVProbeData *p)
 return 0;
 }
 
+static int pnm_magic_check(const AVProbeData *p, int magic)
+{
+const uint8_t *b = p->buf;
+
+return b[0] == 'P' && b[1] == magic + '0';
+}
+
+static inline int pnm_probe(const AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+while (b[2] == '\r')
+b++;
+if (b[2] == '\n' && (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')))
+return AVPROBE_SCORE_EXTENSION + 2;
+return 0;
+}
+
+static int pbm_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 1) || pnm_magic_check(p, 4) ? pnm_probe(p) : 0;
+}
+
+static inline int pgmx_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 2) || pnm_magic_check(p, 5) ? pnm_probe(p) : 0;
+}
+
+static int pgm_probe(AVProbeData *p)
+{
+int ret = pgmx_probe(p);
+return ret && !av_match_ext(p->filename, "pgmyuv") ? ret : 0;
+}
+
+static int pgmyuv_probe(AVProbeData *p)
+{
+int ret = pgmx_probe(p);
+return ret && av_match_ext(p->filename, "pgmyuv") ? ret : 0;
+}
+
+static int ppm_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 3) || pnm_magic_check(p, 6) ? pnm_probe(p) : 0;
+}
+
+static int pam_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 7) ? pnm_probe(p) : 0;
+}
+
 #define IMAGEAUTO_DEMUXER(imgname, codecid)\
 static const AVClass imgname ## _class = {\
 .class_name = AV_STRINGIFY(imgname) " demuxer",\
@@ -888,9 +938,14 @@ IMAGEAUTO_DEMUXER(exr, AV_CODEC_ID_EXR)
 IMAGEAUTO_DEMUXER(j2k, AV_CODEC_ID_JPEG2000)
 IMAGEAUTO_DEMUXER(jpeg,AV_CODEC_ID_MJPEG)
 IMAGEAUTO_DEMUXER(jpegls,  AV_CODEC_ID_JPEGLS)
+IMAGEAUTO_DEMUXER(pam, AV_CODEC_ID_PAM)
+IMAGEAUTO_DEMUXER(pbm, AV_CODEC_ID_PBM)
 IMAGEAUTO_DEMUXER(pcx, AV_CODEC_ID_PCX)
+IMAGEAUTO_DEMUXER(pgm, AV_CODEC_ID_PGM)
+IMAGEAUTO_DEMUXER(pgmyuv,  AV_CODEC_ID_PGMYUV)
 IMAGEAUTO_DEMUXER(pictor,  AV_CODEC_ID_PICTOR)
 IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG)
+IMAGEAUTO_DEMUXER(ppm, AV_CODEC_ID_PPM)
 IMAGEAUTO_DEMUXER(qdraw,   AV_CODEC_ID_QDRAW)
 IMAGEAUTO_DEMUXER(sgi,

Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi

2016-06-16 Thread Amancio Hasty 

> On May 9, 2016, at 7:55 AM, Amancio Hasty  wrote:
> 
> Hi,
> 
> So what is the next step?
> 
> If you want testers I suggest posting to ccrisan’s motionpie mailing list.
> Cheers
> Amancio
> 
> 
>> On Mar 31, 2016, at 7:27 PM, Amancio Hasty  wrote:
>> 
>> I am not a lawyer…
>> 
>> 
>> I updated the patch.  vc264.c now has a the copyright notice embedded in 
>> a volatile global so if a binary is compiled against vc264.o , the copyright 
>> notice
>> can be displayed by:
>> strings ffmpeg | grep -i copyright
>> 
>> LICENSE.md has been updated to include Broadcom’s copyright notice.
>> 
>> A distribution of a  binary that includes vc264.o should include LICENSE.md 
>> and if 
>> that is missing,  the copyright notice can be displayed via the shell
>> command ‘strings’ .
>> 
>> Amancio
>> 
>>> On Mar 22, 2016, at 12:12 PM, Lou Logan  wrote:
>>> 
>>> On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote:
>>> 
 From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001
 From: Amancio Hasty 
 Date: Mon, 21 Mar 2016 18:56:05 -0700
 Subject: [PATCH] added support for hardware assist H264  video encoding for
 the Raspberry Pi
 
 ---
 configure  |  12 ++
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   2 +
 libavcodec/vc264.c | 387 
 +
 4 files changed, 402 insertions(+)
 create mode 100644 libavcodec/vc264.c
 
>>> [...]
 diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
 index 2a25d66..3c7bd9b 100644
 --- a/libavcodec/allcodecs.c
 +++ b/libavcodec/allcodecs.c
 @@ -74,6 +74,7 @@ void avcodec_register_all(void)
   initialized = 1;
 
>>> 
>>> Nit: Whitespace on the line above should be removed.
>>> 
>>> [...]
 --- /dev/null
 +++ b/libavcodec/vc264.c
 @@ -0,0 +1,387 @@
 +/*  H.264 hardware assist video encoding code taken from
 + * raspberry's os :
 + *   /opt/vc/src/hello_pi/hello_encode/encode.c
 + */
 +
 +/*
 +Copyright (c) 2012, Broadcom Europe Ltd
 +Copyright (c) 2012, Kalle Vahlman 
 +Tuomas Kulve 
 +All rights reserved.
 +
 +Redistribution and use in source and binary forms, with or without
 +modification, are permitted provided that the following conditions are 
 met:
 +* Redistributions of source code must retain the above copyright
 +  notice, this list of conditions and the following disclaimer.
 +  * Redistributions in binary form must reproduce the above copyright
 +  notice, this list of conditions and the following disclaimer in the
 +  documentation and/or other materials provided with the distribution.
 +  * Neither the name of the copyright holder nor the
 +  names of its contributors may be used to endorse or promote products
 +  derived from this software without specific prior written 
 permission.
 +
 +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
 IS" AND
 +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
 IMPLIED
 +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 
 LIABLE FOR ANY
 +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
 SERVICES;
 +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
 AND
 +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
 THIS
 +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>> 
>>> I wonder if any of the above legalese is compatible. Granted, I see a
>>> similar paragraph in "libavformat/aadec.c".
>>> 
 + * ffmpeg driver for hardware assist video H.264 encoding using 
 Broadcom's GPU
 + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com
 + *
 + *
 + * 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

Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer

2016-06-16 Thread Clément Bœsch 
On Fri, Jun 10, 2016 at 04:28:55AM +0200, Michael Niedermayer wrote:
> On Thu, Jun 09, 2016 at 04:35:02PM +0200, Clément Bœsch wrote:
> > On Thu, Jun 09, 2016 at 03:59:30PM +0200, Clément Bœsch wrote:
> > > On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote:
> > > > Clément Bœsch  pkh.me> writes:
> > > > 
> > > > > +if (b[3] == '#')
> > > > > +return AVPROBE_SCORE_EXTENSION + 1;
> > > > > +if (b[3] >= '0' && b[3] <= '9')
> > > > > +return AVPROBE_SCORE_MAX - 1;
> > > > 
> > > > Imo, this should be:
> > > > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9'))
> > > >   return AVPROBE_SCORE_EXTENSION + 2;
> > > > or similar
> > > > 
> > > > I count 37 and 34 bits which is only a little more than 
> > > > the usual 32 bit for EXTENSION + 1.
> > > > 
> > > 
> > > Sure. Changed locally, will push soon, thanks.
> > > 
> > 
> > For some reasons it makes seeking with pgm somehow working. The reference
> > test doesn't look that great IIUC, but seeking in these file with ffplay
> > is fine AFAICT.
> 
> it seems it messes with pgmyuv detection (which i think was filename 
> extension based)
> 
> example:
> ./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt yuv420p16be -vframes 1 test.pgmyuv

> ./ffplay-ref test.pgmyuv
> Input #0, image2, from 'test.pgmyuv':B vq=0KB sq=0B f=0/0
>   Duration: 00:00:00.04, start: 0.00, bitrate: 248835 kb/s
> Stream #0:0: Video: pgmyuv, yuv420p16le, 720x576, 25 tbr, 25 tbn
> 

This currently crashes for me with git/master:

pnm_decode_frame (avctx=, data=0x7fffe8012f40, 
got_frame=0x7fffecbe89cc, avpkt=) at src/libavcodec/pnmdec.c:225
225 v = av_be2ne16(((uint16_t *)s->bytestream)[j]);
(gdb) bt
#0  pnm_decode_frame (avctx=, data=0x7fffe8012f40, 
got_frame=0x7fffecbe89cc, avpkt=) at src/libavcodec/pnmdec.c:225
#1  0x00cde5e8 in avcodec_decode_video2 
(avctx=avctx@entry=0x7fffe8000e00, picture=0x7fffe8012f40, 
got_picture_ptr=got_picture_ptr@entry=0x7fffecbe89cc, 
avpkt=avpkt@entry=0x7fffecbe8ac0) at src/libavcodec/utils.c:2217
#2  0x00cdf1c0 in do_decode (avctx=avctx@entry=0x7fffe8000e00, 
pkt=0x7fffecbe8ac0) at src/libavcodec/utils.c:2727
#3  0x00ce014b in avcodec_send_packet 
(avctx=avctx@entry=0x7fffe8000e00, avpkt=, 
avpkt@entry=0x7fffecbe8ac0)
at src/libavcodec/utils.c:2813
#4  0x00710cf5 in try_decode_frame (s=s@entry=0x7fffe8009240, 
st=st@entry=0x7fffe8007500, avpkt=avpkt@entry=0x7fffecbe8c40, 
options=) at src/libavformat/utils.c:2899
#5  0x007194d4 in avformat_find_stream_info (ic=0x7fffe8009240, 
options=0x7fffe8007880) at src/libavformat/utils.c:3595
#6  0x00487d08 in read_thread (arg=0x70ae9040) at src/ffplay.c:2880
#7  0x7647afe8 in ?? () from /usr/lib/libSDL-1.2.so.0
#8  0x764bc8a9 in ?? () from /usr/lib/libSDL-1.2.so.0
#9  0x76254484 in start_thread () from /usr/lib/libpthread.so.0
#10 0x756436dd in clone () from /usr/lib/libc.so.6

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] bans

2016-06-16 Thread Ivan Kalvachev 
On 6/16/16, James Almer  wrote:
> On 6/15/2016 8:16 PM, Ivan Kalvachev wrote:
>>Loads of crap
>
> No one, and i mean no one reply to this email.
>
> You will not get a single answer to any question you make. All you'll get is
> counter questions. He will make questions he knows the answers for only to
> read the reply in your own words. And once you reply to said questions, your
> answer will be nitpicked expecting you to focus on said comments until the
> conversation is fully derailed.
> Insisting with your questions will be useless.
>
> This is the guy that in a reply to the vote thread said he wasn't aware the
> subject was mentioned in the IRC meeting [1] while in reality he knew well
> about everything and even acknowledged it, as pointed out by Ronald in a
> subsequent email [2].
> He will lie and he will pretend to be unaware of things, be it to not answer
> your questions or to get you to reply his, starting the cycle i mentioned
> above.
>
> This is is a guy that has since day 1 derailed every single conversation and
> tried to put the aggressor as the victim and the victim as the aggressor,
> installing the idea of secret unjustified feuds and invoking old bullshit
> like
> libav's debacle in a perfect godwin's law fashion.
>
> Not a single discussion in IRC where he was involved went anywhere, and
> neither
> will anything in this thread. You'll get inside a spiral of bullshit with no
> end until you decide to stop feeding the troll disguised as worried
> contributor.
>
> [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195306.html
> [2] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195344.html

Too late, you already replied and you have demonstrated practically
the things I've described in the mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavd/v4l2: allow devices not implementing VIDIOC_G_PARM

2016-06-16 Thread Benoit Fouet 

Hi,


On 15/06/2016 17:21, Niklas Söderlund wrote:

Not all v4l2 devices implement the VIDIOC_G_PARM ioctl. This patch allow
ffmpeg to open such device and treat it the same as devices that do
implement the ioctl but returns that it do not implement the
V4L2_CAP_TIMEPERFRAME capability.

Signed-off-by: Niklas Söderlund 
---
  libavdevice/v4l2.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 103fb10..c8915e0 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -715,11 +715,8 @@ static int v4l2_set_parameters(AVFormatContext *ctx)
  streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
  if (v4l2_ioctl(s->fd, VIDIOC_G_PARM, ) < 0) {
  ret = AVERROR(errno);
-av_log(ctx, AV_LOG_ERROR, "ioctl(VIDIOC_G_PARM): %s\n", 
av_err2str(ret));
-return ret;
-}
-
-if (framerate_q.num && framerate_q.den) {
+av_log(ctx, AV_LOG_WARNING, "ioctl(VIDIOC_G_PARM): %s\n", 
av_err2str(ret));
+} else if (framerate_q.num && framerate_q.den) {
  if (streamparm.parm.capture.capability & V4L2_CAP_TIMEPERFRAME) {
  tpf = 
  


LGTM

--
Ben

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

Re: [FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort

2016-06-16 Thread Camille Gonnet 
2016-06-13 23:29 GMT+02:00 Lukasz Marek :

> On 02.06.2016 14:29, Camille Gonnet wrote:
>
>> When writing files to FTP, if the data connection is closed before the
>> control connection, the server may handle it as an aborted file transfer
>> and create and leave the file empty.
>>
>> ---
>>   libavformat/ftp.c | 14 ++
>>   1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
>> index 0663b47..00747bb 100644
>> --- a/libavformat/ftp.c
>> +++ b/libavformat/ftp.c
>> @@ -220,15 +220,21 @@ static int ftp_send_command(FTPContext *s, const
>> char
>> *command,
>>
>>   static void ftp_close_data_connection(FTPContext *s)
>>   {
>> -ffurl_closep(>conn_data);
>> +static const int close_codes[] = {225, 226, 0};
>> +
>> +if (s->conn_data) {
>> +ffurl_closep(>conn_data);
>> +// Need to wait for status, or file transfer might be aborted on
>> server side
>> +ftp_status(s, NULL, close_codes);
>> +}
>>   s->position = 0;
>>   s->state = DISCONNECTED;
>>   }
>>
>
> This is not working. ./ffplay ftp://user:pass@localhost/1.avi hangs at
> startup. It was working for you because (probably) your writing operation
> didn't perform seeking (did you enabled ftp-write-seekable?).
> During seek operation, when seek is really done, ftp_abort is called and
> there is ftp_close_data_connection called with status check followed. So
> status is checked twice while sent by server just once.
>
> I can work it out, but just tell what server has this issue. Perfectly
> setup some account for me. You can of course work it out yourself, but
> please test also other scenarios and other servers.
>
> First thing to check is to revert patch completely and replace
> ftp_close_both_connections by ftp_abort inside ftp_close function.
>
>
You are right and I am sorry: I did not make enough tests.

I do not have much information on the server used, this is a ISP one, not
announced in banner. rstatus replies "211 http://www.pureftpd.org/;, so
looks like Pure-FTP, which is known to have some issues (logged in
ftp_connect_control_connection). But may be those issues are related to the
data connection closing.

Maybe it should be worked out another way: when any command answers a 1yz
code, we know we should wait for another code, as stated in §4.2 (page 37)

1yz   Positive Preliminary reply

The requested action is being initiated; expect another
reply before proceeding with a new command.  (The
user-process sending another command before the
completion reply would be in violation of protocol; but
server-FTP processes should queue any commands that
arrive while a preceding command is in progress.)

(This explains also why some server does not answers to abort while data
connection is opened)


Unfortunately I have no time to go deeper, so do whatever you want with my
suggestions.
I just wanted to help a little and I am sorry not to be able to go further,
but another day, perhaps.



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