[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Sasi Inguva]

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c| 52 
 tests/fate/mov.mak   |  5 
 tests/ref/fate/mov-guess-delay-1 |  3 +++
 tests/ref/fate/mov-guess-delay-2 |  3 +++
 4 files changed, 63 insertions(+)
 create mode 100644 tests/ref/fate/mov-guess-delay-1
 create mode 100644 tests/ref/fate/mov-guess-delay-2

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..687297be33 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3213,6 +3213,56 @@ static int64_t add_ctts_entry(MOVStts** ctts_data, 
unsigned int* ctts_count, uns
 return *ctts_count;
 }
 
+static void mov_guess_video_delay(MOVContext *c, AVStream* st) {
+MOVStreamContext *msc = st->priv_data;
+int ind;
+int ctts_ind = 0;
+int ctts_sample = 0;
+int64_t curr_pts = AV_NOPTS_VALUE;
+int64_t prev_pts = AV_NOPTS_VALUE;
+int64_t prev_max_pts = AV_NOPTS_VALUE;
+int num_swaps = 0;
+
+if (st->codecpar->video_delay <= 0 && msc->ctts_data &&
+(st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO ||
+ st->codecpar->codec_id == AV_CODEC_ID_H263 ||
+ st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+ st->codecpar->codec_id == AV_CODEC_ID_HEVC)) {
+st->codecpar->video_delay = 0;
+for(ind = 0; ind < st->nb_index_entries && ctts_ind < msc->ctts_count; 
++ind) {
+curr_pts = st->index_entries[ind].timestamp + 
msc->ctts_data[ctts_ind].duration;
+
+// This is used as an indication that the previous GOP has ended 
and a
+// new GOP has started.
+if (curr_pts > prev_max_pts) {
+st->codecpar->video_delay = 
FFMIN(FFMAX(st->codecpar->video_delay, num_swaps), 16);
+num_swaps = 0;
+prev_max_pts = curr_pts;
+}
+
+// Compute delay as the no. of "drop"s in PTS inside a GOP.
+// Frames: I0 I1 B0 B1 B2
+// PTS: 0  4  1  2  3 -> num_swaps = delay = 1 (4->1)
+//
+// Frames: I0 I1 B1 B0 B2
+// PTS: 0  4  2  1  3 -> num_swaps = delay = 2 (4->2, 2->1)
+if (prev_pts != AV_NOPTS_VALUE) {
+if (curr_pts < prev_pts)
+++num_swaps;
+}
+
+prev_pts = curr_pts;
+ctts_sample++;
+if (ctts_sample == msc->ctts_data[ctts_ind].count) {
+ctts_ind++;
+ctts_sample = 0;
+}
+}
+av_log(c->fc, AV_LOG_DEBUG, "Setting codecpar->delay to %d for stream 
st: %d\n",
+   st->codecpar->video_delay, st->index);
+}
+}
+
 static void mov_current_sample_inc(MOVStreamContext *sc)
 {
 sc->current_sample++;
@@ -3846,6 +3896,8 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 // Fix index according to edit lists.
 mov_fix_index(mov, st);
 }
+
+mov_guess_video_delay(mov, st);
 }
 
 static int test_same_origin(const char *src, const char *ref) {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 76f66ff498..ef89e62096 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -11,6 +11,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-440hz-10ms \
fate-mov-ibi-elst-starts-b \
fate-mov-elst-ends-betn-b-and-i \
+   fate-mov-guess-delay-1 \
+   fate-mov-guess-delay-2 \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -72,3 +74,6 @@ fate-mov-spherical-mono: CMD = run 
ffprobe$(PROGSSUF)$(EXESUF) -show_entries str
 fate-mov-gpmf-remux: CMD = md5 -i 
$(TARGET_SAMPLES)/mov/fake-gp-media-with-real-gpmf.mp4 -map 0 -c copy -fflags 
+bitexact -f mp4
 fate-mov-gpmf-remux: CMP = oneline
 fate-mov-gpmf-remux: REF = 8f48e435ee1f6b7e173ea756141eabf3
+
+fate-mov-guess-delay-1: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_nopyramid_nobsrestriction.mp4
+fate-mov-guess-delay-2: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
stream=has_b_frames -select_streams v 
$(TARGET_SAMPLES)/h264/h264_3bf_pyramid_nobsrestriction.mp4
\ No newline at end of file
diff --git a/tests/ref/fate/mov-guess-delay-1 b/tests/ref/fate/mov-guess-delay-1
new file mode 100644
index 00..96cb67be0c
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-1
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=1
+[/STREAM]
diff --git a/tests/ref/fate/mov-guess-delay-2 b/tests/ref/fate/mov-guess-delay-2
new file mode 100644
index 00..248de1c3ea
--- /dev/null
+++ b/tests/ref/fate/mov-guess-delay-2
@@ -0,0 +1,3 @@
+[STREAM]
+has_b_frames=2
+[/STREAM]
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Sasi Inguva]

restricted the patch to MPEG based codecs. Also, setting the delay only if
it's not set already and capping the max. value to 16.

On Wed, Nov 15, 2017 at 5:55 AM, Michael Niedermayer  wrote:

> On Tue, Nov 14, 2017 at 03:36:49PM -0800, Thierry Foucu wrote:
> > On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> > derek.buitenh...@gmail.com> wrote:
> >
> > > On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > > > I don't know if the patch can be made more generic to work for all
> > > > demuxers, because this patch requires that PTS of all packets be
> > > available
> > > > in the header.  The other route is to make it very specific to codecs
> > > with
> > > > B-frames.
> > >
> > > All PTS may not be available in MP4 either, in the live profile
> fragmented
> > > MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> > > code
> > > say whether we seek to each fragment and make it available or not. I
> assume
> > > you've tested such a case, or can (or know the fragment code)?
> > >
> > > It's feasible to restrict it to codecs, I suppose.
> > >
> > > >> You do not appear to be restricting this to one specific codec, or
> even
> > > >> codecs
> > > >> with B-frames.
> > > >>
> > > >> I can make it specific to only H264 / H265.
> > >
> > > The GOP structure should be applicable to most MPEG codecs, I think.
> > >
> > > > It is true that the patch will fail to compute the correct delay in
> lots
> > > of
> > > > cases. However the consequence of wrongly computing the has_b_frames
> is
> > > > pretty benign. It only increases the buffer size held for PTS
> > > reordering.
> > > > I can put a max-value check on the computed video_delay here. So in
> my
> > > > opinion, we won't see fatal regressions where a file is not able to
> be
> > > > decoded / played.
> > >
> > > It's true it's likely benign, but it's not exactly a "fix" either...
> > >
> > > From a user perspective, it's kinda possible to work around it
> "properly"
> > > (I use that term loosely here) by decoding enough frames to fill the
> max
> > > DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> > > (or in a user's code if they don't use that function), isn't it?
> Though,
> > > I feel that particular fix won't be welcomed with open arms, due to a
> > > ~16x 'slow down' in probing.
> > >
> > >
> > One option i asked on IRC was to use the spec for max DPB when the
> bitstream
> > restriction flag was not set.
> > But people were worry about low latency usage.
> > Normally, if the  bitstream restriction flag is not set, the DPB should
> be
> > set based on the spec, even if there is no B frames.
> > But in some case, it will be 16 frame and this could increase then the
> low
> > latency.
>
> it could also increase memory requirements substantially
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> ___
> 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] Allow "-to" on input files as well

[Michael Niedermayer]

On Sat, Nov 18, 2017 at 03:54:20AM +0100, Michael Niedermayer wrote:
> On Thu, Nov 16, 2017 at 11:15:11PM +0300, vi0...@gmail.com wrote:
> > From: Vitaly _Vi Shukela 
> > 
> > ---
> > 
> > Notes:
> > Second version.
> > 
> > Please CC vi0...@gmail.com when replying.
> > 
> > Note that added code is a duplicate of the respective output option 
> > processing code.
> > I'm not sure if it is worth factoring out.
> 
> 
> please submit a git patch with a useable commit message

Note: if i would apply this git am produces:

commit b259593b6a1f45c968bdaab35279fe8f507e78a2 (HEAD -> master)
Author: Vitaly _Vi Shukela 
Date:   Sat Nov 18 03:18:53 2017 +0100

Signed-off-by: Michael Niedermayer 




[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] Allow "-to" on input files as well

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 11:15:11PM +0300, vi0...@gmail.com wrote:
> From: Vitaly _Vi Shukela 
> 
> ---
> 
> Notes:
> Second version.
> 
> Please CC vi0...@gmail.com when replying.
> 
> Note that added code is a duplicate of the respective output option 
> processing code.
> I'm not sure if it is worth factoring out.


please submit a git patch with a useable commit message

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH]lavf/tcp: Fix type of argument optlen to getsockopt()

[Michael Niedermayer]

On Sun, Nov 12, 2017 at 03:29:21PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes a warning on aix here.
> 
> Please comment, Carl Eugen

>  tcp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> fa136707423e2f36ee2400c37c2d9fefb027fe80  
> 0001-lavf-tcp-Fix-the-type-of-the-optlen-argument-to-gets.patch
> From cd61d9b7b52fd6c74cb19a8e9383b3a2056e67b2 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 12 Nov 2017 15:23:14 +0100
> Subject: [PATCH] lavf/tcp: Fix the type of the optlen argument to
>  getsockopt().
> 
> Fixes a warning on aix:
> libavformat/tcp.c:283:58: warning: passing argument 5 of 'getsockopt' from 
> incompatible pointer type

should be ok if you checked the type in the specs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [mpeg4video] Fix undefined shift on assumed 8-bit input.

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 04:07:42PM -0800, Dale Curtis wrote:
> decode_user_data() attempts to create an integer |build|
> value with 8 bits of spacing for 3 components. However
> each component is an int32_t, so shifting each component
> is undefined for values outside of the 8 bit range.
> 
> This patch simply clamps input to 8-bits per component.
> 
> Signed-off-by: Dale Curtis 

>  mpeg4videodec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 5a181e6ad8a04ea0d3d6c7d08be79243995dc292  fix_mpeg4_shift_v1.patch
> From 0373fed23fb495161267607230e99c8ed36e444a Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Fri, 17 Nov 2017 16:05:30 -0800
> Subject: [PATCH] [mpeg4video] Fix undefined shift on assumed 8-bit input.
> 
> decode_user_data() attempts to create an integer |build|
> value with 8 bits of spacing for 3 components. However
> each component is an int32_t, so shifting each component
> is undefined for values outside of the 8 bit range.
> 
> This patch simply clamps input to 8-bits per component.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavcodec/mpeg4videodec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 76247c3b8c..93fa1d9973 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -2154,7 +2154,7 @@ static int decode_user_data(Mpeg4DecContext *ctx, 
> GetBitContext *gb)
>  if (e != 4) {
>  e = sscanf(buf, "Lavc%d.%d.%d", , , ) + 1;
>  if (e > 1)
> -build = (ver << 16) + (ver2 << 8) + ver3;
> +build = ((ver & 0xFF) << 16) + ((ver2 & 0xFF) << 8) + (ver3 & 
> 0xFF);

Not sure what is best but
throwing part of the version silently away is not correct
most likely erroring out and asking for a sample video to be uploaded
would make sense if such a file is encountered


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH] lavf/mov: don't read outside frag_index bounds

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 12:23:11PM -0800, Dale Curtis wrote:
> lgtm, fixes the crash and doesn't regress any of our tests.

will apply unless it breaks something in testing

thanks

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH] Ignore libavcodec/tests/mpeg12framerate, a test program

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 01:45:27AM -0800, Jim DeLaHunt wrote:
> Add to libavcodec/tests/.gitignore an entry for test
> program libavcodec/tests/mpeg12framerate . Other
> similar test programs, e.g. jpeg2000dwt and dct, are
> ignored in a similar way.
> 
> On initially checking out master, and doing "./configure"
> and "make clean", "git status" reports no untracked
> files. After running "make fate", "git status" reports
> untracked file "libavcodec/tests/mpeg12framerate".
> 
> mpeg12framerate is a unit test program. It was apparently
> introduced in commit
> 278c308ceae6b8d7bac1dfc24518821aae603988, on
> Tue Sep 12 22:11:56 2017 +0100. It added a new function
> ff_mpeg12_find_best_frame_rate() to
> libavcodec/mpeg12framerate.c , and the code in
> libavcodec/tests/mpeg12framerate.c to exercise that
> function. This commit also added the new program to
> the FATE suite, but it omitted a .gitignore entry.
> ---
>  libavcodec/tests/.gitignore | 1 +
>  1 file changed, 1 insertion(+)

will apply unless someone else is faster

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

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


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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
>  wrote:
> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> >> >> > Hi all
> >> >> >
> >> >> > I intend to make 3.4.1 very soon
> >> >>
> >> >> Shouldn't we first decide on how to proceed with #6775?
> >> >
> >> > This would be ideal.
> >> >
> >> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
> >>
> >> This was confirmed by more than one developer, yes.
> >>
> >> > I see a patch that is said to improve 6775, can that be applied and
> >> > would that resolve this ?
> >>
> >> Iiuc, it would not completely resolve the issue, see:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >>
> >> > If so why was it not applied yet ?
> >>
> >> The patch did not get support here, see:
> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> >> in compat_decode
> >
> >
> > Is someone working on fixing this better than with the available patch ?
> >
> 
> I don't even agree this needs fixing. Those projects use the API wrong.

Had we documented the correct/wrong use precissely in the past when
these wrong uses where written ?

Because if it was documented then few should have made the mistake.
But it seems this affects multiple projects, so i wonder if our API
really excluded the use


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

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


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

[FFmpeg-devel] [PATCH 1/4] configure: require libvpx-1.4.0 for vp[89] support

[James Zern]

this will simplify libvpxenc/dec.c and ensure more stable versions of
the codecs are present.

Signed-off-by: James Zern 
---
 configure | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index c8e2e35192..bfb1d9ab3a 100755
--- a/configure
+++ b/configure
@@ -5895,22 +5895,22 @@ enabled libvorbis && require_pkg_config 
libvorbis vorbis vorbis/codec.h
 
 enabled libvpx&& {
 enabled libvpx_vp8_decoder && {
-check_pkg_config libvpx_vp8_decoder "vpx >= 0.9.1" "vpx/vpx_decoder.h 
vpx/vp8dx.h" vpx_codec_vp8_dx ||
-check_lib libvpx_vp8_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
vpx_codec_dec_init_ver -lvpx ||
-die "ERROR: libvpx decoder version must be >=0.9.1";
+check_pkg_config libvpx_vp8_decoder "vpx >= 1.4.0" "vpx/vpx_decoder.h 
vpx/vp8dx.h" vpx_codec_vp8_dx ||
+check_lib libvpx_vp8_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
"vpx_codec_dec_init_ver VPX_IMG_FMT_HIGHBITDEPTH" -lvpx ||
+die "ERROR: libvpx decoder version must be >=1.4.0";
 }
 enabled libvpx_vp8_encoder && {
-check_pkg_config libvpx_vp8_encoder "vpx >= 0.9.7" "vpx/vpx_encoder.h 
vpx/vp8cx.h" vpx_codec_vp8_cx ||
-check_lib libvpx_vp8_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
"vpx_codec_enc_init_ver VP8E_SET_MAX_INTRA_BITRATE_PCT" -lvpx ||
-die "ERROR: libvpx encoder version must be >=0.9.7";
+check_pkg_config libvpx_vp8_encoder "vpx >= 1.4.0" "vpx/vpx_encoder.h 
vpx/vp8cx.h" vpx_codec_vp8_cx ||
+check_lib libvpx_vp8_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
"vpx_codec_enc_init_ver VPX_IMG_FMT_HIGHBITDEPTH" -lvpx ||
+die "ERROR: libvpx encoder version must be >=1.4.0";
 }
 enabled libvpx_vp9_decoder && {
-check_pkg_config libvpx_vp9_decoder "vpx >= 1.3.0" "vpx/vpx_decoder.h 
vpx/vp8dx.h" vpx_codec_vp9_dx ||
-check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
"vpx_codec_vp9_dx" -lvpx
+check_pkg_config libvpx_vp9_decoder "vpx >= 1.4.0" "vpx/vpx_decoder.h 
vpx/vp8dx.h" vpx_codec_vp9_dx ||
+check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
"vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
 }
 enabled libvpx_vp9_encoder && {
-check_pkg_config libvpx_vp9_encoder "vpx >= 1.3.0" "vpx/vpx_encoder.h 
vpx/vp8cx.h" vpx_codec_vp9_cx ||
-check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
"vpx_codec_vp9_cx VP9E_SET_AQ_MODE" -lvpx
+check_pkg_config libvpx_vp9_encoder "vpx >= 1.4.0" "vpx/vpx_encoder.h 
vpx/vp8cx.h" vpx_codec_vp9_cx ||
+check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
"vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
 }
 if disabled_all libvpx_vp8_decoder libvpx_vp9_decoder libvpx_vp8_encoder 
libvpx_vp9_encoder; then
 die "libvpx enabled but no supported decoders found"
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: Propagate errors in mov_switch_root.

[Moritz Barsnick]

On Thu, Nov 16, 2017 at 16:28:22 -0800, Jacob Trimble wrote:
> -if (mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX 
> }) < 0 ||
> -avio_feof(s->pb))
> +if ((ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), 
> INT64_MAX })) < 0)
> +return ret;
> +if (avio_feof(s->pb))
>  return AVERROR_EOF;

The recommendation is to use:

ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX });
if (ret < 0)
return ret;

in new code.

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

[FFmpeg-devel] [PATCH 3/4] libvpxdec: remove pre-1.4.0 checks

[James Zern]

Signed-off-by: James Zern 
---
 libavcodec/libvpxdec.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index ad0ea3b02a..2ae29d202a 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -70,7 +70,6 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img,
int has_alpha_channel)
 {
-#if VPX_IMAGE_ABI_VERSION >= 3
 static const enum AVColorSpace colorspaces[8] = {
 AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
AVCOL_SPC_SMPTE170M,
 AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
AVCOL_SPC_RGB,
@@ -82,7 +81,6 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img,
 avctx->color_range = color_ranges[img->range];
 #endif
 avctx->colorspace = colorspaces[img->cs];
-#endif
 if (avctx->codec_id == AV_CODEC_ID_VP8 && img->fmt != VPX_IMG_FMT_I420)
 return AVERROR_INVALIDDATA;
 switch (img->fmt) {
@@ -97,22 +95,15 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img,
 avctx->profile = FF_PROFILE_VP9_1;
 avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 return 0;
-#if VPX_IMAGE_ABI_VERSION >= 3
 case VPX_IMG_FMT_I440:
 avctx->profile = FF_PROFILE_VP9_1;
 avctx->pix_fmt = AV_PIX_FMT_YUV440P;
 return 0;
-#endif
 case VPX_IMG_FMT_I444:
 avctx->profile = FF_PROFILE_VP9_1;
-#if VPX_IMAGE_ABI_VERSION >= 3
 avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
  AV_PIX_FMT_GBRP : AV_PIX_FMT_YUV444P;
-#else
-avctx->pix_fmt = AV_PIX_FMT_YUV444P;
-#endif
 return 0;
-#ifdef VPX_IMG_FMT_HIGHBITDEPTH
 case VPX_IMG_FMT_I42016:
 avctx->profile = FF_PROFILE_VP9_2;
 if (img->bit_depth == 10) {
@@ -135,7 +126,6 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img,
 } else {
 return AVERROR_INVALIDDATA;
 }
-#if VPX_IMAGE_ABI_VERSION >= 3
 case VPX_IMG_FMT_I44016:
 avctx->profile = FF_PROFILE_VP9_3;
 if (img->bit_depth == 10) {
@@ -147,29 +137,19 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img,
 } else {
 return AVERROR_INVALIDDATA;
 }
-#endif
 case VPX_IMG_FMT_I44416:
 avctx->profile = FF_PROFILE_VP9_3;
 if (img->bit_depth == 10) {
-#if VPX_IMAGE_ABI_VERSION >= 3
 avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
  AV_PIX_FMT_GBRP10 : AV_PIX_FMT_YUV444P10;
-#else
-avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
-#endif
 return 0;
 } else if (img->bit_depth == 12) {
-#if VPX_IMAGE_ABI_VERSION >= 3
 avctx->pix_fmt = avctx->colorspace == AVCOL_SPC_RGB ?
  AV_PIX_FMT_GBRP12 : AV_PIX_FMT_YUV444P12;
-#else
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
-#endif
 return 0;
 } else {
 return AVERROR_INVALIDDATA;
 }
-#endif
 #endif
 default:
 return AVERROR_INVALIDDATA;
@@ -252,13 +232,8 @@ static int vpx_decode(AVCodecContext *avctx,
 }
 
 if ((ret = set_pix_fmt(avctx, img, ctx->has_alpha_channel)) < 0) {
-#ifdef VPX_IMG_FMT_HIGHBITDEPTH
 av_log(avctx, AV_LOG_ERROR, "Unsupported output colorspace (%d) / 
bit_depth (%d)\n",
img->fmt, img->bit_depth);
-#else
-av_log(avctx, AV_LOG_ERROR, "Unsupported output colorspace (%d) / 
bit_depth (%d)\n",
-   img->fmt, 8);
-#endif
 return ret;
 }
 
-- 
2.15.0.448.gf294e3d99a-goog

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

[FFmpeg-devel] [PATCH 2/4] libvpx: remove pre-1.4.0 checks

[James Zern]

Signed-off-by: James Zern 
---
 libavcodec/libvpx.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index 1eca97a081..36f915a8e5 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -40,9 +40,7 @@ static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV440P,
 AV_PIX_FMT_YUV444P,
-#if VPX_IMAGE_ABI_VERSION >= 3
 AV_PIX_FMT_GBRP,
-#endif
 AV_PIX_FMT_NONE
 };
 
@@ -60,30 +58,22 @@ static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
 AV_PIX_FMT_YUV422P12,
 AV_PIX_FMT_YUV440P12,
 AV_PIX_FMT_YUV444P12,
-#if VPX_IMAGE_ABI_VERSION >= 3
 AV_PIX_FMT_GBRP,
 AV_PIX_FMT_GBRP10,
 AV_PIX_FMT_GBRP12,
-#endif
 AV_PIX_FMT_NONE
 };
 #endif
 
 av_cold void ff_vp9_init_static(AVCodec *codec)
 {
-if (vpx_codec_version_major() < 1
-|| (vpx_codec_version_major() == 1 && vpx_codec_version_minor() < 3))
-codec->capabilities |= AV_CODEC_CAP_EXPERIMENTAL;
 codec->pix_fmts = vp9_pix_fmts_def;
 #if CONFIG_LIBVPX_VP9_ENCODER
-if (vpx_codec_version_major() > 1
-|| (vpx_codec_version_major() == 1 && vpx_codec_version_minor() >= 4)) 
{
-#ifdef VPX_CODEC_CAP_HIGHBITDEPTH
+{
 vpx_codec_caps_t codec_caps = vpx_codec_get_caps(vpx_codec_vp9_cx());
 if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH)
 codec->pix_fmts = vp9_pix_fmts_highbd;
 else
-#endif
 codec->pix_fmts = vp9_pix_fmts_highcol;
 }
 #endif
-- 
2.15.0.448.gf294e3d99a-goog

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

[FFmpeg-devel] [PATCH 4/4] libvpxenc: remove pre-1.4.0 checks

[James Zern]

Signed-off-by: James Zern 
---
 libavcodec/libvpxenc.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index fbb842499b..0258396d08 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -131,9 +131,7 @@ static const char *const ctlidstr[] = {
 [VP9E_SET_TILE_ROWS]   = "VP9E_SET_TILE_ROWS",
 [VP9E_SET_FRAME_PARALLEL_DECODING] = "VP9E_SET_FRAME_PARALLEL_DECODING",
 [VP9E_SET_AQ_MODE] = "VP9E_SET_AQ_MODE",
-#if VPX_ENCODER_ABI_VERSION > 8
 [VP9E_SET_COLOR_SPACE] = "VP9E_SET_COLOR_SPACE",
-#endif
 #if VPX_ENCODER_ABI_VERSION >= 11
 [VP9E_SET_COLOR_RANGE] = "VP9E_SET_COLOR_RANGE",
 #endif
@@ -170,7 +168,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
 av_log(avctx, level, "vpx_codec_enc_cfg\n");
 av_log(avctx, level, "generic settings\n"
"  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n  %*s%u\n"
-#if CONFIG_LIBVPX_VP9_ENCODER && defined(VPX_IMG_FMT_HIGHBITDEPTH)
+#if CONFIG_LIBVPX_VP9_ENCODER
"  %*s%u\n  %*s%u\n"
 #endif
"  %*s{%u/%u}\n  %*s%u\n  %*s%d\n  %*s%u\n",
@@ -179,7 +177,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
width, "g_profile:", cfg->g_profile,
width, "g_w:",   cfg->g_w,
width, "g_h:",   cfg->g_h,
-#if CONFIG_LIBVPX_VP9_ENCODER && defined(VPX_IMG_FMT_HIGHBITDEPTH)
+#if CONFIG_LIBVPX_VP9_ENCODER
width, "g_bit_depth:",   cfg->g_bit_depth,
width, "g_input_bit_depth:", cfg->g_input_bit_depth,
 #endif
@@ -324,9 +322,7 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
vpx_img_fmt_t *img_fmt)
 {
 VPxContext av_unused *ctx = avctx->priv_data;
-#ifdef VPX_IMG_FMT_HIGHBITDEPTH
 enccfg->g_bit_depth = enccfg->g_input_bit_depth = 8;
-#endif
 switch (avctx->pix_fmt) {
 case AV_PIX_FMT_YUV420P:
 case AV_PIX_FMT_YUVA420P:
@@ -337,19 +333,16 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
 enccfg->g_profile = 1;
 *img_fmt = VPX_IMG_FMT_I422;
 return 0;
-#if VPX_IMAGE_ABI_VERSION >= 3
 case AV_PIX_FMT_YUV440P:
 enccfg->g_profile = 1;
 *img_fmt = VPX_IMG_FMT_I440;
 return 0;
 case AV_PIX_FMT_GBRP:
 ctx->vpx_cs = VPX_CS_SRGB;
-#endif
 case AV_PIX_FMT_YUV444P:
 enccfg->g_profile = 1;
 *img_fmt = VPX_IMG_FMT_I444;
 return 0;
-#ifdef VPX_IMG_FMT_HIGHBITDEPTH
 case AV_PIX_FMT_YUV420P10:
 case AV_PIX_FMT_YUV420P12:
 if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
@@ -372,7 +365,6 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
 return 0;
 }
 break;
-#if VPX_IMAGE_ABI_VERSION >= 3
 case AV_PIX_FMT_YUV440P10:
 case AV_PIX_FMT_YUV440P12:
 if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
@@ -387,7 +379,6 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
 case AV_PIX_FMT_GBRP10:
 case AV_PIX_FMT_GBRP12:
 ctx->vpx_cs = VPX_CS_SRGB;
-#endif
 case AV_PIX_FMT_YUV444P10:
 case AV_PIX_FMT_YUV444P12:
 if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
@@ -400,7 +391,6 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
 return 0;
 }
 break;
-#endif
 default:
 break;
 }
@@ -408,7 +398,6 @@ static int set_pix_fmt(AVCodecContext *avctx, 
vpx_codec_caps_t codec_caps,
 return AVERROR_INVALIDDATA;
 }
 
-#if VPX_ENCODER_ABI_VERSION > 8
 static void set_colorspace(AVCodecContext *avctx)
 {
 enum vpx_color_space vpx_cs;
@@ -434,7 +423,6 @@ static void set_colorspace(AVCodecContext *avctx)
 }
 codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
 }
-#endif
 
 #if VPX_ENCODER_ABI_VERSION >= 11
 static void set_color_range(AVCodecContext *avctx)
@@ -701,9 +689,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 codecctl_int(avctx, VP9E_SET_FRAME_PARALLEL_DECODING, 
ctx->frame_parallel);
 if (ctx->aq_mode >= 0)
 codecctl_int(avctx, VP9E_SET_AQ_MODE, ctx->aq_mode);
-#if VPX_ENCODER_ABI_VERSION > 8
 set_colorspace(avctx);
-#endif
 #if VPX_ENCODER_ABI_VERSION >= 11
 set_color_range(avctx);
 #endif
@@ -726,7 +712,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 //provide dummy value to initialize wrapper, values will be updated each 
_encode()
 vpx_img_wrap(>rawimg, img_fmt, avctx->width, avctx->height, 1,
  (unsigned char*)1);
-#if CONFIG_LIBVPX_VP9_ENCODER && defined(VPX_IMG_FMT_HIGHBITDEPTH)
+#if CONFIG_LIBVPX_VP9_ENCODER
 if (avctx->codec_id == AV_CODEC_ID_VP9 && (codec_caps & 
VPX_CODEC_CAP_HIGHBITDEPTH))
 ctx->rawimg.bit_depth = enccfg.g_bit_depth;
 #endif
@@ -1067,11 +1053,6 @@ static int vpx_encode(AVCodecContext 

Re: [FFmpeg-devel] [PATCH] avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()

[Michael Niedermayer]

On Wed, Nov 15, 2017 at 04:25:45AM +0100, Michael Niedermayer wrote:
> Fixes: runtime error: left shift of negative value -7862264
> Fixes: 4074/clusterfuzz-testcase-minimized-4516104123711488
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mlpdsp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()

[Michael Niedermayer]

On Fri, Oct 27, 2017 at 10:09:12PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 3200/clusterfuzz-testcase-5750022136135680
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wmv2dec.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)

applied

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] avcodec/zmbv: Check that the buffer is large enough for mvec

[Michael Niedermayer]

On Wed, Nov 15, 2017 at 05:29:24PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 4143/clusterfuzz-testcase-4736864637419520
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/zmbv.c | 2 ++
>  1 file changed, 2 insertions(+)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0()

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 04:20:03AM +0100, Michael Niedermayer wrote:
> Fixes: 4035/clusterfuzz-testcase-minimized-6479308925173760
> Fixes: runtime error: signed integer overflow: 9 * 402653183 cannot be 
> represented in type 'int'
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dirac_dwt.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

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


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

[FFmpeg-devel] [PATCH 1/3] avcodec/j2kenc: reinitialize state if frame size changes

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/j2kenc.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 2135ece540..1eb091af3b 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -995,7 +995,15 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 Jpeg2000EncoderContext *s = avctx->priv_data;
 uint8_t *chunkstart, *jp2cstart, *jp2hstart;
 
-if ((ret = ff_alloc_packet2(avctx, pkt, avctx->width*avctx->height*9 + 
AV_INPUT_BUFFER_MIN_SIZE, 0)) < 0)
+if (pict->height != s->height || pict->width != s->width) {
+s->height = pict->height;
+s->width = pict->width;
+cleanup(s);
+if ((ret=init_tiles(s)) < 0)
+return ret;
+}
+
+if ((ret = ff_alloc_packet2(avctx, pkt, s->width*s->height*9 + 
AV_INPUT_BUFFER_MIN_SIZE, 0)) < 0)
 return ret;
 
 // init:
@@ -1031,8 +1039,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 chunkstart = s->buf;
 bytestream_put_be32(>buf, 0);
 bytestream_put_buffer(>buf, "ihdr", 4);
-bytestream_put_be32(>buf, avctx->height);
-bytestream_put_be32(>buf, avctx->width);
+bytestream_put_be32(>buf, s->height);
+bytestream_put_be32(>buf, s->width);
 bytestream_put_be16(>buf, s->ncomponents);
 bytestream_put_byte(>buf, s->cbps[0]);
 bytestream_put_byte(>buf, 7);
-- 
2.14.2

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

[FFmpeg-devel] [RFC] changing resolution via video filter

[Aman Gupta]

From: Aman Gupta 

This patchset is not intended to be merged, rather to start a discussion about
some limitations of the current filter graph design in ffmpeg.c

My goal here is to create preview images for a video stream with ffmpeg, with
black bars automatically cropped out. Currently, to acheive this you need to run
ffmpeg twice: once with vf_cropdetect to get the crop parameters, then again 
with
vf_crop to apply the cropping.

After this patchset, the whole thing can be done in a single command like:

  wget https://s3.amazonaws.com/tmm1/4x3-letterbox.mpg
  ./ffmpeg -hide_banner -ss 2 -i 4x3-letterbox.mpg -vf cropdetect -vframes 1 -y 
-c:v jpeg2000 preview.jpg

The main problem is that video filters cannot change the height/width of a 
frame. The
resolution is calculated up-front when the filtergraph and encoder are created,
and any attempts by a vf to change the outlink height/width are essentially 
ignored.
This is because the encoder AVCodecContext has already been initialized, and 
none of the
codecs in lavc can handle resolution changes on the fly.

With this patchset, I taught the jpeg2000 encoder to reinitialize itself when
it detects a resolution change. Then, instead of using vf_crop (which could 
easily be
taught to read cropdetect parameters from the AVFrame metadata dict), I changed
vf_cropdetect to export the crop parameters directly into the AVFrame crop 
fields.
However to make this have an effect, I also needed to add an 
av_frame_apply_cropping()
call in between the filter graph and encoder. At the moment, 
av_frame_apply_cropping()
is done right after decoding only, meaning filters cannot influence cropping 
decisions.

Obviously this is a very blunt change that fixes one very specific use-case.
But I'm curious what (if any) changes could be made to allow this to work more
generally across other existing filters and encoders.

Aman Gupta (3):
  avcodec/j2kenc: reinitialize state if frame size changes
  avfilter/vf_cropdetect: don't ignore frames, export crop parameters
  ffmpeg: apply frame cropping between filter graph and encoder

 fftools/ffmpeg.c|  4 
 libavcodec/j2kenc.c | 14 +++---
 libavfilter/vf_cropdetect.c |  9 +++--
 3 files changed, 22 insertions(+), 5 deletions(-)

-- 
2.14.2

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

Re: [FFmpeg-devel] ffmpeg for CentOS 7 tutorial is broken

[Douglas Wire]

It just moves on to VORBUS for which I have libvorbis compiled. How about I
set up a new VM and follow the tutorial exactly as I have 50 times and we
work off of that. I can take a snapshot so I can return to a spot with all
other prerequisites but no ffmpeg present and can follow along with the not
working tutorial. This way there is nothing I am doing that is the cause of
it - there is something wrong with the tutorial; something I would think
project would want fixed.

On Fri, Nov 17, 2017 at 7:27 PM, grady player  wrote:

> do you have a opus build?
> on my build system opus.pc is in the root of opus-1.1
> if that is the case for your system you should be able to set:
>
> export PKG_CONFIG_PATH=/path/to/opus then rebuild
>
> if you have multiple paths for pc files you can separate them with a colon
> `export PKG_CONFIG_PATH=/path/to/opus:/path/to/other/thing`
>
> you can also build ffmpeg without opus if you dont need it.
>
>
>
>
> > On Nov 17, 2017, at 5:16 PM, Douglas Wire 
> wrote:
> >
> > This is using the procedure right off of the webpage tutorial and it does
> > not appear it even created an OPUS.pc anywhere.
> >
> > BEGIN /tmp/ffconf.zdwwNVl9/test.c
> >1#include 
> >2#include 
> >3long check_lame_set_VBR_quality(void) { return (long)
> > lame_set_VBR_quality; }
> >4int main(void) { int ret = 0;
> >5 ret |= ((intptr_t)check_lame_set_VBR_quality) & 0x;
> >6return ret; }
> > END /tmp/ffconf.zdwwNVl9/test.c
> > gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/root/ffmpeg_build/include
> > -std=c11 -fomit-frame-pointer -pthread -I/root/ffmpeg_build/include
> > -I/usr/include/freetype2 -c -o /tmp/ffconf.zdwwNVl9/test.o
> > /tmp/ffconf.zdwwNVl9/test.c
> > gcc -L/root/ffmpeg_build/lib -Wl,--as-needed -Wl,-z,noexecstack -o
> > /tmp/ffconf.zdwwNVl9/test /tmp/ffconf.zdwwNVl9/test.o -lmp3lame -lpthread
> > require_pkg_config libopus opus opus_multistream.h
> > opus_multistream_decoder_create
> > check_pkg_config libopus opus opus_multistream.h
> > opus_multistream_decoder_create
> > test_pkg_config libopus opus opus_multistream.h
> > opus_multistream_decoder_create
> > pkg-config --exists --print-errors opus
> > Package opus was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `opus.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'opus' found
> > ERROR: opus not found using pkg-config
> >
> > The reason I mentioned the tutorial is I thought whoever rights those
> might
> > wan to revisit their work as the one for CentOS 7 is incorrect. I think I
> > cn figure out how to compile as shared on my.
> >
> > On Fri, Nov 17, 2017 at 7:02 PM, grady player 
> wrote:
> >
> >> if you post the output of failed build step, someone might have some
> >> insight... but just saying everything is broken isn't likely going to go
> >> anywhere.
> >>
> >> if you are having problems with ffmpeg-php you may want to contact their
> >> maintainers https://github.com/PHP-FFMpeg/PHP-FFMpeg/issues
> >>
> >> -grady
> >>
> >>
> >>> On Nov 17, 2017, at 4:38 PM, Douglas Wire 
> >> wrote:
> >>>
> >>> I spent a week or so at one point making a set of one liners to install
> >>> ffmpeg with a bunch of encoder support and since I need ffmpeg-php
> >> support
> >>> I was compiling as shared.
> >>>
> >>> Now nothing I wrote works and if you run the tutorial it fails with
> >>> pckg-config errors and refuses to compile. Can someone take a look at
> >> this?
> >>> I have spent three days pulling my hair out until I realized just
> >> following
> >>> your published tutorial exhibits the same failures as I have been
> seeing
> >>> with my script. Thanks in advance
> >>> ___
> >>> 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
> >>
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] ffmpeg: apply frame cropping between filter graph and encoder

[Aman Gupta]

From: Aman Gupta 

---
 fftools/ffmpeg.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index babd85f7bc..159b8e0016 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1265,6 +1265,10 @@ static void do_video_out(OutputFile *of,
enc->time_base.num, enc->time_base.den);
 }
 
+// apply any frame cropping added by filters
+av_frame_apply_cropping(in_picture, ist->dec_ctx->flags & 
AV_CODEC_FLAG_UNALIGNED ?
+AV_FRAME_CROP_UNALIGNED : 0);
+
 ost->frames_encoded++;
 
 ret = avcodec_send_frame(enc, in_picture);
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_cropdetect: don't ignore frames, export crop parameters

[Aman Gupta]

From: Aman Gupta 

---
 libavfilter/vf_cropdetect.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index 7c7d0b953a..87ecb2a6ec 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -167,8 +167,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 int outliers, last_y;
 int limit = lrint(s->limit);
 
-// ignore first 2 frames - they may be empty
-if (++s->frame_nb > 0) {
+if (1) {
+s->frame_nb++;
 metadata = >metadata;
 
 // Reset the crop area every reset_count frames, if reset_count is > 0
@@ -230,6 +230,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 SET_META("lavfi.cropdetect.x",  x);
 SET_META("lavfi.cropdetect.y",  y);
 
+frame->crop_top = y;
+frame->crop_left = x;
+frame->crop_right = frame->width - w - x;
+frame->crop_bottom = frame->height - h - y;
+
 av_log(ctx, AV_LOG_INFO,
"x1:%d x2:%d y1:%d y2:%d w:%d h:%d x:%d y:%d pts:%"PRId64" t:%f 
crop=%d:%d:%d:%d\n",
s->x1, s->x2, s->y1, s->y2, w, h, x, y, frame->pts,
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000: Dynamically allocate codeblock data

[Michael Niedermayer]

Fixes: OOM
Fixes: 3541/clusterfuzz-testcase-minimized-6469958596820992

Adds support for decoding codeblock data larger than 8kb
Reduces decoder memory consumption

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/j2kenc.c  |  8 ++--
 libavcodec/jpeg2000.c| 12 ++--
 libavcodec/jpeg2000.h|  4 ++--
 libavcodec/jpeg2000dec.c | 22 +++---
 4 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 2135ece540..362c7f0f49 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -663,7 +663,8 @@ static void encode_cblk(Jpeg2000EncoderContext *s, 
Jpeg2000T1Context *t1, Jpeg20
 bpno = cblk->nonzerobits - 1;
 }
 
-ff_mqc_initenc(>mqc, cblk->data);
+cblk->data[0] = 0;
+ff_mqc_initenc(>mqc, cblk->data + 1);
 
 for (passno = 0; bpno >= 0; passno++){
 nmsedec=0;
@@ -796,7 +797,7 @@ static int encode_packet(Jpeg2000EncoderContext *s, 
Jpeg2000ResLevel *rlevel, in
 if (cblk->ninclpasses){
 if (s->buf_end - s->buf < 
cblk->passes[cblk->ninclpasses-1].rate)
 return -1;
-bytestream_put_buffer(>buf, cblk->data,   
cblk->passes[cblk->ninclpasses-1].rate
+bytestream_put_buffer(>buf, cblk->data + 1,   
cblk->passes[cblk->ninclpasses-1].rate
- 
cblk->passes[cblk->ninclpasses-1].flushed_len);
 bytestream_put_buffer(>buf, 
cblk->passes[cblk->ninclpasses-1].flushed,

cblk->passes[cblk->ninclpasses-1].flushed_len);
@@ -937,6 +938,9 @@ static int encode_tile(Jpeg2000EncoderContext *s, 
Jpeg2000Tile *tile, int tileno
 }
 }
 }
+prec->cblk[cblkno].data = av_malloc(1 + 8192);
+if (!prec->cblk[cblkno].data)
+return AVERROR(ENOMEM);
 encode_cblk(s, , prec->cblk + cblkno, tile, xx1 - 
xx0, yy1 - yy0,
 bandpos, codsty->nreslevels - reslevelno - 
1);
 xx0 = xx1;
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index afeb9df27c..8551cf8d6c 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -357,7 +357,6 @@ static int init_prec(Jpeg2000Band *band,
  comp->reslevel[reslevelno-1].coord[1][0];
 }
 
-cblk->zero  = 0;
 cblk->lblock= 3;
 cblk->length= 0;
 memset(cblk->lengthinc, 0, sizeof(cblk->lengthinc));
@@ -598,9 +597,18 @@ void ff_jpeg2000_cleanup(Jpeg2000Component *comp, 
Jpeg2000CodingStyle *codsty)
 for (precno = 0; precno < reslevel->num_precincts_x * 
reslevel->num_precincts_y; precno++) {
 if (band->prec) {
 Jpeg2000Prec *prec = band->prec + precno;
+int nb_code_blocks = prec->nb_codeblocks_height * 
prec->nb_codeblocks_width;
+
 av_freep(>zerobits);
 av_freep(>cblkincl);
-av_freep(>cblk);
+if (prec->cblk) {
+int cblkno;
+for (cblkno = 0; cblkno < nb_code_blocks; cblkno ++) {
+Jpeg2000Cblk *cblk = >cblk[cblkno];
+av_freep(>data);
+}
+av_freep(>cblk);
+}
 }
 }
 
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 8a022ad918..eaf7faf342 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -168,8 +168,8 @@ typedef struct Jpeg2000Cblk {
 uint16_t lengthinc[JPEG2000_MAX_PASSES];
 uint8_t nb_lengthinc;
 uint8_t lblock;
-uint8_t zero;
-uint8_t data[8192];
+uint8_t *data;
+size_t data_allocated;
 int nb_terminations;
 int nb_terminationsinc;
 int data_start[JPEG2000_MAX_PASSES];
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 62b9009a82..0309b1f6fb 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1001,10 +1001,18 @@ static int 
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
 
 if ((ret = get_bits(s, av_log2(newpasses1) + cblk->lblock)) < 
0)
 return ret;
-if (ret > sizeof(cblk->data)) {
+if (ret > cblk->data_allocated) {
+size_t new_size = FFMAX(2*cblk->data_allocated, ret);
+void *new = av_realloc(cblk->data, new_size);
+if (new) {
+cblk->data = new;
+

[FFmpeg-devel] [PATCH 1/2] avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v()

[Michael Niedermayer]

Fixes: runtime error: left shift of negative value -255
Fixes: 4037/clusterfuzz-testcase-minimized-5290998163832832

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

diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index e09c661759..46a0da2045 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -1407,7 +1407,7 @@ static void FUNC(put_hevc_epel_bi_w_v)(uint8_t *_dst, 
ptrdiff_t _dststride, uint
 for (y = 0; y < height; y++) {
 for (x = 0; x < width; x++)
 dst[x] = av_clip_pixel(((EPEL_FILTER(src, srcstride) >> (BIT_DEPTH 
- 8)) * wx1 + src2[x] * wx0 +
-((ox0 + ox1 + 1) << log2Wd)) >> (log2Wd + 
1));
+((ox0 + ox1 + 1) * (1 << log2Wd))) >> 
(log2Wd + 1));
 src  += srcstride;
 dst  += dststride;
 src2 += MAX_PB_SIZE;
-- 
2.15.0

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

Re: [FFmpeg-devel] ffmpeg for CentOS 7 tutorial is broken

[grady player]

do you have a opus build?
on my build system opus.pc is in the root of opus-1.1
if that is the case for your system you should be able to set:

export PKG_CONFIG_PATH=/path/to/opus then rebuild

if you have multiple paths for pc files you can separate them with a colon 
`export PKG_CONFIG_PATH=/path/to/opus:/path/to/other/thing`

you can also build ffmpeg without opus if you dont need it.




> On Nov 17, 2017, at 5:16 PM, Douglas Wire  wrote:
> 
> This is using the procedure right off of the webpage tutorial and it does
> not appear it even created an OPUS.pc anywhere.
> 
> BEGIN /tmp/ffconf.zdwwNVl9/test.c
>1#include 
>2#include 
>3long check_lame_set_VBR_quality(void) { return (long)
> lame_set_VBR_quality; }
>4int main(void) { int ret = 0;
>5 ret |= ((intptr_t)check_lame_set_VBR_quality) & 0x;
>6return ret; }
> END /tmp/ffconf.zdwwNVl9/test.c
> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/root/ffmpeg_build/include
> -std=c11 -fomit-frame-pointer -pthread -I/root/ffmpeg_build/include
> -I/usr/include/freetype2 -c -o /tmp/ffconf.zdwwNVl9/test.o
> /tmp/ffconf.zdwwNVl9/test.c
> gcc -L/root/ffmpeg_build/lib -Wl,--as-needed -Wl,-z,noexecstack -o
> /tmp/ffconf.zdwwNVl9/test /tmp/ffconf.zdwwNVl9/test.o -lmp3lame -lpthread
> require_pkg_config libopus opus opus_multistream.h
> opus_multistream_decoder_create
> check_pkg_config libopus opus opus_multistream.h
> opus_multistream_decoder_create
> test_pkg_config libopus opus opus_multistream.h
> opus_multistream_decoder_create
> pkg-config --exists --print-errors opus
> Package opus was not found in the pkg-config search path.
> Perhaps you should add the directory containing `opus.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'opus' found
> ERROR: opus not found using pkg-config
> 
> The reason I mentioned the tutorial is I thought whoever rights those might
> wan to revisit their work as the one for CentOS 7 is incorrect. I think I
> cn figure out how to compile as shared on my.
> 
> On Fri, Nov 17, 2017 at 7:02 PM, grady player  wrote:
> 
>> if you post the output of failed build step, someone might have some
>> insight... but just saying everything is broken isn't likely going to go
>> anywhere.
>> 
>> if you are having problems with ffmpeg-php you may want to contact their
>> maintainers https://github.com/PHP-FFMpeg/PHP-FFMpeg/issues
>> 
>> -grady
>> 
>> 
>>> On Nov 17, 2017, at 4:38 PM, Douglas Wire 
>> wrote:
>>> 
>>> I spent a week or so at one point making a set of one liners to install
>>> ffmpeg with a bunch of encoder support and since I need ffmpeg-php
>> support
>>> I was compiling as shared.
>>> 
>>> Now nothing I wrote works and if you run the tutorial it fails with
>>> pckg-config errors and refuses to compile. Can someone take a look at
>> this?
>>> I have spent three days pulling my hair out until I realized just
>> following
>>> your published tutorial exhibits the same failures as I have been seeing
>>> with my script. Thanks in advance
>>> ___
>>> 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
>> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH]lavc/dnxhddata: Improve help output for yuv444p10 and gbrp10

[Carl Eugen Hoyos]

2017-11-14 18:19 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes ticket #6836 here.

Patch applied.

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

Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

[Colin NG]

Cleaned the code up.



From: ffmpeg-devel  on behalf of Carl Eugen 
Hoyos 
Sent: November 17, 2017 5:24 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-17 1:55 GMT+01:00 Colin NG :
> Excluded the fix for byte range issue and update some coding style issues.

> +if (pb) av_freep(pb);

The if() should be unnecessary.

Please avoid adding empty lines in unrelated parts of the file
and while there, try to fix "if (condition)  {" to "if (condition) {"
(one space).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...


diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 671ae9d..9bdfefd 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
 return  av_gettime() / 100;
 }
 
+static char * ishttp(char *url) {
+char *proto_name = avio_find_protocol_name(url);
+return av_strstart(proto_name, "http", NULL);
+}
+
 static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char 
*datetime)
 {
 struct tm timeinfo;
@@ -392,7 +397,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+av_freep(pb);
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, );
+
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -640,6 +647,74 @@ static int parse_manifest_segmenttimeline(AVFormatContext 
*s, struct representat
 return 0;
 }
 
+static int resolve_content_path(AVFormatContext *s, const char *url,  
xmlNodePtr *baseurl_nodes,  int n_baseurl_nodes) {
+
+int i;
+char *text;
+char tmp_str[MAX_URL_SIZE];
+char tmp_str_2[MAX_URL_SIZE];
+
+char *path = av_mallocz(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/"))) {
+nameSize = strlen(mpdName);
+}
+
+av_strlcpy (path, url, strlen(url)-nameSize+1);
+
+int rootId = 0;
+xmlNodePtr  *node = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--) {
+if (!(node = baseurl_nodes[rootId])) continue;
+if (ishttp(xmlNodeGetContent(node))) {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (node) {
+xmlNodeSetContent(node, root_url);
+}
+
+int size = strlen(root_url);
+char *isRootHttp= ishttp(root_url);
+
+char token ='/';
+if (strncmp(_url[size-1],, 1) != 0) {
+av_strlcat(root_url, "/", size+2);
+size+=2;
+}
+
+for (i = 0; i < n_baseurl_nodes; ++i) {
+if (i==rootId) continue;
+text = xmlNodeGetContent(baseurl_nodes[i]);
+if (text) {
+memset(tmp_str, 0, strlen(tmp_str));
+
+if (!ishttp(text) && isRootHttp) {
+av_strlcpy(tmp_str, root_url, size+1);
+}
+int start = (strncmp(text, , 1) == 0) ? 1: 0;
+memset(tmp_str_2, 0, strlen(tmp_str_2));
+av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
+xmlFree(text);
+xmlNodeSetContent(baseurl_nodes[i], tmp_str);
+updated = 1;
+}
+}
+
+av_free(path);
+return updated;
+
+}
 static int parse_manifest_representation(AVFormatContext *s, const char *url,
  xmlNodePtr node,
  xmlNodePtr adaptionset_node,
@@ -699,6 +774,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 baseurl_nodes[2] = adaptionset_baseurl_node;
 baseurl_nodes[3] = representation_baseurl_node;
 
+resolve_content_path(s, url, baseurl_nodes, 4);
+
 if (representation_segmenttemplate_node || fragment_template_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
@@ -994,6 +1071,9 @@ static int parse_manifest(AVFormatContext *s, const char 
*url, AVIOContext *in)
 }
 
 mpd_baseurl_node = find_child_node_by_name(node, "BaseURL");
+if 

Re: [FFmpeg-devel] ffmpeg for CentOS 7 tutorial is broken

[Douglas Wire]

This is using the procedure right off of the webpage tutorial and it does
not appear it even created an OPUS.pc anywhere.

BEGIN /tmp/ffconf.zdwwNVl9/test.c
1#include 
2#include 
3long check_lame_set_VBR_quality(void) { return (long)
lame_set_VBR_quality; }
4int main(void) { int ret = 0;
5 ret |= ((intptr_t)check_lame_set_VBR_quality) & 0x;
6return ret; }
END /tmp/ffconf.zdwwNVl9/test.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/root/ffmpeg_build/include
-std=c11 -fomit-frame-pointer -pthread -I/root/ffmpeg_build/include
-I/usr/include/freetype2 -c -o /tmp/ffconf.zdwwNVl9/test.o
/tmp/ffconf.zdwwNVl9/test.c
gcc -L/root/ffmpeg_build/lib -Wl,--as-needed -Wl,-z,noexecstack -o
/tmp/ffconf.zdwwNVl9/test /tmp/ffconf.zdwwNVl9/test.o -lmp3lame -lpthread
require_pkg_config libopus opus opus_multistream.h
opus_multistream_decoder_create
check_pkg_config libopus opus opus_multistream.h
opus_multistream_decoder_create
test_pkg_config libopus opus opus_multistream.h
opus_multistream_decoder_create
pkg-config --exists --print-errors opus
Package opus was not found in the pkg-config search path.
Perhaps you should add the directory containing `opus.pc'
to the PKG_CONFIG_PATH environment variable
No package 'opus' found
ERROR: opus not found using pkg-config

The reason I mentioned the tutorial is I thought whoever rights those might
wan to revisit their work as the one for CentOS 7 is incorrect. I think I
cn figure out how to compile as shared on my.

On Fri, Nov 17, 2017 at 7:02 PM, grady player  wrote:

> if you post the output of failed build step, someone might have some
> insight... but just saying everything is broken isn't likely going to go
> anywhere.
>
> if you are having problems with ffmpeg-php you may want to contact their
> maintainers https://github.com/PHP-FFMpeg/PHP-FFMpeg/issues
>
> -grady
>
>
> > On Nov 17, 2017, at 4:38 PM, Douglas Wire 
> wrote:
> >
> > I spent a week or so at one point making a set of one liners to install
> > ffmpeg with a bunch of encoder support and since I need ffmpeg-php
> support
> > I was compiling as shared.
> >
> > Now nothing I wrote works and if you run the tutorial it fails with
> > pckg-config errors and refuses to compile. Can someone take a look at
> this?
> > I have spent three days pulling my hair out until I realized just
> following
> > your published tutorial exhibits the same failures as I have been seeing
> > with my script. Thanks in advance
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tcp: Fix type of argument optlen to getsockopt()

[Carl Eugen Hoyos]

2017-11-12 15:29 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes a warning on aix here.

Ping.

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

[FFmpeg-devel] [mpeg4video] Fix undefined shift on assumed 8-bit input.

[Dale Curtis]

decode_user_data() attempts to create an integer |build|
value with 8 bits of spacing for 3 components. However
each component is an int32_t, so shifting each component
is undefined for values outside of the 8 bit range.

This patch simply clamps input to 8-bits per component.

Signed-off-by: Dale Curtis 
From 0373fed23fb495161267607230e99c8ed36e444a Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 16:05:30 -0800
Subject: [PATCH] [mpeg4video] Fix undefined shift on assumed 8-bit input.

decode_user_data() attempts to create an integer |build|
value with 8 bits of spacing for 3 components. However
each component is an int32_t, so shifting each component
is undefined for values outside of the 8 bit range.

This patch simply clamps input to 8-bits per component.

Signed-off-by: Dale Curtis 
---
 libavcodec/mpeg4videodec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 76247c3b8c..93fa1d9973 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2154,7 +2154,7 @@ static int decode_user_data(Mpeg4DecContext *ctx, GetBitContext *gb)
 if (e != 4) {
 e = sscanf(buf, "Lavc%d.%d.%d", , , ) + 1;
 if (e > 1)
-build = (ver << 16) + (ver2 << 8) + ver3;
+build = ((ver & 0xFF) << 16) + ((ver2 & 0xFF) << 8) + (ver3 & 0xFF);
 }
 if (e != 4) {
 if (strcmp(buf, "ffmpeg") == 0)
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] ffmpeg for CentOS 7 tutorial is broken

[grady player]

if you post the output of failed build step, someone might have some insight... 
but just saying everything is broken isn't likely going to go anywhere.

if you are having problems with ffmpeg-php you may want to contact their 
maintainers https://github.com/PHP-FFMpeg/PHP-FFMpeg/issues

-grady


> On Nov 17, 2017, at 4:38 PM, Douglas Wire  wrote:
> 
> I spent a week or so at one point making a set of one liners to install
> ffmpeg with a bunch of encoder support and since I need ffmpeg-php support
> I was compiling as shared.
> 
> Now nothing I wrote works and if you run the tutorial it fails with
> pckg-config errors and refuses to compile. Can someone take a look at this?
> I have spent three days pulling my hair out until I realized just following
> your published tutorial exhibits the same failures as I have been seeing
> with my script. Thanks in advance
> ___
> 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

[FFmpeg-devel] ffmpeg for CentOS 7 tutorial is broken

[Douglas Wire]

I spent a week or so at one point making a set of one liners to install
ffmpeg with a bunch of encoder support and since I need ffmpeg-php support
I was compiling as shared.

Now nothing I wrote works and if you run the tutorial it fails with
pckg-config errors and refuses to compile. Can someone take a look at this?
I have spent three days pulling my hair out until I realized just following
your published tutorial exhibits the same failures as I have been seeing
with my script. Thanks in advance
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

[Aman Gupta]

On Fri, Nov 17, 2017 at 3:14 PM Hendrik Leppkes  wrote:

> On Fri, Nov 17, 2017 at 11:44 PM, Aman Gupta  wrote:
> > On Wed, Nov 15, 2017 at 1:57 PM, Hendrik Leppkes 
> > wrote:
> >
> >> On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta  wrote:
> >> > From: Aman Gupta 
> >> >
> >> > Previously the codec kept an entire copy of the SPS, and restarted the
> >> VT decoder
> >> > session whenever it changed. This fixed decoding errors in [1], as
> >> > described in 9519983c. On further inspection, that sample features an
> >> SPS change
> >> > from High/4.0 to High/3.2 while moving from one scene to another.
> >> >
> >> > Yesterday I received [2], which contains minor SPS changes where the
> >> > profile and level do not change. These occur frequently and are not
> >> associated with
> >> > scene changes. After 9519983c, the VT decoder session is recreated
> >> unnecessarily when
> >> > these are encountered causing visual glitches.
> >> >
> >> > This commit simplifies the state kept in the VTContext to include just
> >> the first three
> >> > bytes of the SPS, containing the profile and level details. This is
> >> populated initially
> >> > when the VT decoder session is created, and used to detect changes and
> >> force a restart.
> >> >
> >> > This means minor SPS changes are fed directly into the existing
> decoder,
> >> whereas
> >> > profile/level changes force the decoder session to be recreated with
> the
> >> new parameters.
> >> >
> >>
> >> The profile and level are not exactly the only things that can change
> >> to force a decoder to be re-created.
> >> How about the frame dimensions, within the same level?
> >>
> >
> > I compared the different SPS present in the spschange2.ts sample, and
> here
> > is a diff:
> >
> >  === SPS ===
> >   profile_idc : 100
> >   constraint_set0_flag : 0
> >   constraint_set1_flag : 0
> >   constraint_set2_flag : 0
> >   constraint_set3_flag : 0
> >   constraint_set4_flag : 0
> >   constraint_set5_flag : 0
> >   reserved_zero_2bits : 0
> >   level_idc : 40
> >   seq_parameter_set_id : 0
> >   chroma_format_idc : 1
> >   residual_colour_transform_flag : 0
> >   bit_depth_luma_minus8 : 0
> >   bit_depth_chroma_minus8 : 0
> >   qpprime_y_zero_transform_bypass_flag : 0
> >   seq_scaling_matrix_present_flag : 1
> >   log2_max_frame_num_minus4 : 0
> > - pic_order_cnt_type : 1
> > + pic_order_cnt_type : 0
> > -   log2_max_pic_order_cnt_lsb_minus4 : 0
> > +   log2_max_pic_order_cnt_lsb_minus4 : 3
> > delta_pic_order_always_zero_flag : 0
> > offset_for_non_ref_pic : 0
> > -   offset_for_top_to_bottom_field : 7
> > +   offset_for_top_to_bottom_field : 0
> > -   num_ref_frames_in_pic_order_cnt_cycle : 7
> > +   num_ref_frames_in_pic_order_cnt_cycle : 0
> > - num_ref_frames : 3
> > + num_ref_frames : 0
> > - gaps_in_frame_num_value_allowed_flag : 0
> > + gaps_in_frame_num_value_allowed_flag : 1
> > - pic_width_in_mbs_minus1 : 13
> > + pic_width_in_mbs_minus1 : 81
> > - pic_height_in_map_units_minus1 : 2
> > + pic_height_in_map_units_minus1 : 38
> >   frame_mbs_only_flag : 1
> >   mb_adaptive_frame_field_flag : 0
> >   direct_8x8_inference_flag : 0
> >   frame_cropping_flag : 0
> > frame_crop_left_offset : 0
> > frame_crop_right_offset : 0
> > frame_crop_top_offset : 0
> > frame_crop_bottom_offset : 0
> > - vui_parameters_present_flag : 1
> > + vui_parameters_present_flag : 0
> >
> > Interestingly, the pic_height/pic_width do in fact change already in that
> > sample. But the correct thing to do, as far as decoding with
> VideoToolbox,
> > is to keep the same decompression session instance and pass the new SPS
> > NALU into the decoder along with the image slices.
> >
>
> Does it actually properly output images of the new size in that case?
>
> All I'm saying is that profile and level may not exactly be the
> parameters that actually require a re-creation. Profile maybe, but
> level unlikely. And there might as well be others.


> Is this not documented?


I understand what you're saying, but there is no documentation about this
from Apple so I can only deduce what is required empirically.

I already confirmed that level changes require a decoder restart, as seen
in the first sample (which goes from level 40 to 32). Without a restart the
VT decoder stalls and fails to produce any new frames.

Aman


>
> - Hendrik
> ___
> 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] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

[Hendrik Leppkes]

On Fri, Nov 17, 2017 at 11:44 PM, Aman Gupta  wrote:
> On Wed, Nov 15, 2017 at 1:57 PM, Hendrik Leppkes 
> wrote:
>
>> On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta  wrote:
>> > From: Aman Gupta 
>> >
>> > Previously the codec kept an entire copy of the SPS, and restarted the
>> VT decoder
>> > session whenever it changed. This fixed decoding errors in [1], as
>> > described in 9519983c. On further inspection, that sample features an
>> SPS change
>> > from High/4.0 to High/3.2 while moving from one scene to another.
>> >
>> > Yesterday I received [2], which contains minor SPS changes where the
>> > profile and level do not change. These occur frequently and are not
>> associated with
>> > scene changes. After 9519983c, the VT decoder session is recreated
>> unnecessarily when
>> > these are encountered causing visual glitches.
>> >
>> > This commit simplifies the state kept in the VTContext to include just
>> the first three
>> > bytes of the SPS, containing the profile and level details. This is
>> populated initially
>> > when the VT decoder session is created, and used to detect changes and
>> force a restart.
>> >
>> > This means minor SPS changes are fed directly into the existing decoder,
>> whereas
>> > profile/level changes force the decoder session to be recreated with the
>> new parameters.
>> >
>>
>> The profile and level are not exactly the only things that can change
>> to force a decoder to be re-created.
>> How about the frame dimensions, within the same level?
>>
>
> I compared the different SPS present in the spschange2.ts sample, and here
> is a diff:
>
>  === SPS ===
>   profile_idc : 100
>   constraint_set0_flag : 0
>   constraint_set1_flag : 0
>   constraint_set2_flag : 0
>   constraint_set3_flag : 0
>   constraint_set4_flag : 0
>   constraint_set5_flag : 0
>   reserved_zero_2bits : 0
>   level_idc : 40
>   seq_parameter_set_id : 0
>   chroma_format_idc : 1
>   residual_colour_transform_flag : 0
>   bit_depth_luma_minus8 : 0
>   bit_depth_chroma_minus8 : 0
>   qpprime_y_zero_transform_bypass_flag : 0
>   seq_scaling_matrix_present_flag : 1
>   log2_max_frame_num_minus4 : 0
> - pic_order_cnt_type : 1
> + pic_order_cnt_type : 0
> -   log2_max_pic_order_cnt_lsb_minus4 : 0
> +   log2_max_pic_order_cnt_lsb_minus4 : 3
> delta_pic_order_always_zero_flag : 0
> offset_for_non_ref_pic : 0
> -   offset_for_top_to_bottom_field : 7
> +   offset_for_top_to_bottom_field : 0
> -   num_ref_frames_in_pic_order_cnt_cycle : 7
> +   num_ref_frames_in_pic_order_cnt_cycle : 0
> - num_ref_frames : 3
> + num_ref_frames : 0
> - gaps_in_frame_num_value_allowed_flag : 0
> + gaps_in_frame_num_value_allowed_flag : 1
> - pic_width_in_mbs_minus1 : 13
> + pic_width_in_mbs_minus1 : 81
> - pic_height_in_map_units_minus1 : 2
> + pic_height_in_map_units_minus1 : 38
>   frame_mbs_only_flag : 1
>   mb_adaptive_frame_field_flag : 0
>   direct_8x8_inference_flag : 0
>   frame_cropping_flag : 0
> frame_crop_left_offset : 0
> frame_crop_right_offset : 0
> frame_crop_top_offset : 0
> frame_crop_bottom_offset : 0
> - vui_parameters_present_flag : 1
> + vui_parameters_present_flag : 0
>
> Interestingly, the pic_height/pic_width do in fact change already in that
> sample. But the correct thing to do, as far as decoding with VideoToolbox,
> is to keep the same decompression session instance and pass the new SPS
> NALU into the decoder along with the image slices.
>

Does it actually properly output images of the new size in that case?

All I'm saying is that profile and level may not exactly be the
parameters that actually require a re-creation. Profile maybe, but
level unlikely. And there might as well be others.
Is this not documented?

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

[FFmpeg-devel] [PATCH] Download dash content with byte range info

[Colin NG]

---
 libavformat/dashdec.c | 39 +--
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..671ae9d 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,25 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * get_Fragment(char *range)
+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+if (!seg)
+return NULL;
+
+memset(seg, 0, sizeof(struct fragment));
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,33 +549,40 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;
 
 if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = get_Fragment(range_val);
 if (!rep->init_section) {
 xmlFree(initialization_val);
+xmlFree(range_val);
 return AVERROR(ENOMEM);
 }
 rep->init_section->url = get_content_url(baseurl_nodes, 4,
  rep_id_val,
  rep_bandwidth_val,
  initialization_val);
+
 if (!rep->init_section->url) {
 av_free(rep->init_section);
 xmlFree(initialization_val);
+xmlFree(range_val);
 return AVERROR(ENOMEM);
 }
-rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  get_Fragment(range_val);
 if (!seg) {
 xmlFree(media_val);
+xmlFree(range_val);
 return AVERROR(ENOMEM);
 }
 seg->url = get_content_url(baseurl_nodes, 4,
@@ -566,11 +592,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 if (!seg->url) {
 av_free(seg);
 xmlFree(media_val);
+xmlFree(range_val);
 return AVERROR(ENOMEM);
 }
-seg->size = -1;
 dynarray_add(>fragments, >n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }
 
-- 
2.7.4

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

[FFmpeg-devel] [mov] Fix leak of frame_duration_buffer in mov_fix_index().

[Dale Curtis]

Should be unconditionally freed at the end of mov_fix_index() in case it
hasn't been used during the fix up.

Signed-off-by: Dale Curtis 
From bbdf90542a98bb297d4143949e3281500815d0b1 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 14:53:25 -0800
Subject: [PATCH] [mov] Fix leak of frame_duration_buffer in mov_fix_index().

Should be unconditionally freed at the end of mov_fix_index() in
case it hasn't been used during the fix up.

Signed-off-by: Dale Curtis 
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d49d820d2b..3eef043046 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3553,6 +3553,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 // Free the old index and the old CTTS structures
 av_free(e_old);
 av_free(ctts_data_old);
+av_freep(_duration_buffer);
 
 // Null terminate the index ranges array
 current_index_range++;
-- 
2.15.0.448.gf294e3d99a-goog

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

[FFmpeg-devel] [mpegaudio] Use ff_thread_once for fixed, float table init.

[Dale Curtis]

These tables are static so they should only be initialized once
instead of on every call to ff_mpadsp_init().

Signed-off-by: Dale Curtis 
From 70ffbeb41f0432c72701f6147385e9aa47bf8419 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 14:51:09 -0800
Subject: [PATCH] [mpegaudio] Use ff_thread_once for fixed, float table init.

These tables are static so they should only be initialized once
instead of on every call to ff_mpadsp_init().

Signed-off-by: Dale Curtis 
---
 libavcodec/mpegaudiodsp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mpegaudiodsp.c b/libavcodec/mpegaudiodsp.c
index a5d20df629..3cafca27bf 100644
--- a/libavcodec/mpegaudiodsp.c
+++ b/libavcodec/mpegaudiodsp.c
@@ -20,17 +20,21 @@
 
 #include "config.h"
 #include "libavutil/attributes.h"
+#include "libavutil/thread.h"
 #include "mpegaudiodsp.h"
 #include "dct.h"
 #include "dct32.h"
 
+static AVOnce mpadsp_float_table_init = AV_ONCE_INIT;
+static AVOnce mpadsp_fixed_table_init = AV_ONCE_INIT;
+
 av_cold void ff_mpadsp_init(MPADSPContext *s)
 {
 DCTContext dct;
 
 ff_dct_init(, 5, DCT_II);
-ff_init_mpadsp_tabs_float();
-ff_init_mpadsp_tabs_fixed();
+ff_thread_once(_float_table_init, _init_mpadsp_tabs_float);
+ff_thread_once(_fixed_table_init, _init_mpadsp_tabs_fixed);
 
 s->apply_window_float = ff_mpadsp_apply_window_float;
 s->apply_window_fixed = ff_mpadsp_apply_window_fixed;
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolbox: fix decoding of h264 streams with minor SPS changes

[Aman Gupta]

On Wed, Nov 15, 2017 at 1:57 PM, Hendrik Leppkes 
wrote:

> On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta  wrote:
> > From: Aman Gupta 
> >
> > Previously the codec kept an entire copy of the SPS, and restarted the
> VT decoder
> > session whenever it changed. This fixed decoding errors in [1], as
> > described in 9519983c. On further inspection, that sample features an
> SPS change
> > from High/4.0 to High/3.2 while moving from one scene to another.
> >
> > Yesterday I received [2], which contains minor SPS changes where the
> > profile and level do not change. These occur frequently and are not
> associated with
> > scene changes. After 9519983c, the VT decoder session is recreated
> unnecessarily when
> > these are encountered causing visual glitches.
> >
> > This commit simplifies the state kept in the VTContext to include just
> the first three
> > bytes of the SPS, containing the profile and level details. This is
> populated initially
> > when the VT decoder session is created, and used to detect changes and
> force a restart.
> >
> > This means minor SPS changes are fed directly into the existing decoder,
> whereas
> > profile/level changes force the decoder session to be recreated with the
> new parameters.
> >
>
> The profile and level are not exactly the only things that can change
> to force a decoder to be re-created.
> How about the frame dimensions, within the same level?
>

I compared the different SPS present in the spschange2.ts sample, and here
is a diff:

 === SPS ===
  profile_idc : 100
  constraint_set0_flag : 0
  constraint_set1_flag : 0
  constraint_set2_flag : 0
  constraint_set3_flag : 0
  constraint_set4_flag : 0
  constraint_set5_flag : 0
  reserved_zero_2bits : 0
  level_idc : 40
  seq_parameter_set_id : 0
  chroma_format_idc : 1
  residual_colour_transform_flag : 0
  bit_depth_luma_minus8 : 0
  bit_depth_chroma_minus8 : 0
  qpprime_y_zero_transform_bypass_flag : 0
  seq_scaling_matrix_present_flag : 1
  log2_max_frame_num_minus4 : 0
- pic_order_cnt_type : 1
+ pic_order_cnt_type : 0
-   log2_max_pic_order_cnt_lsb_minus4 : 0
+   log2_max_pic_order_cnt_lsb_minus4 : 3
delta_pic_order_always_zero_flag : 0
offset_for_non_ref_pic : 0
-   offset_for_top_to_bottom_field : 7
+   offset_for_top_to_bottom_field : 0
-   num_ref_frames_in_pic_order_cnt_cycle : 7
+   num_ref_frames_in_pic_order_cnt_cycle : 0
- num_ref_frames : 3
+ num_ref_frames : 0
- gaps_in_frame_num_value_allowed_flag : 0
+ gaps_in_frame_num_value_allowed_flag : 1
- pic_width_in_mbs_minus1 : 13
+ pic_width_in_mbs_minus1 : 81
- pic_height_in_map_units_minus1 : 2
+ pic_height_in_map_units_minus1 : 38
  frame_mbs_only_flag : 1
  mb_adaptive_frame_field_flag : 0
  direct_8x8_inference_flag : 0
  frame_cropping_flag : 0
frame_crop_left_offset : 0
frame_crop_right_offset : 0
frame_crop_top_offset : 0
frame_crop_bottom_offset : 0
- vui_parameters_present_flag : 1
+ vui_parameters_present_flag : 0

Interestingly, the pic_height/pic_width do in fact change already in that
sample. But the correct thing to do, as far as decoding with VideoToolbox,
is to keep the same decompression session instance and pass the new SPS
NALU into the decoder along with the image slices.

Aman


>
> - Hendrik
> ___
> 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] hwcontext_d3d11va: add missing stdint.h include

[Timo Rothenpieler]

applied



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 1/2] avcodec/snowdec: Check intra block dc differences.

[Carl Eugen Hoyos]

2017-11-17 1:47 GMT+01:00 Ronald S. Bultje :

> stop being difficult.

Yes please!

I have no idea what's driving you but please stop this childish
attitude: You haven't answered to a bug report since an eternity,
so you simply cannot claim that error messages are unneeded.

Please stop this behaviour, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Download dash content with byte range info

[Colin NG]

Fixed the range_val leak problem.



From: ffmpeg-devel  on behalf of Michael 
Niedermayer 
Sent: November 17, 2017 12:15 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Download dash content with byte range info

On Thu, Nov 16, 2017 at 08:33:35PM +, Colin NG wrote:
> ---
>  libavformat/dashdec.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 0e3afd2..33255f2 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
>  return type;
>  }
>
> +static struct fragment * get_Fragment(char *range) {
> +struct fragment * seg = av_mallocz(sizeof(struct fragment));
> +
> +if (!seg)
> +return NULL;
> +
> +seg->size = -1;
> +if (range)  {
> +char *str_end_offset;
> +char *str_offset = av_strtok(range, "-", _end_offset);
> +seg->url_offset = strtoll(str_offset, NULL, 10);
> +seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset+1;
> +}
> +return seg;
> +}
> +
>  static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
> representation *rep,
>   xmlNodePtr fragmenturl_node,
>   xmlNodePtr *baseurl_nodes,
> @@ -530,11 +546,13 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  {
>  char *initialization_val = NULL;
>  char *media_val = NULL;
> +char *range_val = NULL;
>
>  if (!av_strcasecmp(fragmenturl_node->name, (const char 
> *)"Initialization")) {
>  initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
> -if (initialization_val) {
> -rep->init_section = av_mallocz(sizeof(struct fragment));
> +range_val = xmlGetProp(fragmenturl_node, "range");
> +if (initialization_val || range_val) {
> +rep->init_section = get_Fragment(range_val);
>  if (!rep->init_section) {
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
> @@ -548,13 +566,14 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
>  }
> -rep->init_section->size = -1;
>  xmlFree(initialization_val);
> +xmlFree(range_val);
>  }
>  } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
> *)"SegmentURL")) {
>  media_val = xmlGetProp(fragmenturl_node, "media");
> -if (media_val) {
> -struct fragment *seg = av_mallocz(sizeof(struct fragment));
> +range_val = xmlGetProp(fragmenturl_node, "mediaRange");
> +if (media_val || range_val) {
> +struct fragment *seg =  get_Fragment(range_val);
>  if (!seg) {
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
> @@ -568,15 +587,14 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
>  }
> -seg->size = -1;
>  dynarray_add(>fragments, >n_fragments, seg);
>  xmlFree(media_val);
> +xmlFree(range_val);
>  }

I think this is leaking range_val in some error paths


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

Democracy is the form of government in which you can choose your dictator
From 61c79e979ba7586b7fbf98e674dfcd4d4adc5797 Mon Sep 17 00:00:00 2001
From: Colin Ng 
Date: Fri, 17 Nov 2017 13:59:13 -0800
Subject: [PATCH] Download dash content with byte range info

---
 libavformat/dashdec.c | 38 --
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..8a575d5 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,25 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * get_Fragment(char *range)
+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+if (!seg)
+return NULL;
+
+memset(seg, 0, sizeof(struct fragment));
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct representation *rep,
 

Re: [FFmpeg-devel] [avformat] Prevent undefined shift with wrap_bits > 63.

[Dale Curtis]

Derp, actually, 2 << 63 doesn't fit in int64_t either, this check should be
< 63. Fixed.



On Fri, Nov 17, 2017 at 1:38 PM, Dale Curtis 
wrote:

> 2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check
> used in other places that handle wrap bits to ensure the values
> are <= 63.
>
> Signed-off-by: Dale Curtis 
>
>
From 4ae4992326487ba0e42fa7fcf2a53fe3d4564780 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 13:35:56 -0800
Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits >= 63.

2 << (wrap_bits=63 - 1) does not fit in int64_t; apply the check
used in other places that handle wrap bits to ensure the values
are < 63.

Signed-off-by: Dale Curtis 
---
 libavformat/utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index ff5e14df6c..65d111459f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1738,8 +1738,8 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
 // current one had no dts, we will set this to AV_NOPTS_VALUE.
 int64_t last_dts = next_pkt->dts;
 while (pktl && next_pkt->pts == AV_NOPTS_VALUE) {
-if (pktl->pkt.stream_index == next_pkt->stream_index &&
-(av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0)) {
+if (pktl->pkt.stream_index == next_pkt->stream_index && wrap_bits < 63 &&
+av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0) {
 if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2LL << (wrap_bits - 1))) {
 // not B-frame
 next_pkt->pts = pktl->pkt.dts;
-- 
2.15.0.448.gf294e3d99a-goog

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

[FFmpeg-devel] [avformat] Prevent undefined shift with wrap_bits > 63.

[Dale Curtis]

2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check
used in other places that handle wrap bits to ensure the values
are <= 63.

Signed-off-by: Dale Curtis 
From c566067623760a24f729ac5197c20531b9e518ae Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Fri, 17 Nov 2017 13:35:56 -0800
Subject: [PATCH] [avformat] Prevent undefined shift with wrap_bits > 63.

2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check
used in other places that handle wrap bits to ensure the values
are <= 63.

Signed-off-by: Dale Curtis 
---
 libavformat/utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index ff5e14df6c..50bc6ca62d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1738,8 +1738,8 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
 // current one had no dts, we will set this to AV_NOPTS_VALUE.
 int64_t last_dts = next_pkt->dts;
 while (pktl && next_pkt->pts == AV_NOPTS_VALUE) {
-if (pktl->pkt.stream_index == next_pkt->stream_index &&
-(av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0)) {
+if (pktl->pkt.stream_index == next_pkt->stream_index && wrap_bits <= 63 &&
+av_compare_mod(next_pkt->dts, pktl->pkt.dts, 2LL << (wrap_bits - 1)) < 0) {
 if (av_compare_mod(pktl->pkt.pts, pktl->pkt.dts, 2LL << (wrap_bits - 1))) {
 // not B-frame
 next_pkt->pts = pktl->pkt.dts;
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 05:10:17PM -0300, James Almer wrote:
> On 11/17/2017 4:20 PM, James Almer wrote:
> > On 11/17/2017 4:16 PM, Michael Niedermayer wrote:
> >> On Thu, Nov 16, 2017 at 03:07:54PM -0800, Nick Lewycky wrote:
> >>> Sorry! Let's try an attachment then.
> >>>
> >>> On 16 November 2017 at 14:36, Michael Niedermayer
> >>>  wrote:
>  On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
> > I initially discovered a signed integer overflow on this line. Since
> > this value is updated in multiple threads, I use an atomic update and
> > as it happens atomic addition is defined to wrap around. However,
> > there's still a potential bug in that the error_count may wrap around
> > and equal zero again causing problems down the line.
> >
> > ---
> >  libavcodec/mpeg12dec.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > index d5bc5f21b2..b7c3b5106e 100644
> > --- a/libavcodec/mpeg12dec.c
> > +++ b/libavcodec/mpeg12dec.c
> > @@ -28,6 +28,7 @@
> >  #define UNCHECKED_BITSTREAM_READER 1
> >  #include 
> >
> > +#include "libavutil/atomic.h"
> >  #include "libavutil/attributes.h"
> >  #include "libavutil/imgutils.h"
> >  #include "libavutil/internal.h"
> > @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
> > AVFrame *picture,
> > >thread_context[0], NULL,
> > s->slice_count, sizeof(void *));
> >  for (i = 0; i < s->slice_count; i++)
> > -s2->er.error_count +=
> > s2->thread_context[i]->er.error_count;
> > +
> > avpriv_atomic_int_add_and_fetch(>er.error_count,
> > s2->thread_context[i]->er.error_count);
> >  }
> 
>  This patch is corrupted by newlines
> 
>  [...]
> 
>  --
>  Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
>  Dictatorship naturally arises out of democracy, and the most aggravated
>  form of tyranny and slavery out of the most extreme liberty. -- Plato
> 
>  ___
>  ffmpeg-devel mailing list
>  ffmpeg-devel@ffmpeg.org
>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> >>
> >>>  mpeg12dec.c |3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>> eed6baa2f9ae5b6fcd227e4b7fa0e87e9ca55b64  
> >>> 0001-libavcodec-mpeg12dec-Use-atomic-addition-for-value-u.patch
> >>> From cd8ed0ee35853ae089df3d904846879ce4f00c4a Mon Sep 17 00:00:00 2001
> >>> From: Nick Lewycky 
> >>> Date: Thu, 16 Nov 2017 11:50:38 -0800
> >>> Subject: [PATCH] libavcodec/mpeg12dec: Use atomic addition for value 
> >>> updated
> >>>  in multiple threads.
> >>
> >> LGTM, unless theres a new API for doing this, in which case the new
> >> style should be used.
> > 
> > Yes, he should use C11 atomics. It's been mentioned to everyone that
> > submitted code using the old lavu wrappers, including you some days ago.
> 
> To expand on this, I'm aware that the entire error resilience feature
> needs to be ported to C11 atomics. My point is that, much like i said to
> you in that patch some days ago, it should be ported before adding new
> code that will ultimately make the port harder.

Yes, i did not yet had time to update the patch

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

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


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

[FFmpeg-devel] [PATCH] avfilter/vf_tile: add queue option

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  4 
 libavfilter/vf_tile.c | 18 +-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 5d99437871..7eeeafab8e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14461,6 +14461,10 @@ is "black".
 @item overlap
 Set the number of frames to overlap when tiling several successive frames 
together.
 The value must be between @code{0} and @var{nb_frames - 1}.
+
+@item queue
+Set the number of frames to initially queue when displaying first frame.
+The value must be between @code{0} and @var{nb_frames}.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index 7717ce12e7..dfc9377569 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -38,6 +38,7 @@ typedef struct TileContext {
 unsigned margin;
 unsigned padding;
 unsigned overlap;
+unsigned queue;
 unsigned current;
 unsigned nb_frames;
 FFDrawContext draw;
@@ -62,6 +63,8 @@ static const AVOption tile_options[] = {
 { "color",   "set the color of the unused area", OFFSET(rgba_color), 
AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
 { "overlap", "set how many frames to overlap for each render", 
OFFSET(overlap),
 AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
+{ "queue", " set how many frames to initially queue", OFFSET(queue),
+AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
@@ -99,6 +102,19 @@ static av_cold int init(AVFilterContext *ctx)
 tile->overlap = tile->nb_frames - 1;
 }
 
+if (!tile->queue) {
+tile->queue = tile->nb_frames;
+tile->current = 0;
+} else {
+if (tile->queue > tile->nb_frames) {
+av_log(ctx, AV_LOG_WARNING, "queue must be less than or equal to 
%d\n", tile->nb_frames);
+tile->queue = tile->nb_frames;
+tile->current = 0;
+} else {
+tile->current = tile->nb_frames - tile->queue;
+}
+}
+
 return 0;
 }
 
@@ -201,7 +217,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
 tile->out_ref->height = outlink->h;
 
 /* fill surface once for margin/padding */
-if (tile->margin || tile->padding)
+if (tile->margin || tile->padding || tile->queue != tile->nb_frames)
 ff_fill_rectangle(>draw, >blank,
   tile->out_ref->data,
   tile->out_ref->linesize,
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: don't read outside frag_index bounds

[Dale Curtis]

lgtm, fixes the crash and doesn't regress any of our tests.

- dale

On Fri, Nov 17, 2017 at 8:21 AM, John Stebbins 
wrote:

> Potentially fixes:
> https://bugs.chromium.org/p/chromium/issues/detail?id=786269#c1
>
> In theory, the crash can be triggered by an invalid stream that has
> either tfdt or trun outside of the moof
> ---
>  libavformat/mov.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d49d820d2b..0fbc7f54a2 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1188,6 +1188,10 @@ static void set_frag_stream(MOVFragmentIndex
> *frag_index, int id)
>  static MOVFragmentStreamInfo * get_current_frag_stream_info(
>  MOVFragmentIndex *frag_index)
>  {
> +if (frag_index->current < 0 ||
> +frag_index->current >= frag_index->nb_items)
> +return NULL;
> +
>  MOVFragmentIndexItem * item = _index->item[frag_index->current];
>  if (item->current >= 0 && item->current < item->nb_stream_info)
>  return >stream_info[item->current];
> --
> 2.13.6
>
> ___
> 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] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

[James Almer]

On 11/17/2017 4:20 PM, James Almer wrote:
> On 11/17/2017 4:16 PM, Michael Niedermayer wrote:
>> On Thu, Nov 16, 2017 at 03:07:54PM -0800, Nick Lewycky wrote:
>>> Sorry! Let's try an attachment then.
>>>
>>> On 16 November 2017 at 14:36, Michael Niedermayer
>>>  wrote:
 On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
> I initially discovered a signed integer overflow on this line. Since
> this value is updated in multiple threads, I use an atomic update and
> as it happens atomic addition is defined to wrap around. However,
> there's still a potential bug in that the error_count may wrap around
> and equal zero again causing problems down the line.
>
> ---
>  libavcodec/mpeg12dec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index d5bc5f21b2..b7c3b5106e 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -28,6 +28,7 @@
>  #define UNCHECKED_BITSTREAM_READER 1
>  #include 
>
> +#include "libavutil/atomic.h"
>  #include "libavutil/attributes.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/internal.h"
> @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
> >thread_context[0], NULL,
> s->slice_count, sizeof(void *));
>  for (i = 0; i < s->slice_count; i++)
> -s2->er.error_count +=
> s2->thread_context[i]->er.error_count;
> +
> avpriv_atomic_int_add_and_fetch(>er.error_count,
> s2->thread_context[i]->er.error_count);
>  }

 This patch is corrupted by newlines

 [...]

 --
 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

 Dictatorship naturally arises out of democracy, and the most aggravated
 form of tyranny and slavery out of the most extreme liberty. -- Plato

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

>>
>>>  mpeg12dec.c |3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>> eed6baa2f9ae5b6fcd227e4b7fa0e87e9ca55b64  
>>> 0001-libavcodec-mpeg12dec-Use-atomic-addition-for-value-u.patch
>>> From cd8ed0ee35853ae089df3d904846879ce4f00c4a Mon Sep 17 00:00:00 2001
>>> From: Nick Lewycky 
>>> Date: Thu, 16 Nov 2017 11:50:38 -0800
>>> Subject: [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated
>>>  in multiple threads.
>>
>> LGTM, unless theres a new API for doing this, in which case the new
>> style should be used.
> 
> Yes, he should use C11 atomics. It's been mentioned to everyone that
> submitted code using the old lavu wrappers, including you some days ago.

To expand on this, I'm aware that the entire error resilience feature
needs to be ported to C11 atomics. My point is that, much like i said to
you in that patch some days ago, it should be ported before adding new
code that will ultimately make the port harder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add tune-content option

[James Zern]

On Mon, Nov 13, 2017 at 4:01 PM, James Zern  wrote:
> Signed-off-by: James Zern 
> ---
>  doc/encoders.texi  |  2 ++
>  libavcodec/libvpxenc.c | 20 
>  2 files changed, 22 insertions(+)
>

Applied with an additional note in the commit message about the
parameter matching vpxenc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

[James Almer]

On 11/17/2017 4:16 PM, Michael Niedermayer wrote:
> On Thu, Nov 16, 2017 at 03:07:54PM -0800, Nick Lewycky wrote:
>> Sorry! Let's try an attachment then.
>>
>> On 16 November 2017 at 14:36, Michael Niedermayer
>>  wrote:
>>> On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
 I initially discovered a signed integer overflow on this line. Since
 this value is updated in multiple threads, I use an atomic update and
 as it happens atomic addition is defined to wrap around. However,
 there's still a potential bug in that the error_count may wrap around
 and equal zero again causing problems down the line.

 ---
  libavcodec/mpeg12dec.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
 index d5bc5f21b2..b7c3b5106e 100644
 --- a/libavcodec/mpeg12dec.c
 +++ b/libavcodec/mpeg12dec.c
 @@ -28,6 +28,7 @@
  #define UNCHECKED_BITSTREAM_READER 1
  #include 

 +#include "libavutil/atomic.h"
  #include "libavutil/attributes.h"
  #include "libavutil/imgutils.h"
  #include "libavutil/internal.h"
 @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
 AVFrame *picture,
 >thread_context[0], NULL,
 s->slice_count, sizeof(void *));
  for (i = 0; i < s->slice_count; i++)
 -s2->er.error_count +=
 s2->thread_context[i]->er.error_count;
 +
 avpriv_atomic_int_add_and_fetch(>er.error_count,
 s2->thread_context[i]->er.error_count);
  }
>>>
>>> This patch is corrupted by newlines
>>>
>>> [...]
>>>
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> Dictatorship naturally arises out of democracy, and the most aggravated
>>> form of tyranny and slavery out of the most extreme liberty. -- Plato
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
> 
>>  mpeg12dec.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> eed6baa2f9ae5b6fcd227e4b7fa0e87e9ca55b64  
>> 0001-libavcodec-mpeg12dec-Use-atomic-addition-for-value-u.patch
>> From cd8ed0ee35853ae089df3d904846879ce4f00c4a Mon Sep 17 00:00:00 2001
>> From: Nick Lewycky 
>> Date: Thu, 16 Nov 2017 11:50:38 -0800
>> Subject: [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated
>>  in multiple threads.
> 
> LGTM, unless theres a new API for doing this, in which case the new
> style should be used.

Yes, he should use C11 atomics. It's been mentioned to everyone that
submitted code using the old lavu wrappers, including you some days ago.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 03:07:54PM -0800, Nick Lewycky wrote:
> Sorry! Let's try an attachment then.
> 
> On 16 November 2017 at 14:36, Michael Niedermayer
>  wrote:
> > On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
> >> I initially discovered a signed integer overflow on this line. Since
> >> this value is updated in multiple threads, I use an atomic update and
> >> as it happens atomic addition is defined to wrap around. However,
> >> there's still a potential bug in that the error_count may wrap around
> >> and equal zero again causing problems down the line.
> >>
> >> ---
> >>  libavcodec/mpeg12dec.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> >> index d5bc5f21b2..b7c3b5106e 100644
> >> --- a/libavcodec/mpeg12dec.c
> >> +++ b/libavcodec/mpeg12dec.c
> >> @@ -28,6 +28,7 @@
> >>  #define UNCHECKED_BITSTREAM_READER 1
> >>  #include 
> >>
> >> +#include "libavutil/atomic.h"
> >>  #include "libavutil/attributes.h"
> >>  #include "libavutil/imgutils.h"
> >>  #include "libavutil/internal.h"
> >> @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
> >> AVFrame *picture,
> >> >thread_context[0], NULL,
> >> s->slice_count, sizeof(void *));
> >>  for (i = 0; i < s->slice_count; i++)
> >> -s2->er.error_count +=
> >> s2->thread_context[i]->er.error_count;
> >> +
> >> avpriv_atomic_int_add_and_fetch(>er.error_count,
> >> s2->thread_context[i]->er.error_count);
> >>  }
> >
> > This patch is corrupted by newlines
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Dictatorship naturally arises out of democracy, and the most aggravated
> > form of tyranny and slavery out of the most extreme liberty. -- Plato
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  mpeg12dec.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> eed6baa2f9ae5b6fcd227e4b7fa0e87e9ca55b64  
> 0001-libavcodec-mpeg12dec-Use-atomic-addition-for-value-u.patch
> From cd8ed0ee35853ae089df3d904846879ce4f00c4a Mon Sep 17 00:00:00 2001
> From: Nick Lewycky 
> Date: Thu, 16 Nov 2017 11:50:38 -0800
> Subject: [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated
>  in multiple threads.

LGTM, unless theres a new API for doing this, in which case the new
style should be used.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 10:28:49AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Nov 17, 2017 at 10:14 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > As a maintainer If a file fails with an error i want to know
> > what error it is. Why is this so hard or controversal ?
> 
> 
> Because *it doesn't happen* for real files.
> 
> But you don't want to listen.

So you know exactly which error conditions will never happen ?
And thats considering all the odd files we saw over the years,
hacked and modified encoders and hacked and modified specs and drafts
on which some encoders are based which we have seen files from.

And you expect that every time we consider adding an error message
someone should do this analysis ?

And after we have ommitted hundreads of error messages this way with
all the time that costs. the 10kb of space saved is worth more than
the hundread hours spend on this analysis ?

and none of these predictions of non occurance in real world files
will be wrong ?
In no significant number of cases will bugs be missed because they
are just vissible through one of these ommited error messages ?

The above sounds unreasonable if that is your position. But please
correct me if that is not your position. It seemed to follow from
a selective ommision of error messages


> You still -after all these years- think that
> if you believe something, then it must be true. How can this project be
> collaborative if any time we disagree, you just dig in your heels in the
> sand and start this same old argument where "you are maintainer" and
> therefore whatever you believe is true, and whatever you say is final?

Something in your reasoning is a bit unreasonable here.
I do not remember that you ever backed down from an argument.  And
you say i am diging my heels in ?
and that after i agreed to remove the messages yesterday so this
can move forward and this bug can be fixed.

About "collaborative" i must repeat what i said multiple times now
"Iam happy to follow what the community prefers." How can this be
anti-collaborative !?!?!?!

We can do what i suggested many times already, poll the community and
follow the communities preferrance on error messages.

Thanks

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Aman Gupta]

On Wed, Nov 15, 2017 at 6:21 PM, Aman Gupta  wrote:

>
>
> On Wed, Nov 15, 2017 at 2:35 AM, Jeyapal, Karthick 
> wrote:
>
>> >Hmm, I guess if we want this to propagate down we need to add the option
>> to the tls protocol as well, then pass it down when it instantiates the tcp
>> protocol. Then add the same option to hls/dash, and again propagate it
>> >down to tls or tcp.
>>
>> >
>>
>> >This is turning into a much bigger change than I anticipated, and I
>> don't really care enough about it to continue. If someone else wants to
>> take over this patchset, they are more than welcome to it.
>>
>> >
>>
>> >Aman
>>
>>
>>
>> Well, I would suggest you could push the first tcp patch and leave the
>> http/tls patch for somebody else to take it up later.
>>
>
> That's fair.
>
> I've tested compiling the change on windows (w/ mingw), freebsd, linux and
> macOS. I hope there are no other obscure supported platforms where
> TCP_NODELAY might not be defined?
>

I've pushed the change to add the tcp_nodelay option to the tcp protocol.
The second patch to use it from http/tls has been abandoned.

Aman


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

Re: [FFmpeg-devel] Feature request

[Paul B Mahol]

On 11/17/17, Ben Hutchinson  wrote:
> I would like to be able to deinterlace a video by converting full-height
> frames into half-height fields (where each frame of the output represents
> one field of the input) at double the frame rate. The way this would work
> is it would take the top field (or bottom field) first and export it as the
> first frame in the output file, and then take the next field of the input
> and output it as the second frame in the output file. Then it moves on to
> the first field of the second input frame, and outputs this as the 3rd
> frame of the output. And this continues until the output file has twice as
> many frames as the input, at half the height of the input, and runs at
> twice the frame rate as the input.
> For example:
> Input Frame1 Field1 > Output Frame1
> Input Frame1 Field2 > Output Frame2
> Input Frame2 Field1 > Output Frame3
> Input Frame2 Field2 > Output Frame4
>
>
> I would also like to be able to do the reverse of this, take a video file
> who's frames represent fields, and then interlace them so that they
> actually are fields within frames in the output video, and at the same time
> cut the frame rate in half.
> For example:
> Input Frame1 > Output Frame1 Field1
> Input Frame2 > Output Frame1 Field2
> Input Frame3 > Output Frame2 Field1
> Input Frame4 > Output Frame2 Field2

Already done via separatefields and weave filters.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Allow "-to" on input files as well

[vi0oss]

From: Vitaly _Vi Shukela 

---

Notes:
Second version.

Please CC vi0...@gmail.com when replying.

Note that added code is a duplicate of the respective output option 
processing code.
I'm not sure if it is worth factoring out.

 doc/ffmpeg.texi  |  4 ++--
 fftools/ffmpeg_opt.c | 17 -
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7db80ebf6a..9a90d7327a 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -289,8 +289,8 @@ see @ref{time duration syntax,,the Time duration section in 
the ffmpeg-utils(1)
 
 -to and -t are mutually exclusive and -t has priority.
 
-@item -to @var{position} (@emph{output})
-Stop writing the output at @var{position}.
+@item -to @var{position} (@emph{input/output})
+Stop writing the output or reading the input at @var{position}.
 @var{position} must be a time duration specification,
 see @ref{time duration syntax,,the Time duration section in the 
ffmpeg-utils(1) manual,ffmpeg-utils}.
 
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ca6f10d5ca..e453cb34c5 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -972,6 +972,21 @@ static int open_input_file(OptionsContext *o, const char 
*filename)
 char *data_codec_name = NULL;
 int scan_all_pmts_set = 0;
 
+if (o->stop_time != INT64_MAX && o->recording_time != INT64_MAX) {
+o->stop_time = INT64_MAX;
+av_log(NULL, AV_LOG_WARNING, "-t and -to cannot be used together; 
using -t.\n");
+}
+
+if (o->stop_time != INT64_MAX && o->recording_time == INT64_MAX) {
+int64_t start_time = o->start_time == AV_NOPTS_VALUE ? 0 : 
o->start_time;
+if (o->stop_time <= start_time) {
+av_log(NULL, AV_LOG_ERROR, "-to value smaller than -ss; 
aborting.\n");
+exit_program(1);
+} else {
+o->recording_time = o->stop_time - start_time;
+}
+}
+
 if (o->format) {
 if (!(file_iformat = av_find_input_format(o->format))) {
 av_log(NULL, AV_LOG_FATAL, "Unknown input format: '%s'\n", 
o->format);
@@ -3403,7 +3418,7 @@ const OptionDef options[] = {
 OPT_INPUT | OPT_OUTPUT,  { .off = 
OFFSET(recording_time) },
 "record or transcode \"duration\" seconds of audio/video",
 "duration" },
-{ "to", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_OUTPUT,  { .off 
= OFFSET(stop_time) },
+{ "to", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_INPUT | 
OPT_OUTPUT,  { .off = OFFSET(stop_time) },
 "record or transcode stop time", "time_stop" },
 { "fs", HAS_ARG | OPT_INT64 | OPT_OFFSET | OPT_OUTPUT, { .off 
= OFFSET(limit_filesize) },
 "set the limit file size in bytes", "limit_size" },
-- 
2.11.0

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

[FFmpeg-devel] Feature request

[Ben Hutchinson]

I would like to be able to deinterlace a video by converting full-height
frames into half-height fields (where each frame of the output represents
one field of the input) at double the frame rate. The way this would work
is it would take the top field (or bottom field) first and export it as the
first frame in the output file, and then take the next field of the input
and output it as the second frame in the output file. Then it moves on to
the first field of the second input frame, and outputs this as the 3rd
frame of the output. And this continues until the output file has twice as
many frames as the input, at half the height of the input, and runs at
twice the frame rate as the input.
For example:
Input Frame1 Field1 > Output Frame1
Input Frame1 Field2 > Output Frame2
Input Frame2 Field1 > Output Frame3
Input Frame2 Field2 > Output Frame4


I would also like to be able to do the reverse of this, take a video file
who's frames represent fields, and then interlace them so that they
actually are fields within frames in the output video, and at the same time
cut the frame rate in half.
For example:
Input Frame1 > Output Frame1 Field1
Input Frame2 > Output Frame1 Field2
Input Frame3 > Output Frame2 Field1
Input Frame4 > Output Frame2 Field2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Nicolas George]

Le septidi 27 brumaire, an CCXXVI, Carl Eugen Hoyos a écrit :
> Hi!
> 
> I believe attached patch is necessary to fix ticket #6839 and several
> older bug reports.
> 
> Missing version bump and APIchanges entry.
> 
> Please review, Carl Eugen

As is, no, it is just code connected with nothing. With a full patch
maybe.

But if I understand correctly what this field does, then to get it
working you would have to go over all filters that change the contents
of the signal to see how many significant bits they produce.

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 1/2] avcodec/snowdec: Check intra block dc differences.

[Nicolas George]

Le septidi 27 brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> Because *it doesn't happen* for real files.

Then why do you want it gone?

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] lavr: deprecate the entire library

[Rostislav Pehlivanov]

On 17 November 2017 at 17:53, James Almer  wrote:

> On 11/17/2017 12:58 PM, Rostislav Pehlivanov wrote:
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  doc/APIchanges| 5 +
> >  libavresample/utils.c | 3 +++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index d336f6ce22..22c7b5a0d0 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,11 @@ libavutil: 2017-10-21
> >
> >  API changes, most recent first:
> >
> > +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
> > +  Deprecate the entire library. It was unmaintained and redundant> +
> as libswresample did everything it did better, faster, with more
> > +  control and with a better, slightly higher level API.
>
> This is only partly true. For example, last time i checked swr is
> missing some multichannel simd optimizations available on lavr.
>

Which ones?



>
> > +
> >  2017-xx-xx - xxx - lavc 58.3.100 - avcodec.h
> >Add avcodec_get_hw_frames_parameters().
> >
> > diff --git a/libavresample/utils.c b/libavresample/utils.c
> > index b4fb906556..3e629fe901 100644
> > --- a/libavresample/utils.c
> > +++ b/libavresample/utils.c
> > @@ -37,6 +37,9 @@ int avresample_open(AVAudioResampleContext *avr)
> >  {
> >  int ret;
> >
> > +av_log(avr, AV_LOG_WARNING, "This library is being deprecated in
> favor of libswresample, "
> > +   "please migrate your program.");
> > +
> >  if (avresample_is_open(avr)) {
> >  av_log(avr, AV_LOG_ERROR, "The resampling context is already
> open.\n");
> >  return AVERROR(EINVAL);
> >
>
> I don't like this patch much. It gives the same bad vibes as the
> "deprecated" ffmpeg package in debian from five years ago. Lets try to
> not go there again.
>

Ignore politics, we're trying to remove something we don't maintain and
never have.



>
> In any case, lavr is disabled by default, ffmpeg requires swr, opusdec
> requires swr, etc. So the only people using lavr are those that
> purposely want their codebase to work with both projects even if in a
>

Yeah, no. No one packages libav and no one's really trying to do that
anymore. The APIs have diverged (w.r.t. filtering).



> handicapped way, and are thus unlikely to consider/bother to migrate to
> swr.
>

This provides the motivation to move to something better that _we_ actually
maintain and has numerous advantages.


We can't let this sit in our repo as it bitrots when there's a better
solution.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[Rostislav Pehlivanov]

On 17 November 2017 at 17:51, Carl Eugen Hoyos  wrote:

> 2017-11-17 16:58 GMT+01:00 Rostislav Pehlivanov :
>
> > +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
> > +  Deprecate the entire library. It was unmaintained and redundant
> > +  as libswresample did everything it did better, faster, with more
> > +  control and with a better, slightly higher level API.
>
> Shouldn't you remove the resample filter first?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

No, I'll send a separate patch to deprecate that one (if this one's okayed)
as well so eventually they would be removed at the same time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

[Derek Buitenhuis]

On 11/17/2017 5:37 PM, Michael Niedermayer wrote:
> hmm, i cant really remember this clearly but from looking at the code
> it looks like this is the logic:
> b->next[k] < 64
> b->next[k] >= mb_area_start[a + 1] implies mb_area_start[a + 1] < 64
> which implies a < 3
> and a2 < 4 on the first iteration so the first is still in the array
> subsequently, b->next[k] >= mb_area_start[a2 + 1] exists before the end
> as b->next[k] < 64 and the last entry being 64

Seems to be the case, though it is incredibly non-obvious.

Is there a better way to have that assert run than to check we'd have
already run the OOB access?

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

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[James Almer]

On 11/17/2017 12:58 PM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  doc/APIchanges| 5 +
>  libavresample/utils.c | 3 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index d336f6ce22..22c7b5a0d0 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
> +  Deprecate the entire library. It was unmaintained and redundant> +  as 
> libswresample did everything it did better, faster, with more
> +  control and with a better, slightly higher level API.

This is only partly true. For example, last time i checked swr is
missing some multichannel simd optimizations available on lavr.

> +
>  2017-xx-xx - xxx - lavc 58.3.100 - avcodec.h
>Add avcodec_get_hw_frames_parameters().
>  
> diff --git a/libavresample/utils.c b/libavresample/utils.c
> index b4fb906556..3e629fe901 100644
> --- a/libavresample/utils.c
> +++ b/libavresample/utils.c
> @@ -37,6 +37,9 @@ int avresample_open(AVAudioResampleContext *avr)
>  {
>  int ret;
>  
> +av_log(avr, AV_LOG_WARNING, "This library is being deprecated in favor 
> of libswresample, "
> +   "please migrate your program.");
> +
>  if (avresample_is_open(avr)) {
>  av_log(avr, AV_LOG_ERROR, "The resampling context is already 
> open.\n");
>  return AVERROR(EINVAL);
> 

I don't like this patch much. It gives the same bad vibes as the
"deprecated" ffmpeg package in debian from five years ago. Lets try to
not go there again.

In any case, lavr is disabled by default, ffmpeg requires swr, opusdec
requires swr, etc. So the only people using lavr are those that
purposely want their codebase to work with both projects even if in a
handicapped way, and are thus unlikely to consider/bother to migrate to swr.
People that only care about ffmpeg already use swr because of the above
reasons.

If others however support/endorse this patch or a similar one then I'll
not block it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[Carl Eugen Hoyos]

2017-11-17 16:58 GMT+01:00 Rostislav Pehlivanov :

> +2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
> +  Deprecate the entire library. It was unmaintained and redundant
> +  as libswresample did everything it did better, faster, with more
> +  control and with a better, slightly higher level API.

Shouldn't you remove the resample filter first?

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/snowdec: Check for remaining bitstream in decode_blocks()

[Michael Niedermayer]

On Wed, Nov 15, 2017 at 09:17:16PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 3142/clusterfuzz-testcase-5007853163118592
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/snowdec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply


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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 06:27:38PM -0500, Dave Rice wrote:
> 
> > On Nov 16, 2017, at 6:08 PM, Carl Eugen Hoyos  wrote:
> > 
> > 2017-11-16 17:54 GMT+01:00 Dave Rice :
> > 
> >> +if (track->mode == MODE_MOV && track->par->codec_id == 
> >> AV_CODEC_ID_V410)
> >> +avio_wb16(pb, 0x18);
> >> +else if (track->mode == MODE_MOV && track->par->codec_id == 
> >> AV_CODEC_ID_V210)
> >> +avio_wb16(pb, 0x18);
> > 
> > It appears you can merge the two cases.
> 
> The patch is updated with merged cases below.
> 
> > Or maybe patch bits_per_coded_sample in the encoder…
> 
> 
> With Apple’s TN2162 there doesn’t appear to be a reliable relationship 
> between the bits_per_coded_sample and what the ImageDescription depth value 
> should be for the uncompressed yuv formats. TN2162 simply lists what the 
> depth value should be and this patch corrects the few instances, where 
> ffmpeg’s behavior doesn’t correlate to what TN2162 defines.
> 
> 
> From cfa5b2cd959154f2896a9557d9ca2ed2d2d3834e Mon Sep 17 00:00:00 2001
> From: Dave Rice 
> Date: Thu, 16 Nov 2017 11:53:32 -0500
> Subject: [PATCH 2/2] avformat/movenc: correct ImageDescription depth for v210
>  v410

please add a fate test
LGTM if its tested

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

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


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

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 04:20:55PM +, Derek Buitenhuis wrote:
> mb_area_start has 5 entries, and 'a' is iterated through from 0 to 3.
> 'a2' is set to 'a + 1', and mb_area_start[a2 + 1] is accessed, so if
> a is 3, then we try to access mb_area_start[5].
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> I'm not 100% sure if this fix is /correct/, so hopefully someone
> knows the DV code...
> ---
>  libavcodec/dvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
> index ce2fc75daa..b79cbebb04 100644
> --- a/libavcodec/dvenc.c
> +++ b/libavcodec/dvenc.c
> @@ -383,7 +383,7 @@ static inline void dv_guess_qnos(EncBlockInfo *blks, int 
> *qnos)
>  prev= k;
>  } else {
>  if (b->next[k] >= mb_area_start[a + 1] && 
> b->next[k] < 64) {
> -for (a2 = a + 1; b->next[k] >= 
> mb_area_start[a2 + 1]; a2++)
> +for (a2 = a + 1; a2 < 4 && b->next[k] >= 
> mb_area_start[a2 + 1]; a2++)
>  b->prev[a2] = prev;
>  av_assert2(a2 < 4);

hmm, i cant really remember this clearly but from looking at the code
it looks like this is the logic:
b->next[k] < 64
b->next[k] >= mb_area_start[a + 1] implies mb_area_start[a + 1] < 64
which implies a < 3
and a2 < 4 on the first iteration so the first is still in the array
subsequently, b->next[k] >= mb_area_start[a2 + 1] exists before the end
as b->next[k] < 64 and the last entry being 64


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH] movenc: write clap tag

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 12:14:30PM -0500, Dave Rice wrote:
> 
> > On Nov 16, 2017, at 11:30 AM, Dave Rice  wrote:
> > 
> >> On Jul 9, 2017, at 7:26 PM, Dave Rice  wrote:
> >> 
> >>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis  
> >>> wrote:
> >>> 
> >>> On 7/7/2017 10:13 PM, James Almer wrote:
>  Isn't this necessary only for files with raw video? As is, this box
>  would be written on any mov file with a video stream.
> >>> 
> >>> This was addressed a previous email:
> >>> 
> >>>  http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html
> >>> 
> >>> I guess the spec is up for interpretation.
> >> 
> >> The quicktime spec says "This is a mandatory extension for all 
> >> uncompressed Y´CbCr data formats”. It doesn’t clarify if the clap atom is 
> >> recommended or not in mov files that are not “uncompressed Y´CbCr”, though 
> >> it would make sense if the video container needs to store cropping data. I 
> >> think constraining the change for only  “uncompressed Y´CbCr” would be 
> >> more cautious though. I’ll revise my patch to include the condition and 
> >> resubmit.
> >> 
> >> If the patch only impacts “uncompressed Y´CbCr” would any fate updates be 
> >> needed?
> >> Dave Rice
> > 
> > Here’s an update to only write the clap atom for the specific uncompressed 
> > encodings listed in TN2162.
> > 
> > From 37457c1ee135f39452b91b047af4adf1ec43464b Mon Sep 17 00:00:00 2001
> > From: Dave Rice 
> > Date: Thu, 16 Nov 2017 11:29:06 -0500
> > Subject: [PATCH] avformat/movenc: write clap atom for uncompressed yuv in 
> > mov
> 
> Sorry, this patch should supersede the prior email's patch. I realized that 
> Apple requires new uncompressed ycbcr files to use version 2 in the Image 
> Description, so I reused the uncompressed_ycbcr variable to add that in as 
> well.
> 
> From 3ea99e7d22f67b8a556152acbcbc8bf2eeec8a39 Mon Sep 17 00:00:00 2001
> From: Dave Rice 
> Date: Thu, 16 Nov 2017 11:29:06 -0500
> Subject: [PATCH 1/2] avformat/movenc: write clap atom for uncompressed yuv in
>  mov
> 
> fixes 6145
> ---
>  libavformat/movenc.c | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)

please add a fate test

and if this is tested with some official player and works then LGTM

thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH] Download dash content with byte range info

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 08:33:35PM +, Colin NG wrote:
> ---
>  libavformat/dashdec.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 0e3afd2..33255f2 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
>  return type;
>  }
>  
> +static struct fragment * get_Fragment(char *range) {
> +struct fragment * seg = av_mallocz(sizeof(struct fragment));
> +
> +if (!seg)
> +return NULL;
> +
> +seg->size = -1;
> +if (range)  {
> +char *str_end_offset;
> +char *str_offset = av_strtok(range, "-", _end_offset);
> +seg->url_offset = strtoll(str_offset, NULL, 10);
> +seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset+1;
> +}
> +return seg;
> +}
> +
>  static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
> representation *rep,
>   xmlNodePtr fragmenturl_node,
>   xmlNodePtr *baseurl_nodes,
> @@ -530,11 +546,13 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  {
>  char *initialization_val = NULL;
>  char *media_val = NULL;
> +char *range_val = NULL;
>  
>  if (!av_strcasecmp(fragmenturl_node->name, (const char 
> *)"Initialization")) {
>  initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
> -if (initialization_val) {
> -rep->init_section = av_mallocz(sizeof(struct fragment));
> +range_val = xmlGetProp(fragmenturl_node, "range");
> +if (initialization_val || range_val) {
> +rep->init_section = get_Fragment(range_val);
>  if (!rep->init_section) {
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
> @@ -548,13 +566,14 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
>  }
> -rep->init_section->size = -1;
>  xmlFree(initialization_val);
> +xmlFree(range_val);
>  }
>  } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
> *)"SegmentURL")) {
>  media_val = xmlGetProp(fragmenturl_node, "media");
> -if (media_val) {
> -struct fragment *seg = av_mallocz(sizeof(struct fragment));
> +range_val = xmlGetProp(fragmenturl_node, "mediaRange");
> +if (media_val || range_val) {
> +struct fragment *seg =  get_Fragment(range_val);
>  if (!seg) {
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
> @@ -568,15 +587,14 @@ static int 
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
>  }
> -seg->size = -1;
>  dynarray_add(>fragments, >n_fragments, seg);
>  xmlFree(media_val);
> +xmlFree(range_val);
>  }

I think this is leaking range_val in some error paths


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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] fate/hapdec : add test for hap alpha only

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 11:45:41PM +0100, Martin Vignali wrote:
> >
> > New patch in attach (use gray8 pix_fmt)
> > Need to be apply after patch in discussion
> > avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0
> >
> > Martin
> >
> 
> With the attachment

>  fate/video.mak  |6 ++
>  ref/fate/hap-alpha-only-nosnappy-128x72 |6 ++
>  ref/fate/hap-alpha-only-snappy-127x71   |6 ++
>  3 files changed, 18 insertions(+)
> 8bef58025d01657be6807ee0517400a8b7658a36  
> 0007-fate-hapAlphaOnly-add-test-for-hap-alpha-only-decodi.patch
> From e36f20b8d9d0361047da1834e32b354937bf54d5 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Thu, 16 Nov 2017 23:16:33 +0100
> Subject: [PATCH 7/7] fate/hapAlphaOnly : add test for hap alpha only decoding

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

[Derek Buitenhuis]

On 11/17/2017 4:42 PM, Martin Vignali wrote:
> doesn't know the dvenc code,
> but you seems to test the assert of the next line
> 
> Maybe move the assert (a2 < 4); before the for loop, if it's a theorical
> case,
> or remove it if this case can really happen.

I don't see anything that would prevent it from happening, but the code
is also about as clear as mud.

In general, I think I prefer a real check to an assert, unless someone
can explain why it *wouldn't* happen.

After git blame-ing my way through roughly 166393765431 "K formatting"
and "refactor" commits, the original code comes from the ancient commit of 
d2d230a7569154306a1625ca37dbfa4c36627ec6 which provides no info whatsoever
on why it is correct at all.

CCing Michael, as he authored that commit - maybe he can provide insight.

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

Re: [FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

[Martin Vignali]

2017-11-17 17:20 GMT+01:00 Derek Buitenhuis :

> mb_area_start has 5 entries, and 'a' is iterated through from 0 to 3.
> 'a2' is set to 'a + 1', and mb_area_start[a2 + 1] is accessed, so if
> a is 3, then we try to access mb_area_start[5].
>
> Signed-off-by: Derek Buitenhuis 
> ---
> I'm not 100% sure if this fix is /correct/, so hopefully someone
> knows the DV code...
> ---
>  libavcodec/dvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
> index ce2fc75daa..b79cbebb04 100644
> --- a/libavcodec/dvenc.c
> +++ b/libavcodec/dvenc.c
> @@ -383,7 +383,7 @@ static inline void dv_guess_qnos(EncBlockInfo *blks,
> int *qnos)
>  prev= k;
>  } else {
>  if (b->next[k] >= mb_area_start[a + 1] &&
> b->next[k] < 64) {
> -for (a2 = a + 1; b->next[k] >=
> mb_area_start[a2 + 1]; a2++)
> +for (a2 = a + 1; a2 < 4 && b->next[k]
> >= mb_area_start[a2 + 1]; a2++)
>  b->prev[a2] = prev;
>  av_assert2(a2 < 4);
>  av_assert2(b->mb[b->next[k]]);
> --
>
>
Hello,

doesn't know the dvenc code,
but you seems to test the assert of the next line

Maybe move the assert (a2 < 4); before the for loop, if it's a theorical
case,
or remove it if this case can really happen.

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

[FFmpeg-devel] [PATCH] dvenc: Prevent out-of-bounds read

[Derek Buitenhuis]

mb_area_start has 5 entries, and 'a' is iterated through from 0 to 3.
'a2' is set to 'a + 1', and mb_area_start[a2 + 1] is accessed, so if
a is 3, then we try to access mb_area_start[5].

Signed-off-by: Derek Buitenhuis 
---
I'm not 100% sure if this fix is /correct/, so hopefully someone
knows the DV code...
---
 libavcodec/dvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..b79cbebb04 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -383,7 +383,7 @@ static inline void dv_guess_qnos(EncBlockInfo *blks, int 
*qnos)
 prev= k;
 } else {
 if (b->next[k] >= mb_area_start[a + 1] && 
b->next[k] < 64) {
-for (a2 = a + 1; b->next[k] >= 
mb_area_start[a2 + 1]; a2++)
+for (a2 = a + 1; a2 < 4 && b->next[k] >= 
mb_area_start[a2 + 1]; a2++)
 b->prev[a2] = prev;
 av_assert2(a2 < 4);
 av_assert2(b->mb[b->next[k]]);
-- 
2.15.0

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

[FFmpeg-devel] [PATCH] lavf/mov: don't read outside frag_index bounds

[John Stebbins]

Potentially fixes:
https://bugs.chromium.org/p/chromium/issues/detail?id=786269#c1

In theory, the crash can be triggered by an invalid stream that has
either tfdt or trun outside of the moof
---
 libavformat/mov.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d49d820d2b..0fbc7f54a2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1188,6 +1188,10 @@ static void set_frag_stream(MOVFragmentIndex 
*frag_index, int id)
 static MOVFragmentStreamInfo * get_current_frag_stream_info(
 MOVFragmentIndex *frag_index)
 {
+if (frag_index->current < 0 ||
+frag_index->current >= frag_index->nb_items)
+return NULL;
+
 MOVFragmentIndexItem * item = _index->item[frag_index->current];
 if (item->current >= 0 && item->current < item->nb_stream_info)
 return >stream_info[item->current];
-- 
2.13.6

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

[FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 doc/APIchanges| 5 +
 libavresample/utils.c | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index d336f6ce22..22c7b5a0d0 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
+  Deprecate the entire library. It was unmaintained and redundant
+  as libswresample did everything it did better, faster, with more
+  control and with a better, slightly higher level API.
+
 2017-xx-xx - xxx - lavc 58.3.100 - avcodec.h
   Add avcodec_get_hw_frames_parameters().
 
diff --git a/libavresample/utils.c b/libavresample/utils.c
index b4fb906556..3e629fe901 100644
--- a/libavresample/utils.c
+++ b/libavresample/utils.c
@@ -37,6 +37,9 @@ int avresample_open(AVAudioResampleContext *avr)
 {
 int ret;
 
+av_log(avr, AV_LOG_WARNING, "This library is being deprecated in favor of 
libswresample, "
+   "please migrate your program.");
+
 if (avresample_is_open(avr)) {
 av_log(avr, AV_LOG_ERROR, "The resampling context is already open.\n");
 return AVERROR(EINVAL);
-- 
2.15.0.291.g0d8980c5de

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

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Hendrik Leppkes]

On Fri, Nov 17, 2017 at 1:26 PM, Carl Eugen Hoyos  wrote:
> 2017-11-17 12:43 GMT+01:00 Paul B Mahol :
>> On 11/17/17, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> I believe attached patch is necessary to fix ticket #6839 and several
>>> older bug reports.
>>
>> No it is not neccessary. Because nothing uses it.
>
> libavcodec uses it in several codecs and others may benefit from it.
> It is also used by ffmpeg and shown by ffprobe.
>

Where is this field realistically used for video? I only know if its
use for audio.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

[Ronald S. Bultje]

Hi,

On Fri, Nov 17, 2017 at 10:14 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> As a maintainer If a file fails with an error i want to know
> what error it is. Why is this so hard or controversal ?


Because *it doesn't happen* for real files.

But you don't want to listen. You still -after all these years- think that
if you believe something, then it must be true. How can this project be
collaborative if any time we disagree, you just dig in your heels in the
sand and start this same old argument where "you are maintainer" and
therefore whatever you believe is true, and whatever you say is final?

:-(

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 11:13:27PM -0300, James Almer wrote:
> On 11/16/2017 10:43 PM, Michael Niedermayer wrote:
> > On Thu, Nov 16, 2017 at 07:47:55PM -0500, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Thu, Nov 16, 2017 at 4:41 PM, Michael Niedermayer 
> >>  >>> wrote:
> >>
> >>> On Thu, Nov 16, 2017 at 01:21:19PM -0500, Ronald S. Bultje wrote:
>  Hi,
> 
>  On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
>  mich...@niedermayer.cc> wrote:
> 
> > On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos <
> >>> ceffm...@gmail.com>
> >> wrote:
> >>
> >>> 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> >>>
>  So, commit it without the error message? I really don't see the
> > issue.
> >>>
> >>> As explained, the issue is that without an error message, it
> >>> is impossible to parse any related bug report.
> >>
> >>
> >> We've been OK with that situation so far. Since it only happens for
> > fuzzed
> >> files, it's OK to continue going like that.
> >
> > Thats not the case, the snow spec contains no limit in the place where
> > we need to check. Its a natural and expected limit so likely all files
> > will be within that but a file outside would still be arguably valid.
> >
> > So a valid file could potentially be outside this range and the
> > maintainer (that being me) need to know about this.
> >
> > Please dont see every change that originated from a fuzzer generated
> > report as only related to fuzzed files.
> 
> 
>  We are re-hashing old arguments here. I'm not really interested in that.
> >>>
> 
>  My review comment is and remains: please remove the log msg. Otherwise,
> >>> the
>  patch is perfectly fine.
> >>>
> >>> Thank you for your review comment.
> >>>
> >>> please awnser my question, if this is just a suggestion or a
> >>> veto, so we can move forward. Its not clear from your wording to me
> >>> if you belive you have authority over other maintainers or not.
> >>
> >>
> >> I'm sorry, what? Authority? Are you kidding me? Amend the patch, stop being
> >> difficult. This whole discussion is ridiculous. I thought you were on a
> >> deadline for a remote root code execution exploit or something?
> > 
> > The patch should be commited theres no question about this.
> > Why should i amend it and remove the error message which help me to
> > maintain the code ?
> > 
> > Do you realize how ridiculous your request is ?
> > This is code i wrote, code i maintain, you dont work on this code
> > or have anything to do with it. And these error messages help me
> > maintain the code.
> > 
> > I think you should relax a bit and jump over your shadow and let me
> > maintain my code instead of threads like this.
> > 
> > ill remove the messages so this gets resolved but its harder to maintain
> > this way so this means fewer usefull contributions from me and lower
> > code quality.
> > I dont think thats the ideal outcome ...
> > 
> > Thanks
> 
> Use ff_dlog() for the log message. It'll still be enabled on debug
> builds but not on release builds. Ronald said he's ok with it for this
> case on IRC.
> 
> Unless this was suggested before and the idea discarded/rejected for
> some reason...

ff_dlog() is not enabled in user builds so it wont result in an
error message in a bug report.
Its also  not enabled when you use --enable-debug so very few
developers would see it either.

That is in effect ff_dlog() is the same as removing the log message

I also do not know if the build would be generally useable with all
ff_dlog() enabled or too noisy or too slow.

error message have a low volume, they are only shown when an
error occurs.
debug messages and ff_dlog() is high volume there alot
of stuff displayed for valid files.

As a maintainer If a file fails with an error i want to know
what error it is. Why is this so hard or controversal ?

Thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, November 17, 2017 6:06 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning
> 
> 2017-11-17 6:52 GMT+01:00 Li, Zhong :
> 
> >> > 2017-11-15 10:04 GMT+01:00 Zhong Li :
> >> > > fix the compiling warning of "ignoring return value"
> >> >
> >> > > -ff_formats_ref(in_fmts, >inputs[0]->out_formats);
> >> > > -ff_formats_ref(out_fmts, >outputs[0]->in_formats);
> >> > > +if ((ret = ff_formats_ref(in_fmts,
> >> > > + >inputs[0]->out_formats))
> >> > > < 0)
> >> > > +return ret;
> >> > > +if ((ret = ff_formats_ref(out_fmts,
> >> > > + >outputs[0]->in_formats)) <
> >> > 0)
> >> >
> >> > Two additional lines are cheap.
> >>
> >> Just don't like any compiling warnings which may have potential
> >> issues just like this one.
> >> Personally speaking, I prefer to clear most of FFmpeg compiling warnings.
> >
> > Sorry, I may misunderstood due to miss some history discussion, here
> > you mean should be coding style making code clearer, right? Just like this:
> > "ret = ff_formats_ref();
> >  if (ret < 0) return ret;"
> 
> Yes, this is more readable.
> 
> Thank you, Carl Eugen

Got it, thanks. Patches will be updated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Carl Eugen Hoyos]

2017-11-17 13:35 GMT+01:00 Paul B Mahol :
> On 11/17/17, Carl Eugen Hoyos  wrote:
>> 2017-11-17 12:43 GMT+01:00 Paul B Mahol :
>>> On 11/17/17, Carl Eugen Hoyos  wrote:

 I believe attached patch is necessary to fix ticket #6839 and
 several older bug reports.
>>>
>>> No it is not neccessary. Because nothing uses it.
>>
>> libavcodec uses it in several codecs and others may benefit from it.
>> It is also used by ffmpeg and shown by ffprobe.
>
> But one you just added is not used

That is because I wanted to know if the addition of the field is
acceptable before patching the various functions that will use it.
Do you find that this is unreasonable?

But I realize now that the struct I had been searching for
is probably AVFilterLink in avfilter.h.

Sorry for the noise, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Paul B Mahol]

On 11/17/17, Carl Eugen Hoyos  wrote:
> 2017-11-17 12:43 GMT+01:00 Paul B Mahol :
>> On 11/17/17, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> I believe attached patch is necessary to fix ticket #6839 and several
>>> older bug reports.
>>
>> No it is not neccessary. Because nothing uses it.
>
> libavcodec uses it in several codecs and others may benefit from it.
> It is also used by ffmpeg and shown by ffprobe.

But one you just added is not used
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Carl Eugen Hoyos]

2017-11-17 12:43 GMT+01:00 Paul B Mahol :
> On 11/17/17, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> I believe attached patch is necessary to fix ticket #6839 and several
>> older bug reports.
>
> No it is not neccessary. Because nothing uses it.

libavcodec uses it in several codecs and others may benefit from it.
It is also used by ffmpeg and shown by ffprobe.

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

Re: [FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Paul B Mahol]

On 11/17/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> I believe attached patch is necessary to fix ticket #6839 and several
> older bug reports.

No it is not neccessary. Because nothing uses it.

>
> Missing version bump and APIchanges entry.
>
> Please review, Carl Eugen
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavfi/buffersrc: Add AVBufferSrcParameters->bits_per_raw_sample parameter.

[Carl Eugen Hoyos]

Hi!

I believe attached patch is necessary to fix ticket #6839 and several
older bug reports.

Missing version bump and APIchanges entry.

Please review, Carl Eugen
From 3c5966f992c4bf5e64cc1a4196eb90f804b65bf6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 17 Nov 2017 12:06:24 +0100
Subject: [PATCH] lavfi/buffersrc: Add
 AVBufferSrcParameters->bits_per_raw_sample parameter.

Allows to choose the correct destination pix_fmt for source pix_fmt
with bits_per_raw_sample < AVComponentDescriptor->depth.
---
 libavfilter/buffersrc.h |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
index 0652113..c9cb1a8 100644
--- a/libavfilter/buffersrc.h
+++ b/libavfilter/buffersrc.h
@@ -114,6 +114,13 @@ typedef struct AVBufferSrcParameters {
  * Audio only, the audio channel layout
  */
 uint64_t channel_layout;
+
+/**
+ * Video only, the actual number of used bits of the AVPixelFormat,
+ * corresponds to bits_per_raw_sample.
+ * 0 means unknown, assume max number of bits for the AVPixelFormat.
+ */
+int bits_per_raw_sample;
 } AVBufferSrcParameters;
 
 /**
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Nicolas George]

Le sextidi 26 brumaire, an CCXXVI, Jeyapal, Karthick a écrit :
> I have done the change as suggested. Please find the new patch attached.

Sorry, but I still have doubts about it.

To begin with, -1 is not an acceptable error code.

But what bothers me most is that on the two uses, one has an assert, the
other has an error return, the inconsistency looks suspicious.

I think, at least, it should include a comment at both places to
indicate why the test is done like that.

> I need to send ‘0’ byte http packet to indicate close.
> But ffurl_write doesn’t call http_write for a 0 byte packet.
> Hence, I am calling prot->url_write directly. 

Let me see if I understand correctly: are you saying that it is not
possible to perform multiple requests using only public APIs? I find it
suspicious, since multiple_requests is a public option. If that is true,
then it needs fixing.

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] Fix for ticket 6658 (Dash demuxer segfault)

[Carl Eugen Hoyos]

2017-11-17 1:55 GMT+01:00 Colin NG :
> Excluded the fix for byte range issue and update some coding style issues.

> +if (pb) av_freep(pb);

The if() should be unnecessary.

Please avoid adding empty lines in unrelated parts of the file
and while there, try to fix "if (condition)  {" to "if (condition) {"
(one space).

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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

[Carl Eugen Hoyos]

2017-11-17 6:52 GMT+01:00 Li, Zhong :

>> > 2017-11-15 10:04 GMT+01:00 Zhong Li :
>> > > fix the compiling warning of "ignoring return value"
>> >
>> > > -ff_formats_ref(in_fmts, >inputs[0]->out_formats);
>> > > -ff_formats_ref(out_fmts, >outputs[0]->in_formats);
>> > > +if ((ret = ff_formats_ref(in_fmts, >inputs[0]->out_formats))
>> > > < 0)
>> > > +return ret;
>> > > +if ((ret = ff_formats_ref(out_fmts,
>> > > + >outputs[0]->in_formats)) <
>> > 0)
>> >
>> > Two additional lines are cheap.
>>
>> Just don't like any compiling warnings which may have potential issues
>> just like this one.
>> Personally speaking, I prefer to clear most of FFmpeg compiling warnings.
>
> Sorry, I may misunderstood due to miss some history discussion, here you
> mean should be coding style making code clearer, right? Just like this:
> "ret = ff_formats_ref();
>  if (ret < 0) return ret;"

Yes, this is more readable.

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

[FFmpeg-devel] [PATCH] Ignore libavcodec/tests/mpeg12framerate, a test program

[Jim DeLaHunt]

Add to libavcodec/tests/.gitignore an entry for test
program libavcodec/tests/mpeg12framerate . Other
similar test programs, e.g. jpeg2000dwt and dct, are
ignored in a similar way.

On initially checking out master, and doing "./configure"
and "make clean", "git status" reports no untracked
files. After running "make fate", "git status" reports
untracked file "libavcodec/tests/mpeg12framerate".

mpeg12framerate is a unit test program. It was apparently
introduced in commit
278c308ceae6b8d7bac1dfc24518821aae603988, on
Tue Sep 12 22:11:56 2017 +0100. It added a new function
ff_mpeg12_find_best_frame_rate() to
libavcodec/mpeg12framerate.c , and the code in
libavcodec/tests/mpeg12framerate.c to exercise that
function. This commit also added the new program to
the FATE suite, but it omitted a .gitignore entry.
---
 libavcodec/tests/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 7f9e3825b6..350fb2990c 100644
--- a/libavcodec/tests/.gitignore
+++ b/libavcodec/tests/.gitignore
@@ -14,6 +14,7 @@
 /mathops
 /mjpegenc_huffman
 /motion
+/mpeg12framerate
 /options
 /rangecoder
 /snowenc
-- 
2.12.2

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

[FFmpeg-devel] [PATCH] avformat/hlsenc: remove unused avio_open_dyn_buf call

[Steven Liu]

fix CID: 1421196

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e0cef8b879..d39b65fddd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1678,7 +1678,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 range_length = avio_close_dyn_buf(oc->pb, );
 avio_write(hls->out, buffer, range_length);
 hls->init_range_length = range_length;
-avio_open_dyn_buf(>pb);
 hls->packets_written = 0;
 ff_format_io_close(s, >out);
 } else {
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Hendrik Leppkes]

On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
 wrote:
> On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
>> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
>> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
>> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
>> >> > Hi all
>> >> >
>> >> > I intend to make 3.4.1 very soon
>> >>
>> >> Shouldn't we first decide on how to proceed with #6775?
>> >
>> > This would be ideal.
>> >
>> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
>>
>> This was confirmed by more than one developer, yes.
>>
>> > I see a patch that is said to improve 6775, can that be applied and
>> > would that resolve this ?
>>
>> Iiuc, it would not completely resolve the issue, see:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
>>
>> > If so why was it not applied yet ?
>>
>> The patch did not get support here, see:
>> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
>> in compat_decode
>
>
> Is someone working on fixing this better than with the available patch ?
>

I don't even agree this needs fixing. Those projects use the API wrong.

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