Strange Blu-ray Encoding Problem using AME

[SameSelf]

I don't know if Jeff Bellune is a member of this forum, but his tutorial for encoding for Encore BD compliant H.264 is truly awesome! Given all the tweaks needed to ensure that Encore accepts it without triggering the transcode flag, I would have never been able to figure out all those tweaks on my own. Plus, my encoded video didn't exhibit the problem I was having when using AME that I reported in my OP. And, I was able to encode at close to 30 fps! So I am saying goodbye forever to AME.

http://bellunevideo.com/tutvideo.php?tutid=18

[_Al_]

I don't know if Jeff Bellune is a member of this forum, but his tutorial for encoding for Encore BD compliant H.264 is truly awesome! Given all the tweaks needed to ensure that Encore accepts it without triggering the transcode flag, I would have never been able to figure out all those tweaks on my own. Plus, my encoded video didn't exhibit the problem I was having when using AME that I reported in my OP. And, I was able to encode at close to 30 fps! So I am saying goodbye forever to AME.

http://bellunevideo.com/tutvideo.php?tutid=18

that command line in that tutorial is pretty much the same as here: http://www.x264bluray.com/home/1080i-p ,
he just added: --b-adapt 2 --ref 4

another thing, he is exporting RGB 24 from Premiere, and not some YUV, as original video is, maybe he color corrects his video or uses filters that work in RGB, but if not, why not export directly YUV, so you have only YUY2 to YV12 conversion and you do not go through RGB unnecessarily

[SameSelf]

that command line in that tutorial is pretty much the same as here: http://www.x264bluray.com/home/1080i-p ,
he just added: --b-adapt 2 --ref 4

another thing, he is exporting RGB 24 from Premiere, and not some YUV, as original video is, maybe he color corrects his video or uses filters that work in RGB, but if not, why not export directly YUV, so you have only YUY2 to YV12 conversion and you do not go through RGB unnecessarily

That is very interesting. My knowledge of colorspace is very limited. I checked my source video and it is YUV per Mediainfo (however, I have learned to be cautious of what it says). Neither of the options available in the frameserve are YUV, just YUY2 and UYVY, unless one those FourCCs is YUV. Quoting Mr. Bellune from his tutorial:

Choosing any of the non-RGB colorspace options will add an extra and unnecessary conversion to this process.

Therefore, it sounds like he does this regardless of whether he adds RGB filters or not. Are you saying this is incorrect and I should choose one of the other options? If so, which one?

As for --b-adapt 2 --ref 4, are those necessary? What do they do? Thanks!

[SameSelf]

Lemme see if I can answer my question myself. From the FourCC Wiki:

YUY2: YUV 4:2:2 as for UYVY but with different component ordering within the u_int32 macropixel.
UYVY: YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32.

Here is my Mediainfo output below. So I guess it doesn't matter whether I choose YUY2 or UYVY since I have YUV 4:2:2. But then, maybe it does? Anyhow, very interested to know if Mr. Bellune's advice is correct and that RGB should be used, not the YUV options.

Video
ID                                       : 2
Format                                   : ProRes
Format version                           : Version 0
Codec ID                                 : apcn
Duration                                 : 12mn 51s
Bit rate mode                            : Variable
Bit rate                                 : 132 Mbps
Width                                    : 1 888 pixels
Original width                           : 1 920 pixels
Height                                   : 1 062 pixels
Original height                          : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 29.970 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 2.198
Stream size                              : 11.9 GiB (99%)
Writing library                          : atms
Language                                 : English
Encoded date                             : UTC 2000-01-01 00:02:18
Tagged date                              : UTC 2000-01-01 00:02:18
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

[poisondeathray]

"YUV" is a color model (also called YCbCr)

YUY2 and UYVY are 2 different variants of YUV 4:2:2 (ie. 4:2:2 chroma subsampled) . Both fall under the YUV color model. Functionally they are the same, they are just organized differently .

RGB should be used only if you used some RGB filter , or required some RGB operation . Everytime you convert between YUV<=>RGB there is some loss incurred . So it depends on your project specifics .

--b-adapt 2 is for the "smart" b-frame placement . Yes you should use it if you have time, but it's slower and that stage is poorly multithreaded . If you're using "slow" or anything slower as a preset, --b-adapt 2 is already included and can be omitted from the commandline

--ref 4 is 4 reference frames. It's safe to put it in, to make sure it's compatible for BD. The slower presets by default have more reference frames which are illegal for BD at 1080 size

[newpball]

The slower presets by default have more reference frames which are illegal for BD at 1080 size

Well, uh, that eh, obviously makes total sense!

[SameSelf]

"YUV" is a color model (also called YCbCr)

YUY2 and UYVY are 2 different variants of YUV 4:2:2 (ie. 4:2:2 chroma subsampled) . Both fall under the YUV color model. Functionally they are the same, they are just organized differently .

RGB should be used only if you used some RGB filter , or required some RGB operation . Everytime you convert between YUV<=>RGB there is some loss incurred . So it depends on your project specifics .

--b-adapt 2 is for the "smart" b-frame placement . Yes you should use it if you have time, but it's slower and that stage is poorly multithreaded . If you're using "slow" or anything slower as a preset, --b-adapt 2 is already included and can be omitted from the commandline

--ref 4 is 4 reference frames. It's safe to put it in, to make sure it's compatible for BD. The slower presets by default have more reference frames which are illegal for BD at 1080 size

pdr to the rescue again! So, I guess it doesn't matter which one I choose, YUY2 or UYVY, just choose one if I am not using any RGB effects in my timeline. I guess I will be more careful going forward about using RGB effects. The devil is in the details.

I need to start a diary of some sort of all this info I am learning because I am sure that I will forget some of it along the way.

[_Al_]

newpball - instead of that regular BS, you could try that advanced frame server in that video, it might work with Premiere CC. In that video he used that one. http://wedframe.ru/showthread.php?t=1255

[newpball]

newpball - instead of that regular BS, you could try that advanced frame server in that video, it might work with Premiere CC. In that video he used that one. http://wedframe.ru/showthread.php?t=1255

It would be nice if it worked, debug mode frame server is broken for CC (there is a workaround but that one is unworkable).

But if advanced frameserver was designed for CS5 it is almost certain it is not going to work, because different interface architecture.

As far as I know frameserving in CC is still not possible.

[_Al_]

advanced frame server suppose to have some audio issues, but that should not be a problem, all it matters here is to get a video stream out and encode it ...