Log in

View Full Version : Any free MVC encoder yet?


Pages : 1 2 3 4 [5] 6 7 8

Dark Shikari
10th January 2011, 19:54
h->fenc->i_frame can be used to get the current frame number, which you can use to do left/right signalling (i.e. h->fenc->i_frame&1).

rica
10th January 2011, 20:11
Yesterday i gave it a go with H264StereoSource again. This time i tried to use right video without recompressing it to a lossy x264:
And instead of Adam's method i gave it a go with x264 frame-pacing 5 method...

First of all i got two working aviscripts; both of them works individually on graph-stuff without any issues.

left.avs:
DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)

out.avs:
LoadPlugin("H264StereoSource.dll")
H264StereoSource("decoder.cfg",64174)

yeni.avs:
lv = DirectShowSource("left.avs")
rv = DirectShowSource("out.avs")
Interleave(lv, rv)
ConvertToYV12()

I made a basic coding with x264 for quick test,


1) Without any compression: (of right hand video)

I got the same error warning as i get with Adam's Tool:

C:\H264StereoSource_a2>x264 --fps 23.976 --level 4.1 --sar 1:1 --aud --frame-packing 5 -o final.264 yeni.avs

avs [error]: Interleave: videos must be of the same size.
(yeni.avs, line 3)

x264 [error]: could not open input file `yeni.avs'

2) With lossless compression:

I re-encoded to huffyuv via Graph-stuff:

http://img808.imageshack.us/img808/8374/rightavi.png (http://img808.imageshack.us/i/rightavi.png/)

And that re-created avi crashes all the applications.

When i open it on VirtualDubMod, i get this report: (added)

Now i'm trying to create a new huffyuv via VirtualDubMod...

EDIT: BTW i don't understand what the "same size" issue is? Same size normally means both videos must be the same resolution not have to have the total frame number?
_ _ _ _ _ _

BigPines
10th January 2011, 22:40
Rica,

It is too bad it is crashing because I really think this lossless right eye "one shot" approach is the correct way to go. It would be the highest quality and save a ton of time.

I think the problem is the missing frames we get when encoding right eye video. It seems that bug is keeping the encoder from being able to create the final output. It seems both eye files must have the exact same number of frames.

Too bad we can't get the developer to fix this bug. Actually, who is the developer of H264StereoSource? Maybe we should contact them?

Mike

nm
10th January 2011, 22:45
Interleave should handle clips with different number of frames just fine. Check the resolution of the clips with AviSynth's info function by playing the scripts with a media player or VirtualDub. If the resolutions differ (one is 1920x1088 for example), crop the video.

rica
10th January 2011, 22:56
Hi Mike,
This is why i started a thread: (but i forgot to go on :) )

http://forum.doom9.org/showthread.php?t=158764

Hi nm,

mediainfo says both are the same 1920*1080...

nm
10th January 2011, 23:30
Have you tried this:

LoadPlugin("H264StereoSource.dll")

lv = DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)
rv = H264StereoSource("decoder.cfg",64174)

Interleave(lv, rv)
ConvertToYV12()

If that doesn't work, maybe it's the seeking issue in H264StereoSource that BlackSharkfr mentioned earlier:


Adam's MVC decoder does not support seeking, even seeking to the first frame of the video makes avisynth and x264 and Megui crash (I can't use CLI, I prefer GUIs), so I had to manually force x264 to start encoding at frame 1 otherwise I'd get instant crash when starting the encode.

rica
10th January 2011, 23:49
Have you tried this:

LoadPlugin("H264StereoSource.dll")

lv = DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)
rv = H264StereoSource("decoder.cfg",64174)

Interleave(lv, rv)
ConvertToYV12()



Just tried and i got the same error...

Thanks.

rica
11th January 2011, 00:17
BTW i have to appreciate to crl2007 again for his perfect start:
http://forum.doom9.org/showpost.php?p=1410709&postcount=1

_ _ _ _ _

J_Darnley
11th January 2011, 11:26
Just tried and i got the same error...

Thanks.

Have you tried looking at Info() of the left and right clips to see what the problem might be?

BlackSharkfr
11th January 2011, 18:30
I was about to download the latest x264 binaries from x264.nl and start doing some compression tests when i found this :

VFR/framerate-aware ratecontrol, part 2

MB-tree and qcomp complexity estimation now consider the duration of a frame in their calculations.
This is very important for visual optimizations, as frames that last longer are inherently more important quality-wise.
Improves VFR-aware PSNR as much as 1-2db on extreme test cases, ~0.5db on more ordinary VFR clips (e.g. deduped anime episodes).

WARNING: This change redefines x264's internal quality measurement.
x264 will now scale its quality based on the framerate of the video due to the aforementioned frame duration logic.
That is, --crf X will give lower quality per frame for a 60fps video than for a 30fps one.
This will make --crf closer to constant perceptual quality than previously.
The "center" for this change is 25fps: that is, videos lower than 25fps will go up in quality at the same CRF and videos above will go down.
This choice is completely arbitrary.

Note that to take full advantage of this, x264 must encode your video at the correct framerate, with the correct timestamps.

Will this affect frame sequential encoding ?
I mean when using --framepacking 5, will it keep an equivalent quality between a side by side full resolution encode and a frame sequential encode, or will this patch kick in and downgrade the quality in the frame sequential encode ?

I would like to encode two videos at the same quality to make compression tests, I though CRF would provide the same visual quality so that I wouldn't have to worry about comparing the pictures and just look at the file size and get % differences. If I can't use CRF, what should I use ? Quantizer ? (QP mode)

sneaker_ger
11th January 2011, 19:17
Yes, it will be affected. (frame sequential fps = 2 times side by side fps).
(I'll let your other questions open for people more qualified than me...)

BigPines
11th January 2011, 19:25
BlackSharkfr,

This is an interesting question. I would say yes, because the frame rate is doubled, the quality of encoding will go down. This is unfortunate for comparison purposes but really doesn't matter other than that. If we bump up the CRF, we can still get the same quality with the same level of efficiency. We may have to play with this to figure out how much we have to raise the quality to compensate.

One way to cheat may be to encode all Frame Sequential video using the original frame rate and then correct it when muxing with the audio. For instance, if I have a 23.976 fps 3D video, I would encode both streams together in Frame Sequential at 23.976. This will effectively slow down the clip - it will be twice as long. Then, I would bring the h264 clip into tsmuxer and correct the frame rate to 47.95 which should correct the speed and keep audio sync. In theory, this would give a good comparison with other types of 3D encodes.

Mike

Dark Shikari
11th January 2011, 19:27
If you're looking to get the same quality on a frame-per-frame basis, you can force the two to use the same framerate. I'm not sure what the "right" way to handle this internally is.

BigPines
11th January 2011, 19:52
If you're looking to get the same quality on a frame-per-frame basis, you can force the two to use the same framerate. I'm not sure what the "right" way to handle this internally is.
Yep. He said it a lot more concisely than I did. :)

Just my two cents...I understand the reason for lowering the quality on higher frame rates. The goal is to keep PERCEIVED quality which this does. However, if the --frame-packing 5 flag has been used, x264 knows the video being encoded is actually two distinct views intended to be displayed at half the actual frame rate. I think it would be nice if x264 would compensate appropriately to keep PERCEIVED quality the same.

Mike

Dark Shikari
11th January 2011, 20:00
Yep. He said it a lot more concisely than I did. :)

Just my two cents...I understand the reason for lowering the quality on higher frame rates. The goal is to keep PERCEIVED quality which this does. However, if the --frame-rate 5 flag has been used, x264 knows the video being encoded is actually two distinct views intended to be displayed at half the actual frame rate. I think it would be nice if x264 would compensate appropriately to keep PERCEIVED quality the same.

MikeYeah, I understand the logic, it's just about finding a way to do it cleanly internally.

It's also confusing, because it'll mean that --frame-packing 5 will dramatically increase bitrate, which users won't expect or initially understand.

BigPines
11th January 2011, 20:27
I can imagine internally, stuff like this can get messy to do correctly.

Yep, I meant --frame-packing 5 but you caught that.

As far as the bitrate goes, I think it is just part of educating people on 3D encoding. I personally wouldn't be surprised to see the bitrate go up while merging two views and encoding them together for 3D. However, others may disagree.

Mike

BlackSharkfr
11th January 2011, 20:47
I just used a simple CRF encode with preset slow

I have just completed the Side by Side 3840x1080 30fps and the frame packing 60fps and CRF20 does modify the image quality, as previously predicted. The encoding with frame packing at faked 30fps is still in progress.
Frame packing 60fps is more blurry and is a smaller file but I was expecting a bigger difference. The bitrate only went from 17.9Mbps (fullSBS) down to 15.3Mbps (frame packing 5) for a loss of quality.
Maybe preset slow does not contain enough reference and or B-frames to really take advantage of frame packing ?

I'll have the final one in about 15 minutes, and i'll show the stats x264 displays when the encode finishes.

EDIT : at 80% encode in progress, the one with assumed 30fps seems to be encoding with a significantly lower bitrate, the live stats say it's using only 10Mbps average.
Re-edit : yes of course, it's normal, each second is twice as long, it's using the same bitrate as the full side by side encoding.

BigPines
11th January 2011, 20:58
Nice work BlackShark. I will be very interested in the results of your experiments.

I think it makes sense that the bitrate would report lower on the 30 fps encode. Remember, the actual framerate will be doubled which I think in theory would effectively double your bitrate per second too.

Mike

BlackSharkfr
11th January 2011, 21:29
And the results arrrre.... rolling drums..... disappointing !
Alright so the version with forced lower framerate uses more bitrate : the final file size is almost identical to the full SBS 3840x1080 file, but the quality just doesn't climb like it should do. The quality barely improves at all on the 60fps one.

Here are the logs :
Do not look at the encoding speed, I was doing other stuff at the same time.

CRF20 frame alternate 60fps as 60fps, with --frame-packing 5
(worst quality, blurry)
C:\Users\BlackShark>C:\Users\BlackShark\Downloads\x264_1867.exe --preset slow --crf 20 --frame-packing 5 --output "Test-frameseq" "C:\Users\BlackShark\Documents\Workspace\Video\TrackMania\encode-frameseq.avs"
avs [info]: 1920x1080p 0:0 @ 20000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 5.0
x264 [info]: frame I:32 Avg QP:18.14 size:113582
x264 [info]: frame P:2528 Avg QP:23.23 size: 35932
x264 [info]: frame B:4832 Avg QP:23.09 size: 29499
x264 [info]: consecutive B-frames: 8.0% 10.6% 11.9% 69.5%
x264 [info]: mb I I16..4: 32.7% 54.6% 12.7%
x264 [info]: mb P I16..4: 6.4% 9.1% 1.0% P16..4: 33.1% 10.3% 4.7% 0.0% 0.0% skip:35.4%
x264 [info]: mb B I16..4: 2.2% 3.0% 0.3% B16..8: 39.7% 8.7% 1.5% direct: 8.7% skip:35.9% L0:51.0% L1:45.2% BI: 3.8%
x264 [info]: 8x8 transform intra:55.1% inter:73.5%
x264 [info]: direct mvs spatial:97.3% temporal:2.7%
x264 [info]: coded y,uvDC,uvAC intra: 41.6% 40.6% 6.9% inter: 26.7% 21.3% 0.3%
x264 [info]: i16 v,h,dc,p: 31% 33% 9% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 12% 15% 8% 13% 8% 18% 6% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 16% 10% 7% 12% 8% 17% 7% 15%
x264 [info]: i8c dc,h,v,p: 51% 31% 12% 6%
x264 [info]: Weighted P-Frames: Y:17.5% UV:8.5%
x264 [info]: ref P L0: 62.0% 14.3% 14.2% 5.3% 3.4% 0.7% 0.1%
x264 [info]: ref B L0: 74.5% 18.0% 6.9% 0.6%
x264 [info]: ref B L1: 91.3% 8.7%
x264 [info]: kb/s:15390.30

encoded 7392 frames, 3.29 fps, 15390.30 kb/s
The file size of the raw video is 231 456 kB

CRF20 frame alternate 60fps assumed as 30fps, with --frame-packing 5
(barely better than the previous one)
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --preset slow --crf 20 --frame-packing 5 --output "Test-frameseq2" "C:\Users\BlackShark\Documents\Workspace\Video\TrackMania\encode-frameseq-framerate.avs"
avs [info]: 1920x1080p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 5.0
x264 [info]: frame I:32 Avg QP:16.27 size:143272
x264 [info]: frame P:2528 Avg QP:21.62 size: 49213
x264 [info]: frame B:4832 Avg QP:22.52 size: 30612
x264 [info]: consecutive B-frames: 8.0% 10.6% 11.9% 69.5%
x264 [info]: mb I I16..4: 28.8% 55.9% 15.3%
x264 [info]: mb P I16..4: 5.3% 10.5% 1.3% P16..4: 31.9% 12.8% 5.7% 0.0% 0.0% skip:32.4%
x264 [info]: mb B I16..4: 2.1% 2.7% 0.3% B16..8: 39.8% 9.4% 1.7% direct: 8.8% skip:35.1% L0:51.4% L1:43.6% BI: 5.0%
x264 [info]: 8x8 transform intra:58.2% inter:71.4%
x264 [info]: direct mvs spatial:97.2% temporal:2.8%
x264 [info]: coded y,uvDC,uvAC intra: 47.6% 44.5% 9.7% inter: 29.0% 22.3% 0.4%
x264 [info]: i16 v,h,dc,p: 32% 33% 9% 27%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 13% 14% 8% 13% 8% 18% 7% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 15% 9% 7% 12% 9% 17% 7% 16%
x264 [info]: i8c dc,h,v,p: 48% 32% 12% 8%
x264 [info]: Weighted P-Frames: Y:17.5% UV:8.5%
x264 [info]: ref P L0: 61.5% 14.1% 14.4% 5.7% 3.6% 0.7% 0.1%
x264 [info]: ref B L0: 74.6% 17.8% 7.0% 0.6%
x264 [info]: ref B L1: 91.5% 8.5%
x264 [info]: kb/s:8990.62

encoded 7392 frames, 5.88 fps, 8990.62 kb/s
The file size of the raw video is 270 421 kB

CRF20 side by side 3840x1080 30fps, standard encode
(best quality of the 3, significantly sharper)
C:\Users\BlackShark>C:\Users\BlackShark\Downloads\x264_1867.exe --preset slow --crf 20 --output "TEST-CRF20" "C:\Users\BlackShark\Documents\Workspace\Video\TrackMania\encode-SBSFullHD.avs"
avs [info]: 3840x1080p 0:0 @ 10000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 5.0
x264 [info]: frame I:16 Avg QP:15.68 size:286427
x264 [info]: frame P:1344 Avg QP:21.82 size:105947
x264 [info]: frame B:2336 Avg QP:22.56 size: 55388
x264 [info]: consecutive B-frames: 8.2% 11.2% 33.9% 46.6%
x264 [info]: mb I I16..4: 29.3% 54.5% 16.1%
x264 [info]: mb P I16..4: 7.1% 16.1% 2.3% P16..4: 28.4% 11.8% 5.0% 0.0% 0.0% skip:29.3%
x264 [info]: mb B I16..4: 1.3% 2.9% 0.4% B16..8: 39.8% 8.1% 1.5% direct: 6.6% skip:39.3% L0:41.4% L1:50.4% BI: 8.3%
x264 [info]: 8x8 transform intra:63.0% inter:75.5%
x264 [info]: direct mvs spatial:99.5% temporal:0.5%
x264 [info]: coded y,uvDC,uvAC intra: 56.1% 47.5% 10.9% inter: 23.7% 21.5% 0.4%
x264 [info]: i16 v,h,dc,p: 27% 33% 8% 32%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 13% 9% 8% 13% 8% 19% 7% 17%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 15% 6% 7% 13% 9% 19% 7% 17%
x264 [info]: i8c dc,h,v,p: 43% 35% 13% 9%
x264 [info]: Weighted P-Frames: Y:16.9% UV:8.7%
x264 [info]: ref P L0: 62.0% 15.4% 12.3% 5.0% 3.7% 1.6% 0.0%
x264 [info]: ref B L0: 85.8% 9.6% 3.7% 0.9%
x264 [info]: ref B L1: 94.9% 5.1%
x264 [info]: kb/s:17945.62

encoded 3696 frames, 1.52 fps, 17945.62 kb/s
The file size of the raw video is 269 886kB

BigPines
11th January 2011, 21:57
Very interesting. Were you using Dark Shikari's new x264 with the Frame Sequential optimizations?

I am surprised you saw NO file size decrease in Frame Sequential. That really doesn't make sense to me. I'll definitely have to run some of these tests myself.

If this is true, it sounds like SBS Full is the way to go (if you can find a player that can take advantage of it of course).

Mike

BlackSharkfr
11th January 2011, 22:04
I used the latest x264 32bit windows executable from x264.nl. The change log shows DarkShikari's patch is included.
I'm trying with a slower preset (slower) to see if it unlocks the situation.

BigPines
11th January 2011, 22:20
Cool.

Maybe Dark Shikari can shed some light on this too.

Mike

BlackSharkfr
11th January 2011, 23:24
Not much change with slower encoding. The bitrate is even higher by 700kbps where it should be lower.
It seems CRF has a problem, i'll try QP mode.

BlackSharkfr
12th January 2011, 00:18
I've done another test, this time with QP mode with quantizer 21 and default preset :
Tested : Side by side 3840x1080, frame alternate with frame packing 5, and without framepacking 5.
Result : bitrate goes up to 25Mbps, all 3 files get the same bitrate, same filesize, identical visual quality

I've got a big problem here : I get zero optimization from my source.

I'll do one final test, I'll try to see if I can get any optimisation at low bitrate.
I'll try CRF25 and preset "veryfast" + 4 refs just to make sure it'll use them.

rica
12th January 2011, 00:46
Hi guys,

a noob question.

Any help would be appreciated:

I'm looking for the right switch to make "ReFrames" to 2 frames.

--frames 2 doesn't work.

Thanks.

BlackSharkfr
12th January 2011, 00:48
The command is --ref
See --fullhelp for the list of commands

rica
12th January 2011, 01:10
The command is --ref
See --fullhelp for the list of commands

Thanks but here is the code:

C:\H264StereoSource_a2>x264 --fps 23.976 --ref 2 --level 4.1 --sar 1:1 --aud -o blank.264 blank.avs

And here is what i got:

(Image loss)

4 Frames instead of 2...


And this is what i want to see:

(Image loss)


_ _ _ _

Dark Shikari
12th January 2011, 01:38
Mediainfo shows the size of the DPB, not the number of reference frames. B-pyramid requires a DPB of size 4.

rica
12th January 2011, 01:46
Mediainfo shows the size of the DPB, not the number of reference frames. B-pyramid requires a DPB of size 4.

And? What should i do?

LoRd_MuldeR
12th January 2011, 01:48
And? What should i do?

Turning off B-Pyramid sounds like the way to go...

BlackSharkfr
12th January 2011, 02:05
Alright last test for tonight, and it's still unsucessful.

I took my source, converted it to : CRF25, preset veryfast just like Dark Shikari did a few pages back
-Separate left and right files
-Side by Side full resolution
-Frame sequential with framepacking 5 and ref 2 at 30fps
-Frame sequential with framepacking 5 and ref 2 at 60fps

I get no gain at all.
The files are approximately the same size.
Visually, SBS and separate files look almost as good (as bad) as each other and frame sequential looks a bit less good (worse), and as predicted framesequential at 60fps confuses CRF mode at breaks everything. It's a total fiasco for me.
Framepacking 5 60fps
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --preset veryfast --ref 2 --crf 25 --frame-packing 5 --output "Test-FAST-seq5-60" "C:\...\frameseq.avs"
avs [info]: 1920x1080p 0:0 @ 20000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.2
x264 [info]: frame I:62 Avg QP:24.77 size: 39404
x264 [info]: frame P:4380 Avg QP:28.32 size: 12522
x264 [info]: frame B:2950 Avg QP:28.26 size: 13237
x264 [info]: consecutive B-frames: 30.8% 47.6% 1.1% 20.5%
x264 [info]: mb I I16..4: 38.5% 55.9% 5.7%
x264 [info]: mb P I16..4: 9.9% 9.2% 0.1% P16..4: 23.7% 4.8% 1.0% 0.0% 0.0% skip:51.3%
x264 [info]: mb B I16..4: 8.4% 6.1% 0.1% B16..8: 21.2% 4.9% 0.2% direct: 7.0% skip:52.1% L0:44.8% L1:51.5% BI: 3.7%
x264 [info]: 8x8 transform intra:46.5% inter:56.4%
x264 [info]: coded y,uvDC,uvAC intra: 20.6% 15.7% 1.2% inter: 6.1% 5.7% 0.0%
x264 [info]: i16 v,h,dc,p: 40% 34% 17% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 30% 41% 2% 3% 2% 4% 2% 4%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 33% 23% 2% 6% 3% 7% 3% 7%
x264 [info]: i8c dc,h,v,p: 68% 20% 11% 1%
x264 [info]: Weighted P-Frames: Y:19.5% UV:7.8%
x264 [info]: ref P L0: 72.6% 27.4%
x264 [info]: ref B L0: 72.5% 27.5%
x264 [info]: ref B L1: 96.4% 3.6%
x264 [info]: kb/s:6255.65

encoded 7392 frames, 15.29 fps, 6255.65 kb/s

Framepacking 5 30fps
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --preset veryfast --ref 2 --crf 25 --frame-packing 5 --psnr --ssim --output "Test-FAST-seq5-30" "C:\...\frameseq-framerate.avs"
avs [info]: 1920x1080p 0:0 @ 30/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:62 Avg QP:22.82 size: 51107 PSNR Mean Y:45.34 U:52.36 V:53.25 Avg:46.54 Global:44.73
x264 [info]: frame P:4380 Avg QP:26.43 size: 17021 PSNR Mean Y:42.53 U:51.30 V:52.36 Avg:43.84 Global:41.87
x264 [info]: frame B:2950 Avg QP:28.06 size: 11937 PSNR Mean Y:44.79 U:55.52 V:56.65 Avg:46.08 Global:40.88
x264 [info]: consecutive B-frames: 30.8% 47.6% 1.1% 20.5%
x264 [info]: mb I I16..4: 35.5% 56.3% 8.2%
x264 [info]: mb P I16..4: 10.5% 9.9% 0.1% P16..4: 27.5% 6.4% 1.5% 0.0% 0.0% skip:44.1%
x264 [info]: mb B I16..4: 7.6% 5.6% 0.1% B16..8: 20.5% 4.7% 0.2% direct: 5.8% skip:55.5% L0:44.8% L1:51.0% BI: 4.2%
x264 [info]: 8x8 transform intra:46.9% inter:53.9%
x264 [info]: coded y,uvDC,uvAC intra: 23.2% 17.3% 1.5% inter: 7.4% 6.3% 0.0%
x264 [info]: i16 v,h,dc,p: 41% 34% 17% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 32% 38% 2% 4% 2% 5% 2% 4%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 34% 22% 2% 6% 3% 7% 3% 7%
x264 [info]: i8c dc,h,v,p: 66% 21% 11% 2%
x264 [info]: Weighted P-Frames: Y:19.5% UV:7.8%
x264 [info]: ref P L0: 73.7% 26.3%
x264 [info]: ref B L0: 73.4% 26.6%
x264 [info]: ref B L1: 96.9% 3.1%
x264 [info]: SSIM Mean Y:0.9642673 (14.469db)
x264 [info]: PSNR Mean Y:43.455 U:52.995 V:54.079 Avg:44.757 Global:41.462 kb/s:3666.73

encoded 7392 frames, 15.67 fps, 3666.73 kb/s

Side by Side 3840x1080
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --preset veryfast --crf 25 --psnr --ssim --output "Test-FAST-SBS" "C:\...\FULLSBS.avs"
avs [info]: 3840x1080p 0:0 @ 10000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 5.0
x264 [info]: frame I:28 Avg QP:22.53 size:111389 PSNR Mean Y:46.55 U:54.14 V:55.01 Avg:47.75 Global:44.83
x264 [info]: frame P:2306 Avg QP:26.53 size: 42867 PSNR Mean Y:42.17 U:50.77 V:51.81 Avg:43.47 Global:41.76
x264 [info]: frame B:1362 Avg QP:28.49 size: 9918 PSNR Mean Y:45.62 U:56.69 V:57.89 Avg:46.93 Global:41.41
x264 [info]: consecutive B-frames: 41.2% 25.8% 9.7% 23.4%
x264 [info]: mb I I16..4: 34.2% 56.1% 9.7%
x264 [info]: mb P I16..4: 14.8% 16.4% 0.2% P16..4: 23.2% 9.6% 2.6% 0.0% 0.0% skip:33.2%
x264 [info]: mb B I16..4: 1.1% 0.8% 0.0% B16..8: 12.5% 2.8% 0.1% direct: 2.5% skip:80.1% L0:35.1% L1:55.0% BI: 9.9%
x264 [info]: 8x8 transform intra:52.0% inter:51.1%
x264 [info]: coded y,uvDC,uvAC intra: 25.6% 17.3% 1.6% inter: 7.1% 6.4% 0.1%
x264 [info]: i16 v,h,dc,p: 40% 34% 17% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 35% 34% 2% 4% 2% 5% 2% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 34% 22% 2% 6% 3% 7% 3% 7%
x264 [info]: i8c dc,h,v,p: 66% 22% 11% 2%
x264 [info]: Weighted P-Frames: Y:17.0% UV:10.0%
x264 [info]: SSIM Mean Y:0.9645624 (14.505db)
x264 [info]: PSNR Mean Y:43.475 U:52.980 V:54.078 Avg:44.778 Global:41.642 kb/s:7498.57

encoded 3696 frames, 7.86 fps, 7498.57 kb/s

LEFT alone
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --crf 25 --preset veryfast --psnr --ssim --output "Test-FAST-left" "C:\...\left.avs"
avs [info]: 1920x1080p 0:0 @ 10000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:30 Avg QP:22.76 size: 50677 PSNR Mean Y:46.38 U:53.88 V:54.84 Avg:47.59 Global:44.80
x264 [info]: frame P:2288 Avg QP:26.49 size: 21526 PSNR Mean Y:42.16 U:50.70 V:51.76 Avg:43.47 Global:41.75
x264 [info]: frame B:1378 Avg QP:28.46 size: 5023 PSNR Mean Y:45.56 U:56.75 V:57.97 Avg:46.87 Global:41.36
x264 [info]: consecutive B-frames: 40.5% 26.1% 9.7% 23.7%
x264 [info]: mb I I16..4: 34.5% 57.3% 8.2%
x264 [info]: mb P I16..4: 14.8% 16.5% 0.2% P16..4: 23.3% 9.6% 2.6% 0.0% 0.0% skip:33.1%
x264 [info]: mb B I16..4: 1.1% 0.9% 0.0% B16..8: 12.5% 2.8% 0.1% direct: 2.6% skip:80.0% L0:34.9% L1:55.2% BI: 9.9%
x264 [info]: 8x8 transform intra:52.1% inter:51.1%
x264 [info]: coded y,uvDC,uvAC intra: 25.7% 17.2% 1.6% inter: 7.1% 6.4% 0.1%
x264 [info]: i16 v,h,dc,p: 40% 34% 17% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 35% 34% 2% 4% 2% 5% 2% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 34% 23% 2% 6% 3% 7% 3% 7%
x264 [info]: i8c dc,h,v,p: 66% 22% 10% 2%
x264 [info]: Weighted P-Frames: Y:17.0% UV:10.5%
x264 [info]: SSIM Mean Y:0.9642113 (14.463db)
x264 [info]: PSNR Mean Y:43.463 U:52.982 V:54.101 Avg:44.770 Global:41.617 kb/s:3746.32

encoded 3696 frames, 14.82 fps, 3746.32 kb/s

RIGHT alone
C:\Users\BlackShark>"C:\Users\BlackShark\Downloads\x264_1867.exe" --crf 25 --preset veryfast --psnr --ssim --output "Test-FAST-right" "C:\...\right.avs"
avs [info]: 1920x1080p 0:0 @ 10000000/333333 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:27 Avg QP:22.57 size: 55457 PSNR Mean Y:46.63 U:54.26 V:55.06 Avg:47.81 Global:44.82
x264 [info]: frame P:2307 Avg QP:26.54 size: 21394 PSNR Mean Y:42.22 U:50.92 V:51.97 Avg:43.52 Global:41.79
x264 [info]: frame B:1362 Avg QP:28.47 size: 5037 PSNR Mean Y:45.56 U:56.46 V:57.68 Avg:46.86 Global:41.39
x264 [info]: consecutive B-frames: 41.2% 25.5% 10.1% 23.2%
x264 [info]: mb I I16..4: 34.8% 55.5% 9.8%
x264 [info]: mb P I16..4: 14.7% 16.4% 0.2% P16..4: 23.1% 9.5% 2.6% 0.0% 0.0% skip:33.4%
x264 [info]: mb B I16..4: 1.1% 0.8% 0.0% B16..8: 12.5% 2.8% 0.2% direct: 2.6% skip:80.1% L0:34.6% L1:55.3% BI:10.1%
x264 [info]: 8x8 transform intra:52.1% inter:51.1%
x264 [info]: coded y,uvDC,uvAC intra: 25.6% 17.4% 1.6% inter: 7.1% 6.4% 0.1%
x264 [info]: i16 v,h,dc,p: 41% 33% 17% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 35% 35% 2% 4% 2% 5% 2% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 34% 23% 2% 6% 3% 7% 3% 7%
x264 [info]: i8c dc,h,v,p: 66% 22% 10% 2%
x264 [info]: Weighted P-Frames: Y:17.3% UV:10.2%
x264 [info]: SSIM Mean Y:0.9647482 (14.528db)
x264 [info]: PSNR Mean Y:43.479 U:52.988 V:54.092 Avg:44.783 Global:41.656 kb/s:3747.71

encoded 3696 frames, 14.97 fps, 3747.71 kb/s

rica
12th January 2011, 02:06
Turning off B-Pyramid sounds like the way to go...

My friend pls give me the recipe. :)

What i'm trying to do here is to add a blank video to the right video.
The blank video is consist of missing frames and re-encoded to x264.

blank.avs:

BlankClip(length=60, width=1920, height=1080)

ConvertToYV12()

Created blank.264 via x264... (using above script)

And the final avs would be:

v1=DirectShowSource("C:\H264StereoSource_a2\out.avs", fps=23.976, audio=false)
v2=DirectShowSource("C:\H264StereoSource_a2\blank.264", fps=23.976, audio=false)
V=v1+v2
ConvertToYV12()

But i have to make blank.264 2 frames first since the right is 2.

Otherwise:
(Image loss)

BigPines
12th January 2011, 02:39
BlackShark,

This is very disappointing. I may have to rethink using Frame Sequential altogether. Bummer...before I worry about getting this working for the PS3, I think I better do some encoding tests myself.

Mike

Zerofool
12th January 2011, 03:07
Yesterday i gave it a go with H264StereoSource again. This time i tried to use right video without recompressing it to a lossy x264:
...

rica, I guess you've missed my post:
My second suggestion was to merge second step and third step into one single step (again, using H264StereoSource) by directly combining the left and right views as they are decoded on the fly. Exactly what nm is talking about here:
But have you tried using it within your 3rd step script:

lv = DGSource("C:\xx\left.dgi")

rv = H264StereoSource("decoder.cfg",xxxxx)

I don't see why that would fail if the separately encoded right view is ok.
I did lots of tests today (and continuing as we speak). All my initial experiments ended with crashes when starting the encoding process with x264. But, if I first open the avs script in vdub, start a frameserver and open the vdr in x264 (megui) through avisynth - it works :) ...
But obviously, there's the same problem of dropped frames/lost sync with this approach as well (thanks to the decoder I guess). Sometimes it appears, sometimes it's just fine.
So basically what I said back then was that it works, so just try the same thing, and it should work for you too. If you wish, I could explain it step by step, so you could do it in exactly the same way.
I guess BlackSharkfr could also share his method of avoiding the crash in x264 (i.e. how to "manually force x264 to start encoding at frame 1").

I also spotted the newly released rev.1867 today, which contains the frame-sequential optimizations by Dark Shikari (many thanks, we really appreciate it!). I've been testing for the last few hours (crf), and I get different result from you, BlackSharkfr. I'm using the 64-bit build from xvidvideo.ru (with 32-bit megui). My first test was with a trailer (80sec) from BluRay, I first compared frame-sequential video with the --frame-packing 5 flag, and without it. The difference in the bitrate was 0.32 Kbps (~3kb in final file size) with my settings (close to placebo), then I encoded the same source as SBS (with forced double the framerate). The resulfing file was 21.6% bigger than the frame-sequential ones. In terms of IQ I think the SBS file looked just a tad better.
Then I tested with some simple CGI renders (60fps per eye, 15sec), the SBS file was just 5.0% bigger than the flagged frame-sequential vid (forced to half the fps for the encode). Quality-wise, I think the SBS clip looked little worse, showing some more noticeable banding issues in color gradients.
And finally - some videogame footage (60 fps per eye, 47sec), the SBS file was 16.8% bigger than the forced half-fps interleaved. I can't say which one looks better.
I'll do some more, longer tests in the future.

LoRd_MuldeR
12th January 2011, 11:15
Created blank.264 via x264... (using above script)

And the final avs would be:

v1=DirectShowSource("C:\H264StereoSource_a2\out.avs", fps=23.976, audio=false)
v2=DirectShowSource("C:\H264StereoSource_a2\blank.264", fps=23.976, audio=false)
V=v1+v2
ConvertToYV12()

But i have to make blank.264 2 frames first since the right is 2.

Why do you need an intermediate file? Why not do it like this:

v1 = FFVideoSource("C:\Some Folder\Original Source.foo", fps=23.976, audio=false)
v2 = v1.BlankClip(length=60)
V = v1 + v2
return V.ConvertToYV12()

And how is this releated to the number of reference frames and/or B-Pyramid? :confused:

If you don't want to enable B-Pyramid, you simply set the x264 options accordingly when encoding from the AVS script.

Just like this: x264.exe --b-pyramid none -o output.mkv input.avs

BigPines
12th January 2011, 18:55
Rica,

Rather than struggling with splicing blank frames in one clip, it may be easier to simply trim the appropriate number of frames from the other clip. Just an idea...

Mike

nm
12th January 2011, 19:27
It's like fighting windmills anyway because the actual problem is somewhere else than in clip lengths.

@rica:
Check the right and left video parameters with info() as I and J_Darnley suggested earlier.

BigPines
12th January 2011, 19:40
Yep, you are probably correct. Someone must have already done this and figured it out.

Mike

BlackSharkfr
12th January 2011, 21:32
Maybe one of the clips is decoded as RGB and the other is decoded as one of the YUV subsampled formats.
Try adding ConvertToYV12() for each source before assembling them.

My wor around with the frame count was only at the encoding stage, Megui just crashed to desktop with a fatal windows error. I don't have the exact line I used anyore, I think Ionly added --seek 1 to the x264 command line to make it start at frame 1. It was something very simple.

rica
12th January 2011, 22:04
Hi guys.
I have to appreciate to you all for your efforts to help me.

Zerofool, i haven't missed your post and i already gave it a go with DGNVTools.
Later i gave it a go with an Ati card. (i'm still with an ati for test.)
And i tried this also:

LoadPlugin("H264StereoSource.dll")

lv = DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)
rv = H264StereoSource("decoder.cfg",64174)

Interleave(lv, rv)
ConvertToYV12()

None of them worked.


Lord_Mulder,

I got :

"format settings, ReFrames > 3 Frames with this code: (instead of 2 frames)

C:\H264StereoSource_a2>x264 --fps 23.976 --b-pyramid none --level 4.1 --sar 1:1 --aud -o blank.264 blank.avs

rica
12th January 2011, 22:22
It's like fighting windmills anyway because the actual problem is somewhere else than in clip lengths.

@rica:
Check the right and left video parameters with info() as I and J_Darnley suggested earlier.

Two questions:

Shall i test source videos?

How i use this "info()" and in what command?

nm
12th January 2011, 22:26
Two questions:

Shall i test source videos?

How i use this "info()" and in what command?

Write two scripts:

DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)
info()

and
LoadPlugin("H264StereoSource.dll")
H264StereoSource("decoder.cfg",64174)
info()


Play them and see what AviSynth prints on the video.

sneaker_ger
12th January 2011, 22:38
I have to side with LoRd_MuldeR - what are you trying to achieve by meddling with the number of reference frames? AviSynth's splice or interleave functions do not care about such things, they only see color formats and resolutions.

rica
12th January 2011, 22:44
OK, thanks nm.

Left.avs:

DirectShowSource("C:\H264StereoSource_a2\left.h264", fps=23.976, audio=false)
info()

http://img191.imageshack.us/img191/8172/leftjb.png (http://img191.imageshack.us/i/leftjb.png/)


Right.avs:

DirectShowSource("C:\H264StereoSource_a2\out.avs", fps=23.976, audio=false)
info()

(FYI out.avs is here:

LoadPlugin("H264StereoSource.dll")
H264StereoSource("decoder.cfg",64174)
)


http://img401.imageshack.us/img401/6031/rightci.png (http://img401.imageshack.us/i/rightci.png/)



PS: out.avs crashes any application when it's used by alone.

LoadPlugin("H264StereoSource.dll")
H264StereoSource("decoder.cfg",64174)
info()


_ _ _ _

rica
12th January 2011, 23:06
info() says:
left: 103652 frames
right: 61546 frames.

I don't know what it means?

I'm about to fell myself as an idiot.

BigPines
12th January 2011, 23:17
That is the only difference I could see too. 42,106 frames difference! That is nearly 30 minutes of video at 23.976 fps. Something definitely seems wrong with that right clip either way.

Mike

rica
12th January 2011, 23:21
On the other hand after encoding right video to x264(over out.avs), seems only 60 frames are missing.

:mad::mad::mad:

rica
12th January 2011, 23:27
Guys,
the test 3DBD is Grand Canyon of IMAX btw.

I've given up testing; i'm tired enough...

nm
13th January 2011, 00:29
That is the only difference I could see too.

But the difference that caused rica's frame size error is ... surprise, surprise ... the frame size: 1920x1088 for the left view and 1920x1080 for the right. As I suspected in the beginning. It's probably caused by whatever DirectShow decoder gets used for the video in his system. Try FFMS2 instead.

The length difference is another issue. What is the correct number of frames?

rica
13th January 2011, 00:46
But the difference that caused rica's frame size error is ... surprise, surprise ... the frame size: 1920x1088 for the left view and 1920x1080 for the right. As I suspected in the beginning. It's probably caused by whatever DirectShow decoder gets used for the video in his system. Try FFMS2 instead.

The length difference is another issue. What is the correct number of frames?

Really weird; i haven't bewared the left is 1088. My display is an HDTV and it is far from me and i couldn't differ.
(anyway MediaInfo showed both videos as 1080 btw)

And the real total frame number is 64174.

So i suspect whether the information of this "info()" is OK?