Any free MVC encoder yet?

[rica]

And one of the new presets of MeGui might be "3D frame -packed" ?

[Zerofool]

--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. OK, thanks. That's not a problem for me because I tend to use custom settings, close to the placebo preset :) (6-8 refs, ME range of 32 when I use high stereo separation).

Here's my first attempt at 3D interleaved optimization. (https://github.com/DarkShikari/x264-devel/commit/60e29caff431451b7bbe5dfa14f870cbff45b185)
That's fantastic, I can't wait to test it when it appears in the main branch.

I have another question regarding "--frame-packing" - is this SEI message/flag part of some standard? Because if it's not, and fi it's not too late, you should definitely add an option to state which frame/line/half of the video is the left, and which one is the right view (that doesn't matter compression-wise, but it's important during playback). Take a look at stereoscopic player for example - each and every stereo format has two variations - one that starts with the left view, and one that starts with the right one. I hate the way TV manufacturers have implemented support for very few stereo formats, it's a shame, it would basically force people to use these limited formats.
Looking at the --longhelp description, people would think that for modes 3 and 4, L on left & L on top are the only correct ways to set the views, and this is wrong, it could be the other way around. For crosseyed viewing for example, a side-by-side video is used, but with the right view first (on the left side), and the left view after it (on the right side), and that's the mode I used up until recently. The same thing goes for line/row-interleaved 3D video.
I guess there are two ways to achiev this - the first is to effectively double the values for --frame-packing by adding the variants with the other view first, and the second way is to just add a new optional argument, let's say "--firstview" which would have values of 0 for left and 1 for right, indicating which view is the first frame/row/line/half of the video). This has to be done, otherwise users will have to override that setting during playback (swap L/R) for non-standard videos, or it will force people to encode only in these six modes, which is step backwards in my opinion, It's always good to have the freedom of choice. Well, most people will stick to frame-sequential anyway, and setting views before encoding is easy in this case, but probably there would be situations in which that won't be possible (like checkerboard footage for example, or if you need that crosseyed side-by-side mode) and this feature would help.


@rica: in the second step, I would use fast lossless compression for the right view (I have no idea what CML is, if that's the lossless mode of x264, than please excuse me :)), and then use that in the third step:
rv = AVISource("C:\xx\right_lossless.avi")
I wouldn't use "LeftRight3DReduced", because it obviously produced "side-by-side (half)" video, which has half the horizontal resolution (unless that's exactly what you're after, for example for compatibility with the internal player of a 3DTV), use this instead (for full rez, let's say 3840x1080 video):
StackHorizontal(lv, rv)
In the fourth step, the correct syntax would be "--frame-packing 3" ;) (no matter whether you chose full- or half-resolution).

OR, if you decide to use the frame-sequential stereo format, the third step would look something like this:
LoadPlugin("C:\DG\DGDecodeNV.dll")

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

rv = AVISource("C:\xx\right_lossless.avi")

Interleave(lv, rv)

ConvertToYV12()
And for the final encode (step 4) use "--frame-packing 5". The resulting video will have double the framerate, that's normal, don't worry, it'll play properly (on the PC :)).

[rica]

OK, i made a typo: take it as "CLI" -Command Line Interface.
Forget "CML" :cool:
The rest?
Tomorrow.
Thanks for the contribution.

[Dark Shikari]

I have another question regarding "--frame-packing" - is this SEI message/flag part of some standard? Because if it's not, and fi it's not too late, you should definitely add an option to state which frame/line/half of the video is the left, and which one is the right view (that doesn't matter compression-wise, but it's important during playback). It's in the H.264 spec, and it has this as an option; we just didn't expose it because I don't see a reason to. Nobody should be swapping the views and we don't want to encourage this.

[rica]

And @Zerofool ,

i think you have no idea on the second step.

And more you have no idea or knowledge on Adam's tool...

[kieranrk]

I have another question regarding "--frame-packing" - is this SEI message/flag part of some standard? Because if it's not, and fi it's not too late, you should definitely add an option to state which frame/line/half of the video is the left, and which one is the right view (that doesn't matter compression-wise, but it's important during playback).

Right view first isn't intended to be used anyway. It's only present for completeness.

[BlackSharkfr]

Hello, I wished I found this thread sooner, that subject interests me very much.
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?
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.
Hello, it seems you are speaking about the kind of dual-projector 3D setup I use (http://www.mtbs3d.com/phpBB/viewtopic.php?f=122&t=11320).

I could use the simple multi-monitor desktop extension that all versions of MS Windows provide. Some stereo-3D enabled video players like "Stereoscopic Player" even provide a dedicated mode to manage automatically dual-projector setups in this kind of configuration. But there are some synchronisation and heavy tearing issues on the projector considered as secondary display, I don't know why, I think it's a GPU driver bug.

In order to circumvent these bugs, as nm guessed, I use ATi Eyefinity with the two projector outputs spanning side by side as one single 3840x1080 virtual display.
Eyefinity locks the two outputs in perfect sync so I get absolutely perfect images but has it's own sets of problems (difficulties to use the desktop as the cursor in on one screen but appears on both, interference of windows and desktop background between the two projectors, switching between different eyefinity configurations and 24Hz output mode not supported at the moment).

The easiest content to play on this dual projector system is side by side stacked video, just fullscreen the video, stretch to full-screen if necessary and voilà ! I get stereo 3D movies working straight from any non-3D-ready video player such as MPC-HC.

When I have videos encoded over/under, switching the desktop to vertical Eyefinity is not a viable option. First it takes a lot of time to switch Eyefinity from horizontal to vertical (you can't use driver presets, you have to do the entire Eyefinity configuration as the driver only remembers one Eyefinity configuration).
Moreover, when you have a 2.35:1 scope ratio movie displayed on 16:9 stacked desktops, the over/under stacking does not match : the frames are not centered vertically, you've got one eye view stuck at the top of the screen and the other stuck at the bottom of the screen, the content would have to be letterboxed to work, which is... bad... evil, don't letterbox your movies, ever !

Instead you have multiple options : either use Stereoscopic player which can read vertically stacked files and display them stacked horizontally.
Or if you want to use your favourite MPC-HC (which I do), you can use FFDShow's Avisynth postprocess filter to isolate the views and re-stack them on playback. It works great with very little CPU usage.
Here is the FFDshow Avisynth postprocess script I use

//Tick the "FFDShow source" checkbox

Source=ffdshow
Size=Height()/2
Left=Crop(Source,0,0,0,-Size)
Right=Crop(Source,0,Size,0,0)
StackHorizontal(Left,Right)

The great thing about the FFDshow Avisynth postprocess filter is that it can be enabled and disabled instantaneously at all times, even when the movie is playing, it doesn't restart the video.
I also keep presets for swapping the left and right eye views in case the video is encoded side by side but with the wrong order.


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.
Thanks you Dark Shikari for all the work you do, it will definitely help make things better for 3D users.

I do not have really deep understanding of MVC, just the generic information given to the general public, I grabbed a copy of the spec but that's too complicated for me, I have to admit it.
From what I understood, MVC does almost the same thing as you do when you encode interleaved L/R stereo3D video, which explains the file size gains you encounter are similar to the ones claimed by MVC.

With appropriate decoding codecs and updated video players, you could reach similar results to MVC. From my user point of view, if you manage to get everyone to use and support the x264 interleaved system, what we'll end up with is a new 3D format that has the same picture than MVC but isn't readable by BluRay players.

[Zerofool]

It's in the H.264 spec, and it has this as an option; we just didn't expose it because I don't see a reason to. Nobody should be swapping the views and we don't want to encourage this.
OK, thanks for clearing that up. Please excuse my lack of knowledge, and ignore my post.

And @Zerofool ,

i think you have no idea on the second step.

And more you have no idea or knowledge on Adam's tool...
I have a pretty good idea on what the second step is. I haven't done it, but I have an idea how it's done ;). Instead of encoding the right view to lossy format, then combine it with the left one through AviSynth and encode again in lossy format, you can have just one lossy compression - the final one. Actually in theory both the second and third steps could be done at once, saving time (arguably) and space, and that's what I plan to test tomorrow (because just talking isn't doing any good to anybody).

Nope, I've never used that tool either, I found out about it form your post on the first page. It doesn't do anything different from what I do manually for the past 1.5-2 years - crop, resize, stack - bam, it's done (well, except anaglyph, it's more complicated there, especially the optimized modes). Now I see BlackSharkfr's post, and what he describes is pretty much what I'm talking about.
What is there to know about it - the name itself talks alone "LeftRight3DReduced" - with 1080p 3D source, you will get 960x1080 per eye, in side-by-side configuration, which is called "Side-by-side (half)". And during playback it's being scaled to 1920x1080 per eye.
Excuse me for trying to help.

Right view first isn't intended to be used anyway. It's only present for completeness.
I don't know who is to say what is to be used, and what not, but it appears that these people (that created the standard) haven't been using 3D until just recently. Long before BluRay 3D was even just a thought in someone's head, and long before YouTube 3D, the majority of "home-made" 3D videos around internet were either anaglyph or side-by-side, R image first, because that's cross-eye-viewing-ready, no glasses needed, no special monitor required, no crosstalk (ghosting), it's just great for short clips or images. Unfortunately, that trend is going to die obviously. I'll live with that, but it's just sad.

[nm]

I have a pretty good idea on what the second step is. I haven't done it, but I have an idea how it's done ;). Instead of encoding the right view to lossy format, then combine it with the left one through AviSynth and encode again in lossy format, you can have just one lossy compression - the final one. Actually in theory both the second and third steps could be done at once, saving time (arguably) and space, and that's what I plan to test tomorrow (because just talking isn't doing any good to anybody).

Agreed. There should be no need to encode the right view separately first and then load it back.

What is there to know about it - the name itself talks alone "LeftRight3DReduced" - with 1080p 3D source, you will get 960x1080 per eye, in side-by-side configuration, which is called "Side-by-side (half)". And during playback it's being scaled to 1920x1080 per eye.

Sounds right to me too.

[BlackSharkfr]

Agreed. There should be no need to encode the right view separately first and then load it back.

When I ripped my copy of AVATAR to play it on the dual projector setup, I tried to do it in a single step.
It worked but it was difficult,
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.

It worked but half-way into the encoding a bug happened and one of the views got a 1-frame delay in one eye which ruins half of the movie.
These encodes take so long (30+ hours), after an entire week of countless failing, I didn't want it to happen again anymore, so I used the temporary right eye file technique which I knew from my previous BluRay3D rips worked fine.

[invincible]

How to open right.h264 (demux from 3D BD) with avisynth ? I used h264stereosource but it's not a good program?

[nm]

How to open right.h264 (demux from 3D BD) with avisynth ?

Is it an MVC stream that contains both views? Then h264stereosource is pretty much the only free option to get the second view.

[invincible]

It's for right eye. I used h264stereosource to encode but it alway misses frames at the end.

[nm]

It's for right eye. I used h264stereosource to encode but it alway misses frames at the end.

If the stream only contains one view as plain AVC (not MVC), then you could use any normal source filter, like FFMS2.

[rica]

I have a pretty good idea on what the second step is. I haven't done it, but I have an idea how it's done ;). Instead of encoding the right view to lossy format, then combine it with the left one through AviSynth and encode again in lossy format, you can have just one lossy compression - the final one. Actually in theory both the second and third steps could be done at once, saving time (arguably) and space, and that's what I plan to test tomorrow (because just talking isn't doing any good to anybody).

Nope, I've never used that tool either, I found out about it form your post on the first page. It doesn't do anything different from what I do manually for the past 1.5-2 years - crop, resize, stack - bam, it's done (well, except anaglyph, it's more complicated there, especially the optimized modes). Now I see BlackSharkfr's post, and what he describes is pretty much what I'm talking about.
What is there to know about it - the name itself talks alone "LeftRight3DReduced" - with 1080p 3D source, you will get 960x1080 per eye, in side-by-side configuration, which is called "Side-by-side (half)". And during playback it's being scaled to 1920x1080 per eye.


I wish i would pass the second step but i couldn't achieve without H264StereoSource. I hate encoding twice too. I hate more encoding squeezed videos.
You may re-encode to (1920*1080)*2 to either "top-down" or "side by side" as well but you can not watch them with any player except TMT5. (in SW mode.)
The only way to play multilayer 1920*1080s without a need of lossy re-encoding (even once) is to encode with an MVC encoder.
And all existent commercial players will play it in DXVA.

This is why i opened this thread.

[rica]

It's for right eye. I used h264stereosource to encode but it alway misses frames at the end.

This is not important. I lost only 60 frames at the end. (aprox. 2-3 seconds for the entire movie.)

[nm]

I wish i would pass the second step but i couldn't achieve without H264StereoSource.

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.

[rica]

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.

Doesn't work.
Even it worked i had to encode squeezed videos.
What we need is a free MVC encoder not a modified x264 which is just putting some flags.

This is why i told: Here is the workflow for the time being: (without an MVC encoder)
on my previous post.

[Dark Shikari]

Doesn't work.
Even it worked i had to encode to squeezed videos.
What we need is a free MVC encoder not a modified x264...Why are you complaining about x264 when you can't even get your input script working correctly? No MVC encoder will magically fix the fact that you're incompetent.

[rica]

Why are you complaining about x264 when you can't even get your input script working correctly? No MVC encoder will magically fix the fact that you're incompetent.

I agreed i'm incompetent.
If i were not incompetent i would write codes while open source stuff is over there:

http://research.nokia.com/page/4988

http://wftp3.itu.int/av-arch/jvt-site/2009_01_Geneva/JVT-AD207.zip

What i say is very clear: AVC is not sufficient or far from meeting my expectations for those 3D stuff: believe or not. If you are happy, it's your problem.

[Dark Shikari]

What i say is very clear: AVC is not enough for those 3D stuff: believe or not.... says someone who admits they're incompetent? :rolleyes:

[rica]

... says someone who admits they're incompetent? :rolleyes:

I can't see --says someone switch on --fullhelp? :)

[rica]

And this switch will never change the truth of x264 is unable to frame-packing of 3D truly.

[Zerofool]

Agreed. There should be no need to encode the right view separately first and then load it back.

Sounds right to me too.
nm, thanks for stepping in, man.

I wish i would pass the second step but i couldn't achieve without H264StereoSource. I hate encoding twice too.
My first suggestion was not to skip it, but just to use lossless codec for the right view instead of the lossy x264. I tested it today with huffyuv and lagarith, and it works fine most of the time (I had to disable input and output view panes in virtualdub to avoid crash at start), but sometimes a frame is dropped and obviously the sync is lost, similar to BlackSharkfr's observation here (http://forum.doom9.org/showthread.php?p=1466062#post1466062).

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 :) (although with slight loss in quality because of the YV12->RGB->YV12 conversion, I think there should be a setting for the color format of the frame server, but I haven't found such yet).
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.

You may re-encode to (1920*1080)*2 to either "top-down" or "side by side" as well but you can not watch them with any player except TMT5. (in SW mode.)
You obviously haven't ever heard of Stereoscopic Player (http://3dtv.at/Products/Player/Features_en.aspx), currently the most feature-rich and mature (imo) 3D-video player and it's one of the first such players. Well, it lacks BluRay 3D playback capabilities yet, but it probably will support it at some point (I guess when a decent directshow decoder is released).

The only way to play multilayer 1920*1080s without a need of lossy re-encoding (even once) is to encode with an MVC encoder.
And all existent commercial players will play it in DXVA.

This is why i opened this thread. To encode files in MVC, you first have to decode the source, isn't that right? And in this case the only decoder on our disposal is that buggy H264StereoSource, which is the root of all problems (sorry if I sound ungrateful to its author, I'm not :)).

Doesn't work.
I does work. You have to make sure both views have the same framerate and color format.
Even it worked i had to encode squeezed videos.
What we need is a free MVC encoder not a modified x264 which is just putting some flags.
So what? You can use that tool of yours to squeezed both views again, the same way you would with your old approach.
MVC encoder would only be useful for stand-alone hardware BluRay decoders and probably other such hardware devices, for PC it ain't crucial, x264 with the proper optimizations (which are under way thanks to Dark Shikari) is the way to go. It works pretty well as it is, and it will get even better in the future.

[mariner]

...
OR, if you decide to use the frame-sequential stereo format, the third step would look something like this:
LoadPlugin("C:\DG\DGDecodeNV.dll")

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

rv = AVISource("C:\xx\right_lossless.avi")

Interleave(lv, rv)

ConvertToYV12()
And for the final encode (step 4) use "--frame-packing 5". The resulting video will have double the framerate, that's normal, don't worry, it'll play properly (on the PC :)).

Greetings Zerofool.

When I used ffvideosource to interleave 1920x1080/59.94p stream without specifying the frame rate, the result was reported as 119.596 fps. Is this a known issue?

Many thanks and best regards.

[JEEB]

Greetings Zerofool.

When I used ffvideosource to interleave 1920x1080/59.94p stream without specifying the frame rate, the result was reported as 119.596 fps. Is this a known issue?

Many thanks and best regards.

Interleave modifies the frame rate in the usual sense. When you double the amount of frames, you usually want to double the frame rate as well; or else the video's length will go 50% and a/v synch goes wee.

Use AssumeFPS("ntsc_double" ) to get 60000/1001 frame rate. Although I'm not sure if you really want it.

[Zerofool]

Greetings Zerofool.

When I used ffvideosource to interleave 1920x1080/59.94p stream without specifying the frame rate, the result was reported as 119.596 fps. Is this a known issue?

Many thanks and best regards.
Hello mariner,
I wouldn't call it an issue, it's more of a side effect. JEEB is absolutely correct (with a small mistake - video's length will go 200% (not 50%) if you retain the original, lower framerate). You don't need to worry about it, when you set the input 3D format in your player, it will play as it should (59,94 fps per eye).
You are welcome :).

Happy holidays everyone!

[Episodio1]

"with a small mistake - video's length will go 200% (not 50%) "

I guess he meant "runtime", not file size.

[JEEB]

(with a small mistake - video's length will go 200% (not 50%) if you retain the original, lower framerate).

Ugh, yes, my bad. You get 200% length if you don't double the frame rate.

I must say though, that I have no idea which frame rate should be used with 3D video to be honest. Does it just show two frames at a time, keeping the frame rate (in which case 60/1.001 is correct) -- or does it show two and half the frame rate (since two go into one -- which would make 120/1.001 correct in this case, and would end up 60/1.001 dual for the viewer)?

[Zerofool]

"with a small mistake - video's length will go 200% (not 50%) "

I guess he meant "runtime", not file size.

Yes my friend, we're talking about length, as in seconds. Let me explain myself with a short example:

Let's say we have a 60fps clip (the left view for example), 200 seconds long, thats 12000 frames. Now add 12000 frames more for the right view, that makes 24000 frames for the interleaved (frame-sequential) clip. If you play them at the original speed (of one of the views) - 60fps, it would take 24000/60=400 seconds, twice as much time (200%). So, to play the new clip, and still match the original length (in seconds) as in each of the individual views, you need double the speed, to play the double number of frames (simple physics - speed=distance/time, you make the time constant, and therefore, if you double the distance (frames), you should double the speed (framerate) for the equation to make sense).
I hope it's clear now for everybody who had any doubts.

[rica]

You obviously haven't ever heard of Stereoscopic Player (http://3dtv.at/Products/Player/Features_en.aspx), currently the most feature-rich and mature (imo) 3D-video player ...


I must have heard Peter's perfect tool. :)

To encode files in MVC, you first have to decode the source, isn't that right? And in this case the only decoder on our disposal is that buggy H264StereoSource, which is the root of all problems (sorry if I sound ungrateful to its author, I'm not :)).


JMVC and MainConcept MVC Encoders have their own MVC decoders.

So what? You can use that tool of yours to squeezed both views again, the same way you would with your old approach.

You didn't notice i never said "i loved" either of those methods,
I just said "for the time being", until any free MVC Encoder released.


MVC encoder would only be useful for stand-alone hardware BluRay decoders and probably other such hardware devices, for PC it ain't crucial, x264 with the proper optimizations

Please read some documents on MVC.

[Zerofool]

I must say though, that I have no idea which frame rate should be used with 3D video to be honest. Does it just show two frames at a time, keeping the frame rate (in which case 60/1.001 is correct) -- or does it show two and half the frame rate (since two go into one -- which would make 120/1.001 correct in this case, and would end up 60/1.001 dual for the viewer)?
That really depends on what technology your 3D display is based on.
If it's based on frame-sequential/"page-flipping" approach (stuff with "active" shutter glasses - 3DTVs, 120Hz projectors, good old CRTs, etc., that work in 120Hz mode) these frames are displayed (logically :)) one after another. It's easy for 60fps per eye (120fps frame-sequential file), it retains the same 120fps speed, but what happens with 24fps per eye video (24/1.001 to be precise) for example? The player uses two buffers, one for each eye (basically one for the even, and one for the odd frames), and they are displayed sequentially, and each view (buffer) is played the way a normal 24fps video would be played on 60Hz display (with some frame duplication and so on). I think that doesn't sound very clear, but that's the best explanation I can give :). It's interesting thing to note that if you use the HDMI 1.4a stereoscopic modes, in theory you would get some lag, because you first need to decode the first two frames, combine them in the "frame-packing"-formatted frame, which in terms of HDMI means top/bottom configuration (obviously with the normal framerate), with some empty ("active blanking") space between each view (30 pixels for 720p, 45px for 1080p if I'm not mistaken), then the 3DTV has to show the top image first, and then the bottom one (again with the double framerate, and in the same time working in 120Hz (the native refreshrate of the display)).

If the display is based on technology that displays both views at the same time (like dual projectors, stereo mirror-based, "passive" polarized 3DTVs (interlaced), or active polarized displays (like the iZ3D monitor), autostereoscopic displays, anaglyph, etc.) then both frames are displayed simultaneously (imagine it as one image) at the normal speed (60/1.001 fps in your example). Basically, the player takes care for all of this.
Once you know the speed of the video in "fps per eye" and the way the 3D display in question works, you can answer your question easily.



I must have heard Peter's perfect tool. :)
How could have I guessed? You said there were no players to support 3840x1080 or 1920x2160 videos (except TMT)...

JVMC and MainConcept MVC Encoders have their own MVC decoders.
I don't know what "JVMC" is, google was not of much help either. If you refer to the reference JM decoder, well as far as I know H264StereoSource is based on it.
Then what stops you from using Mainconcept's MVC decoder right now? :) Whatever it is, it won't change even when a free MVC Encoder is released.

You didn't notice i never said "i loved" either of those methods,
I just said "for the time being", until any free MVC Encoder released.
As we said many times already - you can create full-rez per eye encodes right now, with good compression ratios, and we're still in the "until any free MVC Encoder released" timeframe. What do you expect to change?

Please read some documents on MVC.That wouldn't help, I have really basic programming and video-compression knowledge, that would be like reading in Japanese (meaning that I won't understand anything and I would only look at the pictures :p).
On the other hand, I know the practical aspect of it. The way it's implemented in BluRay is to have two files, only for backwards-compatibility reason. If you have an old BD-player, you'll still be able to watch the 2D version (only the file for the left view), that's all. I guess MVC could be useful for more-multiview videos, like in autostereoscopic displays, where sometimes 7 or 9 views are needed, but probably the same efficiency could be achieved through x264 with some optimizations (not necessarily specs-compliant).

[invincible]

DVDFab Can decode MVC using SSIF source. I don't know how they can. They also use x264 to encode but It's close source and we can't customise.

[Zerofool]

DVDFab Can decode MVC using SSIF source. I don't know how they can. They also use x264 to encode but It's close source and we can't customise.

The same thing can be said about 3DBDBuster and other such paid tools, but exactly the lack of customizations and not knowing what is going on under the hood is the turn-off thing for me. I'd really love to see a decent MVC decoder for avisynth (or a directshow filter :)), we'll live and see ;).

[rica]

zerofool,

I explained why i need MVC encoder, check out these posts again:


http://forum.doom9.org/showpost.php?p=1465744&postcount=81

http://forum.doom9.org/showpost.php?p=1465748&postcount=83


As for JMVC, just have a look at post three by kurt in this thread. (second link.)

http://forum.doom9.org/showpost.php?p=1463721&postcount=3


BTW i will test Stereoscopic Player again with huge files to confirm.

But even it works with any kind of (1920*1080)*2, it won't use DXVA.

Best wishes.

[Zerofool]

zerofool,

I explained why i need MVC encoder, check out these posts again:


http://forum.doom9.org/showpost.php?p=1465744&postcount=81

http://forum.doom9.org/showpost.php?p=1465748&postcount=83

As for JMVC just have a look at post three of kurt in this thread. (second link.)
OK, as I said, I can't comment on the internals. But if your only concern is the filesize, then it shouldn't matter if you use MVC encoder, or AVC one, as long as the results are similar (in terms of final image quality and filesize), that's what I've being trying to say all along.

I will test again Stereoscopic Player with huge files to confirm.

But even it works with any kind of (1920*1080)*2 it won't use DXVA.

Best wishes.
Seeing is believing :).
Unfortunately that's correct, you can't use DXVA with steroscopic player (no matter of the resolution), it's because of the nature of the transform filter and renderer used by the player and DXVA's requirements. But you can use CUDA-acceleration if you have nvidia card and such decoder ;).

Thanks, to you too.

P.S.: I forgot the fact that you're using DGDecodeNV, so you obviously have an nvidia card :).

[mariner]

Interleave modifies the frame rate in the usual sense. When you double the amount of frames, you usually want to double the frame rate as well; or else the video's length will go 50% and a/v synch goes wee.

Use AssumeFPS("ntsc_double" ) to get 60000/1001 frame rate. Although I'm not sure if you really want it.

Hello mariner,
I wouldn't call it an issue, it's more of a side effect. JEEB is absolutely correct (with a small mistake - video's length will go 200% (not 50%) if you retain the original, lower framerate). You don't need to worry about it, when you set the input 3D format in your player, it will play as it should (59,94 fps per eye).
You are welcome :).

Happy holidays everyone!

Greetings JEEB and Zerofaol. Thanks for the reply and happy holidays.

I was expecting interleave to double the frame rate to 119.88 fps rather than something like 119.596.

Does it mean it is always necessary to specify the frame rate explicitly in the script?

[Zerofool]

Greetings JEEB and Zerofaol. Thanks for the reply and happy holidays.

I was expecting interleave to double the frame rate to 119.88 fps rather than something like 119.596.

Does it mean it is always necessary to specify the frame rate explicitly in the script?

Ooops, I didn't really look into the number closely, sorry. That's definitely strange. When you use Interleave() it should produce output with exactly double the framerate, so something's wrong here. I have no idea what, though. I guess you should force it to 120/1.001 when it's not, just to be sure you maintain a/v sync :).

[JEEB]

Once you know the speed of the video in "fps per eye" and the way the 3D display in question works, you can answer your question easily.
The guy got 120/1.001fps and asked if it was right (and on a second look he didn't exactly get 120/1.001 it seems, which is why he asked -- not because he wanted 60/1.001 or something). I didn't introduce any extra questions on the method of how it's shown. Just if in his case of two-frames-per-one-view (that x264 supports) the needed frame rate was 120/1.001 or 60/1.001. As I thought originally, 120/1.001 is what he needed.

You took my question and threw it way out on the deserts of Savanna, if you know what I mean :) .

Greetings JEEB and Zerofaol. Thanks for the reply and happy holidays.

I was expecting interleave to double the frame rate to 119.88 fps rather than something like 119.596.

Does it mean it is always necessary to specify the frame rate explicitly in the script?

Ok, this either sounds like a bug in Avisynth, or like a problem with your way of inputting stuff into Avisynth :)

I see you used ffvideosource. What did you make it read, and does the frame rate of both clips match 60000/1001 frames per second exactly?

If not, try it with two one-or-two-frame-long AVIs or maybe even two frames' worth of exactly "ntsc_double"'d blankclip interleaved. If these tests succeed, and ffmpegsource fails, it could be a problem in ffmpegsource. MPEG-TS can be problematic for ffmpegsource over all, for example (esp. in older revisions, but still nowadays), and wrong frame rate can be gotten from it at least on mingw and *nix where Haali's splitter is not usable (with MPEG-TS).

If all tests fail, even on just blankclip() and interleave(), that'd point at a problem in avisynth itself (although I'd bet on ffmpegsource being the culprit here).

[mariner]

The goal is to create a 1920x1080/119.88p frame-sequential pseudo-3D video using Martin Haverland's simple 2D to 3D conversion script found here (http://forum.doom9.org/showthread.php?p=1421042). The source is 1920x1080/59.94p .mts (http://hdcam.web-pda.info/21639208%20-%20ken%20ross%2003.mts) stream.

There is also the more complicated script by Branko Jermanis (http://free-ri.htnet.hr/Branko/10.html). Appreciate if anyone familiar with it could lend a helping hand.

BTW, AssumeFPS("ntsc_double" ) outputs 59.94 fps with the bit-rate halved.

2Dto3D_interleave.avs:
## Open the video file for conversion, change the video file name
video=FFVideoSource ("D:\3D\left.mts")
audio=FFAudioSource("D:\3D\left.mts")
video2d = AudioDub(video,audio)

## Increase video brightnes on dark videos, good for 3D Vision owners
# video2d = video2d.Tweak(Bright=10)

## Convert to RGB32 to avoid the width restrictions
video2d = ConvertToRGB32(video2d)

## Optional aspect ratio maintaining quality resize for 3d monitor target resolution.
## Very cpu intensive, may be for offline use only, e.g. in virtualdubmod.
## 2x 3.0ghz cpu may give you a framerate of 16fps while running the whole script in virtualdubmod including xvid compression in HDTV quality saving setting.
## Offers great quality in the result video for fullscreen playback in every .avs capable player later.
## Also reduces ghosting if the original file resolution is smaller than the target resolution.
# videoW = width(video2d)
# videoH = height(video2d)
## For 19" Zalman use 1280, for 22" Zalman Trimon it is 1680 etc.
# hzTargetSize = 1280
# video2d = Lanczos4Resize(video2d, hzTargetsize, hzTargetsize * videoH / videoW)
## Commenting out the above resizing maintains realtime capability!

## Get video width/height and set the frame stretch factor
## Lower the value 100 to increase frame stretch, may introduce ghosting
videoW = width(video2d)
videoH = height(video2d)
ResW = videoW + (videoW / 100)
CropW = (ResW - videoW) / 2

## Create variables for left and right frame with one frame difference
## This is the Plufrich-like simulation that creates illusion of depth from movement
f1 = video2d
f2 = DeleteFrame(video2d, 0)

## Stretch the right frame to further the depth effect
f1 = LanczosResize(f1, ResW, videoH)
f1 = Crop(f1, 0, 0, videoW, videoH)

## Stretch the left frame to further the depth effect
f2 = LanczosResize(f2, ResW, videoH)
f2 = Crop(f2, CropW, 0, videoW, videoH)

## Output the two video frames in a side-by-side / parallel format
## Use this as a default for playing back on 3D Vision (Side by Side L/R)
#StackHorizontal(f2, f1)

## Output the two video frames in a Above/Below format (like Sony?)
# StackVertical(f2,f1)

VideoInterleave = Interleave(f1,f2)
ConvertToYV12(VideoInterleave)
AssumeFPS(120000, 1001)
#AssumeFPS("ntsc_double" )

x264.exe:
x264 --frame-packing 5 --crf 17 --tune film -o 700_2D3D_interleave.mkv 2Dto3D_interleave.avs

General
Complete name : D:\3D\700_2D3D_interleave.mkv
Format : Matroska
File size : 105 MiB
Duration : 13s 972ms
Overall bit rate : 63.1 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 972ms
Bit rate : 61.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 119.880 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.249
Stream size : 103 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


Name: 700_2D3D_interleave.mkv
Size: 105.14MB
Description: 1920x1080/60p 2D to 3D Interleave
http://www.sendspace.com/file/pxhas6

Here are some raw Panasonic HS700 .mts samples for you to play with:
http://hdcam.web-pda.info/San%20Fran%20trolley.MTS
http://hdcam.web-pda.info/21639208%20-%20ken%20ross%2003.mts
http://www.megaupload.com/?d=3EBAWEWN

@rica: it would be interesting to see if your MVCV encoder would output a "non-compliant" 1920x1080/60p BD3D.

[nm]

OK, as I said, I can't comment on the internals. But if your only concern is the filesize, then it shouldn't matter if you use MVC encoder, or AVC one, as long as the results are similar (in terms of final image quality and filesize), that's what I've being trying to say all along.

Yep, and according to Dark Shikari's tests, the results are similar. So x264 should work fine regarding compression efficiency, but for BD 3D specs compatibility, one might need an MVC encoder.

[Zerofool]

I didn't introduce any extra questions on the method of how it's shown.
...
You took my question and threw it way out on the deserts of Savanna, if you know what I mean :) .
Does it just show two frames at a time...
I obviously misinterpreted your question, and understood it differently, please excuse me for that, my bad.

Just if in his case of two-frames-per-one-view (that x264 supports) the needed frame rate was 120/1.001 or 60/1.001. As I thought originally, 120/1.001 is what he needed.
I don't understand what you mean by "two-frames-per-one-view". Could you please explain in detail?


Yep, and according to Dark Shikari's tests, the results are similar. So x264 should work fine regarding compression efficiency, but for BD 3D specs compatibility, one might need an MVC encoder.
Exactly my point, that's what I was saying to rica.

[rica]

Yep, and according to Dark Shikari's tests, the results are similar. So x264 should work fine regarding compression efficiency, but for BD 3D specs compatibility, one might need an MVC encoder.

That is not why i need MVC encoder really; not only for the 3D BD specs compatibility.

MVC:

as encoder:

It is an AVC encoder, sure.
What is different here: MVC encoder, while encoding the dependent right video, removes the similar information which is existent on the left video and only encodes different information. So you will get a right video dependent on left video which its file size is smaller than the left video.

For instance you will get 9 GB left + 6 GB right videos instead of 9 GB left and 9 GB right when you use MVC encoder.

(btw @dark says it's possible even with AVC but i don't know how?

http://forum.doom9.org/showpost.php?p=1465749&postcount=84 )

as muxer:

It will put 1920*1080 layers on top of the 1920*1080 layers and you will see the file as 1920*1080 and all DXVA stuff will work with MKV.

[Episodio1]

MVC encoder, while encoding the dependent right video, removes the similar information which is existent on the left video and only encodes different information.

Hmm... would it be possible to do same with another codec? I mean.. to make MVC step independent in the encoding-chain.

[nm]

What is different here: MVC encoder, while encoding the dependent right video, removes the similar information which is existent on the left video and only encodes different information. So you will get a right video dependent on left video which its file size is smaller than the left video.

For instance you will get 9 GB left + 6 GB right videos instead of 9 GB left and 9 GB right when you use MVC encoder.

No, you'll get 9 GB left + 6 GB right with plain AVC too, according to Dark Shikari's tests. AVC provides tools that are powerful enough to encode stereo video efficiently.

(btw @dark says it's possible even with AVC but i don't know how?

http://forum.doom9.org/showpost.php?p=1465749&postcount=84 )

That's for making a video where a "non-stereo" decoder could skip decoding the right view, as with MVC. This has nothing to do with compression efficiency.

[rica]

No, you'll get 9 GB left + 6 GB right with plain AVC too, according to Dark Shikari's tests. AVC provides tools that are powerful enough to encode stereo video efficiently.

The question was "HOW?"
Sorry but i don't understand?

[Zerofool]

you'll get 9 GB left + 6 GB right with plain AVC too, according to Dark Shikari's tests.
That statement could be misunderstood, so here's a refined version of it :):
You'll get a single 15GB file that combines both views.
The question was "HOW?"
By using frame-sequential stereo-format/frame-packing.

[BigPines]

--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)
This is extremely exciting as I am planning to go with Frame Sequential for all my 3D encodes. How will we know once your optimizations make it into an official revision of x264?

Mike

[Dark Shikari]

This is extremely exciting as I am planning to go with Frame Sequential for all my 3D encodes. How will we know once your optimizations make it into an official revision of x264?

MikeThey'll come in the next push. Current version is here (https://github.com/DarkShikari/x264-devel/commit/d263f32ba15430fc1de2cb63ac08ad369f311376); the version I posted above is bugged to hell and back and then some.

[BigPines]

They'll come in the next push.
Sweet! So you mean they should be in revision 1835?

the version I posted above is bugged to hell and back and then some.
Hehehehe, that doesn't sound good. :)

Thank you very much for all your efforts on this. It is much appreciated!

Mike