[FFmpeg-devel] Feature request: "overlap" option for segment muxer?

2021-03-22 Thread Peter B. 

Hi everyone!

We're planning on using FFmpeg's segment muxer [1] to split radio 
recordings for archival preservation usage (*).


Works pretty well! (except for some warnings, but that's another issue).

Would it be possible to have a "segment_overlap" option, to add some 
time before/after each cut, so that the output segments overlap?




Thank you very much in advance,
Peter B.


(*) For example:
$ ffmpeg -i day1.ts -c copy -map 0 -copy_unknown -f segment 
-segment_time 3600 out/day1-%03d.ts


# Links:
[1] 
https://ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-ssegment



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Feature request: Segment using info from textfile?

2021-03-22 Thread Peter B. 

Hello everyone! :)

FFmpeg's segment muxer [1] is very useful and very configurable already, 
and I was wondering if it would be possible to add the possibility for 
splitting based on something like information given in an additional 
(text)file?


Each line of the textfile would contain the following information:
  * start-position
  * end-position
  * title

Creating a separate file for each start/end/title line.

We would need such a functionality for archival preservation of 
multi-content recordings.

This can be a paid request.



Thank you very much in advance,
Peter B.


# Links:
[1] 
https://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment

[2] https://en.wikipedia.org/wiki/Edit_decision_list
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer

2019-09-12 Thread Peter B. 
Hi :)

On 11/09/2019 17:57, Gyan wrote:
>
> On 11-09-2019 08:19 PM, Moritz Barsnick wrote:
>> The original user suggesting this muxer also requested a stream type
>> indicator. Is that info really useful and not redundant, assuming the
>> user will need to understand the implications of remuxing anyway?
>
> A bit of redundancy is useful for error-checking.

If I understand this correctly, does it mean that the order of streams
output by the streamhash muxer will be "in order of type" (video, audio,
etc), independent of the order in the source?

So 2 files (source/target) will have matching streamhash output order,
independent of their actual stream order inside their containers?


Since this streamhash is intended for content-validation and not
remux-validation, I would say the way it's now is great!



>>
>> If I add this, and don't make it optional, what should the format be?
>> Thus?:
>>
>> 0,v,SHA256=...
>> 1,a,SHA256=...
>> 2,s,SHA256=...
> Looks fine.

+1 from me, too :)

I guess with multiple A/V tracks it will then be like this?

0,v,SHA256=...
1,v,SHA256=...
2,a,SHA256=...
3,a,SHA256=...
4,a,SHA256=...
5,s,SHA256=...


Thank you very much,
Peter B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer

2019-09-19 Thread Peter B. 
btw: If you need anything to be tested, just let me know :)


Cheers!
Peter
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1enc: Use version 3 by default (CRCs by default)

2019-12-09 Thread Peter B. 

On 09/12/2019 17:27, Kieran O Leary wrote:
This was recently raised at the No Time To Wait conference in 
Budapest, so it would be great to see version three as the default!


Actually it was triggered by NTTW4.
(Thanks Michael for addressing this)


It should be noted though, that Michael also reminded me of "why it was 
v1 in the first place":


[quote]
"The default is the lowest version which supports all the user selected 
features.


Thats chosen so as to generate a file which is most widely supported.
(older bitstream versions work on older decoders, newer would only work 
on newer decoders)"

[/quote]


This should be known.
However, since I hardly see any reason to prefer v1 over v3 anymore, and 
considering that it's now the most widely one used, I'm happy to see it 
become default.



Any objections?


Kind regards,
Peter B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

2017-03-02 Thread Peter B. 
On 03/01/2017 03:00 PM, Jerome Martinez wrote:
> My suggestion:
> - support by the demuxer
> - for the muxer, support only if a specific explicit option is set,
> default stays AVI compatibility layer (no break in playback by old
> players).

This sounds like a very practical approach to me:
New files can be played, but one is not accidentially/surprisingly
creating incompatible files unless they explicitly choose to do so.
:)


Regards,
Pb

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-09 Thread Peter B. 
On 08/08/2014 09:22 PM, Matthias Urlichs wrote:
> We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
> hate to report some intractable codec bug which Upstream closes with
> an "it works with FFmpeg" comment

Oh, btw, just a few days ago, that's exactly what happened on kdenlive [1].
A developer posted the following statement on an issue which is open for
more than 1.5 years now:

[quote]
Confirm this is a libav problem, use builds with ffmpeg or wait debian
(&derivatives) to bring ffmpeg back
[/quote]

Just thought this might fit here...


Regards,
Pb


== References:
[1] http://www.kdenlive.org/mantis/view.php?id=2943#c10195
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-20 Thread Peter B. 
On 08/19/2014 12:45 PM, Clément Bœsch wrote:
> See:
> http://fate.ffmpeg.org/
> http://coverage.ffmpeg.org/

The 2nd link to "coverage" (which should show the LCOV output, I guess)
seems to be broken:
I get a "404 Not Found" :(

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

Re: [FFmpeg-devel] Please help update tasks and mentor/backups for OPW

2014-09-25 Thread Peter B. 
On 09/25/2014 10:54 PM, Carl Eugen Hoyos wrote:
> The FFv1 P frame project sounds very difficult.

I just read the description of this [1].

I was surprised to see this, because currently FFV1 already supports
GOPs > 1, and according to my tests [2], FFV1.3 already is faster *and*
smaller than h264-lossless :)


Regards,
Pb


== References:
[1]
https://trac.ffmpeg.org/wiki/SponsoringPrograms/OPW/2014-12#FFv1Pframesupport
[2]
http://download.das-werkstatt.com/pb/mthk/info/video/comparison_video_codecs_containers.html#codec_tests
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?

2022-10-25 Thread Peter B. 

Hi everyone :)

This is merely a question of interest. Not a request, complaint or 
trolling of any kind :)

I'm happy about any answer. I'm curious.

Would it possibly have a significant impact on coding speed of FFV1's 
slicecrc option (Where a CRC is calculated for each frame slice), to use 
a faster algorithm instead (if one exists)?

I'm wondering if, for example something like "xxHash" may warrant a try?
(Haven't found CRC vs xxHash benchmarks yet, but I'm still looking)



Anyhow,
Thanks for any of your time :D





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?

2022-11-08 Thread Peter B. 

Thanks for all your replies!

Now I can refer to this, when being asked "Why CRC and not ...?" :)



Kind regards,
Peter
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] hashing audio streams beyond pcm_s16le

2022-11-18 Thread Peter B. 

Hello everyone :)

I was wondering about the behavior of FFmpeg's hashing muxer for audio 
streams:


For example:
With a 32bit float (f32le) source, FFmpeg seems to be able to generate a 
hash for the f32le source - but only if I explicitly know (and then 
tell) FFmpeg to do so.

By default, I get the hash of a pcm_s16le version (see examples below).

I remember it defaults to "pcm_s16le" (also mentioned in 
https://trac.ffmpeg.org/wiki/framemd5%20Intro%20and%20HowTo), but why is 
that so?


And would it be possible to generate the hash of the source audio, 
without having to know what raw/uncompressed type it is?
I would like to be able to use the hash to compare lossless conversion 
of the content between different audio formats (eg vs FLAC and PCM).




Thank you very much in advance :)
Peter B.



Example:

# pcm_f32le defaults to pcm_s16le hash:
$ ffmpeg-git -loglevel quiet -i drums3.wav -f streamhash -hash md5 -
0,a,MD5=08170d6e02fbccc07b61fbf1d7476057

# ...as shown here:
$ ffmpeg-git -loglevel quiet -i drums3.wav -c:a pcm_s16le -f streamhash 
-hash md5 -

0,a,MD5=08170d6e02fbccc07b61fbf1d7476057

#
$ ffmpeg-git -loglevel quiet -i drums3.wav -c:a pcm_f32le -f streamhash 
-hash md5 -

0,a,MD5=1444cdc20cb8ea30874114cb53729797

$ ffmpeg-git -loglevel quiet -i drums3.wav -c:a copy -f streamhash -hash 
md5 -

0,a,MD5=1444cdc20cb8ea30874114cb53729797



$ ffmpeg-git -i drums3.wav -hash md5 -

ffmpeg version N-109029-g1800a0da09 Copyright (c) 2000-2022 the FFmpeg 
developers

  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree 
--enable-version3 --enable-postproc --enable-ffplay --enable-swscale 
--enable-avfilter --enable-pthreads --enable-bzlib --enable-zlib 
--enable-decoder=png --enable-encoder=png --enable-openssl 
--samples=../fate-suite --enable-libfreetype --enable-libopenjpeg 
--disable-decoder=jpeg2000 --enable-libvpx --enable-libvorbis 
--enable-libx264 --enable-libx265

  libavutil  57. 42.100 / 57. 42.100
  libavcodec 59. 52.100 / 59. 52.100
  libavformat    59. 34.101 / 59. 34.101
  libavdevice    59.  8.101 / 59.  8.101
  libavfilter 8. 50.100 /  8. 50.100
  libswscale  6.  8.112 /  6.  8.112
  libswresample   4.  9.100 /  4.  9.100
  libpostproc    56.  7.100 / 56.  7.100
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, wav, from 'drums3.wav':
  Duration: 00:00:54.25, bitrate: 1536 kb/s
  Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, 1 
channels, flt, 1536 kb/s





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Matroska and PCM variants, error in encoding?

2015-08-04 Thread Peter B. 
On 08/03/2015 01:50 PM, Ronald S. Bultje wrote:
> Just different offsets and ranges. Unsigned, n bits (e.g. u8) is in the
> range [0,2^^n> (e.g. for u8, the range is [0,255] or [0,256>), where
> silence is 2^^n-1, e.g. 0x80 (128) for u8. Signed is in the range
> [-2^^n-1,2^^n-1> (e.g. s16, the most typical variant, is [-32768,32767].
> Float is in the range [-1.0, 1.0]. In both cases, 0, is silence.
>
> We have various formats so we can represent exactly what's in a file or
> output by any one particular decoder without having to convert the internal
> representation into some intermediate format.

Thanks for that detailed explanation.

I've never used DPCM with FFmpeg, but after Andreas' question I looked
it up, and found some documentation, and wanted to clear things up.

Am I correct with the following conclusion:

- acodec "pcm_*" is always linear PCM [1]
- DPCM would be prefixed with "adpcm_*" (and some exceptions, like
"interplay_dpcm", etc [2])


Thanks in advance,
Pb


== References:
[1] https://trac.ffmpeg.org/wiki/audio%20types
[2] http://ffmpeg.org/doxygen/trunk/dpcm_8c.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Adding FATE tests for FFV1 - revisited

2015-08-30 Thread Peter B. 
Hello,

I've been working on FATE tests for FFV1 in the past already [1]. My
tests didn't work on all platforms and therefore never made it upstream.
I think it's better if I try to provide these new tests in smaller
chunks now :)


First of all, there are things I find inconsistent or confusing with the
current tests (vcodec.mak):

- ENCOPTS for FFV1.3 contain "-vcodec ffv1" instead of "CODEC=ffv1"
(this generates "-c ffv1.3" as parameter?)
- Target "fate-vsynth%-*" tests default to sws_flags
"accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
- ENCOPTS for "fate-vsynth%-ffv1" are "-slices 4", which is an
FFV1.3-only option.
- What is "ffv1.0"?


My ideas/plans would be something like this:

First steps:
1) Clean the current FFV1 tests (naming, ENCDEC options, etc)
2) Move FFV1 tests to its own file (ffv1.mak). Or at least to
"lossless-video.mak".
3) Have separate tests for different FFV1 versions (1,3)

Then:
4) Add default argument "-g 1"
5) Add tests to cover the following cases:
- Color spaces YUV, RGB, GRAY
- bits-per-component as currently supported
- YUV subsampling 420, 422, 444
- Alpha channel: YUVA, BGRA

Maybe:
6) Multiple coder/context options
7) Multiple slices options
8) Testing SliceCRC


This will produce quite a number of tests :(
I guess it is desired to keep the number of tests as low as necessary?
I've attached my old test Makefile (ffv1.mak), for reference.
:D


What is the best way to proceed?



Thanks in advance,
Pb



== References:
[1] http://ffmpeg.org/pipermail/ffmpeg-user/2013-November/018361.html
DEC_SRC = $(TARGET_PATH)/tests/data/fate

# Word-size options for PSNR calculations: u8, s16, f32, f64
# Default is "u8" (8bits):
fate-ffv1-enc-%: CMP_UNIT = u8

fate-ffv1-enc-%: CODEC = $(word 2, $(subst -, ,$(@)))
fate-ffv1-enc-%: FMT = avi
fate-ffv1-enc-%: SRC = tests/data/vsynth1.yuv
# Limit the duration of test videos to 4 frames at 25fps:
fate-ffv1-enc-%: DUR = 0:00:00.160
fate-ffv1-enc-%: CMD = enc_dec "rawvideo -s 352x288 -pix_fmt yuv420p 
$(RAWDECOPTS) -t $(DUR)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-s 
352x288 -pix_fmt yuv420p -vsync 0 $(DECOPTS)" -keep "$(DECINOPTS)"

# This Makefile checks for $(CONFIG_...) variables being set, so we can
# include/exclude tests accordingly:
ifdef CONFIG_AVCONV
FLAGS_FFV1_V3 = -strict experimental
else
FLAGS_FFV1_V3 =
endif

FATE_FFV1_LEVEL1 = v1-defaults \
   v1-gray \
   v1-rgb32\
   v1-yuv410p  \
   v1-yuv411p  \
   v1-yuv420p  \
   v1-yuv422p  \
   v1-yuv444p  \
   v1-bgra \
   v1-tff  \
   v1-bff

# Target-specific tests:
ifdef CONFIG_FFMPEG
FATE_FFV1_LEVEL1 +=v1-bgr0 \
   v1-yuv440p  \
   v1-yuva420p \
   v1-yuva422p \
   v1-yuva444p
endif

FATE_FFV1_LEVEL3 = v3-defaults  \
   v3-rgb32 \
   v3-yuv410p   \
   v3-yuv420p   \
   v3-yuv422p   \
   v3-yuv444p   \
   v3-yuv420p9  \
   v3-yuv422p9  \
   v3-yuv444p9  \
   v3-yuv420p10 \
   v3-yuv422p10 \
   v3-yuv444p10 \
   v3-yuv420p16 \
   v3-yuv422p16 \
   v3-yuv444p16 \
   v3-yuv422p_crc   \
   v3-yuv422p9_crc  \
   v3-yuv422p10_crc \
   v3-yuv422p16_crc \
   v3-yuv422p_pass1 \
   v3-yuv422p_pass2 \
   v3-tff   \
   v3-bff

# Target-specific tests:
ifdef CONFIG_FFMPEG
FATE_FFV1_LEVEL3 +=v3-gray   \
   v3-gray16 \
   v3-bgr0   \
   v3-gbrp9  \
   v3-gbrp10 \
   v3-gbrp12 \
   v3-gbrp14 \
   v3-yuva420p9  \
   v3-yuva422p9  \
   v3-yuva444p9  \
   v3-yuva420p10 \
   v3-yuva422p10 \
   v3-yuva444p10 \
   v3-yuva420p16 \
   v3-yuva422p16 \
   v3-yuva444p16
endif


FATE_FFV1 = $(FATE_FFV1_LEVEL1) \
$(FATE_FFV1_LEVEL3)


#  FFV1 - version 1
###
#  Encoding:
###
#  YUV (8bit)
#  - This also iterates through all coder/context combinations.
fate-ffv1-enc-v1-defaults:   ENCOPTS = -

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

2015-08-30 Thread Peter B. 
On 08/30/2015 07:33 PM, Paul B Mahol wrote:
> On 8/30/15, Peter B.  wrote:
>> This will produce quite a number of tests :(
>> I guess it is desired to keep the number of tests as low as necessary?
> Not at all. Just look at ffv1 coverage at coverage.ffmpeg.org

:)
I'd love to add tests for FFV1 to increase the coverage as much as possible.

So, in order to avoid silent regressions in less-common combinations,
I've added very detailed test-scenarios (as shown in my "ffv1.mak")
previously.
Except for a few other codecs (e.g. h264), most only have a handful of
tests. So I thought my suggested test-suite was overkill.

I'd like to keep the tests as much as necessary, but as little as possible.


Regards,
Pb



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

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

2015-08-30 Thread Peter B. 
On 08/30/2015 09:32 PM, Michael Niedermayer wrote:
>> - Target "fate-vsynth%-*" tests default to sws_flags
>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
> it makes more cases lossless IIRC
> the default upscaling + default downscaling is not binary identical

Roger that.

The way I understand the tests "lossless-video.mak", they operate
differently than the ones in "vcodec.mak".
I'd like to use that method (using framecrc) for FFV1 tests.
Yet, all of them seem to require a specific sample in fate-suite.

What's the proper way of using vsynth samples for that?

My approach in the past was something like this:
// ---
fate-ffv1-enc-%: FMT = avi
fate-ffv1-enc-%: SRC = tests/data/vsynth1.yuv
# Limit the duration of test videos to 4 frames at 25fps:
fate-ffv1-enc-%: DUR = 0:00:00.160
fate-ffv1-enc-%: CMD = enc_dec "rawvideo -s 352x288 -pix_fmt yuv420p
$(RAWDECOPTS) -t $(DUR)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo
"-s 352x288 -pix_fmt yuv420p -vsync 0 $(DECOPTS)" -keep "$(DECINOPTS)"
// ---

That only uses vsynth1.yuv :(


>> I guess it is desired to keep the number of tests as low as necessary?
> avoiding redundant tests would be a good idea

:)
Will try my best.


>> I've attached my old test Makefile (ffv1.mak), for reference.
>> :D
>>
>>
>> What is the best way to proceed?
> probably, send patches
> and probably better few and small ones at once then wait and see
> in which direction reviewes go before spending too much time in some
> specific direction

Will do that.
Currently starting with tidying up the existing tests.


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

[FFmpeg-devel] Clean/reset FATE test data?

2015-08-30 Thread Peter B. 
Hello,

I've read the documentation on FATE tests, and would like to add new ones.
How can I reset the FATE test data for certain targets, without having
to re-run the whole test suite?


Thank in advance,
Pb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

2015-08-30 Thread Peter B. 
Hi.

I've now cleaned up a few things in the current FFV1 tests:
- Changed "ffv1.X" to "ffv1-vX", removing necessity for vcodec argument.
- Added linebreaks to FFV1 FATE tests for better readability.
- Renamed pix_fmts wording in test target name to match pix_fmt parameter.

Replaced the reference files accordingly, and ran "make fate" to verify
that they still run properly.


What do you think?

Pb


>From be1b2ee092a82fdf70ccb99eb20d70e228205182 Mon Sep 17 00:00:00 2001
From: Peter B. 
Date: Mon, 31 Aug 2015 03:02:36 +0200
Subject: [PATCH] Renamed pix_fmts wording in test target name to match
 pix_fmt parameter.

---
 tests/fate/vcodec.mak  |   20 +++-
 tests/ref/vsynth/vsynth1-ffv1-v0   |4 
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |4 
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |4 
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 
 tests/ref/vsynth/vsynth1-ffv1.0|4 
 tests/ref/vsynth/vsynth1-ffv1.3-420|4 
 tests/ref/vsynth/vsynth1-ffv1.3-422p10 |4 
 tests/ref/vsynth/vsynth1-ffv1.3-444p16 |4 
 tests/ref/vsynth/vsynth1-ffv1.3-bgr|4 
 tests/ref/vsynth/vsynth2-ffv1-v0   |4 
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |4 
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |4 
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 
 tests/ref/vsynth/vsynth2-ffv1.0|4 
 tests/ref/vsynth/vsynth2-ffv1.3-420|4 
 tests/ref/vsynth/vsynth2-ffv1.3-422p10 |4 
 tests/ref/vsynth/vsynth2-ffv1.3-444p16 |4 
 tests/ref/vsynth/vsynth2-ffv1.3-bgr|4 
 tests/ref/vsynth/vsynth3-ffv1-v0   |4 
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |4 
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |4 
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 
 tests/ref/vsynth/vsynth3-ffv1.0|4 
 tests/ref/vsynth/vsynth3-ffv1.3-420|4 
 tests/ref/vsynth/vsynth3-ffv1.3-422p10 |4 
 tests/ref/vsynth/vsynth3-ffv1.3-444p16 |4 
 tests/ref/vsynth/vsynth3-ffv1.3-bgr|4 
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |4 
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |4 
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |4 
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |4 
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |4 
 tests/ref/vsynth/vsynth_lena-ffv1.0|4 
 tests/ref/vsynth/vsynth_lena-ffv1.3-420|4 
 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 |4 
 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 |4 
 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr|4 
 42 files changed, 95 insertions(+), 89 deletions(-)
 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v0
 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0
 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p
 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10
 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-420
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-422p10
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-444p16
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-bgr
 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v0
 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0
 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p
 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10
 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-420
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-422p10
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-444p16
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-bgr
 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v0
 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0
 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p
 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10
 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.0
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-420
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-422p10
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-444p16
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-bg

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

2015-08-31 Thread Peter B. 


Am Mo, 31.08.2015, 08:31 schrieb Carl Eugen Hoyos:
> Peter B.  das-werkstatt.com> writes:
>
>> Replaced the reference files accordingly
>
> This cannot be done, we want to run fate (also)
> with old sources.

Hm. Now I'm confused...
I expected old sources to use old tests?

In my case, there are files in "tests/ref/vsynth" that contain the
expected reference results from tests.

If I only provide the changed the FATE makefiles, like "vcodec.mak", who
generates (and validates) the initial reference files?


Thanks,
Pb

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

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

2015-08-31 Thread Peter B. 
Am Mo, 31.08.2015, 11:22 schrieb Hendrik Leppkes:
> On Mon, Aug 31, 2015 at 11:13 AM, Peter B.  wrote:
>>
>> In my case, there are files in "tests/ref/vsynth" that contain the
>> expected reference results from tests.
>>
>> If I only provide the changed the FATE makefiles, like "vcodec.mak", who
>> generates (and validates) the initial reference files?
>>
>
> The references inside the Git tree can be changed just fine if a
> change in the tests warrants it.
> What should not be changed is the samples inside the FATE suite - if a
> change is needed, there should be a new sample with a new name - which
> is probably what Carl refers to.
>
> But since these seem to be vsynth tests, no external samples from the
> FATE suite are actually affected, are  they?

That makes perfect sense now.

The current FFV1 tests only use vsynth*. No external samples.

The reference files in "tests/ref/vsynth" had to be changed, because the
tests were renamed, so the filenames inside the reference textfiles
changed.

So, it is correct if my patch includes "tests/ref/*" in the future?


Regards,
Pb



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

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

2015-08-31 Thread Peter B. 
On 08/31/2015 01:44 PM, Tobias Rapp wrote:
> On 30.08.2015 21:32, Michael Niedermayer wrote:
>>>  - Target "fate-vsynth%-*" tests default to sws_flags
>>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
>>
>> it makes more cases lossless IIRC
>> the default upscaling + default downscaling is not binary identical
>
> Indeed. See
> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174430.html and
> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174447.html for
> reference.

All clear now.
Thanks :)

You also mentioned the stddev not being 0 for RGB. I've also noticed
that yesterday.
In my previous FFV1 tests, I'm using the file generated by ENC,
therefore the pix_fmt of input/output matches and so the framecrc is
happy :)

// --
fate-ffv1-enc-v3-bgr0:   ENCOPTS = -level 3 -g 1 -coder 0
-context 0 -slices 24 -slicecrc 0 -pix_fmt bgr0 $(FLAGS_FFV1_V3)
fate-ffv1-dec-v3-bgr0:   $(CMD = framecrc -i
$(DEC_SRC)/ffv1-enc-v3-bgr0.avi) fate-ffv1-enc-v3-bgr0
// --

Would that be okay?


>>> 4) Add default argument "-g 1"
>
> This removes the test for the default GOP size.

True.
Will keep that in mind.


> I agree that having a full test suite for FFV1 would be a nice thing
> but am not sure if integration into FATE is the right framework for
> it. As far as I understand FATE tests need a good balance between
> processing time and code coverage.

I also understood it that way.
Wouldn't want to overdo it.
I'm not completely sure which things should definitely be tested in
order to avoid regressions in not-so-common cases?
What I've done previously is, to vary the coder/context/slices
parameters for different pix_fmts. So the pix_fmts are tested, but at
the same time coder/context/slices variations, too.

I've added that since we've seen bugs with e.g. certain slice numbers
during FFV1.3 development testing.


>
> Maybe it can be part of the IETF standardization task to create a FFV1
> test environment which tests every
> color-space/bit-depth/subsampling/... combination?

Definitely a good idea.
However, it still doesn't serve the purpose of being a FATE test to
avoid regressions.
Additionally, I'm also planning to submit the final FFV1 tests to LibAV,
so that LibAV stays compatible with changes/improvements implemented in
FFmpeg.


Regards,
Pb

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

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

2015-09-01 Thread Peter B. 
On 08/30/2015 09:32 PM, Michael Niedermayer wrote:
> probably, send patches
> and probably better few and small ones at once then wait and see
> in which direction reviewes go before spending too much time in some
> specific direction

For starters, I'd like to extract the FATE tests for FFV1 to its own
file: "tests/fate/ffv1.mak"
In order to keep the individual changes (=individual patches) minimal,
I've done the following:

1) Move existing FFV1 targets from "vcodec.mak" to "ffv1.mak".
2) Add "include tests/fate/ffv1.mak" in vcodec.mak where the targets
were previously.

Works.

But actually, I think it'd be best to change the FFV1 tests to match the
ones in "lossless-video.mak", using framecrc rather than the enc_dec
function used in "vcodec.mak".

Changing that however, makes it difficult to stick with the
auto-generated fate-vsynth% targets.
So I'd actually be doing a major rewrite of the existing tests - even
just keeping the ones that already exists.

What is your suggestion?


Thanks,
Pb

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

Re: [FFmpeg-devel] [PATCH 1/2] Extract FFV1 FATE tests to own Makefile

2015-09-01 Thread Peter B. 
On 09/01/2015 09:54 PM, Peter B. wrote:
> [...]
> But actually, I think it'd be best to change the FFV1 tests to match the
> ones in "lossless-video.mak", using framecrc rather than the enc_dec
> function used in "vcodec.mak".
>
> Changing that however, makes it difficult to stick with the
> auto-generated fate-vsynth% targets.
> So I'd actually be doing a major rewrite of the existing tests - even
> just keeping the ones that already exists.
>
> What is your suggestion?

Thought I'd give it a try already :)

The attached patch extracts the FFV1 tests to ffv1.mak, and includes the
Makefile in vcodec.mak.
Tests themselves stay as-is.

Regards,
Pb
>From 23bd1397b2aa68541bad334f868d968b79c24bf5 Mon Sep 17 00:00:00 2001
From: Peter B. 
Date: Tue, 1 Sep 2015 21:55:35 +0200
Subject: [PATCH 1/2] Moved FFV1 FATE tests to own file.

---
 tests/fate/ffv1.mak   |   16 
 tests/fate/vcodec.mak |   16 +---
 2 files changed, 17 insertions(+), 15 deletions(-)
 create mode 100644 tests/fate/ffv1.mak

diff --git a/tests/fate/ffv1.mak b/tests/fate/ffv1.mak
new file mode 100644
index 000..f9f2261
--- /dev/null
+++ b/tests/fate/ffv1.mak
@@ -0,0 +1,16 @@
+FATE_VCODEC-$(call ENCDEC, FFV1, AVI)   += ffv1 ffv1-v0 \
+   ffv1-v3-yuv420p ffv1-v3-yuv422p10 ffv1-v3-yuv444p16 \
+   ffv1-v3-bgr0
+fate-vsynth%-ffv1:   ENCOPTS = -slices 4
+fate-vsynth%-ffv1-v0:CODEC   = ffv1
+fate-vsynth%-ffv1-v3-yuv420p:ENCOPTS = -level 3 -pix_fmt yuv420p
+fate-vsynth%-ffv1-v3-yuv422p10:  ENCOPTS = -level 3 -pix_fmt yuv422p10 \
+   -sws_flags neighbor+bitexact
+fate-vsynth%-ffv1-v3-yuv422p10:  DECOPTS = -sws_flags neighbor+bitexact
+fate-vsynth%-ffv1-v3-yuv444p16:  ENCOPTS = -level 3 -pix_fmt yuv444p16 \
+   -sws_flags neighbor+bitexact
+fate-vsynth%-ffv1-v3-yuv444p16:  DECOPTS = -sws_flags neighbor+bitexact
+fate-vsynth%-ffv1-v3-bgr0:   ENCOPTS = -level 3 -pix_fmt bgr0 \
+   -sws_flags neighbor+bitexact
+fate-vsynth%-ffv1-v3-bgr0:   DECOPTS = -sws_flags neighbor+bitexact
+
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index 310352e..aa2f07b 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -68,21 +68,7 @@ fate-vsynth%-dv-50:  ENCOPTS = -dct int -s pal -pix_fmt yuv422p \
 fate-vsynth%-dv-50:  DECOPTS = -sws_flags neighbor
 fate-vsynth%-dv-50:  FMT = dv
 
-FATE_VCODEC-$(call ENCDEC, FFV1, AVI)   += ffv1 ffv1-v0 \
-   ffv1-v3-yuv420p ffv1-v3-yuv422p10 ffv1-v3-yuv444p16 \
-   ffv1-v3-bgr0
-fate-vsynth%-ffv1:   ENCOPTS = -slices 4
-fate-vsynth%-ffv1-v0:CODEC   = ffv1
-fate-vsynth%-ffv1-v3-yuv420p:ENCOPTS = -level 3 -pix_fmt yuv420p
-fate-vsynth%-ffv1-v3-yuv422p10:  ENCOPTS = -level 3 -pix_fmt yuv422p10 \
-   -sws_flags neighbor+bitexact
-fate-vsynth%-ffv1-v3-yuv422p10:  DECOPTS = -sws_flags neighbor+bitexact
-fate-vsynth%-ffv1-v3-yuv444p16:  ENCOPTS = -level 3 -pix_fmt yuv444p16 \
-   -sws_flags neighbor+bitexact
-fate-vsynth%-ffv1-v3-yuv444p16:  DECOPTS = -sws_flags neighbor+bitexact
-fate-vsynth%-ffv1-v3-bgr0:   ENCOPTS = -level 3 -pix_fmt bgr0 \
-   -sws_flags neighbor+bitexact
-fate-vsynth%-ffv1-v3-bgr0:   DECOPTS = -sws_flags neighbor+bitexact
+include tests/fate/ffv1.mak
 
 FATE_VCODEC-$(call ENCDEC, FFVHUFF, AVI) += ffvhuff ffvhuff444 ffvhuff420p12 ffvhuff422p10left ffvhuff444p16
 fate-vsynth%-ffvhuff444: ENCOPTS = -vcodec ffvhuff -pix_fmt yuv444p
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/2] Changed FFV1 tests to work independet of vcodec.mak

2015-09-01 Thread Peter B. 
This patch makes ffv1.mak work without requiring (or being included in)
vcodec.mak.
That's another step towards having a better environment for additional
FFV1 tests.

Regards,
Pb
>From 593f1551b999fbb4c4a378d0723c2140e3b469df Mon Sep 17 00:00:00 2001
From: Peter B. 
Date: Tue, 1 Sep 2015 23:00:48 +0200
Subject: [PATCH 2/2] Changed FFV1 FATE tests to work independent of
 vcodec.mak

---
 tests/Makefile |1 +
 tests/fate/ffv1.mak|   56 +++-
 tests/fate/vcodec.mak  |2 -
 tests/ref/fate/ffv1-v0-defaults-vsynth1|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth2|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth1|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth2|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth1 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth2 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena   |4 ++
 tests/ref/vsynth/vsynth1-ffv1  |4 --
 tests/ref/vsynth/vsynth1-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth2-ffv1  |4 --
 tests/ref/vsynth/vsynth2-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth3-ffv1  |4 --
 tests/ref/vsynth/vsynth3-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1  |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |4 --
 43 files changed, 105 insertions(+), 114 deletions(-)
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth_lena-ffv1
 delete mode 100644 t

Re: [FFmpeg-devel] [PATCH 1/2] Extract FFV1 FATE tests to own Makefile

2015-09-01 Thread Peter B. 
On 09/01/2015 11:40 PM, Michael Niedermayer wrote:
>> +include tests/fate/ffv1.mak
> doesnt this belong in tests/Makefile ?

I did so first, but then all the prerequisites set in vcodec.mak are not
applied, causing ffv1.mak to fail.
So in order to keep the modifications as little as possible, I just
included it where it previously was.

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

Re: [FFmpeg-devel] [PATCH 2/2] Changed FFV1 tests to work independet of vcodec.mak

2015-09-01 Thread Peter B. 
Previous patch worked with "make fate", but fails to build FFmpeg after
"make clean".
I've had to do fix some unclean parts of ffv1.mak.
Patch attached.

Now everything seems to be fine again.

Regards,
Pb
>From bb0b1dd72dd334d6621221e3c55d53f8cc0485b8 Mon Sep 17 00:00:00 2001
From: Peter B 
Date: Wed, 2 Sep 2015 00:32:33 +0200
Subject: [PATCH 29/29] Fixed Makefile errors for FFV1 FATE tests

---
 tests/fate/ffv1.mak |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tests/fate/ffv1.mak b/tests/fate/ffv1.mak
index 4062955..91c4a48 100644
--- a/tests/fate/ffv1.mak
+++ b/tests/fate/ffv1.mak
@@ -5,6 +5,7 @@ fate-ffv1-%: CMP_UNIT = u8
 fate-ffv1-%: CODEC = ffv1
 fate-ffv1-%: FMT = avi
 
+# Requires generating vsynth files as input source:
 fate-ffv1-%-vsynth1: SRC = tests/data/vsynth1.yuv
 fate-ffv1-%-vsynth2: SRC = tests/data/vsynth2.yuv
 fate-ffv1-%-vsynth_lena: SRC = tests/data/vsynth_lena.yuv
@@ -35,14 +36,14 @@ FATE_FFV1_VSYNTH1 := $(FATE_FFV1:%=%-vsynth1)
 FATE_FFV1_VSYNTH2 := $(FATE_FFV1:%=%-vsynth2)
 FATE_FFV1_VSYNTH_LENA := $(FATE_FFV1:%=%-vsynth_lena)
 
-FATE_FFV1-$(call ENCDEC, FFV1, AVI) += $(FATE_FFV1_VSYNTH1) $(FATE_FFV1_VSYNTH2) $(FATE_FFV1_VSYNTH_LENA)
+$(FATE_FFV1_VSYNTH1): tests/data/vsynth1.yuv
+$(FATE_FFV1_VSYNTH2): tests/data/vsynth2.yuv
+$(FATE_FFV1_VSYNTH_LENA): tests/data/vsynth_lena.yuv
+
+FATE_FFV1-$(call ENCDEC, FFV1, AVI) = $(FATE_FFV1_VSYNTH1) $(FATE_FFV1_VSYNTH2) $(FATE_FFV1_VSYNTH_LENA)
 FATE_SAMPLES_FFMPEG += $(FATE_FFV1-yes)
 
 
 fate-ffv1: $(FATE_FFV1-yes)
 
-# Requires generating vsynth*.yuv as input source:
-$(FATE_FFV1-yes) += tests/data/vsynth1.yuv \
-tests/data/vsynth2.yuv \
-tests/data/vsynth_lena.yuv
 
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 1/2] Extract FFV1 FATE tests to own Makefile

2015-09-02 Thread Peter B. 
On 09/02/2015 02:53 PM, Michael Niedermayer wrote:
> the include breaks out of tree builds
> mkdir delthisdir
> cd delthisdir
> ../configure
> make -j12
> /home/michael/ffmpeg/tests/fate/vcodec.mak:71: tests/fate/ffv1.mak: No such 
> file or directory
> make: *** No rule to make target `tests/fate/ffv1.mak'.  Stop.

The "include" was just an idea to have an intermediate step before
making ffv1.mak independent of vcodec.mak. So it wouldn't make much
sense to try "fixing" that step.
Maybe the easiest way would be combine my 2 changes into 1 and I just
submit ONE patch?

Because the current version seems clean.


Pb



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

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, independent of vcodec.mak

2015-09-03 Thread Peter B. 
I've now combined my changes into one patch.
They're basically moving ffv1 tests to ffv1.mak, and making that
independent of vcodec.mak.

Hope it works now :)


Thanks and regards,
Pb
>From 5ba0e0510269e0ee591a9505fcb4654044002743 Mon Sep 17 00:00:00 2001
From: Peter B. 
Date: Tue, 1 Sep 2015 21:55:35 +0200
Subject: [PATCH 2/2] Moved FFV1 FATE tests to own file, making it independent
 of vcodec.mak

---
 tests/Makefile |1 +
 tests/fate/ffv1.mak|   49 
 tests/fate/vcodec.mak  |   16 
 tests/ref/fate/ffv1-v0-defaults-vsynth1|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth2|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth1|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth2|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth1 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth2 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena   |4 ++
 tests/ref/vsynth/vsynth1-ffv1  |4 --
 tests/ref/vsynth/vsynth1-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth2-ffv1  |4 --
 tests/ref/vsynth/vsynth2-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth3-ffv1  |4 --
 tests/ref/vsynth/vsynth3-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1  |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |4 --
 43 files changed, 110 insertions(+), 116 deletions(-)
 create mode 100644 tests/fate/ffv1.mak
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16
 delet

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, independent of vcodec.mak

2015-09-07 Thread Peter B. 
On 09/07/2015 09:14 PM, Michael Niedermayer wrote:
> On Thu, Sep 03, 2015 at 10:14:13PM +0200, Peter B. wrote:
>> I've now combined my changes into one patch.
>> They're basically moving ffv1 tests to ffv1.mak, and making that
>> independent of vcodec.mak.
>>
>> Hope it works now :)
> doesnt work
> make fate ends in
> make: *** No rule to make target `fate-vsynth_lena-ffv1', needed by 
> `fate-seek-vsynth_lena-ffv1'.  Stop.
> make: *** Waiting for unfinished jobs

Darn.
Overlooked the depency in "tests/fate/seek.mak".

Should be fixed.
(Getting errors with "make fate" for some fate-dxv*, with git HEAD but
that seems unrelated to my changes)


Regards,
Pb

>From 249e935516c344617850fa8b23751e60879d13c5 Mon Sep 17 00:00:00 2001
From: Peter B 
Date: Mon, 7 Sep 2015 23:11:37 +0200
Subject: [PATCH 2/2] - Extract FFV1 FATE tests to own Makefile.

---
 tests/Makefile |1 +
 tests/fate/ffv1.mak|   49 
 tests/fate/vcodec.mak  |   17 +---
 tests/ref/fate/ffv1-v0-defaults-vsynth1|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth2|4 ++
 tests/ref/fate/ffv1-v0-defaults-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth1|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth2|4 ++
 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena|4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth1 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth2 |4 ++
 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2   |4 ++
 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena   |4 ++
 tests/ref/seek/vsynth_lena-ffv1|   40 +--
 tests/ref/vsynth/vsynth1-ffv1  |4 +-
 tests/ref/vsynth/vsynth1-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth2-ffv1  |4 +-
 tests/ref/vsynth/vsynth2-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth3-ffv1  |4 +-
 tests/ref/vsynth/vsynth3-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1  |4 +-
 tests/ref/vsynth/vsynth_lena-ffv1-v0   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0  |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p   |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |4 --
 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |4 --
 44 files changed, 140 insertions(+), 127 deletions(-)
 create mode 100644 tests/fate/ffv1.mak
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v0-defaults-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-bgr0-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv420p-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv422p10-vsynth_lena
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth1
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth2
 create mode 100644 tests/ref/fate/ffv1-v3-yuv444p16-vsynth_lena
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10
 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v0
 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0
 delete mode 100644 tests/ref/vs

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, independent of vcodec.mak

2015-09-08 Thread Peter B. 
On 09/08/2015 01:46 AM, Michael Niedermayer wrote:
> On Mon, Sep 07, 2015 at 11:18:56PM +0200, Peter B. wrote:
>> Should be fixed.
>> (Getting errors with "make fate" for some fate-dxv*, with git HEAD but
>> that seems unrelated to my changes)
> this seems to loose some tests
>
> before the patch:
> make fate-list  | wc
>25722572   62899
>
> after the patch:
> make fate-list  | wc
>25672567   62788

True indeed.

I had to drop the vsynth3 tests, because they behave differently and
were intertwined with code in vcodec.mak.
I didn't manage to move those to an external file. Thought it'd take
that loss temporarily and try to add them back in the next step.


Pb

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

[FFmpeg-devel] FATE: testing lossless video differently

2015-09-13 Thread Peter B. 
Hi :)

I'm having difficulties implement FFV1 lossless FATE tests in a way that
seems more appropriate.
I'd be grateful for advice how to deal with this:

I'd rather use "framecrc" instead of the "enc_dec" method used in
vodec.mak. Yet, the usage of framecrc in the tests for other lossless
codecs in "lossless-video.mak", only seem to validate decoding of given
source files in the fate-suite samples collection.


I've checked the BASH code of the testing functions (enc_dec(),
framecrc()) in "tests/fate-run.sh".

I was thinking about adding a new function to tests/fate-run.sh that
does something like this:
1) encode-and-convert vsynth*.yuv
2) framecrc the generated output
3) decode the generated output
4) compare framecrc of encoding with framecrc of decoding

What do you think?


Thanks in advance,
Pb




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

[FFmpeg-devel] [PATCH] Adding ffv1 help reference for "coder" parameter.

2015-09-13 Thread Peter B. 
Hi.

I just saw that "ffmpeg --help encoder=ffv1 full" only lists the
"slicecrc" parameter option.
I'd like to add the other options to the help as well.

The attached patch adds explanation for "-coder".

I've read up on AVOption Struct Reference [1] and read other source
files, but the usage of some arguments (offset, flags, unit) is not
clear to me.


Feedback on my patch, as well as hints towards documentation about
adding AVOptions greatly appreciated :)


Thanks in advance,
Pb



== References:
[1] http://ffmpeg.org/doxygen/trunk/structAVOption.html
>From d51af4c272d3573f4c4c94dcfe93c7c45e9d7e36 Mon Sep 17 00:00:00 2001
From: Peter B 
Date: Sun, 13 Sep 2015 19:04:20 +0200
Subject: [PATCH] Adding ffv1 help reference for "coder" parameter.

---
 libavcodec/ffv1enc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 265ced1..d210692 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -1345,6 +1345,7 @@ static av_cold int encode_close(AVCodecContext *avctx)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
 { "slicecrc", "Protect slices with CRCs", OFFSET(ec), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE },
+{ "coder", "Coder used: 0 (Golomb Rice), 1 (Range coder), 2 (Range coder with custom state transition table)", OFFSET(ac), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE },
 { NULL }
 };
 
-- 
1.7.9.5

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

[FFmpeg-devel] ffprobe -debug 1: Output for FFV1 inconsistent

2015-09-13 Thread Peter B. 
Hello again :)

I've just noticed that the output of "ffprobe -debug 1" for FFV1 files
has different labels for same parameters in different versions.

For example:

== FFV1.1:
[ffv1 @ 0x3a8ab80] ver:1 keyframe:1 coder:0 ec:0 slices:1 bps:8

== FFV1.3:
[ffv1 @ 0x31584e0] global: ver:3.4, coder:0, colorspace: 0 bpr:8
chroma:1(1:0), alpha:0 slices:2x2 qtabs:2 ec:1 intra:0 CRC:0x9A658FB3


Summary:
- "bps" seems to be "bpr"?
- What is "keyframe"?
- FFV1.1 has "slices"?
- "colorspace" only in FFV1.3
- "intra" only in FFV1.3
- "alpha" only in FFV1.3
- keyword "global:" only in FFV1.3


Why is that so?


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

[FFmpeg-devel] FFV1: version 0 vs 1?

2015-09-13 Thread Peter B. 
Hello again :)

I've just noticed that by default, FFV1 chooses version "0".
I thought it would be "1".

When adding "-level 1" it properly shows "ver:1".
(and a proper value for "bps")


== For example:

Source video: https://media.xiph.org/video/derf/y4m/football_422_ntsc.y4m

$ ffmpeg -i input.avi -c:v ffv1 -an output.avi
$ ffprobe -debug 1 -i output.avi

Shows:
[ffv1 @ 0x2263b80] ver:0 keyframe:1 coder:0 ec:0 slices:1 bps:0


On the other hand:
$ ffmpeg -i input.avi -c:v ffv1 -level 1 -an output.avi
$ ffprobe -debug 1 -i output.avi

Shows:
[ffv1 @ 0x2c9eb80] ver:1 keyframe:1 coder:0 ec:0 slices:1 bps:8


Interestingly, the console output of both commands seems identical.
Why is that so?


Thanks in advance,
Pb

--
Complete uncut console output:

// --
$ ffmpeg -i ../football_422_ntsc.y4m -c:v ffv1 -an output.avi
// --

ffmpeg version N-75272-g5629143 Copyright (c) 2000-2015 the FFmpeg
developers
  built with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree
--enable-version3 --enable-postproc --enable-swscale --enable-avfilter
--enable-pthreads --enable-bzlib --enable-zlib --enable-decoder=png
--enable-encoder=png --samples=../fate-suite --enable-libfreetype
--enable-libschroedinger --enable-libopenjpeg --disable-decoder=jpeg2000
--enable-libvpx --enable-libvorbis --enable-libx264 --enable-libfaac
  libavutil  55.  2.100 / 55.  2.100
  libavcodec 57.  1.100 / 57.  1.100
  libavformat57.  0.100 / 57.  0.100
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6.  2.100 /  6.  2.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
  libpostproc54.  0.100 / 54.  0.100
Input #0, yuv4mpegpipe, from '../football_422_ntsc.y4m':
  Duration: 00:00:12.00, start: 0.00, bitrate: 167963 kb/s
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p, 720x486,
SAR 4320:4379 DAR 6400:4379, 30 fps, 30 tbr, 30 tbn, 30 tbc
Output #0, avi, to 'output.avi':
  Metadata:
ISFT: Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p, 720x486 [SAR
4320:4379 DAR 6400:4379], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
Metadata:
  encoder : Lavc57.1.100 ffv1
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame=  360 fps= 45 q=-0.0 Lsize=  111033kB time=00:00:12.00
bitrate=75798.8kbits/s   
video:111019kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.012829%
// --


// --
$ ffmpeg_git -i ../football_422_ntsc.y4m -c:v ffv1 -level 1 -an output.avi
// --

ffmpeg version N-75272-g5629143 Copyright (c) 2000-2015 the FFmpeg
developers
  built with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree
--enable-version3 --enable-postproc --enable-swscale --enable-avfilter
--enable-pthreads --enable-bzlib --enable-zlib --enable-decoder=png
--enable-encoder=png --samples=../fate-suite --enable-libfreetype
--enable-libschroedinger --enable-libopenjpeg --disable-decoder=jpeg2000
--enable-libvpx --enable-libvorbis --enable-libx264 --enable-libfaac
  libavutil  55.  2.100 / 55.  2.100
  libavcodec 57.  1.100 / 57.  1.100
  libavformat57.  0.100 / 57.  0.100
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6.  2.100 /  6.  2.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
  libpostproc54.  0.100 / 54.  0.100
Input #0, yuv4mpegpipe, from '../football_422_ntsc.y4m':
  Duration: 00:00:12.00, start: 0.00, bitrate: 167963 kb/s
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p, 720x486,
SAR 4320:4379 DAR 6400:4379, 30 fps, 30 tbr, 30 tbn, 30 tbc
Output #0, avi, to 'output.avi':
  Metadata:
ISFT: Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p, 720x486 [SAR
4320:4379 DAR 6400:4379], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
Metadata:
  encoder : Lavc57.1.100 ffv1
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame=  360 fps= 54 q=-0.0 Lsize=  111033kB time=00:00:12.00
bitrate=75798.8kbits/s   
video:111019kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.012829%
// --
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFV1: version 0 vs 1?

2015-09-14 Thread Peter B. 
On 09/14/2015 12:25 AM, Michael Niedermayer wrote:
> the encoder chooses the lowest version that supports the requested
> features well to maximize compatibility

Thanks for the explanation.
Sounds reasonable.

If I read [1] correcly, FFV1.0 does not store "bits_per_raw_sample".
I'd be interested in any downsides FFV1.0 would have over FFV1.1?


Thanks,
Pb


== References:
[1] http://ffmpeg.org/~michael/ffv1.html#toc-Subsubsection-4.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2

2015-09-14 Thread Peter B. 
I wanted to check what happens if someone uses an invalid parameter
combination:
"-c:v ffv1 -level 1 -slices 2"

I expected an error message about invalid slice number, but the code
selected FFV1.2:

"[ffv1 @ 0x391b060] Version 2 needed for requested features but version
2 is experimental and not enabled"



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

Re: [FFmpeg-devel] ffprobe -debug 1: Output for FFV1 inconsistent

2015-09-14 Thread Peter B. 
On 09/13/2015 11:48 PM, Michael Niedermayer wrote:
>> - What is "keyframe"?
> a random access point

I'm not sure what your answer means.
I understand that "A keyframe" is a random access point. The flag in
ffprobe's output seems to always be "1".
I thought it might be the same as "intra" in FFV1.3's ffprobe output,
but it doesn't go to "0" when GOP>1.


>> - FFV1.1 has "slices"?
> one could argue that any codec without slices has 1 slice per frame

True.
I just found it a bit confusing to have "slices" mentioned in FFV1 <
version 2.


>> - "colorspace" only in FFV1.3
>> - "intra" only in FFV1.3
>> - "alpha" only in FFV1.3
>> - keyword "global:" only in FFV1.3
>>
>>
>> Why is that so?
> The code parsing the headers differs and so does the debug printout
> i think noone thought about / noticed these differences before

Thanks for clearing that up.

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

Re: [FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2

2015-09-16 Thread Peter B. 
On 09/15/2015 08:47 PM, Michael Niedermayer wrote:
> On Tue, Sep 15, 2015 at 01:31:20AM +0200, Peter B. wrote:
>> I wanted to check what happens if someone uses an invalid parameter
>> combination:
>> "-c:v ffv1 -level 1 -slices 2"
>>
>> I expected an error message about invalid slice number, but the code
>> selected FFV1.2:
>>
>> "[ffv1 @ 0x391b060] Version 2 needed for requested features but version
>> 2 is experimental and not enabled"
> fixed

Thanks.

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

Re: [FFmpeg-devel] [PATCH]lavc/v210dec: Skip Canopus C210 extradata

2018-05-18 Thread Peter B. 
On 17/05/18 12:20, Carl Eugen Hoyos wrote:
> 2018-05-10 22:50 GMT+02:00, Carl Eugen Hoyos :
>
>> Peter Bubestinger provided a C210 file where every frame starts with
>> 64 bytes of extradata (24 byte "INFO", 16 byte "RDRT", rest "FIEL").
>> Piotr confirmed that the Canopus decoder accepts files without the
>> extradata but consumes it if present.
>> Attached patch fixes the file in question visually.
> Patch applied, Carl Eugen

I've just tested with recent git (=including your path) and it seems to
work properly.
Also transcoded to FFV1 and compared framemd5: matches.


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

[FFmpeg-devel] [PATCH] fate: Add test for wav Peak Envelope Chunk encoder (levl, chunk).

2014-07-18 Thread Peter B. 
Hello.

Georg Lippitsch and I created 2 FATE tests for the EBU Peak Envelope Chunk:
Test 1: Normal WAV file with levl-chunk and audio data.
Test 2: "Peakfile" WAV with levl-chunk, without audio data.

I tried to follow the style of existing lavf-regression tests in FATE as
good as possible.

Regards,
Pb
>From bec0905cc5b896a287d8e0953c9931e41a62972d Mon Sep 17 00:00:00 2001
From: Peter B 
Date: Thu, 17 Jul 2014 18:51:38 +0200
Subject: [PATCH] fate: Add test for wav Peak Envelope Chunk encoder (levl
 chunk).

---
 tests/fate/avformat.mak  |2 ++
 tests/lavf-regression.sh |9 +
 tests/ref/lavf/wav_peak  |3 +++
 tests/ref/lavf/wav_peak_only |2 ++
 4 files changed, 16 insertions(+)
 create mode 100644 tests/ref/lavf/wav_peak
 create mode 100644 tests/ref/lavf/wav_peak_only

diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 5f9c8c1..1040afa 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -45,6 +45,8 @@ FATE_LAVF-$(call ENCDEC2, MPEG2VIDEO, MP2,   MPEGTS) += ts
 FATE_LAVF-$(call ENCDEC,  PCM_U8,VOC)+= voc
 FATE_LAVF-$(call ENCDEC,  PCM_S16LE, VOC)+= voc_s16
 FATE_LAVF-$(call ENCDEC,  PCM_S16LE, WAV)+= wav
+FATE_LAVF-$(call ENCDEC,  PCM_S16LE, WAV)+= wav_peak
+FATE_LAVF-$(call ENCDEC,  PCM_S16LE, WAV)+= wav_peak_only
 FATE_LAVF-$(call ENCMUX,  PCM_S16LE, W64)+= w64
 FATE_LAVF-$(call ENCDEC,  MP2,   WTV)+= wtv
 FATE_LAVF-$(call ENCDEC,  XBM,   IMAGE2) += xbm
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index 0efbc9c..7e6ad06 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-regression.sh
@@ -274,6 +274,15 @@ if [ -n "$do_wav" ] ; then
 do_audio_only wav
 fi
 
+if [ -n "$do_wav_peak" ] ; then
+do_audio_only peak.wav "" "-write_peak on"
+fi
+
+if [ -n "$do_wav_peak_only" ] ; then
+file=${outfile}lavf.peak_only.wav
+do_avconv $file $DEC_OPTS -ar 44100 -f s16le -i $pcm_src $ENC_OPTS -t 1 -qscale 10 -write_peak only
+fi
+
 if [ -n "$do_alaw" ] ; then
 do_audio_only al "" "" "-ar 44100"
 fi
diff --git a/tests/ref/lavf/wav_peak b/tests/ref/lavf/wav_peak
new file mode 100644
index 000..aa7e5fc
--- /dev/null
+++ b/tests/ref/lavf/wav_peak
@@ -0,0 +1,3 @@
+35148d1f6e66b0080893851d917ecbf4 *./tests/data/lavf/lavf.peak.wav
+89094 ./tests/data/lavf/lavf.peak.wav
+./tests/data/lavf/lavf.peak.wav CRC=0x3a1da17e
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
new file mode 100644
index 000..dccd0e7
--- /dev/null
+++ b/tests/ref/lavf/wav_peak_only
@@ -0,0 +1,2 @@
+b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+832 ./tests/data/lavf/lavf.peak_only.wav
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] fate: Add test for wav Peak Envelope Chunk encoder (levl, chunk).

2014-07-18 Thread Peter B. 
On 07/18/2014 07:40 PM, Michael Niedermayer wrote:
> applied

Thanks!

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