compressing collections of still images with x264

[pcordes]

Sometimes I have a group of pictures of something (e.g. a landscape I photographed, or people at a gathering) that don't form a movie in the usual sense, but have at least some redundancy in backgrounds. What's the best compressor for redundant groups of pictures that I know of? x264.

So I've tried using jpeg2yuv from mjpegtools to make a .y4m out of some pictures, and compressing the result with x264 with insane settings. Obviously I cranked the motion search way up, umh@range=64. And I allowed lots of B frames and ref distance, since sometimes related pictures don't all come in order.

As I understand it, motion search starts looking in the direction the motion was going previously. If you actually played back this "movie", it would be incredibly jerky. So regular motion search has a hard time finding good refs.

An improvement on this might sort the pics based on some kind of rough similarity heuristic before feeding them to x264, since you'd most likely only use this as a batch encoder, not try to access one pic at a time from the stream. Well, I guess you can play it back as a slideshow easily enough, so mabye that makes the compressed version even less useful! OTOH, with pic dimensions > 2048, ffmpeg-based stuff on GNU/Linux mostly just crashes. (Err, I think that's because of my graphics drivers. I guess it's time to go file a bug reports about some i915 drm errors in the kernel log, on the bleeding edge Intel xorg/mesa/gem (2.6.28) graphics stack I'm testing. So maybe it's not vlc's and xine's fault that they crash. :p

Anyway, Intel g965 Xv only handles 1920x1088 max source dimensions. I think a recent mesa git commit raised the texture size limits to 4096x4096, so I should try mplayer -vo gl or -vo gl2. If mplayer has to use the CPU for colour-space conversion, I'll need to recompile it with a higher max width for -vf scale...

anyway, I used:


jpeg2yuv -f 1 -R0 -Ip -j img_53%02d.jpg -b 12 > output.y4m

time x264 output.y4m -o output-try2.mkv -q 18 --pbratio 1 --ipratio 1 -v --subme 9 --me umh --trellis=2 --direct auto --merange 64 --ref 16 --mixed-refs -8 --bframes 16 --b-adapt 2


(I tried once with -q 18, and a second time with --crf 18. Probably -q 18 is more sensible, since unlike a real movie, all pictures are more or less of equal importance.)

I didn't use -A all (p4x4 is slow and won't help at high rez) or --b-pyramid, because I thought it might just be a waste of CPU time with nearby pictures not necessarily being related to each other anyway.

I got a warning that --ref 16 exceeds the DPB allowed by the standard. Since x264 is ok with non-standard refs, and mplayer's libavcodec (ffmpeg) decoder seemed to handle it, maybe I should try --refs 30 or something!

As I said, I ran into a lot of trouble with programs crashing, probably because image dimensions are higher than even normal HD resolution, so the tools haven't had any testing. e.g. jpeg2yuv seems to only read the first 1MB of a jpeg, but I used it because the pics I was finally able to do anything with were 2048x1536. (I didn't feel like recompiling mplayer, although I do have an svn checkout of it and a script that I run every now and then to update x264 git, and mplayer svn, and compile both. I kind of wanted to see what I could do to work around that limitation in -vf scale.)

I had limited success with ffmpeg -i img_53%d.jpg -pix_fmt yuv420p output.y4m The main problem with ffmpeg is that the pics in that subdirectory were numbered starting from 5312, and ffmpeg was only looking for %d to expand to some number of zeros for the first frame. Otherwise, ffmpeg seemed to be doing well. It shows you whether your JPEGs are yuvj444p, yuvj422p sub-sampled, or yuvj440p (my losslessly rotated JPEGs are this, which makes sense because horizontal is now vertical.) Probably if I had any rgb444p JPEGs, ffmpeg would notice that, too.

It also seems to cause problems when you have a 1536x2048 pic mixed in with your 2048x1536 pics. (I usually run exifautotran after pulling my pics of my camera.) Which reminds me, one would have to save the JPEG metadata separately from the h.264. Hmm, you could put it in a matroska attachment.

Results for 56 2048x1536 frames. A lot of the photos have a lot of noise, because I was using a high ISO speed in a dark-ish room taking pictures of a very small party with black lights and so on. I should have tried this on some landscapes where I wouldn't feel weird about posting the pics in such an out-of-context forum. e.g. I have some pics of mountains from an airplane window, and there's a similar textures all over the place.
Anyway these results are from pics that are on my public web site, so PM me if you want the URL.


$ time x264 output.y4m -o output-try2.mkv --crf 18 --pbratio 1 --ipratio 1 -v --subme 9 --me umh --trellis=2 --direct auto --merange 64 --ref 16 --mixed-refs -8 --bframes 10 --b-adapt 2
yuv4mpeg: 2048x1536@1/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [warning]: DPB size (16 frames, 75497472 bytes) > level limit (15 frames, 70778880 bytes)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1
x264 [debug]: frame= 0 QP=14.09 NAL=3 Slice:I Poc:0 I:12288 P:0 SKIP:0 size=327532 bytes PSNR Y:51.16 U:52.37 V:53.02 SSIM Y:0.99442
x264 [debug]: scene cut at 1 Icost:37637252 Pcost:37583016 ratio:0.0014 bias:0.0025 gop:1 (imb:11966 pmb:322 smb:0)
x264 [debug]: frame= 1 QP=16.16 NAL=2 Slice:I Poc:2 I:12288 P:0 SKIP:0 size=488753 bytes PSNR Y:48.32 U:49.10 V:49.55 SSIM Y:0.99308
x264 [debug]: frame= 2 QP=18.22 NAL=2 Slice:P Poc:4 I:10885 P:1403 SKIP:0 size=289715 bytes PSNR Y:46.50 U:48.22 V:48.67 SSIM Y:0.98527
x264 [debug]: frame= 3 QP=19.43 NAL=2 Slice:P Poc:6 I:10939 P:1341 SKIP:8 size=303242 bytes PSNR Y:45.10 U:46.63 V:47.21 SSIM Y:0.98341
x264 [debug]: frame= 4 QP=20.71 NAL=2 Slice:P Poc:8 I:10982 P:1283 SKIP:23 size=347265 bytes PSNR Y:44.04 U:46.05 V:46.40 SSIM Y:0.97792
x264 [debug]: frame= 5 QP=21.78 NAL=2 Slice:P Poc:24 I:9351 P:2937 SKIP:0 size=589539 bytes PSNR Y:43.47 U:44.54 V:44.16 SSIM Y:0.97988
x264 [debug]: frame= 6 QP=20.14 NAL=0 Slice:B Poc:10 I:11987 P:292 SKIP:0 size=251301 bytes PSNR Y:44.41 U:47.52 V:47.12 SSIM Y:0.98600
x264 [debug]: frame= 7 QP=21.67 NAL=0 Slice:B Poc:12 I:8219 P:3827 SKIP:0 size=513453 bytes PSNR Y:42.92 U:43.70 V:44.04 SSIM Y:0.98004
x264 [debug]: frame= 8 QP=22.07 NAL=0 Slice:B Poc:14 I:3235 P:8447 SKIP:0 size=597957 bytes PSNR Y:42.31 U:43.20 V:43.10 SSIM Y:0.97717
x264 [debug]: frame= 9 QP=19.97 NAL=0 Slice:B Poc:16 I:2855 P:8777 SKIP:0 size=377810 bytes PSNR Y:44.75 U:46.26 V:46.14 SSIM Y:0.97657
x264 [debug]: frame= 10 QP=19.94 NAL=0 Slice:B Poc:18 I:3094 P:8513 SKIP:0 size=374756 bytes PSNR Y:44.89 U:46.42 V:46.20 SSIM Y:0.97630
x264 [debug]: frame= 11 QP=20.00 NAL=0 Slice:B Poc:20 I:3091 P:8470 SKIP:1 size=376548 bytes PSNR Y:44.87 U:46.53 V:46.29 SSIM Y:0.97613
x264 [debug]: frame= 12 QP=21.55 NAL=0 Slice:B Poc:22 I:2048 P:9670 SKIP:0 size=572932 bytes PSNR Y:43.00 U:44.18 V:43.67 SSIM Y:0.97546
x264 [debug]: frame= 13 QP=20.56 NAL=2 Slice:P Poc:28 I:9086 P:3202 SKIP:0 size=452513 bytes PSNR Y:44.84 U:46.28 V:46.01 SSIM Y:0.98003
x264 [debug]: frame= 14 QP=21.84 NAL=0 Slice:B Poc:26 I:2067 P:9681 SKIP:0 size=610410 bytes PSNR Y:42.29 U:43.29 V:43.18 SSIM Y:0.97651
x264 [debug]: frame= 15 QP=19.72 NAL=2 Slice:P Poc:32 I:9728 P:2560 SKIP:0 size=429004 bytes PSNR Y:45.56 U:46.99 V:47.13 SSIM Y:0.98078
x264 [debug]: frame= 16 QP=19.81 NAL=0 Slice:B Poc:30 I:3505 P:8190 SKIP:0 size=410292 bytes PSNR Y:44.87 U:46.17 V:46.49 SSIM Y:0.97769
x264 [debug]: frame= 17 QP=19.26 NAL=2 Slice:P Poc:34 I:9966 P:2322 SKIP:0 size=424633 bytes PSNR Y:46.03 U:47.40 V:47.74 SSIM Y:0.98169
x264 [debug]: frame= 18 QP=18.48 NAL=2 Slice:P Poc:36 I:9716 P:2572 SKIP:0 size=403847 bytes PSNR Y:47.03 U:49.13 V:49.24 SSIM Y:0.98398
x264 [debug]: frame= 19 QP=21.10 NAL=2 Slice:P Poc:38 I:11640 P:648 SKIP:0 size=539448 bytes PSNR Y:44.27 U:44.97 V:45.03 SSIM Y:0.98122
x264 [debug]: frame= 20 QP=19.59 NAL=2 Slice:P Poc:40 I:11844 P:444 SKIP:0 size=403719 bytes PSNR Y:45.62 U:47.10 V:47.14 SSIM Y:0.98281
x264 [debug]: scene cut at 21 Icost:42414309 Pcost:42080475 ratio:0.0079 bias:0.0084 gop:21 (imb:11712 pmb:576 smb:0)
x264 [debug]: frame= 21 QP=20.31 NAL=2 Slice:I Poc:42 I:12288 P:0 SKIP:0 size=401967 bytes PSNR Y:44.51 U:45.86 V:45.92 SSIM Y:0.98259
x264 [debug]: frame= 22 QP=20.42 NAL=2 Slice:P Poc:46 I:9961 P:2327 SKIP:0 size=383621 bytes PSNR Y:43.66 U:44.92 V:45.08 SSIM Y:0.98073
x264 [debug]: frame= 23 QP=20.47 NAL=0 Slice:B Poc:44 I:4925 P:6968 SKIP:0 size=391385 bytes PSNR Y:43.23 U:44.25 V:44.40 SSIM Y:0.97982
x264 [debug]: frame= 24 QP=19.64 NAL=2 Slice:P Poc:48 I:10645 P:1643 SKIP:0 size=344797 bytes PSNR Y:44.94 U:46.81 V:46.86 SSIM Y:0.98252
x264 [debug]: frame= 25 QP=19.58 NAL=2 Slice:P Poc:50 I:10097 P:2189 SKIP:2 size=356803 bytes PSNR Y:44.55 U:46.27 V:46.14 SSIM Y:0.98313
x264 [debug]: frame= 26 QP=19.36 NAL=2 Slice:P Poc:56 I:9903 P:2381 SKIP:4 size=364201 bytes PSNR Y:44.49 U:46.18 V:45.94 SSIM Y:0.98335
x264 [debug]: frame= 27 QP=18.95 NAL=0 Slice:B Poc:52 I:6285 P:5858 SKIP:1 size=372299 bytes PSNR Y:46.28 U:47.55 V:47.50 SSIM Y:0.98222
x264 [debug]: frame= 28 QP=19.56 NAL=0 Slice:B Poc:54 I:7319 P:4775 SKIP:0 size=381849 bytes PSNR Y:45.03 U:46.35 V:46.08 SSIM Y:0.98313
x264 [debug]: frame= 29 QP=20.47 NAL=2 Slice:P Poc:58 I:11036 P:1252 SKIP:0 size=550531 bytes PSNR Y:45.01 U:45.76 V:45.53 SSIM Y:0.98186
x264 [debug]: frame= 30 QP=20.79 NAL=2 Slice:P Poc:60 I:11362 P:926 SKIP:0 size=546184 bytes PSNR Y:44.71 U:45.41 V:45.15 SSIM Y:0.98110
x264 [debug]: frame= 31 QP=22.46 NAL=2 Slice:P Poc:62 I:11096 P:1192 SKIP:0 size=495443 bytes PSNR Y:42.15 U:43.29 V:43.50 SSIM Y:0.97861
x264 [debug]: scene cut at 33 Icost:65338530 Pcost:63883865 ratio:0.0223 bias:0.0239 gop:33 (imb:11436 pmb:852 smb:0)
x264 [debug]: frame= 32 QP=22.41 NAL=2 Slice:P Poc:64 I:11057 P:1220 SKIP:11 size=506231 bytes PSNR Y:42.47 U:43.60 V:43.57 SSIM Y:0.97730
x264 [debug]: scene cut at 34 Icost:55608273 Pcost:54314315 ratio:0.0233 bias:0.0256 gop:34 (imb:11137 pmb:1151 smb:0)
x264 [debug]: frame= 33 QP=22.03 NAL=2 Slice:P Poc:66 I:10910 P:1378 SKIP:0 size=511482 bytes PSNR Y:42.78 U:43.81 V:43.87 SSIM Y:0.97801
(trim for forum limit of 16000 chars :mad: )
x264 [debug]: frame= 55 QP=16.61 NAL=2 Slice:P Poc:42 I:8312 P:3976 SKIP:0 size=301376 bytes PSNR Y:47.77 U:50.66 V:51.84 SSIM Y:0.98144
x264 [info]: slice I:11 Avg QP:18.99 size:362007 PSNR Mean Y:46.53 U:47.49 V:47.87 Avg:46.87 Global:46.37
x264 [info]: slice P:29 Avg QP:19.73 size:386155 PSNR Mean Y:45.31 U:46.64 V:46.89 Avg:45.73 Global:45.32
x264 [info]: slice B:16 Avg QP:21.00 size:364290 PSNR Mean Y:44.35 U:45.63 V:45.55 Avg:44.72 Global:44.54
x264 [info]: consecutive B-frames: 48.9% 17.8% 6.7% 8.9% 0.0% 0.0% 0.0% 17.8% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.4% 96.4% 2.2%
x264 [info]: mb P I16..4: 1.6% 82.8% 1.8% P16..4: 9.4% 3.5% 0.9% 0.0% 0.0% skip: 0.0%
x264 [info]: mb B I16..4: 0.2% 35.0% 1.7% B16..8: 36.7% 3.5% 3.0% direct: 7.3% skip:12.6% L0:66.0% L1:18.1% BI:15.8%
x264 [info]: 8x8 transform intra:96.0% inter:96.0%
x264 [info]: direct mvs spatial:37.5% temporal:62.5%
x264 [info]: ref P L0 32.9% 18.5% 8.3% 7.1% 5.7% 7.2% 6.0% 3.1% 2.6% 1.6% 1.4% 1.0% 0.8% 1.7% 1.1% 0.8%
x264 [info]: ref B L0 14.9% 17.6% 19.9% 13.5% 18.3% 2.4% 2.0% 0.1% 0.1% 0.6% 0.9% 2.0% 2.6% 3.6% 1.3%
x264 [info]: SSIM Mean Y:0.9824314
x264 [info]: PSNR Mean Y:45.275 U:46.519 V:46.702 Avg:45.663 Global:45.259 kb/s:3001.31

encoded 56 frames, 0.09 fps, 3001.41 kb/s

real 10m50.004s
user 10m45.264s
sys 0m0.848s


This was my second run, and the first run with --bframes 16 never used more than 8. Normally (err, if I ever do this again!) I'd probably just leave it at 16.

(machine: E6600 w/ DDR800, on g965, running amd64 Ubuntu GNU/Linux 8.10. x264 - core 66 r1110+4 b10b937 compiled with gcc 4.3.2. (The +4 is two tiny local git commits, one to compile with -march=native, and another to make the fps from the command line take precedence over the fps from the y4m input. I should clean it up enough to submit upstream (hi guys), I guess.)

I didn't use multiple threads because I ran into a problem with it with one set of options. Note the extremely short run time, and empty output file. And that it is reproducible with --ref 15, not just with non-standard 16.


$ time x264 output.y4m --threads 0 -o output-thread.mkv -q 18 --pbratio 1 -v --subme 9 --me umh --trellis=2 --direct auto --merange 64 --ref 15 --mixed-refs -8 --bframes 16 --b-adapt 2 --weightb --no-fast-pskip
yuv4mpeg: 2048x1536@1/1fps, 1:1
x264 [debug]: using mv_range_thread = 248
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1

encoded 56 frames, 85.53 fps, 0.00 kb/s

real 0m2.477s
user 0m2.048s
sys 0m0.624s


And output-thread.mkv is empty.
(That time is with the 253MB y4m cached.)

Let me know if you can't reproduce that, and I'll play around with it some more and see if it's maybe something weird about the y4m or something.


I haven't taken the time to do much subjective evaluation of the pics, but I can play back a slideshow with mplayer -vo x11. (-vo gl2 just freezes and has to be killed. Probably my poor Intel drivers need an update an a reboot. ) But things do look pretty good at less than half the bytes per frame of the original JPEGs straight from the camera (with middle of three available compression settings, Canon A510).


edit: I noticed that x264 doesn't seem to accept yuv444p input in a .y4m. Or anything but yuv420p. That's a bit of a hitch for 444p lossless, which might be good for storing camera raw files (after downsampling to 8 bits per colour.) Also re: colour spaces, it seems JPEG has a different 422 than MPEG. http://en.wikipedia.org/wiki/Chroma_subsampling Annoying if you want to feed decoded jpegs to a video encoder.

[Dark Shikari]

So I've tried using jpeg2yuv from mjpegtools to make a .y4m out of some pictures, and compressing the result with x264 with insane settings. Obviously I cranked the motion search way up, umh@range=64. And I allowed lots of B frames and ref distance, since sometimes related pictures don't all come in order.You probably don't want B-frames at all here. Ref frames you want as many as possible. Exhaustive motion search might help if you have the time.
(I tried once with -q 18, and a second time with --crf 18. Probably -q 18 is more sensible, since unlike a real movie, all pictures are more or less of equal importance.)QP disables AQ... and AQ is very important in coding of still images. You can use CRF and qcomp 1 if you want to treat all pictures equally.
I got a warning that --ref 16 exceeds the DPB allowed by the standard. Since x264 is ok with non-standard refs, and mplayer's libavcodec (ffmpeg) decoder seemed to handle it, maybe I should try --refs 30 or something!No, x264 is hardcoded to a max of 16. libavcodec theoretically could work with up to 32, but that's not intended behavior. Let me know if you can't reproduce that, and I'll play around with it some more and see if it's maybe something weird about the y4m or something.That's a known bug where x264 will not encode correctly if you set settings such that the lookahead value is greater than the total number of frames in the video.edit: I noticed that x264 doesn't seem to accept yuv444p input in a .y4m. Or anything but yuv420p. That's a bit of a hitch for 444p lossless, which might be good for storing camera raw files (after downsampling to 8 bits per colour.) Also re: colour spaces, it seems JPEG has a different 422 than MPEG. http://en.wikipedia.org/wiki/Chroma_subsampling Annoying if you want to feed decoded jpegs to a video encoder.Adding 4:4:4/4:2:2 support to x264 would be an enormous amount of work. It isn't just input parsing.

[pcordes]

:thanks: for all the hints and tips, esp. crf qcomp=1. I might well make some of my sets of photos into H.264 slideshows. Then I just need a video player with a good interactive zoom, which could prove problematic. Any thoughts, anyone (I only use GNU/Linux)? There's always mplayer -vo jpeg or png or pnm. Probably video editting software like avidemux would be the best bet for using a video as a collection of photos. But avidemux doesn't like this x264 output.

You probably don't want B-frames at all here. Ref frames you want as many as possible. Exhaustive motion search might help if you have the time.


My intuition was that b-frames would allow references to further-away I and P frames (I omitted b-pyramid, so my hope was that x264 would use b frames to make non-reference frames for pictures that aren't similar to ones before or after, to space out the ref frames. Err, can you have a non-ref p frame that doesn't use up your ref count?). Obviously I'm not an h.264 expert... In practice, x264 chose to use some b frame, even 8 in a row for one sequence (of highly similar pictures of the same subject and background). But frequently it chose no b-frames. Anyway, if you want to take the time to expound on the merits of B-frames for this, I'd be interested.

So ESA/TESA will do better at finding refs that aren't in the direction of predicted motion vectors? I guessed that for the same amount of CPU usage, cranking up merange with umh would help more than using tesa. I should read up on how umh's heuristics work, since I've often wondered what kinds of motion it misses. I'll have to give tesa a try, since I'm curious how well this could be made to work, even if it's not practical in terms of CPU usage.

Adding 4:4:4/4:2:2 support to x264 would be an enormous amount of work. It isn't just input parsing.

ok, so much optimized code takes advantage of the assumption that the format is 4:2:0... You probably can't just do motion search and everything based on a downsampled version, and then use those decisions to encode 4:4:4 input, can you? :p

Does x264's lossless mode actually output 4:4:4 video? I had been assuming "High 4:4:4 Predictive Profile" == actually using 4:4:4 chroma. But I just noticed that wikipedia says that profile supports up to 4:4:4 sampling, and up to 14bits per sample. So x264 uses that profile because it's the only one that allows predictive lossless coding, and outputs 4:2:0 like normal, right?
:stupid:

I was going to ask, does it waste bits for lossless mode to use 4:4:4 instead of the 4:2:0 chroma subsampling that x264 does know how to accept? Or does it just give CABAC some easy redundancy to compress? I was thinking: if x264 is going to output 4:4:4 anyway, I might as well see if I can give it 4:4:4 input. :cool: :o.

So, out of curiosity, are there any H.264 encoders that will accept 4:2:2 input, or even 4:4:4? What about at 14bpp? Then one could come close to losslessly compressing digital camera raw files. The difficulties include: They're RGB, not YUV, and their RGB samples are positioned on a sensor-hardware-specific grid (e.g. hexagonal)! I guess it's lossless, so if you stuff your data in in a way that lines up with 444 enough for the codec to do something other than literal PCM blocks, you could get it back out again verbatim, and achieve some compression. This probably means converting to YUV, but you could just tell the codec to compress RGB data as if it was YUV. esp. with lots of bit depth, motion search will probably work on R instead of Y, and I wouldn't expect too many heuristics for dark areas to come into play in lossless mode. Still, probably better to convert to YUV. 14 bits is enough that you don't have to guard them that jealously. Also tricky would be converting back to the camera's native raw format and restoring all the metadata (shutter speed and other settings used. And according to wikipedia, in the case of motion picture film scans (!), timecode or frame number. http://en.wikipedia.org/wiki/RAW_image_format. The point of keeping a raw file is so you can "digitally develop" it again with different settings. So raw files are as fresh-from-the-sensor as possible, and wouldn't look right without gamma correction and other processing. So the compressed video wouldn't be a useful slideshow, just a way to remove redundancy when making backups and archives.)

[Dark Shikari]

My intuition was that b-frames would allow references to further-away I and P frames (I omitted b-pyramid, so my hope was that x264 would use b frames to make non-reference frames for pictures that aren't similar to ones before or after, to space out the ref frames.Theoretically this would be true, but I wouldn't trust the B-frame decision too much on series of still frames. You could try and compare.Err, can you have a non-ref p frame that doesn't use up your ref count?)Yes, but you'd have to modify x264 to do it. So ESA/TESA will do better at finding refs that aren't in the direction of predicted motion vectors?Exhaustive will probably work better when dealing with trying to find matches between very different images.ok, so much optimized code takes advantage of the assumption that the format is 4:2:0... You probably can't just do motion search and everything based on a downsampled version, and then use those decisions to encode 4:4:4 input, can you? :pNothing to do with optimization per se; it just requires adding a bunch of new features with regard to deblocking, transform, bitstream coding, and fixing all the places that 4:2:0 was hardcoded.
Does x264's lossless mode actually output 4:4:4 video? I had been assuming "High 4:4:4 Predictive Profile" == actually using 4:4:4 chroma.No, that's the name of the profile. x264 only supports YV12.But I just noticed that wikipedia says that profile supports up to 4:4:4 sampling, and up to 14bits per sample. So x264 uses that profile because it's the only one that allows predictive lossless coding, and outputs 4:2:0 like normal, right?Correct.I was going to ask, does it waste bits for lossless mode to use 4:4:4 instead of the 4:2:0 chroma subsampling that x264 does know how to accept? Or does it just give CABAC some easy redundancy to compress? I was thinking: if x264 is going to output 4:4:4 anyway, I might as well see if I can give it 4:4:4 input. :cool: :o.Per the above, it's all 4:2:0.So, out of curiosity, are there any H.264 encoders that will accept 4:2:2 input, or even 4:4:4?The reference (JM) does. I think Ateme has 4:2:2 support now.What about at 14bpp?I've heard about up to 10 bit, not beyond that.

[LoRd_MuldeR]

Does x264's lossless mode actually output 4:4:4 video? I had been assuming "High 4:4:4 Predictive Profile" == actually using 4:4:4 chroma

Nope. x264 doesn't support the 4:4:4 colorspace at all.

However its "lossless" mode now uses a feature called "Predictive Lossless", which is part of the "High 4:4:4" profile.

But using a feature from that profile doesn't imply using the 4:4:4 colorspace...

--[EDIT]--

Too late :p

[pcordes]

Theoretically this would be true, but I wouldn't trust the B-frame decision too much on series of still frames.


What's bad about using a B frame when ipratio = pbratio = 1, anyway? (assuming those settings are a good idea for this.)


Nothing to do with optimization per se; it just requires adding a bunch of new features with regard to deblocking, transform, bitstream coding, and fixing all the places that 4:2:0 was hardcoded.


I was forgetting that the colour planes are stored separately, so it's not like you'd have to write new versions of lots of asm routines, just use them differently. (i.e. separating out 4:2:0 data isn't something that most of the time-critical code in x264 does itself). Duh. You'd only have this problem if you added support for more bit depth, since then format of the colour planes would have to change from uint8_t *plane[4];

[akupenguin]

What's bad about using a B frame when ipratio = 1, pbratio = 1 anyway? (assuming those settings are a good idea for this.
While CABAC adapts to image-specific statistics to some extent, not all of the adaption is left to CABAC; there are some parts hard-coded in the standard. One of those is that it costs extra bits to code intra blocks in B-frames. Normally this is just fine, as B-frames have few intra blocks in video since the biprediction works so well. But if you're coding fundamentally different images and just hoping for a little redundancy exploitation, then even the B-frames will be mostly intra, so that cost is non-negligible.

And x264 does not in fact use B-frames to optimize its reference lists. If you want that, you'll have to manually decide which frames are most important for being referenced, and specify all the frame types. x264 uses a B-frame if and only if that particular frame is best predicted as B (to within the limits of our heuristics accuracy, of course).