Command line arguments help

[zilee]

Hey, I've been playing a little with x264 and I'd like to have people's opinion on how I should go on to encode stitched stereopair images(3840x1080) with best quality-size ratio.

I've tried using --frame-packing 5, but to my surprise the size of the file is 5mb larger.

I'm reading the full help, but I'd except a few tips from people with more experience.


Thanks

[LoRd_MuldeR]

I've tried using --frame-packing 5, but to my surprise the size of the file is 5mb larger.

Larger compared to what? :confused:

If the file came out larger at the same target bitrate, then this is probably due to the small bitrate derivation that x264 allows.

And if the file came out larger at the same CRF value, it doesn't necessarily mean the compression is worse!

That's because the larger file may also have better quality. And possibly the increase in quality is "bigger" than the increase in size...

So it's actually quite possible that both, the file size and the compression-efficiency, have increased.

(This is also the reason why comparing different settings in CRF mode is difficult or impossible. Use 2-Pass mode instead!)

[Dark Shikari]

stitched stereopair images(3840x1080)Frame-packing 5 means "frame alternation", which your video isn't. Please read the help before using options.

[zilee]

Frame-packing 5 means "frame alternation", which your video isn't. Please read the help before using options.


Yeah sorry, I had a discussion later and now I understand. Frame-packing is working well.

Now though I have another question, once I get my encoded file which is interleaved, playing it in Stereoscopic player with interlace(Left First, Right Second), the frames are played back to back as in left then right, etc.

I would have expected to see them get stacked and view disparity of some sort?

@LoRd_MuldeR, thanks for this explanation, I have a better comprehension now.

[nm]

Now though I have another question, once I get my encoded file which is interleaved, playing it in Stereoscopic player with interlace(Left First, Right Second), the frames are played back to back as in left then right, etc.

I would have expected to see them get stacked and view disparity of some sort?

While I have no experience with Stereoscopic Player, and "interlace" could just as well mean "weave", that function name and description certainly doesn't sound like it would stack the views.

[zilee]

While I have no experience with Stereoscopic Player, and "interlace" could just as well mean "weave", that function name and description certainly doesn't sound like it would stack the views.

Well I'm just a little confused, is there a de interlacing process that is required to view the 3D content after compression?

[nm]

Well I'm just a little confused, is there a de interlacing process that is required to view the 3D content after compression?

1. Your encoded file shouldn't be interlaced but frame-alternating video if you are using --frame-packing 5. Each view should be encoded as a full frame and placed one after another: L1 R1 L2 R2 ... Make sure your video looks like this when you feed it to x264.

2. Unless the player supports frame-packing signals, you need to tell it manually that the video is frame-alternating.

3. Output options must be set according to the display used. If you have a display that only supports side-by-side 3D, then that's what the video must be converted to during playback.

[zilee]

Got some other concerns, people might be able to enlighten me.

So I've been doing compression tests for my stereo pair images. When I stitch them together, and use ffmpeg to generate a y4m data file with a pixel format of yuv420p with this line :


ffmpeg.exe -i "C:\path\merged_%03d.bmp" -pix_fmt yuv420p mergedFrames.y4m


And then I use x264 with these settings:


x264.exe mergedFrames.y4m -o mergedStereo.h264


The filesize is at 8.44MB

When I take my frames and interleave the left with the right in a chain with the same ffmpeg command(Just a different image name, single images one after the next) and then I use:


x264.exe --frame-packing 5 alternateFrames.y4m -o alternateSequence.h264


The file is at 19.7MB

I would have thought frame-packing the sequence grant me a size reduction, unless I am doing something wrong.

[nm]

Could you post encode logs (the stuff x264 prints to the console during and after encoding)?

[zilee]

Could you post encode logs (the stuff x264 prints to the console during and after encoding)?

Sure,

c:\prefix\exec>ffmpeg.exe -i "C:/Users/out/alternation/alter_%03d.bmp" -pix_fmt yuv420p alter3D.y4m
ffmpeg version N-34549-g13b7781, Copyright (c) 2000-2011 the FFmpeg developers
built on Nov 6 2011 22:08:46 with gcc 4.6.1
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-li
bfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 51. 24. 0 / 51. 24. 0
libavcodec 53. 28. 0 / 53. 28. 0
libavformat 53. 19. 0 / 53. 19. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 47. 0 / 2. 47. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0
Input #0, image2, from 'C:/Users/pzielinski/Desktop/Samples/StichUseCase/out/alternation/alter_%03d.bmp':
Duration: 00:00:28.80, start: 0.000000, bitrate: N/A
Stream #0:0: Video: bmp, bgr24, 1920x1080, 25 tbr, 25 tbn, 25 tbc
[buffer @ 0000000001D2FC00] w:1920 h:1080 pixfmt:bgr24 tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 0000000001D2FE40] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0000000001C768C0] w:1920 h:1080 fmt:bgr24 -> w:1920 h:1080 fmt:yuv420p flags:0x4
Output #0, yuv4mpegpipe, to 'alter3D.y4m':
Metadata:
encoder : Lavf53.19.0
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (bmp -> rawvideo)
Press [q] to stop, [?] for help
frame= 720 fps= 16 q=0.0 Lsize= 2187004kB time=00:00:28.80 bitrate=622081.2kbits/s
video:0kB audio:0kB global headers:0kB muxing overhead 1.#INF00%


c:\prefix\exec>x264.exe --crf 24 --frame-packing 5 alter3D.y4m -o leftWDiff_alternated.h264
y4m [info]: 1920x1080p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High, level 4.0
x264 [info]: frame I:3 Avg QP:19.19 size:386129
x264 [info]: frame P:360 Avg QP:22.40 size: 19181
x264 [info]: frame B:357 Avg QP:25.74 size: 35476
x264 [info]: consecutive B-frames: 0.8% 99.2% 0.0% 0.0%
x264 [info]: mb I I16..4: 7.2% 49.9% 42.9%
x264 [info]: mb P I16..4: 1.4% 2.2% 0.5% P16..4: 21.7% 6.1% 4.9% 0.0% 0.0% skip:63.1%
x264 [info]: mb B I16..4: 87.2% 1.4% 11.4% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip: 0.0% L0:43.3% L1:56.5% BI: 0.2%
x264 [info]: 8x8 transform intra:3.9% inter:69.3%
x264 [info]: coded y,uvDC,uvAC intra: 11.0% 13.0% 10.5% inter: 11.5% 8.3% 0.9%
x264 [info]: i16 v,h,dc,p: 95% 3% 1% 1%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 10% 31% 5% 9% 8% 7% 7% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 32% 13% 39% 3% 3% 3% 2% 4% 2%
x264 [info]: i8c dc,h,v,p: 91% 4% 5% 0%
x264 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x264 [info]: ref P L0: 70.1% 12.8% 12.1% 5.0% 0.0%
x264 [info]: ref B L0: 83.9% 16.1%
x264 [info]: kb/s:5757.90

encoded 720 frames, 17.52 fps, 5757.90 kb/s

[nm]

And logs for the other encode with side-by-side views? I can't compare them otherwise.

[zilee]

c:\prefix\exec>ffmpeg.exe -i "C:/Users/StichUseCase/out/out_%d.bmp" -pix_fmt yuv420p left_with_diff.y4m
ffmpeg version N-34549-g13b7781, Copyright (c) 2000-2011 the FFmpeg developers
built on Nov 6 2011 22:08:46 with gcc 4.6.1
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-li
bfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 51. 24. 0 / 51. 24. 0
libavcodec 53. 28. 0 / 53. 28. 0
libavformat 53. 19. 0 / 53. 19. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 47. 0 / 2. 47. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0
Input #0, image2, from 'C:/Users/StichUseCase/out/out_%d.bmp':
Duration: 00:00:14.40, start: 0.000000, bitrate: N/A
Stream #0:0: Video: bmp, bgr24, 3840x1080, 25 tbr, 25 tbn, 25 tbc
File 'left_with_diff.y4m' already exists. Overwrite ? [y/N] y
w:3840 h:1080 pixfmt:bgr24 tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 00000000003BFDD0] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0000000001DE7060] w:3840 h:1080 fmt:bgr24 -> w:3840 h:1080 fmt:yuv420p flags:0x4
Output #0, yuv4mpegpipe, to 'left_with_diff.y4m':
Metadata:
encoder : Lavf53.19.0
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 3840x1080, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (bmp -> rawvideo)
Press [q] to stop, [?] for help
frame= 360 fps= 4 q=0.0 Lsize= 2187002kB time=00:00:14.40 bitrate=1244161.2kbits/s
video:0kB audio:0kB global headers:0kB muxing overhead 1.#INF00%




c:\prefix\exec>x264.exe --crf 24 left_with_diff.y4m -o leftWDiffConstantQ.h264
y4m [info]: 3840x1080p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High, level 5.0
x264 [info]: frame I:2 Avg QP:21.11 size:401193
x264 [info]: frame P:99 Avg QP:24.69 size: 38716
x264 [info]: frame B:259 Avg QP:29.49 size: 12236
x264 [info]: consecutive B-frames: 0.8% 9.4% 0.8% 88.9%
x264 [info]: mb I I16..4: 45.2% 26.7% 28.1%
x264 [info]: mb P I16..4: 2.6% 2.8% 0.8% P16..4: 15.9% 4.8% 3.6% 0.0% 0.0% skip:69.5%
x264 [info]: mb B I16..4: 0.9% 0.5% 0.1% B16..8: 15.4% 2.0% 0.5% direct: 0.9% skip:79.6% L0:44.8% L1:52.1% BI: 3.1%
x264 [info]: 8x8 transform intra:38.2% inter:59.3%
x264 [info]: coded y,uvDC,uvAC intra: 36.9% 35.0% 17.6% inter: 4.3% 2.7% 0.7%
x264 [info]: i16 v,h,dc,p: 61% 12% 3% 24%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 11% 15% 7% 13% 11% 10% 9% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 13% 28% 6% 8% 7% 6% 6% 5%
x264 [info]: i8c dc,h,v,p: 65% 14% 17% 4%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 61.2% 12.1% 18.1% 8.7%
x264 [info]: ref B L0: 78.5% 17.0% 4.5%
x264 [info]: ref B L1: 92.1% 7.9%
x264 [info]: kb/s:4335.78

encoded 360 frames, 12.10 fps, 4335.78 kb/s

[nm]

That is odd. What do you mean by "left_with_diff"? Is the other view some kind of residual image that is not intended to be viewed as-is? Could you show a pair of images from the bmp sequence?

[zilee]

That is odd. What do you mean by "left_with_diff"? Is the other view some kind of residual image that is not intended to be viewed as-is? Could you show a pair of images from the bmp sequence?

Sorry for the wait, I got side-lined by another project.


Yes, the image is actually not intended for direct viewing once it's encoded. The left image is a regular 2D image, but the difference image(right image within the stereoPair), is a black image with a subtraction of edge detection done with a different algorithm. It's for a paper I'm writing.

I don't think you actually need to see them with this description:

-3840x1080
-Left is standard image of anything
-Right is a black image(On 6 million pixels 3-4million are black)

Right now I'm just trying to figure out optimal encoding that can be done for this peculiar case. I am aware that this is a special case and that x264 wasn't intended for this use, that's why I might actually have to read on compression schemes and try to handle this myself. Thanks for looking into it with me.

[Asmodian]

I would have thought frame-packing the sequence grant me a size reduction, unless I am doing something wrong.

When using a residual fram this makes sense, as the two frames look very different you are basically interleaving two completely different videos. References don't apply to every other frame, there are constant scene changes, etc.

Side by side would be better than interleaved if you are using a residual frame.