-
Apple Compressor won’t encode H.264 @ the desired Mbps
Greetings!
First, some system specs:
Comp: Intel Mac 2×3 Ghz Quad-Core Intel Xeon, 8Gb DDR2
Card: AJA Kona3
OS: Mac OSX 10.5.8
FCP: 6.0.6
Compressor: 3.0.5THE PROBLEM: I currently have a client who is requiring a very specific Mbps for his H.264 transcode and we are having problems reaching his desired specs using Compressor. The media source is a SpotTrac encoded NTSC DigiBeta with CC and we originally brought it into our system via SDI from a Sony HD-Cam deck through an AJA Kona3 into our FCP. We used the HD-cam deck as our DigiBeta decks were busy at the time and this was the only deck open. It was encoded as an AJA Uncompressed 8-bit 4-2-2 NTSC QT. After adding a slate, we exported the sequence through Compressor (sequence settings: 720×486, NTSC CCIR 601/DV, 29.97, Lower Field First, Uncompressed 8-bit 4-2-2, 48kHz 24-bit audio) using the following transcode settings:
File Extension: mov
Estimated file size: 40.05 MB
Audio Encoder: AAC, Stereo (L R), 48.000 kHz
Video Encoder:
Format: QT
Width: 720
Height: 486
Pixel aspect ratio: NTSC CCIR 601/DV
Crop: None
Padding: None
Frame rate: 29.97
Frame Controls: Off
Codec Type: H.264
Multi-pass: On, frame reorder: Off
Pixel depth: 24
Spatial quality: 75
Min. Spatial quality: 50
Temporal quality: 50
Min. temporal quality: 50
Average data rate: 8.192 (Mbps)All this seemed well and good, until we played the file in QT Pro and we noticed that it was grainy, the file was smaller than expected (only 16 Mb) and only playing at 1.6 Mbps.
MY QUICK ATTEMPTS @ TROUBLESHOOTING: We have done many projects for this client from Digibeta to H.264 at this bitrate and have not had an issue thus far. So, we began troubleshooting by loading an old project from this same client and encoded a similar length spot from an old Digibeta protection master of the client’s material through SDI from a Sony DigiBeta deck (as opposed to the HD-Cam deck we used previously). We were able to produce an H.264 that played at the proper 8Mbps.
We then decided to try and encode the client’s media again through the Kona3 into FCP this time using the DigiBeta deck as opposed to the SDI from the HDCam deck. The file that we encoded was run through Compressor and this time we received a bit rate of 5.227Mbps. This is still not up the specs required by the client.
Although this 5.227 was acceptable for the client, I still would like to know why I could not transcode the file to the requested bitrate. I was able to encode a test file @ the exact bitrate specified (in this case 8 Mbps) during my troubleshooting, so I know that it is possible to encode an 8-bit uncompressed 4.2.2. file from the AJA Kona to an 8Mbps H.264 through my FCP, but I am at a loss as to why this time things were so inconsistent. As stated, we have done this same project many times before without issue.
As far as variables, the only one I can see at present is that this current tape is SpotTrac encoded while all the others are not. From what I know of SpotTrac encoding, it’s tie to the audio channels should not be having such an adverse reaction on the video signal, so I would be absolutely floored if indeed this is an issue. At present I would rather ask the forums for guidance before continuing my troubleshooting.
Thoughts? Questions?
Thank you for your time.
-Christopher Campbell -
3 Replies
-
[Christopher Campbell] “Width: 720
Height: 486
Pixel aspect ratio: NTSC CCIR 601/DV
Crop: None
Padding: None
Frame rate: 29.97
Frame Controls: Off
Codec Type: H.264
Multi-pass: On, frame reorder: Off
Pixel depth: 24
Spatial quality: 75
Min. Spatial quality: 50
Temporal quality: 50
Min. temporal quality: 50
Average data rate: 8.192 (Mbps) “None of this adds up.
At standard def you don’t need anything like 8Mb/s to achieve a visually lossless picture with H.264.
If you set spatial and temporal quality to be 75/50 (which means nothing really, but in real terms, tells the codec to retain the visual quality of the source, but decide the datarate itself) it will use whatever it requires, nothing more.
In these circumstances, you can’t force a codec to use more data per second than it needs.
Despite what you have experienced with previous encodes, the only way to force a codec to use a certain amount of data per frame or per second, is to use an I-frame only format. and these are generally in the 15, 30 or 50Mb/s arenas.
I regularly encode HD content at 4Mb/s or less and it looks great with H.264.
__________________________________________________________________
Sent from my iPad Nano. -
Thanks, Daniel. That’s a good bit of info.
So as a follow up… is it possible that the files which we previously encoded @ 8Mpbs, were of a higher quality and that is why they encoded at the requested bitrate of 8Mbps? In essence, I am just trying to understand why one file encoded at 5.2 and the other at 8.0. Both were from Digibeta, but the lower quality one had at one point originally been BetaSP while the higher quality one has always been at least Digi-beta quality.
Thoughts?
-
[Christopher Campbell] “is it possible that the files which we previously encoded @ 8Mpbs, were of a higher quality and that is why they encoded at the requested bitrate of 8Mbps?”
No, lower quality content will actually require a higher bit rate.
Lower ‘complexity’ or simple footage is what will require less data.
Simple is stuff like a talking head shot, no camera movement.
Complex is fast moving action with explosions etc or similar__________________________________________________________________
Sent from my iPad Nano.
Reply to this Discussion! Login or Sign Up