Re: [libav-devel] [PATCH] ffv1: Report additional bitstream information in verbose mode
On 06/28/2016 12:35 PM, Luca Barbato wrote: >> This looks great! :D And it would indeed be very useful. Is it on >> purpose, that "slicecrc" is not included? > Just that I didn't find it interesting, I can add it before pushing. hihi... nice answer! :) Actually, it's quite interesting for preservation people. If it's not too much effort, it'd be great if you could add it. Thank you very much, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ffv1: Report additional bitstream information in verbose mode
On 06/28/2016 12:02 PM, Luca Barbato wrote:
> Useful to inspect samples.
> ---
> libavcodec/ffv1dec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index de3a019..5861908 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -494,6 +494,12 @@ static int read_extra_header(FFV1Context *f)
> f->num_h_slices = 1 + get_symbol(c, state, 0);
> f->num_v_slices = 1 + get_symbol(c, state, 0);
>
> +av_log(f->avctx, AV_LOG_VERBOSE,
> + "FFV1 version %d.%d colorspace %d - %d bits - %d/%d planes %s
> transparent - tile geometry %dx%d\n",
> + f->version, f->minor_version, f->colorspace,
> f->avctx->bits_per_raw_sample,
> + f->plane_count, f->chroma_planes, f->transparency ? "" : "not",
> + f->num_h_slices, f->num_v_slices);
> +
> if (f->num_h_slices > (unsigned)f->width ||
> f->num_v_slices > (unsigned)f->height) {
> av_log(f->avctx, AV_LOG_ERROR, "too many slices\n");
> --
This looks great! :D
And it would indeed be very useful.
Is it on purpose, that "slicecrc" is not included?
Thank you very much,
Pb
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ffv1: Encode only version 3
On 06/28/2016 11:00 AM, Luca Barbato wrote: > Since Vittorio asked, here the patch to drop version 0 and 1. Does this mean, that it won't be possible to encode any FFV1.[01] files with libav (and applications using libav libraries) in the future? If so, than this might not be too good, since there are installations I know of, that rely on creating FFV1 in versions prior to 3. They cannot easily upgrade to FFV1.3 yet, due to dependency on applications that don't support FFV1 (e.g. ffdshow-tryouts). Kind regards, Peter B. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: remove the concat protocol
On 01/27/2016 01:21 PM, Luca Barbato wrote: > On 27/01/16 12:10, Peter B. wrote: >> I'm a user of "concat" for creating lossy access-copies of segmented >> lossless archival files. >> This is done in one step, integrated in an automated mass-digitization >> workflow. > You can use hls as an editlist. It is much flexible incidentally. Will read up on this "hls" feature. Thanks for the tip :) Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: remove the concat protocol
On 01/27/2016 09:05 AM, Anton Khirnov wrote: > I don't really understand your position -- on one hand you don't want to > remove "useful" functionality, even though the concat protocol is IMO > borderline-useless. OTOH you are quite fine with breaking applications > by adding restrictive defaults. I'm a user of "concat" for creating lossy access-copies of segmented lossless archival files. This is done in one step, integrated in an automated mass-digitization workflow. Following the discussion, I wanted to ask what the preferred alternative is, to concatenate multiple files together - in one step - if "concat" is removed? The documentation currently only lists streamable formats (like MPEG), and the usage of pipes [1]. Thanks, Pb == References: [1] https://libav.org/faq.html#How-can-I-join-video-files_003f ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1 improvements v2
On 02/15/2014 08:09 PM, Luca Barbato wrote: The fate tests still need lots of love, the rest should be addressed. I'd be super-passionate regarding the love they need ;) What do they need? Lg, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FOSDEM train tickets
Quoting Rémi Denis-Courmont r...@remlab.net: If you plan to get to FOSDEM via Brussels National airport (BRU), you can buy your train tickets to the city online at http://www.sncb.be/ and print them. The Week-end Internet fare is cheaper, but note it is only valid from Friday 19:00 through Sunday 24:00. Otherwise the normal fare will avoid queueing at the ticket counter. Thank you very much for this insider-tip! :) I went to sncb.be's ticket-booking-site [1] and selected a Weekend Ticket Internet from BRUSSEL-NATIONAAL-LUCHTHAVEN (BRU?) to BRUXELLES-CENTRAL. It calculates the reduced (50%) price for this return (*) ticket with 13,20 EUR. A single, regular ticket from airport to center however, is only 7,80 EUR. So, just to avoid confusion on my side: The weekend ticket is valid for the whole weekend (until Sunday evening), so can I also use it for public transport within Brussels? Thanks, Pb (*) The Netherlands and German version say back and forth ticket, whereas the English version of the site only writes return ticket for the Weekend option. == References: [1] https://www.belgianrail.be/en/timetable-and-buy-tickets/Search/secure/buy-your-ticket-step-1.aspx ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FOSDEM 2014
On 01/06/2014 12:58 PM, Diego Biurrun wrote: It's that time of year again. Who will be coming to FOSDEM? As I am not a developer, is there still a chance to meet you guys at FOSDEM outside of dev rooms? :) Thanks and regards, Peter B. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FOSDEM 2014
On 01/18/2014 01:43 PM, Diego Biurrun wrote: Will you be at the Friday beer event? Just walk up to us and say hello :) I'll be arriving on Friday evening in Brussels, but I'll try to join the beer event as early as possible, but probably won't be able to do so before 21h30. Thanks for the info! Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] fate: Add FFV1 tests
On 12/29/2013 02:15 AM, Luca Barbato wrote: Tell me how you created the fuzzed files =) I've used zzuf (http://caca.zoy.org/wiki/zzuf) for fuzzing the files. parameters: FUZZ_RATIO=0.009# Fuzz-probability per byte. 1.0 = 100% FUZZ_RANGE=3000- # Skip file header 1) Input file: FFV1.3 without slice-CRCs: cat ffv1.3-yuv422p.avi | $ZZUF -b $FUZZ_RANGE -r $FUZZ_RATIO ffv1.3-yuv422p-fuzzed.avi 2) Input file: FFV1.3 with sliceCRCs: cat ffv1.3-yuv422p_crc.avi | $ZZUF -b $FUZZ_RANGE -r $FUZZ_RATIO ffv1.3-yuv422p_crc-fuzzed.avi For clean FATE tests, I'm planning to use the internal fuzzing tool, so these files can be generated too. I already adapted a bit the regression tests you wrote and they are already helping me sorting out what's different. Happy to hear that they are helpful! :) Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] fate: Add FFV1 tests
On 12/28/2013 03:09 PM, Luca Barbato wrote: Today I'm starting again to work on ffv1, support welcome. Great to hear that! Thanks. If there's anything I can help you with, let me know. Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] fate: Add FFV1 tests
Quoting Diego Biurrun di...@biurrun.de:
From 9fde43d493e6ce3216dd4ff779a8440fb647d8db Mon Sep 17 00:00:00 2001
From: Peter B. p...@das-werkstatt.com
Date: Wed, 6 Nov 2013 14:50:53 +0100
Subject: [PATCH] - Improved FFV1 fate test speed. - Added dependencies:
decoding requires encoding before - Added dependency: pass2
requires pass1 - Added dependency: vsynth1.yuv must be
generated - Added conditionals to work with multiple
targets (ffmpeg,avconv)
This list of changes belongs in an annotation, not in the log message.
I still prefer the original log message I suggested :)
I'm not really familiar with auto-generated patches.
The Subject is auto-generated by git format-patch and is basically
my commit message.
I did change the mail-subject to your suggested log-message, but
wasn't aware that you also meant the message inside the patch.
Thanks for clearing that up.
--- /dev/null
+++ b/tests/fate/ffv1.mak
@@ -0,0 +1,313 @@
+# 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
trailing whitespace
Oops.
Overlooked. Sorry.
This ifdef is redundant, avconv is required to run these tests in the
first place.
Well, yes and no:
In order to make it easier for me to maintain this FFV1 fate-testset,
I've written the Makefile in a way that the same file will build the
tests properly for both: FFmpeg and Libav.
So, I've used the CONFIG_AVCONV and CONFIG_FFMPEG variables as
indicator for which target system the tests are being ran.
That also explains other references to FFmpeg in that Makefile.
Just limit the number of frames directly. Ideally by cutting the samples
to 4 frames.
Hm...
I actually wanted to use vsynth1.yuv as-is, but actually it's a good idea:
It would also enable to generate other pix_fmt and size versions out
of the vsynth source.
Where would be a good location to store such intermediate files?
In tests/data/fate somewhere?
+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
nit: You could align the '\'.
Like this?
+FATE_FFV1_LEVEL1 = v1-defaults \
+ v1-gray \
+ v1-rgb32\
+###
+# Decoding:
+###
+# YUV (8bit)
+fate-ffv1-dec-v1-defaults: ${CMD = framecrc -i
$(DEC_SRC)/ffv1-enc-v1-defaults.avi} fate-ffv1-enc-v1-defaults
This works as expected?
Actually yes. Why?
Also, use $() syntax instead of ${}.
Roger that.
Thought it might be nice to have some difference between Makefile
variable-access use and actual Makefile-command sets.
It's purely cosmetic though, so I'll change it to whatever your custom is.
+###
+# Encoding:
+###
Some of these options could be factored out into variables.
You mean making variables to for-loop over?
This is my first Makefile and my first contact with FATE tests, so I
tried to keep it as straightforward as possible.
+# Requires generating vsynth1.yuv as input source:
+$(FATE_FFV1-yes): tests/data/vsynth1.yuv
pointless comment
I agree and disagree.
When I started to understand tests/vcodec.mak, I didn't consider
this line necessary for ffv1.mak.
Only to realize days later, that vsynth1.yuv generating is triggered
if executing vcodec.mak - and so the ffv1 tests here Requires
generating vsynth1.yuv as input source.
If there were some more of these kind of pointless comments, I'd
wouldn't have had to spend several days reverse-engineering the what
is where and why? of FATE testing.
I am technically skilled, but not too familiar with Makefiles or C-code.
Comments might make the life of non-C-guru-contributors way easier.
No ranting, just my personal experience.
diff --git a/tests/ref/fate/ffv1-dec-v1-bff b/tests/ref/fate/ffv1-dec-v1-bff
new file mode 100644
index 000..e69de29
diff --git a/tests/ref/fate/ffv1-dec-v1-bgra
b/tests/ref/fate/ffv1-dec-v1-bgra
new file mode 100644
index 000..e69de29
diff --git a/tests/ref/fate/ffv1-dec-v1-defaults
b/tests/ref/fate/ffv1-dec-v1-defaults
new file mode 100644
index 000..e69de29
Empty files?
Hm...
Will check.
Thanks for your feedback!
Will incorporate the changes as soon as possible.
Regards,
Pb
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
On 11/02/2013 01:19 AM, Luca Barbato wrote: lu - still with no time to write documentation to the wiki... I seem to be unable to find the LCOV coverage report of libav anywhere :( I've tried googling, as well as a lucky-guess with coverage.libav.org (similar to ffmpeg's URL [1]), but to no avail. It might be nice to have the links to LCOV maybe in the FATE docs [2] or the GcovCoverageHowTo [3] maybe? Thanks, Pb == References: [1] http://coverage.ffmpeg.org/index.html [2] http://www.libav.org/fate.html [3] https://wiki.libav.org/GcovCoverageHowTo ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
On 10/27/2013 12:07 PM, Luca Barbato wrote: On 27/10/13 10:14, Peter B. wrote: How do I add the reference files, required for tests to be able to diff? You can upload to our local ftp[1] and drop me a note. [1] http://upload.libav.org I get a 404 when I go to that URL :( I propose it should be ftp://; instead of http://;. I've uploaded my FFV1 testfiles to: ftp://upload.libav.org/incoming/fate-ffv1 Patch for FFV1 FATE tests will follow as soon as I've cleaned out my try-n-error leftovers ;) Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
On 11/03/2013 12:53 PM, Luca Barbato wrote: On 03/11/13 12:15, Peter B. wrote: I seem to be unable to find the LCOV coverage report of libav anywhere :( I've tried googling, as well as a lucky-guess with coverage.libav.org (similar to ffmpeg's URL [1]), but to no avail. It depends on your options enabled, so it would be meaningful only if we integrate it in FATE, actually might be a neat idea. Ok. So it's not done by default. I just found it nice to be able to compare my FATE results to the official ones, in order to spot LCOV regressions. It might be nice to have the links to LCOV maybe in the FATE docs [2] or the GcovCoverageHowTo [3] maybe? I'll work on it if nobody does before (again projects taking priority). When there's LCOV coverage report generated for libav, you could send me the link and I can try to add it to the docs? Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FFV1 multithreading issue
Hello again, I've noticed that it seems to be that ffmpeg's ffv1 implementation is able to use multiple cores while encoding/decoding FFV1 version 1, whereas libav's current implementation does not: $ time make fate-ffv1.1 SAMPLES=fate-suite THREADS=1 real0m12.013s user0m11.213s sys0m0.504s $ time make fate-ffv1.1 SAMPLES=fate-suite THREADS=8 real0m13.416s user0m12.353s sys0m0.680s In ffmpeg's implementation, I see parallel usage on my CPU graph, as well as the speed is faster with THREADS=8: $ time make SAMPLES=fate-suite fate-ffv1.1 THREADS=1 real0m18.247s user0m16.933s sys0m0.856s $ time make SAMPLES=fate-suite fate-ffv1.1 THREADS=8 real0m14.235s user0m19.717s sys0m1.040s NOTE: ffmpeg's execution time is longer, because it's running 4 additional tests which aren't done in libav's testset. I remember something about a change by Niedermayer which greatly improved decoding speeds of FFV1.1. I think it correlated with the switching to threadframe [1]. Maybe...? Don't know the code. Regards, Pb == References: [1] http://git.videolan.org/?p=ffmpeg.git;a=commit;h=69cfe63a43f43207f72fd677c47eafcf58fcfd13 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] fate: Add FFV1 tests
My very first patch being reviewed. YAY! :) Thanks for checking it out. --- /dev/null +++ b/tests/fate/ffv1.mak @@ -0,0 +1,284 @@ +# +# FATE tests for FFV1 lossless video codec +# This is unnecessary. Clear. I'm just used to putting such a small header on all my scripts. Habit ;) Get rid of all the tabs. trailing whitespace, more below Roger that. Will be fixed. Don't include the file from here, include it from tests/Makefile instead. Roger that. I thought so too at first, but then considered it a nice-to-have to be able to have a make-target for running all lossless-video FATE tests in one. But I'll put it in tests/Makefile. No problem. I'll update/fix the Makefile and then send the improved patch. Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1 multithreading issue
On 11/03/2013 02:27 PM, Luca Barbato wrote: The libav implementation doesn't have threading support, adding it might be useful indeed, please open a set of bugs regarding all the issues you find on FFV1. I've now created tickets for the following observations: 1) Issue: FFV1: Incorrectly encoding pix_fmts gbrp9/gbrp10 https://bugzilla.libav.org/show_bug.cgi?id=582 2) Issue: FFV1: Incorrectly encoding pix_fmts gray/gray16 FFV1.3 https://bugzilla.libav.org/show_bug.cgi?id=583 3) Issue: FFV1: Multithreading for FFV1.1 https://bugzilla.libav.org/show_bug.cgi?id=584 4) Issue: FFV1: Current implementation cannot handle pix_fmt: gbrp14 https://bugzilla.libav.org/show_bug.cgi?id=585 I hope that's ok so? Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] avconv still treats FFV1.3 as experimental
Hello, I've been working on a clean suite of FFV1 tests, and it seems that the Libav's code still considers FFV1 version 3 as experimental, although Version 3 was officially marked as released at the end of August 2013. I have verified it with the current git head: --- $ ./avconv -i fate-suite/prores/prores_with_transparency.mov -an -c:v ffv1 -level 3 delme.avi --- Returns the following: --- avconv version v9-2433-g5928b29, Copyright (c) 2000-2013 the Libav developers built on Nov 2 2013 18:47:37 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x25b9800] Could not find codec parameters (Data: tmcd / 0x64636D74, 0 kb/s) Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'fate-suite/prores/prores_with_transparency.mov': Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt creation_time : 2012-09-12 08:48:56 Duration: 00:00:00.04, start: 0.00, bitrate: 43461 kb/s Stream #0.0(eng): Video: prores, yuva444p10le, 1920x1080, 40697 kb/s, PAR 1:1 DAR 16:9, 25 fps, 25 tbn (default) Metadata: creation_time : 2012-09-12 08:48:56 Stream #0.1(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: creation_time : 2012-09-12 08:48:56 Stream #0.2(eng): Data: tmcd / 0x64636D74, 0 kb/s (default) Metadata: creation_time : 2012-09-12 08:48:57 [ffv1 @ 0x25c05c0] Version 3 requested, please set -strict experimental in order to enable it Output #0, avi, to 'delme.avi': Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt creation_time : 2012-09-12 08:48:56 Stream #0.0(eng): Video: ffv1, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc (default) Metadata: creation_time : 2012-09-12 08:48:56 Stream mapping: Stream #0:0 - #0:0 (prores - ffv1) Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height --- I've created ticket #581 for this: https://bugzilla.libav.org/show_bug.cgi?id=581 Thank you very much in advance, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] avconv still treats FFV1.3 as experimental
On 11/02/2013 08:39 PM, Luca Barbato wrote: Till I do not have at least the test suite you are producing (I gave up on having readable documentation), I cannot be sure what we have matches the other implementation. Ah, ok! Didn't understand that you needed the FATE tests for this. Sorry... Well, I've now tried to create the ffv1.mak in a way that works for testing FFV1 in ffmpeg and libav. My FATE tests run fine with ffmpeg (git head). With current avconv from libav git head, I ran into the following issues with FFV1: 1) vsynth1.yuv in ffv1 using pix_fmt gray is encoded incorrectly. 2) vsynth1.yuv in ffv1 using pix_fmt gray16 is encoded incorrectly. 3) pix_fmt gbrp9 and gbrp10 are encoded incorrectly. 4) pix_fmt gbrp14 is not supported. FFV1 currently cannot do gbrp16, but supports RGB with 14 bits per component (gbrp14) in ffmpeg. Commandlines for each issue: 1) avconv -nostats -cpuflags all -f rawvideo -s 352x288 -pix_fmt yuv420p -threads 8 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -threads 8 -thread_type frame+slice -i tests/data/vsynth1.yuv -threads 1 -idct simple -dct fastint -c ffv1 -level 3 -g 1 -coder 0 -context 0 -slices 24 -slicecrc 0 -pix_fmt gray -strict experimental -flags +bitexact -sws_flags +accurate_rnd+bitexact -f avi -y tests/data/fate/ffv1-enc-v3-gray.avi 2) avconv -nostats -cpuflags all -f rawvideo -s 352x288 -pix_fmt yuv420p -threads 8 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -threads 8 -thread_type frame+slice -i tests/data/vsynth1.yuv -threads 1 -idct simple -dct fastint -c ffv1 -level 3 -g 1 -coder 1 -context 0 -slices 24 -slicecrc 0 -pix_fmt gray16 -strict experimental -flags +bitexact -sws_flags +accurate_rnd+bitexact -f avi -y tests/data/fate/ffv1-enc-v3-gray16.avi 3) avconv -nostats -cpuflags all -f rawvideo -s 352x288 -pix_fmt yuv420p -threads 8 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -threads 8 -thread_type frame+slice -i tests/data/vsynth1.yuv -threads 1 -idct simple -dct fastint -c ffv1 -level 3 -g 1 -coder 0 -context 0 -slices 24 -slicecrc 0 -pix_fmt gbrp9 -strict experimental -flags +bitexact -sws_flags +accurate_rnd+bitexact -f avi -y tests/data/fate/ffv1-enc-v3-gbrp9.avi 4) avconv -nostats -cpuflags all -f rawvideo -s 352x288 -pix_fmt yuv420p -threads 8 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -threads 8 -thread_type frame+slice -i tests/data/vsynth1.yuv -threads 1 -idct simple -dct fastint -c ffv1 -level 3 -g 1 -coder 0 -context 0 -slices 24 -slicecrc 0 -pix_fmt gbrp14 -strict experimental -flags +bitexact -sws_flags +accurate_rnd+bitexact -f avi -y tests/data/fate/ffv1-enc-v3-gbrp14.avi How to proceed? Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
On 10/29/2013 08:57 PM, Luca Barbato wrote: On 10/28/2013 03:18 PM, Peter B. wrote: All the videos used for these tests could actually be generated, but I don't know how to add commands for generating the videos in FATE automatically so they are available for the actual tests. Could anyone point me at examples for doing so? I would still need an answer on this. I'd like to reduce my current fate-suite/ffv1 sample set size of ~9.9 MiB, by generating the required videos by FATE, instead of having to upload them to the fate-suite files. Is that possible? Yes we can have first the encoder test check against a reference and then use the produced files to check the decoder. Sounds a good idea. I'm right now trying to implement this. I've found out that the files generated during the encoding tests are stored in tests/data/fate. Is there any variable, I could use in the .mak files for the FATE tests, that points to that location? Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
Hello again, I've now added encoding tests, too. The current coverage of FFV1 in my setup is now: Filename | Line Coverage | Functions | Branches ffv1.c 99.0 % 101 / 102 100.0 % 7 / 7 80.0 % 48 / 60 ffv1.h 100.0 % 49 / 49 100.0 % 2 / 2 81.8 % 18 / 22 ffv1dec.c 77.9 % 475 / 610 100.0 % 16 / 16 55.7 % 307 / 551 ffv1enc.c 73.6 % 452 / 614 84.6 % 11 / 13 43.5 % 365 / 839 On 10/28/2013 03:18 PM, Peter B. wrote: All the videos used for these tests could actually be generated, but I don't know how to add commands for generating the videos in FATE automatically so they are available for the actual tests. Could anyone point me at examples for doing so? I would still need an answer on this. I'd like to reduce my current fate-suite/ffv1 sample set size of ~9.9 MiB, by generating the required videos by FATE, instead of having to upload them to the fate-suite files. Is that possible? If so, I'd be happy if someone could provide me hints to where to find an example or documentation for this. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
Quoting Luca Barbato lu_z...@gentoo.org: On 27/10/13 10:14, Peter B. wrote: 1) How do I add the reference files, required for tests to be able to diff? You can upload to our local ftp[1] and drop me a note. I'd like to keep the set of testvideos as small as possible, but I'm trying to improve the LCOV coverage of the FFV1 tests as high as possible. I've seen that the current FFV1 tests were in vcodec.mak, and if I understood it correctly, only encoding of 2 videos was tested. No decoding. Therefore, I've added additional FFV1 tests to lossless-video.mak, and transcoded the files used for Lagarith FATE-tests to a new folder in fate-suite/ffv1. Next to the Lagarith testvideos, I've used 4 frames of a test-signal generated by us, because the Lagarith videos were mainly still images, and I wanted to have at least a few frames with a visual change in them. So far my files used for FFV1 testing are around 8,5 MiB in total. I have several files for different pix_fmts to test decoding as thoroughly as necessary. All the videos used for these tests could actually be generated, but I don't know how to add commands for generating the videos in FATE automatically so they are available for the actual tests. Could anyone point me at examples for doing so? If there are any objections or suggestions regarding this approach, I'm happy to hear about them, so I can learn. 2) How do I get a LCOV HTML report locally? https://wiki.libav.org/GcovCoverageHowTo Worked (almost) perfectly. Thank you very much! I had to add -b . to the command shown in your Wiki, in order for lcov to find the source. So my call looks as follows: [quote] $ lcov -b . --directory . --capture --output-file coverage.info [/quote] I've already used it with my new FFV1 set, and the line-coverage for ffv1dec.c already increased. I've seen in FFmpeg's docs about lcov [1], that they've included Makefile-rules, such as: - make lcov: for generating HTML output - make lcov-reset: for resetting coverage measurements Do these also work in Libav? (They're not mentioned in your HowTo, so I thought I'd ask) Regards, Pb == References: [1] http://www.ffmpeg.org/developer.html ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add ffv1.0 test
I was trying to read myself into FATE, in order to be able to add additional tests for FFV1. I've already read the documentation about FATE [1], and I've already managed to add new testing rules for FFV1 (in tests/fate/vcodec.mak). btw: The FATE docs [1] only describe how to run the existing tests, but I didn't find information about how to create new ones. So far so good, but now I have some questions: 1) How do I add the reference files, required for tests to be able to diff? 2) How do I get a LCOV HTML report locally? I'd like to cover more lines of FFV1's code, and therefore would like to be able to view the LCOV - code coverage report [2] from my local tests. I assumed that running the fate.sh script for submitting FATE results would create those HTML pages. I've created a fate_config.sh file, based on doc/fate_config.sh.template and ran the tests. Now I've got the $workdir with the compile.log, configure.log, report, etc. Any suggestions how I could have a local LCOV view? Thanks and regards, Pb == References: [1] http://www.libav.org/fate.html [2] http://coverage.ffmpeg.org/ffmpeg/libavcodec/ffv1enc.c.gcov.html ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/25/2013 12:32 PM, Luca Barbato wrote: E.g. you encode parkjoy using all the ffv1 version .1 features, then you do the same using version .2, then .3 and so on. This way I can make sure the decoder I'm updating is working fine, then I'll do the opposite encoding, making sure the bitstream produced is correct. This kind of samples (small and short) are what we use in FATE to do regression testing. I think I got the idea. If I got it right, then it would make sense to have different samples from e.g. Derf's collection with different properties (resolution, pix_fmt), right? I mention different properties, because back then in the FFV1.3 test series I ran into issues that only appeared with e.g. certain pix_fmts, resolutions - in combination with certain parameters. Where would I find the video-samples already used for FFV1 or other codecs? Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/26/2013 01:29 PM, Luca Barbato wrote: On 26/10/13 13:16, Peter B. wrote: Where would I find the video-samples already used for FFV1 or other codecs? Beside Derf's collection I'm not sure. No, I meant where are the video-samples that people have already cut/prepared for other FATE tests? Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/26/2013 01:55 PM, Peter B. wrote: No, I meant where are the video-samples that people have already cut/prepared for other FATE tests? Nevermind. I think I found them. I read [1] and [2], and rsync'ed the fate-suite into a new folder. I'll read up on creating FATE test scenarios, and possibly return with questions ;) Regards, Pb == References: [1] http://www.ffmpeg.org/fate.html [2] http://www.libav.org/fate.html ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/24/2013 11:52 PM, Ronald S. Bultje wrote: Hi, On Thu, Oct 24, 2013 at 5:29 PM, Peter B. p...@das-werkstatt.com wrote: On 10/21/2013 12:43 AM, Luca Barbato wrote: Basically you should make sample files (so 1 frame or 3 frame sample) that sports specific corner cases or common cases. e.g. all the kind of capture you want to make using it. Like, e.g. VHS, DigiBeta, etc? If so, then how many different samples should I provide? The ones I have are usually in yuv422p. People typically use more standardized existing content, such as: http://media.xiph.org/video/derf/ Hm... So, it seems that I didn't yet fully understand the purpose of the provided samples. I know the Derf Collection at Xiph.org very well, and I've ran mass-tests for FFV1 on them during FFV1.3 development [1]. Luca Barbato said to provide 1-3 frame samples of all the kind of capture you want to make using it. Comparing the results from tests with the Derf Collection (and others, e.g. VQEG [2]) to our archive material, I've noticed that there are big differences, regarding the original source media of the video. The Derf collection, btw. also does not contain any material in 720x576 [3] - which is a common resolution for capturing PAL material. So, which samples would you like? I would also appreciate it, if you could point me somewhere to read up on what you are actually testing in this case, so I could understand the choice of samples myself :) Regards, Pb == References: [1] http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ [2] ftp://vqeg.its.bldrdoc.gov/ [3] http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ffv1_gopdiff-sd-yuv.html ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/21/2013 12:43 AM, Luca Barbato wrote: Basically you should make sample files (so 1 frame or 3 frame sample) that sports specific corner cases or common cases. e.g. all the kind of capture you want to make using it. Like, e.g. VHS, DigiBeta, etc? If so, then how many different samples should I provide? The ones I have are usually in yuv422p. release it under a liberal license (so I can keep it in the fate repository w/out qualms) and you'll make my life much easier =) That, of course, goes without saying :) Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/20/2013 05:13 PM, Luca Barbato wrote: There are updates, will take some time to sync them up, would be nice having proper documentation, but I guess extracting it from the code will be the fast route. Yes, I also guess that this will be the practically fastest way. Thanks, if you're going to synchronize the code. If you really care about ffv1 a standard set of vectors to try it would be needed as well. (compare vp8, vp9, h264 and hevc in this regard) I must admit that my videocodec-foo is too weak to really be able to comment on this. Could you point me to the right resources, so I could do some reading-up on this one? Thank you very much in advance, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFV1.3 released: How is libav's implementation status?
On 10/02/2013 04:07 PM, Luca Barbato wrote: On 02/10/13 15:57, Peter B. wrote: Does the current libav version match the official release implementation? Unfortunately, I hadn't had time to run interoperability tests yet, so I thought I'd ask first. To my knowledge it didn't see any update, I'll check if there is something changed. Thank you very much :) Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FFV1.3 released: How is libav's implementation status?
Since you added these FFV1.0 fate tests, I was curious to ask about libav's implementation-status of FFV1.3, now that it's bitstream was finally frozen and released as stable. Does the current libav version match the official release implementation? Unfortunately, I hadn't had time to run interoperability tests yet, so I thought I'd ask first. Thank you very much, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Contract development for mpeg-2 decoding
On 01/26/2013 03:49 PM, kenneth.el...@thomsonreuters.com wrote: I also realized you asked for more info, and I never really answered. We're playing out that video through VLC with the decklink output plugin, to the SDI output of a decklink card, to an interlaced studio monitor and a linear editing system. Quality is very important and we can't deinterlace. We also want the playout controls of VLC. @Kenneth: Sounds interesting. Would you be so kind and tell me which plugin you're using to output over Decklink's SDI in VLC? So far, we've done that using the Media Lovin' Toolkit (MLT) apps [1], but we're planning to continue our A/D converter testing [2] and having more options to output over SDI might come in handy... :) Also, for BlackMagic, what's the issue you mentioned with their software? Let me know, I'll communicate it to them. They have gotten much better recently responding to issues. Same offer here. Thanks in advance, Peter B. == References: [1] http://www.mltframework.org/ [2] http://www.dva-profession.mediathek.at/fidelity_analyzer/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Contract development for mpeg-2 decoding
On 01/26/2013 08:57 PM, Luca Barbato wrote: Same offer here. Hopefully if enough people pester them they will maybe consider either providing a plain C api or just document their kernel device and let people drive it as they like. I've recently tried to explain within the archiving community (on the Association of Moving Image Archivists (AMIA) mailing list [1]) how, and why, I think we should increase requirement of openness from hardware vendors in order to get high-quality, sustainable equipment for our use-cases [2] in a way that'd be very profitable for them, too. ...instead of just living with the leftovers from broadcasters or consumer-grade equipment ;) With digital video use-cases (and therefore demand for hardware) increasing, Blackmagic might be clever enough to see their opportunity if they'd enable others to use their hardware besides their constrained market use-cases. If they did, they might turn into the WRT-54GL [3] of capture/playback cards and go down in history. Who knows... Regards, Pb == References: [1] http://www.amianet.org/participate/listserv.php [2] http://lsv.uky.edu/scripts/wa.exe?A2=ind1212L=amia-lF=S=P=30612 [3] http://en.wikipedia.org/wiki/Linksys_WRT54G_series ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ffv1.3 framemd5: segmentation fault
On 10/25/2012 05:29 PM, Luca Barbato wrote: On 10/24/2012 04:52 PM, Peter B. wrote: I've just seen that it also segfaults with files produced by avconv: The original problem was due me not resetting the transition states, that part might be clarified in the specification so others won't do the same mistake. Next will be figuring out why it segfaults on corrupted input. I've re-generated framemd5 checksums for waterfall_cif ffv1.3 and no segfault. Seems to work! Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ffv1.3 framemd5: segmentation fault
When creating framemd5 checksums of a FFv1.3 file created with ffmpeg, I sometimes get a segfault with avconv. Example: Input video is waterfall_cif.y4m from Derf's collection at xiph.org [1]. //- $ ffmpeg -i input/xiph-derf/bis_SD/waterfall_cif.y4m -an -vcodec ffv1 -level 3 -context 1 -coder 1 -g 300 -threads 8 -strict experimental -slices 30 -slicecrc 1 waterfall_ffv1.avi //- ffmpeg version N-45924-ge2820d9 Copyright (c) 2000-2012 the FFmpeg developers built on Oct 23 2012 20:00:42 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) configuration: --prefix=/usr/local --enable-gpl --enable-nonfree --enable-version3 --enable-postproc --enable-swscale --enable-avfilter --enable-pthreads --enable-bzlib --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-zlib --enable-libopenjpeg --enable-decoder=png --enable-encoder=png --enable-libfreetype --enable-libschroedinger libavutil 52. 0.100 / 52. 0.100 libavcodec 54. 68.100 / 54. 68.100 libavformat54. 34.100 / 54. 34.100 libavdevice54. 3.100 / 54. 3.100 libavfilter 3. 20.104 / 3. 20.104 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 16.100 / 0. 16.100 libpostproc52. 1.100 / 52. 1.100 [yuv4mpegpipe @ 0x3313240] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from 'input/xiph-derf/bis_SD/waterfall_cif.y4m': Duration: N/A, bitrate: N/A Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 352x288, SAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc Output #0, avi, to 'waterfall_ffv1.avi': Metadata: ISFT: Lavf54.34.100 Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 352x288 [SAR 128:117 DAR 1408:1053], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc Stream mapping: Stream #0:0 - #0:0 (rawvideo - ffv1) Press [q] to stop, [?] for help frame= 260 fps=0.0 q=0.0 Lsize= 21983kB time=00:00:08.67 bitrate=20758.1kbits/s video:21971kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.053888% //- //- $ avconv -i waterfall_ffv1.avi -an -f framemd5 waterfall_avconv.framemd5 //- avconv version v9_beta1-212-g5e28e97, Copyright (c) 2000-2012 the Libav developers built on Oct 23 2012 20:39:35 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) [ffv1 @ 0x1b057a0] quant_table_index out of range [ffv1 @ 0x1b057a0] bytestream end mismatching by 1650 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1255 [ffv1 @ 0x1b057a0] bytestream end mismatching by 997 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1225 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1290 [ffv1 @ 0x1b057a0] quant_table_index out of range [ffv1 @ 0x1b057a0] bytestream end mismatching by 1630 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1172 [ffv1 @ 0x1b057a0] quant_table_index out of range Last message repeated 1 times [ffv1 @ 0x1b057a0] bytestream end mismatching by 1790 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1462 [ffv1 @ 0x1b057a0] quant_table_index out of range Last message repeated 2 times [ffv1 @ 0x1b057a0] bytestream end mismatching by 982 [ffv1 @ 0x1b057a0] bytestream end mismatching by 395 [ffv1 @ 0x1b057a0] bytestream end mismatching by -734 Input #0, avi, from 'waterfall_ffv1.avi': Metadata: encoder : Lavf54.34.100 Duration: 00:00:08.67, start: 0.00, bitrate: 20758 kb/s Stream #0.0: Video: ffv1, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn Output #0, framemd5, to 'waterfall_avconv.framemd5': Metadata: encoder : Lavf54.19.0 Stream #0.0: Video: rawvideo, yuv420p, 352x288 [PAR 128:117 DAR 1408:1053], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc Stream mapping: Stream #0:0 - #0:0 (ffv1 - rawvideo) Press ctrl-c to stop encoding [ffv1 @ 0x1b057a0] quant_table_index out of range Last message repeated 3 times [ffv1 @ 0x1b057a0] bytestream end mismatching by 1225 [ffv1 @ 0x1b057a0] quant_table_index out of range Last message repeated 3 times [ffv1 @ 0x1b057a0] bytestream end mismatching by 1290 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1172 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1630 [ffv1 @ 0x1b057a0] bytestream end mismatching by 982 [ffv1 @ 0x1b057a0] bytestream end mismatching by 395 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1255 [ffv1 @ 0x1b057a0] bytestream end mismatching by 997 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1650 [ffv1 @ 0x1b057a0] bytestream end mismatching by -734 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1790 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1462 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1658 [ffv1 @ 0x1b057a0] bytestream end mismatching by 1760 [ffv1 @ 0x1b057a0] quant_table_index out of range Last message repeated 5 times [ffv1 @ 0x1b057a0] bytestream end mismatching by 2758 [ffv1 @ 0x1b057a0] bytestream end mismatching by 2020
Re: [libav-devel] [PATCH] mention plan 9 support in the changelog
On 10/24/2012 10:23 AM, Reinhard Tartler wrote: On Wed, Oct 24, 2012 at 10:14 AM, Kostya Shishkov kostya.shish...@gmail.com wrote: On Wed, Oct 24, 2012 at 10:06:22AM +0200, Reinhard Tartler wrote: maybe support FFv1 codec version 3 as well? 1.3 maybe? The commit message reads: ffv1: update to ffv1 version 3 Luca, can you clarify how this reads best? I know I wasn't asked, but in practice the new version of FFv1 turned out to be referred to as FFv1.3. Additionally, update to ffv1 version 3 sounds like version 1 would have been replaced, which is not true. What about something like: ffv1: Added support for version 3 (FFv1.3) Just my 2 cents. Regards, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ffv1.3 framemd5: segmentation fault
I've just seen that it also segfaults with files produced by avconv: //--- $ avconv -i waterfall_cif.y4m -an -vcodec ffv1 -level 3 -context 1 -coder 1 -g 300 -threads 8 -strict experimental -slices 30 -slicecrc 1 waterfall_ffv1.avi - avconv version v9_beta1-212-g5e28e97, Copyright (c) 2000-2012 the Libav developers built on Oct 23 2012 20:39:35 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) [yuv4mpegpipe @ 0x2fdf760] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from 'waterfall_cif.y4m': Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn Output #0, avi, to 'waterfall_ffv1.avi': Metadata: ISFT: Lavf54.19.0 Stream #0.0: Video: ffv1, yuv420p, 352x288 [PAR 128:117 DAR 1408:1053], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc Stream mapping: Stream #0:0 - #0:0 (rawvideo - ffv1) Press ctrl-c to stop encoding frame= 260 fps= 0 q=0.0 Lsize= 21983kB time=8.68 bitrate=20758.1kbits/s video:21971kB audio:0kB global headers:0kB muxing overhead 0.053880% Execution return value: 0 Encoding finished: Wed Oct 24 11:59:20 CEST 2012 ffprobe version N-45924-ge2820d9 Copyright (c) 2007-2012 the FFmpeg developers built on Oct 23 2012 20:00:42 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) configuration: --prefix=/usr/local --enable-gpl --enable-nonfree --enable-version3 --enable-postproc --enable-swscale --enable-avfilter --enable-pthreads --enable-bzlib --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-zlib --enable-libopenjpeg --enable-decoder=png --enable-encoder=png --enable-libfreetype --enable-libschroedinger libavutil 52. 0.100 / 52. 0.100 libavcodec 54. 68.100 / 54. 68.100 libavformat54. 34.100 / 54. 34.100 libavdevice54. 3.100 / 54. 3.100 libavfilter 3. 20.104 / 3. 20.104 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 16.100 / 0. 16.100 libpostproc52. 1.100 / 52. 1.100 Input #0, avi, from 'waterfall_ffv1.avi': Metadata: encoder : Lavf54.19.0 Duration: 00:00:08.67, start: 0.00, bitrate: 20758 kb/s Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 352x288, SAR 128:117 DAR 1408:1053, 29.97 tbr, 29.97 tbn, 29.97 tbc //--- == ./avconv -i waterfall_ffv1.avi -an -f framemd5 waterfall_ffv1.avi.avconv.framemd5 - Waiting 0 seconds... avconv version v9_beta1-212-g5e28e97, Copyright (c) 2000-2012 the Libav developers built on Oct 23 2012 20:39:35 with gcc 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) [ffv1 @ 0x1668800] quant_table_index out of range [ffv1 @ 0x1668800] bytestream end mismatching by 1650 [ffv1 @ 0x1668800] bytestream end mismatching by 1255 [ffv1 @ 0x1668800] bytestream end mismatching by 997 [ffv1 @ 0x1668800] bytestream end mismatching by 1225 [ffv1 @ 0x1668800] bytestream end mismatching by 1290 [ffv1 @ 0x1668800] quant_table_index out of range [ffv1 @ 0x1668800] bytestream end mismatching by 1630 [ffv1 @ 0x1668800] bytestream end mismatching by 1172 [ffv1 @ 0x1668800] quant_table_index out of range Last message repeated 1 times [ffv1 @ 0x1668800] bytestream end mismatching by 1790 [ffv1 @ 0x1668800] bytestream end mismatching by 1462 [ffv1 @ 0x1668800] quant_table_index out of range Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 982 [ffv1 @ 0x1668800] bytestream end mismatching by 395 [ffv1 @ 0x1668800] bytestream end mismatching by -734 Input #0, avi, from 'waterfall_ffv1.avi': Metadata: encoder : Lavf54.19.0 Duration: 00:00:08.67, start: 0.00, bitrate: 20758 kb/s Stream #0.0: Video: ffv1, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn Output #0, framemd5, to 'waterfall_ffv1.avi.avconv.framemd5': Metadata: encoder : Lavf54.19.0 Stream #0.0: Video: rawvideo, yuv420p, 352x288 [PAR 128:117 DAR 1408:1053], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc Stream mapping: Stream #0:0 - #0:0 (ffv1 - rawvideo) Press ctrl-c to stop encoding [ffv1 @ 0x1668800] quant_table_index out of range Last message repeated 3 times [ffv1 @ 0x1668800] bytestream end mismatching by 1172 [ffv1 @ 0x1668800] quant_table_index out of range Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 1630 Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 1650 Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 997 Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 1255 Last message repeated 2 times [ffv1 @ 0x1668800] bytestream end mismatching by 1290 [ffv1 @ 0x1668800] bytestream end mismatching by 982 [ffv1 @ 0x1668800] bytestream end mismatching by 1462 [ffv1 @ 0x1668800] bytestream end mismatching by 395 [ffv1 @ 0x1668800]
Re: [libav-devel] ffv1.3 support - Unrecognized option 'slicecrc'
On 10/20/2012 12:15 AM, Peter B. wrote: On 10/19/2012 08:30 PM, Luca Barbato wrote: slicecrc should be supported. The version I've compiled now does. Before it was complaining that the commandline argument slicecrc is unknown. Sorry! Mistake in my testscript. It was still using ffmpeg instead of avconv. So, here's the commandline and uncut console output, where your githead ffv1 version complains about slicecrc: //== avconv -i /media/verbatim_vf/DVA-Profession/Testvideos/xiph-derf/bis_SD/foreman_cif.y4m -an -vcodec ffv1 -level 3 -context 0 -coder 0 -g 1 -threads 8 -strict experimental -slices 4 -slicecrc 0 /home/pb/Videos/ffv1-avconv-SD/video/foreman_cif/foreman_cif-./avconv_3l_0cn_0c_001g_08t_04s_0crc.avi //-- avconv version c9e04a1, Copyright (c) 2000-2011 the Libav developers built on Oct 19 2012 23:43:26 with gcc 4.6.1 [yuv4mpegpipe @ 0x2a4e760] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from '/media/verbatim_vf/DVA-Profession/Testvideos/xiph-derf/bis_SD/foreman_cif.y4m': Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc Unrecognized option 'slicecrc' Failed to set value '0' for option 'slicecrc' Execution return value: 1 Encoding finished: Sat Oct 20 12:21:39 CEST 2012 Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ffv1: import ffv1.3 support
Sorry, but I've slightly lost track... Which patches must now be applied to which code-tree in order to be able to test ffv1.3 support? I've tried applying the following patches to libav's git-head: 1) import ffv1.3 support (Couldn't find any patch labelled 1/3) 2) [PATCH 2/3] ffv1: propagate errors 3) [PATCH 3/3] ffv1: import ffv1.3 Seems I'm missing the patch which splits ffv1.c into encoder/decoder part. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ffv1.3 support
I've compiled your github libav version including ffv1.3 and it seems that slicecrc is not yet implemented, correct? If you could quickly tell me which features/colorspaces should be working in your implementation, I could run my testsuite and report any findings. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ffv1.3 support
On 10/19/2012 08:30 PM, Luca Barbato wrote: On 10/19/2012 04:43 PM, Peter B. wrote: I've compiled your github libav version including ffv1.3 and it seems that slicecrc is not yet implemented, correct? If you could quickly tell me which features/colorspaces should be working in your implementation, I could run my testsuite and report any findings. Anything but 12 and 13bit pixel formats for now, let me update github with the round of review and fix a little bit the last patch. slicecrc should be supported. The version I've compiled now does. Before it was complaining that the commandline argument slicecrc is unknown. I'm running the full testsuite on the xiph-derf collection's SD-and-below testvideos. Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
On 10/12/2012 12:24 AM, Luca Barbato wrote: On 10/05/2012 05:31 PM, Peter B. wrote: On 10/01/2012 05:30 PM, Luca Barbato wrote: I'm rebasing old patches supporting some pixel formats and possibly I'll have a look at ffv1 to see what really changed. In order to avoid misunderstandings, I wanted to ask if you are trying to merge the new FFv1.3 code into libav, or just the colorspaces? It took me a bit of time, here the not clean yet version. https://github.com/lu-zero/libav/tree/ffv1.3 It compiles, but when I tray to playback a ffv1.3 file created with ffmpeg, it bails out: // -- $ avplay red_kayak_1080p-ffv1.avi // -- avplay version c9e04a1, Copyright (c) 2003-2011 the Libav developers built on Oct 14 2012 20:30:24 with gcc 4.6.1 [ffv1 @ 0x2a34620] read_quant_table error Last message repeated 5 times Input #0, avi, from 'red_kayak_1080p-ffv1.avi': Metadata: encoder : Lavf54.29.105 Duration: 00:00:19.01, start: 0.00, bitrate: 243608 kb/s Stream #0.0: Video: ffv1, 1920x1080, PAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc [ffv1 @ 0x2a34620] read_quant_table error red_kayak_1080p-ffv1.avi: could not open codecs 1350239842.67 A-V: 0.000 s:0.0 aq=0KB vq=0KB sq=0B f=0/0 // -- I'll repeat the test with a ffv1.3 file created with avconf. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
On 10/14/2012 09:20 PM, Luca Barbato wrote: Could you please provide me a small sample of it? You can generate it, using red_kayak from xiph/derf's collection: http://media.xiph.org/video/derf/y4m/red_kayak_1080p.y4m Using the current git of ffmpeg, create the FFv1.3 video as follows: // $ ffmpeg -i red_kayak_1080p.y4m -an -vcodec ffv1 -strict experimental -level 3 -g 1 -slices 24 -slicecrc 1 red_kayak_1080p-ffv1.avi // Trying to use avplay to view red_kayak_1080p-ffv1.avi returns the previously posted error. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
On 10/12/2012 12:24 AM, Luca Barbato wrote: On 10/05/2012 05:31 PM, Peter B. wrote: On 10/01/2012 05:30 PM, Luca Barbato wrote: I'm rebasing old patches supporting some pixel formats and possibly I'll have a look at ffv1 to see what really changed. In order to avoid misunderstandings, I wanted to ask if you are trying to merge the new FFv1.3 code into libav, or just the colorspaces? It took me a bit of time, here the not clean yet version. https://github.com/lu-zero/libav/tree/ffv1.3 Sorry, was out of country and away from my computer I will take a look at this ASAP. Hopefully on the weekend already. Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
Quoting Luca Barbato lu_z...@gentoo.org:
On 10/01/2012 12:07 AM, Ronald S. Bultje wrote:
Hi,
On Sun, Sep 30, 2012 at 1:00 PM, Peter B. p...@das-werkstatt.com wrote:
+PIX_FMT_0RGB=0x123+4, /// packed RGB 8:8:8, 32bpp, 0RGB0RGB...
+PIX_FMT_RGB0, /// packed RGB 8:8:8, 32bpp, RGB0RGB0...
+PIX_FMT_0BGR, /// packed BGR 8:8:8, 32bpp, 0BGR0BGR...
+PIX_FMT_BGR0, /// packed BGR 8:8:8, 32bpp, BGR0BGR0...
These look wrong. Also, the 0x123+4 value should go, maybe that's a
ffmpeg'ism?
What do you mean with looks wrong?
Sorry, but I've basically copy/pasted pix_fmt definitions supported by
ffv1, which includes RGB0 colorspaces, too.
+PIX_FMT_YUVA444P, /// planar YUV 4:4:4 32bpp, (1 Cr Cb sample
per 1x1 Y A samples)
+PIX_FMT_YUVA422P, /// planar YUV 4:2:2 24bpp, (1 Cr Cb sample
per 2x1 Y A samples)
Might be useful, even if I'm unsure about uses
This might can be used for video production or rendered material which
is then embedded as overlay. For us as archive it is good to have the
opportunity to preserve any alpha-channel information from incoming
video material.
+PIX_FMT_YUV420P12BE, /// planar YUV 4:2:0,18bpp, (1 Cr Cb sample
per 2x2 Y samples), big-endian
+PIX_FMT_YUV420P12LE, /// planar YUV 4:2:0,18bpp, (1 Cr Cb sample
per 2x2 Y samples), little-endian
+PIX_FMT_YUV420P14BE, /// planar YUV 4:2:0,21bpp, (1 Cr Cb sample
per 2x2 Y samples), big-endian
+PIX_FMT_YUV420P14LE, /// planar YUV 4:2:0,21bpp, (1 Cr Cb sample
per 2x2 Y samples), little-endian
+PIX_FMT_YUV422P12BE, /// planar YUV 4:2:2,24bpp, (1 Cr Cb sample
per 2x1 Y samples), big-endian
+PIX_FMT_YUV422P12LE, /// planar YUV 4:2:2,24bpp, (1 Cr Cb sample
per 2x1 Y samples), little-endian
+PIX_FMT_YUV422P14BE, /// planar YUV 4:2:2,28bpp, (1 Cr Cb sample
per 2x1 Y samples), big-endian
+PIX_FMT_YUV422P14LE, /// planar YUV 4:2:2,28bpp, (1 Cr Cb sample
per 2x1 Y samples), little-endian
+PIX_FMT_YUV444P12BE, /// planar YUV 4:4:4,36bpp, (1 Cr Cb sample
per 1x1 Y samples), big-endian
+PIX_FMT_YUV444P12LE, /// planar YUV 4:4:4,36bpp, (1 Cr Cb sample
per 1x1 Y samples), little-endian
+PIX_FMT_YUV444P14BE, /// planar YUV 4:4:4,42bpp, (1 Cr Cb sample
per 1x1 Y samples), big-endian
+PIX_FMT_YUV444P14LE, /// planar YUV 4:4:4,42bpp, (1 Cr Cb sample
per 1x1 Y samples), little-endian
+PIX_FMT_GBRP12BE,/// planar GBR 4:4:4 36bpp, big endian
+PIX_FMT_GBRP12LE,/// planar GBR 4:4:4 36bpp, little endian
+PIX_FMT_GBRP14BE,/// planar GBR 4:4:4 42bpp, big endian
+PIX_FMT_GBRP14LE,/// planar GBR 4:4:4 42bpp, little endian
These look OK.
Are the 14bit used?
In FFv1.3 the 12 and 14bits are only used with RGB colorspace support,
not in YUV (yet).
Aren't their entries in the relevant table in libavutil/pixdesc.c missing?
Sorry. New to the ffmpeg/libav arch... :(
I've removed unused pix_fmts from my patch (0-padded RGB, for example)
and added entries in pixdesc.c. It compiles correctly, so I assume
there's no syntax error at least.
I also took the liberty to resort some entries to have their lower
bitsize first. e.g.: YUV bits-per-component: 8, 9, 10, 16 - YUV444 for
example had it ordered in reverse.
Which would be the preferred way for patches in the future on this list?
Regards,
Pb
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 122072e..ec76171 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -527,6 +527,32 @@ const AVPixFmtDescriptor av_pix_fmt_descriptors[PIX_FMT_NB] = {
},
.flags = PIX_FMT_PLANAR,
},
+[PIX_FMT_YUVA422P] = {
+.name = yuva422p,
+.nb_components = 4,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 0, 1, 0, 7 },/* Y */
+{ 1, 0, 1, 0, 7 },/* U */
+{ 2, 0, 1, 0, 7 },/* V */
+{ 3, 0, 1, 0, 7 },/* A */
+},
+.flags = PIX_FMT_PLANAR,
+},
+[PIX_FMT_YUVA444P] = {
+.name = yuva444p,
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 0, 1, 0, 7 },/* Y */
+{ 1, 0, 1, 0, 7 },/* U */
+{ 2, 0, 1, 0, 7 },/* V */
+{ 3, 0, 1, 0, 7 },/* A */
+},
+.flags = PIX_FMT_PLANAR,
+},
[PIX_FMT_VDPAU_H264] = {
.name = vdpau_h264,
.log2_chroma_w = 1,
@@ -923,27 +949,27 @@ const AVPixFmtDescriptor av_pix_fmt_descriptors[PIX_FMT_NB] = {
},
.flags = PIX_FMT_BE | PIX_FMT_PLANAR,
},
-[PIX_FMT_YUV444P16LE] = {
-.name = yuv444p16le,
+[PIX_FMT_YUV444P9LE] = {
+.name = yuv444p9le,
.nb_components = 3,
.log2_chroma_w = 0,
.log2_chroma_h = 0,
.comp = {
-{ 0, 1, 1, 0, 15 },/* Y */
-{ 1, 1, 1, 0, 15 },/* U
Re: [libav-devel] FFv1.3 support
Quoting Luca Barbato lu_z...@gentoo.org: On 10/01/2012 03:55 PM, Peter B. wrote: I've removed unused pix_fmts from my patch (0-padded RGB, for example) and added entries in pixdesc.c. It compiles correctly, so I assume there's no syntax error at least. Thanks, you are missing few bits in swscale, though. Yes, I just looked at the patches committed for adding YUVA and saw that there are more files involved. Sorry. As I said: I'm not really aware of the code layout of ffmpeg/libav. I also took the liberty to resort some entries to have their lower bitsize first. e.g.: YUV bits-per-component: 8, 9, 10, 16 - YUV444 for example had it ordered in reverse. the order in the enum can't be changed ^^; Oh. ABI reasons? Didn't think about that. Sorry. I'm rebasing old patches supporting some pixel formats and possibly I'll have a look at ffv1 to see what really changed. That would be great! Thank you very much! With FFv1.3 it's not only about additional colorspaces, but the main features of the new version include multithreading (=slices), CRC and aspect ratio support. But of course, take a look for yourself. The main question regarding rgb with more than 10 and less than 16 is where it is used. This was added due to a request from the national film-archive for converting scanned film from DPX with 8 (but 16bit) bit-depth to FFv1. Thank you very much, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
Quoting Luca Barbato lu_z...@gentoo.org: Those are more interesting to me, I prefer adding colorspaces only if the need arises. Understood :) The main question regarding rgb with more than 10 and less than 16 is where it is used. This was added due to a request from the national film-archive for converting scanned film from DPX with 8 (but 16bit) bit-depth to FFv1. So DPX with 12 and 14 bits or 13 is also there (and missing) ? Honestly, I'm not 100% sure about that, because that was coordinated directly between someone from the filmarchive and Georg Lippitsch who implemented the changes. He also modified DPX code as far as I know. I only saw 12 and 14 bits - no 13 so far... He would have wanted to implement RGB with 16 bits-pro-component, but as I understood it, this leads to an overflow issue where the conversion between YUV and RGB cannot be done lossless anymore, so he only implemented it up to 14bits. For high-end material any additional bit 8 is desireable ;) Thanks, Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FFv1.3 support
Hello, I'm working at the Austrian Mediathek (national audio/video archive) and together with other archives we are using FFv1 as our archival video codec. There have been major updates to FFv1, and its version 3 (FFv1.3) is nearing its release. I've tried to merge the code from ffmpeg to the current git-head of libav, but I'm still running into compile errors: //-- libavcodec/ffv1.c: In function ‘encode_slice’: libavcodec/ffv1.c:1245:13: warning: passing argument 2 of ‘put_rac’ from incompatible pointer type [enabled by default] libavcodec/rangecoder.h:82:20: note: expected ‘uint8_t * const’ but argument is of type ‘int *’ libavcodec/ffv1.c: In function ‘encode_frame’: libavcodec/ffv1.c:1286:5: error: implicit declaration of function ‘ff_alloc_packet2’ [-Werror=implicit-function-declaration] libavcodec/ffv1.c: In function ‘decode_slice’: libavcodec/ffv1.c:1680:13: warning: passing argument 2 of ‘get_rac’ from incompatible pointer type [enabled by default] libavcodec/rangecoder.h:110:19: note: expected ‘uint8_t * const’ but argument is of type ‘int *’ libavcodec/ffv1.c:1709:9: warning: passing argument 2 of ‘get_rac’ from incompatible pointer type [enabled by default] libavcodec/rangecoder.h:110:19: note: expected ‘uint8_t * const’ but argument is of type ‘int *’ libavcodec/ffv1.c: In function ‘decode_frame’: libavcodec/ffv1.c:2104:49: error: ‘AVCodecContext’ has no member named ‘pkt_timebase’ libavcodec/ffv1.c:2105:85: error: ‘AVCodecContext’ has no member named ‘pkt_timebase’ libavcodec/ffv1.c:2118:36: warning: cast discards ‘__attribute__((const))’ qualifier from pointer target type [-Wcast-qual] libavcodec/ffv1.c:2136:53: warning: to be safe all intermediate pointers in cast from ‘uint8_t **’ to ‘const uint8_t **’ must be ‘const’ qualified [-Wcast-qual] cc1: some warnings being treated as errors //-- As I'm not familiar with the code structure of neither ffmpeg nor libav, I'd be happy if anyone here could help me out, so libav can support this important format, too. Thanks, Peter B. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
On 09/30/2012 09:16 PM, Luca Barbato wrote: pkt_timebase reference could be dropped, not sure what got changed in the rangecoder let's have a look. What does pkt_timebase do, and which counterpart would exist in libav? Is there a struct-documentation anywhere, btw? Thanks! Pb ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
I forgot to supply my patches which add the newly supported colorspace
definitions:
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -157,6 +157,31 @@
PIX_FMT_GBRP10LE, /// planar GBR 4:4:4 30bpp, little endian
PIX_FMT_GBRP16BE, /// planar GBR 4:4:4 48bpp, big endian
PIX_FMT_GBRP16LE, /// planar GBR 4:4:4 48bpp, little endian
+
+PIX_FMT_0RGB=0x123+4, /// packed RGB 8:8:8, 32bpp, 0RGB0RGB...
+PIX_FMT_RGB0, /// packed RGB 8:8:8, 32bpp, RGB0RGB0...
+PIX_FMT_0BGR, /// packed BGR 8:8:8, 32bpp, 0BGR0BGR...
+PIX_FMT_BGR0, /// packed BGR 8:8:8, 32bpp, BGR0BGR0...
+PIX_FMT_YUVA444P, /// planar YUV 4:4:4 32bpp, (1 Cr Cb sample
per 1x1 Y A samples)
+PIX_FMT_YUVA422P, /// planar YUV 4:2:2 24bpp, (1 Cr Cb sample
per 2x1 Y A samples)
+
+PIX_FMT_YUV420P12BE, /// planar YUV 4:2:0,18bpp, (1 Cr Cb sample
per 2x2 Y samples), big-endian
+PIX_FMT_YUV420P12LE, /// planar YUV 4:2:0,18bpp, (1 Cr Cb sample
per 2x2 Y samples), little-endian
+PIX_FMT_YUV420P14BE, /// planar YUV 4:2:0,21bpp, (1 Cr Cb sample
per 2x2 Y samples), big-endian
+PIX_FMT_YUV420P14LE, /// planar YUV 4:2:0,21bpp, (1 Cr Cb sample
per 2x2 Y samples), little-endian
+PIX_FMT_YUV422P12BE, /// planar YUV 4:2:2,24bpp, (1 Cr Cb sample
per 2x1 Y samples), big-endian
+PIX_FMT_YUV422P12LE, /// planar YUV 4:2:2,24bpp, (1 Cr Cb sample
per 2x1 Y samples), little-endian
+PIX_FMT_YUV422P14BE, /// planar YUV 4:2:2,28bpp, (1 Cr Cb sample
per 2x1 Y samples), big-endian
+PIX_FMT_YUV422P14LE, /// planar YUV 4:2:2,28bpp, (1 Cr Cb sample
per 2x1 Y samples), little-endian
+PIX_FMT_YUV444P12BE, /// planar YUV 4:4:4,36bpp, (1 Cr Cb sample
per 1x1 Y samples), big-endian
+PIX_FMT_YUV444P12LE, /// planar YUV 4:4:4,36bpp, (1 Cr Cb sample
per 1x1 Y samples), little-endian
+PIX_FMT_YUV444P14BE, /// planar YUV 4:4:4,42bpp, (1 Cr Cb sample
per 1x1 Y samples), big-endian
+PIX_FMT_YUV444P14LE, /// planar YUV 4:4:4,42bpp, (1 Cr Cb sample
per 1x1 Y samples), little-endian
+PIX_FMT_GBRP12BE,/// planar GBR 4:4:4 36bpp, big endian
+PIX_FMT_GBRP12LE,/// planar GBR 4:4:4 36bpp, little endian
+PIX_FMT_GBRP14BE,/// planar GBR 4:4:4 42bpp, big endian
+PIX_FMT_GBRP14LE,/// planar GBR 4:4:4 42bpp, little endian
+
PIX_FMT_NB,/// number of pixel formats, DO NOT USE THIS if
you want to link with shared libav* because the number of formats might
differ between versions
};
@@ -170,6 +195,8 @@
#define PIX_FMT_RGB32_1 PIX_FMT_NE(RGBA, ABGR)
#define PIX_FMT_BGR32 PIX_FMT_NE(ABGR, RGBA)
#define PIX_FMT_BGR32_1 PIX_FMT_NE(BGRA, ARGB)
+#define PIX_FMT_0RGB32 PIX_FMT_NE(0RGB, BGR0)
+#define PIX_FMT_0BGR32 PIX_FMT_NE(0BGR, RGB0)
#define PIX_FMT_GRAY16 PIX_FMT_NE(GRAY16BE, GRAY16LE)
#define PIX_FMT_RGB48 PIX_FMT_NE(RGB48BE, RGB48LE)
@@ -187,12 +214,20 @@
#define PIX_FMT_YUV420P10 PIX_FMT_NE(YUV420P10BE, YUV420P10LE)
#define PIX_FMT_YUV422P10 PIX_FMT_NE(YUV422P10BE, YUV422P10LE)
#define PIX_FMT_YUV444P10 PIX_FMT_NE(YUV444P10BE, YUV444P10LE)
+#define PIX_FMT_YUV420P12 PIX_FMT_NE(YUV420P12BE, YUV420P12LE)
+#define PIX_FMT_YUV422P12 PIX_FMT_NE(YUV422P12BE, YUV422P12LE)
+#define PIX_FMT_YUV444P12 PIX_FMT_NE(YUV444P12BE, YUV444P12LE)
+#define PIX_FMT_YUV420P14 PIX_FMT_NE(YUV420P14BE, YUV420P14LE)
+#define PIX_FMT_YUV422P14 PIX_FMT_NE(YUV422P14BE, YUV422P14LE)
+#define PIX_FMT_YUV444P14 PIX_FMT_NE(YUV444P14BE, YUV444P14LE)
#define PIX_FMT_YUV420P16 PIX_FMT_NE(YUV420P16BE, YUV420P16LE)
#define PIX_FMT_YUV422P16 PIX_FMT_NE(YUV422P16BE, YUV422P16LE)
#define PIX_FMT_YUV444P16 PIX_FMT_NE(YUV444P16BE, YUV444P16LE)
#define PIX_FMT_GBRP9 PIX_FMT_NE(GBRP9BE ,GBRP9LE)
#define PIX_FMT_GBRP10PIX_FMT_NE(GBRP10BE,GBRP10LE)
+#define PIX_FMT_GBRP12PIX_FMT_NE(GBRP12BE,GBRP12LE)
+#define PIX_FMT_GBRP14PIX_FMT_NE(GBRP14BE,GBRP14LE)
#define PIX_FMT_GBRP16PIX_FMT_NE(GBRP16BE,GBRP16LE)
#endif /* AVUTIL_PIXFMT_H */
--- a/libavcodec/ffv1.c
+++ b/libavcodec/ffv1.c
@@ -1,7 +1,7 @@
/*
* FFV1 codec for libavcodec
*
- * Copyright (c) 2003 Michael Niedermayer michae...@gmx.at
+ * Copyright (c) 2003-2012 Michael Niedermayer michae...@gmx.at
*
* This file is part of Libav.
*
@@ -26,13 +26,24 @@
*/
#include avcodec.h
+#include internal.h
#include get_bits.h
#include put_bits.h
#include dsputil.h
#include rangecoder.h
#include golomb.h
#include mathops.h
+#include libavutil/pixdesc.h
#include libavutil/avassert.h
+#include libavutil/crc.h
+#include libavutil/opt.h
+#include libavutil/imgutils.h
+#include libavutil/timer.h
+
+#ifdef __INTEL_COMPILER
+#undef av_flatten
+#define av_flatten
+#endif
#define MAX_PLANES 4
#define CONTEXT_SIZE 32
@@ -156,6 +167,7 @@
#define MAX_SLICES 256
typedef struct FFV1Context{
+AVClass *class;
AVCodecContext *avctx;
RangeCoder c;
GetBitContext gb;
@@ -163,13 +175,18 @@
uint64_t rc_stat[256][2];
uint64_t
