ABR encoding issues

[mparade]

After testing some of (15 pcs) my BD 3Ds' main feature AVC streams I realized that FRIM Encoder does have encoding problems (part of the pictures in a scene starts blocking) even at twice the bitrate of an CRF=18 encode (which was a starting point for me as a visually sufficient encode) at the very hard to encode scenes. Such a BD 3D was e.g. How to train your dragon 3D. The blackish dragon's head starts blocking in the middle of the scene which is more than eye-catching on my not so big Fujitsu monitor...

According to my PSNR tests these visual differences between ABR and CRF method might be valid. (There are gaps between the overall PSNR values).

Did anyone else realize similar issues?
I wish BD-RB ever had an MVC encoder using CRF....:eek:
I wish full SBS were BD 3D compliant sometime....:eek:

[SquallMX]

It's not only the ABR thing, QuickSync is just bad.

Yes, even the crappy (hacked?) x264 version with 3D support from DVDFab produces better results (High Quality Mode) and it also uses ABR.

Too bad that it fails half of the times for completely random and weird reasons.

I recently compared both encoders, using the 3D version of Need for Speed, where FRIM/QS produces awful macro-blocking during complex scenes DVDFab encoder creates an acceptable result, not transparent, but far better than QS.

[mparade]

It's not only the ABR thing, QuickSync is just bad.

Yes, even the crappy (hacked?) x264 version with 3D support from DVDFab produces better results (High Quality Mode) and it also uses ABR.

Too bad that it fails half of the times for completely random and weird reasons.

I recently compared both encoders, using the 3D version of Need for Speed, where FRIM/QS produces awful macro-blocking during complex scenes DVDFab encoder creates an acceptable result, not transparent, but far better than QS.

I have got the result described above using BD-RB with the options as follows:

FRIM_SW_DECODE=1;
FRIM_SW_ENCODE=1;
I do not have a PC that is Intel Quick-Sync enabled;

So, my results have nothing to do with Quick-Sync...:scared:

[Sharc]

@mparade
What is your target size? You can't expect good results with 3D Frim on BD5. BD9 is minimum, BD25 is recommended for a 90+ minutes movie. 3D requires almost 2x the size of 2D because of the AVC and MVC streams. But still, the Intel/Frim encoder is inferior to x264, especially at low bitrates like those required for BD9.

Edit:
You may also try to add
AUTO_BIAS=3 in the .ini in case you encode with "Automatic Quality Settings".

[mparade]

@mparade
What is your target size? You can't expect good results with 3D Frim on BD5. BD9 is minimum, BD25 is recommended for a 90+ minutes movie. 3D requires almost 2x the size of 2D because of the AVC and MVC streams. But still, the Intel/Frim encoder is inferior to x264, especially at low bitrates like those required for BD9.

Edit:
You may also try to add
AUTO_BIAS=3 in the .ini in case you encode with "Automatic Quality Settings".

My target size is always custom at the moment for 3D projects due to testing purposes. (Upto now, I do not think I can use generally FRIMEncoder for my 3D projects for quality and encoding efficiency reasons).

As for my quality settings: the best both for x264 and Frim to be fair. (however it is still not so fair comparing CRF to ABR)

My problem with Frim:

Extract the AVC stream for the main movie of a 3D movie (e.g. How to train your dragon BD3D) with TSmuxer into a BD structrured folder.

You will get a 15GB m2ts. Encode this "original" AVC stream
with BD-RB using x264 CRF=18 with quality maximized out.
You will get a 5.6GB file which is visually sufficient and not blocking at all anywhere through the video. You can do a PSNR comparison also with the original 15GB file just to see the "maths" behind. You will get an overall PSNR of around 48.5.

Encode the "original" AVC stream
with BD-RB using FrimEncode ABR 1-pass with quality maximized out and give a custom file size of let us say
11.2GB. (so simply double the bitrate).

You will get a file which is not visually sufficient and starts blocking at some segments of the frames at specific scenes within the video. (If you are really concerned and have the BD mentioned above I can let you know the part which is "eye-catching" in a negative sense). You can do a PSNR comparison also with the original 15GB file. You will get an overall PSNR of around 45-46, however the average PSNR will probably exceed the one of x264 encode.

Upto now, I haven't talked about any 3D and I have got a ~11.2GB file for a ~90 minutes movie using FrimEncode which is visually not sufficient for me. Add HD audio, menu, MVC, extras...I think the best way to stay with the original material instead of FRIM until a better encoder will be available. :scared:

[Sharc]

@mparade
Oh I see you compare on pure 2D (AVC) basis and get some blocks at even double average bitrate with FRIM.
Well, as you write, there is still no free alternative to the Intel/FRIM encoder for MVC 3D AFAIK. The 3D fork of x264 seems not to have developed further after some initial efforts some time ago.

[mparade]

@mparade
Oh I see you compare on pure 2D (AVC) basis and get some blocks at even double average bitrate with FRIM.
Well, as you write, there is still no free alternative to the Intel/FRIM encoder for MVC 3D AFAIK. The 3D fork of x264 seems not to have developed further after some initial efforts some time ago.

Correct. I do not really know why is it so problematic for x264 developers to include an encoding option for MVC (Dark Shikari could answer this, I think) stream. In my opinion "maths", efficiency, visual quality says that CRF is the way to go for 3D encoding, either. Until then, I will be very happy with the results of my BD-RB 2D encodings.

[frank]

FRIM based on Intel's Media SDK, and the SDK has a lot of bugs (blockiness, crash, memory holes...)
The source of blockiness in some frames is the faulty DECODER, not the encoder.
Test 3D MVC decoding with FRIMdec, Avisynth and VirtualDub, but you cannot search, only play from start.
There are more movies with this problem, e.g. Pacific Rim.
If you use both components, FRIM decoder and FRIM encoder the whole is even more instable. Using x264 for 3D HSBS/HTAB encoding is more stable. (->BD3D2MK3D)
Until now Intel has not solved the problem, and ignores messages from users.
The use of Intel Media SDK is NOT reliable.

CoreMVC 3D video decoder from CoreCodec works fine but is not free. It is used in Stereoscopic Player.