Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[James Almer]

On 10/21/2017 11:03 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
>> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
>>> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
 Hi,

 On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer 
  wrote:

> This is different from FF_API_VISMV which is supported through codecview.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/version.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 8584bb7006..25696690d7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -79,7 +79,7 @@
>  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
>  #endif
>  #ifndef FF_API_DEBUG_MV
> -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
> +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif
>

 Can you give an explanation for why this should be delayed? (It's missing
 in the commit message, and this is hard to evaluate without a
 justification/explanation.)
>>>
>>> It was not agreed on ffmpeg-devel to remove this feature.
>>
>> I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
>> c6c03dfdf1692137111fe4aea0b72a1cff08f71e.
> 
> thats one i think was the code which we now have in codecview.
> So that itself should be ok to remove
> 
> 
>>
>> The commit even states it should have removed "all traces of its use",
>> but it looks like with the years more and more code was added to it,
>> seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
>> libav doesn't even feature the massive amount of code we have under this
>> deprecation wrapper in mpegvideo.
>> So basically, the functionality was deprecated, but then further
>> developed to the point removing it is almost impossible.
>>
>> How the hell did this happen?
> 
> I dont know, maybe,
> Libav deprecating and removing as much FFmpeg code as they can
> FFmpeg continuing to work on the FFmpeg code

No, i mean, why did a feature marked as deprecated keep getting
development? Shouldn't the replacement have gotten it instead? And if a
replacement was never planned, why wasn't the deprecation undone,
instead of getting pushed further into the future indefinitely?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[Michael Niedermayer]

On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> > On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer 
> >>  >>> wrote:
> >>
> >>> This is different from FF_API_VISMV which is supported through codecview.
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/version.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>> index 8584bb7006..25696690d7 100644
> >>> --- a/libavcodec/version.h
> >>> +++ b/libavcodec/version.h
> >>> @@ -79,7 +79,7 @@
> >>>  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
> >>>  #endif
> >>>  #ifndef FF_API_DEBUG_MV
> >>> -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
> >>> +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>  #endif
> >>>
> >>
> >> Can you give an explanation for why this should be delayed? (It's missing
> >> in the commit message, and this is hard to evaluate without a
> >> justification/explanation.)
> > 
> > It was not agreed on ffmpeg-devel to remove this feature.
> 
> I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
> c6c03dfdf1692137111fe4aea0b72a1cff08f71e.

thats one i think was the code which we now have in codecview.
So that itself should be ok to remove


> 
> The commit even states it should have removed "all traces of its use",
> but it looks like with the years more and more code was added to it,
> seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
> libav doesn't even feature the massive amount of code we have under this
> deprecation wrapper in mpegvideo.
> So basically, the functionality was deprecated, but then further
> developed to the point removing it is almost impossible.
> 
> How the hell did this happen?

I dont know, maybe,
Libav deprecating and removing as much FFmpeg code as they can
FFmpeg continuing to work on the FFmpeg code

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[James Almer]

On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer >> wrote:
>>
>>> This is different from FF_API_VISMV which is supported through codecview.
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/version.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>> index 8584bb7006..25696690d7 100644
>>> --- a/libavcodec/version.h
>>> +++ b/libavcodec/version.h
>>> @@ -79,7 +79,7 @@
>>>  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
>>>  #endif
>>>  #ifndef FF_API_DEBUG_MV
>>> -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
>>> +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
>>>  #endif
>>>
>>
>> Can you give an explanation for why this should be delayed? (It's missing
>> in the commit message, and this is hard to evaluate without a
>> justification/explanation.)
> 
> It was not agreed on ffmpeg-devel to remove this feature.

I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
c6c03dfdf1692137111fe4aea0b72a1cff08f71e.

The commit even states it should have removed "all traces of its use",
but it looks like with the years more and more code was added to it,
seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
libav doesn't even feature the massive amount of code we have under this
deprecation wrapper in mpegvideo.
So basically, the functionality was deprecated, but then further
developed to the point removing it is almost impossible.

How the hell did this happen?

> 
> Its used for example by me occasionally to analyze videos in bug
> reports for debuging them.
> 
> There is no replacement or alternative iam aware of
> 
> [...]
> 
> 
> 
> ___
> 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] avcodec/version: Postpone FF_API_DEBUG_MV

[Michael Niedermayer]

On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer  > wrote:
> 
> > This is different from FF_API_VISMV which is supported through codecview.
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/version.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 8584bb7006..25696690d7 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -79,7 +79,7 @@
> >  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
> >  #endif
> >  #ifndef FF_API_DEBUG_MV
> > -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
> > +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
> >  #endif
> >
> 
> Can you give an explanation for why this should be delayed? (It's missing
> in the commit message, and this is hard to evaluate without a
> justification/explanation.)

It was not agreed on ffmpeg-devel to remove this feature.

Its used for example by me occasionally to analyze videos in bug
reports for debuging them.

There is no replacement or alternative iam aware of

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

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


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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[James Almer]

On 10/21/2017 9:55 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
>> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
>>> This patchset removes the long-deprecated ffserver program and all
>>> its privately exposed things from libavformat.
>>>
>>> Rostislav Pehlivanov (6):
>>>   Remove the ffserver program
>>>   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>>>   libavformat: unexpose the ff_inet_aton function
>>>   libavformat: remove the ff_rtp_get_local_rtcp_port function
>>>   libavformat: unexpose private ff_ functions needed by ffserver
>>>   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
>>
>> This set will be applied a month or so from now, when the unstable ABI
>> period is over.
>>
>> If you can do in a month what was not done in a year plus, anyone is
>> welcome to fix all ffserver issues or preferably replace it altogether
>> with a new tool with a more user friendly syntax/interface.
> 
> Can you list the technical problems that require dropping ffserver,
> so that someone interrested in fixing them can do so ?

They have been listed in both the November 2016 discussion/vote thread
and i think in the bump patch i sent last month as well.
The most important one is of course the usage of internal API. Then
there's https://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203926.html

If anyone actually cared about ffserver, one think it would be fixed by
now...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[Ronald S. Bultje]

Hi,

On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer  wrote:

> This is different from FF_API_VISMV which is supported through codecview.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/version.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 8584bb7006..25696690d7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -79,7 +79,7 @@
>  #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
>  #endif
>  #ifndef FF_API_DEBUG_MV
> -#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
> +#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif
>

Can you give an explanation for why this should be delayed? (It's missing
in the commit message, and this is hard to evaluate without a
justification/explanation.)

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[Michael Niedermayer]

On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> > This patchset removes the long-deprecated ffserver program and all
> > its privately exposed things from libavformat.
> > 
> > Rostislav Pehlivanov (6):
> >   Remove the ffserver program
> >   libavformat: remove the ffmenc and ffmdec muxer and demuxers
> >   libavformat: unexpose the ff_inet_aton function
> >   libavformat: remove the ff_rtp_get_local_rtcp_port function
> >   libavformat: unexpose private ff_ functions needed by ffserver
> >   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
> 
> This set will be applied a month or so from now, when the unstable ABI
> period is over.
> 
> If you can do in a month what was not done in a year plus, anyone is
> welcome to fix all ffserver issues or preferably replace it altogether
> with a new tool with a more user friendly syntax/interface.

Can you list the technical problems that require dropping ffserver,
so that someone interrested in fixing them can do so ?

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

[FFmpeg-devel] [PATCH] avcodec/version: Postpone FF_API_DEBUG_MV

[Michael Niedermayer]

This is different from FF_API_VISMV which is supported through codecview.

Signed-off-by: Michael Niedermayer 
---
 libavcodec/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/version.h b/libavcodec/version.h
index 8584bb7006..25696690d7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -79,7 +79,7 @@
 #define FF_API_SET_DIMENSIONS(LIBAVCODEC_VERSION_MAJOR < 58)
 #endif
 #ifndef FF_API_DEBUG_MV
-#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 58)
+#define FF_API_DEBUG_MV  (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
 #ifndef FF_API_AC_VLC
 #define FF_API_AC_VLC(LIBAVCODEC_VERSION_MAJOR < 58)
-- 
2.14.2

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

[FFmpeg-devel] [PATCH]lavc/hevcdec: Silence warnings when decoding DolbyVision

[Carl Eugen Hoyos]

Hi!

Attached patch silences the many warnings shown when decoding streams
with DolbyVision content.

Please comment, Carl Eugen
From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 22 Oct 2017 02:17:27 +0200
Subject: [PATCH] lavc/hevcdec: Silence warnings when decoding DolbyVision.

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

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 2e4add2..d5ed9f5 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2933,6 +2933,8 @@ static int decode_nal_unit(HEVCContext *s, const H2645NAL *nal)
 break;
 case HEVC_NAL_AUD:
 case HEVC_NAL_FD_NUT:
+case 62: // unspecified, used by DolbyVision
+case 63: // unspecified, used by DolbyVision
 break;
 default:
 av_log(s->avctx, AV_LOG_INFO,
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 2/3] ffmpeg: add -bitexact flag to simplify enabling bitexact mode in (de)muxer and (de/en)coder

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 fftools/ffmpeg.h |  1 +
 fftools/ffmpeg_opt.c | 16 
 2 files changed, 17 insertions(+)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 888f77223a..cb912d95e4 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -161,6 +161,7 @@ typedef struct OptionsContext {
 float mux_preload;
 float mux_max_delay;
 int shortest;
+int bitexact;
 
 int video_disable;
 int audio_disable;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 500920326b..a6af1c6622 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -786,6 +786,9 @@ static void add_input_streams(OptionsContext *o, 
AVFormatContext *ic)
 exit_program(1);
 }
 
+if (o->bitexact)
+ist->dec_ctx->flags |= AV_CODEC_FLAG_BITEXACT;
+
 switch (par->codec_type) {
 case AVMEDIA_TYPE_VIDEO:
 if(!ist->dec)
@@ -1049,6 +1052,8 @@ static int open_input_file(OptionsContext *o, const char 
*filename)
 av_format_set_data_codec(ic, find_codec_or_die(data_codec_name, 
AVMEDIA_TYPE_DATA, 0));
 
 ic->flags |= AVFMT_FLAG_NONBLOCK;
+if (o->bitexact)
+ic->flags |= AVFMT_FLAG_BITEXACT;
 ic->interrupt_callback = int_cb;
 
 if (!av_dict_get(o->g->format_opts, "scan_all_pmts", NULL, 
AV_DICT_MATCH_CASE)) {
@@ -1370,6 +1375,10 @@ static OutputStream *new_output_stream(OptionsContext 
*o, AVFormatContext *oc, e
 ost->encoder_opts = filter_codec_opts(o->g->codec_opts, 
AV_CODEC_ID_NONE, oc, st, NULL);
 }
 
+
+if (o->bitexact)
+ost->enc_ctx->flags |= AV_CODEC_FLAG_BITEXACT;
+
 MATCH_PER_STREAM_OPT(time_bases, str, time_base, oc, st);
 if (time_base) {
 AVRational q;
@@ -2148,6 +2157,10 @@ static int open_output_file(OptionsContext *o, const 
char *filename)
 const AVOption *o = av_opt_find(oc, "fflags", NULL, 0, 0);
 av_opt_eval_flags(oc, o, e->value, _flags);
 }
+if (o->bitexact) {
+format_flags |= AVFMT_FLAG_BITEXACT;
+oc->flags|= AVFMT_FLAG_BITEXACT;
+}
 
 /* create streams for all unlabeled output pads */
 for (i = 0; i < nb_filtergraphs; i++) {
@@ -3471,6 +3484,9 @@ const OptionDef options[] = {
 { "shortest",   OPT_BOOL | OPT_EXPERT | OPT_OFFSET |
 OPT_OUTPUT,  { .off = 
OFFSET(shortest) },
 "finish encoding within shortest input" },
+{ "bitexact",   OPT_BOOL | OPT_EXPERT | OPT_OFFSET |
+OPT_OUTPUT | OPT_INPUT,  { .off = 
OFFSET(bitexact) },
+"bitexact mode" },
 { "apad",   OPT_STRING | HAS_ARG | OPT_SPEC |
 OPT_OUTPUT,  { .off = 
OFFSET(apad) },
 "audio pad", "" },
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/3] avcodec/h264dec: Fix potential array overread

[Michael Niedermayer]

add padding before scantable arrays

See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a

Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264dec.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 2106ba077e..de8b7c38b9 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -416,6 +416,7 @@ typedef struct H264Context {
 uint8_t (*mvd_table[2])[2];
 uint8_t *direct_table;
 
+uint8_t scan_padding[16];
 uint8_t zigzag_scan[16];
 uint8_t zigzag_scan8x8[64];
 uint8_t zigzag_scan8x8_cavlc[64];
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 3/3] tests/fate-run: Use -bitexact

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tests/fate-run.sh | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index e8d2e67709..05f4ca5e20 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -127,15 +127,15 @@ ffmpeg(){
 }
 
 framecrc(){
-ffmpeg "$@" -flags +bitexact -fflags +bitexact -f framecrc -
+ffmpeg "$@" -bitexact -f framecrc -
 }
 
 ffmetadata(){
-ffmpeg "$@" -flags +bitexact -fflags +bitexact -f ffmetadata -
+ffmpeg "$@" -bitexact -f ffmetadata -
 }
 
 framemd5(){
-ffmpeg "$@" -flags +bitexact -fflags +bitexact -f framemd5 -
+ffmpeg "$@" -bitexact -f framemd5 -
 }
 
 crc(){
@@ -160,7 +160,7 @@ pcm(){
 fmtstdout(){
 fmt=$1
 shift 1
-ffmpeg -flags +bitexact -fflags +bitexact "$@" -f $fmt -
+ffmpeg -bitexact "$@" -f $fmt -
 }
 
 enc_dec_pcm(){
@@ -173,7 +173,7 @@ enc_dec_pcm(){
 cleanfiles=$encfile
 encfile=$(target_path ${encfile})
 ffmpeg -i $src_file "$@" -f $out_fmt -y ${encfile} || return
-ffmpeg -flags +bitexact -fflags +bitexact -i ${encfile} -c:a 
pcm_${pcm_fmt} -fflags +bitexact -f ${dec_fmt} -
+ffmpeg -bitexact -i ${encfile} -c:a pcm_${pcm_fmt} -fflags +bitexact -f 
${dec_fmt} -
 }
 
 FLAGS="-flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact"
@@ -294,16 +294,16 @@ gapless(){
 cleanfiles="$cleanfiles $decfile1 $decfile2 $decfile3"
 
 # test packet data
-ffmpeg $extra_args -i "$sample" -flags +bitexact -fflags +bitexact -c:a 
copy -f framecrc -y $decfile1
+ffmpeg $extra_args -i "$sample" -bitexact -c:a copy -f framecrc -y 
$decfile1
 do_md5sum $decfile1
 # test decoded (and cut) data
-ffmpeg $extra_args -i "$sample" -flags +bitexact -fflags +bitexact -f wav 
md5:
+ffmpeg $extra_args -i "$sample" -bitexact -f wav md5:
 # the same as above again, with seeking to the start
-ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-fflags +bitexact -c:a copy -f framecrc -y $decfile2
+ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -bitexact -c:a 
copy -f framecrc -y $decfile2
 do_md5sum $decfile2
-ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-fflags +bitexact -f wav md5:
+ffmpeg $extra_args -ss 0 -seek_timestamp 1 -i "$sample" -bitexact -f wav 
md5:
 # test packet data, with seeking to a specific position
-ffmpeg $extra_args -ss 5 -seek_timestamp 1 -i "$sample" -flags +bitexact 
-fflags +bitexact -c:a copy -f framecrc -y $decfile3
+ffmpeg $extra_args -ss 5 -seek_timestamp 1 -i "$sample" -bitexact -c:a 
copy -f framecrc -y $decfile3
 do_md5sum $decfile3
 }
 
@@ -316,7 +316,7 @@ gaplessenc(){
 cleanfiles="$cleanfiles $file1"
 
 # test data after reencoding
-ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a 
$codec -f $format -y "$file1"
+ffmpeg -i "$sample" -bitexact -map 0:a -c:a $codec -f $format -y "$file1"
 probegaplessinfo "$file1"
 }
 
@@ -328,7 +328,7 @@ audio_match(){
 decfile="${outdir}/${test}.wav"
 cleanfiles="$cleanfiles $decfile"
 
-ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact $extra_args -y 
$decfile
+ffmpeg -i "$sample" -bitexact $extra_args -y $decfile
 tests/audiomatch $decfile $trefile
 }
 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH]lavf/avio: Also print the https warning for missing tls protocol

[Carl Eugen Hoyos]

Hi!

On redirection to https, FFmpeg only shows "protocol missing" without
a hint to what is missing.

Please comment, Carl Eugen
From 8c068d06fa425471590a8ee8765ef510476a180d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 22 Oct 2017 01:11:55 +0200
Subject: [PATCH] lavf/avio: Print the https warning also for missing tls
 protocol.

---
 libavformat/avio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 4718753..4dc4683 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -297,7 +297,7 @@ int ffurl_alloc(URLContext **puc, const char *filename, int flags,
return url_alloc_for_protocol(puc, p, filename, flags, int_cb);
 
 *puc = NULL;
-if (av_strstart(filename, "https:", NULL))
+if (av_strstart(filename, "https:", NULL) || av_strstart(filename, "tls:", NULL))
 av_log(NULL, AV_LOG_WARNING, "https protocol not found, recompile FFmpeg with "
  "openssl, gnutls "
  "or securetransport enabled.\n");
-- 
1.7.10.4

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

[FFmpeg-devel] libavcodec/huffyuvdsp(enc) : add avx2 version for add(diff)_int16

[Martin Vignali]

Hello,

In attach patch to add avx2 version for huffyuv dsp and huffyuvdsp enc
for add_int16 and diff_int16 func

Check asm result for add_int16 (Kaby Lake, os 10.12)
add_int16_128_c: 1607.9
add_int16_128_sse2: 442.7
add_int16_128_avx2: 218.9

Pass fate test for me


0001-checkasm-add-test-for-huffyuvdsp-add_int16 :
add a checkasm test for add_int16
base on lossless_videodsp checkasm test

i add a test with a fix size, to make speed test more easy to compare

0002-libavcodec-huffyuvdsp-enc-move-duplicate-macro-to-a-
huffyuvdsp.asm and huffyuvdspenc.asm use the same INT16_LOOP macro
with arg add for dec and sub for encoder

this patch move this macro in an asm file in order to be share by both dsp
asm

0003-libavcodec-huffyuvdsp-reorganize-add_int16-asm
0005-libavcodec-huffyuvdspenc-reorganize-diff_int16
Code reorganization


0004-libavcodec-huffyuvdsp-add-add_int16-AVX2-func
0006-libavcodec-huffyuvdspenc-add-diff_int16-AVX2-func
AVX2 version for each func


Martin
Jokyo Images


0001-checkasm-add-test-for-huffyuvdsp-add_int16.patch
Description: Binary data


0002-libavcodec-huffyuvdsp-enc-move-duplicate-macro-to-a-.patch
Description: Binary data


0003-libavcodec-huffyuvdsp-reorganize-add_int16-asm.patch
Description: Binary data


0004-libavcodec-huffyuvdsp-add-add_int16-AVX2-func.patch
Description: Binary data


0005-libavcodec-huffyuvdspenc-reorganize-diff_int16.patch
Description: Binary data


0006-libavcodec-huffyuvdspenc-add-diff_int16-AVX2-func.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

[Marton Balint]

On Sat, 21 Oct 2017, Carl Eugen Hoyos wrote:


2017-10-21 18:29 GMT+02:00 Nicolas George :

Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :

I thought filenames in libavformat are limited to 1K anyway
because of the AVFormatContext->filename field.


How can I reproduce this?
I tested the data from the ticket from the command line
and it worked fine here.

Or is there maybe no limitation for the data protocol?



Okay, I checked the code, and libavformat opens the file with the original 
filename, not the truncated one which is stored in AVFormatContext, so the 
1024 character file name limit does not affect every use case.



So if your patch really fixes the ticket, then how? :)


So the original (and the attached) patch do not fix the
ticket for you?
Could you provide some console output to allow me to
better understand the issue?


You cannot open for example an image sequence which has a path longer 
than 1024 bytes.





Yes, exactly. This limitation was the reason I did not bother handling
longer lines. I would like to understand how it makes a difference.


New patch attached, please comment.


Like I said earlier, with only a little additional work you can eliminate 
the concat file name limit if you if you create a line reader function in 
avio which dynamically extends the available buffer, I think that is the 
better solution, because next time somebody will want 100k and not 50k.


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

Re: [FFmpeg-devel] libavcodec/blockdsp : fix comment

[Ronald S. Bultje]

Hi,

On Sat, Oct 21, 2017 at 1:30 PM, Martin Vignali 
wrote:

> Hello,
>
> in attach patch to fix comment in blockdsp
>
> the dsp need align 32 now.
>

lgtm.

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[Carl Eugen Hoyos]

2017-10-21 1:28 GMT+02:00 James Almer :

> Could you look at ticket #6714 while at it? (And others also potentially
> related to edit lists).

https://trac.ffmpeg.org/query?status=new=open=~edts

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

Re: [FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

[Carl Eugen Hoyos]

2017-10-21 18:29 GMT+02:00 Nicolas George :
> Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :
>> I thought filenames in libavformat are limited to 1K anyway
>> because of the AVFormatContext->filename field.

How can I reproduce this?
I tested the data from the ticket from the command line
and it worked fine here.

Or is there maybe no limitation for the data protocol?

>> So if your patch really fixes the ticket, then how? :)

So the original (and the attached) patch do not fix the
ticket for you?
Could you provide some console output to allow me to
better understand the issue?

> Yes, exactly. This limitation was the reason I did not bother handling
> longer lines. I would like to understand how it makes a difference.

New patch attached, please comment.

Carl Eugen
From aa8ff422cfe1d7753f9a90cfbbefe1c02ebf5091 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 21 Oct 2017 22:02:52 +0200
Subject: [PATCH] lavf/concatdec: Allocate the filenames on the heap.

Allow huge filenames, real-world content can be passed via data: protocol.

Fixes ticket #6761.
---
 libavformat/concatdec.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 0e18901..b0075ce 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -386,16 +386,24 @@ static int concat_read_close(AVFormatContext *avf)
 static int concat_read_header(AVFormatContext *avf)
 {
 ConcatContext *cat = avf->priv_data;
-uint8_t buf[4096];
-uint8_t *cursor, *keyword;
+int buf_size = 50002;
+uint8_t *buf, *cursor, *keyword;
 int ret, line = 0, i;
 unsigned nb_files_alloc = 0;
 ConcatFile *file = NULL;
 int64_t time = 0;
 
+buf = av_malloc(buf_size);
+if (!buf)
+return AVERROR(ENOMEM);
+
 while (1) {
-if ((ret = ff_get_line(avf->pb, buf, sizeof(buf))) <= 0)
+if ((ret = ff_get_line(avf->pb, buf, buf_size)) <= 0)
 break;
+if (ret == buf_size - 1) {
+av_log(avf, AV_LOG_ERROR, "filename too long (>%d)\n", buf_size - 2);
+FAIL(AVERROR_INVALIDDATA);
+}
 line++;
 cursor = buf;
 keyword = get_keyword();
@@ -499,9 +507,11 @@ static int concat_read_header(AVFormatContext *avf)
MATCH_ONE_TO_ONE;
 if ((ret = open_file(avf, 0)) < 0)
 goto fail;
+av_freep();
 return 0;
 
 fail:
+av_freep();
 concat_read_close(avf);
 return ret;
 }
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote:
> 2017-10-21 21:43 GMT+02:00 Clément Bœsch :
> > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
> >> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
> >>
> >> > Aside from these nitpicks, I'm still concerned about how it's going
> >> > to conflict with GIF encoding where the transparent color is actually
> >> > used as a mean of not updating pixels from previous frames.
> >>
> >> But is this really related to this patch?
> >
> > Maybe not, but we need to keep that in mind and not make a
> > hasty decision wrt how we handle the transparency, because
> > it might makes future related development much harder.
> 
> Given that this is a libavfilter-only patch and we can reproduce
> the issue without using libavfilter, I am not completely
> convinced, but this is of course your decision.
> 

Yes it should be fine, I just want to be sure that using
palettegen/paletteuse will not create input streams that the limited GIF
encoder does not handle well because it doesn't make a difference between
"transparency flavours". If paletteuse starts inserting transparent colors
that are not meant to be used for the frame-diff system it could become a
problem.

In any case, I'll probably apply the patch at the next version, I'm just
not exactly comfortable with that part.

-- 
Clément B.


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

[FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Martin Vignali]

Hello,

In attach patch to add AVX2 version for add_bytes

0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
add AVX2 version

pass fate-test for me (os 10.12, x86_64)

checkasm result : (Kaby Lake) (run 10 times, and i took the fastest version)
checkasm: all 2 tests passed
add_bytes_c: 108.7
add_bytes_sse2: 26.5
add_bytes_avx2: 15.5


0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
only cosmetic
like the ref c function declaration in asm file is not consistent between
each asm file
i think a better separator for each function make the file easier to read

also add the c declaration for add bytes in comment


Martin


0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers.patch
Description: Binary data


0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Carl Eugen Hoyos]

2017-10-21 21:43 GMT+02:00 Clément Bœsch :
> On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
>> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
>>
>> > Aside from these nitpicks, I'm still concerned about how it's going
>> > to conflict with GIF encoding where the transparent color is actually
>> > used as a mean of not updating pixels from previous frames.
>>
>> But is this really related to this patch?
>
> Maybe not, but we need to keep that in mind and not make a
> hasty decision wrt how we handle the transparency, because
> it might makes future related development much harder.

Given that this is a libavfilter-only patch and we can reproduce
the issue without using libavfilter, I am not completely
convinced, but this is of course your decision.

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
> 
> > Aside from these nitpicks, I'm still concerned about how it's going
> > to conflict with GIF encoding where the transparent color is actually
> > used as a mean of not updating pixels from previous frames.
> 
> But is this really related to this patch?

Maybe not, but we need to keep that in mind and not make a hasty decision
wrt how we handle the transparency, because it might makes future related
development much harder.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for hapqa decoding

[Carl Eugen Hoyos]

2017-10-21 21:32 GMT+02:00 Martin Vignali :
> 2017-10-21 21:23 GMT+02:00 Carl Eugen Hoyos :
>
>> 2017-10-21 19:35 GMT+02:00 Martin Vignali :
>> > Hello,
>> >
>> > I split the previous patch for HAPQAlpha decoding
>> > in several part, to be easier to read
>> >
>> > 0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
>> > prepare for multi texture support but only decode the first texture
>> >
>> > 0003-libavcodec-hapdec-indent-after-previous-commit :
>> > Cosmetic : indent
>> >
>> > 0004-libavcodec-hapdec-add-support-for-hapqa-decoding :
>> > Decode HAQA, and support 2 texture decoding
>>
>> Is this the same patch as the one you explained to me
>> would show both unexpected behaviour for users and
>> make usage of the format needlessly difficult for
>> users?
>>
>> If yes, I don't think it is a good idea to resend it.
>>
>>
>>
> Are you sure, you don't talk about the discussion for HapAlphaOnly decoding
> /encoding ?
> if yes, the patch here are for another codec (HAQAlpha, who is RGBA with 2
> textures (one for RGB and one for Alpha))

Sorry!

Thank you for the clarification, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Carl Eugen Hoyos]

2017-10-21 18:40 GMT+02:00 Clément Bœsch :

> Aside from these nitpicks, I'm still concerned about how it's going
> to conflict with GIF encoding where the transparent color is actually
> used as a mean of not updating pixels from previous frames.

But is this really related to this patch?
I just tested the following and see some issues:
$ ffmpeg -i http://solvedproblems.hydex11.net/old/Images/apng/firefox.png
out.gif

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for hapqa decoding

[Martin Vignali]

2017-10-21 21:23 GMT+02:00 Carl Eugen Hoyos :

> 2017-10-21 19:35 GMT+02:00 Martin Vignali :
> > Hello,
> >
> > I split the previous patch for HAPQAlpha decoding
> > in several part, to be easier to read
> >
> > 0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
> > prepare for multi texture support but only decode the first texture
> >
> > 0003-libavcodec-hapdec-indent-after-previous-commit :
> > Cosmetic : indent
> >
> > 0004-libavcodec-hapdec-add-support-for-hapqa-decoding :
> > Decode HAQA, and support 2 texture decoding
>
> Is this the same patch as the one you explained to me
> would show both unexpected behaviour for users and
> make usage of the format needlessly difficult for
> users?
>
> If yes, I don't think it is a good idea to resend it.
>
>
>
Are you sure, you don't talk about the discussion for HapAlphaOnly decoding
/encoding ?
if yes, the patch here are for another codec (HAQAlpha, who is RGBA with 2
textures (one for RGB and one for Alpha))
I think for this one, everyone will be agree, that we need to use RGBA :-)

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for hapqa decoding

[Carl Eugen Hoyos]

2017-10-21 19:35 GMT+02:00 Martin Vignali :
> Hello,
>
> I split the previous patch for HAPQAlpha decoding
> in several part, to be easier to read
>
> 0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
> prepare for multi texture support but only decode the first texture
>
> 0003-libavcodec-hapdec-indent-after-previous-commit :
> Cosmetic : indent
>
> 0004-libavcodec-hapdec-add-support-for-hapqa-decoding :
> Decode HAQA, and support 2 texture decoding

Is this the same patch as the one you explained to me
would show both unexpected behaviour for users and
make usage of the format needlessly difficult for
users?

If yes, I don't think it is a good idea to resend it.

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

[FFmpeg-devel] [PATCH]lavc/avcodec: Constify the return value of av_bitstream_filter_next().

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a warning when compiling with sufficiently new gcc.

Please comment, Carl Eugen
From bdb2ad2bc45465675e9fff7313ae5f1b062ec3e1 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 21 Oct 2017 20:55:01 +0200
Subject: [PATCH] lavc/avcodec: Constify the return value of
 av_bitstream_filter_next().

Fixes the following gcc warning:
libavcodec/bitstream_filter.c:39:12: warning: return discards 'const' qualifier from pointer target type
---
 libavcodec/avcodec.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 18c3e3e..c9031d1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -6074,7 +6074,7 @@ void av_bitstream_filter_close(AVBitStreamFilterContext *bsf);
  * filters.
  */
 attribute_deprecated
-AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
+const AVBitStreamFilter *av_bitstream_filter_next(const AVBitStreamFilter *f);
 #endif
 
 /**
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[James Almer]

On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> This patchset removes the long-deprecated ffserver program and all
> its privately exposed things from libavformat.
> 
> Rostislav Pehlivanov (6):
>   Remove the ffserver program
>   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>   libavformat: unexpose the ff_inet_aton function
>   libavformat: remove the ff_rtp_get_local_rtcp_port function
>   libavformat: unexpose private ff_ functions needed by ffserver
>   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag

This set will be applied a month or so from now, when the unstable ABI
period is over.

If you can do in a month what was not done in a year plus, anyone is
welcome to fix all ffserver issues or preferably replace it altogether
with a new tool with a more user friendly syntax/interface.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[James Almer]

On 10/21/2017 4:14 PM, Carl Eugen Hoyos wrote:
> 2017-10-21 21:12 GMT+02:00 James Almer :
>> On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
>>> Just to understand this better:
>>> The plan was to remove some fields from avcodec.h to have a reason
>>> to remove a tool that has a large user base
>> The "plan" is to follow what was agreed a year and a half ago, then
>> confirmed with a vote last November: Remove an unmaintainted tool that
>> uses internal libavformat API. This has nothing to do with libavcodec.
> 
> But the reason ffserver doesn't build anymore is that you
> removed a field from avcodec.h, no?
> So how does this have nothing to do with libavcodec?

I was not aware of this failure. Why didn't you report it to the bump
patch i sent a month and a half ago?

I'll try to put the field back in the struct until ffserver is dropped a
month from now. Sorry for the breakage.

> 
>> I beg all developers to not start a new flamewar like we had last
>> November. You were able to extend the life of ffserver until a major
>> bump were to take place. ffserver got virtually no development and was
>> not fixed/adapted to work like every other fftool for an entire year
>> since then, and is therefore going to be removed as agreed.
> 
>> Lets for once show the FOSS world that this project is not run by children.
> 
> Thank you for violating our Coc, I found it bad enough that
> you commit unreviewed patches.
> 
> 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] [PATCH]lavc/bitstream_filter: Make a cast explicit

[Carl Eugen Hoyos]

2017-03-01 23:36 GMT+01:00 Carl Eugen Hoyos :

> Attached patch silences one of three warnings when compiling
> bitstream_filter.o, I suspect this cast is necessary.

Ping.

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

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[Carl Eugen Hoyos]

2017-10-21 21:12 GMT+02:00 James Almer :
> On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
>> Just to understand this better:
>> The plan was to remove some fields from avcodec.h to have a reason
>> to remove a tool that has a large user base
> The "plan" is to follow what was agreed a year and a half ago, then
> confirmed with a vote last November: Remove an unmaintainted tool that
> uses internal libavformat API. This has nothing to do with libavcodec.

But the reason ffserver doesn't build anymore is that you
removed a field from avcodec.h, no?
So how does this have nothing to do with libavcodec?

> I beg all developers to not start a new flamewar like we had last
> November. You were able to extend the life of ffserver until a major
> bump were to take place. ffserver got virtually no development and was
> not fixed/adapted to work like every other fftool for an entire year
> since then, and is therefore going to be removed as agreed.

> Lets for once show the FOSS world that this project is not run by children.

Thank you for violating our Coc, I found it bad enough that
you commit unreviewed patches.

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

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[James Almer]

On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base
The "plan" is to follow what was agreed a year and a half ago, then
confirmed with a vote last November: Remove an unmaintainted tool that
uses internal libavformat API. This has nothing to do with libavcodec.

I beg all developers to not start a new flamewar like we had last
November. You were able to extend the life of ffserver until a major
bump were to take place. ffserver got virtually no development and was
not fixed/adapted to work like every other fftool for an entire year
since then, and is therefore going to be removed as agreed.

Lets for once show the FOSS world that this project is not run by children.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[Paul B Mahol]

On 10/21/17, Rostislav Pehlivanov  wrote:
> This patchset removes the long-deprecated ffserver program and all
> its privately exposed things from libavformat.
>
> Rostislav Pehlivanov (6):
>   Remove the ffserver program
>   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>   libavformat: unexpose the ff_inet_aton function
>   libavformat: remove the ff_rtp_get_local_rtcp_port function
>   libavformat: unexpose private ff_ functions needed by ffserver
>   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
>

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

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[Paul B Mahol]

On 10/21/17, Carl Eugen Hoyos  wrote:
> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base?

This is the Joke.

>
> What kind of logic is that?

Sane one, yours is flawed.

> Shouldn't we communicate to our users that we like them?

We do not like our users, because ffserver is not any more actively
maintained at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[Rostislav Pehlivanov]

On 21 October 2017 at 20:04, Carl Eugen Hoyos  wrote:

> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base?
>
> What kind of logic is that?
> Shouldn't we communicate to our users that we like them?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Discussed that ad nauseum a year ago.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] Remove the ffserver program

[Carl Eugen Hoyos]

Just to understand this better:
The plan was to remove some fields from avcodec.h to have a reason
to remove a tool that has a large user base?

What kind of logic is that?
Shouldn't we communicate to our users that we like them?

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

[FFmpeg-devel] [PATCH 3/6] libavformat: unexpose the ff_inet_aton function

[Rostislav Pehlivanov]

Used only by ffserver.

Signed-off-by: Rostislav Pehlivanov 
---
 libavformat/libavformat.v | 1 -
 libavformat/network.h | 2 --
 libavformat/os_support.c  | 6 +++---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index c961cd8f19..4edf52f45e 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -2,7 +2,6 @@ LIBAVFORMAT_MAJOR {
 global:
 av*;
 #FIXME those are for ffserver
-ff_inet_aton;
 ff_socket_nonblock;
 ff_rtsp_parse_line;
 ff_rtp_get_local_rtp_port;
diff --git a/libavformat/network.h b/libavformat/network.h
index f83c796a95..5ab858f08d 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -95,8 +95,6 @@ int ff_network_wait_fd(int fd, int write);
  */
 int ff_network_wait_fd_timeout(int fd, int write, int64_t timeout, 
AVIOInterruptCB *int_cb);
 
-int ff_inet_aton (const char * str, struct in_addr * add);
-
 #if !HAVE_STRUCT_SOCKADDR_STORAGE
 struct sockaddr_storage {
 #if HAVE_STRUCT_SOCKADDR_SA_LEN
diff --git a/libavformat/os_support.c b/libavformat/os_support.c
index 86d0b8f306..dc3bf65f34 100644
--- a/libavformat/os_support.c
+++ b/libavformat/os_support.c
@@ -46,7 +46,7 @@
 #if !HAVE_INET_ATON
 #include 
 
-int ff_inet_aton(const char *str, struct in_addr *add)
+static int inet_aton(const char *str, struct in_addr *add)
 {
 unsigned int add1 = 0, add2 = 0, add3 = 0, add4 = 0;
 
@@ -61,7 +61,7 @@ int ff_inet_aton(const char *str, struct in_addr *add)
 return 1;
 }
 #else
-int ff_inet_aton(const char *str, struct in_addr *add)
+static int inet_aton(const char *str, struct in_addr *add)
 {
 return inet_aton(str, add);
 }
@@ -92,7 +92,7 @@ int ff_getaddrinfo(const char *node, const char *service,
 sin->sin_family = AF_INET;
 
 if (node) {
-if (!ff_inet_aton(node, >sin_addr)) {
+if (!inet_aton(node, >sin_addr)) {
 if (hints && (hints->ai_flags & AI_NUMERICHOST)) {
 av_free(sin);
 return EAI_FAIL;
-- 
2.15.0.rc1.287.g2b38de12cc

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

[FFmpeg-devel] [PATCH 4/6] libavformat: remove the ff_rtp_get_local_rtcp_port function

[Rostislav Pehlivanov]

Only used by ffserver

Signed-off-by: Rostislav Pehlivanov 
---
 libavformat/libavformat.v | 1 -
 libavformat/rtpproto.c| 6 --
 libavformat/rtpproto.h| 1 -
 3 files changed, 8 deletions(-)

diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 4edf52f45e..87401f7a9b 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -5,7 +5,6 @@ LIBAVFORMAT_MAJOR {
 ff_socket_nonblock;
 ff_rtsp_parse_line;
 ff_rtp_get_local_rtp_port;
-ff_rtp_get_local_rtcp_port;
 ffio_open_dyn_packet_buf;
 ffio_set_buf_size;
 ffurl_close;
diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index 0706cae25f..c01d9cea18 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -636,12 +636,6 @@ int ff_rtp_get_local_rtp_port(URLContext *h)
  * @return the local port number
  */
 
-int ff_rtp_get_local_rtcp_port(URLContext *h)
-{
-RTPContext *s = h->priv_data;
-return ff_udp_get_local_port(s->rtcp_hd);
-}
-
 static int rtp_get_file_handle(URLContext *h)
 {
 RTPContext *s = h->priv_data;
diff --git a/libavformat/rtpproto.h b/libavformat/rtpproto.h
index 5b243fb248..131aac5f3c 100644
--- a/libavformat/rtpproto.h
+++ b/libavformat/rtpproto.h
@@ -26,6 +26,5 @@
 int ff_rtp_set_remote_url(URLContext *h, const char *uri);
 
 int ff_rtp_get_local_rtp_port(URLContext *h);
-int ff_rtp_get_local_rtcp_port(URLContext *h);
 
 #endif /* AVFORMAT_RTPPROTO_H */
-- 
2.15.0.rc1.287.g2b38de12cc

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

[FFmpeg-devel] [PATCH 6/6] libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavformat/mpjpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpjpeg.c b/libavformat/mpjpeg.c
index 3904ccb2b4..80f83c5871 100644
--- a/libavformat/mpjpeg.c
+++ b/libavformat/mpjpeg.c
@@ -23,7 +23,7 @@
 
 /* Multipart JPEG */
 
-#define BOUNDARY_TAG "ffserver"
+#define BOUNDARY_TAG "ffmpeg"
 
 typedef struct MPJPEGContext {
 AVClass *class;
-- 
2.15.0.rc1.287.g2b38de12cc

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

[FFmpeg-devel] [PATCH 5/6] libavformat: unexpose private ff_ functions needed by ffserver

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavformat/libavformat.v | 9 -
 1 file changed, 9 deletions(-)

diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 87401f7a9b..df28e15b0e 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -1,15 +1,6 @@
 LIBAVFORMAT_MAJOR {
 global:
 av*;
-#FIXME those are for ffserver
-ff_socket_nonblock;
-ff_rtsp_parse_line;
-ff_rtp_get_local_rtp_port;
-ffio_open_dyn_packet_buf;
-ffio_set_buf_size;
-ffurl_close;
-ffurl_open;
-ffurl_write;
 #those are deprecated, remove on next bump
 url_feof;
 local:
-- 
2.15.0.rc1.287.g2b38de12cc

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

[FFmpeg-devel] [PATCH 2/6] libavformat: remove the ffmenc and ffmdec muxer and demuxers

[Rostislav Pehlivanov]

Used only by ffserver.

Signed-off-by: Rostislav Pehlivanov 
---
 Changelog|   1 +
 libavformat/Makefile |   2 -
 libavformat/allformats.c |   1 -
 libavformat/ffm.h|  62 
 libavformat/ffmdec.c | 878 ---
 libavformat/ffmenc.c | 362 ---
 6 files changed, 1 insertion(+), 1305 deletions(-)
 delete mode 100644 libavformat/ffm.h
 delete mode 100644 libavformat/ffmdec.c
 delete mode 100644 libavformat/ffmenc.c

diff --git a/Changelog b/Changelog
index 3c453a502a..bec54e5d6e 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
   requires 2.1 (or later) and pkg-config.
 - Removed the ffserver program
+- Removed the ffmenc and ffmdec muxer and demuxer
 
 
 version 3.4:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8111b4ca6a..0bfa27572f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -158,8 +158,6 @@ OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
 OBJS-$(CONFIG_EAC3_DEMUXER)  += ac3dec.o rawdec.o
 OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
 OBJS-$(CONFIG_EPAF_DEMUXER)  += epafdec.o pcm.o
-OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
-OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
 OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5ad9..bee8429aed 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -117,7 +117,6 @@ static void register_all(void)
 REGISTER_MUXDEMUX(EAC3, eac3);
 REGISTER_DEMUXER (EPAF, epaf);
 REGISTER_MUXER   (F4V,  f4v);
-REGISTER_MUXDEMUX(FFM,  ffm);
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
 REGISTER_MUXER   (FIFO, fifo);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
diff --git a/libavformat/ffm.h b/libavformat/ffm.h
deleted file mode 100644
index c445f472f7..00
--- a/libavformat/ffm.h
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * FFM (ffserver live feed) common header
- * Copyright (c) 2001 Fabrice Bellard
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#ifndef AVFORMAT_FFM_H
-#define AVFORMAT_FFM_H
-
-#include 
-#include "avformat.h"
-#include "avio.h"
-
-/* The FFM file is made of blocks of fixed size */
-#define FFM_HEADER_SIZE 14
-#define FFM_PACKET_SIZE 4096
-#define PACKET_ID   0x666d
-
-/* each packet contains frames (which can span several packets */
-#define FRAME_HEADER_SIZE16
-#define FLAG_KEY_FRAME   0x01
-#define FLAG_DTS 0x02
-
-enum {
-READ_HEADER,
-READ_DATA,
-};
-
-typedef struct FFMContext {
-const AVClass *class;
-/* only reading mode */
-int64_t write_index, file_size;
-int read_state;
-uint8_t header[FRAME_HEADER_SIZE+4];
-
-/* read and write */
-int first_packet; /* true if first packet, needed to set the discontinuity 
tag */
-int packet_size;
-int frame_offset;
-int64_t dts;
-uint8_t *packet_ptr, *packet_end;
-uint8_t packet[FFM_PACKET_SIZE];
-int64_t start_time;
-int server_attached;
-} FFMContext;
-
-#endif /* AVFORMAT_FFM_H */
diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
deleted file mode 100644
index de6ac27252..00
--- a/libavformat/ffmdec.c
+++ /dev/null
@@ -1,878 +0,0 @@
-/*
- * FFM (ffserver live feed) demuxer
- * Copyright (c) 2001 Fabrice Bellard
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy 

[FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[Rostislav Pehlivanov]

This patchset removes the long-deprecated ffserver program and all
its privately exposed things from libavformat.

Rostislav Pehlivanov (6):
  Remove the ffserver program
  libavformat: remove the ffmenc and ffmdec muxer and demuxers
  libavformat: unexpose the ff_inet_aton function
  libavformat: remove the ff_rtp_get_local_rtcp_port function
  libavformat: unexpose private ff_ functions needed by ffserver
  libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag

 .gitignore|1 -
 Changelog |2 +
 MAINTAINERS   |3 -
 README.md |2 -
 configure |4 -
 doc/ffmpeg-bitstream-filters.texi |4 +-
 doc/ffmpeg-codecs.texi|4 +-
 doc/ffmpeg-devices.texi   |4 +-
 doc/ffmpeg-filters.texi   |4 +-
 doc/ffmpeg-formats.texi   |4 +-
 doc/ffmpeg-protocols.texi |4 +-
 doc/ffmpeg-resampler.texi |4 +-
 doc/ffmpeg-scaler.texi|4 +-
 doc/ffmpeg-utils.texi |4 +-
 doc/ffmpeg.texi   |   18 +-
 doc/ffplay.texi   |4 +-
 doc/ffprobe.texi  |4 +-
 doc/ffserver.conf |  372 
 doc/ffserver.texi |  923 -
 doc/issue_tracker.txt |3 -
 doc/libavcodec.texi   |4 +-
 doc/libavdevice.texi  |4 +-
 doc/libavfilter.texi  |4 +-
 doc/libavformat.texi  |4 +-
 doc/libavutil.texi|4 +-
 doc/libswresample.texi|4 +-
 doc/libswscale.texi   |4 +-
 doc/mailing-list-faq.texi |3 +-
 doc/protocols.texi|2 +-
 fftools/Makefile  |4 +-
 fftools/ffmpeg_opt.c  |   96 +-
 fftools/ffserver.c| 4026 -
 fftools/ffserver_config.c | 1325 
 fftools/ffserver_config.h |  155 --
 libavformat/Makefile  |2 -
 libavformat/allformats.c  |1 -
 libavformat/ffm.h |   62 -
 libavformat/ffmdec.c  |  878 
 libavformat/ffmenc.c  |  362 
 libavformat/libavformat.v |   11 -
 libavformat/mpjpeg.c  |2 +-
 libavformat/network.h |2 -
 libavformat/os_support.c  |6 +-
 libavformat/rtpproto.c|6 -
 libavformat/rtpproto.h|1 -
 tests/Makefile|   10 -
 tests/ffserver-regression.sh  |   45 -
 tests/ffserver.conf   |  311 ---
 tests/ffserver.regression.ref |   11 -
 tools/bisect-create   |2 +-
 50 files changed, 49 insertions(+), 8674 deletions(-)
 delete mode 100644 doc/ffserver.conf
 delete mode 100644 doc/ffserver.texi
 delete mode 100644 fftools/ffserver.c
 delete mode 100644 fftools/ffserver_config.c
 delete mode 100644 fftools/ffserver_config.h
 delete mode 100644 libavformat/ffm.h
 delete mode 100644 libavformat/ffmdec.c
 delete mode 100644 libavformat/ffmenc.c
 delete mode 100755 tests/ffserver-regression.sh
 delete mode 100644 tests/ffserver.conf
 delete mode 100644 tests/ffserver.regression.ref

-- 
2.15.0.rc1.287.g2b38de12cc

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

[FFmpeg-devel] Job Request | Audio Codecs

[Dylan Marcus]

Hello, 

I am interested in hiring someone to expand FFmpeg with a flag that changes the 
behavior of channel ordering for as many audio codecs as possible. When this 
flag is seen in the command line it has FFmpeg use slightly modified channel 
order and channel assignment (TYPESCE instead of TYPELFE) to allow more use 
cases that are outside of Surround Formats which can be very destructive to 
FFmpeg uses for newer audio formats such as spatial audio and audio for 
interactive installations or games. 
After this it would be fantastic to expand common audio codecs (pcm, aac, 
vorbis/ogg) to support +8 channels. 

Apologies if this is not the best way to contact everyone, this is my first 
email to the ffmpeg-devel chain. 

Best,
Dylan

--

340.29 m / s

MACH 1 
A Sound Technology Company.
New York New York
The United States of America.

LEGAL NOTICE

The contents of this message may be privileged and confidential. Therefore, if 
this message has been received in error, please delete it without reading it. 
All contents of the message, including any attachments, are the copyright 
property of Q Department, L.L.C. This message cannot in any way bind Q 
Department, L.L.C. to any contract or other obligation.

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

Re: [FFmpeg-devel] order T-shirts

[Lou Logan]

On Sat, Oct 21, 2017, at 08:38 AM, Thilo Borgmann wrote:
> We can use another color for sure. I guess multicolor printings would
> raise the price, though.

I assume it will raise the price if it is screenprinted, but I'm not
sure by how much.

> Do you think this would actually look better?

Yes, compared to the all white logo. The logo is green. I would want it
to be green on a shirt too. I think it's more familiar and recognizable
as green instead of white.

> Black/white shirts were preferred by the people wearing them during CLT
> for the past few years.

I was thinking of black shirt, green logo, white "FFmpeg" lettering.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Bump major versions of all libraries

[James Almer]

On 9/2/2017 1:23 PM, James Almer wrote:
> From: Vittorio Giovara 
> 
> This disables almost everything that was deprecated at least two years ago
> 
> Readjust the minimum API version as needed, postponing any
> API-incompatible changes until the next bump.
> 
> (cherry picked from commit 07a2b155949eb267cdfc7805f42c7b3375f9c7c5)
> Signed-off-by: Vittorio Giovara 
> Signed-off-by: James Almer 
> ---
> This depends on "[RFC] avcodec: add AV_HWACCEL_CODEC_CAP_EXPERIMENTAL flag"
> and is meant to be applied after release 3.4 is branched off from master,
> as requested by both Michael and Marton.
> This patch does not include the cleaning that will come afterwards, like
> removing all the dead code inside the disabled FF_API_ wrappers. Those
> commits will be cherry-picked or authored as needed later.
> 
> Three API deprecated ~2 years ago or more are also postponed here for
> varying reasons.
> 
> FF_API_LOWRES:
> Since this functionality depends on AVStream->codec, i figure the two can
> be removed at the same time in the next bump or so.
> 
> FF_API_AVCTX_TIMEBASE:
> Couldn't get this one to work. Not just libavcodec but apparently also
> libavformat and ffmpeg.c expect AVCodecContext->time_base to be set for
> decoding. Upon removal some tests report a different generic stream time
> base (like 1/25), and others lose packet duration values. I guess it's
> somehow tied to the AVStream->codec clusterfuck.
> Help would be very welcome on removing this one. Otherwise it can be dealt
> with alongside AVStream->codec in the next bump.
> 
> FF_API_OLD_FILTER_OPTS_ERROR:
> This one is meant to remain after FF_API_OLD_FILTER_OPTS is removed.
> Its purpose is displaying the corrected command line using the new syntax
> as a suggestion as part of the error message.
> Please, do not report command lines using the old syntax suddenly not
> working.
> 
> 
> Notes:
> I have no way to test what effect the removal of XVMC truly has.
> The decoders are removed but unlike libav we have hwaccels that are not
> removed by this. Similarly, the pixfmt is also not removed in our case.
> Commit dcc39ee10e82833ce24aa57926c00ffeb1948198 does a thorough removal
> of the remnants of this functionality, but given the above i don't know
> if that applies to us the same way.
> I assume the hwaccels are meant to stay and work after this, so someone
> that knows this code and functionality and has a system where it can be
> tested should ideally look at this.
> 
> After the bump there's a grace period of a month or so up to at most when
> the first post-bump release is tagged, to do the general ABI cleaning this
> allows us to. This includes but is not limited to:
> 
> - Fixing field offsets of private fields in public structs by moving them
>   to the end fo the struct (properly drawing the line where fields stop
>   being public), or directly to internal structs.
> - Deprecating get/setters created because said offsets were out of whack,
>   and removing their usage within the libraries.
> - Removing public enum value gaps that were missed during the last bump.
> - Removing usage of internal API in avpriv_ functions (GetBitContext
>   especially), or altering said functions in whatever way may be needed.
> - Stop exposing internal API from libavformat.
> 
> The latter includes the scheduled removal of ffserver, as resolved in last
> November's vote. A fixed version or even a full replacement working
> exclusively with public API can be introduced at any point afterwards, so
> please, lets not start a new fight like we had last November.
> Of course, if someone goes and fixes it inside the grace period then there
> will be no need to remove it at all. But that sounds kinda unfeasible
> considering nine months have passed since the vote and nobody even gave it
> a try.

Ok, I've reached this commit in the merge queue and applied it. Now
starts a month or two long period where we can do a general ABI cleaning
like i listed above.
As usual, and like APIChanges mentions, the API/ABI should be considered
unstable during the aforementioned period.

Help cleaning public structs and similar tasks very much welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] fate/hap : add test for HAPQA decoding

[Martin Vignali]

Hello,

Sample can be found here
https://we.tl/1XuI6QJ7Ra

and need to be put inside ./fate-suite/hap

can be test with
make fate-hap SAMPLES=fate-suite/

Need to be apply after patch in discussion
libavcodec/hapdec : add support for hapqa decoding

Martin


0005-fate-hapdec-add-test-for-hapqa-decoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] libavcodec/blockdsp : fix comment

[Martin Vignali]

Hello,

in attach patch to fix comment in blockdsp

the dsp need align 32 now.

Martin


0001-libavcodec-blockdsp-fix-comment.-clear_block-need-32.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] libavcodec/hapdec : add support for hapqa decoding

[Martin Vignali]

Hello,

I split the previous patch for HAPQAlpha decoding
in several part, to be easier to read

0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
prepare for multi texture support but only decode the first texture

0003-libavcodec-hapdec-indent-after-previous-commit :
Cosmetic : indent

0004-libavcodec-hapdec-add-support-for-hapqa-decoding :
Decode HAQA, and support 2 texture decoding

Pass fate-hap for me (os 10.12, x86_64)

Martin
Jokyo Images


0002-libavcodec-hapdec-reorganize-code-before-adding-mult.patch
Description: Binary data


0003-libavcodec-hapdec-indent-after-previous-commit.patch
Description: Binary data


0004-libavcodec-hapdec-add-support-for-hapqa-decoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

> Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

The commit message needs adjustment "lavfi/paletteuse: ..."

[...]
>  struct color_node {
> -uint8_t val[3];
> +uint8_t val[4];
>  uint8_t palette_id;
>  int split;
>  int left_id, right_id;
> @@ -86,6 +86,8 @@ typedef struct PaletteUseContext {
>  struct cache_node cache[CACHE_SIZE];/* lookup cache */
>  struct color_node map[AVPALETTE_COUNT]; /* 3D-Tree (KD-Tree with K=3) 
> for reverse colormap */
>  uint32_t palette[AVPALETTE_COUNT];

> +int transparency_index; /* index in the palette of transparency. -1 if 
> there isn't a transparency. */

"if there is no transparent color" might be more correct but I'm not a
native speaker.

> +int trans_thresh;
>  int palette_loaded;
>  int dither;
>  int new;
> @@ -116,6 +118,7 @@ static const AVOption paletteuse_options[] = {
>  { "bayer_scale", "set scale for bayer dithering", OFFSET(bayer_scale), 
> AV_OPT_TYPE_INT, {.i64=2}, 0, 5, FLAGS },
>  { "diff_mode",   "set frame difference mode", OFFSET(diff_mode),   
> AV_OPT_TYPE_INT, {.i64=DIFF_MODE_NONE}, 0, NB_DIFF_MODE-1, FLAGS, "diff_mode" 
> },
>  { "rectangle", "process smallest different rectangle", 0, 
> AV_OPT_TYPE_CONST, {.i64=DIFF_MODE_RECTANGLE}, INT_MIN, INT_MAX, FLAGS, 
> "diff_mode" },

> +{ "threshold", "set the alpha threshold for transparency. Above this 
> threshold, pixels are considered opaque, below they are considered 
> transparent.", OFFSET(trans_thresh), AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },

The long explanation belongs in doc/filters.texi

[...]
> -static av_always_inline int diff(const uint8_t *c1, const uint8_t *c2)
> +static av_always_inline int diff(const uint8_t *c1, const uint8_t *c2, const 
> int trans_thresh)
>  {
>  // XXX: try L*a*b with CIE76 (dL*dL + da*da + db*db)
> -const int dr = c1[0] - c2[0];
> -const int dg = c1[1] - c2[1];
> -const int db = c1[2] - c2[2];
> -return dr*dr + dg*dg + db*db;

> +const static int max_diff = 195075; //equal to 255*255 + 255*255 + 
> 255*255

That's not what I meant; I wasn't concerned about the expression but the
static const int. I was thinking "return 255*255 + 255*255 + 255*255"

[...]
>  /**
>   * Check if the requested color is in the cache already. If not, find it in 
> the
>   * color tree and cache it.
> - * Note: r, g, and b are the component of c but are passed as well to avoid
> + * Note: a, r, g, and b are the components of argb, but are passed as well 
> to avoid
>   * recomputing them (they are generally computed by the caller for other 
> uses).
>   */
> -static av_always_inline int color_get(struct cache_node *cache, uint32_t 
> color,
> -  uint8_t r, uint8_t g, uint8_t b,

> +static av_always_inline int color_get(struct cache_node *cache, uint32_t 
> argb,

I'm sorry to insist, but renaming "color" belongs in another commit.

[...]
>  static av_always_inline int get_dst_color_err(struct cache_node *cache,

> -  uint32_t c, const struct 
> color_node *map,
> +  uint32_t argb, const struct 
> color_node *map,

ditto, "c" should be renamed in another commit

[...]
>  i = 0;
>  for (y = 0; y < palette_frame->height; y++) {
> -for (x = 0; x < palette_frame->width; x++)
> -s->palette[i++] = p[x];
> +for (x = 0; x < palette_frame->width; x++) {
> +s->palette[i] = p[x];
> +if (p[x]>>24 < s->trans_thresh) {
> +s->transparency_index = i; // we are assuming at most one 
> transparent color in palette
> +}

> +++i;

i++ is the appropriate idiom.

Aside from these nitpicks, I'm still concerned about how it's going to
conflict with GIF encoding where the transparent color is actually used as
a mean of not updating pixels from previous frames.

-- 
Clément B.


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

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Hi,
> On Fri, Oct 20, 2017, at 07:16 AM, Thilo Borgmann wrote:
>> If there are no objections, I will order them and ship early next week :)
> 
> Can we use a color logo? 

We can use another color for sure. I guess multicolor printings would raise the 
price, though.
I will ask them about it. 
 

> You can use my non-gradient logo variant that I
> made for the hypothetical shirts I was going to make but never did. I'll
> attach the SVG file when I get back home on Monday or Tuesday. It looks
> like this but with white lettering:
> 
> 

Do you think this would actually look better?
I doubt three colors (including shirt color) would look better.

Black/white shirts were preferred by the people wearing them during CLT for the 
past few years.
We had a bright-green/white before that. Dark-green/white might also look good. 
The question of colors is of course all open. However, to my experience black 
is the most favored shirt color for stuff like that.

I could do several color combination if people would like me to. I think we 
should keep the amount of combinations small for the recognition value of the 
shirt.

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

Re: [FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

[Nicolas George]

Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :
> I thought filenames in libavformat are limited to 1K anyway because of the
> AVFormatContext->filename field. So if your patch really fixes the ticket,
> then how? :)

Yes, exactly. This limitation was the reason I did not bother handling
longer lines. I would like to understand how it makes a difference.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

[Marton Balint]

On Fri, 20 Oct 2017, Carl Eugen Hoyos wrote:


Hi!

I believe that the use-case is valid and there is definitely a bug
because no error is shown for too long filenames.
In addition, allocating 50k on the heap seems nicer than 4k on the stack.


50k is not much better than 4k. You should add an ff_get_line variant 
which dynamically allocates the needed buffer.


Also you should free buf somewhere eventually.

I thought filenames in libavformat are limited to 1K anyway because of the 
AVFormatContext->filename field. So if your patch really fixes the ticket, 
then how? :)


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

Re: [FFmpeg-devel] order T-shirts

[Lou Logan]

Hi,

On Fri, Oct 20, 2017, at 07:16 AM, Thilo Borgmann wrote:
> If there are no objections, I will order them and ship early next week :)

Can we use a color logo? You can use my non-gradient logo variant that I
made for the hypothetical shirts I was going to make but never did. I'll
attach the SVG file when I get back home on Monday or Tuesday. It looks
like this but with white lettering:



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

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Am 21.10.17 um 00:30 schrieb Timo Rothenpieler:
> Am 20.10.2017 um 17:16 schrieb Thilo Borgmann:
>> Hi,
>>
 Some guys at the VDD asked for FFmpeg T-shirts.
 I'd like to do a new T-shirt order. The shirts could be given to
 multimedia devs who stop at one of our next booths.

 My idea is to order 25 shirts:

 1*S
 5*M
 10*L
 7*XL
 2*XXL

 Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
 So, we are talking about a maximum price of 562,50 Euro (excluding
 delivery costs).
>>>
>>> since I had my own shirt exchanged during VDD, I don't even have one for 
>>> the next conf thing I might go to so I hereby revive this thread. I 
>>> promised some shirts to Mozilla, Nicolas reminded me of getting one for him 
>>> also during VDD...
>>>
>>> I went to a nice shop today and they can offer a quite nice price for 
>>> shirts based on Thomas' last design with breast and neck printings. So I 
>>> ordered four samples for just 12€ each! I had the unprinted shirts in my 
>>> hand and the quality is good in spite of that nice price. I even think that 
>>> 12€ per shirt can't be beaten by Liu's offer to have them printed in 
>>> China... shipping should eat up anything we might save by China-shirts.
>>>
>>> I'll get the printed samples tomorrow and one of these will definitely find 
>>> its way to Nicolas.
>>> If we're happy with the samples, I'd like to order a pile of shirts for us 
>>> and that could be the amount Thomas listed in the beginning of this thread. 
>>> I'd also like to add some more for the shirts I've already promised to send 
>>> to several people. This means I expect something like 350-400€ including 
>>> shipping to various places.
>>>
>>> This is even cheaper than what Thomas estimation was so I hope nobody 
>>> objects :)
>>>
>>> This shop can also do stitching on basecaps, with a little longer waiting 
>>> time also the coffee mugs.
>>> I also talked about stickers that would come in a similar manner like the 
>>> nice ones we got from the Kodi guy some years ago and that are almost gone. 
>>> However I want to get the shirts done first.
>>
>> I got the samples done and I think they are good! You can find pictures of 
>> what the design is here:
>> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
>>
>> I add to the numbers for our stock of shirts (list quoted above) the 
>> additional need I have for already assigned/promised shirts and subtract the 
>> number of samples I made, what comes out are the following numbers:
>>
>> S    1
>> M    6
>> L   11
>> XL  11
>> 2XL  3
>>
>> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
>> Then there will be some costs for shipping, so I expect a low 400+ € total.
>>
>> If there are no objections, I will order them and ship early next week :)
>>
>> -Thilo
> 
> I'd also like one.
> Will send you an E-Mail size and address.

Recieved, consider it done.

-Thilo

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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Jan Ekstrom]

On Tue, Oct 17, 2017 at 11:29 AM, Daniel Kucera  wrote:
> transfer_func variable passed to retry_transfer_wrapper
> are h->prot->url_read and h->prot->url_write functions.
> These need to return EOF or other error properly.
> In case of returning >= 0, url_read/url_write is retried
> until error is returned.

This seems to have broken seeking and files ending. FLAC was
experienced yesterday but it seems like it's more general. This was
reported on the mpv users' channel by sfan5, but I feel like this
might be more general than related to just mpv. At first this was
thought to be limited to HTTP, but later was found out to be
applicable to local files as well.

Quote:
< wm4> reproduction is "play anything with lavf"
< JEEB> oh really? and seek?
< sfan5> yes
< wm4> no, seek close to end of file and see if it ends correctly. if
it freezes it's the bug
< sfan5> sounds like two different bugs
< sfan5> bug 1: files don't end correctly
< sfan5> bug 2: seeking somewhere never finishes and spins the cpu
< sfan5> 2 is what i was experiencing yesterday


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Dixit, Vishwanath]

Hi,

Please find the attached patches which add support to create multiple HLS 
variant streams and master playlist.

Key advantages:

  1.  A single HLS encoder instance can handle multiple variant streams now. 
Otherwise, a separate HLS encoder instance was needed for each variant stream. 
So, now a single set of HLS parameters can be provided in the command line for 
creating multiple variant streams.
  2.  Variant streams can be created as muxed AV media segments or separate AV 
media segments. Having separate AV media segments helps to re-use a single 
audio for multiple video only variant streams.
  3.  Creating variant streams in a single hlsenc instance simplifies the 
master playlist creation, as one hlsenc plugin handle will have details of all 
the variant streams.

Logic:
Same logic of creating variant streams in DASH encoder plugin has been 
implemented here. It appears that there are lot of changes in the first patch. 
However, most of the changes are due to movement of HLS context structure 
parameters to new variant stream structure. Because of this, in many places the 
variable names ‘s’ and ‘hls’ have been replace by ‘vs’. Just an additional loop 
in write_header and write_trailer function handles creation of multiple variant 
streams.

Future updates:
Currently master playlist creation patch creates a basic master playlist. I 
will be submitting one more patch over this which will handle mapping of 
different rendition streams using #EXT-X-MEDIA and audio group id tags.

Regards,
Vishwanath


0001-libavformat-hlsenc-creation-of-hls-variant-streams-i.patch
Description: 0001-libavformat-hlsenc-creation-of-hls-variant-streams-i.patch


0002-libavformat-hlsenc-creation-of-hls-master-playlist-f.patch
Description: 0002-libavformat-hlsenc-creation-of-hls-master-playlist-f.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel