Re: [FFmpeg-devel] [PATCH 0/1] af_hdcd: Process stereo channels together, fix #5727

2016-07-27 Thread Burt P. 
> My suggestion is that you send your public key to
> Michael and commit yourself including adding yourself
> as maintainer of hdcd.

I don't know enough about what that would mean. I'm also not
an expert user of git.

>> One strange case is John Mellencamp - [1994] Mr. Happy Go Lucky
>> 06. Emotional Love, where there is one extra HDCD packet in one
>> channel, and that target_gain value ends up being ignored.
>
> Is this a regression against the code in current git head?
> Or just a (possibly) unsolved issue?

This patch causes the target_gain in that packet to be ignored, where
before it would not have been. This is correct, however, if you're trying
to replicate HDCD decoding as described in the paper mentioned in #5727.
Although, aside from being unmatched in the other channel, the packet
appears completely legit. Its just a weird example where the output is
different with the new code. Most of the time the two processing modes
output is exactly the same.

>> This patch is against master, so it also includes the changes in an
>> earlier (not yet applied) patch set for HDCD detection, PE mode,
>> cdt counter, and code comments.
>
> Please split the patches as much as it makes sense.
>

Those other patches have been applied today. I'll split this one up and
resubmit as a set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/matroskadec: Add test for seeking with codec delay.

2016-07-27 Thread Chris Cunningham 
The file to upload to fate-suite can be found here:
https://storage.googleapis.com/chcunningham-chrome-shared/codec_delay_opus.mkv

Alternatively, you can generate it via:
ffmpeg -i ../../tests/data/lavf/lavf.mkv -acodec opus -vn
codec_delay_opus.mkv

On Wed, Jul 27, 2016 at 6:33 PM,  wrote:

> From: Chris Cunningham 
>
> Also cleanup parens for the skip_to_timecode check.
> ---
>  libavformat/matroskadec.c  |  2 +-
>  tests/fate/seek.mak|  3 +++
>  tests/ref/seek/mkv-codec-delay | 48
> ++
>  3 files changed, 52 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/seek/mkv-codec-delay
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 60b1b34..d07a092 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3153,7 +3153,7 @@ static int matroska_parse_block(MatroskaDemuxContext
> *matroska, uint8_t *data,
>  // Compare signed timecodes. Timecode may be negative due to
> codec delay
>  // offset. We don't support timestamps greater than int64_t
> anyway - see
>  // AVPacket's pts.
> -if ((int64_t)timecode < (int64_t)(matroska->skip_to_timecode))
> +if ((int64_t)timecode < (int64_t)matroska->skip_to_timecode)
>  return res;
>  if (is_keyframe)
>  matroska->skip_to_keyframe = 0;
> diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak
> index b831cf8..f835da5 100644
> --- a/tests/fate/seek.mak
> +++ b/tests/fate/seek.mak
> @@ -247,8 +247,11 @@ FATE_SEEK += $(FATE_SEEK_LAVF-yes:%=fate-seek-lavf-%)
>
>  FATE_SEEK_EXTRA-$(CONFIG_MP3_DEMUXER)   += fate-seek-extra-mp3
>  FATE_SEEK_EXTRA-$(call ALLYES, CACHE_PROTOCOL PIPE_PROTOCOL MP3_DEMUXER)
> += fate-seek-cache-pipe
> +FATE_SEEK_EXTRA-$(CONFIG_MATROSKA_DEMUXER) += fate-seek-mkv-codec-delay
>  fate-seek-extra-mp3:  CMD = run libavformat/tests/seek$(EXESUF)
> $(TARGET_SAMPLES)/gapless/gapless.mp3 -fastseek 1
>  fate-seek-cache-pipe: CMD = cat $(TARGET_SAMPLES)/gapless/gapless.mp3 |
> run libavformat/tests/seek$(EXESUF) cache:pipe:0 -read_ahead_limit -1
> +fate-seek-mkv-codec-delay:   CMD = run libavformat/tests/seek$(EXESUF)
> $(TARGET_SAMPLES)/mkv/codec_delay_opus.mkv
> +
>  FATE_SEEK_EXTRA += $(FATE_SEEK_EXTRA-yes)
>
>
> diff --git a/tests/ref/seek/mkv-codec-delay
> b/tests/ref/seek/mkv-codec-delay
> new file mode 100644
> index 000..9d4582c
> --- /dev/null
> +++ b/tests/ref/seek/mkv-codec-delay
> @@ -0,0 +1,48 @@
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret: 0 st:-1 flags:0  ts:-1.00
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret: 0 st:-1 flags:1  ts: 1.894167
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret: 0 st: 0 flags:0  ts: 0.788000
> +ret: 0 st: 0 flags:1 dts: 0.794000 pts: 0.794000 pos:   7358
> size:   154
> +ret: 0 st: 0 flags:1  ts:-0.317000
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret:-1 st:-1 flags:0  ts: 2.576668
> +ret: 0 st:-1 flags:1  ts: 1.470835
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret: 0 st: 0 flags:0  ts: 0.365000
> +ret: 0 st: 0 flags:1 dts: 0.374000 pts: 0.374000 pos:   3963
> size:   150
> +ret: 0 st: 0 flags:1  ts:-0.741000
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret:-1 st:-1 flags:0  ts: 2.153336
> +ret: 0 st:-1 flags:1  ts: 1.047503
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret: 0 st: 0 flags:0  ts:-0.058000
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret: 0 st: 0 flags:1  ts: 2.836000
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret:-1 st:-1 flags:0  ts: 1.730004
> +ret: 0 st:-1 flags:1  ts: 0.624171
> +ret: 0 st: 0 flags:1 dts: 0.614000 pts: 0.614000 pos:   5903
> size:   159
> +ret: 0 st: 0 flags:0  ts:-0.482000
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret: 0 st: 0 flags:1  ts: 2.413000
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret:-1 st:-1 flags:0  ts: 1.306672
> +ret: 0 st:-1 flags:1  ts: 0.200839
> +ret: 0 st: 0 flags:1 dts: 0.194000 pts: 0.194000 pos:   2512
> size:   159
> +ret: 0 st: 0 flags:0  ts:-0.905000
> +ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748
> size:   320
> +ret: 0 st: 0 flags:1  ts: 1.989000
> +ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306
> size:   291
> +ret: 0 st:-1 flags:0  ts: 0.883340
> +ret: 0 st: 0

[FFmpeg-devel] [PATCH] libavformat/matroskadec: Add test for seeking with codec delay.

2016-07-27 Thread chcunningham 
From: Chris Cunningham 

Also cleanup parens for the skip_to_timecode check.
---
 libavformat/matroskadec.c  |  2 +-
 tests/fate/seek.mak|  3 +++
 tests/ref/seek/mkv-codec-delay | 48 ++
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/seek/mkv-codec-delay

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 60b1b34..d07a092 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3153,7 +3153,7 @@ static int matroska_parse_block(MatroskaDemuxContext 
*matroska, uint8_t *data,
 // Compare signed timecodes. Timecode may be negative due to codec 
delay
 // offset. We don't support timestamps greater than int64_t anyway - 
see
 // AVPacket's pts.
-if ((int64_t)timecode < (int64_t)(matroska->skip_to_timecode))
+if ((int64_t)timecode < (int64_t)matroska->skip_to_timecode)
 return res;
 if (is_keyframe)
 matroska->skip_to_keyframe = 0;
diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak
index b831cf8..f835da5 100644
--- a/tests/fate/seek.mak
+++ b/tests/fate/seek.mak
@@ -247,8 +247,11 @@ FATE_SEEK += $(FATE_SEEK_LAVF-yes:%=fate-seek-lavf-%)
 
 FATE_SEEK_EXTRA-$(CONFIG_MP3_DEMUXER)   += fate-seek-extra-mp3
 FATE_SEEK_EXTRA-$(call ALLYES, CACHE_PROTOCOL PIPE_PROTOCOL MP3_DEMUXER) += 
fate-seek-cache-pipe
+FATE_SEEK_EXTRA-$(CONFIG_MATROSKA_DEMUXER) += fate-seek-mkv-codec-delay
 fate-seek-extra-mp3:  CMD = run libavformat/tests/seek$(EXESUF) 
$(TARGET_SAMPLES)/gapless/gapless.mp3 -fastseek 1
 fate-seek-cache-pipe: CMD = cat $(TARGET_SAMPLES)/gapless/gapless.mp3 | run 
libavformat/tests/seek$(EXESUF) cache:pipe:0 -read_ahead_limit -1
+fate-seek-mkv-codec-delay:   CMD = run libavformat/tests/seek$(EXESUF) 
$(TARGET_SAMPLES)/mkv/codec_delay_opus.mkv
+
 FATE_SEEK_EXTRA += $(FATE_SEEK_EXTRA-yes)
 
 
diff --git a/tests/ref/seek/mkv-codec-delay b/tests/ref/seek/mkv-codec-delay
new file mode 100644
index 000..9d4582c
--- /dev/null
+++ b/tests/ref/seek/mkv-codec-delay
@@ -0,0 +1,48 @@
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret: 0 st:-1 flags:0  ts:-1.00
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret: 0 st:-1 flags:1  ts: 1.894167
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret: 0 st: 0 flags:0  ts: 0.788000
+ret: 0 st: 0 flags:1 dts: 0.794000 pts: 0.794000 pos:   7358 size:   
154
+ret: 0 st: 0 flags:1  ts:-0.317000
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret:-1 st:-1 flags:0  ts: 2.576668
+ret: 0 st:-1 flags:1  ts: 1.470835
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret: 0 st: 0 flags:0  ts: 0.365000
+ret: 0 st: 0 flags:1 dts: 0.374000 pts: 0.374000 pos:   3963 size:   
150
+ret: 0 st: 0 flags:1  ts:-0.741000
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret:-1 st:-1 flags:0  ts: 2.153336
+ret: 0 st:-1 flags:1  ts: 1.047503
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret: 0 st: 0 flags:0  ts:-0.058000
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret: 0 st: 0 flags:1  ts: 2.836000
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret:-1 st:-1 flags:0  ts: 1.730004
+ret: 0 st:-1 flags:1  ts: 0.624171
+ret: 0 st: 0 flags:1 dts: 0.614000 pts: 0.614000 pos:   5903 size:   
159
+ret: 0 st: 0 flags:0  ts:-0.482000
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret: 0 st: 0 flags:1  ts: 2.413000
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret:-1 st:-1 flags:0  ts: 1.306672
+ret: 0 st:-1 flags:1  ts: 0.200839
+ret: 0 st: 0 flags:1 dts: 0.194000 pts: 0.194000 pos:   2512 size:   
159
+ret: 0 st: 0 flags:0  ts:-0.905000
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret: 0 st: 0 flags:1  ts: 1.989000
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret: 0 st:-1 flags:0  ts: 0.883340
+ret: 0 st: 0 flags:1 dts: 0.894000 pts: 0.894000 pos:   8154 size:   
155
+ret: 0 st:-1 flags:1  ts:-0.222493
+ret: 0 st: 0 flags:1 dts:-0.007000 pts:-0.007000 pos:748 size:   
320
+ret:-1 st: 0 flags:0  ts: 2.672000
+ret: 0 st: 0 flags:1  ts: 1.566000
+ret: 0 st: 0 flags:1 dts: 1.014000 pts: 1.014000 pos:   9306 size:   
291
+ret: 0 st:-1 flags:0  ts: 0.460008
+ret: 0 st: 0 flags:1 dts: 0.474000 pts: 0.474000 pos:   4768 size:   
153
+ret: 0 st:-1

Re: [FFmpeg-devel] [PATCH 4/4] af_hdcd: Report PE as being intermittent or permanent

2016-07-27 Thread Michael Niedermayer 
On Sat, Jul 23, 2016 at 09:26:51PM -0500, Burt P wrote:
> The Peak Extend feature could be enabled permanently or only
> when needed. This is now reported.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)

applied

thx

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

What does censorship reveal? It reveals fear. -- Julian Assange


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/matroskaenc: Write duration early during mkv_write_header (Rev #3)

2016-07-27 Thread Michael Niedermayer 
On Tue, Jul 19, 2016 at 01:33:38AM +, Soft Works wrote:
> From 7d6d6a7775fef707ea1e8e705acc3362f20b6b89 Mon Sep 17 00:00:00 2001
> From: softworkz 
> Date: Sun, 17 Jul 2016 04:19:41 +0200
> Subject: [PATCH] avformat/matroskaenc: Write duration early during 
> mkv_write_header (Rev #3)
> 
> Rev #2: Fixes doubled header writing, checked FATE running without errors
> Rev #3: Fixed coding style
> 
> This commit addresses the following scenario:
> 
> we are using ffmpeg to transcode or remux mkv (or something else) to mkv. The 
> result is being streamed on-the-fly to an HTML5 client (streaming starts 
> while ffmpeg is still running). The problem here is that the client is unable 
> to detect the duration because the duration is only written to the mkv at the 
> end of the transcoding/remoxing process. In matroskaenc.c, the duration is 
> only written during mkv_write_trailer but not during mkv_write_header.
> 
> The approach:
> 
> FFMPEG is currently putting quite some effort to estimate the durations of 
> source streams, but in many cases the source stream durations are still left 
> at 0 and these durations are nowhere mapped to or used for output streams. As 
> much as I would have liked to deduct or estimate output durations based on 
> input stream durations - I realized that this is a hard task (as Nicolas 
> already mentioned in a previous conversation). It would involve changes to 
> the duration calculation/estimation/deduction for input streams and 
> propagating these durations to output streams or the output context in a 
> correct way.
> So I looked for a simple and small solution with better chances to get 
> accepted. In webmdashenc.c I found that a duration is written during 
> write_header and this duration is taken from the streams' metadata, so I 
> decided for a similar approach.
> 
> And here's what it does:
> 
> At first it is checking the duration of the AVFormatContext. In typical cases 
> this value is not set, but: It is set in cases where the user has specified a 
> recording_time or an end_time via the -t or -to parameters.
> Then it is looking for a DURATION metadata field in the metadata of the 
> output context (AVFormatContext::metadata). This would only exist in case the 
> user has explicitly specified a metadata DURATION value from the command line.
> Then it is iterating all streams looking for a "DURATION" metadata (this 
> works unless the option "-map_metadata -1" has been specified) and determines 
> the maximum value.
> The precendence is as follows: 1. Use duration of AVFormatContext - 2. Use 
> explicitly specified metadata duration value - 3. Use maximum (mapped) 
> metadata duration over all streams.
> 
> To test this:
> 
> 1. With explicit recording time:
> ffmpeg -i file:"src.mkv" -loglevel debug -t 01:38:36.000 -y "dest.mkv"
> 
> 2. Take duration from metadata specified via command line parameters:
> ffmpeg -i file:"src.mkv" -loglevel debug -map_metadata -1 -metadata 
> Duration="01:14:33.00" -y "dest.mkv"
> 
> 3. Take duration from mapped input metadata:
> ffmpeg -i file:"src.mkv" -loglevel debug -y "dest.mkv"
> 
> Regression risk:
> 
> Very low IMO because it only affects the header while ffmpeg is still 
> running. When ffmpeg completes the process, the duration is rewritten to the 
> header with the usual value (same like without this commit).
> 
> Signed-off-by: SoftWorkz 
> ---
>  libavformat/matroskaenc.c | 39 ++-
>  1 file changed, 38 insertions(+), 1 deletion(-)

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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/utils: Fix find_stream_info not considering the extradata it found

2016-07-27 Thread Anssi Hannula 
27.07.2016, 02:04, Michael Niedermayer kirjoitti:
> On Tue, Jul 26, 2016 at 08:39:03PM +0300, Anssi Hannula wrote:
>> 26.07.2016, 17:59, Michael Niedermayer kirjoitti:
>>> On Tue, Jul 26, 2016 at 03:56:13PM +0300, Anssi Hannula wrote:
 Commit 9200514ad8717c6 ("lavf: replace AVStream.codec with
 AVStream.codecpar") merged in commit 6f69f7a8bf6a0d01 changed
 avformat_find_stream_info() to put the extradata it got from
 st->parser->parser->split() to st->internal->avctx instead of st->codec
 (from where it will be later copied to st->codecpar).

 However, in the same function, the "is stream ready?" check was changed
 to check for extradata in st->codecpar instead of st->codec.

 Extradata retrieved from split() is therefore not considered anymore,
 and avformat_find_stream_info() will therefore needlessly continue
 probing in some cases.

 Fix that by checking for the extradata at st->internal->avctx where it
 is actually put.

 ---

 Michael Niedermayer wrote:
> seems to break fate here:
 [...]

 Oops, seems I messed up running fate and missed the "warning: only a
 subset of the fate tests will be run because SAMPLES is not specified"
 warning it gave... Thanks for catching that.

 Seems this reverse fix is actually needed, as extradata is actually
 copied in the other direction (from st->internal->avctx to
 st->codecpar).
>>>
>>> it seems this causes some changes, quite possibly thats simply due to
>>> less packets being read
>>>
>>> libavformat/tests/seek 
>>> Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv 
>>> -duration 400
>>> with 
>>> http://samples.ffmpeg.org/Matroska/matrix/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
>>
>> @@ -9,7 +9,7 @@
>>  ret: 0 st:13 flags:1 dts: 86.75 pts: 86.75 pos: -1
>> size: 50436
>>  ret:-1 st: 1 flags:0  ts: 250.577000
>>  ret: 0 st: 1 flags:1  ts: 13.471000
>> -ret: 0 st:13 flags:1 dts: 5.909000 pts: 5.909000 pos: -1
>> size: 50436
>> +ret: 0 st:13 flags:1 dts: 1.776000 pts: 1.776000 pos: -1
>> size: 50436
>>  ret:-1 st: 2 flags:0  ts: 176.365000
>>  ret: 0 st: 2 flags:1  ts: 339.259000
>>  ret: 0 st:13 flags:1 dts: 145.08 pts: 145.08 pos:
>> -1 size: 50436
>>
>> Seems to indeed be due to less packets being read in
>> avformat_find_stream_info().
>>
>> Matroska demuxer seems to add keyframes to the index as it encounters
>> them, and in this case more keyframes are encountered in
>> avformat_stream_info() phase, which seems to result in more accurate
>> seeking in the early seconds of the file.
>>
>>> for tickets//2254/ttvHD_vlc_sample.ts the tbr changes from
>>> 1001/3 to 1/30
>>
>> Looks like the timestamps are jittery in that sample:
>>
>> 36072.231911, dts = prev + 3002
>> 36072.265289, dts = prev + 3004
>> 36072.298656, dts = prev + 3003
>> 36072.331433, dts = prev + 2950
>> 36072.364800, dts = prev + 3003
>> 36072.398167, dts = prev + 3003
>> 36072.431533, dts = prev + 3003
>> 36072.464900, dts = prev + 3003
>> 36072.498267, dts = prev + 3003
>> 36072.531633, dts = prev + 3003
>> 36072.565000, dts = prev + 3003
>> 36072.598367, dts = prev + 3003
>> 36072.630667, dts = prev + 2907
>> 36072.664033, dts = prev + 3003
>> 36072.697400, dts = prev + 3003
>> 36072.730767, dts = prev + 3003
>> 36072.764133, dts = prev + 3003
>> 36072.797500, dts = prev + 3003
>> 36072.830867, dts = prev + 3003
>> 36072.864233, dts = prev + 3003
>> 36072.897600, dts = prev + 3003
>> 36072.939278, dts = prev + 3751
>> 36072.972644, dts = prev + 3003
>> 36073.006011, dts = prev + 3003
>> 36073.034478, dts = prev + 2562
>> 36073.067844, dts = prev + 3003
>>
>> And this throws the ff_rfps_calculate() algorithm off unless it is
>> called with fpsprobesize (fps_analyze_framecount) of 160 or more
>> (default is 20).
>>
>> Not sure if something could/should be done to keep tbr of that file to
>> be detected as 1001/3000.
>>
>>
>> For both of these cases I verified that FFmpeg 3.0 had the same behavior
>> as with this patch, i.e. their behavior was unintendedly changed by the
>> original commit 6f69f7a8bf6a0d01.
> 
> thanks alot for the deep analysis
> i have no objections to the change
> 
> 
> [...]

Applied.


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

Re: [FFmpeg-devel] [PATCH 2/4] af_hdcd: more comments in state struct

2016-07-27 Thread Michael Niedermayer 
On Sat, Jul 23, 2016 at 09:26:49PM -0500, Burt P wrote:
> Add some comments describing the fields in hdcd_state_t.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 34 +-
>  1 file changed, 21 insertions(+), 13 deletions(-)

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] af_hdcd: Add counter for cdt expirations

2016-07-27 Thread Michael Niedermayer 
On Sun, Jul 24, 2016 at 11:15:22AM -0500, Burt P wrote:
> Adds a counter for when the "code detect timer" expired without
> finding a valid packet.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 1/4] af_hdcd: Improve HDCD detection

2016-07-27 Thread Michael Niedermayer 
On Sat, Jul 23, 2016 at 09:26:48PM -0500, Burt P wrote:
> HDCD is now only considered detected if a valid packet
> is active in both channels simultaneously.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

applied

thanks

[...]
-- 
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] [PATCH] fate: Add HDCD filter tests for false positive and error detection

2016-07-27 Thread Michael Niedermayer 
On Thu, Jul 14, 2016 at 12:54:34PM -0500, Burt P wrote:
> Signed-off-by: Burt P 
> ---
>  tests/fate-run.sh   |  3 ++-
>  tests/fate/filter-audio.mak | 12 
>  2 files changed, 14 insertions(+), 1 deletion(-)

it seems ive forgotton this one

applied

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-07-27 Thread Davinder Singh 
On Wed, Jul 27, 2016 at 4:50 PM Michael Niedermayer 
wrote:

> On Tue, Jul 26, 2016 at 07:30:14PM +, Davinder Singh wrote:
> > hi
> >
> > On Mon, Jul 25, 2016 at 9:55 PM Ronald S. Bultje 
> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer
> > >  > > > wrote:
> > >
> > > > On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > > > > https://github.com/dsmudhar/FFmpeg/commits/dev
> > >
> > >
> > > So, correct me if I'm wrong, but it seems the complete ME code
> currently
> > > lives inside the filter. I wonder if that is the best way forward. I
> > > thought the idea was to split out the ME code into its own module and
> share
> > > it between various filters and the relevant encoders without a strict
> > > dependency on avfilter/avcodec, or more specifically, AVCodecContext or
> > > anything like that?
> > >
> > > Ronald
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> > The code is almost ready to be shared, I just didn't move that yet. That
> > makes changes difficult. mInterpolate will use those functions (which are
> > currently in mEstimate) to find true motion. My plan is to move that code
> > out of mEstimate to say, libavfilter/motion_estimation.c and can be
> shared
> > between multiple filters. Since that is general ME, I think it can be
> used
> > with encoding (with some changes). So, should I move it to libavutil
> > instead?
>
> one thing thats important,
> independant of where its moved, the interface between libs is part
> of the public ABI of that lib and thus cannot be changed once it is
> added. That is new functions can be added but they
> cannot be removed nor their interface changed once added until the
> next major version bump (which might occur once a year)
>
> its important to keep this in mind when designing inter lib interfaces


 I'll keep this in mind.



On Wed, Jul 27, 2016 at 6:12 PM Ronald S. Bultje  wrote:

> Hi,
>
> [...]
>
>
> You could - to address this - design it as if it lived in libavutil, but
> (until it actually is used in libavcodec) keep it in libavfilter with a ff_
> function prefix to ensure functions are not exported from the lib.
>
> Once libavcodec uses it, move it to libavutil and change ff_ to av(priv?)_
> prefix so it's exported.


I was thinking something like that! Will do.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-07-27 Thread Michael Niedermayer 
On Wed, Jul 27, 2016 at 08:41:28AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Jul 27, 2016 at 7:20 AM, Michael Niedermayer  > wrote:
> 
> > On Tue, Jul 26, 2016 at 07:30:14PM +, Davinder Singh wrote:
> > > hi
> > >
> > > On Mon, Jul 25, 2016 at 9:55 PM Ronald S. Bultje 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer
> > > >  > > > > wrote:
> > > >
> > > > > On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > > > > > https://github.com/dsmudhar/FFmpeg/commits/dev
> > > >
> > > >
> > > > So, correct me if I'm wrong, but it seems the complete ME code
> > currently
> > > > lives inside the filter. I wonder if that is the best way forward. I
> > > > thought the idea was to split out the ME code into its own module and
> > share
> > > > it between various filters and the relevant encoders without a strict
> > > > dependency on avfilter/avcodec, or more specifically, AVCodecContext or
> > > > anything like that?
> > > >
> > > > Ronald
> > > > ___
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@ffmpeg.org
> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
> > > The code is almost ready to be shared, I just didn't move that yet. That
> > > makes changes difficult. mInterpolate will use those functions (which are
> > > currently in mEstimate) to find true motion. My plan is to move that code
> > > out of mEstimate to say, libavfilter/motion_estimation.c and can be
> > shared
> > > between multiple filters. Since that is general ME, I think it can be
> > used
> > > with encoding (with some changes). So, should I move it to libavutil
> > > instead?
> >
> > one thing thats important,
> > independant of where its moved, the interface between libs is part
> > of the public ABI of that lib and thus cannot be changed once it is
> > added. That is new functions can be added but they
> > cannot be removed nor their interface changed once added until the
> > next major version bump (which might occur once a year)
> >
> > its important to keep this in mind when designing inter lib interfaces
> 
> 
> You could - to address this - design it as if it lived in libavutil, but
> (until it actually is used in libavcodec) keep it in libavfilter with a ff_
> function prefix to ensure functions are not exported from the lib.
> 
> Once libavcodec uses it, move it to libavutil and change ff_ to av(priv?)_
> prefix so it's exported.

i like this idea alot!

thanks!

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH 2/2] MAINTAINERS: Add myself as maintainer of fifo muxer

2016-07-27 Thread Michael Niedermayer 
On Wed, Jul 27, 2016 at 09:16:36PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 25, 2016 at 06:00:16PM +0200, sebechlebsky...@gmail.com wrote:
> > From: Jan Sebechlebsky 
> > 
> > Signed-off-by: Jan Sebechlebsky 
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> 
> applied

actually i will apply once the muxer is reviewed and 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 2/2] MAINTAINERS: Add myself as maintainer of fifo muxer

2016-07-27 Thread Michael Niedermayer 
On Mon, Jul 25, 2016 at 06:00:16PM +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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/alsdec: implement floating point decoding

2016-07-27 Thread Clément Bœsch 
On Wed, Jul 27, 2016 at 07:48:56PM +0200, Thilo Borgmann wrote:
> > @@ -1803,6 +2057,34 @@ static av_cold int decode_init(AVCodecContext *avctx)
> >  ctx->raw_buffer   = av_mallocz_array(avctx->channels * 
> > channel_size, sizeof(*ctx->raw_buffer));
> >  ctx->raw_samples  = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->raw_samples));
> >  
> > +if (sconf->floating) {
> > +ctx->acf   = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->acf));
> > +ctx->shift_value   = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->shift_value));
> > +ctx->last_shift_value  = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->last_shift_value));
> > +ctx->last_acf_mantissa = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->last_acf_mantissa));
> > +ctx->raw_mantissa  = av_malloc_array(avctx->channels, 
> > sizeof(*ctx->raw_mantissa));
> > +
> > +ctx->larray = av_malloc_array(ctx->cur_frame_length * 4, 
> > sizeof(*ctx->larray));
> > +ctx->nbits  = av_malloc_array(ctx->cur_frame_length, 
> > sizeof(*ctx->nbits));
> > +ctx->mlz= av_malloc(sizeof(*ctx->mlz));
> > +ff_mlz_init_dict(avctx, ctx->mlz);
> > +ff_mlz_flush_dict(ctx->mlz);
> > +
> > +if (!ctx->mlz || !ctx->acf || !ctx->shift_value || 
> > !ctx->last_shift_value
> > +|| !ctx->last_acf_mantissa || !ctx->raw_mantissa) {
> > +av_log(avctx, AV_LOG_ERROR, "Allocating buffer memory 
> > failed.\n");
> > +ret = AVERROR(ENOMEM);
> > +goto fail;
> > +}
> 
> > +for (c = 0; c < avctx->channels; ++c) {
> > +ctx->raw_mantissa[c] = av_malloc_array(ctx->cur_frame_length, 
> > sizeof(**ctx->raw_mantissa));
> 
> Is there no av_malloc_arrayz() ?
> 

there is av_mallocz_array()

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] Fix audio clipping problem in dynaudnorm

2016-07-27 Thread andyndeanna 
Hello,

See attached patch to fix a clipping problem with dynaudnorm when the first
frame contains silence.  I implemented the fix by adding a boundary mode.
It could also be done by changing how b=1 works.

Thanks,
Andy


0001-Adds-another-boundry-mode-to-dynaudnorm-that-perform.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fwd: [PATCH] avcodec: allow hardware decoding with multithread for FFmpeg

2016-07-27 Thread Stève Lhomme 
On Wed, Jul 27, 2016 at 7:58 PM, Hendrik Leppkes  wrote:
> On Wed, Jul 27, 2016 at 6:43 PM, Stève Lhomme  wrote:
>> Hello fellow FFmpegers,
>>
>> Is there still an issue with hardware decoding when combined with
>> multithread ? It seems to work fine on our Windows build. Although we
>> have a mutex in place in the D3D11 variant of the code that may help.
>> It mostly protects the video context...
>>
>> If necessary we can have the same trick for DXVA2 if there are still
>> known issues.
>>
>
> ffmpeg.c just produces corrupt decoding when you try to use that, so
> use at your own peril.
> Not to mention that it doesn't offer any performance benefits.

Thanks.

> - 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] Fwd: [PATCH] avcodec: allow hardware decoding with multithread for FFmpeg

2016-07-27 Thread Hendrik Leppkes 
On Wed, Jul 27, 2016 at 6:43 PM, Stève Lhomme  wrote:
> Hello fellow FFmpegers,
>
> Is there still an issue with hardware decoding when combined with
> multithread ? It seems to work fine on our Windows build. Although we
> have a mutex in place in the D3D11 variant of the code that may help.
> It mostly protects the video context...
>
> If necessary we can have the same trick for DXVA2 if there are still
> known issues.
>

ffmpeg.c just produces corrupt decoding when you try to use that, so
use at your own peril.
Not to mention that it doesn't offer any performance benefits.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/flvdec: parse keyframe before a\v stream was created add_keyframes_index() when stream created or keyframe parsed

2016-07-27 Thread Michael Niedermayer 
On Wed, Jul 27, 2016 at 12:21:25PM +0800, Xinzheng Zhang wrote:
> ---
>  libavformat/flvdec.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

applied

thx

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

What does censorship reveal? It reveals fear. -- Julian Assange


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/h264_slice: Make setup_finished check cover more cases

2016-07-27 Thread Michael Niedermayer 
On Wed, Jul 27, 2016 at 06:37:17PM +0200, Michael Niedermayer wrote:
> ---
>  libavcodec/h264_slice.c |   11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

as ubitux merge work benefits from this applied

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/flvdec: splitting add_keyframes_index() out from parse_keyframes_index()

2016-07-27 Thread Michael Niedermayer 
On Wed, Jul 27, 2016 at 12:21:24PM +0800, Xinzheng Zhang wrote:
> ---
>  libavformat/flvdec.c | 76 
> +---
>  1 file changed, 60 insertions(+), 16 deletions(-)

applied

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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/alsdec: implement floating point decoding

2016-07-27 Thread Umair Khan 
On Wed, Jul 27, 2016 at 1:27 PM, Umair Khan  wrote:
> On Wed, Jul 27, 2016 at 1:28 PM, Thilo Borgmann  
> wrote:
>> Hi,
>>
 [...]
> @@ -1678,6 +1931,7 @@ static av_cold int decode_init(AVCodecContext 
> *avctx)
>  {
>  unsigned int c;
>  unsigned int channel_size;
> +unsigned int i;
>  int num_buffers, ret;
>  ALSDecContext *ctx = avctx->priv_data;
>  ALSSpecificConfig *sconf = >sconf;
> @@ -1803,6 +2057,34 @@ static av_cold int decode_init(AVCodecContext 
> *avctx)
>  ctx->raw_buffer   = av_mallocz_array(avctx->channels * 
> channel_size, sizeof(*ctx->raw_buffer));
>  ctx->raw_samples  = av_malloc_array(avctx->channels, 
> sizeof(*ctx->raw_samples));
>
> +if (sconf->floating) {
> +ctx->acf   = av_malloc_array(avctx->channels, 
> sizeof(*ctx->acf));
> +ctx->shift_value   = av_malloc_array(avctx->channels, 
> sizeof(*ctx->shift_value));
> +ctx->last_shift_value  = av_malloc_array(avctx->channels, 
> sizeof(*ctx->last_shift_value));
> +ctx->last_acf_mantissa = av_malloc_array(avctx->channels, 
> sizeof(*ctx->last_acf_mantissa));
> +ctx->raw_mantissa  = av_malloc_array(avctx->channels, 
> sizeof(*ctx->raw_mantissa));
> +
> +for (c = 0; c < avctx->channels; ++c) {
> +ctx->raw_mantissa[c] = 
> av_malloc_array(ctx->cur_frame_length, sizeof(**ctx->raw_mantissa));

 using ctx->raw_mantissa without prior malloc failure check
>>>
>>> Should I keep this in a separate patch? It is unrelated to my patch.
>>
>> This is not unrelated to your patch. You're allocating ctx->raw_mantissa 
>> array
>> and use the (maybe invalid) "allocated" array in the for loop. Test for a 
>> valid
>> pointer in ctx->raw_matissa before using it.
>
> Oops. Sorry. I mistook it as raw_samples. I'll send another patch in a bit.

Updated patch attached.

-Umair


0001-avcodec-alsdec-implement-floating-point-decoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fwd: [PATCH] avcodec: allow hardware decoding with multithread for FFmpeg

2016-07-27 Thread Stève Lhomme 
Hello fellow FFmpegers,

Is there still an issue with hardware decoding when combined with
multithread ? It seems to work fine on our Windows build. Although we
have a mutex in place in the D3D11 variant of the code that may help.
It mostly protects the video context...

If necessary we can have the same trick for DXVA2 if there are still
known issues.

Steve


-- Forwarded message --
From: Steve Lhomme 
Date: Wed, Jul 27, 2016 at 4:43 PM
Subject: [PATCH] avcodec: allow hardware decoding with multithread for FFmpeg
To: vlc-de...@videolan.org


The context is protected by a mutex.
---
 modules/codec/avcodec/video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/codec/avcodec/video.c b/modules/codec/avcodec/video.c
index 0c10f9e..bbf3ebb 100644
--- a/modules/codec/avcodec/video.c
+++ b/modules/codec/avcodec/video.c
@@ -1233,7 +1233,7 @@ static enum PixelFormat ffmpeg_GetFormat(
AVCodecContext *p_context,
 if (!can_hwaccel)
 return swfmt;

-#if (LIBAVCODEC_VERSION_MICRO >= 100) /* FFmpeg only */
+#if (LIBAVCODEC_VERSION_MICRO >= 100) && !defined(_WIN32) /* FFmpeg only */
 if (p_context->active_thread_type)
 {
 msg_Warn(p_dec, "thread type %d: disabling hardware acceleration",
--
2.8.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/h264_slice: Make setup_finished check cover more cases

2016-07-27 Thread Michael Niedermayer 
---
 libavcodec/h264_slice.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 74e8118..8d20028 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1563,12 +1563,15 @@ int ff_h264_decode_slice_header(H264Context *h, 
H264SliceContext *sl,
 if (ret < 0)
 return ret;
 
+if (sl->first_mb_addr == 0 || !h->current_slice) {
+if (h->setup_finished) {
+av_log(h->avctx, AV_LOG_ERROR, "Too many fields\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
 if (sl->first_mb_addr == 0) { // FIXME better field boundary detection
 if (h->current_slice) {
-if (h->setup_finished) {
-av_log(h->avctx, AV_LOG_ERROR, "Too many fields\n");
-return AVERROR_INVALIDDATA;
-}
 if (h->max_contexts > 1) {
 if (!h->single_decode_warning) {
 av_log(h->avctx, AV_LOG_WARNING, "Cannot decode multiple 
access units as slice threads\n");
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 1/4] lavc: add mpeg4 mediacodec decoder

2016-07-27 Thread Matthieu Bouron 
On Tue, Jul 26, 2016 at 05:54:58PM +0200, Thomas Volkert wrote:
> On 26.07.2016 11:15, Matthieu Bouron wrote:
> > On Tue, Jul 26, 2016 at 11:00:46AM +0200, Matthieu Bouron wrote:
> >> On Sun, Jul 24, 2016 at 03:06:14PM +0200, Thomas Volkert wrote:
> >>> From: Thomas Volkert 
> >>>
> >>> ---
> >>>  Changelog|   1 +
> >>>  configure|   1 +
> >>>  libavcodec/Makefile  |   1 +
> >>>  libavcodec/allcodecs.c   |   1 +
> >>>  libavcodec/mediacodecdec_mpeg4.c | 239 
> >>> +++
> >>>  libavcodec/version.h |   2 +-
> >>>  6 files changed, 244 insertions(+), 1 deletion(-)
> >>>  create mode 100644 libavcodec/mediacodecdec_mpeg4.c
> >>>
> >>> diff --git a/Changelog b/Changelog
> >>> index 2bd18ec..b8bbdb9 100644
> >>> --- a/Changelog
> >>> +++ b/Changelog
> >>> @@ -7,6 +7,7 @@ version :
> >>>  - Changed metadata print option to accept general urls
> >>>  - Alias muxer for Ogg Video (.ogv)
> >>>  - VP8 in Ogg muxing
> >>> +- MediaCodec MPEG-4 decoding
> >>>  
> >>>  
> >>>  version 3.1:
> >>> diff --git a/configure b/configure
> >>> index 1b41303..9004b06 100755
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -2621,6 +2621,7 @@ 
> >>> mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder"
> >>>  mpeg2_xvmc_hwaccel_deps="xvmc"
> >>>  mpeg2_xvmc_hwaccel_select="mpeg2video_decoder"
> >>>  mpeg4_crystalhd_decoder_select="crystalhd"
> >>> +mpeg4_mediacodec_decoder_deps="mediacodec"
> >>>  mpeg4_mmal_decoder_deps="mmal"
> >>>  mpeg4_mmal_decoder_select="mmal"
> >>>  mpeg4_mmal_hwaccel_deps="mmal"
> >>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >>> index abef19e..642cf2a 100644
> >>> --- a/libavcodec/Makefile
> >>> +++ b/libavcodec/Makefile
> >>> @@ -317,6 +317,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264.o 
> >>> h264_cabac.o h264_cavlc.o \
> >>>h2645_parse.o
> >>>  OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuvid.o
> >>>  OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec_h264.o
> >>> +OBJS-$(CONFIG_MPEG4_MEDIACODEC_DECODER) += mediacodecdec_mpeg4.o
> >>>  OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
> >>>  OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
> >>>  OBJS-$(CONFIG_NVENC_ENCODER)   += nvenc_h264.o
> >>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> >>> index 951e199..2d98694 100644
> >>> --- a/libavcodec/allcodecs.c
> >>> +++ b/libavcodec/allcodecs.c
> >>> @@ -239,6 +239,7 @@ void avcodec_register_all(void)
> >>>  REGISTER_ENCDEC (MPEG2VIDEO,mpeg2video);
> >>>  REGISTER_ENCDEC (MPEG4, mpeg4);
> >>>  REGISTER_DECODER(MPEG4_CRYSTALHD,   mpeg4_crystalhd);
> >>> +REGISTER_DECODER(MPEG4_MEDIACODEC,  mpeg4_mediacodec);
> >>>  REGISTER_DECODER(MPEG4_MMAL,mpeg4_mmal);
> >> You should also add the relevant hwaccel entry in this file:
> >>
> >> +REGISTER_HWACCEL(MPEG4_MEDIACODEC,  mpeg4_mediacodec);
> >>
> >> and declare the hwaccel at the bottom of libavcodec/mediacodecdec.c, like 
> >> the h264 one.
> >>
> >>>  #if FF_API_VDPAU
> >>>  REGISTER_DECODER(MPEG4_VDPAU,   mpeg4_vdpau);
> >>> diff --git a/libavcodec/mediacodecdec_mpeg4.c 
> >>> b/libavcodec/mediacodecdec_mpeg4.c
> >>> new file mode 100644
> >>> index 000..7c4559b
> >>> --- /dev/null
> >>> +++ b/libavcodec/mediacodecdec_mpeg4.c
> >>> @@ -0,0 +1,239 @@
> >>> +/*
> >>> + * Android MediaCodec MPEG 4 decoder
> >>> + *
> >>> + * Copyright (c) 2016 Thomas Volkert 
> >>> + *
> >>> + * This file is part of FFmpeg.
> >>> + *
> >>> + * FFmpeg is free software; you can redistribute it and/or
> >>> + * modify it under the terms of the GNU Lesser General Public
> >>> + * License as published by the Free Software Foundation; either
> >>> + * version 2.1 of the License, or (at your option) any later version.
> >>> + *
> >>> + * FFmpeg is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >>> + * Lesser General Public License for more details.
> >>> + *
> >>> + * You should have received a copy of the GNU Lesser General Public
> >>> + * License along with FFmpeg; if not, write to the Free Software
> >>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> >>> 02110-1301 USA
> >>> + */
> >>> +
> >>> +#include "libavutil/avassert.h"
> >>> +#include "libavutil/common.h"
> >>> +#include "libavutil/fifo.h"
> >>> +
> >>> +#include "avcodec.h"
> >>> +#include "internal.h"
> >>> +#include "mediacodecdec.h"
> >>> +#include "mediacodec_wrapper.h"
> >>> +
> >>> +#define CODEC_MIME "video/mp4v-es"
> >>> +
> >>> +typedef struct MediaCodecMPEG4DecContext {
> >>> +
> >>> +MediaCodecDecContext *ctx;
> >>> +
> >>> +AVBSFContext *bsf;
> >>> +
> >>> +AVFifoBuffer *fifo;
> >>> +
> >>> +AVPacket

[FFmpeg-devel] [PATCH] Fix double free and null dereferences in the qsv decoder

2016-07-27 Thread Yuli Khodorkovskiy 
This patch fixes the h264_qsv decoder issues mentioned
in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.

The patch may be tested by specifying h264_qsv as the decoder to ffplay
for an h264 encoded file.

ffplay -vcodec h264_qsv foo.mts

Signed-off-by: Yuli Khodorkovskiy 
---
 libavcodec/qsvdec.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 9125700..b462887 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -408,7 +408,7 @@ static int do_qsv_decode(AVCodecContext *avctx, QSVContext 
*q,
 return ff_qsv_error(ret);
 }
 n_out_frames = av_fifo_size(q->async_fifo) / 
(sizeof(out_frame)+sizeof(sync));
-
+av_freep();
 if (n_out_frames > q->async_depth || (flush && n_out_frames) ) {
 AVFrame *src_frame;
 
@@ -555,16 +555,18 @@ void ff_qsv_decode_reset(AVCodecContext *avctx, 
QSVContext *q)
 }
 
 /* Reset output surfaces */
-av_fifo_reset(q->async_fifo);
+if (q->async_fifo)
+av_fifo_reset(q->async_fifo);
 
 /* Reset input packets fifo */
-while (av_fifo_size(q->pkt_fifo)) {
+while (q->pkt_fifo && av_fifo_size(q->pkt_fifo)) {
 av_fifo_generic_read(q->pkt_fifo, , sizeof(pkt), NULL);
 av_packet_unref();
 }
 
 /* Reset input bitstream fifo */
-av_fifo_reset(q->input_fifo);
+if (q->input_fifo)
+av_fifo_reset(q->input_fifo);
 }
 
 int ff_qsv_decode_close(QSVContext *q)
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH] lavc/ffjni: replace ff_jni_{attach, detach} with ff_jni_get_env

2016-07-27 Thread Matthieu Bouron 
On Tue, Jul 26, 2016 at 09:38:28AM +0200, Matthieu Bouron wrote:
> On Mon, Jul 25, 2016 at 09:50:58AM +0200, Benoit Fouet wrote:
> > Hi,
> 
> Hi,
> 
> > 
> > On 24/07/2016 23:05, Matthieu Bouron wrote:
> > > From: Matthieu Bouron
> > > 
> > > If a JNI environment is not already attached to the thread where the
> > > MediaCodec calls are made the current implementation will attach /
> > > detach an environment for each MediaCodec call wasting some CPU time.
> > > 
> > > ff_jni_get_env replaces ff_jni_{attach,detach} by permanently attaching
> > > an environment (if it is not already the case) to the current thread.
> > > The environment will be automatically detached at the thread destruction
> > > using a pthread_key callback.
> > > 
> > > Saves around 5% of CPU time (out of 20%) while decoding a stream with
> > > MediaCodec.
> > > ---
> > >   libavcodec/ffjni.c  |  43 +
> > >   libavcodec/ffjni.h  |  15 +--
> > 
> > LGTM
> 
> Thanks for the review. I will push the patch in a few hours.

Pushed. Thanks.

> 
> Matthieu
> 
> [...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-07-27 Thread Ronald S. Bultje 
Hi,

On Wed, Jul 27, 2016 at 7:20 AM, Michael Niedermayer  wrote:

> On Tue, Jul 26, 2016 at 07:30:14PM +, Davinder Singh wrote:
> > hi
> >
> > On Mon, Jul 25, 2016 at 9:55 PM Ronald S. Bultje 
> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer
> > >  > > > wrote:
> > >
> > > > On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > > > > https://github.com/dsmudhar/FFmpeg/commits/dev
> > >
> > >
> > > So, correct me if I'm wrong, but it seems the complete ME code
> currently
> > > lives inside the filter. I wonder if that is the best way forward. I
> > > thought the idea was to split out the ME code into its own module and
> share
> > > it between various filters and the relevant encoders without a strict
> > > dependency on avfilter/avcodec, or more specifically, AVCodecContext or
> > > anything like that?
> > >
> > > Ronald
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> > The code is almost ready to be shared, I just didn't move that yet. That
> > makes changes difficult. mInterpolate will use those functions (which are
> > currently in mEstimate) to find true motion. My plan is to move that code
> > out of mEstimate to say, libavfilter/motion_estimation.c and can be
> shared
> > between multiple filters. Since that is general ME, I think it can be
> used
> > with encoding (with some changes). So, should I move it to libavutil
> > instead?
>
> one thing thats important,
> independant of where its moved, the interface between libs is part
> of the public ABI of that lib and thus cannot be changed once it is
> added. That is new functions can be added but they
> cannot be removed nor their interface changed once added until the
> next major version bump (which might occur once a year)
>
> its important to keep this in mind when designing inter lib interfaces


You could - to address this - design it as if it lived in libavutil, but
(until it actually is used in libavcodec) keep it in libavfilter with a ff_
function prefix to ensure functions are not exported from the lib.

Once libavcodec uses it, move it to libavutil and change ff_ to av(priv?)_
prefix so it's exported.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-07-27 Thread Michael Niedermayer 
On Tue, Jul 26, 2016 at 07:30:14PM +, Davinder Singh wrote:
> hi
> 
> On Mon, Jul 25, 2016 at 9:55 PM Ronald S. Bultje  wrote:
> 
> > Hi,
> >
> > On Mon, Jul 25, 2016 at 5:39 AM, Michael Niedermayer
> >  > > wrote:
> >
> > > On Mon, Jul 25, 2016 at 04:05:54AM +, Davinder Singh wrote:
> > > > https://github.com/dsmudhar/FFmpeg/commits/dev
> >
> >
> > So, correct me if I'm wrong, but it seems the complete ME code currently
> > lives inside the filter. I wonder if that is the best way forward. I
> > thought the idea was to split out the ME code into its own module and share
> > it between various filters and the relevant encoders without a strict
> > dependency on avfilter/avcodec, or more specifically, AVCodecContext or
> > anything like that?
> >
> > Ronald
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> The code is almost ready to be shared, I just didn't move that yet. That
> makes changes difficult. mInterpolate will use those functions (which are
> currently in mEstimate) to find true motion. My plan is to move that code
> out of mEstimate to say, libavfilter/motion_estimation.c and can be shared
> between multiple filters. Since that is general ME, I think it can be used
> with encoding (with some changes). So, should I move it to libavutil
> instead?

one thing thats important,
independant of where its moved, the interface between libs is part
of the public ABI of that lib and thus cannot be changed once it is
added. That is new functions can be added but they
cannot be removed nor their interface changed once added until the
next major version bump (which might occur once a year)

its important to keep this in mind when designing inter lib interfaces

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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/alsdec: implement floating point decoding

2016-07-27 Thread Umair Khan 
On Wed, Jul 27, 2016 at 1:28 PM, Thilo Borgmann  wrote:
> Hi,
>
>>> [...]
 @@ -1678,6 +1931,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
  {
  unsigned int c;
  unsigned int channel_size;
 +unsigned int i;
  int num_buffers, ret;
  ALSDecContext *ctx = avctx->priv_data;
  ALSSpecificConfig *sconf = >sconf;
 @@ -1803,6 +2057,34 @@ static av_cold int decode_init(AVCodecContext 
 *avctx)
  ctx->raw_buffer   = av_mallocz_array(avctx->channels * 
 channel_size, sizeof(*ctx->raw_buffer));
  ctx->raw_samples  = av_malloc_array(avctx->channels, 
 sizeof(*ctx->raw_samples));

 +if (sconf->floating) {
 +ctx->acf   = av_malloc_array(avctx->channels, 
 sizeof(*ctx->acf));
 +ctx->shift_value   = av_malloc_array(avctx->channels, 
 sizeof(*ctx->shift_value));
 +ctx->last_shift_value  = av_malloc_array(avctx->channels, 
 sizeof(*ctx->last_shift_value));
 +ctx->last_acf_mantissa = av_malloc_array(avctx->channels, 
 sizeof(*ctx->last_acf_mantissa));
 +ctx->raw_mantissa  = av_malloc_array(avctx->channels, 
 sizeof(*ctx->raw_mantissa));
 +
 +for (c = 0; c < avctx->channels; ++c) {
 +ctx->raw_mantissa[c] = av_malloc_array(ctx->cur_frame_length, 
 sizeof(**ctx->raw_mantissa));
>>>
>>> using ctx->raw_mantissa without prior malloc failure check
>>
>> Should I keep this in a separate patch? It is unrelated to my patch.
>
> This is not unrelated to your patch. You're allocating ctx->raw_mantissa array
> and use the (maybe invalid) "allocated" array in the for loop. Test for a 
> valid
> pointer in ctx->raw_matissa before using it.

Oops. Sorry. I mistook it as raw_samples. I'll send another patch in a bit.

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

2016-07-27 Thread Thilo Borgmann 
Hi,

>> [...]
>>> @@ -1678,6 +1931,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>>  {
>>>  unsigned int c;
>>>  unsigned int channel_size;
>>> +unsigned int i;
>>>  int num_buffers, ret;
>>>  ALSDecContext *ctx = avctx->priv_data;
>>>  ALSSpecificConfig *sconf = >sconf;
>>> @@ -1803,6 +2057,34 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>>  ctx->raw_buffer   = av_mallocz_array(avctx->channels * 
>>> channel_size, sizeof(*ctx->raw_buffer));
>>>  ctx->raw_samples  = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->raw_samples));
>>>
>>> +if (sconf->floating) {
>>> +ctx->acf   = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->acf));
>>> +ctx->shift_value   = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->shift_value));
>>> +ctx->last_shift_value  = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->last_shift_value));
>>> +ctx->last_acf_mantissa = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->last_acf_mantissa));
>>> +ctx->raw_mantissa  = av_malloc_array(avctx->channels, 
>>> sizeof(*ctx->raw_mantissa));
>>> +
>>> +for (c = 0; c < avctx->channels; ++c) {
>>> +ctx->raw_mantissa[c] = av_malloc_array(ctx->cur_frame_length, 
>>> sizeof(**ctx->raw_mantissa));
>>
>> using ctx->raw_mantissa without prior malloc failure check
> 
> Should I keep this in a separate patch? It is unrelated to my patch.

This is not unrelated to your patch. You're allocating ctx->raw_mantissa array
and use the (maybe invalid) "allocated" array in the for loop. Test for a valid
pointer in ctx->raw_matissa before using it.

-Thilo

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

Re: [FFmpeg-devel] [PATCH 1/2] Add an OpenH264 decoder wrapper

2016-07-27 Thread Martin Storsjö 

On Tue, 26 Jul 2016, Michael Niedermayer wrote:


On Tue, Jul 26, 2016 at 09:31:17PM +0300, Martin Storsjö wrote:

This is cherrypicked from libav, from commits
82b7525173f20702a8cbc26ebedbf4b69b8fecec and
d0b1e6049b06ca146ece4d2f199c5dba1565.

---
Fixed the issues pointed out by Michael, removed the parts of the
commit message as requested by Carl.
---
 Changelog   |   1 +
 configure   |   2 +
 doc/general.texi|   9 +-
 libavcodec/Makefile |   3 +-
 libavcodec/allcodecs.c  |   2 +-
 libavcodec/libopenh264.c|  62 +++
 libavcodec/libopenh264.h|  39 +++
 libavcodec/libopenh264dec.c | 243 
 libavcodec/libopenh264enc.c |  48 ++---
 libavcodec/version.h|   2 +-
 10 files changed, 366 insertions(+), 45 deletions(-)
 create mode 100644 libavcodec/libopenh264.c
 create mode 100644 libavcodec/libopenh264.h
 create mode 100644 libavcodec/libopenh264dec.c


LGTM, please push, unless someone else has more comments

thanks


Pushed both.

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