Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg.c: allow forcing input framerate on streamcopy
On 4/4/19 5:11 AM, Michael Niedermayer wrote: On Wed, Jan 09, 2019 at 05:26:53PM -0500, Leo Izen wrote: --- fftools/ffmpeg.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) Does this behave as intended when there is also an audio stream ? It depends on what you mean by "as indended." You can already uses -r as an input option if you're transcoding the video stream. This makes it work the same way for streamcopy. In either case, it doesn't touch the audio stream or the container timebase. also a fate test should be added I can add a fate test and re-submit the patch with one included. thx [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/af_asetnsamples: fix sample queuing.
When asetnsamples uses output samples < input samples, remaining samples build
up in the fifo over time.
Fix this by marking the filter as ready again if there are enough samples.
Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239
---
libavfilter/af_asetnsamples.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavfilter/af_asetnsamples.c b/libavfilter/af_asetnsamples.c
index c60ce3063f..cab02d56f6 100644
--- a/libavfilter/af_asetnsamples.c
+++ b/libavfilter/af_asetnsamples.c
@@ -67,8 +67,12 @@ static int activate(AVFilterContext *ctx)
return ret;
if (ret > 0) {
-if ((!s->pad || (s->pad && frame->nb_samples == s->nb_out_samples)))
-return ff_filter_frame(outlink, frame);
+if ((!s->pad || (s->pad && frame->nb_samples == s->nb_out_samples))) {
+ret = ff_filter_frame(outlink, frame);
+if (ff_framequeue_queued_samples(inlink) >= s->nb_out_samples)
+ff_filter_set_ready(ctx, 100);
+return ret;
+}
pad_frame = ff_get_audio_buffer(outlink, s->nb_out_samples);
if (!pad_frame) {
--
2.21.0.392.gf8f6787159e-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil/hwcontext_opencl.c: fix bug in `opencl_get_plane_format`
The `opencl_get_plane_format` function was incorrectly determining the value used to set the image channel order. This resulted in all RGB pixel formats being set to the `CL_RGBA` pixel format, regardless of whether or not they actually *were* RGBA. This patch fixes the issue by using the `offset` field on components rather than the loop index to determine the value of `order` for RGB pixel formats (and leaves the formula to determine `order` the same for other formats so as not to break those cases). Signed-off-by: Jarek Samic --- I'm including this in the email (but not the commit description) to make this patch easier to review. In order to make sure I was fixing the bug and not messing up channel order mapping for any of the other formats, I set up a few quick print statements within the function after the `order` value was set. Here's the output without this patch: ``` [AVHWDeviceContext @ _] Maximum supported image size 16384x16384. [opencl_get_plane_format] order_num: 1, pixel_format: yuv420p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv420p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv420p, plane: 2 [AVHWDeviceContext @ _] Format yuv420p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuv422p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv422p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv422p, plane: 2 [AVHWDeviceContext @ _] Format yuv422p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuv444p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv444p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv444p, plane: 2 [AVHWDeviceContext @ _] Format yuv444p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuv410p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv410p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv410p, plane: 2 [AVHWDeviceContext @ _] Format yuv410p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuv411p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv411p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv411p, plane: 2 [AVHWDeviceContext @ _] Format yuv411p supported. [opencl_get_plane_format] order_num: 1, pixel_format: gray, plane: 0 [AVHWDeviceContext @ _] Format gray supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuvj420p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuvj420p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuvj420p, plane: 2 [AVHWDeviceContext @ _] Format yuvj420p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuvj422p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuvj422p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuvj422p, plane: 2 [AVHWDeviceContext @ _] Format yuvj422p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuvj444p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuvj444p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuvj444p, plane: 2 [AVHWDeviceContext @ _] Format yuvj444p supported. [opencl_get_plane_format] order_num: 1, pixel_format: nv12, plane: 0 [opencl_get_plane_format] order_num: 23, pixel_format: nv12, plane: 1 [AVHWDeviceContext @ _] Format nv12 supported. [opencl_get_plane_format] order_num: 1, pixel_format: nv21, plane: 0 [opencl_get_plane_format] order_num: 23, pixel_format: nv21, plane: 1 [AVHWDeviceContext @ _] Format nv21 supported. [opencl_get_plane_format] order_num: 1234, pixel_format: argb, plane: 0 [AVHWDeviceContext @ _] Format argb supported. [opencl_get_plane_format] order_num: 1234, pixel_format: rgba, plane: 0 [AVHWDeviceContext @ _] Format rgba supported. [opencl_get_plane_format] order_num: 1234, pixel_format: abgr, plane: 0 [AVHWDeviceContext @ _] Format abgr supported. [opencl_get_plane_format] order_num: 1234, pixel_format: bgra, plane: 0 [AVHWDeviceContext @ _] Format bgra supported. [opencl_get_plane_format] order_num: 1, pixel_format: gray16le, plane: 0 [AVHWDeviceContext @ _] Format gray16le supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuv440p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuv440p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuv440p, plane: 2 [AVHWDeviceContext @ _] Format yuv440p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuvj440p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuvj440p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuvj440p, plane: 2 [AVHWDeviceContext @ _] Format yuvj440p supported. [opencl_get_plane_format] order_num: 1, pixel_format: yuva420p, plane: 0 [opencl_get_plane_format] order_num: 2, pixel_format: yuva420p, plane: 1 [opencl_get_plane_format] order_num: 3, pixel_format: yuva420p, plane: 2 [opencl_get_plane_format] order_num: 4, pixel_format:
Re: [FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
On Fri, Apr 5, 2019 at 11:50 AM Jun Li wrote:
> stimeout option is already used in tcp transport, since
> http is based on tcp, pass the option to http for tunneling
> case.
> ---
> libavformat/rtsp.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 033095905d..8349840c96 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -1744,6 +1744,9 @@ redirect:
> char httpname[1024];
> char sessioncookie[17];
> char headers[1024];
> +AVDictionary *options = NULL;
> +
> +av_dict_set_int(, "timeout", rt->stimeout, 0);
>
> ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
> "http", auth, host, port, "%s", path);
> snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
> @@ -1774,7 +1777,8 @@ redirect:
> }
>
> /* complete the connection */
> -if (ffurl_connect(rt->rtsp_hd, NULL)) {
> +if (ffurl_connect(rt->rtsp_hd, )) {
> +av_dict_free();
> err = AVERROR(EIO);
> goto fail;
> }
> @@ -1818,10 +1822,12 @@ redirect:
> ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
>
> /* complete the connection */
> -if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
> +if (ffurl_connect(rt->rtsp_hd_out, )) {
> +av_dict_free();
> err = AVERROR(EIO);
> goto fail;
> }
> +av_dict_free();
> } else {
> int ret;
> /* open the tcp connection */
> --
> 2.17.1
>
>
Updated the version, free the memory in error path, patch is here:
https://patchwork.ffmpeg.org/patch/12620/
I initially planned to do that then I realized the error path will trigger
whole process to exit, which may be safe. But I agree with you, it is a
better practice to clean-up here.
Thanks for review, Michael.
Best Regards,
Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
stimeout option is already used in tcp transport, since
http is based on tcp, pass the option to http for tunneling
case.
---
libavformat/rtsp.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 033095905d..8349840c96 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1744,6 +1744,9 @@ redirect:
char httpname[1024];
char sessioncookie[17];
char headers[1024];
+AVDictionary *options = NULL;
+
+av_dict_set_int(, "timeout", rt->stimeout, 0);
ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
"http", auth, host, port, "%s", path);
snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
@@ -1774,7 +1777,8 @@ redirect:
}
/* complete the connection */
-if (ffurl_connect(rt->rtsp_hd, NULL)) {
+if (ffurl_connect(rt->rtsp_hd, )) {
+av_dict_free();
err = AVERROR(EIO);
goto fail;
}
@@ -1818,10 +1822,12 @@ redirect:
ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
/* complete the connection */
-if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
+if (ffurl_connect(rt->rtsp_hd_out, )) {
+av_dict_free();
err = AVERROR(EIO);
goto fail;
}
+av_dict_free();
} else {
int ret;
/* open the tcp connection */
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: Fix integer overflow with w/h
On Fri, Apr 05, 2019 at 09:54:51AM +0200, Paul B Mahol wrote:
> On 4/5/19, Michael Niedermayer wrote:
> > Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to
> > an unsigned type to negate this value to itself
> > Fixes:
> > 13999/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644405991538688
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/agm.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> > index 2d209d..cbd45e8095 100644
> > --- a/libavcodec/agm.c
> > +++ b/libavcodec/agm.c
> > @@ -535,11 +535,13 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data,
> >
> > s->flags = 0;
> > w = bytestream2_get_le32(gbyte);
> > +h = bytestream2_get_le32(gbyte);
> > +if (w == INT32_MIN || h == INT32_MIN)
> > +return AVERROR_INVALIDDATA;
> > if (w < 0) {
> > w = -w;
> > s->flags |= 2;
> > }
> > -h = bytestream2_get_le32(gbyte);
> > if (h < 0) {
> > h = -h;
> > s->flags |= 1;
> > --
>
> OK
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
On Fri, Apr 05, 2019 at 01:20:31AM -0700, Jun Li wrote:
> stimeout option is already used in tcp transport, since
> http is based on tcp, pass the option to http for tunneling
> case.
> ---
> libavformat/rtsp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 033095905d..2ca1aca94e 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -1744,6 +1744,9 @@ redirect:
> char httpname[1024];
> char sessioncookie[17];
> char headers[1024];
> +AVDictionary *options = NULL;
> +
> +av_dict_set_int(, "timeout", rt->stimeout, 0);
>
> ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
> "http", auth, host, port, "%s", path);
> snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
> @@ -1774,7 +1777,7 @@ redirect:
> }
>
> /* complete the connection */
> -if (ffurl_connect(rt->rtsp_hd, NULL)) {
> +if (ffurl_connect(rt->rtsp_hd, )) {
> err = AVERROR(EIO);
> goto fail;
> }
> @@ -1818,10 +1821,11 @@ redirect:
> ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
>
> /* complete the connection */
> -if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
> +if (ffurl_connect(rt->rtsp_hd_out, )) {
> err = AVERROR(EIO);
> goto fail;
> }
> +av_dict_free();
wouldnt this leak options on the error path ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 13/21] avformat/matroskadec: Improve length check
On Wed, Mar 27, 2019 at 12:18:44PM +0100, Andreas Rheinhardt via ffmpeg-devel wrote: > The earlier code had three flaws: > > 1. The case of an unknown-sized element inside a finite-sized element > (which is against the specifications) was not caught. > > 2. The error message wasn't helpful: It compared the length of the child > with the offset of the end of the parent and claimed that the first > exceeds the latter, although that is not necessarily true. > > 3. Unknown-sized elements that are not parsed can't be skipped. Given > that according to the Matroska specifications only the segment and the > clusters can be of unknown-size, this is handled by not allowing any > other units to have infinite size whereas the earlier code would seek > back by 1 byte upon encountering an infinite-size element that ought > to be skipped. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/matroskadec.c | 26 ++ > 1 file changed, 22 insertions(+), 4 deletions(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] swscale/ppc: VSX-optimize non-full-chroma yuv2rgb_2
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags
fast_bilinear \
-s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -
32-bit mul, power8 only.
~2x speedup:
rgb24
24431 UNITS in yuv2packed2, 16384 runs, 0 skips
13783 UNITS in yuv2packed2, 16383 runs, 1 skips
bgr24
24396 UNITS in yuv2packed2, 16384 runs, 0 skips
14059 UNITS in yuv2packed2, 16384 runs, 0 skips
rgba
26815 UNITS in yuv2packed2, 16383 runs, 1 skips
12797 UNITS in yuv2packed2, 16383 runs, 1 skips
bgra
27060 UNITS in yuv2packed2, 16384 runs, 0 skips
13138 UNITS in yuv2packed2, 16384 runs, 0 skips
argb
26998 UNITS in yuv2packed2, 16384 runs, 0 skips
12728 UNITS in yuv2packed2, 16381 runs, 3 skips
bgra
26651 UNITS in yuv2packed2, 16384 runs, 0 skips
13124 UNITS in yuv2packed2, 16384 runs, 0 skips
This is a low speedup, but the x86 mmx version also gets only ~2x. The mmx
version
is also heavily inaccurate, while the vsx version has high accuracy.
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 188 +++
1 file changed, 188 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index e05f9ec..ba00791 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -793,6 +793,180 @@ yuv2rgb_full_2_vsx_template(SwsContext *c, const int16_t
*buf[2],
}
}
+static av_always_inline void
+yuv2rgb_2_vsx_template(SwsContext *c, const int16_t *buf[2],
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf[2], uint8_t *dest, int dstW,
+ int yalpha, int uvalpha, int y,
+ enum AVPixelFormat target, int hasAlpha)
+{
+const int16_t *buf0 = buf[0], *buf1 = buf[1],
+ *ubuf0 = ubuf[0], *ubuf1 = ubuf[1],
+ *vbuf0 = vbuf[0], *vbuf1 = vbuf[1],
+ *abuf0 = hasAlpha ? abuf[0] : NULL,
+ *abuf1 = hasAlpha ? abuf[1] : NULL;
+const int16_t yalpha1 = 4096 - yalpha;
+const int16_t uvalpha1 = 4096 - uvalpha;
+vector int16_t vy, vu, vv, A = vec_splat_s16(0);
+vector int32_t vy32_l, vy32_r, vu32_l, vu32_r, vv32_l, vv32_r, tmp32;
+vector int32_t R_l, R_r, G_l, G_r, B_l, B_r, vud32_l, vud32_r, vvd32_l,
vvd32_r;
+vector int32_t tmp, tmp2, tmp3, tmp4, tmp5, tmp6;
+vector uint16_t rd16, gd16, bd16;
+vector uint8_t rd, bd, gd, ad, out0, out1, tmp8;
+const vector int16_t vyalpha1 = vec_splats(yalpha1);
+const vector int16_t vuvalpha1 = vec_splats(uvalpha1);
+const vector int16_t vyalpha = vec_splats((int16_t) yalpha);
+const vector int16_t vuvalpha = vec_splats((int16_t) uvalpha);
+const vector uint16_t zero16 = vec_splat_u16(0);
+const vector int32_t y_offset = vec_splats(c->yuv2rgb_y_offset);
+const vector int32_t y_coeff = vec_splats(c->yuv2rgb_y_coeff);
+const vector int32_t y_add = vec_splats(1 << 21);
+const vector int32_t v2r_coeff = vec_splats(c->yuv2rgb_v2r_coeff);
+const vector int32_t v2g_coeff = vec_splats(c->yuv2rgb_v2g_coeff);
+const vector int32_t u2g_coeff = vec_splats(c->yuv2rgb_u2g_coeff);
+const vector int32_t u2b_coeff = vec_splats(c->yuv2rgb_u2b_coeff);
+const vector int32_t rgbclip = vec_splats(1 << 30);
+const vector int32_t zero32 = vec_splat_s32(0);
+const vector uint32_t shift19 = vec_splats(19U);
+const vector uint32_t shift22 = vec_splats(22U);
+const vector uint32_t shift10 = vec_splat_u32(10);
+const vector int32_t dec128 = vec_splats(128 << 19);
+const vector int32_t add18 = vec_splats(1 << 18);
+int i;
+
+// Various permutations
+const vector uint8_t doubleleft = (vector uint8_t) {0, 1, 2, 3,
+0, 1, 2, 3,
+4, 5, 6, 7,
+4, 5, 6, 7 };
+const vector uint8_t doubleright = (vector uint8_t) {8, 9, 10, 11,
+8, 9, 10, 11,
+12, 13, 14, 15,
+12, 13, 14, 15 };
+const vector uint8_t perm3rg0 = (vector uint8_t) {0x0, 0x10, 0,
+ 0x1, 0x11, 0,
+ 0x2, 0x12, 0,
+ 0x3, 0x13, 0,
+ 0x4, 0x14, 0,
+ 0x5 };
+const vector uint8_t perm3rg1 = (vector uint8_t) { 0x15, 0,
+ 0x6, 0x16, 0,
+ 0x7, 0x17, 0
[FFmpeg-devel] [PATCH v1] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
stimeout option is already used in tcp transport, since
http is based on tcp, pass the option to http for tunneling
case.
---
libavformat/rtsp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 033095905d..2ca1aca94e 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1744,6 +1744,9 @@ redirect:
char httpname[1024];
char sessioncookie[17];
char headers[1024];
+AVDictionary *options = NULL;
+
+av_dict_set_int(, "timeout", rt->stimeout, 0);
ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
"http", auth, host, port, "%s", path);
snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
@@ -1774,7 +1777,7 @@ redirect:
}
/* complete the connection */
-if (ffurl_connect(rt->rtsp_hd, NULL)) {
+if (ffurl_connect(rt->rtsp_hd, )) {
err = AVERROR(EIO);
goto fail;
}
@@ -1818,10 +1821,11 @@ redirect:
ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
/* complete the connection */
-if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
+if (ffurl_connect(rt->rtsp_hd_out, )) {
err = AVERROR(EIO);
goto fail;
}
+av_dict_free();
} else {
int ret;
/* open the tcp connection */
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: Fix integer overflow with w/h
On 4/5/19, Michael Niedermayer wrote:
> Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to
> an unsigned type to negate this value to itself
> Fixes:
> 13999/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644405991538688
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/agm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index 2d209d..cbd45e8095 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -535,11 +535,13 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
>
> s->flags = 0;
> w = bytestream2_get_le32(gbyte);
> +h = bytestream2_get_le32(gbyte);
> +if (w == INT32_MIN || h == INT32_MIN)
> +return AVERROR_INVALIDDATA;
> if (w < 0) {
> w = -w;
> s->flags |= 2;
> }
> -h = bytestream2_get_le32(gbyte);
> if (h < 0) {
> h = -h;
> s->flags |= 1;
> --
OK
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] fate-samples entry in MAINTAINERS
On Tue, Mar 12, 2019 at 02:15:28PM +0100, Michael Niedermayer wrote: > Hi > > I think we should add a entry for fate-samples to MAINTAINERS > so that people who need a file uploaded know with whom to talk > if the file is not being uploaded from a post to the ML > > if people agree. Who can i add to that entry ? (i dont want to > just dump everyone who has access to it as people did not explicitly > volunteer to handle it) ping ATM, contributors who need a sample uploaded only can post to the mailing list or privatly to a random developer (who then himself quite possibly wont know where to direct this request) I did receive such question for example in my inbox a while ago and did in fact not know where to point the contributor to ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
