Free H.264 MVC 3D Encoder

[BigPines]

I am doing a few different kinds of things. Mainly, I edit content from films for my kids. My family gets to enjoy quality entertainment free from all the garbage Hollywood insists is crucial for brainwashing...er...realism. I know James Cameron would freak out to hear this but there isn't anything he can do about it since I am not doing it commercially. He can try to sue me like he has others if he wants but I don't think it will stick. Sometimes, I do fan edits of films too. For instance, even though Peter Jackson made Legolas do something even more ridiculous with each Hobbit film, I don't have to endure it over and over again. Indiana Jones doesn't have to get shot three miles in a refrigerator propelled by a nuclear blast. (facepalm) The Star Wars prequels don't have to be dragged down by some of Anakin's over-the-top tantrums and embarrassing dialog. I also make fairly elaborate home movies. I plan to make some 3D home movies in the future. One of the things I insist on is quality. My sources are always ripped losslessly. My audio is always re-encoded lossless with DTS Master Audio. My video is always encoded at high bitrate and multi-generational loss is always avoided where possible. Now with your tools, my 3D edits will be as clean as my 2D edits!

A few of things I still need to work out in my quest for the ultimate quality and convenience:

1) VC-1 encoded source material is difficult to work with because Premiere doesn't like it. For now, I use x264 to encode it losslessly and then do my editing on that. I would like to figure out how to import VC-1 into Premiere without the step of large re-encodes that are time consuming. Perhaps Avisynth Importer can help here?
2) I recently purchased a media player that can accept H.265. I would like to start encoding all my finished videos (except 3D of course) in H.265 to retain quality and save hard drive space. I have a 44 TB RAID on my media server and I am running out of room! Perhaps DebugMode Frameserver and x265 can help here?
3) There are a couple of 3D BDs that don't necessarily need any editing which have their left and right eyes flipped for some reason. I can switch these each time I watch them on my media player but I'd rather not have to worry about doing that. Maybe Avisynth + FRIM Source for decoding and FRIM Encode for encoding would work here? Or maybe you have another idea?

Thank you again for the wonderful tools that make my life easier!

Mike

[videofan3d]

Originally Posted by BigPines

I am doing a few different kinds of things. ...

Cool

ad 1) VC-1
For VC-1 you can use similar .frim trick like for 3DMVC:

step 1: converting to proxy h264, e.g. using command

FRIMDecode -i::vc1 VC1.m2ts -ts -o - | FRIMEncode -i - -o::h264 VC1proxy.h264 -f 23.976 -w 1920 -h 1080 -vbr 12000 18000

and multipex it (tsMuxer) into VC1proxy.m2ts with WAVE converted audio

step 2: do all edits in Premiere with VC1proxy.m2ts

step 3: use VC1proxy.frim side-car file like you do for 3D

[Video]
codec=VC1
container=TS
filename=VC1.m2ts

[Audio]
; empty or WAV-audio

and use similar replacement-process like for 3D (but now only for 2D)

step 4: do final render in Premiere. Benefit = you will perform only one(!) recompression from VC-1 to e.g. h.264

ad 2) H.265:
DebugMode Frameserver and x265 will likely work (I have no exprerience with H.265 yet, for HD content x264 is already well proven, while H.265 is still not mature and not widely supported - yet... it will come)
DebugMode Frameserver will create virtual .avi, which you can (very likely) read by x265 directly, or indirectly by wrapping into Avisynth script.

ad 3) left and right eyes flipped
You can process it via recompression FRIMDecode + FRIMEncode with -swaplr option, or maybe it will be enough to remux it with txMuxer and check its option "Use base video for right eye" located on Blu-ray tab. Just need to test...

[r0lZ]

The problem of the left and right views inverted may be caused by a bug in your media player. Normally, there is a flag in the MPLS that tells the player if the views are in the standard order (left view first) or inverted. As far as I know (almost) all commercial 3DBDs that have the right view first have that flag set correctly. Therefore, if you see the images inverted on your TV, that means that the player doesn't obey the flag. Or that the information is lost somewhere between the player and the TV/projector/monitor. Anyway, try what videofan3d suggests and remux the original stream with the base view for right eye flag (without re-encoding the video). If the problem persists, that will confirm that your software or hardware is the culprit.

[BigPines]

Thanks guys. Using tsMuxeR to set the "Use base video stream for right eye" flag didn't fix the problem so the problem is the media player. That makes sense since all these discs play fine in my BD player. For now, I will ask the manufacturer of the media player to look into a fix. If they can't or won't fix it, I think I'll re-encode these. I have only run into three of these so far:

The Chronicles of Narnia: The Voyage of the Dawn Treader (2010)
The Hobbit: An Unexpected Journey (2012)
The Hobbit: The Desolation of Smaug (2013)

I am at a loss as to understand why these discs were even encoded this way.

[r0lZ]

Originally Posted by BigPines

I am at a loss as to understand why these discs were even encoded this way.

It is the responsibility of the director of the movie to select what he think is the best view for the 2D version. It is totally legit to select the right view instead of the left one, although IMO, most of the time, the two views are equivalent and can be considered as the main view without problem.

There are other examples of "right view first" 3DBDs. For example, all movies released by the Belgian animation studio nWave (Samy 1 and 2, The House of Magic...).

[BigPines]

Interesting. I fail to see how the difference between the two views would be material but these are artists we are talking about. It would just be nice to have a standard we could count on and it would also reduce complexity.

[r0lZ]

IMO, there is a de-facto standard. Most of the time, the left view is the base view. Also, currently, when a BD3D is converted to 3D Side-by-Side or Top&Bottom, the left view is (almost) always the first view (left or top). At least, it's what BD3D2MK3D does automatically, regardless of the base view of the original BD.

In the past, I have worked on 3D animation. Usually, the director places a single virtual camera and computes the whole movie in 2D. When he is happy with the result, the second virtual camera is created. To respect the de-facto standard, it should be placed to the right of the original camera, but it's not always possible. For example, it can be in a wall or behind an object during some shots. Therefore, it might be necessary to move the original camera a bit (and therefore changing slightly the original 2D version), or to place the second camera to the left. If the second solution is possible without having to move the original camera, I understand perfectly that it is chosen. I don't know exactly how live movies are shot in 3D, but I know that the double cameras are heavy and cumbersome. In some shots, it might be difficult to place that cameras such as both views give a perfect result, and the right view may be much better.

However, I agree that some directors (notably Ben Stassen at nWave) prefer the right view without a good reason. But again, they are free to decide what view is the base view.

Anyway, the industry has no interest in simplifying things for us. The BD players can perfectly play the 3D movies, regardless of the views order, and it's the only thing that they want. And the standard exists. It is based on the "right-view-first" flag. It's a pity that some players (or converters to SBS or T&B) do not respect it, but you can't blame the standard.

[BigPines]

Thanks and understood.

No, they have no interest in simplifying things for us. If anything, inverting the eyes could be seen as yet another layer of copy protection which is beneficial for them. I guess what I meant to say is I don't like the decision they made on the standard. I am an amateur photographer so I understand framing a little bit. The problem is, once you enter the realm of 3D, your sacred framing for one particular eye or the other goes out the window. The other thing is, the two views are so similar that most of the time it is simply immaterial which eye you watch in 2D because it is the same experience. I can see for consistency, you'd want to pick one eye or the other for setting up shots but that is it. I'll bet you could take 100 people who have only seen the left eye of a particular film and show them the right eye instead and nobody would even notice. People's displays introduce larger changes than watching one eye over the other. Most of the time when you look at the two frames right next to each other, it can be difficult to pick out the differences. I believe it is an unnecessary complication but that is just my humble opinion.

Anyway, thanks for your help. You taught me something about the way this is handled in BD players with the flag. The media player is at fault. I will avoid re-encoding if I can get the manufacturer to fix it. If not, I may just re-encode them. No harm done as the Hobbit films need fan edits anyway.

[jmsmarcelo]

Hello,
Is possible add Chapter point in video on encoding?

[BigPines]

I am getting unexpected results with FRIM Encoder. I am trying to create a 3D test pattern to verify full resolution through the display chain. I created my test patterns in Premiere and exported them to two identical lossless yuv files. The yuv files play fine. I then used FRIM Encoder via the command line to encode the 3D video using the following: FRIMEncode -i video_L.yuv video_R.yuv -o::mvc 3D_Patterns.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000 -u 1

FRIM Encoder then says the output video is AVC which is a little strange but it produces an MVC H.264 file. The file however is distorted and unusable. I know these test patterns are probably torture for an encoder but that is the whole point of them. They ought to work, right?

The same YUV file encoded perfectly in 2D using x264 via Handbrake.

Exporting from Sony Vegas to MVC produced the same distortions as FRIM Encoder. What is going on here?

Original horizontal test pattern: https://drive.google.com/file/d/0B3-...ew?usp=sharing

3D encoded horizontal test pattern: https://drive.google.com/file/d/0B3-...ew?usp=sharing

UPDATE: It appears to be a problem with YUV. I re-exported the patterns from Premiere in Quicktime Animation Lossless and it re-encoded with Sony Vegas just fine. Does this make sense to anyone?

[BigPines]

jmsmarcelo, chapters are not part of the video stream. You need to add chapters into the container when you mux your audio and video together. tsmuxer can do this.

[videofan3d]

Originally Posted by BigPines

UPDATE: It appears to be a problem with YUV. I re-exported the patterns from Premiere in Quicktime Animation Lossless and it re-encoded with Sony Vegas just fine. Does this make sense to anyone?

Please check your YUV streams.
I don't know how did you convert .png into yuv, maybe you have there some kind of header - which should not be there for FRIM.

YUV stream must have size as multiple of 3110400 (exactly), i.e. 1920*1080 + 2 * 960*540 = pure sequence of planes Y and U and V.

[BigPines]

My YUV streams were exported from Premiere. The Premiere project had 1920x1080 PNGs in a 1920x1080 23.976fps project and the exported video was 1920x1080 23.976fps. I exported in Quicktime - Uncompressed YUV 8 bit 4:2:2. I would upload one of the YUVs but they are ~6GB.

Mediainfo:

Video
ID : 1
Format : YUV
Codec ID : 2vuy
Duration : 1mn 0s
Bit rate mode : Constant
Bit rate : 795 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 5.56 GiB (100%)
Language : English
Encoded date : UTC 2015-09-17 20:34:30
Tagged date : UTC 2015-09-17 20:34:35

Does this sound like it should have worked?

[videofan3d]

Originally Posted by BigPines

Uncompressed YUV 8 bit 4:2:2

Does this sound like it should have worked?

This is the issue: you have to have YUV 8 bit 4:2:0 (!)

FRIM (Intel Media) works only with chroma-subsampling 4:2:0 which is native for Bluray.

[jmsmarcelo]

Originally Posted by BigPines

jmsmarcelo, chapters are not part of the video stream. You need to add chapters into the container when you mux your audio and video together. tsmuxer can do this.

yes it is possible to add, for GOPs .. for not to give difference when put chapter.
in CineVision, HCEncoder, and etc. It has that option.

[videofan3d]

Originally Posted by jmsmarcelo

yes it is possible to add, for GOPs .. for not to give difference when put chapter.
in CineVision, HCEncoder, and etc. It has that option.

Yes, it is possible to force I-frame in FRIM Encoder:

-gopfile filename

where "filename" is text file describing requested I-frame structure e.g.:
9 I
40 I
55 I
etc.

Please note that some older versions of Intel Media libraries libmfxswNN.dll and libmfxhwNN.dll had a bug and didn't respect the forced I-frames.

[BigPines]

Originally Posted by videofan3d

This is the issue: you have to have YUV 8 bit 4:2:0 (!)

FRIM (Intel Media) works only with chroma-subsampling 4:2:0 which is native for Bluray.

Thank you! I'll see if I can export the correct file from Premiere.

[videofan3d]

Originally Posted by BigPines

Thank you! I'll see if I can export the correct file from Premiere.

Keep on mind it must be 4:2:0 planar, i.e. Y-plane followed by U-plane and V-plane (both U a V are deduced by 2 in both x- and y-dimensions, therefore :2:0)

And no frame-header, just pure YUV-data-stream.

[jmsmarcelo]

Originally Posted by videofan3d

Yes, it is possible to force I-frame in FRIM Encoder:

-gopfile filename

where "filename" is text file describing requested I-frame structure e.g.:
9 I
40 I
55 I
etc.

Please note that some older versions of Intel Media libraries libmfxswNN.dll and libmfxhwNN.dll had a bug and didn't respect the forced I-frames.

thanks!!

[tartak]

videofan3d, are you going to update to Intel Media SDK 2015 Update 2.1? There are quite a few quality and performance improvements (plus official Windows 10 support) mentioned in Release Notes, but I am not sure how big the benefits really are. Is it just a matter of recompiling for you?