Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: refine EXT-X-BYTERANGE support for segments

[Steven Liu]

2016-09-15 20:31 GMT+08:00 Steven Liu :

>
>
> 2016-09-14 6:51 GMT+08:00 Steven Liu :
>
>>
>>
>> 2016-09-14 2:53 GMT+08:00 Moritz Barsnick :
>>
>>> On Tue, Sep 13, 2016 at 11:25:39 +0800, Steven Liu wrote:
>>> > +int byterange_mode = hls->flags & (HLS_SINGLE_FILE) ||
>>> hls->max_seg_size > 0;
>>>  ^   ^
>>> Why the bracket?
>>>
>>> > +av_log(oc, AV_LOG_ERROR, "Invalid segment filename
>>> template '%s' you can try use -use_localtime 1 with it\n", c->basename);
>>> Rather:
>>>av_log(oc, AV_LOG_ERROR, "Invalid segment filename
>>> template '%s', you can try to use -use_localtime 1 with it\n", c->basename);
>>>
>>> > +{"hls_segment_size", "set maximum size per segment file,
>>> (Byte)",  OFFSET(max_seg_size),AV_OPT_TYPE_INT,{.i64 = 0}, 0,
>>> INT_MAX, E},
>>>{"hls_segment_size", "set maximum size per segment file (in
>>> bytes)",  OFFSET(max_seg_size),AV_OPT_TYPE_INT,{.i64 = 0}, 0,
>>> INT_MAX, E},
>>>
>>> This isn't a flag, right? Perhaps you shouldn't be putting the option
>>> between the flags' lines (but probably still as the final option).
>>>
>> I shall update patch :-)
>>
>>>
>>> The value of 0 seems to have a special meaning. Is this documented
>>>
>> I cannot understand "The value of 0 seems to have a special meaning" ,
>> it will not set value when unuse hls_segment_size, so give it value of 0.
>> is that a problem?
>>
>>> anywhere? In other words: You should also update doc/muxers.texi. (I
>>> can help with the grammar of the wording.)
>>>
>> patch will come soon :-D
>>
>>>
>>>
> patch update
>
>
patch update,
give a warning message when video bitrate large than hls_segment_size.


0001-avformat-hlsenc-refine-EXT-X-BYTERANGE-support-for-s.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/libvpxenc: Avaoid vp8 transparency encoding with auto-alt-ref

[James Zern]

On Fri, Sep 16, 2016 at 4:50 PM, Carl Eugen Hoyos  wrote:
> 2016-09-17 1:48 GMT+02:00 James Zern:
>> On Fri, Sep 16, 2016 at 5:23 AM, Carl Eugen Hoyos wrote:
>
>>> Attached patch fixes ticket #5815.
>>
>>> +if (ctx->auto_alt_ref && ctx->is_alpha && avctx->codec_id == 
>>> AV_CODEC_ID_VP8) {
>>> +av_log(avctx, AV_LOG_ERROR, "Transparency encoding with 
>>> auto_alt_ref does not work\n");
>>> +return AVERROR(EINVAL);
>>> +}
>>> +
>>>
>>
>> This is a bit drastic, but might be necessary if the bug is reliably
>
> It only occurs if you try to encode with transparency and
> auto_alt_ref.
>

Thanks for the easy repro. It may have something to do with the fact
that in vp8 the alt-ref is a separate frame, this needs a closer look.
Feel free to apply the change in the meantime.

>> occurring. This sounds like a libvpx bug, I'll try to reproduce
>> locally when I get a chance.
>
> Please do!
>
> Carl Eugen
> ___
> 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] Dropping SDL1 support [VOTE]

[Lou Logan]

On Thu, 15 Sep 2016 14:36:32 -0300, James Almer wrote:

> There have been some complains from developers about keeping both
> SDL1 and SDL2 support at the same time even after all SDL1 code
> has been already ported, and especially since it makes maintaining
> ffplay more complex, so seeing the waters are divided I think the
> best solution will be to vote.
[...]

I vote in favor of dropping SDL1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/muxers: add flv muxer document into doc/muxers

[Lou Logan]

On Fri, 16 Sep 2016 09:50:25 +0800, Steven Liu wrote:

> From e94de46102a57be1988cc451e1b610b404453c81 Mon Sep 17 00:00:00 2001
> From: Steven Liu 
> Date: Fri, 16 Sep 2016 08:58:33 +0800
> Subject: [PATCH] doc/muxers: add flv muxer document into doc/muxers
> 
> add flvflags aac_seq_header_detect and flvflags no_sequence_end
> document into doc/muxers
> ---
>  doc/muxers.texi | 30 ++
>  1 file changed, 30 insertions(+)

LGTM and pushed after removing the examples.

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpxenc: Avaoid vp8 transparency encoding with auto-alt-ref

[Carl Eugen Hoyos]

2016-09-17 1:48 GMT+02:00 James Zern:
> On Fri, Sep 16, 2016 at 5:23 AM, Carl Eugen Hoyos wrote:

>> Attached patch fixes ticket #5815.
>
>> +if (ctx->auto_alt_ref && ctx->is_alpha && avctx->codec_id == 
>> AV_CODEC_ID_VP8) {
>> +av_log(avctx, AV_LOG_ERROR, "Transparency encoding with 
>> auto_alt_ref does not work\n");
>> +return AVERROR(EINVAL);
>> +}
>> +
>>
>
> This is a bit drastic, but might be necessary if the bug is reliably

It only occurs if you try to encode with transparency and
auto_alt_ref.

> occurring. This sounds like a libvpx bug, I'll try to reproduce
> locally when I get a chance.

Please do!

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpxenc: Avaoid vp8 transparency encoding with auto-alt-ref

[James Zern]

On Fri, Sep 16, 2016 at 5:23 AM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #5815.
>

> +if (ctx->auto_alt_ref && ctx->is_alpha && avctx->codec_id == 
> AV_CODEC_ID_VP8) {
> +av_log(avctx, AV_LOG_ERROR, "Transparency encoding with auto_alt_ref 
> does not work\n");
> +return AVERROR(EINVAL);
> +}
> +
>

This is a bit drastic, but might be necessary if the bug is reliably
occurring. This sounds like a libvpx bug, I'll try to reproduce
locally when I get a chance.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Ronald S. Bultje]

Hi,

On Fri, Sep 16, 2016 at 12:22 PM, Carl Eugen Hoyos 
wrote:

> 2016-09-16 18:19 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Fri, Sep 16, 2016 at 12:16 PM, Carl Eugen Hoyos 
> > wrote:
> >
> >> 2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :
> >>
> >> > You want other developers to do more work
> >>
> >> Of which work are you talking about?
> >
> > Installing libsdl1.
>
> I don't understand: Why would a developer who has libsdl2 install
> libsdl1 after we switched the default sdl to sdl2?


Oh, you mean the sdl1+2 variant; I agree with others that duplicate code is
never a good thing, particularly not for this ridiculous reason that some
of our devs refuse to go through the trouble to install libsdl2.

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Carl Eugen Hoyos]

2016-09-16 18:24 GMT+02:00 Josh de Kock :
> On 16/09/2016 17:22, Carl Eugen Hoyos wrote:
>>
>> 2016-09-16 18:19 GMT+02:00 Ronald S. Bultje :
>>>
>>> On Fri, Sep 16, 2016 at 12:16 PM, Carl Eugen Hoyos 
>>> wrote:
>>>
 2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :

> You want other developers to do more work

 Of which work are you talking about?
>>>
>>> Installing libsdl1.
>>
>> I don't understand: Why would a developer who has libsdl2 install
>> libsdl1 after we switched the default sdl to sdl2?
>
> To maintain the sdl1 variant.

You of course do not have to maintain it: I find it extremely
helpful that you already did all the necessary work, asking
for more would be completely unreasonable.

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Josh de Kock]

On 16/09/2016 17:22, Carl Eugen Hoyos wrote:

2016-09-16 18:19 GMT+02:00 Ronald S. Bultje :

Hi,

On Fri, Sep 16, 2016 at 12:16 PM, Carl Eugen Hoyos 
wrote:


2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :


You want other developers to do more work


Of which work are you talking about?


Installing libsdl1.


I don't understand: Why would a developer who has libsdl2 install
libsdl1 after we switched the default sdl to sdl2?



To maintain the sdl1 variant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Carl Eugen Hoyos]

2016-09-16 18:19 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Fri, Sep 16, 2016 at 12:16 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :
>>
>> > You want other developers to do more work
>>
>> Of which work are you talking about?
>
> Installing libsdl1.

I don't understand: Why would a developer who has libsdl2 install
libsdl1 after we switched the default sdl to sdl2?

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Ronald S. Bultje]

Hi,

On Fri, Sep 16, 2016 at 12:16 PM, Carl Eugen Hoyos 
wrote:

> 2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :
>
> > You want other developers to do more work
>
> Of which work are you talking about?


Installing libsdl1.

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Carl Eugen Hoyos]

2016-09-16 16:07 GMT+02:00 Hendrik Leppkes :

> You want other developers to do more work

Of which work are you talking about?

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Hendrik Leppkes]

On Fri, Sep 16, 2016 at 2:48 PM, Carl Eugen Hoyos  wrote:
> 2016-09-16 14:21 GMT+02:00 Rostislav Pehlivanov :
>
>> I'd rather have SDL1 support dropped. ffplay is the only thing on my
>> machine which uses libsdl1.2
>
> And we already (everybody) agreed that we want to switch to SDL2
> so that you (and others) do not have to use (or depend on) sdl1
> anymore.
> But this is an entirely different question that is completely unrelated
> to your installation:
> Do we allow developers to continue to use sdl1 to test on their
> old (but supported) Linux distributions or do we forcibly stop
> them from contributing here?
>

If you think its too much to ask a developer to either run a more
modern OS or manually install one dependency, then I don't think we
can help you.
You want other developers to do more work, just so that one or two
developers can stick to their antiquated development machines?

I find it odd that we typically ask much more of users then we can
even expect from our developers.


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

Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Interpret unspecified color range as limited range

[Clément Bœsch]

On Fri, Sep 16, 2016 at 03:20:49PM +0200, Vittorio Giovara wrote:
> This is the assumption that is made in pixel format conversion do
> throughout the code (in particular swscale), and BT-specifications
> mandate.
> 
> Add a warning to inform the user that an automatic selection is being
> made.
> 
> Signed-off-by: Vittorio Giovara 
> ---
>  libavfilter/vf_colorspace.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index e69be50..41d1692 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -518,10 +518,13 @@ static int convert(AVFilterContext *ctx, void *data, 
> int job_nr, int n_jobs)
>  return 0;
>  }
>  
> -static int get_range_off(int *off, int *y_rng, int *uv_rng,
> +static int get_range_off(AVFilterContext *ctx, int *off,
> + int *y_rng, int *uv_rng,
>   enum AVColorRange rng, int depth)
>  {
>  switch (rng) {
> +case AVCOL_RANGE_UNSPECIFIED:
> +av_log(ctx, AV_LOG_WARNING, "Input range not set, assuming 
> tv/mpeg\n");

nit: I think coverity likes a "// Fall-through" below this line in these
cases.

[...]

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Interpret unspecified color range as limited range

[Ronald S. Bultje]

Hi,

On Fri, Sep 16, 2016 at 9:20 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> This is the assumption that is made in pixel format conversion do
> throughout the code (in particular swscale), and BT-specifications
> mandate.
>
> Add a warning to inform the user that an automatic selection is being
> made.
>
> Signed-off-by: Vittorio Giovara 
> ---
>  libavfilter/vf_colorspace.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index e69be50..41d1692 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -518,10 +518,13 @@ static int convert(AVFilterContext *ctx, void *data,
> int job_nr, int n_jobs)
>  return 0;
>  }
>
> -static int get_range_off(int *off, int *y_rng, int *uv_rng,
> +static int get_range_off(AVFilterContext *ctx, int *off,
> + int *y_rng, int *uv_rng,
>   enum AVColorRange rng, int depth)
>  {
>  switch (rng) {
> +case AVCOL_RANGE_UNSPECIFIED:
> +av_log(ctx, AV_LOG_WARNING, "Input range not set, assuming
> tv/mpeg\n");
>  case AVCOL_RANGE_MPEG:
>  *off = 16 << (depth - 8);
>  *y_rng = 219 << (depth - 8);
> @@ -740,7 +743,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>  double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
>  int off, bits, in_rng;
>
> -res = get_range_off(, >in_y_rng, >in_uv_rng,
> +res = get_range_off(ctx, , >in_y_rng, >in_uv_rng,
>  s->in_rng, in_desc->comp[0].depth);
>  if (res < 0) {
>  av_log(ctx, AV_LOG_ERROR,
> @@ -773,7 +776,7 @@ static int create_filtergraph(AVFilterContext *ctx,
>  double (*rgb2yuv)[3] = s->rgb2yuv_dbl_coeffs;
>  int off, out_rng, bits;
>
> -res = get_range_off(, >out_y_rng, >out_uv_rng,
> +res = get_range_off(ctx, , >out_y_rng, >out_uv_rng,
>  s->out_rng, out_desc->comp[0].depth);
>  if (res < 0) {
>  av_log(ctx, AV_LOG_ERROR,
> --
> 2.9.3


OK.

(I'll leave for a few hours for others to review, and apply after.)

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

[FFmpeg-devel] [PATCHv2] vf_colorspace: Interpret unspecified color range as limited range

[Vittorio Giovara]

This is the assumption that is made in pixel format conversion do
throughout the code (in particular swscale), and BT-specifications
mandate.

Add a warning to inform the user that an automatic selection is being
made.

Signed-off-by: Vittorio Giovara 
---
 libavfilter/vf_colorspace.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index e69be50..41d1692 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -518,10 +518,13 @@ static int convert(AVFilterContext *ctx, void *data, int 
job_nr, int n_jobs)
 return 0;
 }
 
-static int get_range_off(int *off, int *y_rng, int *uv_rng,
+static int get_range_off(AVFilterContext *ctx, int *off,
+ int *y_rng, int *uv_rng,
  enum AVColorRange rng, int depth)
 {
 switch (rng) {
+case AVCOL_RANGE_UNSPECIFIED:
+av_log(ctx, AV_LOG_WARNING, "Input range not set, assuming tv/mpeg\n");
 case AVCOL_RANGE_MPEG:
 *off = 16 << (depth - 8);
 *y_rng = 219 << (depth - 8);
@@ -740,7 +743,7 @@ static int create_filtergraph(AVFilterContext *ctx,
 double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
 int off, bits, in_rng;
 
-res = get_range_off(, >in_y_rng, >in_uv_rng,
+res = get_range_off(ctx, , >in_y_rng, >in_uv_rng,
 s->in_rng, in_desc->comp[0].depth);
 if (res < 0) {
 av_log(ctx, AV_LOG_ERROR,
@@ -773,7 +776,7 @@ static int create_filtergraph(AVFilterContext *ctx,
 double (*rgb2yuv)[3] = s->rgb2yuv_dbl_coeffs;
 int off, out_rng, bits;
 
-res = get_range_off(, >out_y_rng, >out_uv_rng,
+res = get_range_off(ctx, , >out_y_rng, >out_uv_rng,
 s->out_rng, out_desc->comp[0].depth);
 if (res < 0) {
 av_log(ctx, AV_LOG_ERROR,
-- 
2.9.3

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Ronald S. Bultje]

Hi,

On Fri, Sep 16, 2016 at 8:48 AM, Carl Eugen Hoyos 
wrote:

> Do we allow developers to continue to use sdl1 to test on their
> old (but supported) Linux distributions or do we forcibly stop
> them from contributing here?


All developers are welcome. You'll just have to install libsdl2 yourself to
enable ffplay.

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Ronald S. Bultje]

Hi folks,

On Thu, Sep 15, 2016 at 1:36 PM, James Almer  wrote:

> The vote will end 1 week from now, simple majority wins, and
> it's open only to those in the voting committee[1].
> Marton Balint, while not in the committee, should IMO also
> have the chance to vote or at least comment since he's the
> main ffplay maintainer.


Marton, it sounds like your opinion is valued. Penny for your thoughts? :)

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Ronald S. Bultje]

Hi,

On Fri, Sep 16, 2016 at 8:01 AM, Carl Eugen Hoyos 
wrote:

> 2016-09-16 13:32 GMT+02:00 Paul B Mahol :
>
> >>> That's why i started this vote, to see how many devs are
> >>> effectively in favor or against and make the final decision
> >>> official.
> >>
> >> A vote on how evil the FFmpeg community is wrt to
> >> new (and existing) contributors? Seriously?
> >
> > Proof?
>
> Wasn't it explained that Debian Ubuntu LTS would not
> allow using ffplay anymore if this vote gets a yes?
> Or did I misunderstand?


Debian and Ubuntu LTS will continue to use the release branches of FFmpeg.

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Rostislav Pehlivanov]

On 15 September 2016 at 18:36, James Almer  wrote:

> There have been some complains from developers about keeping both
> SDL1 and SDL2 support at the same time even after all SDL1 code
> has been already ported, and especially since it makes maintaining
> ffplay more complex, so seeing the waters are divided I think the
> best solution will be to vote.
>
> Arguments in favor of keeping SDL1:
> * Debian Old-Stable and Ubuntu 12.04 don't ship an usable SDL2
>   by default, meaning a few extra steps for anyone wanting to
>   compile ffmpeg git would be needed to keep ffplay and the sdl
>   outdev working on them.
> * We have a dev willing to maintain the SDL1 version of ffplay
>   until the above two distros are EOLed.
>
> Arguments in favor of dropping SDL1:
> * SDL1 is old and effectively unmaintained.
> * The above distros will never upgrade their ffmpeg packages.
> * Anyone compiling ffmpeg git from source on any of the above
>   distros most likely already has to deal with other missing
>   deps, like any recent x264, be it from unnofficial PPAs or
>   manually compiling from source. SDL2 would not be any
>   different in that regard.
> * Even though we have a dev willing to maintain the deprecated
>   SDL1 code, he'd rather not have to deal with it.
>
> Other arguments in favor or against are welcome.
>
> The vote will end 1 week from now, simple majority wins, and
> it's open only to those in the voting committee[1].
> Marton Balint, while not in the committee, should IMO also
> have the chance to vote or at least comment since he's the
> main ffplay maintainer.
>
> Regards.
>
> [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd rather have SDL1 support dropped. ffplay is the only thing on my
machine which uses
libsdl1.2. Everything else has moved to libsdl2 (except dosbox which got
forked to support
sdl2 because development is mostly dead). Keeping a separate version of
ffplay (like ffmpeg_qsv)
doesn't sound to me like a good idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/libvpxenc: Avaoid vp8 transparency encoding with auto-alt-ref

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5815.

Please comment, Carl Eugen
From 3cf356b38a8ea6f9c98c36ad5cc7413dfa780e28 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 16 Sep 2016 14:21:09 +0200
Subject: [PATCH] lavc/libvpxenc: Avoid vp8 transparency encoding with
 auto-alt-ref.

Fixes ticket #5815.
---
 libavcodec/libvpxenc.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index f3cff81..2db87f7 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -631,6 +631,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (ctx->tune >= 0)
 codecctl_int(avctx, VP8E_SET_TUNING,   ctx->tune);
 
+if (ctx->auto_alt_ref && ctx->is_alpha && avctx->codec_id == 
AV_CODEC_ID_VP8) {
+av_log(avctx, AV_LOG_ERROR, "Transparency encoding with auto_alt_ref 
does not work\n");
+return AVERROR(EINVAL);
+}
+
 if (CONFIG_LIBVPX_VP8_ENCODER && avctx->codec_id == AV_CODEC_ID_VP8) {
 #if FF_API_PRIVATE_OPT
 FF_DISABLE_DEPRECATION_WARNINGS
-- 
1.7.10.4

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Carl Eugen Hoyos]

2016-09-16 13:32 GMT+02:00 Paul B Mahol :

>>> That's why i started this vote, to see how many devs are
>>> effectively in favor or against and make the final decision
>>> official.
>>
>> A vote on how evil the FFmpeg community is wrt to
>> new (and existing) contributors? Seriously?
>
> Proof?

Wasn't it explained that Debian Ubuntu LTS would not
allow using ffplay anymore if this vote gets a yes?
Or did I misunderstand?

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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Paul B Mahol]

On 9/16/16, Carl Eugen Hoyos  wrote:
> 2016-09-15 19:55 GMT+02:00 James Almer :
>> On 9/15/2016 2:51 PM, Carl Eugen Hoyos wrote:
>
>>> Didn't we all agree yesterday that this makes the transition
>>> less painful?
>>
>> Not all. Several mentioned on IRC that they didn't like it.
>
> So development discussion has moved to irc (again)?

Development discussion happens on irc all the time.
It's your problem you are rarely on irc.

>
>> That's why i started this vote, to see how many devs are
>> effectively in favor or against and make the final decision
>> official.
>
> A vote on how evil the FFmpeg community is wrt to
> new (and existing) contributors? Seriously?

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

Re: [FFmpeg-devel] [PATCH] avformat/http: remove duplicate user-agent option

[Steven Liu]

2016-09-16 19:07 GMT+08:00 Carl Eugen Hoyos :

> 2016-09-16 4:43 GMT+02:00 Steven Liu :
>
> > +@item user-agent
> > +This is a deprecated option, you can use user_agent instead it.
>
> Sorry for the nitpicking: Why do you move the first, unchanged line?
>
> Carl Eugen
>
>
Because it will be remove, so it's position is not important :-D
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Carl Eugen Hoyos]

2016-09-15 19:55 GMT+02:00 James Almer :
> On 9/15/2016 2:51 PM, Carl Eugen Hoyos wrote:

>> Didn't we all agree yesterday that this makes the transition
>> less painful?
>
> Not all. Several mentioned on IRC that they didn't like it.

So development discussion has moved to irc (again)?

> That's why i started this vote, to see how many devs are
> effectively in favor or against and make the final decision
> official.

A vote on how evil the FFmpeg community is wrt to
new (and existing) contributors? Seriously?

>>> and especially since it makes maintaining
>>> ffplay more complex
>>
>> How?
>
> Having two separate codepaths, and needing to fix potential
> bugs in both.

Why?
I don't easily remember a "bug" in ffplay that needed fixing to
keep it 100% usable, there were many improvements and
there will be no reason to backport the future improvements.

Do you remember one?

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

Re: [FFmpeg-devel] [PATCH] avformat/http: remove duplicate user-agent option

[Carl Eugen Hoyos]

2016-09-16 4:43 GMT+02:00 Steven Liu :

> +@item user-agent
> +This is a deprecated option, you can use user_agent instead it.

Sorry for the nitpicking: Why do you move the first, unchanged line?

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Make the packet check more tolerant

[Michael Niedermayer]

On Fri, Sep 16, 2016 at 11:45:54AM +0200, Paul B Mahol wrote:
> On 9/16/16, Michael Niedermayer  wrote:
> > Depends-on "avformat/movenc: Check packet in mov_write_single_packet() too"
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/movenc.c | 31 ---
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> >
> 
> lgtm

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/movenc: Check packet in mov_write_single_packet() too

[Michael Niedermayer]

On Fri, Sep 16, 2016 at 11:39:21AM +0200, Paul B Mahol wrote:
> On 9/16/16, Michael Niedermayer  wrote:
> > Fixes assertion failure
> >
> > Found-by: durandal117
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/movenc.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> 
> lgtm

applied

thanks

[...]
-- 
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] [PATCH 1/2] avformat/movenc: Factor check_pkt() out

[Michael Niedermayer]

On Fri, Sep 16, 2016 at 11:38:57AM +0200, Paul B Mahol wrote:
> On 9/16/16, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/movenc.c | 24 ++--
> >  1 file changed, 18 insertions(+), 6 deletions(-)
> >
> 
> lgtm

applied

thanks

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Make the packet check more tolerant

[Paul B Mahol]

On 9/16/16, Michael Niedermayer  wrote:
> Depends-on "avformat/movenc: Check packet in mov_write_single_packet() too"
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/movenc.c | 31 ---
>  1 file changed, 16 insertions(+), 15 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH] avutil/softfloat_ieee754: make all functions inline

[Michael Niedermayer]

On Thu, Sep 15, 2016 at 11:08:47PM -0300, James Almer wrote:
> Removes "defined but not used" warnings
> 
> Signed-off-by: James Almer 
> ---
>  libavutil/softfloat_ieee754.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

iam not the author/maintainer, but patch looks ok to me

thx

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: Factor check_pkt() out

[Paul B Mahol]

On 9/16/16, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/movenc.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/movenc: Check packet in mov_write_single_packet() too

[Paul B Mahol]

On 9/16/16, Michael Niedermayer  wrote:
> Fixes assertion failure
>
> Found-by: durandal117
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/movenc.c | 4 
>  1 file changed, 4 insertions(+)
>

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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Thu, Sep 15, 2016 at 05:53:58PM -0800, Lou Logan wrote:
> On Wed, 7 Sep 2016 14:27:07 +0200, Michael Niedermayer wrote:
> 
> > yes one can ignore it but its alot more usefull if people keep in
> > mind that theres patchwork.
> 
> The patch submission checklist is lengthy.
> 
> I'm fine with an addition somewhere in doc/developer pointing out that
> it exists and how to use it if the patch submitter wants to, but I don't
> think it needs to be in the checklist.

where should it be put / where would you suggest to put it ?

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

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


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

Re: [FFmpeg-devel] Dropping SDL1 support [VOTE]

[Josh de Kock]

On 15/09/2016 23:00, Lukasz Marek wrote:

On 15.09.2016 23:36, Josh de Kock wrote:

On 15/09/2016 22:28, Lukasz Marek wrote:

On 15.09.2016 23:19, Moritz Barsnick wrote:

On Thu, Sep 15, 2016 at 14:36:32 -0300, James Almer wrote:

* SDL1 is old and effectively unmaintained.


I understand this verbatim, but what is it supposed to mean? Has SDL1
gotten rotten? Or more precisely:

- Has technology evolved, and the library not kept up?
- Is a long list of bugs (somehow effecting ffmpeg) piling up and never
  being fixed?
- Something else?


It doesn't compile on Mac OS


I've been testing it just fine on Mac OS.


I don't remember now everything, I worked with it like 2 years ago,  but
I got the same issue as here
https://forums.libsdl.org/viewtopic.php?p=45264=ae0efc2e82d373067c5112bfba70cd11


Other example is that SDL is trying to use X11 on Mac which is dropped
(since 10.8?).

You can ignore my answer as it doesn't stand for anything. It won't stop
introducing SDL 2.0 nor force 1.2 drop, but asked question if SDL 1.2 is
getting rotten then asnwer is yes IMHO.



SDL1 works absolutely fine on Mac OS, it uses the native window, no X11 
required.


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