Any free MVC encoder yet?

[nm]

I've discovered FFVideo Source gives the right information and no need to crop

[...]
LoadPlugin("H264StereoSource.dll")
lv= FFVideoSource("C:\H264StereoSource_a2\left.m2ts")
rv = H264StereoSource("decoder.cfg",64172)
Interleave(lv, rv)
ConvertToYV12()

I think I told you to try that at least three times in this thread..?


But i must say i never advise frame sequential; I really got tired while watching it.

Stick with Side By Side or Top Bottom method...


There's still something wrong with your encode or the player if there's that kind of a difference. More likely it's a placebo effect.

Could you upload sample clips of both encodes?

[rica]

More likely it's a placebo effect.

Could you upload sample clips of both encodes?

I hope it's a placebo effect.
I will upload the samples this evening.
Thanks.

[rica]

Side by Side (left-right):

http://www.mediafire.com/?dq8vng4kzxf7nbe


Frame Sequential: (left first)

http://www.mediafire.com/?btleid020d6bfkt


Both files are re-encoded using ffVideoSource method:

http://forum.doom9.org/showpost.php?p=1471971&postcount=300

_ _

[rica]

Guys,

I wonder if anybody have had a look at those uploaded re-encodes on above post?

[nm]

Guys,

I wonder if anybody have had a look at those uploaded re-encodes on above post?

I looked now, but I don't have stereo gear, so I simply interleaved the corresponding views from both files to check for any differences frame by frame.

left.avs

LoadPlugin("ffms2.dll")
a=FFVideoSource("fs.mp4").trim(612,0).selecteven()
b=FFVideoSource("ss.mp4").crop(0,0,1920,1080)
a=a.subtitle("FS", size=32, align=9)
b=b.subtitle("SS", size=32, align=9)
interleave(a,b)


right.avs

LoadPlugin("ffms2.dll")
a=FFVideoSource("fs.mp4").trim(612,0).selectodd()
b=FFVideoSource("ss.mp4").crop(1920,0,1920,1080)
a=a.subtitle("FS", size=32, align=9)
b=b.subtitle("SS", size=32, align=9)
interleave(a,b)

(Had to remux the streams to MP4 since I'm on Linux and FFMS2 doesn't support TS very well without Haali's splitter.)


Comparing the left view of the frame sequential video to the left view of the side-by-side video revealed only minor differences due to compression. Sharp edges and objects were visually identical in both. It's difficult to say which video is closer to the source without a reference.

Same deal with the right view.

However, there's a color difference between the views in both files. That might cause some discomfort, but the problem is the same in both files. I'd blame H264StereoSource for it.

[rica]

I looked now, but I don't have stereo gear, so I simply Comparing the left view of the frame sequential video to the left view of the side-by-side video revealed only minor differences due to compression. Sharp edges and objects were visually identical in both. It's difficult to say which video is closer to the source without a reference.

Same deal with the right view.

However, there's a color difference between the views in both files. That might cause some discomfort, but the problem is the same in both files. I'd blame H264StereoSource for it.

Thanks for the feedback.
Really it's hard to say the difference. (unless watching them in 3D mode.)

[rica]

And with Adam's tool: (full rsolution too.)

SetMemoryMax (64)
LoadPlugin("C:\DG\DGDecodeNV.dll")
LoadPlugin("H264StereoSource.dll")
lv = DGSource("C:\blabla\left.dgi")
rv= H264StereoSource("decoder.cfg",*****)
LeftRight3D(lv, rv)
ConvertToYV12()

SetMemoryMax (64)
LoadPlugin("C:\DG\DGDecodeNV.dll")
LoadPlugin("H264StereoSource.dll")
lv = DGSource("C:\blabla\left.dgi")
rv= H264StereoSource("decoder.cfg",*****)
TopDown3D(lv, rv)
ConvertToYV12()

And:

C:\H264StereoSource_a2>x264 --fps 24000/1001 --level 4.1 --sar 1:1 --aud -o leftright_adam.264 leftright_adam.avs

C:\H264StereoSource_a2>x264 --fps 24000/1001 --level 4.1 --sar 1:1 --aud -o topbottom.264 topbottom_adam.avs


_ _ _ _ _

[nm]

Really it's hard to say the difference. (unless watching them in 3D mode.)
Then you have a playback problem. Maybe one of the views is delayed by 1 frame:

frame-sequential stream: L1 R1 L2 R2 L3 R3 ...

instead of displaying frames L2 and R2 at the same time the player displays L3 and R2.

[rica]

Then you have a playback problem. Maybe one of the views is delayed by 1 frame:

frame-sequential stream: L1 R1 L2 R2 L3 R3 ...

instead of displaying frames L2 and R2 at the same time the player displays L3 and R2.

Not sure, maybe it's related with decoding to checkerboard issue. (by my DLP-Link PJ)
Finally i get tired while watching frame sequential encoded files while i'm comfortable with side by side or top bottom.

[BlackSharkfr]

The git tree at videolan has been updated with a patch that fixes the rate control and framerate issue with frame sequential.
Now waiting for the builds to test again.

[BigPines]

If anyone has Frame Sequential working on the PS3, I would love to hear about it.

Mike

[BlackSharkfr]

Alright I just did a new encoding test with the latest x264 version from x264.nl (rev1884) and my usual stereoscopic source and... the CRF quality difference is gone, both streams look almost identical so that is good, there is just one problem : I get no bitrate gain at all.
I used dfault options, just with frame-packing 5. Would there be any particular option I should enable that could trigger the huge bandwidth gains DarkShikari got in his test last month ?

There is still that little thing with the picture I can't really describe, some parts are just as sharp on both encodings but some very specific parts seem a little blurred, it's like the psy-opts would prioritize different parts of the picture in some very specific conditions.


C:\Users\BlackShark>C:\Users\BlackShark\...\x264_1884.exe --crf 21 --frame-packing 5 --psnr --ssim -o 1884-crf21-frameseq
C:\Users\...\Video-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:18.60 size: 91066 PSNR Mean Y:47.72 U:54.71 V:55.53 Avg:48.94 Global:47.10
x264 [info]: frame P:4380 Avg QP:22.30 size: 36151 PSNR Mean Y:45.47 U:53.94 V:54.93 Avg:46.77 Global:44.74
x264 [info]: frame B:2950 Avg QP:24.34 size: 25199 PSNR Mean Y:47.94 U:58.00 V:58.97 Avg:49.20 Global:43.66
x264 [info]: consecutive B-frames: 30.8% 47.6% 1.1% 20.5%
x264 [info]: mb I I16..4: 22.1% 63.1% 14.7%
x264 [info]: mb P I16..4: 4.2% 9.1% 0.9% P16..4: 40.9% 11.6% 5.7% 0.0% 0.0% skip:27.6%
x264 [info]: mb B I16..4: 3.1% 3.5% 0.3% B16..8: 32.9% 7.6% 1.3% direct: 9.3% skip:42.1% L0:47.4% L1:49.4% BI: 3.2%
x264 [info]: 8x8 transform intra:60.8% inter:73.6%
x264 [info]: coded y,uvDC,uvAC intra: 41.3% 40.8% 6.5% inter: 28.2% 20.0% 0.3%
x264 [info]: i16 v,h,dc,p: 34% 34% 8% 25%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 24% 30% 4% 6% 4% 11% 3% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 33% 18% 4% 7% 5% 10% 3% 6%
x264 [info]: i8c dc,h,v,p: 61% 24% 11% 4%
x264 [info]: Weighted P-Frames: Y:19.5% UV:7.8%
x264 [info]: ref P L0: 63.6% 13.4% 16.8% 5.6% 0.6%
x264 [info]: ref B L0: 75.1% 24.5% 0.4%
x264 [info]: ref B L1: 97.6% 2.4%
x264 [info]: SSIM Mean Y:0.9771880 (16.418db)
x264 [info]: PSNR Mean Y:46.472 U:55.568 V:56.544 Avg:47.758 Global:44.289 kb/s:15475.64

encoded 7392 frames, 9.00 fps, 15475.64 kb/s

C:\Users\BlackShark>C:\Users\BlackShark\...\x264_1884.exe --crf 21 --frame-packing 3 --psnr --ssim -o 1884-crf21-SBSfull C:\Users\BlackShark\...\Video-SBSFull.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:18.26 size:194588 PSNR Mean Y:48.91 U:56.39 V:57.15 Avg:50.12 Global:47.25
x264 [info]: frame P:2307 Avg QP:22.49 size: 84652 PSNR Mean Y:45.08 U:53.36 V:54.38 Avg:46.37 Global:44.59
x264 [info]: frame B:1361 Avg QP:24.47 size: 24946 PSNR Mean Y:49.00 U:59.16 V:60.16 Avg:50.25 Global:44.35
x264 [info]: consecutive B-frames: 41.2% 25.8% 9.7% 23.3%
x264 [info]: mb I I16..4: 21.2% 63.4% 15.4%
x264 [info]: mb P I16..4: 6.2% 14.9% 1.5% P16..4: 39.2% 12.4% 5.1% 0.0% 0.0% skip:20.7%
x264 [info]: mb B I16..4: 0.4% 0.7% 0.1% B16..8: 33.3% 3.6% 0.7% direct: 1.9% skip:59.4% L0:41.5% L1:52.8% BI: 5.7%
x264 [info]: 8x8 transform intra:65.4% inter:76.8%
x264 [info]: coded y,uvDC,uvAC intra: 46.9% 41.5% 6.8% inter: 22.1% 19.2% 0.3%
x264 [info]: i16 v,h,dc,p: 30% 35% 7% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 25% 27% 5% 6% 4% 11% 3% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 35% 17% 4% 7% 5% 11% 3% 6%
x264 [info]: i8c dc,h,v,p: 60% 25% 12% 4%
x264 [info]: Weighted P-Frames: Y:17.1% UV:10.0%
x264 [info]: ref P L0: 67.9% 17.8% 10.3% 3.7% 0.2%
x264 [info]: ref B L0: 91.0% 8.1% 0.9%
x264 [info]: ref B L1: 95.7% 4.3%
x264 [info]: SSIM Mean Y:0.9781515 (16.606db)
x264 [info]: PSNR Mean Y:46.552 U:55.522 V:56.529 Avg:47.830 Global:44.517 kb/s:15239.71

encoded 3696 frames, 4.38 fps, 15239.71 kb/s

[MDF]

I had a similar experience, mine depended on the source I'd used for encoding:

On separate YUV raws (left and right) I'd obtained very little gain, either on bitrate and PSNR (almost close to zero, even negative in some cases), especially 1080p on sequences, for 720p I did still obtained a decent 30~35%.
But when I used a .wmv sequence (downloaded from 3dtv.at :P) the gains were up to 50%, which was still 1080p sequence, but different from the YUV ones.

I still don't know if this depends on the nature of the sequence per see, or the fact that the video was previously encoded which makes the encoding more efficient?!?!

[Dark Shikari]

My hunch:

1. B-frames help more on SBS than frame-packing.
2. Frame-packing helps significantly on sources where inter prediction works well.

If inter prediction works very well -- as in a video with little or no grain -- even the effect of 1) isn't nearly enough to compensate for the fact that frame-packing works so well. My original test video was an artificial Call of Duty clip, which of course had zero grain and predicted perfectly.

However, if your video has lots of grain, SBS may be similar, or even slightly better.

[BlackSharkfr]

My test video is also artificial : I used the game Trackmania to render a replay sequence, there is no grain in the video, just landscape, cars and motion blur.
The problem in my case is that I see almost no gains at all, both SBS and Frame sequential are extremely close to each other, and more importantly : there is almost no gain even over separate left and right streams.

I tried re-encoding the encoded files, to see if the blurring caused by compression triggers anything : I got very small results (8% : about 20MB less out of a 230MB original encode) when doing two successive encodes with the same process (two frame sequential in a row or two side by side in a row). But then the visual quality also suffers a little, so I'm not even sure if these benefits aren't caused just by the more blurry source than any actual optimisation.
More interesting : if I create a frame sequential encode from the side by side compressed file, I get a negative effect, the final video is bigger than the source (not by much, though). This would confirm the artefacts introduced by frame sequential are different from the ones of side by side.

I also just tried to resize to 720p, it's still a draw. The file size dropped by half though (it's logic, 720p is half the amount of pixels of 1080p).

[invincible]

Hi! Stereocopic Player 1.66 is compatible with x264 1913 --frame-packing 5, isn't it?
I have some unsync when play.

[BlackSharkfr]

Stereoscopic player is compatible with frame alternate, but I don't think it can auto-detect when frame-packing 5 is used or self self resynchronize if a bug caused unsync.

[invincible]

When I encode 3D : x264 --setting --output test.mkv test.avs. I open mkv file with Stereoscopic player, It plays OK. But when I mux the mkv file with mkvmerge and open it, it has some unsync frame when play. I used x264 r1913. I think ffdshow or mkvmerge or Stereoscopic player is not compatible with r1913. Everything is OK with r1884. The video source I encode is interleave 2 files with --frame-packing 5 technology (24/1.001 fps for each file)

[rica]

I think this is mkvmerge. Try to mux with GraphStudio so as to compare.

[BlackSharkfr]

I'm relaying a message, a few people at AVSforums still can't get their 3D frame sequential files play on their PS3s.
Has there been any improvement on the frame packing SEI message at every frame to match Sony's implementation ?

[invincible]

I saw on x264 page:
"Frame-packing 3D: don't place scenecuts on right views
Caused problems for some players."
So this is the reason made Stereoscopic player had some unsync frame when play?

[BlackSharkfr]

Stereoscopic player does not understand the Frame packing SEI messages, when using the frame sequential mode it just takes the frames one after the other. If it gets the frame count wrong it means you have an issue with the frames not arriving in the correct order. It can mean either an encoding or a decoding issue.

[rica]

Guys, haven't found any way to add subtitles to side by side encoded videos. (3840*1080)
Any ideas?

[nm]

Guys, haven't found any way to add subtitles to side by side encoded videos. (3840*1080)
Any ideas?

During encoding (to draw the subtitles on video) or playback?

[rica]

During encoding (to draw the subtitles on video) or playback?

I'd prefer during "playback" but if not i want to know how to add while encoding.
Thanks.

[nm]

ffdshow has a stereoscopic subtitling feature for side-by-side video. It can be enabled in Subtitles->Placement options.

AviSynth subtitling filters can be used to draw a pair of subtitles on the video during encoding.

[rica]

Thanks nm, selecting "stereoscopic" option fixed the playing with subtitle issue.

[Nick [D]vB]

FYI - New Stereoscopic player 1.6.9 with CoreMVC trail out now:

http://forum.doom9.org/showthread.php?p=1486088#post1486088

:)

[invincible]

I use stereoscopic player 1.66+ffdshow+haali+mkvmerge+x264 r1913
I try to encode 2 3D movies with frame packing 5 (Frame-sequential)
All of 2 movies get unsync frames from 00:52:30 to 00:57:00 when play with stereoscopic player (encoder x264, decoder ffdshow+haali, container mkvmerge 4.6.0)
So I think all movies that have more than 1h will have unscync frame at that time. Movies have less than 52:30 play fine.
I think one of my software has a bug, so everyone can test this thing?
This problem occurs only with Frame-sequential, others are fine.

[rica]

@Nick [D]vB, even i had no time to start a new topic here i'm sure you might be interested in how i fixed anaglyph to SBS via DG NVTools in advance?

Check out the post 9 here:

http://neuron2.net/board/viewtopic.php?f=8&t=110&start=10


_ _ _ _ _

[Nick [D]vB]

Thanks rica, good work! We better keep this thread on topic so I have replied in the dvbviewer thread. :)

[k-c-ksum]

anyone tried
mainconcept 2.2 mvc beta trial - http://downloads.mainconcept.com/mdl/mdl1.php?c4656f8b7f2b7756a1784a5404065f65

encoding seems to go fine and 2 streams are created but niether stream will open in ts muxer which is strange as it can open the left eye stream from a 3d bluray just fine, only limitation of the ref 2.2 mvc encoder is it encodes a watermark onto the video but as i cant open its output im not sure how invasive it actuallly is :(

[shon3i]

anyone tried
mainconcept 2.2 mvc beta trial - http://downloads.mainconcept.com/mdl/mdl1.php?c4656f8b7f2b7756a1784a5404065f65

encoding seems to go fine and 2 streams are created but niether stream will open in ts muxer which is strange as it can open the left eye stream from a 3d bluray just fine, only limitation of the ref 2.2 mvc encoder is it encodes a watermark onto the video but as i cant open its output im not sure how invasive it actuallly is :(
Did you follow BD specs? Mainconcept MVC can go outside BD MVC specs. I tested with Cinevision and left eye is normal 264 file.

[k-c-ksum]

Did you follow BD specs? Mainconcept MVC can go outside BD MVC specs. I tested with Cinevision and left eye is normal 264 file.

i just left everything as default apart from selecting split view.

[rica]

You can open right video with only MVCDecoder.
Here is the main thread:
http://forum.doom9.org/showthread.php?t=155246

And you may find some of my post related with re-encoding to x264 SBS here:

http://forum.doom9.org/showpost.php?p=1471971&postcount=300


http://forum.doom9.org/showpost.php?p=1471898&postcount=295

And the other method:

http://forum.doom9.org/showthread.php?p=1473807#post1473807

[k-c-ksum]

You can open right video with only MVCDecoder.
Here is the main thread:
http://forum.doom9.org/showthread.php?t=155246

And you may find some of my post related with re-encoding to x254 SBS here:

http://forum.doom9.org/showpost.php?p=1471971&postcount=300


http://forum.doom9.org/showpost.php?p=1471898&postcount=295

i should at least be able to open the left eye stream though TSmuxer has never complained before when opening a left eye stream :( not really interested in SBS, sorry

[rica]

I think you will have to be interested in SBS soon. :)

[k-c-ksum]

I think you will have to be interested in SBS soon. :)

hope not, with 1080p 3d video cameras available there will be a growing market for full left/right eye 1080 muxing, i think the only reason SBS is popular is because there are no consumer affordable alternatives :(
anyone opened the left eye stream created with the mainconcept mvc encoder in tsmuxer?, it will fail at opening the right eye stream but it should open the left eye stream without issues

[rica]

anyone opened the left eye stream created with the mainconcept mvc encoder in tsmuxer?, it will fail at opening the right eye stream but it should open the left eye stream without issues

AFAIK nobody has been able to open right video with TSMuxer; this is why i was telling that.

[k-c-ksum]

AFAIK nobody has been able to open right video with TSMuxer; this is why i was telling that.

i know, but why wont it open the left eye stream either

[shon3i]

Split it (20mb) with dgsplitter and upload it to mediafire, maybe is some grabage on beginning of file, like DTS master suite add to dts streams.

[kieranrk]

This is being worked on as part of Google Summer of Code 2011. Information about any non-standard rules in the Blu-Ray 3D spec would be appreciated.

[rica]

Guys even i know it is a cross-post, i felt i should repeat it here:
H264StereoSource.dll doesn't decode Tron Legacy 3D's right hand video. Any feed-back would be appreciated.

[kolak]

L eye is just a normal AVC, but to decode R you need both files and MVC decoder (but I think you know this). R stream by itself is useless.

Andrew

[rica]

L eye is just a normal AVC, but to decode R you need both files and MVC decoder (but I think you know this). R stream by itself is useless.

Andrew

I know but this SS will explain: (L is on the left and R is on the right.)

http://img820.imageshack.us/img820/4725/hereitis.png (http://imageshack.us/photo/my-images/820/hereitis.png/)


_ _ _ _

[rica]

Sorry, i forgot to point out it has been fixed:

http://forum.doom9.org/showthread.php?p=1508988#post1508988

_ _ _ _

[nickolasemp]

So let me get this straight, because I am trying to encode my own 3D bluray collection and move it to my NAS.

Dark Shikari in this (http://forum.doom9.org/showthread.php?p=1465964#post1465964)post and especially in this (http://forum.doom9.org/showthread.php?p=1464453#post1464453) post says that frame sequential is the best way to go (with frame-packing 5 option).

However, DarkShark's results (in this (http://forum.doom9.org/showthread.php?p=1470512#post1470512) post) show no such improvement.

As DarkShark says in this (http://www.avsforum.com/avs-vb/showthread.php?p=20590045#post20590045) post If reencoding, theory says frame sequential should be the way to go since it should allow optimisations similar to MVC.
Unfortunately, current implementations in AVC encoders just don't take advantage of them. An x264 developer claimed he got a nice quality/bitrate boost with one of his test footage, unfortunately this never happened with my own test footage, the results I had were the opposite. I got lower quality than independent streams for higher bitrate because depth was interpreted as motion, the adaptiv quality algorithms detects separated elements of the image as motion and applies blur to spare the bitrate for stuff it believed were not moving (the parts at screen depth). It did not create ghosting (i did not test ultra-low bitrates though).
At the moment the best scheme for reencoding is to do side by side at full resolution if you play the video with a PC and at half resolution if you have to play it with a stand alone device. (since no stand alone device currently supports side by side full resolution)

So what am I supposed to encode my BluRays? SBS or framesequential?

Thank you very much in advance for your time in this lengthy, time-consuming post.:thanks:

[shon3i]

So what am I supposed to encode my BluRays? SBS or framesequential?frame sequential or mvc, but since there is no yet "free" mvc encoder then answer is framesequential. But here (http://forum.doom9.org/showthread.php?p=1529465#post1529465) can be found mvc patch for x264, i don't know compiled x264 can be found.

[nickolasemp]

frame sequential or mvc, but since there is no yet "free" mvc encoder then answer is framesequential. So, considering I have both views, in order to have frame sequential all I have to do is put in Avisynth Interleave(lv, rv) and in x264 the option frame-packing 5, and then I will take advantage of a special algorithm so as to save bit-rate, right?

What about what DarkShark's results? I am saying all that because currently SBS is currently presenting no trouble to my PC, but is still bitrate consuming.

[nm]

So, considering I have both views, in order to have frame sequential all I have to do is put in Avisynth Interleave(lv, rv) and in x264 the option frame-packing 5, and then I will take advantage of a special algorithm so as to save bit-rate, right?

Right, except that there is no special algorithm. The credit for possible bitrate savings compared to side-by-side go to normal H.264 encoding algorithms. x264 doesn't switch to any special stereo mode when you use frame-packing 5 -- it just adds flags to the stream and avoids some keyframe issues.

What about what DarkShark's results? I am saying all that because currently SBS is currently presenting no trouble to my PC, but is still bitrate consuming.

Try both yourself and post the results.