Free H.264 MVC 3D Encoder

[jdobbs]

Is anyone else having problems with the FRIMSource() in v1.26?

I get an error if I try to use it, but it works fine if I just replace it with the DLL from v1.25.

[r0lZ]

That's right. It doesn't work with the latest libmfxsw32.dll (v7.15.10.28, 28/10/2015). The plugin crashes without any error message.
I have not tried it with an older libmfxsw32.dll, but the previous version of FRIMSource.dll works fine with the latest Intel library.

[videofan3d]

That's right. It doesn't work with the latest libmfxsw32.dll (v7.15.10.28, 28/10/2015). The plugin crashes without any error message.
I have not tried it with an older libmfxsw32.dll, but the previous version of FRIMSource.dll works fine with the latest Intel library.

Show me the script and conditions to reproduce, I'll check this...

[r0lZ]

You can download this sample (http://download.videohelp.com/r0lZ/tmp/DGMVCSource%20bug%20with%20libmfxsw32%20v6.15.6.2.7z) I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

But IMO you don't need it. AFAIK, the crash happens with any MVC decoding.

I've used the two DLLs from FRIM_x86_version_1.26.zip, but the same bug happens with the Intel lib directly downloaded from their site. I have not tested the 64-bit version of FRIMSource.

[videofan3d]

You can download this sample (http://download.videohelp.com/r0lZ/tmp/DGMVCSource%20bug%20with%20libmfxsw32%20v6.15.6.2.7z) I did to test the black frames bug of DGMVCSource. Just comment out the 2 lines related to DGMVCSource and uncomment the two lines for FRIMSource, and change the path to the DLL.

But IMO you don't need it. AFAIK, the crash happens with any MVC decoding.

I've used the two DLLs from FRIM_x86_version_1.26.zip, but the same bug happens with the Intel lib directly downloaded from their site. I have not tested the 64-bit version of FRIMSource.

This is strange...
I used sample files which you provided, and played it using the script:

LoadPlugin("c:\Prj\IntelMedia\_exe\Win32\Release_v1.26\FRIMSource.dll")
FRIMSource(codec="mvc", filename="c:\a\sample.264", filename_dep="c:\a\sample.mvc", num_frames=100, cache=2, platform="sw", log_file="c:\a\Z.log", layout="sbs")

without any issue!

I used fresh installation of Avisynth 2.6.0 downloaded from videohelp.com.
And Intel library libmfxsw32.dll is file version 7.15.10.28, API 1.17 (this is written into file Z.log).

No crash occurred to me....
(and the same for layout "tab" or "alt")

[jdobbs]

It crashes on every source I try. I'll send you an example.

[jdobbs]

@videofan3d

I've sent you a PM with a link to test files that cause it to crash on my computer. My test was with AVISYNTH 2.58... but it should do the same with 2.60.

[videofan3d]

@videofan3d

I've sent you a PM with a link to test files that cause it to crash on my computer. My test was with AVISYNTH 2.58... but it should do the same with 2.60.

Tested on Windows 7.

LoadPlugin("c:\a\frimsource1.26.dll")
FRIMSource(codec="h264",filename="00000.m2ts",container="ts",platform="sw",num_frames=4427,cache=24,log_file="c:\a\Z.log")

Tested with both libraries libmfxsw32.dll:
version 7.15.10.28, as well as 6.14.11.28

Avisynth 2.6.0
(cksum avisynth.dll is
3665143647 401920 C:\Windows\System32\avisynth.dll
3665143647 401920 C:\Windows\SysWOW64\avisynth.dll

Again, no problem on my setup.
- attached is screen from MPC-HC version 1.7.8.61 which I have installed.

[jdobbs]

All I can tell you is that it fails. Not sometimes, but every time on every source I try with the new dll. If I switch to v1.25 (even when using the newer libmfxsw.dll) it works every time. This is true not just with MPC, but with X264 or anything else that tries to use the AVS.

I'm not sure what else to tell you -- but if switching fixes it, it is very obviously the version. If it were the configuration, hardware, or some other variable it would fail with both.

It's not a big deal, as I can just use the older dll -- I just wanted to report it.

[Edit] Hope you don't mind that I removed the attachment after I looked at it... it was really big and made the thread hard to read

[videofan3d]

All I can tell you is that it fails. Not sometimes, but every time on every source I try with the new dll. If I switch to v1.25 (even when using the newer libmfxsw.dll) it works every time. This is true not just with MPC, but with X264 or anything else that tries to use the AVS.

I'm not sure what else to tell you -- but if switching fixes it, it is very obviously the version. If it were the configuration, hardware, or some other variable it would fail with both.

It's not a big deal, as I can just use the older dll -- I just wanted to report it.

[Edit] Hope you don't mind that I removed the attachment after I looked at it... it was really big and made the thread hard to read

Version 1.25 and 1.26 differ only a little ("alt" option), and in compilation with Intel Media 2016 libraries.
Avisynth 2.6.0 also brought some changes in calling "AVS_linkage" vector, which I incorporated in version 1.26.

If you will add FRIMSource (..., log_file="whatever_path_file.log"), then you will see in .log where is the libmfxswNN.dll called from.

I re-tested it now quickly also on Windows 8.1 (64-bit) - no problem.
And also with FRIMSource64.dll (opening .avs with MPC_HC x64 via AviSynth+). Both again without obstacles.
Hard to say what is wrong until I reproduce the problem...

[jdobbs]

Version 1.25 and 1.26 differ only a little ("alt" option), and in compilation with Intel Media 2016 libraries.
Avisynth 2.6.0 also brought some changes in calling "AVS_linkage" vector, which I incorporated in version 1.26.

If you will add FRIMSource (..., log_file="whatever_path_file.log"), then you will see in .log where is the libmfxswNN.dll called from.

I re-tested it now quickly also on Windows 8.1 (64-bit) - no problem.
And also with FRIMSource64.dll (opening .avs with MPC_HC x64 via AviSynth+). Both again without obstacles.
Hard to say what is wrong until I reproduce the problem...I just tested it with AVISYNTH 2.6 and it works. As I'd mentioned, previous tests were using AVISYNTH 2.58. So the change you made using the AVS_linkage vector apparently makes if incompatible with earlier versions of AVISYNTH.

BD Rebuilder supports downward compatibility with earlier versions of AVISYNTH (2.5), so unfortunately I won't be able to update the installation package to include the v1.26 FrimSource dll.

[videofan3d]

I just tested it with AVISYNTH 2.6 and it works. As I'd mentioned, previous tests were using AVISYNTH 2.58. So the change you made using the AVS_linkage vector apparently makes if incompatible with earlier versions of AVISYNTH.

BD Rebuilder supports downward compatibility with earlier versions of AVISYNTH (2.5), so unfortunately I won't be able to update the installation package to include the v1.26 FrimSource dll.

Good - so we found the root. Thanks!

Avisynth 2.6.0 is stable - so for time-being I'll leave it.
Later I'll check if it can be easily fixed...

[Eseninzhiv]

can someone make a video on YouTube?
how to install in system, the entire procedure
and re-encode a small piece of 3D (SSIF file demux into streams through tsMuxeR)
with the last AVISYNTH 2.6 and Intel_Media_SDK_2016
preferably on 64-bit windows
thanks in advance!

PS: video (http://www.youtube.com/watch?v=DT4nBVofLXg) made
Sef Thank you!

[Thalyn]

Small, quick observation, Videofan3d: it seems your AVISynth plugin won't work in the absence of hardware decoding acceleration.

For stability reasons (which I later determined to be heat-related) I disabled my on-die GPU (HD4600) and just went with my stand-alone GPU. FRIMSource flat out refused to work, kicking back the error "Cannot initialize Intel Media SKD session." Out of curiosity I re-enabled the on-die GPU and set the Platform to be SW - same error. Worked fine in HW mode, however (forced or allowed to detect it).

[jdobbs]

Try leaving your GPU on but enabling sw encoding.

[Thalyn]

I've only ever used software encoding (x264). It's the decoding which is giving issues when attempting to use software mode instead of hardware, whether the on-die GPU is active or not.

[jdobbs]

You missed the point. You can individually enable sw encoding and decoding... so the point is that the encoder or decoder may see your (Intel) processor and assume you have hw acceleration available. By manually forcing sw, you 1) Don't have to disable your GPU 2) May avoid issues. What I was suggesting was that it may be possible that the failure was due to the fact that the GPU was disabled but the software (Intel's dll) was still trying to use it.

I use software encoding/decoding all the time with a non-Intel (AMD) CPU, and it works fine.

[Thalyn]

I guess it could be the presence of an Intel CPU giving it issues. I'm perhaps the only person, anywhere, using SW decoding on an Intel CPU with an appropriate GPU. But I have tried forcing software (platform = "SW"). I mention as much. It gives the same error as when the hardware is not available.

Incidentally, having the GPU enabled on its own is not sufficient to get HW decoding. Not for now, at least - headless mode isn't available through the Media SDK. It requires a screen also be active, though that screen doesn't necessarily need to physically exist.

[l33tmeatwad]

Any plans to port the AviSynth plugin to VapourSynth?

[BlackSharkfr]

Hello,
I'm using this program for the first time.
I bought a Sony BDP S4500 BluRay player with 3D capability, the player has no problem with AVC side by side 3D (squashed) clips, but it cannot play side by side (full ratio) 3840x1080 clips I am used to manipulate on my computer.
So I decided to try using FRIM to convert these side by side AVC clips into MVC.
I has some difficulties, but in the end I managed to make it work. However, I am very surprised by how different the image quality looks depending on which software/hardware i use to play the files.

I had a lot of difficulties feeding FrimEncode from my usual mkv clips. The file I used as source for this test is a 5 minute clip with 3840x1080 resolution 24fps side-by-side AVC made with x264 at about 10-15 Mbps average bitrate.
I wanted to use avisynth scripts to open the mkv files directly, but for some reason I couldn't get DirectShowSource to open them, I did manage to open them with FFmpegSource but for some reason I do not understand, I couldn't feed this script to FrimEncode.
When I used : -i input.avs -sbs 2 -w width -h height, the program stops at 0 frames (it creates empty output files)
When I used : -i input.avs -avi -sbs 2, the program gives me codec error. ( I did try to add converttoYV12() but it makes no difference)
I haven't used avisynth in a very very long time, it's probably an obscure problem on my side and I'm not that interested in using avisynth at the time. (I don't use it for anything else at the moment)

So I used a different feeding system : I extracted the h264 elementary streams using mkvextract gui, and used FrimDecode to open the elementary stream into a pipe using the -o \\.\pipe\filename.yuv trick.
I then reopen that pipe in FrimEncode with a difference command prompt, and finally managed to get it working.
The first time I did, I used the following parameters : -i \\.\pipe\filename.yuv -sbs 2 -w 1920 -h 1080 -o:mvc base.h264 dependent.h264 -vbr 10000
It went quite fast even though FrimEncode says it was using software mode : almost real time (I have an Intel Ivy Bridge i5-3570K, but the IGP is off : i use an AMD gaming graphics card)

I then muxed the base and dependent stream with TSmuxer into a m2ts container (along with the audio from the original clip).
I opened the file into my usual 2D video player (MPC HC) to check the picture quality of the base view : I was shocked at how awful the picture looked.
The initial fade in from black of the video has a large amount of small black artefacts across the picture (like if the fade in is delayed by one or two frames in these blocks), then during the clip I could see obvious blocking issues, especially backgrounds where there should be smooth gradients, if the camera is panning the blocking in these gradients moves randomly and attracts the eye towards the defect.

I then learned about the quality setting (-u value) which defaults to 4 (medium) if not specified.
So I tried again with : -i \\.\pipe\filename.yuv -sbs 2 -w 1920 -h 1080 -o:mvc base.h264 dependent.h264 -vbr 10000 -u 1
It went much more slowly (about 5-10 fps on average) but the end result looked much better.
The "-u 1" file has way less visible blocking artefacts, but they're not really gone. It's not clean like x264 AVC.

I then tried playback in stereoscopic player (3dtv.at) to see the dependent stream and got even more surprises.
The base view looks just like in MPC HC, the dependent view has about an equivalent amount of blocking artefacts as the base view, but the dependent view also has some bright green blobs appearing temporarily on the top edge of the picture wherever there is movement in the adjacent lower parts of the picture (typically : across the entire top of the picture during pans or when just in the part above a character's head when they move)
The "-u 4" file shows a lot more artefacts than the "-u 1" file, the occurrence in the "-u 1" file is very rare but it does have it too.

But then the big surprise was when I loaded these files in the Sony BDP-S4500 BluRay player.
The m2ts file successfully loads across the network, 3D is automatically detected and used, and the picture looks completely clean.
Fade ins and outs are clean, background gradients are smooth, the dependent view looks perfectly normal, no green blobs, with both the "-u 4" file and the "-u 1" file. I am stunned !
It's like if the software players had forgotten to do the deblocking pass but the Sony player didn't or something. I cannot explain the difference in behaviour.

Did I forget something ? Did I miss a parameter ?

[videofan3d]

Hello,
I bought a Sony BDP S4500 BluRay player with 3D capability...

Wow, interesting observations - I have never did any such research :)
Maybe other members of this forum will comment their experience with proper encoding parameters.

Just a comment to -vbr: it should have 2 parameters
-vbr bitRate maxRate

e.g. -vbr 10000 15000
the first is requested average bitrate,
the second is requested maximum bitrate.
Attention! It specifies bitrate of both (main and dependent) streams together! Not only for main stream!

Question: how exactly did you manage to play .m2ts file on your Sony BDP S4500 in 3D ? Does it play the .m2ts files in 3D directly from network storage or from USB - without having BDMV navigation structure?

[BlackSharkfr]

I did not set the maxbitrate value and it encoded fine.
As I said it was just a test.
I guess the maxrate becomes important if you want to use a much higher average rate, you have to make sure the maxrate matches the capabilities of the BluRay3D format.

I do not know what value is used by default if nothing is entered.

I could use the USB input, but I play my files through the network.
I store my video library on a Synology NAS, and I use the DLNA madia server application to share my audio and video library over my LAN which the Sony BDP-S4500 accesses over Ethernet. There is a different version of this player (BDP-S5500) which also has WiFi but it's more expensive... and I don't need Wifi since I wanted to use a wired connection from the very start.
The DLNA server app is configured to only serve the original files and never reencode.

The m2ts files appear like any other shared video : the displayed name is the "title" metadata. The actual file name mentionned only appears if the "title" metadata is missing, and the icon displays the file type (MPEG is drawn in the icon instead of MKV or MP4).
When I play the file, the BluRay player automatically activates the 3D mode. Just like with my side by side squashed mkvs (if the stereoscopic tag is properly set).

Note that I only tried to play the file in the m2ts container. I did not try to play it in an mkv container (I definitely should try that, I'm curious).
I also tried to add BluRay PGS subtitles in the m2ts : the player just refuses to load the video file.
I did not try SRT subs, I know they work fine in side by side mkvs, I'm curious to see if they work with MVC too (although the font chosen by Sony is really ugly)

One interesting thing to mention : there is a button on the remote to display technical information while playing a video (audio and video codec, number of audio channels and current audio and video bitrate).
When I play a BluRay disc : the video codec says "MVC".
But when I play the m2ts file it only reports AVC (even though it is actually playing the full MVC file in 3D).



I also noticed I cannot switch 3D off (can't play the base view in 2D only). I guess that's probably a bug on Sony's side. I should write to their tech support : they appear to care a lot for this little player : they update the firmware every tree months.

[r0lZ]

Given the symptoms described in your first post, I would suggest that the encoded AVC and/or MVC use a level incompatible with your players, but is flagged with a lower level. That may explain why the players accept to play the file, but fail to do it properly. However, I'm really not sure it's the correct explanation, because if I understand correctly, your hardware player plays it correctly. Usually, the hardware players are much more picky than the software players, and most software players can play AVC/MVC with the highest levels.

I don't know if FRIMEncode has a setting to control the level, but if it's the case, I would try to set it to level 4.1 (Blu-Ray compatible) or even below, and see if that solves the problem. Just a suggestion. I'm not sure that will work.

[BlackSharkfr]

I don't think the encoded level has anything to do with it since I know the software H264 decoders on my computer can easily decode level 5 which the BluRay player has a very strict limit at level 4.1 (it refuses to play the 3840x1080 side by side file, it does not even try).

My guess would be that Sony added extra filters in their player to 'improve" the picture : add extra deblocking if the player detects a lack of deblocking (mpeg 2, mpeg 4 asp, etc...) or an incorrect amount of deblocking in AVC/MVC.

It's just a guess based on experience with TVs vs computer monitors.
TVs tend to have lots of filters because they word all the time with very dirty sources (like low bitrate mpeg 2 HD broadcast).
I guess the same logic probably applies to consumer BluRay players.

[videofan3d]

I don't think the encoded level has anything to do with it since I know the software H264 decoders on my computer can easily decode level 5 which the BluRay player has a very strict limit at level 4.1 ...

I tend to agree. Setting level is only marking the stream, i.e. to announce that it complies with a norm, with relevant bitrate limit and resolution. But actual bitrate itself can be forced higher.

I personally use FRIMEncode only for my own 3D videos(i.e. not for ripping and recompressing of BD3D). And I don't care too much about diskspace, so I always use setting -vbr 28000 40000 giving average 28 mbit/s with maximum 40 mbit/s (this is even higher than what my source material has). And with this setting I didn't observe any artefacts neither in Stereoscopic Player, MPHC (in 2D mode only) nor on 3D plasma (Panasonic) nor on 3D projector (Optoma).

[r0lZ]

I tend to agree. Setting level is only marking the stream, i.e. to announce that it complies with a norm, with relevant bitrate limit and resolution. But actual bitrate itself can be forced higher.I know that. It's why I wrote "... MVC use a level incompatible with your players, but is flagged with a lower level". And the fact that the level written in the header does not necessarily reflect the real level is IMO the cause of many problems. I consider it as a very big bug (of most h264 encoders). BTW, there are mods of the x264 encoder that fixes that bug, and limit the bitrate according to the specified level. Anyway, it is a fact that currently, it is almost impossible to know exactly the level of a particular encoding if you don't know the command line that has been used. It's why I tend to suspect level problems.

I have had some playback problems (choppy playback and abrupt stops) with my TV when I encoded with x264 level 4.1 without specifying the max bitrate. The TV trust the level and tries to play the file anyway, but cannot do it properly. However, I agree that the level problem is probably not the cause of the bad decoding here. But what BlackSharkfr has noticed is so strange that there must be an explanation. I supposed that all decoders must decode a properly encoded movie (with a compatible level) properly. It appears that it's not the case (al least with h264 streams encoded with the Intel encoder). If the level is not the culprit, what could be the reason?

[Sharc]

.....I have had some playback problems (choppy playback and abrupt stops) with my TV when I encoded with x264 level 4.1 without specifying the max bitrate. .....
Both --vbv maxrate and --vbv-bufsize must be set Blu-ray compliant to avoid stutter during playback.

[BlackSharkfr]

If I did not miss any setting relative to the deblocking issue, the only possible explanation I can find is that intel simply did not think people would encode MVC at anything lower than BluRay bitrates, thus causing their encoder fall apart at *cough* "low bitrates" *cough* (10Mbps).

[videofan3d]

If I did not miss any setting relative to the deblocking issue, the only possible explanation I can find is that intel simply did not think people would encode MVC at anything lower than BluRay bitrates, thus causing their encoder fall apart at *cough* "low bitrates" *cough* (10Mbps).

I cannot comment nor judge if this statement is true or not :-)

But: If you want to have really working, realistic 3D, you MUST have big screen. And if I say big, I mean really something bigger than 80" (!). It is SIGNIFICANT visual difference in 3D perception once you move from small TV (50-55-65") to 3D projection (90-100-110"). Really, believe me.
And for big screen you need to have high quality signal, which implies you need to use Bluray 3D bitrates, i.e. something above 24 and more mbit/s.
I recommend not to save few GB (which costs nowadays only few bucks) but rather enjoy high quality 3D picture on big screen.

[sef]

:goodpost:

[BlackSharkfr]

If you want to have really working, realistic 3D, you MUST have big screen. And if I say big, I mean really something bigger than 80" (!). It is SIGNIFICANT visual difference in 3D perception once you move from small TV (50-55-65") to 3D projection (90-100-110"). Really, believe me.
And for big screen you need to have high quality signal, which implies you need to use Bluray 3D bitrates, i.e. something above 24 and more mbit/s.

I agree. 3D does look fantastic on a big screen.
I use a DIY passive dual-projector system with a 110" screen.

Even though files with higher bitrates do look best, I also have a lot of content with much lower bitrates that look perfectly acceptable. (Mostly YouTube sbs clips)
The thing is : x264 is so good a low bitrates (yes even YouTube's super fast settings), you get a shock when you switch to other less capable encoders.

I wanted to try MVC for 3 reasons :
1 was being able to play the same video both in 2D on the regular 2D monitor and 3D on the big screen without having to fiddle around with the pan/zoom controls of my media player (practicality)
2 was to take advantage of the alledged 30-50% nitrate advantage of MVC over AVC for 3D stereo. (File size)
3 Being able to play my full-resolution side by side clips on the BluRay player (I currently must use the computer to play them) (practicality again)

It turns out #2 is currently not achievable with free tools. I'll have to wait until some very nice person adds MVC encoding to x264. (I may have to wait a looooong time)

It turns out that

[sneaker_ger]

#2 You can probably squeeze more 3D compression out of x264 if you use frame sequential/interleaved encoding (--frame-packing 5). In principle it is similar to MVC.

[BlackSharkfr]

#2 You can probably squeeze more 3D compression out of x264 if you use frame sequential/interleaved encoding (--frame-packing 5). In principle it is similar to MVC.

I tried it when the feature was introduced, I obtained terrible results :
Not only there is very little software capable of playing this content (basically, only stereoscopic player),
not only did I obtain no bitrate reduction for the same quality setting,
but the picture was heavily distorted as x264 mis-interpreted parallax as extreme horizontal shaking motion : the farther in depth the objects in the scene are to the screen depth, the more blurry x264 would make them.

And finally I suspect frame sequential files to have a weakness to frame loss. If for whatever reason the player isn't capable of keeping an accurate frame count across the entire movie (let's say when seeking), you'll get a 50-50% chance of a stereoscopic eye-swap + 1-frame lag between the eyes.

I never tried it again, ever.
And I don't want to try again. The drawbacks just outweigh any benefit.

[Sharc]

....not only did I obtain no bitrate (file size) reduction for the same quality setting......
You can't expect a significant bitrate (file size) reduction just from the packing method because x264 does not produce a dependent MVC stream for the second view. The bitrate (file size) saving would be achieved by sharing the same I (reference) frames for the 2 views.
Even the Intel MVC encoder is not very strong regarding file size reduction for the dependent view. It is however still the only free MVC encoder which is available today AFAIK, and it produces reasonable quality at sufficiently high bitrates. So the choice is between intel (FRIM) MVC or x264 SBS/TB still. If low file size is the premium target, x264 SBS (or TB) is the choice IMHO.

[sneaker_ger]

You can't expect a significant bitrate (file size) reduction just from the packing method because x264 does not produce a dependent MVC stream for the second view. The bitrate (file size) saving would be achieved by sharing the same I (reference) frames for the 2 views.

The x264 devs say:
Tests consistently show that interleaved frame packing is by far the best way to compress 3D content.
It gives a ~35-50% compression benefit over separate streams or top/bottom or left/right coding.
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected. AVC is not designed for any top-bottom/side-by-side optimization.

And finally I suspect frame sequential files to have a weakness to frame loss. If for whatever reason the player isn't capable of keeping an accurate frame count across the entire movie (let's say when seeking), you'll get a 50-50% chance of a stereoscopic eye-swap + 1-frame lag between the eyes.
x264 writes a SEI to every frame to mark the view so players don't have to keep count.

[BlackSharkfr]

The x264 devs say:

http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected. AVC is not designed for any top-bottom/side-by-side optimization.


x264 writes a SEI to every frame to mark the view so players don't have to keep count.

It looks like they made a few patches since the last time I tried this feature.
I'll need to try again to see if they corrected the issues.
By the way, I never tried frame sequential content on the Sony BluRay player.
I know for sure that Sony does have frame sequential support AVC in mp4 file working on the PlayStation3. I wonder if they implemented it in their BluRay players too.

[Sharc]

Isn't frame sequential packing one of the alternatives in the Blu-ray standard which is for whichever reason just not being used for commercial Blu-ray discs? If it's part of the standard, every player with the Blu-ray label should be able to play frame packed content. Maybe I am wrong ...?


Edit for clarification:
Blu-ray does not support frame sequential packing. It only supports MVC with 2 muxing formats:
- ssif structure based on 2 individual base and dependent .m2ts files
- muxing of the base and dependent streams into one single .m2ts file

tsMuxeR supports both principles.

[Sharc]

The x264 devs say:

http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=247f504d3c7ac64a87ed5a12bab0f6b99af5959c
Which is expected.
They expect an interleaved 3D source, if I read this correctly. What exactly is it? 2 independent source streams for left and right view? Or an AVC and MVC interleaved stream? The --frame-packing 5 just tells x264 how the stereo source is packed. I couldn't produce any watchable result so far with frame-packing 5, just a blocky picture for both 2D and 3D viewing with MPC-HC (2D) or Stereoscopic Player(3D). Not sure how they define the 35....50% file size reduction. Anyway, I probably misunderstand something ..... never mind :o

[BlackSharkfr]

I can't say for the BluRay formats.
MVC was all new and shiny designed specifically for BluRay3D.
It claimed significant bandwidth improvements over separate parallel streams. But parallel streams was never a popular format for distribution.

The most commonly used formats for distribution were interlaced video MPEG2 (from the few 3D DVDs released in this format) with the left and right views stored in the odd/even fields. And side by side for everything on the internet.

X264 frame-packing 5 expects a frame sequential video as input.
It's the same principle as interlaced 3D but with full-resolution progressive pictures.
1st frame is left eye, 2nd frame is right eye, 3rd frame is left, etc... (Typically provided by some avisynth script since I don't know any software that outputs frame sequential stereoscopic video.
The x264 team chose the name for this option very poorly since it adds to the already very confusing HDMI frame packing transmission format (only exists within the HDMI cable, not a file format, not a picture format)

[r0lZ]

It looks like they made a few patches since the last time I tried this feature.
I'll need to try again to see if they corrected the issues.
Have you noticed this ? :

Note that x264 will not do this optimization unless --frame-packing 5 is used to tell x264 that the source is interleaved 3D.

The blurry parallax problem you have experienced might be caused by the missing --frame-packing argument.

[Sharc]

I did a few more tests with x264 and --frame-packing 5, and muxing the frame packed .264 stream to .m2ts with tsMuxeR, setting level 4.1

Encoding:
- x264 encodes the interleaved (combined) source using 1-pass CRF mode, and exits finally with error code 1.
- tsMuxer muxes the encoded .264 stream to .m2ts without error, frame rate = double (47.952fps)

Playback:
- I can watch the 3D .m2ts correctly with bino
- Stereoscopic Player however swaps the views every about half second (??)
- The TV plays the left and right view sequentially (= jittery 2D)

So 3D re-encoding of 3D sources using x264 and --frame-packing 5 seems to work, but playback compatibility is poor (only the bino player works in my case).

Edit:
Some more info on 3D display and HDMI structures is found here:
http://www.spectracal.com/downloads/files/Website/Website%20Articles/Stereoscopic%203D%20Video%20in%20the%20Home.pdf

[BlackSharkfr]

Have you noticed this ? :

The blurry parallax problem you have experienced might be caused by the missing --frame-packing argument.

I did use that option. In fact the whole point was to try it when it was first introduced. But again.. That was a few years ago, I have not tried encoding anything with frame sequential storage and am not very interested by this format. (As far ad I'm concerend it's a dead end).
I am much more interested in MVC since it's an industry standard. And is supported by pretty much any BluRay3D player. (Including the one I have)

And I am pretty sure the next gen players will probably be able to do 1080p fullSBS HEVC because of all the 4K support.

[robl45]

Is there a guide on how to use this? I want to take makemkv mvc output and compress it for space savings. I understand that this tool appears to be the only way to do that, but I can't seem to a find a GUI for it or any instructions. I would simple like to take the makemkv mvc file and shrink it down with burned in subtitles. Is this possible?

[tijgert]

I read a lot of problems with this transcoder.
I use DVDfab to shrink 3D movies. The problem with that is that the output size can only be set at either BD25 or BD50 with some small disc size variations.
The workaround for this to get the proper output size is a little cumbersome but doable.

1. Rip the 3D movie with MakeMKV.
2. Extract largest audio file as single file as well.
3. Make BD ISO (or file structure) from movie with TSmuxer.
4. Load ISO (or file structure) with DVDfab and set output to BD25 and see what kind of % compression that gives.
5. If you need more compression to obtain your desired file size (animation can be squeezed a lot), mux the extra audio file with MKVtoolnix to moviefile from MakeMKV and make a new ISO with TSmuxer.
6. Repeat step 4 and then 5 until you get the compression ratio you need.
7. Encode.
8. From the encoded ISO extract the movie again with MakeMKV and only select 1 audio stream.

Presto. Smaller 3D movie at the size YOU want.

[robl45]

What do you do for step two to extract? And what do you do about subtitles?


I read a lot of problems with this transcoder.
I use DVDfab to shrink 3D movies. The problem with that is that the output size can only be set at either BD25 or BD50 with some small disc size variations.
The workaround for this to get the proper output size is a little cumbersome but doable.

1. Rip the 3D movie with MakeMKV.
2. Extract largest audio file as single file as well.
3. Make BD ISO (or file structure) from movie with TSmuxer.
4. Load ISO (or file structure) with DVDfab and set output to BD25 and see what kind of % compression that gives.
5. If you need more compression to obtain your desired file size (animation can be squeezed a lot), mux the extra audio file with MKVtoolnix to moviefile from MakeMKV and make a new ISO with TSmuxer.
6. Repeat step 4 and then 5 until you get the compression ratio you need.
7. Encode.
8. From the encoded ISO extract the movie again with MakeMKV and only select 1 audio stream.

Presto. Smaller 3D movie at the size YOU want.

[r0lZ]

You can extract the audio from the original BD with tsMuxeR, or from the MKV created at step 1 with mkvtoolnix and gMkvExtractGUI.

Unless you want to keep a lot of subtitle streams, they are light enough to be ignored for the computation of the final file size. Just include them in the MKV in step 1. IMO, the major drawback with that method is that the 3D-Planes are lost during the re-encoding, and therefore the subtitles will not appear at the correct depth.

[tijgert]

Extracting any single stream, be it subs, audio or video, can be done with tsMuxer, but also mkvextractgui (I believe there are two forks or something, 1.6.4.1 and 2.2.2.9).
All the original and important streams are ripped in the first pass with MakeMKV, so subs should be at proper depth.

Theoretically you could and any old stream to the mux to enlarge the file and influence the compression ratio, but using the same movie's stream avoids any type of mismatch with length or bitrate or resolution or what not.

[geheim]

Hi,
I have a problem encoding with FRIM. If I encode files with FRIM via commandline the output shows many artefacts on Stereoscopic Player and after muxing to BD with TSMuxer on my Sony BDP.
Does anyone have an idea what the problem could be??

This is an example command-line I use:

FrimDecode -ts -i:h264 00800_3D.m2ts -o \\.\pipe\bdrb.yuv -sw |FRIMEncode -alt 2 -i \\.\pipe\bdrb.yuv -viewoutput -o::mvc "L:\zzz\VID_00000.AVS.264" "L:\zzz\VID_00000.AVS.mvc" -sw -w 1920 -h 1080 -f 23.976 -u 3 -cpbsize 3372 -l 6 -profile high -level 4.1 -vbr 35000 35000 -gop 24 4 0 O -maxdpb 4

Is there any error??

The artefacts are in both base and dependent view, but mostly in dependent view. I don't know what I'm doing wrong.

Any help would be appreciated!
Thanks!

[r0lZ]

Artefacts were frequent in old versions of the Intel decoder. The bug is fixed now, but if you have the right CPU and you are using an old Intel driver, it might be the culprit. Try to update your drivers or switch to software mode.

Note that this applies to the decoder. I don't know if the encoder has or had the same problem. And, IIRC, the artefacts of the MVC decoder were present in the dependent view only.

[geheim]

Thanks @r0lZ!
I do not have an Intel CPU, therefore I'm already using Software mode.

Interesting is that FRIM works fine for me if I encode BD50 to BD25 with BD-Rebuilder. However it is also not working if I encode SBS MKV to MVC with BDRebuilder.
As I want to hardcode subtitles on my MVC encodes (in order to Keep depth), I can't use BDRebuilder.

I encode to Alternate MKV with hardcoded Subs using your great tool BD3D2MK3D and now I wanted to encode this file to MVC using FRIM. This gives me the artefacts, I tried both FrimSource and FRIMDecode and also DircectShowSource (via avs2yuv). Everything gives me those artefacts....

If anyone has any further ideas I'd really appreciate it :)