[PATCH] ffv1enc: Make ffv1.3 non experimental
The fate tests change as they used 1.2 previously Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-) diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c index cc9a1a9..69474e9 100644 --- a/libavcodec/ffv1enc.c +++ b/libavcodec/ffv1enc.c @@ -651,7 +651,7 @@ static av_cold int encode_init(AVCodecContext *avctx) if ((avctx->flags & (CODEC_FLAG_PASS1|CODEC_FLAG_PASS2)) || avctx->slices>1) s->version = FFMAX(s->version, 2); - if (avctx->level == 3 || (s->version==2 && avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL)) { + if ((avctx->level == 3 || avctx->level <= 0) && s->version == 2) { s->version = 3; } @@ -659,7 +659,7 @@ static av_cold int encode_init(AVCodecContext *avctx) s->ec = (s->version >= 3); } - if (s->version >= 2 && avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) { + if ((s->version == 2 || s->version>3) && avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) { av_log(avctx, AV_LOG_ERROR, "Version 2 needed for requested features but version 2 is experimental and not enabled\n"); return AVERROR_INVALIDDATA; } diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index 7aed089..5f2313c 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -55,7 +55,7 @@ fate-vsynth%-dv-50: DECOPTS = -sws_flags neighbor fate-vsynth%-dv-50: FMT = dv FATE_VCODEC-$(call ENCDEC, FFV1, AVI) += ffv1 -fate-vsynth%-ffv1: ENCOPTS = -slices 4 -strict -2 +fate-vsynth%-ffv1: ENCOPTS = -slices 4 FATE_VCODEC-$(call ENCDEC, FFVHUFF, AVI) += ffvhuff diff --git a/tests/ref/seek/vsynth2-ffv1 b/tests/ref/seek/vsynth2-ffv1 index 715a272..84e7436 100644 --- a/tests/ref/seek/vsynth2-ffv1 +++ b/tests/ref/seek/vsynth2-ffv1 @@ -1,46 +1,46 @@ -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st:-1 flags:0 ts:-1.000000 -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st:-1 flags:1 ts: 1.894167 -ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2498334 size: 75937 +ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2499438 size: 75965 ret: 0 st: 0 flags:0 ts: 0.800000 -ret: 0 st: 0 flags:1 dts: 0.960000 pts: 0.960000 pos:1630830 size: 72682 +ret: 0 st: 0 flags:1 dts: 0.960000 pts: 0.960000 pos:1631570 size: 72710 ret:-1 st: 0 flags:1 ts:-0.320000 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.440000 pts: 1.440000 pos:2498334 size: 75937 +ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2499438 size: 75965 ret: 0 st: 0 flags:0 ts: 0.360000 -ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801262 size: 69457 +ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801634 size: 69485 ret:-1 st: 0 flags:1 ts:-0.760000 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: 0.960000 pts: 0.960000 pos:1630830 size: 72682 +ret: 0 st: 0 flags:1 dts: 0.960000 pts: 0.960000 pos:1631570 size: 72710 ret: 0 st: 0 flags:0 ts:-0.040000 -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st: 0 flags:1 ts: 2.840000 -ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3392418 size: 77461 +ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3393890 size: 77489 ret: 0 st:-1 flags:0 ts: 1.730004 -ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3392418 size: 77461 +ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3393890 size: 77489 ret: 0 st:-1 flags:1 ts: 0.624171 -ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801262 size: 69457 +ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801634 size: 69485 ret: 0 st: 0 flags:0 ts:-0.480000 -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st: 0 flags:1 ts: 2.400000 -ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3392418 size: 77461 +ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3393890 size: 77489 ret: 0 st:-1 flags:0 ts: 1.306672 -ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2498334 size: 75937 +ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2499438 size: 75965 ret: 0 st:-1 flags:1 ts: 0.200839 -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st: 0 flags:0 ts:-0.920000 -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5688 size: 71679 +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 5690 size: 71707 ret: 0 st: 0 flags:1 ts: 2.000000 -ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3392418 size: 77461 +ret: 0 st: 0 flags:1 dts: 1.920000 pts: 1.920000 pos:3393890 size: 77489 ret: 0 st:-1 flags:0 ts: 0.883340 -ret: 0 st: 0 flags:1 dts: 0.960000 pts: 0.960000 pos:1630830 size: 72682 +ret: 0 st: 0 flags:1 dts: 0.960000 pts: 0.960000 pos:1631570 size: 72710 ret:-1 st:-1 flags:1 ts:-0.222493 ret:-1 st: 0 flags:0 ts: 2.680000 ret: 0 st: 0 flags:1 ts: 1.560000 -ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2498334 size: 75937 +ret: 0 st: 0 flags:1 dts: 1.440000 pts: 1.440000 pos:2499438 size: 75965 ret: 0 st:-1 flags:0 ts: 0.460008 -ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801262 size: 69457 +ret: 0 st: 0 flags:1 dts: 0.480000 pts: 0.480000 pos: 801634 size: 69485 ret:-1 st:-1 flags:1 ts:-0.645825 diff --git a/tests/ref/vsynth/vsynth1-ffv1 b/tests/ref/vsynth/vsynth1-ffv1 index a162a77..22c9341 100644 --- a/tests/ref/vsynth/vsynth1-ffv1 +++ b/tests/ref/vsynth/vsynth1-ffv1 @@ -1,4 +1,4 @@ -d236e8441d7e04e24d882bb97faccd36 *tests/data/fate/vsynth1-ffv1.avi -2689718 tests/data/fate/vsynth1-ffv1.avi +394aa2d2ee50abbc2372e6d126c7eb5a *tests/data/fate/vsynth1-ffv1.avi +2691264 tests/data/fate/vsynth1-ffv1.avi c5ccac874dbf808e9088bc3107860042 *tests/data/fate/vsynth1-ffv1.out.rawvideo stddev: 0.00 PSNR:999.99 MAXDIFF: 0 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-ffv1 b/tests/ref/vsynth/vsynth2-ffv1 index 8263b01..6caffdd 100644 --- a/tests/ref/vsynth/vsynth2-ffv1 +++ b/tests/ref/vsynth/vsynth2-ffv1 @@ -1,4 +1,4 @@ -9d8486fc8a260204d8ee3212d95915b5 *tests/data/fate/vsynth2-ffv1.avi -3546258 tests/data/fate/vsynth2-ffv1.avi +0837dc7e6f625e2f6ac16140562c079d *tests/data/fate/vsynth2-ffv1.avi +3547788 tests/data/fate/vsynth2-ffv1.avi dde5895817ad9d219f79a52d0bdfb001 *tests/data/fate/vsynth2-ffv1.out.rawvideo stddev: 0.00 PSNR:999.99 MAXDIFF: 0 bytes: 7603200/ 7603200 -- 1.7.9.5
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings. these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
On Sat, 17 Aug 2013 13:33:27 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings.
these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference
I'm just curious: isn't CRC a pretty slow checksum algorithm? Why are checksums needed at all, isn't that the responsibility of the container, if it should be inside the file at all?
On Sat, 17 Aug 2013 15:27:43 +0200, wm4 wrote:
On Sat, 17 Aug 2013 13:33:27 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings.
these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference
I'm just curious: isn't CRC a pretty slow checksum algorithm? Why are checksums needed at all, isn't that the responsibility of the container, if it should be inside the file at all?
read up on previous ffv1 threads. it was requested from multiple users that it needed frame checksums. either because they use it as rawvideo without a container or because they mux it into a container later. when people use ffv1 for archiving , they want as many checks as possible :) -compn
On Aug 17, 2013, at 10:10 AM, compn <tempn@twmi.rr.com> wrote:
On Sat, 17 Aug 2013 15:27:43 +0200, wm4 wrote:
On Sat, 17 Aug 2013 13:33:27 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings.
these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference
I'm just curious: isn't CRC a pretty slow checksum algorithm? Why are checksums needed at all, isn't that the responsibility of the container, if it should be inside the file at all?
I've seen this for FLAC with audio but is there a container for video that can contain losslessly encoded video and document that data with checksums?
read up on previous ffv1 threads. it was requested from multiple users that it needed frame checksums. either because they use it as rawvideo without a container or because they mux it into a container later.
when people use ffv1 for archiving , they want as many checks as possible :)
I was one of the requestors and one of those who use ffv1 in archival work (mostly for losslessly encoding the results of the digitization of analog video). I see the integration of frame checksums to create a video equivalent of the advantages of FLAC within digital preservation. FLAC stores a checksum of the encoded audio in its header so the entire flac encoding may be assessed as valid or invalid on future inspection and if the FLAC is invalid, then the embedded crc's can direct you to a close location of where the digital error is. FFV1 version 3 offers a similar function in that digital corruption of any FFV1 version 3 encoding may be identified from the point of encoding onward without requiring external checksum workflows or storage of framemd5 files. If interested I wrote up more on this here: http://dericed.com/papers/reconsidering-the-checksum-for-audiovisual-preserv.... Dave Rice
On Sat, 17 Aug 2013 19:54:04 -0400 Dave Rice <dave@dericed.com> wrote:
On Aug 17, 2013, at 10:10 AM, compn <tempn@twmi.rr.com> wrote:
On Sat, 17 Aug 2013 15:27:43 +0200, wm4 wrote:
On Sat, 17 Aug 2013 13:33:27 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings.
these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference
I'm just curious: isn't CRC a pretty slow checksum algorithm? Why are checksums needed at all, isn't that the responsibility of the container, if it should be inside the file at all?
I've seen this for FLAC with audio but is there a container for video that can contain losslessly encoded video and document that data with checksums?
I thought that could be added to NUT, which is AFAIK the native container for this video codec? (Or a least it's a container format created by FFmpeg.)
On 08/18/2013 02:28 AM, wm4 wrote:
On Sat, 17 Aug 2013 19:54:04 -0400 Dave Rice <dave@dericed.com> wrote:
I've seen this for FLAC with audio but is there a container for video that can contain losslessly encoded video and document that data with checksums? I thought that could be added to NUT, which is AFAIK the native container for this video codec? (Or a least it's a container format created by FFmpeg.)
As Dave already mentioned, FFv1 is very viable for long term video archiving. In that domain, there are existing setups and tool-chains which have to be considered when choosing formats for storing the videos. Currently, different institutions use different containers for storing their digital video archive copies. Which container or tools to use is often not free to decide by the responsible persons, but limited by certain criteria. Most of which are not necessarily technical. If someone implements checksums in NUT, that's fine. For the time being, FFv1.3 already offers what is needed. Michael has been working on FFv1.3 for a long time now, and in that time others have worked on being able (and allowed) to use FFv1 in the archiving domain, and there's still a lot of work to be done. Regards, Pb
On Sat, 17 Aug 2013 19:54:04 -0400, Dave Rice wrote:
http://dericed.com/papers/reconsidering-the-checksum-for-audiovisual-preserv...
wow, thats a nice write up. cc'd it to mike melanson, our resident multimedia guru. -compn
On Sat, Aug 17, 2013 at 03:27:43PM +0200, wm4 wrote:
On Sat, 17 Aug 2013 13:33:27 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 08:27:14AM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 05:00, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
It's fairly minimal, but is it expected that every single frame becomes larger?
1.3 adds 32bit CRCs per slice by default (can be disabled), it adds slice headers to allow decoding one slice without the others an additional slice size field is added to make it possible to find slices within corrupted surroundings.
these add up to about 57bit per slice more at 50 frames and 4 slices thats 1425 byte which comes close to the actual difference, so i would say that explains the difference
I'm just curious: isn't CRC a pretty slow checksum algorithm?
compared to what ? md5 sha1, ... are all much slower adler32 is faster but its pretty crap murmur might be faster but it lacks many properties that crcs have, and which may be important for error detection
Why are checksums needed at all,
they arent "needed" but some users want to know which parts of a video is undamaged and which are damaged with more certainity than what you get by checking for decoder errors.
isn't that the responsibility of the container, if it should be inside the file at all?
containers generally dont provide such checksums, even less so at slice level. PS: if you have ideas for improving it, its certainly possible to make changes to it for 1.4 ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer.
On 17.08.2013, at 20:00, Michael Niedermayer <michaelni@gmx.at> wrote:
isn't that the responsibility of the container, if it should be inside the file at all?
containers generally dont provide such checksums, even less so at slice level.
Isn't it a checksum of the uncompressed data anyway? A container can't provide that and it only makes sense for lossless anyway.
On Sat, Aug 17, 2013 at 08:14:19PM +0200, Reimar Döffinger wrote:
On 17.08.2013, at 20:00, Michael Niedermayer <michaelni@gmx.at> wrote:
isn't that the responsibility of the container, if it should be inside the file at all?
containers generally dont provide such checksums, even less so at slice level.
Isn't it a checksum of the uncompressed data anyway? A container can't provide that and it only makes sense for lossless anyway.
its of the compressed data (less data-> faster) and crc has various properties which would be lost if its applied in a different domain than the one where errors occur [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all? What about 1.1 and older version coverage?, that's why original question...
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all?
prior to 1.3 we tested 1.2
What about 1.1 and older version coverage?, that's why original question...
improving fates coverage was and is welcome [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time.
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all?
prior to 1.3 we tested 1.2
What about 1.1 and older version coverage?, that's why original question...
improving fates coverage was and is welcome
Sorry but not me. You as mainter of ffv1 are first on line.
On Sat, Aug 17, 2013 at 11:22:19AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all?
prior to 1.3 we tested 1.2
What about 1.1 and older version coverage?, that's why original question...
improving fates coverage was and is welcome
Sorry but not me. You as mainter of ffv1 are first on line.
maintainers review changes maintainers integrate/merge/pull/cherry pick good changes maintainers fix regressions and make sure the code is in good shape and working maintainers revert bad changes and they then flame thouse who did the bad change maintainers might do alot more than that but adding every good idea someone proposes is not their "duty" though of course they might do it anyway [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
On 2013-08-17 14:11 +0200, Michael Niedermayer wrote:
On Sat, Aug 17, 2013 at 11:22:19AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote: > The fate tests change as they used 1.2 previously > > Signed-off-by: Michael Niedermayer <michaelni@gmx.at> > --- > libavcodec/ffv1enc.c | 4 ++-- > tests/fate/vcodec.mak | 2 +- > tests/ref/seek/vsynth2-ffv1 | 40 > ++++++++++++++++++++-------------------- > tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- > tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- > 5 files changed, 27 insertions(+), 27 deletions(-) >
So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all?
prior to 1.3 we tested 1.2
What about 1.1 and older version coverage?, that's why original question...
improving fates coverage was and is welcome
Sorry but not me. You as mainter of ffv1 are first on line.
maintainers review changes maintainers integrate/merge/pull/cherry pick good changes maintainers fix regressions and make sure the code is in good shape and working maintainers revert bad changes and they then flame thouse who did the bad change
I consider the flaming part optional :)
maintainers might do alot more than that but adding every good idea someone proposes is not their "duty" though of course they might do it anyway
Also we have docs about maintaining written here since some time: https://trac.ffmpeg.org/wiki/MaintainingFFmpeg Maybe we should add reverting bad changes as an explicit bullet point there. Will do so, if no one has good reasons against it. It also kind of includes fixing regressions so I do not think we need to state that explicitly. Alexander
On 8/18/13, Alexander Strasser <eclipse7@gmx.net> wrote:
On 2013-08-17 14:11 +0200, Michael Niedermayer wrote:
On Sat, Aug 17, 2013 at 11:22:19AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 10:38:07AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, Aug 17, 2013 at 09:29:35AM +0000, Paul B Mahol wrote: > On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote: > > The fate tests change as they used 1.2 previously > > > > Signed-off-by: Michael Niedermayer <michaelni@gmx.at> > > --- > > libavcodec/ffv1enc.c | 4 ++-- > > tests/fate/vcodec.mak | 2 +- > > tests/ref/seek/vsynth2-ffv1 | 40 > > ++++++++++++++++++++-------------------- > > tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- > > tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- > > 5 files changed, 27 insertions(+), 27 deletions(-) > > > > So 1.2 coverage is now 0% ?
testing should concentrate on non experimental variants. 1.2 is experimental and cannot be used unless the user explicitly enables experimental code. That means noone should be using it, no files should exist in the wild and thus testing it probably makes no sense
Ah. so previously 1.2 was tested for no reason at all?
prior to 1.3 we tested 1.2
What about 1.1 and older version coverage?, that's why original question...
improving fates coverage was and is welcome
Sorry but not me. You as mainter of ffv1 are first on line.
maintainers review changes maintainers integrate/merge/pull/cherry pick good changes maintainers fix regressions and make sure the code is in good shape and working maintainers revert bad changes and they then flame thouse who did the bad change
I consider the flaming part optional :)
maintainers might do alot more than that but adding every good idea someone proposes is not their "duty" though of course they might do it anyway
Also we have docs about maintaining written here since some time:
https://trac.ffmpeg.org/wiki/MaintainingFFmpeg
Maybe we should add reverting bad changes as an explicit bullet point there. Will do so, if no one has good reasons against it. It also kind of includes fixing regressions so I do not think we need to state that explicitly.
Looks like everybody missed real point. Without coverage one can not found out if some change caused regression, and the only way is if someone reports it.
Hi Paul! On 2013-08-18 10:22 +0000, Paul B Mahol wrote:
On 8/18/13, Alexander Strasser <eclipse7@gmx.net> wrote:
On 2013-08-17 14:11 +0200, Michael Niedermayer wrote:
On Sat, Aug 17, 2013 at 11:22:19AM +0000, Paul B Mahol wrote:
On 8/17/13, Michael Niedermayer <michaelni@gmx.at> wrote: [...]
improving fates coverage was and is welcome
Sorry but not me. You as mainter of ffv1 are first on line.
maintainers review changes maintainers integrate/merge/pull/cherry pick good changes maintainers fix regressions and make sure the code is in good shape and working maintainers revert bad changes and they then flame thouse who did the bad change
I consider the flaming part optional :)
maintainers might do alot more than that but adding every good idea someone proposes is not their "duty" though of course they might do it anyway
Also we have docs about maintaining written here since some time:
https://trac.ffmpeg.org/wiki/MaintainingFFmpeg
Maybe we should add reverting bad changes as an explicit bullet point there. Will do so, if no one has good reasons against it. It also kind of includes fixing regressions so I do not think we need to state that explicitly.
Looks like everybody missed real point. Without coverage one can not found out if some change caused regression, and the only way is if someone reports it.
Or if anybody spots it while reviewing the commit... Anyway, I agree with the point you make. My former reply was only meant about the duties of maintaining code in FFmpeg and that we have a Wiki page that describes the responsibilities. Besides, if I am not mistaken, Michael just committed reg tests for 1.0 --- though I would not see it as a necessity demanded by his maintainer role! I would rather say that he could do it and agreed with your point that test coverage of some older version of the codec makes sense. Alexander
Hi everyone, On 08/17/2013 12:49 PM, Michael Niedermayer wrote:
improving fates coverage was and is welcome
I've read up the documentation of FATE [1,2] in order to increase FFV1 fate-coverage. The existing FFV1 tests I've found were defined in "tests/fate/vcodec.mak". If I understand them correctly, they test encoding, right? The ruleset in "tests/fate/lossless-video.mak" seems to be used for decoding-tests, right? I have managed to add FFV1 tests to lossless-video.mak, matching entries for other codecs. I've mainly derived my testsets there from Lagarith's entries. It seems that I've done things correctly, because I've also enabled LCOV html display and the line coverage increased. Yay! :) Now before I proceed, I wanted to ask some things in advance: - Is there a way to generate videos to be used for decoding-tests, in order not to increase the fate-suite size unnecessarily? I've found Makefile rules like ENCDEC, DEMDEC, etc. but none yet for generating-then-testing. - Current encoding tests assume that the input file is encoded "as-is". No size or pix_fmt variations "on the fly" in the tests. Makes sense. Again, in order not to increase the fate-suite size unnecessarily by adding extra videos: Is there a way to make these tests, based on a common video (e.g. vsynth) which is then changed to different parameters (e.g. "-s pal", "-s hd1080" - or pix_fmt) on the fly? Thanks, Pb [1] http://www.ffmpeg.org/fate.html [2] http://www.ffmpeg.org/developer.html#Regression-tests-1
On Sat, Aug 17, 2013 at 05:00:42AM +0200, Michael Niedermayer wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
patch applied thanks to all [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
On 08/26/2013 05:35 PM, Michael Niedermayer wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
On Sat, Aug 17, 2013 at 05:00:42AM +0200, Michael Niedermayer wrote: patch applied
thanks to all
YESSS! :) Thank you very much, and also thanks to everyone who contributed to this. Peter B.
On 08/26/2013 05:35 PM, Michael Niedermayer wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
On Sat, Aug 17, 2013 at 05:00:42AM +0200, Michael Niedermayer wrote: patch applied
One short question, just to avoid any misunderstandings: This means that the FFv1.3 bitstream will now remain as it is, and decodeability of files generated now will be guaranteed in the future (like it was for FFv1.1 [1])? Thanks, Pb == References: [1] http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b548f2b91b701e1235608ac882e...
On 8/30/13, Peter B. <pb@das-werkstatt.com> wrote:
On 08/26/2013 05:35 PM, Michael Niedermayer wrote:
The fate tests change as they used 1.2 previously
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/ffv1enc.c | 4 ++-- tests/fate/vcodec.mak | 2 +- tests/ref/seek/vsynth2-ffv1 | 40 ++++++++++++++++++++-------------------- tests/ref/vsynth/vsynth1-ffv1 | 4 ++-- tests/ref/vsynth/vsynth2-ffv1 | 4 ++-- 5 files changed, 27 insertions(+), 27 deletions(-)
On Sat, Aug 17, 2013 at 05:00:42AM +0200, Michael Niedermayer wrote: patch applied
One short question, just to avoid any misunderstandings:
This means that the FFv1.3 bitstream will now remain as it is, and decodeability of files generated now will be guaranteed in the future (like it was for FFv1.1 [1])?
Yes.
On 08/30/2013 10:23 PM, Paul B Mahol wrote:
On 8/30/13, Peter B. <pb@das-werkstatt.com> wrote:
One short question, just to avoid any misunderstandings:
This means that the FFv1.3 bitstream will now remain as it is, and decodeability of files generated now will be guaranteed in the future (like it was for FFv1.1 [1])? Yes.
Thank you very much. (I just needed this to be non-misinterpretable, so I can refer to it when talking to officials) Pb
participants (8)
-
Alexander Strasser -
compn -
Dave Rice -
Michael Niedermayer -
Paul B Mahol -
Peter B. -
Reimar Döffinger -
wm4