Free H.264 MVC 3D Encoder

[videofan3d]

Is there any way to deal with seamless branching 3D discs? Mike

Try this several times mentioned tsMuxer (probably the only freely available muxer supporting also MVC elementary stream)

[BigPines]

Can FRIM Export be used with Adobe Media Encoder. I'd like to queue a couple movies up and just let them export one after another. However, when I try to do this, I get a message box with a progress bar that says Export Media - Preparing data for export and it seems like it is hung. Premiere is using 80+ % of the processing power so maybe I just need to be patient?

EDIT: Yep, I decided to try a small 1 min clip and it sent it to Media Encoder so I guess I just need to be patient for a full film.

Now I just have to figure out the encoder options...I'm starting with:

-vbr 28000 40000 -u 1 -level 4.1

[BigPines]

I was able to successfully export a 5 min clip using these Premiere tools and it looked great! I do have some questions I would like answers to:

The encoder didn't seem to follow my bitrate or level flags. I flagged the level as 4.1 and it came out as 4, I flagged the bitrate as 28 and the average bitrate came out as 20.9 and I flagged the max bitrate as 40 and it came out as 35.5. Any ideas on this?

5 mins of video took 2 hours to encode. Ouch! I read it was slow but that was much slower than I had expected. Still for the level of quality I got out of it, I figure it is worth it. Using a virtual machine likely had an impact here. I would be curious to hear what others' encode times are for comparison. I may have to set up a dedicated PC for encoding.

After success with my 5 min clip I decided to try a full length film with a length of 1 hour and 45 mins. It never seemed to start encoding. After sitting there for several hours, it crashed the VM. Again, I may have to go to a dedicated hardware encoder or split the export out into smaller chunks and then combine them with tsMuxeR. Has anyone had success doing anything like that?

When attempting to encode the full length film, I received a message that 2.3 TB of storage was necessary to perform the encode. I assume the encoder works by writing temp files and processing them. Is this storage necessary on the scratch disk or in the same directory the project is in?

What does FRIM stand for? :)

One last thing...thank you very much videofan3d! These are some of the coolest tools I have ever seen on doom9. I am in your debt.

[videofan3d]

I was able to successfully export a 5 min clip using these Premiere tools and it looked great! I do have some questions I would like answers to:
...


Re bitrate:
I also noticed that Intel Media core sometimes lower the bitrate, probably it realizes that source video has less details (aka lower real bitrate) and thus it is not needed to encode in the requested 28 Mbit/s.
(Flagging the levels has only informative meaning to comply with MPEG norm, but has no impact on actual encoding)

Re Encoding time:
I myself encoded maximum 20 minutes of my own movies, and it also took several hours.

Specifically, on my i7 Haswell I obtained e.g. 10 minutes of 3D MVC output in ~3 hours
It is long, but let's look realistically, what is happening:
1. decoding 3D-MVC input into planar YUV 420
2. conversion of each frame (3D thus 2x) from planar YUV 420 to pixel-based YUV or RGB (using internal Premiere routines to assure compatibility)
3. processing internally in Premiere, including e.g. color correction and sharpening, which I always use in my case
4. conversion of each final frame (3D thus 2x) from pixel-based YUV or RGB to planar YUV 420 (using internal Premiere routines to assure compatibility)
5. encoding planar YUV to output 3D MVC

Steps 2-4 are internal in Premiere and apparently represent big overhead.
Some independent measurement shows that step 1 itself is faster than real-time, and step 5 itself is almost real-time on i7.
So most of processing are in complexity of API and internal Premiere processing.

Yes, it is long, but taking the situation that we are working on final render, we can let it run over the night.

Still remember, Intel Media is the only freely available 3D MVC encoding engine, and produces really good quality (even when projected on 80' screen - this surprises me the most)

re Message "2.3 TB of storage was necessary "
This is misleading info from Premiere (calculated from uncompressed size of processed video), nevertheless, system doesn't need any extra temporary disk-space, all MVC-decoding and MVC-encoding is performed on-the-fly in memory. This was the reason to develop FRIM Import and FRIM Export: to avoid huge uncompressed files.

[BigPines]

Thanks for your responses. Yes, there definitely is a lot going on. Given the fact that no other software that I am aware of can decode MVC, modify it in complex ways per the edits on the fly and then re-encode it beautifully all without having multiple generational loss or involving huge lossless files, I think it is worth it. It sounds like my VM running on my quad-core i7 isn't doing too bad. BTW, I started the full-length film encode again yesterday morning. This time it didn't crash. It has been running for 25 hours and the progress bar says it is at 42%.

Since all this is being done in memory, would it speed things up to give the VM more memory?

Of interest, I went to Intel's site to download the SDK. Since I'm a software developer, I figured you never know when I may need something like this. I was surprised to find an OS X / Android version in the download area! I snagged it but it needs 10.9 to run and I am on 10.8 so I can't look at what it has in it yet. I hope the MVC functionality is in there for OS X but the installer for OS X was much smaller than the one for Windows so I'm not sure. Who knows, maybe an OS X native solution is possible after all.

I will report back on my experience with a full-length feature of an hour and 45 minutes once the encoding is finished. I will be doing several of these in the coming weeks so I am going to give this thing a good work-out.

[geheim]

Hi,
I am trying to mux some MVC-coded Video files with Scenarist BD. Encoding was done with FRIMEncode. In Mui Generator I disabled the Checkbox and now I can add the files succesfully to Scenarist. But every time I try to Mux I get this error:

[MUX] Can not write MUX file(s) : Error creating OMF files. Please retry.

This only happens after adding the MVC files from FRIMEncoder.

Any idea what is wrong with the files??

Thanks!!

[BigPines]

I'm not sure what the root issue is but unless you need complex menus or something, I suggest you use tsMuxeR to make your BD ISOs. I used to use Scenarist so I know it is complicated and finicky about what files it will accept. tsMuxeR has taken all that hassle out of my life and saved me tons of time. You should look into it if you just need a simple BD image. Someone else may have more info on your actual problem.

[BigPines]

Happy to report that nearly 64 hours after I started the encode, it finally finished. Wow, that took a long time. The film looks amazing though so I am happy. The export didn't follow my bitrate flags again but I am going to try another film soon and see if that issue seems to be source dependent.

[geheim]

I'm not sure what the root issue is but unless you need complex menus or something, I suggest you use tsMuxeR to make your BD ISOs. I used to use Scenarist so I know it is complicated and finicky about what files it will accept. tsMuxeR has taken all that hassle out of my life and saved me tons of time. You should look into it if you just need a simple BD image. Someone else may have more info on your actual problem.

Thanks for your answer!
It does in deed work when using tsmuxer. The problem is that I do need some menus. For example I like having the option choose between 2D and 3D output via menu. The menus I created with Scenarist are working and muxing flawlessly. The error only shows after adding the MVC files.
Perhaps anyone else has any clue why this error happens??

[videofan3d]

Happy to report that nearly 64 hours after I started the encode, it finally finished. Wow, that took a long time. The film looks amazing though so I am happy. ...


May I ask what you are doing with original BD-3D that you need to process them via Premiere? :)
If you are doing some visual edits, then clear - Adobe Premiere is professional-grade video editing SW.
But if you want it only recode (from whatever reason), then you can use much faster method: Avisynth + FRIM Source for decoding and FRIM Encode for encoding.
Output quality will be identical (FRIM Export and FRIM Encode use identical encoding engine) but output result will be achieved much faster avoiding all Premiere overheads.

Btw, you are probably the first user here who used FRIM Import + FRIM Export :)
Definitely the first one who did such extensive work and reported back - thanks.

[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]

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]

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-obtCH8dE8YTUwandCcFV2aGs/view?usp=sharing

3D encoded horizontal test pattern: https://drive.google.com/file/d/0B3-obtCH8dE8VnVfQlJvNmdmWG8/view?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]

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]

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]

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]

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]

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]

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]

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!!: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?

[videofan3d]

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?

Yes, I will check this in upcoming weeks whether it requires changes in code or not. Please have some patience with me :)
In the meantime, you can try to use core Intel libraries libmfxswNN.dll / libmfxhwNN.dll from new version - they should (or at least could :) ) be backward compatible.

[tartak]

Yes, I will check this in upcoming weeks whether it requires changes in code or not. Please have some patience with me :)
In the meantime, you can try to use core Intel libraries libmfxswNN.dll / libmfxhwNN.dll from new version - they should (or at least could :) ) be backward compatible.
Thanks!
I can confirm that dll's from Media SDK 2.1 work just fine with FRIMSource.

I think this AviSynth plugin makes your toolset the most flexible of the available options for 3D encoding. I would suggest a short wishlist to make it a good deal more convenient - if you find some time.
1) Make FRIMSource work with m2ts transport streams - then there would be no need to demux them first, we could work directly with the ripped blu-ray/image
2) Indexation system like in Donald Graft's plugins. Right now, even to find out the total number of frames, you need to fire DGIndexNV or something similar.

[videofan3d]

Thanks!
I can confirm that dll's from Media SDK 2.1 work just fine with FRIMSource.

I think this AviSynth plugin makes your toolset the most flexible of the available options for 3D encoding. I would suggest a short wishlist to make it a good deal more convenient - if you find some time.
1) Make FRIMSource work with m2ts transport streams - then there would be no need to demux them first, we could work directly with the ripped blu-ray/image
2) Indexation system like in Donald Graft's plugins. Right now, even to find out the total number of frames, you need to fire DGIndexNV or something similar.

ad 1) - m2ts.
This is already implemented, just use parameter FRIMSource(..., container="ts", ...)

ad 2) indexation - this is very difficult task (and Donald's knowledge of h.264 format is much bigger than mine :) )

[trevorjharris]

I see that Intel Media SDK 2016 is available. Please can someone tell me if i is compatable.

[r0lZ]

Just tested it, and it seems to have a bug, already reported to Donald Graft , for a previous version, here (http://rationalqm.us/board/viewtopic.php?f=5&t=324&start=60#p4352).

Note that FRIMSource can process the sample without problem. I don't know why.

Anyway, as far as I know, the only version without bugs of the libmfxsw32.dll is v6.14.11.28 released by Intel in November 2014. Several versions released in 2015 do have the "black frames" bug, and previous versions were unable to decode properly some frames of some rare 3D BDs (notably Pacific Rim and Ice Age 3). IMO, it is better to stick with v6.14.11.28. However, if you really want to try it, I can confirm that the new 2016 version (v7.15.10.28) is compatible with FRIMSource.

I have not tested the encoder.

[DarkCinema]

@videofan3d

r0lZ pointed me to Frimencoder for what I try to achieve.
I would like to create a MVC-3D with hardcodes subtitles using the 3D plane info from the 3D Bluray Disk.
Currently I am using BD3D2MK3D to create a FHD T&B video. Since KODI now supports MVC-3D on the Pi2 and on some Android devices I would like to create a high quality MVC-3D which works better on the android devices than the FHD T&B video. I need to hardcode the subs since there is currently no solution to display the 3D PGS subs correctly (even with the original 3D ISO).

Is there a method I could try using Frim?

[videofan3d]

@videofan3d

r0lZ pointed me to Frimencoder for what I try to achieve.
I would like to create a MVC-3D with hardcodes subtitles using the 3D plane info from the 3D Bluray Disk.
Currently I am using BD3D2MK3D to create a FHD T&B video. Since KODI now supports MVC-3D on the Pi2 and on some Android devices I would like to create a high quality MVC-3D which works better on the android devices than the FHD T&B video. I need to hardcode the subs since there is currently no solution to display the 3D PGS subs correctly (even with the original 3D ISO).

Is there a method I could try using Frim?

Hi,

FRIM Encoder will only encode to MVC-3D planar 3D input, so it depends on you what you feed it with.

I never did any subtitle hardcoding (I don't like it). But I guess there are some plugins for Avisynth which will embed srt into video. Thus you could (in theory) decode original 3D-MVC using FRIMSource, and embed srt into (for L-eye and also for R-eye). And then then encode it back to 3D-MVC using FRIM Encode.

The key-task will be to obtain and somehow decode 3d-plane information from the original MVC stream. Unfortunately, I don't know how it is stored there and how to decode it for horizontal shift of L- and R-eye srt (to achieve Z-plane offset of the subtitles - for good viewer experience). Sorry...

Remark: Even more interesting would be to embed it into new MVC stream, but this is what only very expensive MVC-3D encoders do.

[r0lZ]

The decoding of the original video streams and the 3D-planes can be made easily with BD3D2MK3D (with FRIMSource or DGMVCSource). The conversion of the subtitles to 3D is also automatically made by BD3D2MK3D after the demux operation. The final avisynth script can also hardcode the 3D subtitles (with the SupTitle plugin). However, currently, the output is either Full or Half SBS or T&B, or Full Frame-interleaved. I suppose that the frame-interleaved output is close to what DarkCinema wants to do, but currently the two views are encoded in AVC with x264.

DarkCinema wants a MKV with AVC and MVC streams. I suppose that computing the AVC and MVC streams with FRIMEncode (instead of a single interleaved AVC stream with x264) is possible. Can you confirm that FRIMEncode will accept the AVS script (with alternate frames for the left and right views) ? And do you know if that streams will be ready to be muxed with MkvMerge ? I don't know if they are compatible with the MKV container, or if only TS or M2TS is supported.

MakeMKV can create 3D-MKVs with AVC+MVC streams, but afaik it's a non-standard format, not officially supported by Matroska, and I don't know if MkvMerge is as tolerant. MakeMKV requires a 3D-BD as input, not AVC and MVC streams, and therefore DarkCinema can't use it.

Personally, I'm not really interested in adding the possibility to encode to MVC MKV in BD3D2MK3D, but if it's easy enough, I may do it.

[frank]

3D-MKV is compatible with Matroska, but the MVC is hidden.
You can remux the 3D output from MakeMKV with MKVtoolnix, the MVC is retained. But MKVmerge is not able to generate new 3D-MKVs from AVC and MVC.

The only player for 3D-MKV is the Stereoscopic Player from Peter Wimmer. 3D-subs are not well supported.
You can generate a simple 3D-Blu-ray from 3D-MKV with tsMuxeR to play on 3D standard players.

[r0lZ]

Thanks for the precision. So, if I understand correctly, there is no possibility to create a 3D-MVC MKV with MkvMerge only. That's a serious problem, because I don't want to rely on MakeMKV (not free, and no command line).

I have also studied the possibility to encode to AVC+MVC with FRIMEncode, but it seems that it doesn't accept a frame-interleaved 3D stream (or AVS script) as input. It supports only two different streams, or SBS or T&B input. It is difficult to decode the two original AVC and MVC streams from the 3DBD with two different AVS scripts (due to the impossibility to seek with FRIMSource or DGMVCSource), and anyway it's not at all the way BD3D2MK3D works currently. Therefore the 2 streams input for FRIMEncode is not a good solution for me. It is also currently impossible to hardcode the subtitles on full-SBS or full-TAB (due to the limitation to single frame HD of the subtitles formats), and I don't want to rewrite everything to be able to hardcode the two subtitle streams on each view one at a time, and then combine the two views to Full-SBS or TAB.

It is, however, possible to use the avs script currently created by BD3D2MK3D for Half-SBS or Half-T&B (with or without hardcoded subtitles), and change only the encoder command to output the two video streams. But the benefit of the full resolution will be lost, and the final MKV will have to be created manually with MakeMKV. IMO, that's not interesting at all.

Therefore, it appears that the solution to create full-AVC+MVC MKV is way too complicated to be easily implemented in BD3D2MK3D. And since the compatibility of the MVC MKV format is at least very limited, I don't think I'll implement it. Sorry, DarkCinema. I can try to help you to establish a manual workflow if you wish, but you will have to study and test the possibilities of each programs yourself, and be sure that the output will be compatible with your hardware. I don't have enough time and interest to do it entirely for you, since now I'm sure that I don't want to implement it in BD3D2MK3D.

@videofan3d: Sorry for squatting your thread!

[videofan3d]

I have also studied the possibility to encode to AVC+MVC with FRIMEncode, but it seems that it doesn't accept a frame-interleaved 3D stream (or AVS script) as input. It supports only two different streams, or SBS or T&B input.

FRIM Encode at the moment accepts "only" separate streams, SBS and TAB input. I didn't see a reason to implement frame interleaved format - I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )

[videofan3d]

FRIM Encode at the moment accepts "only" separate streams, SBS and TAB input. I didn't see a reason to implement frame interleaved format - I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )

Just to be clear:

frame interleave = frame alternation,

i.e.
1. frame in the stream is L1
2. frame in the stream is R1
3. frame in the stream is L2
4. frame in the stream is R2
etc.
Correct?
If there is a need, I will consider to implement it.

[frank]

Originally Posted by r0lZ:
So, if I understand correctly, there is no possibility to create a 3D-MVC MKV with MkvMerge only. That's a serious problem, because I don't want to rely on MakeMKV (not free, and no command line).right.

[sneaker_ger]

The only player for 3D-MKV is the Stereoscopic Player from Peter Wimmer.
LAV nightly + latest madVR added support yesterday.

[DarkCinema]

Many thanks guys for your replies on my (I assumed simple) question. Seems to be a bit complicated to accomplish.

I never thought a solution would come so soon, but after waited for more than 2 years for a replacement media player, for my Mede8er and A-400, that could playback 3D Blu-ray ISO or MVC-3D with correct subtitle depth, I now have a working replacement.

The RC2 firmware of the VTEN supports 3D subtitles for both ISO and MVC using original PGS subtitles. It displays them on a fixed depth (configurable in future FW) and works fine using the PGS subs. This means right and left placement is kept + depth.

So this means no re-encoding is needed anymore.

[r0lZ]

I assumed it is possible to manipulate and create SBS from frame interleaved using proper Avisynth script. I'm I correct it is doable ? (question rather for Avisynth experts :) )
Yes, it's possible. It's what BD3D2MK3D does.
I just don't want to have to modify completely my scripts just to be able to output another format, and currently they are built with the conversion to HALF-SBS or HALF-TAB at the very beginning, and then the 3D subtitles are hardcoded on top of the combined frames. It is a pity to have to resize them to half size just because subtitles cannot be hardcoded on full-SBS or full-TAB.
When FULL SBS or TAB is requested by the user, the frames are never combined, the subtitles are hardcoded on each view independently, and the output is frame interleaved.

Just to be clear:

frame interleave = frame alternation,

i.e.
1. frame in the stream is L1
2. frame in the stream is R1
3. frame in the stream is L2
4. frame in the stream is R2
etc.
Correct?
If there is a need, I will consider to implement it.
That's correct, and with BD3D2MK3D, the first frame will always contain the first frame of the left eye view. But I suppose that other scripts may use whatever is the base view as the first frame, and in (not so) rare cases, that can be the right view. Anyway, for the encoder, that should not change anything. The "base view" (AVC) must always be the first stream.

Since it seems that the MVC MKV format is not needed by DarkCinema any more and anyway I don't want to implement it, I don't need the change. But you might want to consider it anyway. That will be simpler to implement via an avisynth script, since currently FRIMSource and DGMVCSource both return frames alternation. It is a pity to have to combine them to full-SBS/TAB, since they will be cut again when converted to AVC/MVC. It's only a waste of time. But I repeat that I don't need that myself, so do it only if you wish and if it's simple enough.

[videofan3d]

...
But you might want to consider it anyway. That will be simpler to implement via an avisynth script, since currently FRIMSource and DGMVCSource both return frames alternation. It is a pity to have to combine them to full-SBS/TAB, since they will be cut again when converted to AVC/MVC. It's only a waste of time. But I repeat that I don't need that myself, so do it only if you wish and if it's simple enough.

I checked quickly and it is not too much work.

I will release FRIM 1.26 soon
- compiled with Intel Media 2016 libraries, so I will add this functionality to FRIMDecode and FRIMEncode (and FRIMSource).
No other changes are planned, Intel Media 2016 didn't bring any major functionality enhancement related to MVC.
(And practically, we all expect only continuous improvement in quality of encoding and performance :) )

[r0lZ]

OK, thanks anyway for your efforts.

I know that the newest Intel libs do not offer better MVC decoding because it is lossless and (afaik) bug free, but I was hoping that the encoder has been improved. It's a pity if it's not the case, because there is much room for improvement here. Anyway, it is always good to stick with the latest version.

[videofan3d]

FRIM 1.26 released

Changes:


Compiled with Intel Media SDK 2016
64-bit versions renamed to FRIMDecode64.exe, FRIMEncode64.exe, FRIMTranscode64.exe. This allows to keep all executables on the same place and avoid confusion when calling the.
FRIMEncode, FRIMDecode, FRIMSource: new option for frame-alternation input/output: -alt (similar to -sbs and -tab)

[r0lZ]

Thanks for the -alt option! :-)