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