Re: [FFmpeg-devel] [PATCH] lavc/qsv: skip the packet if decoding failure.

[Song, Ruiling]

> -Original Message-
> From: Jun Zhao [mailto:mypopy...@gmail.com]
> Sent: Friday, January 26, 2018 1:02 PM
> To: FFmpeg development discussions and patches ;
> Song, Ruiling 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsv: skip the packet if decoding 
> failure.
> 
> 
> 
> On 2018/1/25 16:37, Ruiling Song wrote:
> > From: "Ruiling, Song" 
> >
> > MediaSDK may fail to decode some frame, just skip it.
> > Otherwise, it will keep decoding the failure packet repeatedly
> > without processing any packet afterwards.
> >
> > v2:
> > switch to using av_packet_unref().
> >
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavcodec/qsvdec_h2645.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
> > index 5e00673..d92a150 100644
> > --- a/libavcodec/qsvdec_h2645.c
> > +++ b/libavcodec/qsvdec_h2645.c
> > @@ -153,8 +153,12 @@ static int qsv_decode_frame(AVCodecContext *avctx,
> void *data,
> >  }
> >
> >  ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame, 
> >buffer_pkt);
> > -if (ret < 0)
> > +if (ret < 0) {
> > +/* Drop buffer_pkt when failed to decode the packet. Otherwise,
> > +   the decoder will keep decoding the failure packet. */
> > +av_packet_unref(>buffer_pkt);
> 
> I think add a warning message more better than only drop the packet on
> the quiet.
What do you think "packet decoding failed, skip it."?
Usually some error message has already been printed out before skipping the 
packet.
I am OK to make a new version to address it. And thanks for your feedback.

Ruiling
> >  return ret;
> > +}
> >
> >  s->buffer_pkt.size -= ret;
> >  s->buffer_pkt.data += ret;

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

Re: [FFmpeg-devel] [PATCH] fate: add id3v2 test

[Richard Shaffer]

>From f7398407c1f5822e1536ce03d46c885b2ad00c38 Mon Sep 17 00:00:00 2001
From: Richard Shaffer 
Date: Thu, 25 Jan 2018 19:54:59 -0800
Subject: [PATCH] fate: add id3v2 test

Adds basic unit test for parsing ID3v2 tags.
---
This follows the suggestion to use the ffprobe utility instead of a
test program.

The required test sample is attached.

-Richard

tests/Makefile | 1 +
tests/fate-run.sh | 4 
tests/fate/id3v2.mak | 6 ++
tests/ref/fate/id3v2-read | 5 +
4 files changed, 16 insertions(+)
create mode 100644 tests/fate/id3v2.mak
create mode 100644 tests/ref/fate/id3v2-read

diff --git a/tests/Makefile b/tests/Makefile
index 14b9601378..327e3f4420 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -130,6 +130,7 @@ include $(SRC_PATH)/tests/fate/gapless.mak
include $(SRC_PATH)/tests/fate/gif.mak
include $(SRC_PATH)/tests/fate/h264.mak
include $(SRC_PATH)/tests/fate/hevc.mak
+include $(SRC_PATH)/tests/fate/id3v2.mak
include $(SRC_PATH)/tests/fate/image.mak
include $(SRC_PATH)/tests/fate/indeo.mak
include $(SRC_PATH)/tests/fate/libavcodec.mak
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 05f4ca5e20..82862b7ef4 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -88,6 +88,10 @@ probefmt(){
run ffprobe${PROGSUF} -show_entries format=format_name -print_format
default=nw=1:nk=1 -v 0 "$@"
}
+probetags(){
+ run ffprobe${PROGSUF} -show_entries format_tags -v 0 "$@"
+}
+
runlocal(){
test "${V:-0}" -gt 0 && echo ${base}/"$@" ${base} >&3
${base}/"$@" ${base}
diff --git a/tests/fate/id3v2.mak b/tests/fate/id3v2.mak
new file mode 100644
index 00..af60ee12b5
--- /dev/null
+++ b/tests/fate/id3v2.mak
@@ -0,0 +1,6 @@
+ID3V2_TEST_FILE=tests/data/id3v2-test.mp3
+
+FATE_SAMPLES_ID3V2-$(CONFIG_MP3_DEMUXER) += fate-id3v2-read
+fate-id3v2-read: CMD = probetags $(TARGET_SAMPLES)/id3v2/id3v2-test.mp3
+
+FATE_SAMPLES_FFPROBE += $(FATE_SAMPLES_ID3V2-yes)
\ No newline at end of file
diff --git a/tests/ref/fate/id3v2-read b/tests/ref/fate/id3v2-read
new file mode 100644
index 00..965c8695e8
--- /dev/null
+++ b/tests/ref/fate/id3v2-read
@@ -0,0 +1,5 @@
+[FORMAT]
+TAG:title=id3v2-test
+TAG:id3v2_priv.testowner=testdata
+TAG:id3v2_priv.testowner2=\x00\x01\x02
+[/FORMAT]
-- 
2.14.3 (Apple Git-98)


id3v2-test.mp3
Description: audio/mpeg
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/qsv: skip the packet if decoding failure.

[Jun Zhao]

On 2018/1/25 16:37, Ruiling Song wrote:
> From: "Ruiling, Song" 
>
> MediaSDK may fail to decode some frame, just skip it.
> Otherwise, it will keep decoding the failure packet repeatedly
> without processing any packet afterwards.
>
> v2:
> switch to using av_packet_unref().
>
> Signed-off-by: Ruiling Song 
> ---
>  libavcodec/qsvdec_h2645.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
> index 5e00673..d92a150 100644
> --- a/libavcodec/qsvdec_h2645.c
> +++ b/libavcodec/qsvdec_h2645.c
> @@ -153,8 +153,12 @@ static int qsv_decode_frame(AVCodecContext *avctx, void 
> *data,
>  }
>  
>  ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame, 
> >buffer_pkt);
> -if (ret < 0)
> +if (ret < 0) {
> +/* Drop buffer_pkt when failed to decode the packet. Otherwise,
> +   the decoder will keep decoding the failure packet. */
> +av_packet_unref(>buffer_pkt);

I think add a warning message more better than only drop the packet on
the quiet. 

>  return ret;
> +}
>  
>  s->buffer_pkt.size -= ret;
>  s->buffer_pkt.data += ret;

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

Re: [FFmpeg-devel] [PATCH] lavc/qsv: skip the packet if decoding failure.

[Jun Zhao]

On 2018/1/25 16:37, Ruiling Song wrote:
> From: "Ruiling, Song" 
>
> MediaSDK may fail to decode some frame, just skip it.
> Otherwise, it will keep decoding the failure packet repeatedly
> without processing any packet afterwards.
>
> v2:
> switch to using av_packet_unref().
>
> Signed-off-by: Ruiling Song 
> ---
>  libavcodec/qsvdec_h2645.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
> index 5e00673..d92a150 100644
> --- a/libavcodec/qsvdec_h2645.c
> +++ b/libavcodec/qsvdec_h2645.c
> @@ -153,8 +153,12 @@ static int qsv_decode_frame(AVCodecContext *avctx, void 
> *data,
>  }
>  
>  ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame, 
> >buffer_pkt);
> -if (ret < 0)
> +if (ret < 0) {
> +/* Drop buffer_pkt when failed to decode the packet. Otherwise,
> +   the decoder will keep decoding the failure packet. */
> +av_packet_unref(>buffer_pkt);

I think add a warning message more better than only drop the packet on
the quiet. 

>  return ret;
> +}
>  
>  s->buffer_pkt.size -= ret;
>  s->buffer_pkt.data += ret;

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

[FFmpeg-devel] [PATCH] lavc/aarch64/sbrdsp_neon: fix build on old binutils

[Rodger Combs]

---
 libavcodec/aarch64/sbrdsp_neon.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aarch64/sbrdsp_neon.S b/libavcodec/aarch64/sbrdsp_neon.S
index d1d79b749c..d23717e760 100644
--- a/libavcodec/aarch64/sbrdsp_neon.S
+++ b/libavcodec/aarch64/sbrdsp_neon.S
@@ -287,7 +287,7 @@ endfunc
 zip1v4.4S, v4.4S, v4.4S
 fmlav6.4S, v1.4S, v3.4S
 fmlav2.4S, v5.4S, v4.4S
-fcmeq   v7.4S, v3.4S, #0.0
+fcmeq   v7.4S, v3.4S, #0
 bif v2.16B, v6.16B, v7.16B
 st1 {v2.4S}, [x0], #16
 subsx5, x5, #2
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Check ret on avformat_write_header

[刘歧]

> On 24 Jan 2018, at 09:24, Brendan McGrath  wrote:
> 
> Encoding currently fails when using hls_ts_options with the fmp4
> segment type.
> 
> This is due to the fact that avformat_write_header does not process
> the passed options when the avformat is already initialized.
> 
> When using fmp4, the hls_ts_options are parsed and the avformat
> initialized within hls_mux_init.
> 
> This patch checks the return of avformat_write_header so that if
> it is greater than zero (indicating the avformat is already
> initialized) then it does not error.
> 
> Signed-off-by: Brendan McGrath 
> ---
> I'm not sure if hls_ts_options is supposed to be used with fmp4 as the
> description is currently:
> hls_ts_options E... set hls mpegts list of options for 
> the container format used for hls
> 
> If it is (and the code within hls_mux_init seems to indicate that it is) - 
> then this
> patch fixes that (and the next will change the description - perhaps the 
> option should
> be renamed too?).

maybe fmp4 need not use this option in short time.
> 
> I also considered checking if ret was < 0 and erroring immediately rather 
> than relying
> on av_dict_count. But I wasn't sure if that check had been intentionally left 
> out
> so the av_dict_free would take place.
> 
> Let me know if the preference is for another if statement for ret < 0.
> 
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 42e437f..d83d3b9 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1878,7 +1878,7 @@ static int hls_write_header(AVFormatContext *s)
> 
> av_dict_copy(, hls->format_options, 0);
> ret = avformat_write_header(vs->avf, );
> -if (av_dict_count(options)) {
> +if (ret <= 0 && av_dict_count(options)) {
> av_log(s, AV_LOG_ERROR, "Some of provided format options in '%s' 
> are not recognized\n", hls->format_options_str);
> ret = AVERROR(EINVAL);
> av_dict_free();
> -- 
> 2.7.4
> 
> ___
> 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 3/3] hls: don't print a certain warning if playlist loading is aborted

[刘歧]

> On 24 Jan 2018, at 15:08, wm4  wrote:
> 
> AVERROR_EXIT happens when the user's interrupt callback signals that
> playback should be aborted. In this case, the demuxer shouldn't print a
> warning, as it's expected that all network accesses are stopped.
> ---
> libavformat/hls.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 6e1a2e3f1e..02e764f932 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1422,8 +1422,9 @@ reload:
> if (!v->finished &&
> av_gettime_relative() - v->last_load_time >= reload_interval) {
> if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
> -av_log(v->parent, AV_LOG_WARNING, "Failed to reload playlist 
> %d\n",
> -   v->index);
> +if (ret != AVERROR_EXIT)
> +av_log(v->parent, AV_LOG_WARNING, "Failed to reload 
> playlist %d\n",
> +   v->index);
> return ret;
> }
> /* If we need to reload the playlist again below (if
> -- 
> 2.15.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patchset LGTM


Thanks
Steven

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Check ret on avformat_write_header

[刘歧]

> On 24 Jan 2018, at 09:24, Brendan McGrath  wrote:
> 
> Encoding currently fails when using hls_ts_options with the fmp4
> segment type.
> 
> This is due to the fact that avformat_write_header does not process
> the passed options when the avformat is already initialized.
> 
> When using fmp4, the hls_ts_options are parsed and the avformat
> initialized within hls_mux_init.
> 
> This patch checks the return of avformat_write_header so that if
> it is greater than zero (indicating the avformat is already
> initialized) then it does not error.
> 
> Signed-off-by: Brendan McGrath 
> ---
> I'm not sure if hls_ts_options is supposed to be used with fmp4 as the
> description is currently:
> hls_ts_options E... set hls mpegts list of options for 
> the container format used for hls
> 
> If it is (and the code within hls_mux_init seems to indicate that it is) - 
> then this
> patch fixes that (and the next will change the description - perhaps the 
> option should
> be renamed too?).
> 
> I also considered checking if ret was < 0 and erroring immediately rather 
> than relying
> on av_dict_count. But I wasn't sure if that check had been intentionally left 
> out
> so the av_dict_free would take place.
> 
> Let me know if the preference is for another if statement for ret < 0.
> 
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 42e437f..d83d3b9 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1878,7 +1878,7 @@ static int hls_write_header(AVFormatContext *s)
> 
> av_dict_copy(, hls->format_options, 0);
> ret = avformat_write_header(vs->avf, );
> -if (av_dict_count(options)) {
> +if (ret <= 0 && av_dict_count(options)) {
> av_log(s, AV_LOG_ERROR, "Some of provided format options in '%s' 
> are not recognized\n", hls->format_options_str);
> ret = AVERROR(EINVAL);
> av_dict_free();
> -- 
> 2.7.4
> 
> 

Should be ok


Thanks
Steven

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

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Signal http end of chunk(http_shutdown) explicitly

[Jeyapal, Karthick]

On 1/2/18 1:49 PM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> Currently http end of chunk is signalled implicitly in dashenc_io_open().
> This mean playlists http writes would have to wait upto a segment duration to 
> signal end of chunk causing delays.
> This patch will fix that problem and improve performance.
> ---
>  libavformat/dashenc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 2e4ff67..c9cc389 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -149,7 +149,10 @@ static void dashenc_io_close(AVFormatContext *s, 
> AVIOContext **pb, char *filenam
>  ff_format_io_close(s, pb);
>  #if CONFIG_HTTP_PROTOCOL
>  } else {
> +URLContext *http_url_context = ffio_geturlcontext(*pb);
> +av_assert0(http_url_context);
>  avio_flush(*pb);
> +ffurl_shutdown(http_url_context, AVIO_FLAG_WRITE);
>  #endif
>  }
>  }

Patchset pushed.

Regards,
Karthick



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

[FFmpeg-devel] [PATCH 2/2] avcodec/indeo5: Do not leave frame_type set to an invalid value

[Michael Niedermayer]

Fixes: null pointer dereference
Fixes: 5264/clusterfuzz-testcase-minimized-4621956621008896

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/indeo5.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/indeo5.c b/libavcodec/indeo5.c
index 81b4514038..b39cffd9a9 100644
--- a/libavcodec/indeo5.c
+++ b/libavcodec/indeo5.c
@@ -324,6 +324,7 @@ static int decode_pic_hdr(IVI45DecContext *ctx, 
AVCodecContext *avctx)
 ctx->frame_type  = get_bits(>gb, 3);
 if (ctx->frame_type >= 5) {
 av_log(avctx, AV_LOG_ERROR, "Invalid frame type: %d \n", 
ctx->frame_type);
+ctx->frame_type = FRAMETYPE_INTRA;
 return AVERROR_INVALIDDATA;
 }
 
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/dirac_dwt: Fix several integer overflows

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: -2146071175 + -268479557 cannot 
be represented in type 'int'
Fixes: 5237/clusterfuzz-testcase-minimized-4569895275593728

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dirac_dwt.h  | 4 ++--
 libavcodec/dirac_dwt_template.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index 1af41e0702..68ebd19560 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -93,10 +93,10 @@ void ff_spatial_idwt_slice2(DWTContext *d, int y);
 
 // shared stuff for simd optimizations
 #define COMPOSE_53iL0(b0, b1, b2)\
-(b1 - ((int)(b0 + (unsigned)(b2) + 2) >> 2))
+(b1 - (unsigned)((int)(b0 + (unsigned)(b2) + 2) >> 2))
 
 #define COMPOSE_DIRAC53iH0(b0, b1, b2)\
-(b1 + ((int)(b0 + (unsigned)(b2) + 1) >> 1))
+(b1 + (unsigned)((int)(b0 + (unsigned)(b2) + 1) >> 1))
 
 #define COMPOSE_DD97iH0(b0, b1, b2, b3, b4)\
 (int)(((unsigned)(b2) + ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 8) >> 4)))
diff --git a/libavcodec/dirac_dwt_template.c b/libavcodec/dirac_dwt_template.c
index e436c247a1..e68cc4d530 100644
--- a/libavcodec/dirac_dwt_template.c
+++ b/libavcodec/dirac_dwt_template.c
@@ -49,7 +49,7 @@ static void RENAME(vertical_compose53iL0)(uint8_t *_b0, 
uint8_t *_b1, uint8_t *_
 TYPE *b1 = (TYPE *)_b1;
 TYPE *b2 = (TYPE *)_b2;
 for (i = 0; i < width; i++)
-b1[i] -= (int)(b0[i] + (unsigned)b2[i] + 2) >> 2;
+b1[i] -= (unsigned)((int)(b0[i] + (unsigned)b2[i] + 2) >> 2);
 }
 
 static av_always_inline void RENAME(interleave)(TYPE *dst, TYPE *src0, TYPE 
*src1, int w2,
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

[Bang He]

On Thu, Jan 25, 2018 at 7:44 AM, Ben Chang  wrote:

> Hi,
>
> Please help review this patch to reduce stack frame size per GPU thread.
> The default allocation size per thread (1024 bytes) is excessive and can be
> reduced to 128 bytes based on nvidia cuda kernel compilation statistics.
> This should help with reducing video memory usage per cuda context.
>
> Thanks,
> Ben
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> how to test your patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Jan Ekström]

On Fri, Jan 26, 2018 at 1:56 AM, Carl Eugen Hoyos  wrote:
> 2018-01-26 0:52 GMT+01:00 wm4 :
>> (and I already wrote that on IRC too, where he lurks as
>> michaelni)
>
> Could one of the native speakers please try to convince
> me that this is not a disparaging term?
>

Hi,

I am not an English native, but the verb "to lurk" is colloquially utilized as:

"read the postings in an Internet forum without actively contributing."
(quote from whatever dictionary Google utilizes)

...and this IMHO is applicable enough as Michael is busy just like
many of us are busy most of the day.

Now, please, all parties. Stop. We've had enough rudeness in this
thread. And now, back to on-topic:

* This change set offers to rename some options to make them similar
to how the TCP protocol does things
(http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tcp.c;h=8773493df1efebac33cff5d203c8c9ff17299d4b;hb=HEAD#l52).
UDP protocol seems to follow suite regarding the "timeout" parameter,
even matching the microsecond part?
* It's imperfect since it doesn't change any of the types of the
options (listen_timeout is now name-wise matched, but type-wise is
supposed to contain seconds for rtsp, milliseconds (! yet another time
scale) in tcp).
* But if we do not rename the current timeout parameter (which does a
different thing than timeout for both TCP and UDP - and name-wise
matches "listen_timeout" as far as it can be seen), we cannot have the
matching name for the matching type of - which should be under the
option "timeout".

So, as far as I can see for now applying this or a slightly modified
version of this as per James' comments doesn't seem to be a too bad
initial step. It brings at least one option in line. We can then start
the larger job of normalizing the timeout parameter across FFmpeg, as
it seems like mentioning this area made multiple people notice
possible improvements in this area. But this is just my 2 eurocents.


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

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

[Mark Thompson]

On 24/01/18 23:44, Ben Chang wrote:
> Hi,
> 
> Please help review this patch to reduce stack frame size per GPU thread. The 
> default allocation size per thread (1024 bytes) is excessive and can be 
> reduced to 128 bytes based on nvidia cuda kernel compilation statistics. This 
> should help with reducing video memory usage per cuda context.
> 
> From b0b76b28b1af7dec0b5419ba9625085f7516e1a6 Mon Sep 17 00:00:00 2001
> From: Ben Chang 
> Date: Tue, 23 Jan 2018 19:45:59 -0800
> Subject: [PATCH] Reduce cuda context's stack frame size limit through
>  cuCtxSetLimit. The default stack limit is 1024 byte per GPU thread. This
>  reduces limit to 128 byte as verified against current cuda kernel compilation
>  statistic. This will reduce local memory allocated per cuda context.
> 
> ---
>  compat/cuda/dynlink_cuda.h   | 10 ++
>  compat/cuda/dynlink_loader.h |  2 ++
>  libavcodec/nvenc.c   |  6 ++
>  libavutil/hwcontext_cuda.c   |  6 ++
>  4 files changed, 24 insertions(+)
> 
> diff --git a/compat/cuda/dynlink_cuda.h b/compat/cuda/dynlink_cuda.h
> index 3a13611..b08a777 100644
> --- a/compat/cuda/dynlink_cuda.h
> +++ b/compat/cuda/dynlink_cuda.h
> @@ -59,6 +59,15 @@ typedef enum CUmemorytype_enum {
>  CU_MEMORYTYPE_DEVICE = 2
>  } CUmemorytype;
>  
> +typedef enum CUlimit_enum {
> +CU_LIMIT_STACK_SIZE   = 0x00, /**< GPU thread stack 
> size */
> +CU_LIMIT_PRINTF_FIFO_SIZE = 0x01, /**< GPU printf FIFO 
> size */
> +CU_LIMIT_MALLOC_HEAP_SIZE = 0x02, /**< GPU malloc heap 
> size */
> +CU_LIMIT_DEV_RUNTIME_SYNC_DEPTH   = 0x03, /**< GPU device 
> runtime launch synchronize depth */
> +CU_LIMIT_DEV_RUNTIME_PENDING_LAUNCH_COUNT = 0x04, /**< GPU device 
> runtime pending launch count */
> +CU_LIMIT_MAX
> +} CUlimit;
> +
>  typedef struct CUDA_MEMCPY2D_st {
>  size_t srcXInBytes;
>  size_t srcY;
> @@ -86,6 +95,7 @@ typedef CUresult CUDAAPI tcuDeviceGet(CUdevice *device, int 
> ordinal);
>  typedef CUresult CUDAAPI tcuDeviceGetName(char *name, int len, CUdevice dev);
>  typedef CUresult CUDAAPI tcuDeviceComputeCapability(int *major, int *minor, 
> CUdevice dev);
>  typedef CUresult CUDAAPI tcuCtxCreate_v2(CUcontext *pctx, unsigned int 
> flags, CUdevice dev);
> +typedef CUresult CUDAAPI tcuCtxSetLimit(CUlimit limit, size_t value);
>  typedef CUresult CUDAAPI tcuCtxPushCurrent_v2(CUcontext *pctx);
>  typedef CUresult CUDAAPI tcuCtxPopCurrent_v2(CUcontext *pctx);
>  typedef CUresult CUDAAPI tcuCtxDestroy_v2(CUcontext ctx);
> diff --git a/compat/cuda/dynlink_loader.h b/compat/cuda/dynlink_loader.h
> index fa43782..55030ef 100644
> --- a/compat/cuda/dynlink_loader.h
> +++ b/compat/cuda/dynlink_loader.h
> @@ -118,6 +118,7 @@ typedef struct CudaFunctions {
>  tcuDeviceGetName *cuDeviceGetName;
>  tcuDeviceComputeCapability *cuDeviceComputeCapability;
>  tcuCtxCreate_v2 *cuCtxCreate;
> +tcuCtxSetLimit *cuCtxSetLimit;
>  tcuCtxPushCurrent_v2 *cuCtxPushCurrent;
>  tcuCtxPopCurrent_v2 *cuCtxPopCurrent;
>  tcuCtxDestroy_v2 *cuCtxDestroy;
> @@ -197,6 +198,7 @@ static inline int cuda_load_functions(CudaFunctions 
> **functions, void *logctx)
>  LOAD_SYMBOL(cuDeviceGetName, tcuDeviceGetName, "cuDeviceGetName");
>  LOAD_SYMBOL(cuDeviceComputeCapability, tcuDeviceComputeCapability, 
> "cuDeviceComputeCapability");
>  LOAD_SYMBOL(cuCtxCreate, tcuCtxCreate_v2, "cuCtxCreate_v2");
> +LOAD_SYMBOL(cuCtxSetLimit, tcuCtxSetLimit, "cuCtxSetLimit");
>  LOAD_SYMBOL(cuCtxPushCurrent, tcuCtxPushCurrent_v2, 
> "cuCtxPushCurrent_v2");
>  LOAD_SYMBOL(cuCtxPopCurrent, tcuCtxPopCurrent_v2, "cuCtxPopCurrent_v2");
>  LOAD_SYMBOL(cuCtxDestroy, tcuCtxDestroy_v2, "cuCtxDestroy_v2");
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 4a91d99..2da251b 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -420,6 +420,12 @@ static av_cold int nvenc_check_device(AVCodecContext 
> *avctx, int idx)
>  goto fail;
>  }
>  
> +cu_res = dl_fn->cuda_dl->cuCtxSetLimit(CU_LIMIT_STACK_SIZE, 128);
> +if (cu_res != CUDA_SUCCESS) {
> +av_log(avctx, AV_LOG_FATAL, "Failed reducing CUDA context stack 
> limit for NVENC: 0x%x\n", (int)cu_res);
> +goto fail;
> +}
> +
>  ctx->cu_context = ctx->cu_context_internal;
>  
>  if ((ret = nvenc_pop_context(avctx)) < 0)

Does this actually have any effect?  I was under the impression that the CUDA 
context created inside the NVENC encoder wouldn't actually be used for any CUDA 
operations at all (really just a GPU device handle).

> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 37827a7..1f022fa 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -386,6 +386,12 @@ static int cuda_device_create(AVHWDeviceContext *ctx, 
> const char *device,
>  goto error;
>  }
>  
> +err = 

Re: [FFmpeg-devel] [PATCH V2 2/3] lavfi/procamp_vaapi: fix the green video issue if without arguments.

[Mark Thompson]

On 24/01/18 10:30, Carl Eugen Hoyos wrote:
> 2018-01-24 4:04 GMT+01:00 Jun Zhao :
> 
>> -procamp_params[i].type   = VAProcFilterColorBalance;
>> -procamp_params[i].attrib = VAProcColorBalanceBrightness;
>> -procamp_params[i].value  = map(ctx->bright, BRIGHTNESS_MIN, 
>> BRIGHTNESS_MAX,
>> -   
>> procamp_caps[VAProcColorBalanceBrightness-1].range.min_value,
>> -   
>> procamp_caps[VAProcColorBalanceBrightness-1].range.max_value);
>> -i++;
> 
>> -procamp_params[i].type   = VAProcFilterColorBalance;
>> -procamp_params[i].attrib = VAProcColorBalanceContrast;
>> -procamp_params[i].value  = map(ctx->contrast, CONTRAST_MIN, 
>> CONTRAST_MAX,
>> -   
>> procamp_caps[VAProcColorBalanceContrast-1].range.min_value,
>> -   
>> procamp_caps[VAProcColorBalanceContrast-1].range.max_value);
>> -i++;
> 
>> -procamp_params[i].type   = VAProcFilterColorBalance;
>> -procamp_params[i].attrib = VAProcColorBalanceHue;
>> -procamp_params[i].value  = map(ctx->hue, HUE_MIN, HUE_MAX,
>> -   
>> procamp_caps[VAProcColorBalanceHue-1].range.min_value,
>> -   
>> procamp_caps[VAProcColorBalanceHue-1].range.max_value);
>> -i++;
> 
>> -procamp_params[i].type   = VAProcFilterColorBalance;
>> -procamp_params[i].attrib = VAProcColorBalanceSaturation;
>> -procamp_params[i].value  = map(ctx->saturation, SATURATION_MIN, 
>> SATURATION_MAX,
>> -   
>> procamp_caps[VAProcColorBalanceSaturation-1].range.min_value,
>> -   
>> procamp_caps[VAProcColorBalanceSaturation-1].range.max_value);
>> -i++;
> 
> Please do not reindent these lines in the same patch that removes the
> conditions, this has two advantages: It makes reviewing your changes
> easier now, and allows somebody who looks at your change in the
> future to understand it more quickly.
> Send an independent patch for the re-indentation.

I don't believe this is merited.  I find the change very easy to review now, 
and in future it will be clearer for these lines to be attributed to the patch 
which actually modifies them rather than an "indent after previous commit" 
change.  Such splitting is reasonable where complex blocks change indentation 
levels while staying mostly or completely the same, but these short blocks do 
not meet such a threshold.

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Fri, 26 Jan 2018 00:56:16 +0100
Carl Eugen Hoyos  wrote:

> 2018-01-26 0:52 GMT+01:00 wm4 :
> > (and I already wrote that on IRC too, where he lurks as
> > michaelni)  
> 
> Could one of the native speakers please try to convince
> me that this is not a disparaging term?

That's his IRC nick name. Did you not know this, and this is another
failed attempt of you trying to put me in a bad light?

Maybe you could just stop this behavior for general de-escalation?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Carl Eugen Hoyos]

2018-01-26 0:52 GMT+01:00 wm4 :
> (and I already wrote that on IRC too, where he lurks as
> michaelni)

Could one of the native speakers please try to convince
me that this is not a disparaging term?

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Fri, 26 Jan 2018 00:21:14 +0100
Carl Eugen Hoyos  wrote:

> 2018-01-26 0:00 GMT+01:00 Hendrik Leppkes :
> > On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos  
> > wrote:  
> >>> and in particular stop outright harassing me into leaving.  
> >>
> >> Yes, I would very much prefer if I could stop;-)  
> >
> > So you openly admit to harassing a fellow developer, and
> > even more so to your plans to not stop?  
> 
> I had the feeling he was harassing Michael several times in the
> last hours, do you disagree?

Well, going by your standards, harassment is just OK?

Anyway, if my reply to Michael was too harsh/unfriendly, I hereby
apologize (and I already wrote that on IRC too, where he lurks as
michaelni). I'd still like to ask him to explicitly state whether his
reply is a change request in context of a patch review, or just general
advice when he's suggesting something that would be disproportionally
more work and not solve the problem the original patch tried to solve.
This is sort of irritating because you never know what you're supposed
to do to get the patch OK'ed.

I'd also like to point out that it _did_ happen in the past that
Michael went off tangents in patch reviews and asked for unreasonable
extra work because of minor issues. The AVFrame.opaque_ref fiasco
(whose non-sensical later solution which he demanded was finally
pushed, even though it still does not solve the issues he claimed his
approach would solve) comes to mind, and I considered his general
conduct on this issue harassment (not like I'd get an apology).

I don't know what the other case of supposed harassment Carl Eugen is
making up without providing any proof.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

[Timo Rothenpieler]

Am 26.01.2018 um 00:17 schrieb Ben Chang:

Just use another provider like gmail.


Done.


Patch looks ok on first glance, will do a proper review tomorrow.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE

[Nicolas George]

Mark Thompson (2018-01-25):
> Please don't.  In this case the semantics of ignoring the signal are
> clear and I think we can be confident the change is ok, but that
> certainly isn't true in almost all other cases (especially if people
> are going to catch signals and do something in the signal handler).

Well, you pushed this patch disregarding my advice: obviously you
consider your grasp on signals better than mine. Good. We need somebody
that understands them.

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 V2 2/3] lavfi/procamp_vaapi: fix the green video issue if without arguments.

[Carl Eugen Hoyos]

2018-01-26 0:21 GMT+01:00 Mark Thompson :
> On 24/01/18 03:04, Jun Zhao wrote:
>>
>> From 1d3b388c313881e931928dc4049896265919725d Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Wed, 24 Jan 2018 09:28:24 +0800
>> Subject: [PATCH V2 2/3] lavfi/procamp_vaapi: fix the green video issue if
>>  without arguments.
>>
>> Fix the green output issue when use procamp_vaapi without any
>> arguments, now if use procamp_vaapi without any arguments, will use
>> the default value to setting procamp_vaapi.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vf_procamp_vaapi.c | 73 
>> ++
>>  1 file changed, 31 insertions(+), 42 deletions(-)
>>
> On 24/01/18 03:04, Jun Zhao wrote:
>>
>> From 7a4a53fcc5a9b31b11818976dc02ea8e004d2c5a Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Wed, 24 Jan 2018 09:32:50 +0800
>> Subject: [PATCH V2 3/3] lavfi/misc_vaapi: use default value setting if 
>> without
>>  arguments.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vf_misc_vaapi.c | 64 
>> +
>>  1 file changed, 30 insertions(+), 34 deletions(-)
>>
>
> Ah right, I didn't consider the same issue on the misc filters as well.  
> Always passing the arguments ends up being a bit simpler too, which is nice.
>
> Both LGTM, tested, applied.

So you prefer that nobody else comments on patches?

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE

[Mark Thompson]

On 25/01/18 23:22, Nicolas George wrote:
> Mark Thompson (2018-01-25):
>> And applied.
> 
> I am glad to see that my advice was so well taken into account. From now
> on, I will defer to you on matters relating to Unix system programming,
> especially signals, shall I?

Please don't.  In this case the semantics of ignoring the signal are clear and 
I think we can be confident the change is ok, but that certainly isn't true in 
almost all other cases (especially if people are going to catch signals and do 
something in the signal handler).

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Hendrik Leppkes]

On Fri, Jan 26, 2018 at 12:21 AM, Carl Eugen Hoyos  wrote:
> 2018-01-26 0:00 GMT+01:00 Hendrik Leppkes :
>> On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos  
>> wrote:
 and in particular stop outright harassing me into leaving.
>>>
>>> Yes, I would very much prefer if I could stop;-)
>>
>> So you openly admit to harassing a fellow developer, and
>> even more so to your plans to not stop?
>
> I had the feeling he was harassing Michael several times in the
> last hours, do you disagree?
>

This is about your actions.

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

Re: [FFmpeg-devel] [PATCH V2 2/3] lavfi/procamp_vaapi: fix the green video issue if without arguments.

[Mark Thompson]

On 24/01/18 03:04, Jun Zhao wrote:
> 
> From 1d3b388c313881e931928dc4049896265919725d Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Wed, 24 Jan 2018 09:28:24 +0800
> Subject: [PATCH V2 2/3] lavfi/procamp_vaapi: fix the green video issue if
>  without arguments.
> 
> Fix the green output issue when use procamp_vaapi without any
> arguments, now if use procamp_vaapi without any arguments, will use
> the default value to setting procamp_vaapi.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_procamp_vaapi.c | 73 
> ++
>  1 file changed, 31 insertions(+), 42 deletions(-)
> 
On 24/01/18 03:04, Jun Zhao wrote:
> 
> From 7a4a53fcc5a9b31b11818976dc02ea8e004d2c5a Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Wed, 24 Jan 2018 09:32:50 +0800
> Subject: [PATCH V2 3/3] lavfi/misc_vaapi: use default value setting if without
>  arguments.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_misc_vaapi.c | 64 
> +
>  1 file changed, 30 insertions(+), 34 deletions(-)
> 

Ah right, I didn't consider the same issue on the misc filters as well.  Always 
passing the arguments ends up being a bit simpler too, which is nice.

Both LGTM, tested, applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

[Ben Chang]

>Just use another provider like gmail.

Done.


Patch-wise, is it approved?

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE

[Nicolas George]

Mark Thompson (2018-01-25):
> And applied.

I am glad to see that my advice was so well taken into account. From now
on, I will defer to you on matters relating to Unix system programming,
especially signals, shall I?

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] rtsp: rename certain options after a deprecation period

[Carl Eugen Hoyos]

2018-01-26 0:00 GMT+01:00 Hendrik Leppkes :
> On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos  wrote:
>>> and in particular stop outright harassing me into leaving.
>>
>> Yes, I would very much prefer if I could stop;-)
>
> So you openly admit to harassing a fellow developer, and
> even more so to your plans to not stop?

I had the feeling he was harassing Michael several times in the
last hours, do you disagree?

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Hendrik Leppkes]

On Thu, Jan 25, 2018 at 11:35 PM, Carl Eugen Hoyos  wrote:
>> and in particular stop outright harassing me into leaving.
>
> Yes, I would very much prefer if I could stop;-)
>

So you openly admit to harassing a fellow developer, and even more so
to your plans to not stop?
If this isn't grounds to remove someone from the project, I don't know what is.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE

[Mark Thompson]

On 19/01/18 00:18, Mark Thompson wrote:
> On 19/01/18 00:08, Carl Eugen Hoyos wrote:
>> 2018-01-19 0:42 GMT+01:00 Mark Thompson :
>>
>>> To offer this suggestion in a more concrete form.
>>
>> Works as expected here except for printing an error which
>> may be intended.
> 
> Yes, that's intended.  Data may have been lost unexpectedly (as with any I/O 
> error), so I believe the user should be informed.

And applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Carl Eugen Hoyos]

2018-01-25 23:13 GMT+01:00 wm4 :
> On Thu, 25 Jan 2018 23:08:21 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2018-01-25 23:04 GMT+01:00 wm4 :
>> > On Thu, 25 Jan 2018 22:41:48 +0100
>> > Carl Eugen Hoyos  wrote:
>> >
>> >> 2018-01-25 21:54 GMT+01:00 wm4 :
>> >>
>> >> > Clearly you're trying to bikeshed me here. I'll just ignore this
>> >> > instead of wasting my time on you.
>> >>
>> >> Is there really no hope that you go away for good?
>> >
>> > Oh not you again.
>>
>> Isn't it more like "you again"?
>>
>> This is the second time within a few hours that you have
>> without any imaginable reason attacked another developer
>> (that it happened both times without any action from the
>> mailing list admins is just a detail).
>> Some people here argue that you are simply ill, I tend to
>> disagree.
>>
>
> Please cease your childish

(I have never understood this insult, sorry...)

> and unprofessional behavior

Hmm.
I am not working "professionally" on FFmpeg, are you?

> and in particular stop outright harassing me into leaving.

Yes, I would very much prefer if I could stop;-)

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Thu, 25 Jan 2018 23:08:21 +0100
Carl Eugen Hoyos  wrote:

> 2018-01-25 23:04 GMT+01:00 wm4 :
> > On Thu, 25 Jan 2018 22:41:48 +0100
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2018-01-25 21:54 GMT+01:00 wm4 :
> >>  
> >> > Clearly you're trying to bikeshed me here. I'll just ignore this
> >> > instead of wasting my time on you.  
> >>
> >> Is there really no hope that you go away for good?  
> >
> > Oh not you again.  
> 
> Isn't it more like "you again"?
> 
> This is the second time within a few hours that you have
> without any imaginable reason attacked another developer
> (that it happened both times without any action from the
> mailing list admins is just a detail).
> Some people here argue that you are simply ill, I tend to
> disagree.
> 

Please cease your childish and unprofessional behavior and in particular
stop outright harassing me into leaving.

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Carl Eugen Hoyos]

2018-01-25 23:04 GMT+01:00 wm4 :
> On Thu, 25 Jan 2018 22:41:48 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2018-01-25 21:54 GMT+01:00 wm4 :
>>
>> > Clearly you're trying to bikeshed me here. I'll just ignore this
>> > instead of wasting my time on you.
>>
>> Is there really no hope that you go away for good?
>
> Oh not you again.

Isn't it more like "you again"?

This is the second time within a few hours that you have
without any imaginable reason attacked another developer
(that it happened both times without any action from the
mailing list admins is just a detail).
Some people here argue that you are simply ill, I tend to
disagree.

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Thu, 25 Jan 2018 22:41:48 +0100
Carl Eugen Hoyos  wrote:

> 2018-01-25 21:54 GMT+01:00 wm4 :
> 
> > Clearly you're trying to bikeshed me here. I'll just ignore this
> > instead of wasting my time on you.  
> 
> Is there really no hope that you go away for good?

Oh not you again.

Is there any hope that you will?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Carl Eugen Hoyos]

2018-01-25 21:54 GMT+01:00 wm4 :

> Clearly you're trying to bikeshed me here. I'll just ignore this
> instead of wasting my time on you.

Is there really no hope that you go away for good?

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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Thu, 25 Jan 2018 21:17:54 +0100
Michael Niedermayer  wrote:

> On Thu, Jan 25, 2018 at 08:54:51PM +0100, wm4 wrote:
> > On Thu, 25 Jan 2018 20:46:13 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:  
> > > > The names inherently clash with the meanings of the HTTP libavformat
> > > > protocol options. Rename them after a deprecation period to make them
> > > > compatible with the HTTP ones.
> > > > ---
> > > > I see no better way that wouldn't require more effort than justified.
> > > > The incompatible semantics of the "timeout" option while still clashing
> > > > with the HTTP one caused major problems to me as API user, and I'm
> > > > hoping that this will solve itself in 2 years.
> > > > ---
> > > >  doc/APIchanges| 5 +
> > > >  libavformat/rtsp.c| 9 +
> > > >  libavformat/version.h | 5 -
> > > >  3 files changed, 18 insertions(+), 1 deletion(-)
> > > 
> > > Make sure all newly added options are in standard SI units
> > > that is seconds (not micro seconds for example)  
> > 
> > 1. you can not use seconds if the option type is int because that would
> >not be fine grained enough
> > 2. HTTP already uses microseconds and the whole point is making this
> >compatible with the HTTP impl. (as it establishes sort of a standard
> >being the most used protocol other than file)
> > 3. Microsecond actually counts as SI unit
> > 4. I'm not going to change the HTTP impl. as that would be a much
> >larger and intrusive change and would not solve the RTSP problem
> >either  
> 
> if the user specifies "-whatever_timeout 500m" That should consistently be
> interpreted as 500 milli seconds.
> All new code should follow this consistently
> 
> The user always provides a string never an integer. That is parsed, it can
> be parsed into a double representing seconds, or an integer representing 
> micro/nano/milli/whatever.
> 
> If you want to use an integer there are many ways to achive this, adding
> a
> AV_OPT_TYPE_TIMEOUT with int64 in nano seconds would be one. Using a
> double in seconds would be much easier though
> 
> If you do not want to change http, you can leave that to someone else
> iam not asking you to do any extra work, just that we move toward
> having timeouts handled consistently
> 

Clearly you're trying to bikeshed me here. I'll just ignore this
instead of wasting my time on you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Nicolas George]

Michael Niedermayer (2018-01-25):
> If you want to use an integer there are many ways to achive this,
> adding a AV_OPT_TYPE_TIMEOUT with int64 in nano seconds would be one.
> Using a double in seconds would be much easier though

We already have AV_OPT_TYPE_DURATION, in microseconds rather than
nanoseconds, but with all the good properties.

I fully agree with the points you make.

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] rtsp: rename certain options after a deprecation period

[Michael Niedermayer]

On Thu, Jan 25, 2018 at 08:54:51PM +0100, wm4 wrote:
> On Thu, 25 Jan 2018 20:46:13 +0100
> Michael Niedermayer  wrote:
> 
> > On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:
> > > The names inherently clash with the meanings of the HTTP libavformat
> > > protocol options. Rename them after a deprecation period to make them
> > > compatible with the HTTP ones.
> > > ---
> > > I see no better way that wouldn't require more effort than justified.
> > > The incompatible semantics of the "timeout" option while still clashing
> > > with the HTTP one caused major problems to me as API user, and I'm
> > > hoping that this will solve itself in 2 years.
> > > ---
> > >  doc/APIchanges| 5 +
> > >  libavformat/rtsp.c| 9 +
> > >  libavformat/version.h | 5 -
> > >  3 files changed, 18 insertions(+), 1 deletion(-)  
> > 
> > Make sure all newly added options are in standard SI units
> > that is seconds (not micro seconds for example)
> 
> 1. you can not use seconds if the option type is int because that would
>not be fine grained enough
> 2. HTTP already uses microseconds and the whole point is making this
>compatible with the HTTP impl. (as it establishes sort of a standard
>being the most used protocol other than file)
> 3. Microsecond actually counts as SI unit
> 4. I'm not going to change the HTTP impl. as that would be a much
>larger and intrusive change and would not solve the RTSP problem
>either

if the user specifies "-whatever_timeout 500m" That should consistently be
interpreted as 500 milli seconds.
All new code should follow this consistently

The user always provides a string never an integer. That is parsed, it can
be parsed into a double representing seconds, or an integer representing 
micro/nano/milli/whatever.

If you want to use an integer there are many ways to achive this, adding
a
AV_OPT_TYPE_TIMEOUT with int64 in nano seconds would be one. Using a
double in seconds would be much easier though

If you do not want to change http, you can leave that to someone else
iam not asking you to do any extra work, just that we move toward
having timeouts handled consistently

thanks

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Check log2_sao_offset_scale_*

[Michael Niedermayer]

On Wed, Jan 24, 2018 at 11:42:44PM -0300, James Almer wrote:
> On 1/24/2018 11:03 PM, Michael Niedermayer wrote:
> > On Wed, Jan 24, 2018 at 12:47:18AM -0300, James Almer wrote:
> >> On 1/24/2018 12:34 AM, Michael Niedermayer wrote:
> >>> Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
> >>> Fixes: runtime error: shift exponent 126 is too large for 32-bit type 
> >>> 'int'
> >>>
> >>> Found-by: continuous fuzzing process 
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/hevc_ps.c | 11 +++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index 4787312cfa..746c96b17e 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1324,6 +1324,17 @@ static int pps_range_extensions(GetBitContext *gb, 
> >>> AVCodecContext *avctx,
> >>>  pps->log2_sao_offset_scale_luma = get_ue_golomb_long(gb);
> >>>  pps->log2_sao_offset_scale_chroma = get_ue_golomb_long(gb);
> >>>  
> >>> +if (   pps->log2_sao_offset_scale_luma   > FFMAX(sps->bit_depth  
> >>>   - 10, 0)
> >>> +|| pps->log2_sao_offset_scale_chroma > 
> >>> FFMAX(sps->bit_depth_chroma - 10, 0)
> >>> +) {
> >>> +av_log(avctx, AV_LOG_ERROR,
> >>> +"log2 sao offset scales (%d %d) are invalid\n",
> >>> +   pps->log2_sao_offset_scale_luma,
> >>> +   pps->log2_sao_offset_scale_chroma
> >>> +  );
> >>> +return AVERROR_INVALIDDATA;
> >>
> >> Wouldn't it be better to just port the h264 and hevc decoder to use the
> >> cbs API at this point? It correctly does a range check for every
> >> sps/vps/pps/slice value already.
> >>
> >> Otherwise you'll be adding a lot of range checks as oss-fuzz finds an
> >> ubsan testcase for them.
> > 
> > cbs is not available in the releases
> > we need to fix issues in the releases
> > 
> > so i dont think cbs can help here
> 
> For release branches yes, no way around it, patches like this are
> needed.

Yes and fixes to releases are bascially always backports from master
and thats what this patchset does, fix it in master in a form that can
be hopefully backported with minimal issues.


> But for future releases it will prevent this kind of fix to be
> added as fuzzers find issues. Eventually, every supported release will
> be one using cbs where range checks are already implemented, so the
> quickest it's done the better.

when all release use cbs then we will still find bugs and will have to
fix them. Both in cbs and outside.
In case of hevc that should be fewer bugs as the hevc bit stream reading
seems to have been writen more sloppy than in other decoders.
Other decoders quite possibly will have more bugs in their cbs code than
before as cbs is alot of not very much tested code, while the decoders
have been tested and fuzzed quite extensivly


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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

On Thu, 25 Jan 2018 20:46:13 +0100
Michael Niedermayer  wrote:

> On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:
> > The names inherently clash with the meanings of the HTTP libavformat
> > protocol options. Rename them after a deprecation period to make them
> > compatible with the HTTP ones.
> > ---
> > I see no better way that wouldn't require more effort than justified.
> > The incompatible semantics of the "timeout" option while still clashing
> > with the HTTP one caused major problems to me as API user, and I'm
> > hoping that this will solve itself in 2 years.
> > ---
> >  doc/APIchanges| 5 +
> >  libavformat/rtsp.c| 9 +
> >  libavformat/version.h | 5 -
> >  3 files changed, 18 insertions(+), 1 deletion(-)  
> 
> Make sure all newly added options are in standard SI units
> that is seconds (not micro seconds for example)

1. you can not use seconds if the option type is int because that would
   not be fine grained enough
2. HTTP already uses microseconds and the whole point is making this
   compatible with the HTTP impl. (as it establishes sort of a standard
   being the most used protocol other than file)
3. Microsecond actually counts as SI unit
4. I'm not going to change the HTTP impl. as that would be a much
   larger and intrusive change and would not solve the RTSP problem
   either
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Michael Niedermayer]

On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote:
> The names inherently clash with the meanings of the HTTP libavformat
> protocol options. Rename them after a deprecation period to make them
> compatible with the HTTP ones.
> ---
> I see no better way that wouldn't require more effort than justified.
> The incompatible semantics of the "timeout" option while still clashing
> with the HTTP one caused major problems to me as API user, and I'm
> hoping that this will solve itself in 2 years.
> ---
>  doc/APIchanges| 5 +
>  libavformat/rtsp.c| 9 +
>  libavformat/version.h | 5 -
>  3 files changed, 18 insertions(+), 1 deletion(-)

Make sure all newly added options are in standard SI units
that is seconds (not micro seconds for example)

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] rtmp: Plug leak if sending bytes read report fails.

[Michael Niedermayer]

On Tue, Jan 23, 2018 at 04:49:16PM -0800, Josh Allmann wrote:
> ---
>  libavformat/rtmpproto.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC

[Ray Tiley]

Apologies for attaching the patch, still trying to figure out patches,
didn't know how to send the patch and include info in the email unrelated
to commit message / change.

The unpack_v210 is only called for SD resolutions ,specifically NTSC which
is 720 wide. unpack_v210 should never be called for HD resolutions as that
would violate the spec in which all the vanc should be in the lama. So
MAX_WIDTH_VANC being 1920 is wide enough to hold a single line of unpacked
SD resolution. But probably better to be safe then risk an overflow. I see
a few options.

Increase luma_vanc to be MAX_WIDTH_VANC * 3, but a guard in the unpack_v210
(should it just return early, log a warning), or do both. Any preferences.

C is not my day to day language so let me know what' best practice and I'll
get the patch fixed up.

-ray

On Thu, Jan 25, 2018 at 9:47 AM Devin Heitmueller <
dheitmuel...@ltnglobal.com> wrote:

> Hi Ray,
>
> >
> > Please find updated patch attatched. I reverted the vanc lines changes
> and
> > found that all my tests worked as expected, so not sure what was wrong w/
> > my original test. The need to extract vanc from the entire line vs just
> the
> > luma in NTSC is still required.
>
> It’s helpful if in the future you could not do patches as attachments.  It
> makes it harder for people to comment on them.
>
> Glad to hear you didn’t need to adjust any of the VANC line definitions in
> order to work properly.  I think they do still need some more review, but
> at least we don’t need to commit to any values at this time which would
> violate the spec.
>
> Regarding the luma/chroma extraction, I haven’t looked at your code too
> closely, but isn’t the destination array too small?  If MAX_WIDTH_VANC is
> 1920, presumably intended to be the number of pixels, then you would need
> three times as many uint16_t values in your destination array if you wanted
> Y, U, and V, or else you would overflow the buffer.  Right?  In either
> case, you probably want some bounds protection to ensure GetWidth() never
> returns a size greater than your destination array.
>
> Also, could you send me a copy of the array of V210 bytes you are testing
> with (i.e. just jam a printf loop into the code and dump the whole thing
> out)?  Would be useful to have it here so I can ensure that libklvanc works
> properly as well (and add it to the list of test vectors I bundle with the
> library).  If you can’t that’s fine - I’ll eventually get around to doing
> some SD testing here.
>
> Devin
> ___
> 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] rtsp: rename certain options after a deprecation period

[wm4]

On Thu, 25 Jan 2018 15:12:27 -0300
James Almer  wrote:

> On 1/25/2018 3:00 PM, wm4 wrote:
> > The names inherently clash with the meanings of the HTTP libavformat
> > protocol options. Rename them after a deprecation period to make them
> > compatible with the HTTP ones.
> > ---
> > I see no better way that wouldn't require more effort than justified.
> > The incompatible semantics of the "timeout" option while still clashing
> > with the HTTP one caused major problems to me as API user, and I'm
> > hoping that this will solve itself in 2 years.
> > ---
> >  doc/APIchanges| 5 +
> >  libavformat/rtsp.c| 9 +
> >  libavformat/version.h | 5 -
> >  3 files changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 59e3b20c08..bf8664c799 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,11 @@ libavutil: 2017-10-21
> >  
> >  API changes, most recent first:
> >  
> > +2018-01-xx - xxx - lavf 58.7.100 - avformat.h
> > +  Deprecate the current names of the RTSP "timeout", "stimeout", 
> > "user-agent"
> > +  options. Once the deprecation is over, "timeout" will be renamed to
> > +  "listen_timeout", "stimeout" to "timeout", and "user-agent" to 
> > "user_agent".
> > +
> >  2018-01-xx - xxx - lavf 58.6.100 - avformat.h
> >Add AVFMTCTX_UNSEEKABLE (for HLS demuxer).
> >  
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index cf7cdb2f2b..bed5f1ea11 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -93,10 +93,19 @@ const AVOption ff_rtsp_options[] = {
> >  RTSP_MEDIATYPE_OPTS("allowed_media_types", "set media types to accept 
> > from the server"),
> >  { "min_port", "set minimum local UDP port", OFFSET(rtp_port_min), 
> > AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
> >  { "max_port", "set maximum local UDP port", OFFSET(rtp_port_max), 
> > AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
> > +#if FF_API_OLD_RTSP_OPTIONS
> >  { "timeout", "set maximum timeout (in seconds) to wait for incoming 
> > connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout), 
> > AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
> >  { "stimeout", "set timeout (in microseconds) of socket TCP I/O 
> > operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, 
> > INT_MAX, DEC },
> > +#else
> > +{ "listen_timeout", "set maximum timeout (in seconds) to wait for 
> > incoming connections (-1 is infinite, imply flag listen)", 
> > OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, 
> > DEC },
> > +{ "timeout", "set timeout (in microseconds) of socket TCP I/O 
> > operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, 
> > INT_MAX, DEC },
> > +#endif
> >  COMMON_OPTS(),
> > +#if FF_API_OLD_RTSP_OPTIONS
> >  { "user-agent", "override User-Agent header", OFFSET(user_agent), 
> > AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> > +#else
> > +{ "user_agent", "override User-Agent header", OFFSET(user_agent), 
> > AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> > +#endif  
> 
> Wouldn't it be better to add the new one right now instead of right
> after the deprecated one is removed? People should start moving to the
> new one before that happens, rather than right when it happens.
> That way you can also add "(deprecated, use user_agent instead)" to the
> description of the old one.

Probably, but it can't be solved like this for the timeout options. (If
the patch is accepted I can always expose the user_agent option and
edit the description of user-agent to mention it as deprecated.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[James Almer]

On 1/25/2018 3:00 PM, wm4 wrote:
> The names inherently clash with the meanings of the HTTP libavformat
> protocol options. Rename them after a deprecation period to make them
> compatible with the HTTP ones.
> ---
> I see no better way that wouldn't require more effort than justified.
> The incompatible semantics of the "timeout" option while still clashing
> with the HTTP one caused major problems to me as API user, and I'm
> hoping that this will solve itself in 2 years.
> ---
>  doc/APIchanges| 5 +
>  libavformat/rtsp.c| 9 +
>  libavformat/version.h | 5 -
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 59e3b20c08..bf8664c799 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2018-01-xx - xxx - lavf 58.7.100 - avformat.h
> +  Deprecate the current names of the RTSP "timeout", "stimeout", "user-agent"
> +  options. Once the deprecation is over, "timeout" will be renamed to
> +  "listen_timeout", "stimeout" to "timeout", and "user-agent" to 
> "user_agent".
> +
>  2018-01-xx - xxx - lavf 58.6.100 - avformat.h
>Add AVFMTCTX_UNSEEKABLE (for HLS demuxer).
>  
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cf7cdb2f2b..bed5f1ea11 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -93,10 +93,19 @@ const AVOption ff_rtsp_options[] = {
>  RTSP_MEDIATYPE_OPTS("allowed_media_types", "set media types to accept 
> from the server"),
>  { "min_port", "set minimum local UDP port", OFFSET(rtp_port_min), 
> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
>  { "max_port", "set maximum local UDP port", OFFSET(rtp_port_max), 
> AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
> +#if FF_API_OLD_RTSP_OPTIONS
>  { "timeout", "set maximum timeout (in seconds) to wait for incoming 
> connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout), 
> AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
>  { "stimeout", "set timeout (in microseconds) of socket TCP I/O 
> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, 
> DEC },
> +#else
> +{ "listen_timeout", "set maximum timeout (in seconds) to wait for 
> incoming connections (-1 is infinite, imply flag listen)", 
> OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC 
> },
> +{ "timeout", "set timeout (in microseconds) of socket TCP I/O 
> operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, 
> DEC },
> +#endif
>  COMMON_OPTS(),
> +#if FF_API_OLD_RTSP_OPTIONS
>  { "user-agent", "override User-Agent header", OFFSET(user_agent), 
> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> +#else
> +{ "user_agent", "override User-Agent header", OFFSET(user_agent), 
> AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
> +#endif

Wouldn't it be better to add the new one right now instead of right
after the deprecated one is removed? People should start moving to the
new one before that happens, rather than right when it happens.
That way you can also add "(deprecated, use user_agent instead)" to the
description of the old one.

>  { NULL },
>  };
>  
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 5ff8a89ae0..4285e925cf 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
> Chromium)
>  // Also please add any ticket numbers that you believe might be affected here
>  #define LIBAVFORMAT_VERSION_MAJOR  58
> -#define LIBAVFORMAT_VERSION_MINOR   6
> +#define LIBAVFORMAT_VERSION_MINOR   7
>  #define LIBAVFORMAT_VERSION_MICRO 100
>  
>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> @@ -85,6 +85,9 @@
>  #ifndef FF_API_LAVF_FFSERVER
>  #define FF_API_LAVF_FFSERVER(LIBAVFORMAT_VERSION_MAJOR < 59)
>  #endif
> +#ifndef FF_API_OLD_RTSP_OPTIONS
> +#define FF_API_OLD_RTSP_OPTIONS (LIBAVFORMAT_VERSION_MAJOR < 59)
> +#endif
>  
>  
>  #ifndef FF_API_R_FRAME_RATE
> 

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

[FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[wm4]

The names inherently clash with the meanings of the HTTP libavformat
protocol options. Rename them after a deprecation period to make them
compatible with the HTTP ones.
---
I see no better way that wouldn't require more effort than justified.
The incompatible semantics of the "timeout" option while still clashing
with the HTTP one caused major problems to me as API user, and I'm
hoping that this will solve itself in 2 years.
---
 doc/APIchanges| 5 +
 libavformat/rtsp.c| 9 +
 libavformat/version.h | 5 -
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 59e3b20c08..bf8664c799 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-01-xx - xxx - lavf 58.7.100 - avformat.h
+  Deprecate the current names of the RTSP "timeout", "stimeout", "user-agent"
+  options. Once the deprecation is over, "timeout" will be renamed to
+  "listen_timeout", "stimeout" to "timeout", and "user-agent" to "user_agent".
+
 2018-01-xx - xxx - lavf 58.6.100 - avformat.h
   Add AVFMTCTX_UNSEEKABLE (for HLS demuxer).
 
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cf7cdb2f2b..bed5f1ea11 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -93,10 +93,19 @@ const AVOption ff_rtsp_options[] = {
 RTSP_MEDIATYPE_OPTS("allowed_media_types", "set media types to accept from 
the server"),
 { "min_port", "set minimum local UDP port", OFFSET(rtp_port_min), 
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
 { "max_port", "set maximum local UDP port", OFFSET(rtp_port_max), 
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
+#if FF_API_OLD_RTSP_OPTIONS
 { "timeout", "set maximum timeout (in seconds) to wait for incoming 
connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout), 
AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
 { "stimeout", "set timeout (in microseconds) of socket TCP I/O 
operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, 
DEC },
+#else
+{ "listen_timeout", "set maximum timeout (in seconds) to wait for incoming 
connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout), 
AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
+{ "timeout", "set timeout (in microseconds) of socket TCP I/O operations", 
OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, DEC },
+#endif
 COMMON_OPTS(),
+#if FF_API_OLD_RTSP_OPTIONS
 { "user-agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
+#else
+{ "user_agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
+#endif
 { NULL },
 };
 
diff --git a/libavformat/version.h b/libavformat/version.h
index 5ff8a89ae0..4285e925cf 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR   6
+#define LIBAVFORMAT_VERSION_MINOR   7
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
@@ -85,6 +85,9 @@
 #ifndef FF_API_LAVF_FFSERVER
 #define FF_API_LAVF_FFSERVER(LIBAVFORMAT_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_OLD_RTSP_OPTIONS
+#define FF_API_OLD_RTSP_OPTIONS (LIBAVFORMAT_VERSION_MAJOR < 59)
+#endif
 
 
 #ifndef FF_API_R_FRAME_RATE
-- 
2.15.1

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

[FFmpeg-devel] Using FFmpeg as standalone EXE in commercial product.

[Cody Herzog]

Hello.

I'm working on a closed-source commercial product, and I would like
to deliver FFmpeg as a stand-alone EXE with my installer.

My program will call into FFmpeg using the Windows CreateProcess()
API, and will stream to it through standard input.

I have made a minimal build of FFmpeg which excludes GPL components,
and also excludes all codecs. I'm only using some file muxing
capabilities.

Because I am not linking with FFmpeg, I'm curious as to what
requirements, if any, must be met in terms of the LGPL license.

I found the following thread, which already includes some good
information:

https://ffmpeg.org/pipermail/ffmpeg-devel/2009-May/075528.html

Beyond what's covered in that thread, I'm curious whether the entire
licensing checklist on the following page still applies to my
scenario?

http://ffmpeg.org/legal.html

From the perspective of active FFmpeg developers, which of those
items should be handled in my use case?

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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: Extract 1080i and NTSC VANC

[Devin Heitmueller]

Hi Ray,

> 
> Please find updated patch attatched. I reverted the vanc lines changes and
> found that all my tests worked as expected, so not sure what was wrong w/
> my original test. The need to extract vanc from the entire line vs just the
> luma in NTSC is still required.

It’s helpful if in the future you could not do patches as attachments.  It 
makes it harder for people to comment on them.

Glad to hear you didn’t need to adjust any of the VANC line definitions in 
order to work properly.  I think they do still need some more review, but at 
least we don’t need to commit to any values at this time which would violate 
the spec.

Regarding the luma/chroma extraction, I haven’t looked at your code too 
closely, but isn’t the destination array too small?  If MAX_WIDTH_VANC is 1920, 
presumably intended to be the number of pixels, then you would need three times 
as many uint16_t values in your destination array if you wanted Y, U, and V, or 
else you would overflow the buffer.  Right?  In either case, you probably want 
some bounds protection to ensure GetWidth() never returns a size greater than 
your destination array.

Also, could you send me a copy of the array of V210 bytes you are testing with 
(i.e. just jam a printf loop into the code and dump the whole thing out)?  
Would be useful to have it here so I can ensure that libklvanc works properly 
as well (and add it to the list of test vectors I bundle with the library).  If 
you can’t that’s fine - I’ll eventually get around to doing some SD testing 
here.

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

Re: [FFmpeg-devel] [PATCH]: Change Stack Frame Limit in Cuda Context

[Carl Eugen Hoyos]

2018-01-25 3:41 GMT+01:00 Ben Chang :

>> Please remove this or use another email address.
>
> Is this absolutely necessary?

Have you ever read the footer?

You are sending an email to a public email list that you
know is mirrored on the internet and claim that the
content of your email may be confidential...

Just use another provider like gmail.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_framerate: fix cpy_line_width calculation on >8 bits format

[Muhammad Faiz]

On Sat, Jan 20, 2018 at 3:04 PM, Muhammad Faiz  wrote:
> Fix tsan warnings on fate-filter-framerate-12bit-down and
> fate-filter-framerate-12bit-up.
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/vf_framerate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> index a5ae6ddb71..578acaae52 100644
> --- a/libavfilter/vf_framerate.c
> +++ b/libavfilter/vf_framerate.c
> @@ -240,7 +240,7 @@ static int filter_slice16(AVFilterContext *ctx, void 
> *arg, int job, int nb_jobs)
>  int plane, line, pixel;
>
>  for (plane = 0; plane < 4 && td->copy_src1->data[plane] && 
> td->copy_src2->data[plane]; plane++) {
> -int cpy_line_width = s->line_size[plane];
> +int cpy_line_width = s->line_size[plane] / 2;
>  const uint16_t *cpy_src1_data = (const uint16_t 
> *)td->copy_src1->data[plane];
>  int cpy_src1_line_size = td->copy_src1->linesize[plane] / 2;
>  const uint16_t *cpy_src2_data = (const uint16_t 
> *)td->copy_src2->data[plane];
> --
> 2.13.2
>

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

[FFmpeg-devel] [PATCH] lavc/qsv: skip the packet if decoding failure.

[Ruiling Song]

From: "Ruiling, Song" 

MediaSDK may fail to decode some frame, just skip it.
Otherwise, it will keep decoding the failure packet repeatedly
without processing any packet afterwards.

v2:
switch to using av_packet_unref().

Signed-off-by: Ruiling Song 
---
 libavcodec/qsvdec_h2645.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index 5e00673..d92a150 100644
--- a/libavcodec/qsvdec_h2645.c
+++ b/libavcodec/qsvdec_h2645.c
@@ -153,8 +153,12 @@ static int qsv_decode_frame(AVCodecContext *avctx, void 
*data,
 }
 
 ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame, 
>buffer_pkt);
-if (ret < 0)
+if (ret < 0) {
+/* Drop buffer_pkt when failed to decode the packet. Otherwise,
+   the decoder will keep decoding the failure packet. */
+av_packet_unref(>buffer_pkt);
 return ret;
+}
 
 s->buffer_pkt.size -= ret;
 s->buffer_pkt.data += ret;
-- 
2.7.4

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