View Full Version : Unable to transcode above 20Mbps?


Brad Hebert
April 14th, 2017, 11:19 AM
I have a .mov MPEG-4 at 393Mbps. I want to transcode it to a .mp4 h.264 at 30Mbps, but the highest I can get is around 20Mbps. I have tried VBR and CBR, and I've even cranked the bit rate slider up over 100Mbps. I have tried using Adobe Media Encoder and MPEG Streamclip. Can someone explain this?

Gary Huff
April 14th, 2017, 11:29 AM
You have cranked the slider up to 100Mbps? Then how do you know it's not going over 20Mbps if you can move the bitrate slider well past that point?

Brad Hebert
April 14th, 2017, 11:35 AM
You have cranked the slider up to 100Mbps? Then how do you know it's not going over 20Mbps if you can move the bitrate slider well past that point?

I check the specs on the transcoded file.

Mark Williams
April 14th, 2017, 12:37 PM
Brad,

Brad are you maybe confusing file size with encode bit rate? In other word is your original .mov MPEG-4 file encoded at 393Mbps or is it 393 MB in size? The original may be encoded at a bitrate lower than what you are choosing to re-encode it at.

Brad Hebert
April 14th, 2017, 12:43 PM
Brad,

Brad are you maybe confusing file size with encode bit rate? In other word is your original .mov MPEG-4 file encoded at 393Mbps or is it 393 MB in size? The original may be encoded at a bitrate lower than what you are choosing to re-encode it at.

Here are the specs of the source file (yes, it's intentionally a square video):

Format : MPEG-4

Format profile : QuickTime

Codec ID : qt

File size : 2.76 GiB

Duration : 1mn 0s

Overall bit rate mode : Variable

Overall bit rate : 393 Mbps

Encoded date : UTC 2017-04-13 20:53:04

Tagged date : UTC 2017-04-13 21:03:28

Writing library : Apple QuickTime

©TIM : 00;00;00;00

©TSC : 2997

©TSZ : 100



Video

ID : 1

Format : RLE

Format/Info : Run-length encoding

Codec ID : rle

Duration : 1mn 0s

Bit rate mode : Variable

Bit rate : 391 Mbps

Width : 1 080 pixels

Height : 1 080 pixels

Display aspect ratio : 1.000

Frame rate mode : Constant

Frame rate : 29.970 fps

Color space : RGB

Bit depth : 8 bits

Scan type : Progressive

Bits/(Pixel*Frame) : 11.199

Stream size : 2.74 GiB (100%)

Language : English

Encoded date : UTC 2017-04-13 20:53:04

Tagged date : UTC 2017-04-13 20:53:04



Audio

ID : 2

Format : PCM

Format settings, Endianness : Little

Format settings, Sign : Signed

Codec ID : sowt

Duration : 1mn 0s

Bit rate mode : Constant

Bit rate : 1 536 Kbps

Channel(s) : 2 channels

Channel positions : Front: L R

Sampling rate : 48.0 KHz

Bit depth : 16 bits

Stream size : 11.0 MiB (0%)

Language : English

Encoded date : UTC 2017-04-13 20:53:04

Tagged date : UTC 2017-04-13 20:53:04



Other

ID : 3

Type : Time code

Format : QuickTime TC

Duration : 1mn 0s

Time code of first frame : 00:00:00;00

Time code, striped : Yes

Language : English

Encoded date : UTC 2017-04-13 20:53:04

Tagged date : UTC 2017-04-13 20:53:04

Seth Bloombaum
April 14th, 2017, 05:37 PM
There are a few possibilities. Support for atypical aspect ratios can be spotty. A QT MOV/mpeg-4 has its own format limitations, which may have been exceeded with a previous encoder (it may not be a QT-legal file). I don't know much about MPEG Streamclip, but, AME is a bit limited on some of these things.

Before getting into deep testing on any of the above, I'd try Handbrake. It's freeware, and is built on the truly excellent x264 encoder. Typical results would be better than AME.

Note also that setting profile and level on any h.264 encoder can limit max bitrate. Here's a chart. (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels) Most encoders will respect the allowable bitrate for a particular profile and level. In some encoders profile and level settings may not be clear.

Pete Cofrancesco
April 15th, 2017, 07:06 AM
Echo what Seth said.
1. Handbrake
2. Your goal is good looking video at a reasonable file size. Take a short segment and encode at different bit rates, you might be surprised higher bit rate might not look better.

I also caution you about going overboard with highest bitrate. It might not play on a clients device/computer. Bigger isn't always better.

Brad Hebert
April 15th, 2017, 08:13 AM
Echo what Seth said.
1. Handbrake
2. Your goal is good looking video at a reasonable file size. Take a short segment and encode at different bit rates, you might be surprised higher bit rate might not look better.

I also caution you about going overboard with highest bitrate. It might not play on a clients device/computer. Bigger isn't always better.

In this case, my goal is to meet a spec required by a distributor. They want a mezzanine/master file.

We are able to use FFmpeg directly to achieve 30Mbps, but we want a GUI that anyone can use.

Gary Huff
April 15th, 2017, 10:26 PM
I check the specs on the transcoded file.

What did you use to check the specs? What file size was it? If you set it to 10Mbps, does the file size remain the same? Is it slightly larger? Smaller?

Pete Cofrancesco
April 16th, 2017, 04:10 AM
In this case, my goal is to meet a spec required by a distributor. They want a mezzanine/master file.

We are able to use FFmpeg directly to achieve 30Mbps, but we want a GUI that anyone can use.
You are encoding using variable bitrate so you a can pick an average or in some software a minimum/maximum. Depending on the complexity of the scene the rate will change. You can instead use constant bit rate (CBR) and it won't change but like I said it's not an efficient use of bitrate.

Gary Huff
April 16th, 2017, 07:13 AM
You are encoding using variable bitrate so you a can pick an average or in some software a minimum/maximum. Depending on the complexity of the scene the rate will change. You can instead use constant bit rate and won't change.

Except in the original post, he does explicitly mentioned that he tried both:

the highest I can get is around 20Mbps. I have tried VBR and CBR

Andrew Smith
April 16th, 2017, 11:25 AM
Another possibility is that the encoder has run out of video image detail that it requires data for the encoding of. Being a well behaved encoder, it would therefor only use as much data in the finished file as it actually required (still essentially working within the data rate ceiling) and not any filler data.

Andrew