Re: [FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining

[Muhammad Faiz]

On Tue, Apr 25, 2017 at 1:57 AM, wm4  wrote:
> This is needed to get compatibility with the behavior before the
> recent decode.c restructuring merge, and fixes fate failures with
> this:
>
>   make fate-h264-attachment-631 THREADS=32
>
> For every 4 threads, a frame is dropped at the point at which
> draining is initialized. The problem starts at THREADS=4.
>
> This patch "fixes" it by ignoring errors during draining (if there
> is a frame to be returned), but there is probably a deeper cause
> and/or a better fix for this. I haven't looked closer at this, but
> was asked to send this patch for discussion.
> ---
>  libavcodec/pthread_frame.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 13d682842d..e7fa503adf 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx,
>  fctx->next_finished = finished;
>
>  /* return the size of the consumed packet if no error occurred */
> -if (err >= 0)
> +if (err >= 0 || (!avpkt->size && *got_picture_ptr))

Probably (*got_picture_ptr && p->result >= 0)
So error is not ignored.


>  err = avpkt->size;
>  finish:
>  async_lock(fctx);
> --
> 2.11.0
>
> ___
> 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] Add support for 's' type gopher URL

[Michael Niedermayer]

On Mon, Apr 24, 2017 at 06:19:13PM +0200, François Revol wrote:
> It's not standard but mentionned on:
> http://en.wikipedia.org/wiki/Gopher_%28protocol%29#Gopher_item_types
> 
> It's used at least on:
> gopher://sdf.org/1/sdf/historical
> (commercial.mp3)
> ---
>  libavformat/gopher.c | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

[...]
-- 
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] [rfc] coc violation tribunal

[Rostislav Pehlivanov]

On 25 April 2017 at 01:26, Aaron Levinson  wrote:

> On 4/24/2017 5:05 PM, Compn wrote:
>
>> as a few developers have wondered...
>>
>> how is our project to judge, report and punish coc violations?
>>
>> since we had a vote to approve of the COC, we will probably need
>> another vote to approve of the COC rules.
>>
>> do you want group consensus?
>> how big of a group? whos in the group?
>> who wants to do a bunch of crapwork telling devs to be nice in the
>> sandbox and stop throwing sand at each other or they'll get a timeout?
>>
>> do you want irc/ml admins to handle it? e.g. lou and me set moderation
>> flags on developers and delete mails that are not development related?
>>
>> who judges the judges?
>>
>> what if we scare off devs who get frustrated that the COC was not fully
>> fairly applied to everyone? e.g. one dev gets moderated while another
>> skates ? thats where the strife gains momentum.
>>
>> thoughts?
>>
>
> I think it would be best to set this aside for now.  I think the reason
> things flared up again is nothing was ever resolved the last time around
> ("Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band
> encoding cost function"), and instead, it just sort of died down.  There
> was such animosity displayed on that thread from specific individuals
> towards other specific individuals.  No one benefits from that, least of
> all the people writing it or the people being targeted.  I know what it is
> like to be in an environment in which co-workers basically hate each other,
> and it isn't pleasant, and I think it is reasonable to consider other
> people on this e-mail list as sort of co-workers.
>
> Perhaps what would be helpful would be to get these individuals together
> on a private IRC channel with someone who perhaps knows both of them to
> neutrally moderate and have them air their differences and ideally come to
> some sort of resolution and move forward.  Its one thing to fire off an
> e-mail--its another to say things to someone's "face", so to speak.
>
> I'd also suggest, when passions are up, to step aside and then maybe come
> back to it later.
>
>
Yeah, that's a good idea, especially the stepping aside bit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Ignore expired cookies

[Micah Galizia]

On 2017-04-08 09:05 PM, Micah Galizia wrote:



Is there something I can do to get this reviewed?

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

Re: [FFmpeg-devel] [rfc] coc violation tribunal

[Aaron Levinson]

On 4/24/2017 5:05 PM, Compn wrote:

as a few developers have wondered...

how is our project to judge, report and punish coc violations?

since we had a vote to approve of the COC, we will probably need
another vote to approve of the COC rules.

do you want group consensus?
how big of a group? whos in the group?
who wants to do a bunch of crapwork telling devs to be nice in the
sandbox and stop throwing sand at each other or they'll get a timeout?

do you want irc/ml admins to handle it? e.g. lou and me set moderation
flags on developers and delete mails that are not development related?

who judges the judges?

what if we scare off devs who get frustrated that the COC was not fully
fairly applied to everyone? e.g. one dev gets moderated while another
skates ? thats where the strife gains momentum.

thoughts?


I think it would be best to set this aside for now.  I think the reason 
things flared up again is nothing was ever resolved the last time around 
("Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band 
encoding cost function"), and instead, it just sort of died down.  There 
was such animosity displayed on that thread from specific individuals 
towards other specific individuals.  No one benefits from that, least of 
all the people writing it or the people being targeted.  I know what it 
is like to be in an environment in which co-workers basically hate each 
other, and it isn't pleasant, and I think it is reasonable to consider 
other people on this e-mail list as sort of co-workers.


Perhaps what would be helpful would be to get these individuals together 
on a private IRC channel with someone who perhaps knows both of them to 
neutrally moderate and have them air their differences and ideally come 
to some sort of resolution and move forward.  Its one thing to fire off 
an e-mail--its another to say things to someone's "face", so to speak.


I'd also suggest, when passions are up, to step aside and then maybe 
come back to it later.


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

[FFmpeg-devel] [rfc] coc violation tribunal

[Compn]

as a few developers have wondered...

how is our project to judge, report and punish coc violations?

since we had a vote to approve of the COC, we will probably need
another vote to approve of the COC rules.

do you want group consensus?
how big of a group? whos in the group?
who wants to do a bunch of crapwork telling devs to be nice in the
sandbox and stop throwing sand at each other or they'll get a timeout?

do you want irc/ml admins to handle it? e.g. lou and me set moderation
flags on developers and delete mails that are not development related?

who judges the judges?

what if we scare off devs who get frustrated that the COC was not fully
fairly applied to everyone? e.g. one dev gets moderated while another
skates ? thats where the strife gains momentum.

thoughts?

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

Re: [FFmpeg-devel] [PATCH] webm_dash_manifest_demuxer: Fix UB in cue timestamp string code and make it actually work

[Vignesh Venkatasubramanian]

On Thu, Apr 20, 2017 at 7:02 AM, Derek Buitenhuis
 wrote:
> The original author apparently never read the documentation for snprintf,
> or even tested that the output was correct.

I was the original author and i am sorry about the mistake.

> Passing overlapping memory
> to snprintf causes undefined behavior, and usually resulted in only the
> very last timestamp being written to metadata, and not a list at all.
>
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/matroskadec.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 9adca8d..320d8bf 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3823,6 +3823,7 @@ static int webm_dash_manifest_cues(AVFormatContext *s)
>  char *buf;
>  int64_t cues_start = -1, cues_end = -1, before_pos, bandwidth;
>  int i;
> +int end = 0;
>
>  // determine cues start and end positions
>  for (i = 0; i < seekhead_list->nb_elem; i++)
> @@ -3868,10 +3869,17 @@ static int webm_dash_manifest_cues(AVFormatContext *s)
>  if (!buf) return -1;
>  strcpy(buf, "");
>  for (i = 0; i < s->streams[0]->nb_index_entries; i++) {
> -snprintf(buf, (i + 1) * 20 * sizeof(char),
> - "%s%" PRId64, buf, 
> s->streams[0]->index_entries[i].timestamp);
> -if (i != s->streams[0]->nb_index_entries - 1)
> +int ret = snprintf(buf + end, 20 * sizeof(char),
> +   "%" PRId64, 
> s->streams[0]->index_entries[i].timestamp);
> +if (ret <= 0 || (ret == 20 && i ==  s->streams[0]->nb_index_entries 
> - 1)) {

Given that you are trying to fix an issue here, can you please add a
comment as to what this if condition is doing? (why ret == 20 for
example). But up to you though.

> +av_log(s, AV_LOG_ERROR, "timestamp too long.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +end += ret;
> +if (i != s->streams[0]->nb_index_entries - 1) {
>  strncat(buf, ",", sizeof(char));
> +end++;
> +}
>  }
>  av_dict_set(>streams[0]->metadata, CUE_TIMESTAMPS, buf, 0);
>  av_free(buf);
> --
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Compn]

i apologize in advance for replying to this email and not carls, but
be assured i am replying to both carl and wm4 here.

On Mon, 24 Apr 2017 19:13:32 +0200, wm4  wrote:
> On Mon, 24 Apr 2017 16:00:41 +0200
> Carl Eugen Hoyos  wrote:
> > 2017-04-24 15:38 GMT+02:00 wm4 :
> > > On Mon, 24 Apr 2017 15:23:20 +0200
> > > Carl Eugen Hoyos  wrote:
> > >> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :  
> > >> > On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:
> > >> >> On Mon, 24 Apr 2017 10:46:38 +0200
> > >> >> Carl Eugen Hoyos  wrote:  
> > >> >> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :  
> > >> >> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:  
> > >> >> > >>
> > >> >> > >> Should changes ported from libav (what we call merges) be
> > >> >> > >> reviewed before being pushed?  
> > >> >> > >
> > But if the regressions remain unfixed, it is a little surprising
> > to speak about "no major issues", don't you agree?
> 
> Which regressions? You claim they exist, yet you never mention any of
> those by name. Maybe you're lying, joking, having problems due to
> English not being your native language like you often mention, etc.?

guys... maybe just ... less words and post more trac urls.



> Now most/all distros have switched from Libav to FFmpeg. Do you see
> Libav being forced to merge FFmpeg API? No? then why was FFmpeg
> "forced" to do it?
> 
> I'd really like to know your thoughts about this (we all know they are
> free of lies and jokes, no worries).

wm4 and carl, can you maybe take this conversation and write
libav/ffmpeg history up somewhere else? no one here cares to read 6
year old history again on ffmpeg-devel.

seriously, please. not here. not again. NO ONE WANTS TO READ THIS.
no one cares who is right carl or wm4. fight elsewhere. not here.


> Well, and I find your personal issues with the Libav project odd, to
> say the least.

personal issues arent ffmpeg-devel technical discussions, please take
this private off list. please oh please. both carl and wm4 please.

> > > Frankly you're on the level of an aggressive troll, and always have
> > > been when it came to things related to Libav.  

calling people names like troll probably not good idea in professional
environment. also maybe CoC violation.


> Let me make this clear: we WILL be friendly with the Libav project. We
> WILL work towards reunification with it. We WILL work towards reducing
> conflict with it. We WILL make an effort to reach these goals. The past
> does not matter, there was shit on both sides. Please remove the shit
> still remaining on one of the sides.

mostly positive. although i wonder what is being called shit here
though. but i will wonder off-list.

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

Re: [FFmpeg-devel] [PATCH] webm_dash_manifest_demuxer: Fix initialization range for files with cues at the front

[Vignesh Venkatasubramanian]

On Fri, Apr 21, 2017 at 8:40 AM, Derek Buitenhuis
 wrote:
> The WebM DASH spec states:
> The Initialization Segment shall not contain Clusters or Cues.
> The Segment Index corresponds to the Cues.
>
> Previously, it included the cues if they were at the front.

Looks good. Thanks.

>
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/matroskadec.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 9adca8d..b3f68d3 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3815,7 +3815,7 @@ static int64_t 
> webm_dash_manifest_compute_bandwidth(AVFormatContext *s, int64_t
>  return (int64_t)bandwidth;
>  }
>
> -static int webm_dash_manifest_cues(AVFormatContext *s)
> +static int webm_dash_manifest_cues(AVFormatContext *s, int64_t init_range)
>  {
>  MatroskaDemuxContext *matroska = s->priv_data;
>  EbmlList *seekhead_list = >seekhead;
> @@ -3854,6 +3854,11 @@ static int webm_dash_manifest_cues(AVFormatContext *s)
>  // cues end
>  av_dict_set_int(>streams[0]->metadata, CUES_END, cues_end, 0);
>
> +// if the file has cues at the start, fix up the init range so tht

*that

> +// it does not include it
> +if (cues_start <= init_range)
> +av_dict_set_int(>streams[0]->metadata, INITIALIZATION_RANGE, 
> cues_start - 1, 0);
> +
>  // bandwidth
>  bandwidth = webm_dash_manifest_compute_bandwidth(s, cues_start);
>  if (bandwidth < 0) return -1;
> @@ -3883,6 +3888,7 @@ static int 
> webm_dash_manifest_read_header(AVFormatContext *s)
>  {
>  char *buf;
>  int ret = matroska_read_header(s);
> +int64_t init_range;
>  MatroskaTrack *tracks;
>  MatroskaDemuxContext *matroska = s->priv_data;
>  if (ret) {
> @@ -3903,7 +3909,8 @@ static int 
> webm_dash_manifest_read_header(AVFormatContext *s)
>
>  // initialization range
>  // 5 is the offset of Cluster ID.
> -av_dict_set_int(>streams[0]->metadata, INITIALIZATION_RANGE, 
> avio_tell(s->pb) - 5, 0);
> +init_range = avio_tell(s->pb) - 5;
> +av_dict_set_int(>streams[0]->metadata, INITIALIZATION_RANGE, 
> init_range, 0);
>  }
>
>  // basename of the file
> @@ -3916,7 +3923,7 @@ static int 
> webm_dash_manifest_read_header(AVFormatContext *s)
>
>  // parse the cues and populate Cue related fields
>  if (!matroska->is_live) {
> -ret = webm_dash_manifest_cues(s);
> +ret = webm_dash_manifest_cues(s, init_range);
>  if (ret < 0) {
>  av_log(s, AV_LOG_ERROR, "Error parsing Cues\n");
>  return ret;
> --
> 1.8.3.1
>



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

[FFmpeg-devel] [PATCH 2/2] avcodec/options: do a more thorough clean up in avcodec_copy_context()

[James Almer]

Free coded_frame, coded_side_data and unref hw_device_ctx to prevent
potential leaks.

Signed-off-by: James Almer 
---
 libavcodec/options.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavcodec/options.c b/libavcodec/options.c
index b98da9378a..82e12179a6 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -190,14 +190,26 @@ void avcodec_free_context(AVCodecContext **pavctx)
 #if FF_API_COPY_CONTEXT
 static void copy_context_reset(AVCodecContext *avctx)
 {
+int i;
+
 av_opt_free(avctx);
+#if FF_API_CODED_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+av_frame_free(>coded_frame);
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 av_freep(>rc_override);
 av_freep(>intra_matrix);
 av_freep(>inter_matrix);
 av_freep(>extradata);
 av_freep(>subtitle_header);
 av_buffer_unref(>hw_frames_ctx);
+av_buffer_unref(>hw_device_ctx);
+for (i = 0; i < avctx->nb_coded_side_data; i++)
+av_freep(>coded_side_data[i].data);
+av_freep(>coded_side_data);
 avctx->subtitle_header_size = 0;
+avctx->nb_coded_side_data = 0;
 avctx->extradata_size = 0;
 }
 
@@ -238,11 +250,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 /* reallocate values that should be allocated separately */
 dest->extradata   = NULL;
+dest->coded_side_data = NULL;
 dest->intra_matrix= NULL;
 dest->inter_matrix= NULL;
 dest->rc_override = NULL;
 dest->subtitle_header = NULL;
 dest->hw_frames_ctx   = NULL;
+dest->hw_device_ctx   = NULL;
+dest->nb_coded_side_data = 0;
 
 #define alloc_and_copy_or_fail(obj, size, pad) \
 if (src->obj && size > 0) { \
-- 
2.12.1

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

[FFmpeg-devel] [PATCH v2 1/2] avcodec/options: factorize avcodec_copy_context() cleanup code

[James Almer]

Signed-off-by: James Almer 
---
No changes since last version.

 libavcodec/options.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/libavcodec/options.c b/libavcodec/options.c
index 7bdb0be5af..b98da9378a 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -188,6 +188,19 @@ void avcodec_free_context(AVCodecContext **pavctx)
 }
 
 #if FF_API_COPY_CONTEXT
+static void copy_context_reset(AVCodecContext *avctx)
+{
+av_opt_free(avctx);
+av_freep(>rc_override);
+av_freep(>intra_matrix);
+av_freep(>inter_matrix);
+av_freep(>extradata);
+av_freep(>subtitle_header);
+av_buffer_unref(>hw_frames_ctx);
+avctx->subtitle_header_size = 0;
+avctx->extradata_size = 0;
+}
+
 int avcodec_copy_context(AVCodecContext *dest, const AVCodecContext *src)
 {
 const AVCodec *orig_codec = dest->codec;
@@ -200,12 +213,7 @@ int avcodec_copy_context(AVCodecContext *dest, const 
AVCodecContext *src)
 return AVERROR(EINVAL);
 }
 
-av_opt_free(dest);
-av_freep(>rc_override);
-av_freep(>intra_matrix);
-av_freep(>inter_matrix);
-av_freep(>extradata);
-av_freep(>subtitle_header);
+copy_context_reset(dest);
 
 memcpy(dest, src, sizeof(*dest));
 av_opt_copy(dest, src);
@@ -264,15 +272,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return 0;
 
 fail:
-av_freep(>subtitle_header);
-av_freep(>rc_override);
-av_freep(>intra_matrix);
-av_freep(>inter_matrix);
-av_freep(>extradata);
-av_buffer_unref(>hw_frames_ctx);
-dest->subtitle_header_size = 0;
-dest->extradata_size = 0;
-av_opt_free(dest);
+copy_context_reset(dest);
 return AVERROR(ENOMEM);
 }
 #endif
-- 
2.12.1

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/options: copy the coded_side_data in avcodec_copy_context()

[James Almer]

On 4/23/2017 8:27 PM, Aaron Levinson wrote:
> On 4/22/2017 10:26 AM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/options.c | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/libavcodec/options.c b/libavcodec/options.c
>> index b98da9378a..c721aa8d43 100644
>> --- a/libavcodec/options.c
>> +++ b/libavcodec/options.c
>> @@ -190,15 +190,21 @@ void avcodec_free_context(AVCodecContext **pavctx)
>>  #if FF_API_COPY_CONTEXT
>>  static void copy_context_reset(AVCodecContext *avctx)
>>  {
>> +int i;
>> +
>>  av_opt_free(avctx);
>>  av_freep(>rc_override);
>>  av_freep(>intra_matrix);
>>  av_freep(>inter_matrix);
>>  av_freep(>extradata);
>>  av_freep(>subtitle_header);
>> +for (i = 0; i < avctx->nb_coded_side_data; i++)
>> +av_freep(>coded_side_data[i].data);
>> +av_freep(>coded_side_data);
>>  av_buffer_unref(>hw_frames_ctx);
>>  avctx->subtitle_header_size = 0;
>>  avctx->extradata_size = 0;
>> +avctx->nb_coded_side_data = 0;
>>  }
>>
>>  int avcodec_copy_context(AVCodecContext *dest, const AVCodecContext
>> *src)
>> @@ -262,6 +268,28 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  alloc_and_copy_or_fail(subtitle_header,
>> src->subtitle_header_size, 1);
>>  av_assert0(dest->subtitle_header_size == src->subtitle_header_size);
>>  #undef alloc_and_copy_or_fail
>> +if (src->nb_coded_side_data) {
>> +int i;
>> +
>> +dest->nb_coded_side_data = 0;
>> +dest->coded_side_data = av_realloc_array(NULL,
>> src->nb_coded_side_data,
>> +
>> sizeof(*dest->coded_side_data));
>> +if (!dest->coded_side_data)
>> +goto fail;
>> +
>> +for (i = 0; i < src->nb_coded_side_data; i++) {
>> +const AVPacketSideData *sd_src = >coded_side_data[i];
>> +AVPacketSideData *sd_dst = >coded_side_data[i];
>> +
>> +sd_dst->data = av_malloc(sd_src->size);
>> +if (!sd_dst->data)
>> +goto fail;
>> +memcpy(sd_dst->data, sd_src->data, sd_src->size);
>> +sd_dst->size = sd_src->size;
>> +sd_dst->type = sd_src->type;
>> +dest->nb_coded_side_data++;
>> +}
>> +}
>>
>>  if (src->hw_frames_ctx) {
>>  dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
>>
> 
> If src has coded_side_data and nb_coded_side_data set to non-zero
> values, as a result of the earlier call to memcpy(), it will copy those
> values into dest.  Then, if it does a goto to fail early, as a result of
> your changes to copy_context_reset(), it will call av_freep() on those
> elements in dest, even though they are owned by src.  After doing the
> memcpy() call, I think you can fix this by setting dest->coded_side_data
> to NULL and dest->nb_coded_side_data to 0.

Good catch, will send a new version of the set.

> 
> Everything else looks good.
> 
> Aaron Levinson
> ___
> 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] movenc/isom: update vpcC box to the latest draft specification

[James Almer]

On 4/24/2017 6:48 PM, KongQun Yang wrote:
> -- KongQun Yang (KQ)
> 
> On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes 
> wrote:
> 
>> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes 
>> wrote:
>>> This brings our generation of the vpcC box up to date to version 1.0
>>> of the VP Codec ISO Media File Format Binding.
>>>
>>> Specifically, color/transfer properties are now written with values
>>> based on ISO/IEC 23001-8, which is the same reference specification the
>>> AVColor* enumerations are based on.
>>> ---
>>>  libavformat/movenc.c |  3 ++-
>>>  libavformat/vpcc.c   | 55 +-
>> --
>>>  2 files changed, 7 insertions(+), 51 deletions(-)
>>>
>>
>> Actually I should probably update the main commit message to mention
>> that its v1.0 and not a draft any longer?
>>
> 
> SGTM. Should we remove the experimental check as well:
> https://github.com/FFmpeg/FFmpeg/blob/b905ba5bc18c89c7fccd862179575562ef19/libavformat/movenc.c#L5989
> ?

IMO yes, assuming the vpcc boxes generated after this patch are 100%
v1.0 compliant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification

[KongQun Yang]

-- KongQun Yang (KQ)

On Fri, Apr 21, 2017 at 4:49 PM, Hendrik Leppkes 
wrote:

> On Sat, Apr 22, 2017 at 1:25 AM, Hendrik Leppkes 
> wrote:
> > This brings our generation of the vpcC box up to date to version 1.0
> > of the VP Codec ISO Media File Format Binding.
> >
> > Specifically, color/transfer properties are now written with values
> > based on ISO/IEC 23001-8, which is the same reference specification the
> > AVColor* enumerations are based on.
> > ---
> >  libavformat/movenc.c |  3 ++-
> >  libavformat/vpcc.c   | 55 +-
> --
> >  2 files changed, 7 insertions(+), 51 deletions(-)
> >
>
> Actually I should probably update the main commit message to mention
> that its v1.0 and not a draft any longer?
>

SGTM. Should we remove the experimental check as well:
https://github.com/FFmpeg/FFmpeg/blob/b905ba5bc18c89c7fccd862179575562ef19/libavformat/movenc.c#L5989
?


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

Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter

[Paul B Mahol]

On 4/24/17, Dave Rice  wrote:
>
>> On Apr 24, 2017, at 4:47 PM, Paul B Mahol  wrote:
>>
>> On 4/24/17, Dave Rice  wrote:
>>>
>>> I tested this filter and find it very useful, but could it be adjusted to
>>> handle full range video. Currently when I test with a sample such as:
>>>
>>> ./ffplay -f lavfi -i
>>> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
>>>
>>> The outputs list Y=235, U=240, V=16.
>>
>> Hmm, I cannot reproduce this with my old ffplay build or latest mpv or
>> latest ffmpeg.
>>
>> So it must be ffplay issue.
>
> Can you recreate it with:
>
> ./ffmpeg -f lavfi -i
> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope -f
> nut - | mpv -

No.

Neither with:

./ffmpeg -f lavfi -i
color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
-f nut -c:v rawvideo - | mpv -

or:

mpv 
avdevice://lavfi:color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter

[Dave Rice]

> On Apr 24, 2017, at 4:47 PM, Paul B Mahol  wrote:
> 
> On 4/24/17, Dave Rice  wrote:
>> 
>> I tested this filter and find it very useful, but could it be adjusted to
>> handle full range video. Currently when I test with a sample such as:
>> 
>> ./ffplay -f lavfi -i
>> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
>> 
>> The outputs list Y=235, U=240, V=16.
> 
> Hmm, I cannot reproduce this with my old ffplay build or latest mpv or
> latest ffmpeg.
> 
> So it must be ffplay issue.

Can you recreate it with:

./ffmpeg -f lavfi -i 
color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope -f nut 
- | mpv -

Dave

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

Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter

[Paul B Mahol]

On 4/24/17, Dave Rice  wrote:
>
> I tested this filter and find it very useful, but could it be adjusted to
> handle full range video. Currently when I test with a sample such as:
>
> ./ffplay -f lavfi -i
> color=c=white:s=640x480,format=yuv444p,lutyuv=y=255:u=248:v=10,pixscope
>
> The outputs list Y=235, U=240, V=16.

Hmm, I cannot reproduce this with my old ffplay build or latest mpv or
latest ffmpeg.

So it must be ffplay issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Make tools/target_dec_*_fuzzer buildable with configure and make

[Michael Niedermayer]

On Sat, Apr 22, 2017 at 02:23:08AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  Makefile  |  4 
>  configure | 12 
>  tools/Makefile| 10 ++
>  tools/target_dec_fuzzer.c | 12 
>  4 files changed, 34 insertions(+), 4 deletions(-)

applied

[...]
-- 
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

[FFmpeg-devel] [PATCH] NVENC Surface Allocation Reduction

[Ben Chang]

[sorry for re-sending; but still looking for review. Thanks!]


Hi,



This patch aims to reduce the number of input/output surfaces NVENC allocates 
per session. Previous default sets allocated surfaces to 32 (unless there is 
user specified param or lookahead involved). Having large number of surfaces 
consumes extra video memory (esp for higher resolution encoding), and perf 
return saturates at a certain point. The patch changes the surfaces calculation 
for default, B-frames, lookahead scenario respectively.



The other change involves surface selection. Previously, if a session allocates 
x surfaces, only x-1 surfaces are used (due to combination of output delay and 
lock toggle logic). To prevent unused surfaces, changing surface rotation to 
using predefined fifo.



Testing done:

-Ensure the above changes have no perf impact and does not change bitstream



Thanks,

Ben


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
Marton Balint  wrote:

> On Mon, 24 Apr 2017, Michael Niedermayer wrote:
> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:  
> 
> >> We have recently been able to go through six hundred or so commits in a
> >> month or two this way after being stuck for the longest time by a few of
> >> those big API changes. If we start requiring every commit to go through
> >> a review process on the ML then we will never catch up with the backlog.
> >> In short, things as they are right now are smooth. Changing it will only
> >> make this slower.  
> >
> > Maybe, but is merging more faster also better for FFmpeg ?
> > I did not analyze the bugs on our bug tracker but subjectivly the
> > number of regressions seems much larger than a year or 2 ago.
> > and i just yesterday found 2 issues in a merge (which you fixed)
> >  
> 
> Yeah, I also have two I recently came across, both caused by the delayed 
> filter initialization patch:
> 
> https://trac.ffmpeg.org/ticket/6323
> https://trac.ffmpeg.org/ticket/6318
> 
> Maybe someone more familiar with ffmpeg.c code can take a look?

Currently I'm overworked, I can take a look later if you remind me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 16:19:00 -0300
James Almer  wrote:

> On 4/24/2017 4:08 PM, wm4 wrote:
> > On Mon, 24 Apr 2017 20:27:45 +0200
> > Michael Niedermayer  wrote:
> >   
> >> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:  
> >>> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
>  Hi all
> 
>  Should changes ported from libav (what we call merges) be reviewed
>  before being pushed?
> >>>
> >>> The lot of merges are simple things like "Fix this bug that was already
> >>> fixed in ffmpeg months ago", "K", etc. Lately we are even no-oping a
> >>> good amount of them as they don't even apply.
> >>  
> >>> Only a small set of merges are big API changes, and those are always
> >>> handled by more than one developer, either by reviewing the changes,
> >>> testing them or by helping getting the thing working. And of course, any
> >>> bug that was not caught before pushing is fixed afterwards.
> >>> In fact, it should be noted that if they are initially skipped for
> >>> requiring more thought and for blocking unrelated merges, when we get
> >>> them working at a latter point we always send them to the ML instead of
> >>> simply pushing them.
> >>
> >> yes
> >>
> >> could you send more changes to the ML instead of just ones
> >> initially skiped ? (and of course i dont mean trivial / clearly correct
> >> stuff)
> >>
> >> More eyes may catch more issues also i belive its important that we
> >> all see the changes being done, we all have to maintain the code
> >> which interacts with these changes.  
> > 
> > Sorry, from you I've mostly seen weird command lines failing (and the
> > devs had to find out themselves whether they were legitimate failures).
> > From "eyes catching issues" I'd expect something more concrete, like
> > pointing out errors in the code or fixing them.  
> 
> I agree that pointing out where's the error would be helpful, especially
> if doing so can confirm if it's a legitimate failure or not, but
> detailing a way to reproduce a bug is valid report, especially now that
> he's linking to the failing samples after you complained about it.

A bug is a bug, and bugs should be fixed. So far we agree.

But I think anyone finding a bug and being a developer should at least
do some basic analysis. Apparently that's a weird expectation from me,
not shared by others.

Yes, I appreciate that he posts links to the samples now.

> >   
> >>
> >> [...]
> >>  
> >>> We have recently been able to go through six hundred or so commits in a
> >>> month or two this way after being stuck for the longest time by a few of
> >>> those big API changes. If we start requiring every commit to go through
> >>> a review process on the ML then we will never catch up with the backlog.
> >>> In short, things as they are right now are smooth. Changing it will only
> >>> make this slower.
> >>
> >> Maybe, but is merging more faster also better for FFmpeg ?  
> > 
> > Oh come on, the merge backlog we had almost meant that we were giving
> > up on merging, causing huge problems to various people (including
> > myself).
> >   
> >> I did not analyze the bugs on our bug tracker but subjectivly the
> >> number of regressions seems much larger than a year or 2 ago.  
> > 
> > Because you're not doing the merges yourself anymore, which means that
> > things you test might result in a regression? When you were doing the
> > merges, you probably did this before you merged, meaning you'd of
> > course not find as many regressions after the merge.
> > 
> > Now that's what I call bias.  
> 
> No, regressions Michael finds are rarely if ever reported to trac. He
> instead pokes the merger on IRC or sends an email to the ml.
> Trac gets mostly regression reports from library or CLI users.
> 
> Don't go accusing so lightly of bias...

I think you misunderstood what I was trying to say.

Michael does his own tests, that tend to find issues others don't
find. (Some have joking called this Michael-fate, because he finds
the weirdest issues as if he had a private FATE variant somewhere.)

When Michael merged, he did his tests before he pushed the merge
commit, and of course he fixed them all before pushing. And of course
he didn't find many new issues after the merge, because he was out of
things to test.

Now other peoples merge, and Michael randomly tests FFmpeg, whether
it's on a temporary merge-tree, or after the merge commit was pushed,
so of course he finds a bunch of issues. And of course he's finding
unfixed issues this way, _especially_ if the merge commit has already
been pushed to git.

So he _might_ have some systematic bias in his perception here. It's a
bias because other mergers could be seeing the opposite. They're likely
to test cases they care about before they push their merges, so they
won't see many regressions for their own use cases, while Michael's
merges might have had more regressions from their perspective because
Michael 

Re: [FFmpeg-devel] [PATCH] avfilter: add pixscope filter

[Dave Rice]

> On Apr 22, 2017, at 4:29 PM, Paul B Mahol  wrote:
> 
> Signed-off-by: Paul B Mahol 
> ---
> libavfilter/Makefile   |   1 +
> libavfilter/allfilters.c   |   1 +
> libavfilter/vf_datascope.c | 218 +++--
> 3 files changed, 213 insertions(+), 7 deletions(-)
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 50c5132..feb1404 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -244,6 +244,7 @@ OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
> OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
> OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
> OBJS-$(CONFIG_PIXDESCTEST_FILTER)+= vf_pixdesctest.o
> +OBJS-$(CONFIG_PIXSCOPE_FILTER)   += vf_datascope.o
> OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
> OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
> OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index f482adb..262f14b 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -254,6 +254,7 @@ static void register_all(void)
> REGISTER_FILTER(PERSPECTIVE,perspective,vf);
> REGISTER_FILTER(PHASE,  phase,  vf);
> REGISTER_FILTER(PIXDESCTEST,pixdesctest,vf);
> +REGISTER_FILTER(PIXSCOPE,   pixscope,   vf);
> REGISTER_FILTER(PP, pp, vf);
> REGISTER_FILTER(PP7,pp7,vf);
> REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
> diff --git a/libavfilter/vf_datascope.c b/libavfilter/vf_datascope.c
> index 01a5d99..057a503 100644
> --- a/libavfilter/vf_datascope.c
> +++ b/libavfilter/vf_datascope.c
> @@ -76,7 +76,7 @@ static int query_formats(AVFilterContext *ctx)
> return ff_set_common_formats(ctx, ff_draw_supported_pixel_formats(0));
> }
> 
> -static void draw_text(DatascopeContext *s, AVFrame *frame, FFDrawColor 
> *color,
> +static void draw_text(FFDrawContext *draw, AVFrame *frame, FFDrawColor 
> *color,
>   int x0, int y0, const uint8_t *text, int vertical)
> {
> int x = x0;
> @@ -87,7 +87,7 @@ static void draw_text(DatascopeContext *s, AVFrame *frame, 
> FFDrawColor *color,
> y0 += 8;
> continue;
> }
> -ff_blend_mask(>draw, color, frame->data, frame->linesize,
> +ff_blend_mask(draw, color, frame->data, frame->linesize,
>   frame->width, frame->height,
>   avpriv_cga_font + *text * 8, 1, 8, 8, 0, 0, x, y0);
> if (vertical) {
> @@ -201,7 +201,7 @@ static int filter_color2(AVFilterContext *ctx, void *arg, 
> int jobnr, int nb_jobs
> char text[256];
> 
> snprintf(text, sizeof(text), format[C>>2], value[p]);
> -draw_text(s, out, , xoff + x * C * 10 + 2, yoff + y 
> * P * 12 + p * 10 + 2, text, 0);
> +draw_text(>draw, out, , xoff + x * C * 10 + 2, 
> yoff + y * P * 12 + p * 10 + 2, text, 0);
> }
> }
> }
> @@ -239,7 +239,7 @@ static int filter_color(AVFilterContext *ctx, void *arg, 
> int jobnr, int nb_jobs)
> char text[256];
> 
> snprintf(text, sizeof(text), format[C>>2], value[p]);
> -draw_text(s, out, , xoff + x * C * 10 + 2, yoff + y * 
> P * 12 + p * 10 + 2, text, 0);
> +draw_text(>draw, out, , xoff + x * C * 10 + 2, yoff 
> + y * P * 12 + p * 10 + 2, text, 0);
> }
> }
> }
> @@ -276,7 +276,7 @@ static int filter_mono(AVFilterContext *ctx, void *arg, 
> int jobnr, int nb_jobs)
> char text[256];
> 
> snprintf(text, sizeof(text), format[C>>2], value[p]);
> -draw_text(s, out, >white, xoff + x * C * 10 + 2, yoff + y 
> * P * 12 + p * 10 + 2, text, 0);
> +draw_text(>draw, out, >white, xoff + x * C * 10 + 2, 
> yoff + y * P * 12 + p * 10 + 2, text, 0);
> }
> }
> }
> @@ -328,7 +328,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> ff_fill_rectangle(>draw, >gray, out->data, out->linesize,
>   0, xmaxlen + y * P * 12 + (P + 1) * P - 2, 
> ymaxlen, 10);
> 
> -draw_text(s, out, >yellow, 2, xmaxlen + y * P * 12 + (P + 1) 
> * P, text, 0);
> +draw_text(>draw, out, >yellow, 2, xmaxlen + y * P * 12 + 
> (P + 1) * P, text, 0);
> }
> 
> for (x = 0; x < X; x++) {
> @@ -337,7 +337,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> ff_fill_rectangle(>draw, >gray, out->data, out->linesize,
>   ymaxlen + x * C * 10 + 2 * C - 2, 0, 10, 
> xmaxlen);
> 
> -draw_text(s, out, >yellow, ymaxlen + x * C * 10 + 2 * C, 2, 
> text, 1);
> +draw_text(>draw, out, >yellow, ymaxlen + x 

Re: [FFmpeg-devel] [RFC] Reviewing merges

[James Almer]

On 4/24/2017 4:08 PM, wm4 wrote:
> On Mon, 24 Apr 2017 20:27:45 +0200
> Michael Niedermayer  wrote:
> 
>> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
>>> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:  
 Hi all

 Should changes ported from libav (what we call merges) be reviewed
 before being pushed?  
>>>
>>> The lot of merges are simple things like "Fix this bug that was already
>>> fixed in ffmpeg months ago", "K", etc. Lately we are even no-oping a
>>> good amount of them as they don't even apply.  
>>
>>> Only a small set of merges are big API changes, and those are always
>>> handled by more than one developer, either by reviewing the changes,
>>> testing them or by helping getting the thing working. And of course, any
>>> bug that was not caught before pushing is fixed afterwards.
>>> In fact, it should be noted that if they are initially skipped for
>>> requiring more thought and for blocking unrelated merges, when we get
>>> them working at a latter point we always send them to the ML instead of
>>> simply pushing them.  
>>
>> yes
>>
>> could you send more changes to the ML instead of just ones
>> initially skiped ? (and of course i dont mean trivial / clearly correct
>> stuff)
>>
>> More eyes may catch more issues also i belive its important that we
>> all see the changes being done, we all have to maintain the code
>> which interacts with these changes.
> 
> Sorry, from you I've mostly seen weird command lines failing (and the
> devs had to find out themselves whether they were legitimate failures).
> From "eyes catching issues" I'd expect something more concrete, like
> pointing out errors in the code or fixing them.

I agree that pointing out where's the error would be helpful, especially
if doing so can confirm if it's a legitimate failure or not, but
detailing a way to reproduce a bug is valid report, especially now that
he's linking to the failing samples after you complained about it.

> 
>>
>> [...]
>>
>>> We have recently been able to go through six hundred or so commits in a
>>> month or two this way after being stuck for the longest time by a few of
>>> those big API changes. If we start requiring every commit to go through
>>> a review process on the ML then we will never catch up with the backlog.
>>> In short, things as they are right now are smooth. Changing it will only
>>> make this slower.  
>>
>> Maybe, but is merging more faster also better for FFmpeg ?
> 
> Oh come on, the merge backlog we had almost meant that we were giving
> up on merging, causing huge problems to various people (including
> myself).
> 
>> I did not analyze the bugs on our bug tracker but subjectivly the
>> number of regressions seems much larger than a year or 2 ago.
> 
> Because you're not doing the merges yourself anymore, which means that
> things you test might result in a regression? When you were doing the
> merges, you probably did this before you merged, meaning you'd of
> course not find as many regressions after the merge.
> 
> Now that's what I call bias.

No, regressions Michael finds are rarely if ever reported to trac. He
instead pokes the merger on IRC or sends an email to the ml.
Trac gets mostly regression reports from library or CLI users.

Don't go accusing so lightly of bias...

> 
>> and i just yesterday found 2 issues in a merge (which you fixed)
> 
> So where's the problem?
> 
>>
>>>
>>> That aside, may i ask what prompted this question? Did someone complain
>>> to you privately? No merge recently seems to have broken anything that
>>> hasn't been already fixed, beyond one threading bug that's being
>>> investigated right now, so i wonder why ask this now.  
>>
>> It was on my mind since a long time. I guess the recent surge of merges
>> and the uneasiness of doing the 3.3 release in the middle kind of was
>> bringing it up into relevance again.
> 
> Well, you insisted on a release at this time.
> 
>> Before that with the merges falling behind, multiple libav developers
>> did sent patches to ffmpeg-devel which passed through review on our
>> codebase before application. The merges restarting stoped this it
>> seems.
> 
> Uh, what.

I think he's talking about Martin Storsjö sending patchsets like VP9
arm/aarch64 asm.

> 
>> I strongly belive that libav developers sending patches to ffmpeg
>> and thus the author of a change testing it on top of ffmpeg results
>> in better code than if its merged by a 3rd party.
> 
> You know what would be even better? If there were only a single project
> on which Libav and FFmpeg developer worked.
> ___
> 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] [RFC] Reviewing merges

[Marton Balint]

On Mon, 24 Apr 2017, Michael Niedermayer wrote:

On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:



We have recently been able to go through six hundred or so commits in a
month or two this way after being stuck for the longest time by a few of
those big API changes. If we start requiring every commit to go through
a review process on the ML then we will never catch up with the backlog.
In short, things as they are right now are smooth. Changing it will only
make this slower.


Maybe, but is merging more faster also better for FFmpeg ?
I did not analyze the bugs on our bug tracker but subjectivly the
number of regressions seems much larger than a year or 2 ago.
and i just yesterday found 2 issues in a merge (which you fixed)



Yeah, I also have two I recently came across, both caused by the delayed 
filter initialization patch:


https://trac.ffmpeg.org/ticket/6323
https://trac.ffmpeg.org/ticket/6318

Maybe someone more familiar with ffmpeg.c code can take a look?

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 20:27:45 +0200
Michael Niedermayer  wrote:

> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> > On 4/23/2017 11:07 PM, Michael Niedermayer wrote:  
> > > Hi all
> > > 
> > > Should changes ported from libav (what we call merges) be reviewed
> > > before being pushed?  
> > 
> > The lot of merges are simple things like "Fix this bug that was already
> > fixed in ffmpeg months ago", "K", etc. Lately we are even no-oping a
> > good amount of them as they don't even apply.  
> 
> > Only a small set of merges are big API changes, and those are always
> > handled by more than one developer, either by reviewing the changes,
> > testing them or by helping getting the thing working. And of course, any
> > bug that was not caught before pushing is fixed afterwards.
> > In fact, it should be noted that if they are initially skipped for
> > requiring more thought and for blocking unrelated merges, when we get
> > them working at a latter point we always send them to the ML instead of
> > simply pushing them.  
> 
> yes
> 
> could you send more changes to the ML instead of just ones
> initially skiped ? (and of course i dont mean trivial / clearly correct
> stuff)
> 
> More eyes may catch more issues also i belive its important that we
> all see the changes being done, we all have to maintain the code
> which interacts with these changes.

Sorry, from you I've mostly seen weird command lines failing (and the
devs had to find out themselves whether they were legitimate failures).
From "eyes catching issues" I'd expect something more concrete, like
pointing out errors in the code or fixing them.

> 
> [...]
> 
> > We have recently been able to go through six hundred or so commits in a
> > month or two this way after being stuck for the longest time by a few of
> > those big API changes. If we start requiring every commit to go through
> > a review process on the ML then we will never catch up with the backlog.
> > In short, things as they are right now are smooth. Changing it will only
> > make this slower.  
> 
> Maybe, but is merging more faster also better for FFmpeg ?

Oh come on, the merge backlog we had almost meant that we were giving
up on merging, causing huge problems to various people (including
myself).

> I did not analyze the bugs on our bug tracker but subjectivly the
> number of regressions seems much larger than a year or 2 ago.

Because you're not doing the merges yourself anymore, which means that
things you test might result in a regression? When you were doing the
merges, you probably did this before you merged, meaning you'd of
course not find as many regressions after the merge.

Now that's what I call bias.

> and i just yesterday found 2 issues in a merge (which you fixed)

So where's the problem?

> 
> > 
> > That aside, may i ask what prompted this question? Did someone complain
> > to you privately? No merge recently seems to have broken anything that
> > hasn't been already fixed, beyond one threading bug that's being
> > investigated right now, so i wonder why ask this now.  
> 
> It was on my mind since a long time. I guess the recent surge of merges
> and the uneasiness of doing the 3.3 release in the middle kind of was
> bringing it up into relevance again.

Well, you insisted on a release at this time.

> Before that with the merges falling behind, multiple libav developers
> did sent patches to ffmpeg-devel which passed through review on our
> codebase before application. The merges restarting stoped this it
> seems.

Uh, what.

> I strongly belive that libav developers sending patches to ffmpeg
> and thus the author of a change testing it on top of ffmpeg results
> in better code than if its merged by a 3rd party.

You know what would be even better? If there were only a single project
on which Libav and FFmpeg developer worked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] pthread_frame: ignore errors during draining

[wm4]

This is needed to get compatibility with the behavior before the
recent decode.c restructuring merge, and fixes fate failures with
this:

  make fate-h264-attachment-631 THREADS=32

For every 4 threads, a frame is dropped at the point at which
draining is initialized. The problem starts at THREADS=4.

This patch "fixes" it by ignoring errors during draining (if there
is a frame to be returned), but there is probably a deeper cause
and/or a better fix for this. I haven't looked closer at this, but
was asked to send this patch for discussion.
---
 libavcodec/pthread_frame.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 13d682842d..e7fa503adf 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -548,7 +548,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx,
 fctx->next_finished = finished;
 
 /* return the size of the consumed packet if no error occurred */
-if (err >= 0)
+if (err >= 0 || (!avpkt->size && *got_picture_ptr))
 err = avpkt->size;
 finish:
 async_lock(fctx);
-- 
2.11.0

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Michael Niedermayer]

On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > Should changes ported from libav (what we call merges) be reviewed
> > before being pushed?
> 
> The lot of merges are simple things like "Fix this bug that was already
> fixed in ffmpeg months ago", "K", etc. Lately we are even no-oping a
> good amount of them as they don't even apply.

> Only a small set of merges are big API changes, and those are always
> handled by more than one developer, either by reviewing the changes,
> testing them or by helping getting the thing working. And of course, any
> bug that was not caught before pushing is fixed afterwards.
> In fact, it should be noted that if they are initially skipped for
> requiring more thought and for blocking unrelated merges, when we get
> them working at a latter point we always send them to the ML instead of
> simply pushing them.

yes

could you send more changes to the ML instead of just ones
initially skiped ? (and of course i dont mean trivial / clearly correct
stuff)

More eyes may catch more issues also i belive its important that we
all see the changes being done, we all have to maintain the code
which interacts with these changes.


[...]

> We have recently been able to go through six hundred or so commits in a
> month or two this way after being stuck for the longest time by a few of
> those big API changes. If we start requiring every commit to go through
> a review process on the ML then we will never catch up with the backlog.
> In short, things as they are right now are smooth. Changing it will only
> make this slower.

Maybe, but is merging more faster also better for FFmpeg ?
I did not analyze the bugs on our bug tracker but subjectivly the
number of regressions seems much larger than a year or 2 ago.
and i just yesterday found 2 issues in a merge (which you fixed)


> 
> That aside, may i ask what prompted this question? Did someone complain
> to you privately? No merge recently seems to have broken anything that
> hasn't been already fixed, beyond one threading bug that's being
> investigated right now, so i wonder why ask this now.

It was on my mind since a long time. I guess the recent surge of merges
and the uneasiness of doing the 3.3 release in the middle kind of was
bringing it up into relevance again.
Before that with the merges falling behind, multiple libav developers
did sent patches to ffmpeg-devel which passed through review on our
codebase before application. The merges restarting stoped this it
seems.
I strongly belive that libav developers sending patches to ffmpeg
and thus the author of a change testing it on top of ffmpeg results
in better code than if its merged by a 3rd party.

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 16:00:41 +0200
Carl Eugen Hoyos  wrote:

> 2017-04-24 15:38 GMT+02:00 wm4 :
> > On Mon, 24 Apr 2017 15:23:20 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :  
> >> > Hi,
> >> >
> >> > On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:
> >> >  
> >> >> On Mon, 24 Apr 2017 10:46:38 +0200
> >> >> Carl Eugen Hoyos  wrote:  
> >> >> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :  
> >> >> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:  
> >> >> > >>
> >> >> > >> Should changes ported from libav (what we call merges) be
> >> >> > >> reviewed before being pushed?  
> >> >> > >
> >> >> > > I've asked about this on IRC (#ffmpeg-devel).  The overall
> >> >> > > consensus there, at least at the time I asked it, is there is an
> >> >> > > expectation that such changes have already been properly
> >> >> > > reviewed for libav, so they are likely to be okay for ffmpeg,
> >> >> > > and while some issues have crept into ffmpeg as a result
> >> >> > > of these merges, the merge process has gone smoothly
> >> >> > > overall.  
> >> >> >
> >> >> > This does not sound correct to me.  
> >> >>
> >> >> Are you joking?  
> >>
> >> No, definitely not.  
> >
> > Well that's regrettable, because it appears you are misinformed.  
> 
> This is very unlikely.
> You, otoh, were not around when some of the things you discuss
> below happened, so it is extremely likely that you are misinformed.

When was I not around? Or are you joking?

> > He is certainly right about the consensus on IRC.  
> 
> > He is also right that patches get reviewed in Libav - probably more
> > than in FFmpeg.  
> 
> I always considered this one of the more insulting lies that were
> spread.

Well, all commits in Libav must be reviewed, while on the other hand
FFmpeg, in many cases, allows pushing commits without even posting them
to the mailing list. This alone makes what I said definitely not a
"lie". Maybe there are actually no lies? Then why do you claim there
are lies? Are you misinformed?

What about the cases where Libav commits were actually reviewed by
FFmpeg developers who were on the libav-devel mailing list? Do you mean
to insult them if you say that Libav doesn't review patches properly?
Or are you just misinformed or joking? Tough choice for you...

> > The merges are rather smooth as well,  
> 
> I don't know what exactly you mean but I (strongly) disagree, I
> believe the merges are not smooth at all.

So far most people seem to think the merges go smoothly.

Do you think merges would go more smoothly if we reviewed all
merge commits?

What about the cases where there were regressions (or supposed
regressions) after a change reviewed by many FFmpeg developers was
pushed? Do you mean to belittle these developers?

In some cases, mergers step up and ask FFmpeg developers to review
merges, to help with them, or to fix certain regressions caused by past
merges. Where are you in this? This issue seems important for you, but
why do I not ever see you helping out here? Why are you not doing any
merges yourself?

> > and we are all enjoying the good results of the merges  
> 
> > (including yourself).  
> 
> Given that I have written repeatedly on this mailing list that
> I do not enjoy them (on the contrary), I wonder what you are
> trying to say: I know you are not spreading lies on this mailing
> list but perhaps you could elaborate a little?

Oh, just today I have seen a TRAC ticket that was closed by you, and it
said something like "fixed by ", where  was a merge
commit. (You did that a while back, I merely _saw_ it today by
coincidence. I don't normally follow the bug tracker. While we're at
it, I've never seen you report a merge regression to me, even though
you seem to accuse me of causing some.)

Are you lying? Or maybe joking? Well I know you would never lie, so
maybe you were joking, but I don't find it funny.

> > Usually there are no major issues, although big intrusive
> > changes sometimes cause some regressions - which is
> > normal for this type of change.  
> 
> But if the regressions remain unfixed, it is a little surprising
> to speak about "no major issues", don't you agree?

Which regressions? You claim they exist, yet you never mention any of
those by name. Maybe you're lying, joking, having problems due to
English not being your native language like you often mention, etc.?

> > Regarding what Michael said: merges were never reviewed,
> > and that's the only reason why the FFmpeg project could
> > keep up with Libav.  
> 
> This isn't entirely correct (and some may consider the sentence
> misleading, but I know you weren't around so you cannot know):
> Because the avconv project controlled the api through one

You keep calling it "avconv project". The project is named Libav, and
it never called itself "avconv project". Do 

[FFmpeg-devel] [PATCH] Add support for 's' type gopher URL

[François Revol]

It's not standard but mentionned on:
http://en.wikipedia.org/wiki/Gopher_%28protocol%29#Gopher_item_types

It's used at least on:
gopher://sdf.org/1/sdf/historical
(commercial.mp3)
---
 libavformat/gopher.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/gopher.c b/libavformat/gopher.c
index 3070b24caf..7d27d6febe 100644
--- a/libavformat/gopher.c
+++ b/libavformat/gopher.c
@@ -46,6 +46,7 @@ static int gopher_connect(URLContext *h, const char *path)
 switch (*++path) {
 case '5':
 case '9':
+case 's': /* unofficial type for audio */
 path = strchr(path, '/');
 if (!path) return AVERROR(EINVAL);
 break;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] minterpolate: added codec_me_mode

[Paul B Mahol]

On 4/24/17, Davinder Singh  wrote:
> Patch attached.
>

So this encodes video frames to generate motion vectors?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] minterpolate: added codec_me_mode

[Davinder Singh]

Patch attached.


0001-minterpolate-added-codec_me_mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Sun, 23 Apr 2017 20:50:38 -0700
Aaron Levinson  wrote:

> properly review some of the ported changes on ffmpeg-devel.  For 
> example, I submitted a patch to fix a bug with QuickSync interlaced 
> video to ffmpeg-devel on 4/13/2017.  The change mostly reverted some of 
> the QSV code in ffmpeg back to an earlier state.  Interlaced video QSV 
> encoding used to work in ffmpeg, but this was broken in October 2016 as 
> a result of a merge with libav.  However, I was asked to submit the 
> patch to libav instead because QSV development is more active on 
> libav-devel.  I did that, and the patch finally made it into libav 

The problem is actually that QSV started out in Libav, but then was
modified a bunch of times (and in a bad way) in FFmpeg, without
upstreaming the change to Libav. It didn't help that (in this case,
apparently) the FFmpeg changes were subpar, and the author of them was
often unavailable to provide help or fixes in time.

Of course this won't stop _certain_ people from claiming that the
regression you mentioned is Libav's fault, or the fault of the people
merging the changes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[James Almer]

On 4/24/2017 12:50 AM, Aaron Levinson wrote:
> For example, I submitted a patch to fix a bug with QuickSync interlaced
> video to ffmpeg-devel on 4/13/2017.  The change mostly reverted some of
> the QSV code in ffmpeg back to an earlier state.  Interlaced video QSV
> encoding used to work in ffmpeg, but this was broken in October 2016 as
> a result of a merge with libav.  However, I was asked to submit the
> patch to libav instead because QSV development is more active on
> libav-devel.  I did that, and the patch finally made it into libav
> today.  And, my hope is that it will be merged into ffmpeg--that is, it
> seemed like the most readily available path to getting this code into
> ffmpeg was to contribute it to libav first.

I'd say poke Mark Thompson (jkqxz on irc) to push them here as well. No
real need to wait until we get to that point with the merges, especially
since they were originally submitted here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[James Almer]

On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> Hi all
> 
> Should changes ported from libav (what we call merges) be reviewed
> before being pushed?

The lot of merges are simple things like "Fix this bug that was already
fixed in ffmpeg months ago", "K", etc. Lately we are even no-oping a
good amount of them as they don't even apply.
Only a small set of merges are big API changes, and those are always
handled by more than one developer, either by reviewing the changes,
testing them or by helping getting the thing working. And of course, any
bug that was not caught before pushing is fixed afterwards.
In fact, it should be noted that if they are initially skipped for
requiring more thought and for blocking unrelated merges, when we get
them working at a latter point we always send them to the ML instead of
simply pushing them.

Back when you handled the merges you were able to keep things synced
daily since you were not slowed down by the need of having a review
process for every single one of them, and similarly only asked for help
with big changes that required every module to be adapted, or for
opinions with considerable changes like ref counting, much like Clément
asked for opinions about the new bitstream reader.

We have recently been able to go through six hundred or so commits in a
month or two this way after being stuck for the longest time by a few of
those big API changes. If we start requiring every commit to go through
a review process on the ML then we will never catch up with the backlog.
In short, things as they are right now are smooth. Changing it will only
make this slower.

That aside, may i ask what prompted this question? Did someone complain
to you privately? No merge recently seems to have broken anything that
hasn't been already fixed, beyond one threading bug that's being
investigated right now, so i wonder why ask this now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Carl Eugen Hoyos]

2017-04-24 15:38 GMT+02:00 wm4 :
> On Mon, 24 Apr 2017 15:23:20 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
>> > Hi,
>> >
>> > On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:
>> >
>> >> On Mon, 24 Apr 2017 10:46:38 +0200
>> >> Carl Eugen Hoyos  wrote:
>> >> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
>> >> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
>> >> > >>
>> >> > >> Should changes ported from libav (what we call merges) be
>> >> > >> reviewed before being pushed?
>> >> > >
>> >> > > I've asked about this on IRC (#ffmpeg-devel).  The overall
>> >> > > consensus there, at least at the time I asked it, is there is an
>> >> > > expectation that such changes have already been properly
>> >> > > reviewed for libav, so they are likely to be okay for ffmpeg,
>> >> > > and while some issues have crept into ffmpeg as a result
>> >> > > of these merges, the merge process has gone smoothly
>> >> > > overall.
>> >> >
>> >> > This does not sound correct to me.
>> >>
>> >> Are you joking?
>>
>> No, definitely not.
>
> Well that's regrettable, because it appears you are misinformed.

This is very unlikely.
You, otoh, were not around when some of the things you discuss
below happened, so it is extremely likely that you are misinformed.

> He is certainly right about the consensus on IRC.

> He is also right that patches get reviewed in Libav - probably more
> than in FFmpeg.

I always considered this one of the more insulting lies that were
spread.

> The merges are rather smooth as well,

I don't know what exactly you mean but I (strongly) disagree, I
believe the merges are not smooth at all.

> and we are all enjoying the good results of the merges

> (including yourself).

Given that I have written repeatedly on this mailing list that
I do not enjoy them (on the contrary), I wonder what you are
trying to say: I know you are not spreading lies on this mailing
list but perhaps you could elaborate a little?

> Usually there are no major issues, although big intrusive
> changes sometimes cause some regressions - which is
> normal for this type of change.

But if the regressions remain unfixed, it is a little surprising
to speak about "no major issues", don't you agree?

> Regarding what Michael said: merges were never reviewed,
> and that's the only reason why the FFmpeg project could
> keep up with Libav.

This isn't entirely correct (and some may consider the sentence
misleading, but I know you weren't around so you cannot know):
Because the avconv project controlled the api through one
distribution maintainer, most patches had to be merged.
(You probably don't know that some couldn't be merged
because it would have implied api/abi breaks which FFmpeg
always tried hard to avoid.)

> You never seemed to have an issue with merges when
> Michael did them,

How do you know this?
(I also ask because of the Coc that you so heavily requested
and I wonder what you are implying.)

> although they were definitely not without problems.

I was always strongly against the merges but we unfortunately
couldn't avoid them, see above.

> These days, merges actually get more attention and reviewing,
> because if there's something questionable or not simple, we

> get a "second opinion", rather than adding a bunch of hacks to
> the merge commit, like Michael tended to do.

These constant insults are so bad that I don't understand
why you are still around.

>> > What he meant was: it depends who does the merges, or rather,
>> > what political faction (s)he is part of.
>> >
>> > Tsk, tsk.
>>
>> (Apart from the Coc, I don't remember if you agreed or not:)
>>
>> Please try to comment on technical issues (or at least stay with
>> the facts), the insults are less useful for this conversation.
>
> Shouldn't you heed your own advice?
>
> Like, seriously, shouldn't you, since you're the worst offender ever
> of the things you just brought up here?

Reading your email, I find your constant accusations a little surprising.

> Frankly you're on the level of an aggressive troll, and always have
> been when it came to things related to Libav.

Since you seem to believe so strongly in the avconv project:
You do realize that it was mostly your wiki entry that convinced
the Debian and gentoo people to change projects (project
defaults) - why did you write it?

> I see that even in this thread, you tricked me again into typing out a
> bunch of arguments with just one line of bullshit, while not bringing
> up any arguments yourself. Oh well.

I mostly read insults above.

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 15:23:20 +0200
Carl Eugen Hoyos  wrote:

> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:
> >  
> >> On Mon, 24 Apr 2017 10:46:38 +0200
> >> Carl Eugen Hoyos  wrote:  
> >> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :  
> >> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:  
> >> > >>
> >> > >> Should changes ported from libav (what we call merges) be
> >> > >> reviewed before being pushed?  
> >> > >
> >> > > I've asked about this on IRC (#ffmpeg-devel).  The overall
> >> > > consensus there, at least at the time I asked it, is there is an
> >> > > expectation that such changes have already been properly
> >> > > reviewed for libav, so they are likely to be okay for ffmpeg,
> >> > > and while some issues have crept into ffmpeg as a result
> >> > > of these merges, the merge process has gone smoothly
> >> > > overall.  
> >> >
> >> > This does not sound correct to me.  
> >>
> >> Are you joking?  
> 
> No, definitely not.

Well that's regrettable, because it appears you are misinformed. He is
certainly right about the consensus on IRC. He is also right that
patches get reviewed in Libav - probably more than in FFmpeg.

The merges are rather smooth as well, and we are all enjoying the
good results of the merges (including yourself). Usually there are no
major issues, although big intrusive changes sometimes cause some
regressions - which is normal for this type of change.

Regarding what Michael said: merges were never reviewed, and that's the
only reason why the FFmpeg project could keep up with Libav. You never
seemed to have an issue with merges when Michael did them, although
they were definitely not without problems.

These days, merges actually get more attention and reviewing, because
if there's something questionable or not simple, we get a "second
opinion", rather than adding a bunch of hacks to the merge commit,
like Michael tended to do.

> > What he meant was: it depends who does the merges, or rather,
> > what political faction (s)he is part of.
> >
> > Tsk, tsk.  
> 
> (Apart from the Coc, I don't remember if you agreed or not:)
> 
> Please try to comment on technical issues (or at least stay with
> the facts), the insults are less useful for this conversation.

Shouldn't you heed your own advice?

Like, seriously, shouldn't you, since you're the worst offender ever of
the things you just brought up here? Frankly you're on the level of an
aggressive troll, and always have been when it came to things related
to Libav.

I see that even in this thread, you tricked me again into typing out a
bunch of arguments with just one line of bullshit, while not bringing
up any arguments yourself. Oh well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v9] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

- This patch contains the changes to interface the Turing codec 
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
comments in the review as follows:
  - Added a pkg-config file to list all dependencies required by libturing. 
This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
  - As per suggestions of wm4, two functions (add_option and finalise_options) 
have been created. The former appends new options while the latter sets up the 
argv array of pointers to char* accordingly. add_option re-allocates the buffer 
for options using av_realloc
  - Additionally, both these functions handle the errors in case the memory 
wasn't allocated correctly
  - malloc|free|realloc have been substituted with their corresponding 
av_{malloc|free|realloc} version
  - Check on bit-depth has been removed since the ffmpeg already casts the 
right pix_fmt and bit depth
  - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
  - Changed usage of av_free with av_freep and fixed calls to free arrays
  - Added brackets to all if and for statements
  - Avoid repetition of code to free arrays in case of failure to initialise 
the libturing encoder
  - Some fixes to address the review from wm4 and Mark Thompson received on Wed 
08/02/2017
  - Fixed indentation
---
 LICENSE.md |   1 +
 configure  |   6 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 314 +
 5 files changed, 323 insertions(+)
 create mode 100755 libavcodec/libturing.c

diff --git a/LICENSE.md b/LICENSE.md
index ba65b05..03787c0 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -84,6 +84,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index 487a4d7..6e5fab4 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1497,6 +1498,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 frei0r
 libcdio
 librubberband
+libturing
 libvidstab
 libx264
 libx265
@@ -2866,6 +2868,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5810,6 +5813,9 @@ enabled libssh&& require_pkg_config libssh 
libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h 
turing_version &&
+ { check_cpp_condition turing.h 
"TURING_API_VERSION > 1" ||
+ die "ERROR: libturing requires turing api version 
2 or greater."; }
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3889ced..9230ac5 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -896,6 +896,7 @@ OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
+OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b7d03ad..d3745d3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -616,6 +616,7 @@ static void register_all(void)
 REGISTER_ENCODER(LIBSHINE,  libshine);
 REGISTER_ENCDEC (LIBSPEEX,  libspeex);
 REGISTER_ENCODER(LIBTHEORA, libtheora);
+REGISTER_ENCODER(LIBTURING, libturing);
 

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Carl Eugen Hoyos]

2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:
>
>> On Mon, 24 Apr 2017 10:46:38 +0200
>> Carl Eugen Hoyos  wrote:
>> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
>> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
>> > >>
>> > >> Should changes ported from libav (what we call merges) be
>> > >> reviewed before being pushed?
>> > >
>> > > I've asked about this on IRC (#ffmpeg-devel).  The overall
>> > > consensus there, at least at the time I asked it, is there is an
>> > > expectation that such changes have already been properly
>> > > reviewed for libav, so they are likely to be okay for ffmpeg,
>> > > and while some issues have crept into ffmpeg as a result
>> > > of these merges, the merge process has gone smoothly
>> > > overall.
>> >
>> > This does not sound correct to me.
>>
>> Are you joking?

No, definitely not.

> What he meant was: it depends who does the merges, or rather,
> what political faction (s)he is part of.
>
> Tsk, tsk.

(Apart from the Coc, I don't remember if you agreed or not:)

Please try to comment on technical issues (or at least stay with
the facts), the insults are less useful for this conversation.

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

[FFmpeg-devel] [PATCH] Disable MSA optimization for big endian arch

[shivraj.patil]

From: Shivraj Patil 

Signed-off-by: Shivraj Patil 
---
 configure |4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 1e3463c..c63a48a 100755
--- a/configure
+++ b/configure
@@ -5357,6 +5357,10 @@ elif enabled mips; then
 enabled mipsdsp && check_inline_asm_flags mipsdsp '"addu.qb $t0, $t1, 
$t2"' '-mdsp'
 enabled mipsdspr2 && check_inline_asm_flags mipsdspr2 '"absq_s.qb $t0, 
$t1"' '-mdspr2'
 
+if enabled bigendian && enabled msa; then
+disable msa
+fi
+
 elif enabled parisc; then
 
 if enabled gcc; then
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Ronald S. Bultje]

Hi,

On Mon, Apr 24, 2017 at 5:57 AM, wm4  wrote:

> On Mon, 24 Apr 2017 10:46:38 +0200
> Carl Eugen Hoyos  wrote:
> > 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> > > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
> > >>
> > >> Should changes ported from libav (what we call merges) be reviewed
> > >> before being pushed?
> > >
> > > I've asked about this on IRC (#ffmpeg-devel).  The overall consensus
> there,
> > > at least at the time I asked it, is there is an expectation that such
> > > changes have already been properly reviewed for libav, so they are
> likely to
> > > be okay for ffmpeg, and while some issues have crept into ffmpeg as a
> result
> > > of these merges, the merge process has gone smoothly overall.
> >
> > This does not sound correct to me.
>
> Are you joking?


What he meant was: it depends who does the merges, or rather, what
political faction (s)he is part of.

Tsk, tsk.

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[wm4]

On Mon, 24 Apr 2017 10:46:38 +0200
Carl Eugen Hoyos  wrote:

> 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:  
> >>
> >> Should changes ported from libav (what we call merges) be reviewed
> >> before being pushed?  
> >
> > I've asked about this on IRC (#ffmpeg-devel).  The overall consensus there,
> > at least at the time I asked it, is there is an expectation that such
> > changes have already been properly reviewed for libav, so they are likely to
> > be okay for ffmpeg, and while some issues have crept into ffmpeg as a result
> > of these merges, the merge process has gone smoothly overall.  
> 
> This does not sound correct to me.

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

Re: [FFmpeg-devel] [RFC] Reviewing merges

[Carl Eugen Hoyos]

2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
>>
>> Should changes ported from libav (what we call merges) be reviewed
>> before being pushed?
>
> I've asked about this on IRC (#ffmpeg-devel).  The overall consensus there,
> at least at the time I asked it, is there is an expectation that such
> changes have already been properly reviewed for libav, so they are likely to
> be okay for ffmpeg, and while some issues have crept into ffmpeg as a result
> of these merges, the merge process has gone smoothly overall.

This does not sound correct to me.

The more important issue is:
Who is responsible for fixing the regressions that are merged from avconv?

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