Re: [libav-devel] ffv1.3 support - "Unrecognized option 'slicecrc'"
On 10/20/2012 12:25 PM, Peter B. wrote: > 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": Should work fine and is in master (and soon in 9beta2). avconv -v debug -i /var/tmp/ducks_take_off_420_720p50.y4m -c ffv1 -level 3 -context 0 -coder 0 -g 1 -strict experimental -slices 4 -slicecrc 0 out.nut avconv version v9_beta1-157-gee6fb9d, Copyright (c) 2000-2012 the Libav developers built on Oct 22 2012 22:22:25 with gcc 4.7.2 (Gentoo 4.7.2 p1.1, pie-0.5.5) configuration: libavutil 51. 45. 0 / 51. 45. 0 libavcodec54. 31. 0 / 54. 31. 0 libavformat 54. 19. 0 / 54. 19. 0 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter3. 1. 0 / 3. 1. 0 libavresample 1. 0. 0 / 1. 0. 0 libswscale 2. 1. 1 / 2. 1. 1 [yuv4mpegpipe @ 0x1850760] Probed with size=2048 and score=100 [yuv4mpegpipe @ 0x1850760] Probe buffer size limit 500 reached [yuv4mpegpipe @ 0x1850760] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from '/var/tmp/ducks_take_off_420_720p50.y4m': Duration: N/A, bitrate: N/A Stream #0.0, 4, 1/50: Video: rawvideo, yuv420p, 1280x720, 0/1, PAR 1:1 DAR 16:9, 50 fps, 50 tbr, 50 tbn File 'out.nut' already exists. Overwrite ? [y/N] y [buffer @ 0x18516a0] w:1280 h:720 pixfmt:yuv420p [buffersink @ 0x1855420] auto-inserting filter 'auto-inserted fifo 0' between the filter 'format' and the filter 'output stream 0:0' [ffv1 @ 0x1851ea0] detected 8 logical cores Output #0, nut, to 'out.nut': Metadata: encoder : Lavf54.19.0 Stream #0.0, 0, 1/50: Video: ffv1, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 1/50, q=2-31, 200 kb/s, 50 tbn, 50 tbc Stream mapping: Stream #0:0 -> #0:0 (rawvideo -> ffv1) Press ctrl-c to stop encoding lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
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] 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/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. lu ___ 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 12:16 PM, Luca Barbato wrote: > As Kostya asked here the proper split between decoder and encoder. > > I tested it encoding and decoding properly. Comments addressed here https://github.com/lu-zero/libav/tree/ffv1 to not burden the ml with large patches. lu ___ 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/14/2012 08:39 PM, Peter B. wrote: > 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. Could you please provide me a small sample of it? lu ___ 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/12/2012 03:14 PM, Peter B. wrote: > 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. I'd like you to test few different things later. lu ___ 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
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 lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
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? Both obviously =) Just a chunk at time. more will happen during the weekend. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
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? 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/01/2012 06:22 PM, Peter B. wrote: > 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... patches in this regard welcome =) > For high-end material any additional bit >8 is desireable ;) currently we offer 10 and 16 as I said I was waiting for somebody with a need for intermediates before adding them. lu ___ 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 : 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
Re: [libav-devel] FFv1.3 support
On 10/01/2012 05:57 PM, Peter B. wrote: > That would be great! Thank you very much! No problem, I hope to get the first ones working so you can copy over if the need arises. > 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. Those are more interesting to me, I prefer adding colorspaces only if the need arises. >> 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) ? lu ___ 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 : 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
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. > 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 ^^; I'm rebasing old patches supporting some pixel formats and possibly I'll have a look at ffv1 to see what really changed. The main question regarding rgb with more than 10 and less than 16 is where it is used. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
On Mon, Oct 01, 2012 at 03:55:31PM +0200, Peter B. wrote: > > Which would be the preferred way for patches in the future on this list? git send-email Diego ___ 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 :
On 10/01/2012 12:07 AM, Ronald S. Bultje wrote:
Hi,
On Sun, Sep 30, 2012 at 1:00 PM, Peter B. 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 },
Re: [libav-devel] FFv1.3 support
On 10/01/2012 12:07 AM, Ronald S. Bultje wrote: > Hi, > > On Sun, Sep 30, 2012 at 1:00 PM, Peter B. 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? +1 >> +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 >> +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? > Aren't their entries in the relevant table in libavutil/pixdesc.c missing? Yes that part is missing ^^; lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FFv1.3 support
Hi, On Sun, Sep 30, 2012 at 1:00 PM, Peter B. 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? > +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 These look OK. Aren't their entries in the relevant table in libavutil/pixdesc.c missing? Ronald ___ 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
+ * Copyright (c) 2003-2012 Michael Niedermayer
*
* 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]
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
On 9/30/12 8:59 PM, Peter B. wrote: 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. pkt_timebase reference could be dropped, not sure what got changed in the rangecoder let's have a look. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
