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