Any free MVC encoder yet?

[nm]

By the way, I encoded a 1920x2160 top/bottom using --frame-packing 3 by mistake. Seems to work fine though. Any reason?

Maybe your decoder or player ignores the --frame-packing SEI and uses some frame size heuristics. Which decoder and player are you using?


Why 60 fps?

Why not if that's what he has?

Btw, do you have some specific hardware player that supports side-by-side 3D with frame sizes above 1920x1080, or why are you using Blu-ray presets for the encodes? I don't think they'll be 3D Blu-ray compatible, afterall, or have you read the specs?

[mariner]

Maybe your decoder or player ignores the --frame-packing SEI and uses some frame size heuristics. Which decoder and player are you using?


MPC with CoreAVC/DiVAC.

Name: 700_v17.mkv
Size: 112.13MB
Description: 1920x2160/60p 3D Top/Bottom
http://www.sendspace.com/file/x0fr5l

This is the file properties:

General
Complete name : D:\3D\700_v17.mkv
Format : Matroska
File size : 112 MiB
Duration : 13s 981ms
Overall bit rate : 67.3 Mbps
Writing application : x264 r1834 a51816a
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 13s 981ms
Bit rate : 65.9 Mbps
Width : 1 920 pixels
Height : 2 160 pixels
Display aspect ratio : 0.889
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.265
Stream size : 110 MiB (98%)
Writing library : x264 core 112 r1834 a51816a
Encoding settings : cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English

[nm]

MPC with CoreAVC/DiVAC.

They certainly won't use the frame packing SEI for anything. How are you then displaying the video in stereo?

[mariner]

They certainly won't use the frame packing SEI for anything. How are you then displaying the video in stereo?

Using polarised dual-projector setup championed by BlackShark.

[nm]

Using polarised dual-projector setup championed by BlackShark.

So how do you get the frames to right screens? Does that somehow happen automagically for both side-by-side and top-bottom videos when you play them in MPC?

[rica]

Btw, do you have some specific hardware player that supports side-by-side 3D with frame sizes above 1920x1080, or why are you using Blu-ray presets for the encodes? They won't really be Blu-ray compatible, afterall.

I know none of them is BD compatible; some trials for archiving purposes.

I can watch them in 3D mode with -only TMT5 over my nVidia 430 and Acer 5360 PJ.

But i can get 1920*1080 3D files as well: (Both TMT 5 and PDVD 10 plays them flawlessly in 3D mode:

LEFT-RIGHT:

LoadPlugin("C:\DG\DGDecodeNV.dll")

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

rv = DGSource("C:\H264StereoSource_a2\right_new.dgi")

LeftRight3DReduced(lv, rv)

ConvertToYV12()

or without DGNV Tools:

lv = FFVideoSource("C:\H264StereoSource_a2\left.m2ts")

rv = FFVideoSource("C:\H264StereoSource_a2\right_new.m2ts")

LeftRight3DReduced(lv, rv)

ConvertToYV12()

or:

lv = directshowsource("C:\H264StereoSource_a2\left.m2ts")

rv = directshowsource("C:\H264StereoSource_a2\right_new.m2ts")

LeftRight3DReduced(lv, rv)

ConvertToYV12()

TOP-BOTTOM:

LoadPlugin("C:\DG\DGDecodeNV.dll")

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

rv = DGSource("C:\H264StereoSource_a2\right_new.dgi")

TopDown3DReduced(lv, rv)

ConvertToYV12()

[nm]

But i can get BD compatible files as well: (Both TMT 5 and PDVD 10 plays them flawlessly in 3D mode

Nice. So they support the SEI signaling or how do you specify which format is used?

[mariner]

So how do you get the frames to right screens? Does that somehow happen automagically for both side-by-side and top-bottom videos when you play them in MPC?

It's actually quite crude and simple: create a 1920x2160 desktop using say ATI's Eyefinity software with two 1920x1080 projectors hooked up. Each projector will display the top or bottom half of the video.

[rica]

Nice. So they support the SEI signaling or how do you specify which format is used?

I encoded them into mkv container and i have to select "left-right" or "top-bottom" on player's 3D Settings window before playing.

[nm]

It's actually quite crude and simple: create a 1920x2160 desktop using say ATI's Eyefinity software with two 1920x1080 projectors hooked up. Each projector will display the top or bottom half of the video.

Yep, that's what I thought. So you'll need to manually switch the desktop layout if you have videos with different frame packing formats.

[mariner]

Yep, that's what I thought. So you'll need to manually switch the desktop layout if you have videos with different frame packing formats.

That's right.

Either way should work. I chose vertical stacking because graphics cards may be able to decode 1920x2160 in DXVA.

[sneaker_ger]

As nm already pointed out: setting frame-packing only sets some kind of flag in the stream and your player does not rely on it. That's why correct playback works anyways.

But i can get BD compatible files as well: (Both TMT 5 and PDVD 10 plays them flawlessly in 3D mode:

So the BD specs allow side-by-side/top-bottom encoded H.264 in addition to MVC? If not, please don't call them BD compatible, because the specs define what's BD, not the abilities of some BD player.

[rica]

So the BD specs allow side-by-side/top-bottom encoded H.264 in addition to MVC? If not, please don't call them BD compatible, because the specs define what's BD, not the abilities of some BD player.

You're right; that was a false explaination, sorry.

Edited, thanks:

But i can get 1920*1080 3D files as well: (Both TMT 5 and PDVD 10 plays them flawlessly in 3D mode:

[mariner]

As nm already pointed out: setting frame-packing only sets some kind of flag in the stream and your player does not rely on it. That's why correct playback works anyways.


Thanks again, sneaker_ger. Your help has been indispensable.

For your amusement, here is a short pseudo 3D using Martin Haverland's conversion script:

Name: 700_v_2D3D.mkv
Size: 125.25MB
Description: 1920x1080/60p 2Dto3D Top/bottom
http://www.sendspace.com/file/hnw7q9

Any feedback on graphics cards DXVA decoding capabilities most appreciated.

[sneaker_ger]

Thanks, but I don't actually own a 3D display yet to enjoy the clip.

@x264 devs
Do you plan to also flag 3D streams on the container level (http://www.matroska.org/technical/specs/index.html#StereoMode) for Matroska? Players that prioritize container information over stream information (which is the correct way to do things IMHO) would regard the current output as 2D material. (I know that it's not that important without audio support and missing indexing.)

[rica]

I am playing with Mainconcept MVC (not cinevision) and usualy get same results as kolak. Right eye definitly need less bitrate, but depends from many factors.

Hi shon3i,

i downloaded MainConcept Referance MVC beta and i always got this popup while i was trying to add the files to output:

http://img256.imageshack.us/img256/8761/95221479.png (http://img256.imageshack.us/i/95221479.png/)

Any ideas?

[shon3i]

Try installing reference 2.1 trial too.

[rica]

Try installing reference 2.1 trial too.

Yes i already did but i have the same pop-up.

(Even i unistalled both of them and reinstalled back- this time i installed reference before reference MVC)

Thank you anyway.

[shon3i]

Well you can contact mainconcept, i have no problems.

[rica]

shon3i,

i don't think they will help since my source left and right files are extracted from a 3D BD: :)

BTW, i think the problem is MC can not recognize the frame number of the right-eye video.

Re-encoded right-video: (at bottom)

[PRG] 0:00:39.421 6927 frames found, 92% complete
[PRG] 0:00:39.531 7020 frames found, 93% complete
[PRG] 0:00:39.624 7106 frames found, 94% complete
[PRG] 0:00:39.733 7205 frames found, 95% complete
[PRG] 0:00:39.827 7275 frames found, 96% complete
[PRG] 0:00:39.936 7342 frames found, 97% complete
[PRG] 0:00:40.045 7402 frames found, 98% complete
[PRG] 0:00:40.139 7467 frames found, 99% complete
[DBG] 0:00:40.248 mpegInOpen: 10.323846 sec, result=0
[DBG] 0:00:40.264 mpegdec: opened in 10.378210 sec.
[INF] 0:00:40.264 Successfully opened file 'C:/H264StereoSource_a2/left.h264' with decoder 'mpegdec'.
[INF] 0:00:40.264 Successfully opened file 'C:/H264StereoSource_a2/left.mmf' with decoder 'mvmetadec'.



[PRG] 0:02:42.397 196 frames found, 89% complete
[PRG] 0:02:42.475 197 frames found, 90% complete
[PRG] 0:02:42.522 198 frames found, 91% complete
[PRG] 0:02:42.662 200 frames found, 93% complete
[PRG] 0:02:42.787 204 frames found, 94% complete
[PRG] 0:02:42.865 206 frames found, 95% complete
[PRG] 0:02:42.974 207 frames found, 97% complete
[PRG] 0:02:43.052 210 frames found, 98% complete
[PRG] 0:02:43.161 211 frames found, 99% complete
[DBG] 0:02:43.255 mpegInOpen: 55.040471 sec, result=0



Un-encoded original right video (at bottom)

[PRG] 0:03:26.498 60518 frames found, 95% complete
[PRG] 0:03:27.497 61353 frames found, 96% complete
[PRG] 0:03:28.433 62034 frames found, 97% complete
[PRG] 0:03:29.322 62670 frames found, 98% complete
[PRG] 0:03:30.227 63321 frames found, 99% complete
[DBG] 0:03:31.225 mpegInOpen: 159.904661 sec, result=0
[DBG] 0:03:31.319 mpegdec: opened in 160.580298 sec.
[INF] 0:03:31.319 Successfully opened file 'C:/00010 - 2 - h264 (left eye), 1080p24.h264' with decoder 'mpegdec'.
[INF] 0:03:31.319 Successfully opened file 'C:/00010 - 2 - mmf (left eye), 1080p24.mmf' with decoder 'mvmetadec'.
[DBG] 0:03:31.319 cropper.setParam: mode [Int32] = 1


[PRG] 0:06:36.742 1401 frames found, 87% complete
[PRG] 0:06:37.615 1410 frames found, 88% complete
[PRG] 0:06:38.270 1420 frames found, 89% complete
[PRG] 0:06:39.191 1443 frames found, 90% complete
[PRG] 0:06:39.846 1457 frames found, 91% complete
[PRG] 0:06:40.517 1474 frames found, 92% complete
[PRG] 0:06:41.250 1488 frames found, 93% complete
[PRG] 0:06:41.983 1503 frames found, 94% complete
[PRG] 0:06:42.638 1512 frames found, 95% complete
[PRG] 0:06:43.434 1540 frames found, 96% complete
[PRG] 0:06:44.136 1581 frames found, 97% complete
[PRG] 0:06:44.978 1600 frames found, 98% complete
[PRG] 0:06:45.478 1708 frames found, 99% complete
[DBG] 0:06:46.195 mpegInOpen: 115.293104 sec, result=0

[Dark Shikari]

My initial testing on 3D content is done.

Free lossless 3D test sequence (http://x264.nl/developers/Dark_Shikari/lossless3d.mkv) (L/R interleaved).

I have some tweaking I plan to do, but the crux of the matter is that MVC is totally pointless, as are all coding schemes besides interleaved mode. DVB's insane attempt to use T/B half-resolution using regular AVC is going to cost billions of dollars in wasted bandwidth.

Using that source, at crf 25, without any changes to x264:

Two separate streams: 3709 and 3700kbps, for 7.4mbps total
One stream, interleaved: 5503kbps (improvement: ~34.5%)
PSNR improvement: ~0.381db (~7.5%)
Overall improvement: 42%

Also, even on superfast x264 is able to capture "motion" perfectly between two views, even if they're widely spaced from each other. No special 3D-aware motion estimation methods are required. I do recommend using at least --ref 2 though, even with superfast, so it can predict from both the previous frame and the previous view.

[rica]

No special 3D-aware motion estimation methods are required.

Sorry in advance if i misundersood:
Do you mean existent 3D Players are able to recognize those re-created frame packed files without MVC?

[Stephen R. Savage]

I have some tweaking I plan to do, but the crux of the matter is that MVC is totally pointless, as are all coding schemes besides interleaved mode. DVB's insane attempt to use T/B half-resolution using regular AVC is going to cost billions of dollars in wasted bandwidth.


I can see how frame interleaving might be practical for 720p, since 30 fps is still a reasonable speed, but I fail to see how broadcasters have much choice in the matter for 1080i unless they use some kind of frame packing, probably row interlacing. Or, do you have some other scheme in mind?


Sorry in advance if i misundersood:
Do you mean existent 3D Players are able to recognize those re-created frame packed files without MVC?


I think he just means that the motion estimation in H.264 is sufficient to compress stereoscopic content. Whether players recognize non-MVC 3D is a whole other matter.

[kieranrk]

I can see how frame interleaving might be practical for 720p, since 30 fps is still a reasonable speed.


ESPN uses 720p120 on it's main feed.

[Dark Shikari]

I can see how frame interleaving might be practical for 720p, since 30 fps is still a reasonable speed, but I fail to see how broadcasters have much choice in the matter for 1080i unless they use some kind of frame packing, probably row interlacing. Or, do you have some other scheme in mind?Er... you just lower the resolution. They're already planning on doing this with top/bottom frame packing: you include two 1920x540 streams. They would be better off doing 1920x540 at 60fps than 1920x540, packed to 1920x1080, at 30fps. The amount of processing power required is identical.

[rica]

I think he just means that the motion estimation in H.264 is sufficient to compress stereoscopic content. Whether players recognize non-MVC 3D is a whole other matter.

Ok then please correct me if i'm wrong:

1) If you don't re-create a 3D BD you won't need MVC encoding.
2) In this case you may use x264 and it will put some flags.
3) Then what MVC is for: just for player to recognize the file structure by itself? Side-by-side or top-bottom?

EDIT: BTW thanks Dark for your valuable contribution.

[Dark Shikari]

Ok then please correct me if i'm wrong:

1) If you don't re-create a 3D BD you won't need MVC encoding.
2) In this case you may use x264 and it will put some flags.
3) Then what MVC is for: just for player to recognize the file structure by itself? Side-by-side or top-bottom?

EDIT: BTW thanks Dark for your valuable contribution.--frame-packing is for the player to recognize the file structure. You don't need MVC for that.

[rica]

--frame-packing is for the player to recognize the file structure. You don't need MVC for that.

Sorry but why do i have to reset everytime the player's 3D settings then?

EDIT: I've missed "--frame-packing" switch.

[rica]

I do wonder whether i can combine "--frame-packing" with Adam's tool or not?

http://forum.doom9.org/showpost.php?p=1465125&postcount=56

[Disabled]

But what does MVC add? This Introduction to Multiview Video Coding (http://mpeg.chiariglione.org/technologies/mpeg-4/mp04-mvc/index.htm) doesn't have many details. That "Temporal/inter-view prediction structure for MVC" looks complex, but might be reproducable with multi-refs and b-pyramid? I also wonder, why Cam1 doesn't have any P-frames...

[rica]

When you look at an MVC you will see a 1920*1080.
But it contains layers 1920*1080 on 1920*1080 layers.
MVC has a main stream > left which contains full resolution video+audio plus right video which only contains depth information AFAIK. This is why right-eye video is shorter than the left and without left video, right-eye video is nothing.
While shooting is made with two camcorders (left and right), while they are storing on the similar spaces in portable discs,
WHY we have different file sizes?

Because MVC encoding technology is based on encoding just non-existent info on left video to right-secondary video (i mean depth info...Only the differences...)

[Dark Shikari]

When you look at an MVC you will see a 1920*1080.
But it contains layers 1920*1080 on 1920*1080.
MVC has a main stream > left which contains full resolution video+audio plus right video which only contains depth information AFAIK. This is why right-eye video is shorter than the left and without left video, right-eye video is nothing.What you're talking about is container-level information about how it's stored, not how it's actually compressed.

MVC, as far as I know, doesn't offer any major improvements over AVC for compression of 3D video.

[rica]

What you're talking about is container-level information about how it's stored, not how it's actually compressed.

MVC, as far as I know, doesn't offer any major improvements over AVC for compression of 3D video.

Compression is AVC basically.
What is different is the compression methodology of the secondary (right) stream. That is the improvement.
Think about you have similar avc videos: left and right.
You have limited options in conventional methods:
Either reduce- stretch the fiiles or make huge packs.
Or put layer over layer with dependent limited size right video-only needed pixels, only needed extra info.

[Dark Shikari]

Compression is AVC basically.
What is different is the compression methodology of the secondary (right) stream. That is the improvement.
Think about you have similar avc videos: left and right.
You have limited options in conventional methods:
Eighter reduce- stretch the fiiles or make huge packs.
Or layer over layer with dependent limited size right video-only needed pixels, only needed extra info.You can do the "separate stream" method with AVC too.

[rica]

You can do the "separate stream" method with AVC too.

Sorry but do you mean seperate stream method with only needed extra information like MVC does on right-eye video?
If "yes", how?

[Dark Shikari]

Sorry but do you mean seperate stream method with only needed extra information like MVC does on right-eye video?
If "yes", how?Make the right view entirely consist of disposable frames. Then you can separate them into another stream or whatever you want; they're not needed to decode the left view.

[rica]

Make the right view entirely consist of disposable frames. Then you can separate them into another stream or whatever you want; they're not needed to decode the left view.

Would you explain how to do it more detailled please?

[Dark Shikari]

Would you explain how to do it more detailled please?If you need an explanation of how NAL priorities work, go read the spec.

[nm]

I do wonder whether i can combine "--frame-packing" with Adam's tool or not?

Sure. Those functions are for joining two views to one video in AviSynth. --frame-packing is for signaling where the views were placed.

[kolak]

What you're talking about is container-level information about how it's stored, not how it's actually compressed.

MVC, as far as I know, doesn't offer any major improvements over AVC for compression of 3D video.

I may be wrong but L and R eyes share the same I frames.


Andrew

[Dark Shikari]

I may be wrong but L and R eyes share the same I frames.


AndrewI would think R shouldn't have I-frames at all; it should just reference the I-frame in L instead.

[kolak]

I would think R shouldn't have I-frames at all; it should just reference the I-frame in L instead.

Yes- during encoding there are only I frames for L eye created and than P,B for each eye independently.


Andrew

[Zerofool]

Please excuse me for repeating myself. I have a question for you Dark Shikari, in case you missed it:
my question is if there is something we should take in consideration when encoding frame-sequential 3D videos (regarding psy optimizations for example, or other x264 options/settings)?
...especially for stereoscopic footage from videogames (like your test source).
Thanks

[Dark Shikari]

Please excuse me for repeating myself. I have a question for you Dark Shikari, in case you missed it:

...especially for stereoscopic footage from videogames (like your test source).
Thanks--frame-packing 5, that's it: when I add optimizations for 3D material, they will simply check the frame packing setting to see what format the input is. I would also make sure to use at least 2 reference frames, even if encoding with a very fast preset.

Here's my first attempt at 3D interleaved optimization. (https://github.com/DarkShikari/x264-devel/commit/60e29caff431451b7bbe5dfa14f870cbff45b185)

[rica]

If you need an explanation of how NAL priorities work, go read the spec.

Jason, would you give me the link please?

[Dark Shikari]

Jason, would you give me the link please?Google is your friend, but here it is... (http://www.itu.int/rec/T-REC-H.264-200903-S/en)

[rica]

Sure. Those functions are for joining two views to one video in AviSynth. --frame-packing is for signaling where the views were placed.

Do you mean "make script with Adam's tool and encode it to x264 with --frame packing switch"?

[rica]

Google is your friend, but here it is... (http://www.itu.int/rec/T-REC-H.264-200903-S/en)

Thanks, not always btw :)

[nm]

Do you mean "make script with Adam's tool and encode it to x264 with --frame packing switch"?

Yes. To make use of the setting during playback, you'll also need a decoder and a player that supports frame packing SEI messages.

[rica]

Then please confirm or not:

Here is the workflow for the time being: (without an MVC encoder)


1) Demuxing entire movie with eac3to:

eac3to D:\bdmv\playlist\00005.mpls -demux


2) Re-encoding right video using H264StereoSource.
Create an avisynth script like: (say xx.avs)

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


-"xxxxx" is frame number of entire movie here.
-frame number info is taken from eac3to log.

And re-encode it to x264 using CML:

x264 --blabla -o right_new.264 xx.avs


3) Write a script using Adam's tool, like: (say yy.avs)

LoadPlugin("C:\DG\DGDecodeNV.dll")

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

rv = DGSource("C:\xx\right_new.dgi")

LeftRight3DReduced(lv, rv)

ConvertToYV12()

(more samples may be found here:

http://forum.doom9.org/showpost.php?p=1465125&postcount=56 )


4) Encode it to frame packing x264:

x264 --blabla --frame packing -o final.264 yy.avs