Calculation of Export in MP4

[Haddock]

Hello,

Simple question : I have to export a HD film in mp4 via Wetransfer.

The film is destinated to a copywritter to verify the good use of the language commentary. So he has not to have a top quality of image because he will probably watch the film on his computer. 1920*1080 is not a must (1280*720 may be enough)

For a free service Wetransfer is limited to 2 GB.

My film is 80 minutes long.

Is there a way or a formula to calculate the transfer rate to stay under 2GB for the 80 minutes total... taking also into account 1920 or 1280.... ?

Thanks already

[GrassValley_SL]

There are some file size calculators available which can give you an indication. (google)
You can use google drive for bigger files. Or get wetransfer plus
with which you can send 20 GB .

[BernH]

It's a relatively simple bit of math, but there are a couple of things to remember before doing the math.

1. A file's bitrate dictates it's size, not it's frame size. This means a given bitrate will make a file look worse at larger frame sizes, because bitrate is bit/second, meaning the same amount of data is used per second regardless of frame size if the bitrate remains the same, it just gets divided by a larger number of pixels.

2. For this kind of math we use 8bit data words (8bits=1Byte), and all the calculations have to be done with the same measurement, either bits or Bytes, but not mixed

3. conversion from Bytes to Mega to GigaBytes are factors of 1000 in each step or 1024 for Mebi/GibiBytes.

4. 60 minutes to an hour and 60 seconds to a minute.

5. Bitrates are measured in bits/second (usually Megabits or Kilobits), file sizes are measures in Bytes

Now the math:

formula: bitrate x duration = file size

Your duration is 80 minutes or 4800 seconds (80min x 60)

Your desired file size is 2GB or less, or in bits it is 16Gb (2GB x 8 to convert to bits), or 16000Mb (16Gb x 1000), we will use Mb, as it is a more common bitrate measure

Substituting these numbers into the formula makes it look like this:

bitrate x 4800 = 16000Mb

now we solve for the bitrate with simple math by dividing the file size in Mb, by the duration in seconds, to get a Mbps.

16000/4800 = 3.33333 Mbps

To allow for some error I would alot a 10% to 15% buffer on the number, meaning your maximun bitrate should be in the 2.8 to 3 Mbps area, but you can indeed go less. If you are outputting 1280x720, these files can often look acceptable at bitrates down as low as 1.2Mbps, depending on the encoder, content, motion, noise, and of course what is acceptable for your purpose.

[Haddock]

There are some file size calculators available which can give you an indication. (google)
You can use google drive for bigger files. Or get wetransfer plus
with which you can send 20 GB .

Thanks Steve

[Haddock]

It's a relatively simple bit of math, but there are a couple of things to remember before doing the math.

1. A file's bitrate dictates it's size, not it's frame size. This means a given bitrate will make a file look worse at larger frame sizes, because bitrate is bit/second, meaning the same amount of data is used per second regardless of frame size if the bitrate remains the same, it just gets divided by a larger number of pixels.

2. For this kind of math we use 8bit data words (8bits=1Byte), and all the calculations have to be done with the same measurement, either bits or Bytes, but not mixed

3. conversion from Bytes to Mega to GigaBytes are factors of 1000 in each step or 1024 for Mebi/GibiBytes.

4. 60 minutes to an hour and 60 seconds to a minute.

5. Bitrates are measured in bits/second (usually Megabits or Kilobits), file sizes are measures in Bytes

Now the math:

formula: bitrate x duration = file size

Your duration is 80 minutes or 4800 seconds (80min x 60)

Your desired file size is 2GB or less, or in bits it is 16Gb (2GB x 8 to convert to bits), or 16000Mb (16Gb x 1000), we will use Mb, as it is a more common bitrate measure

Substituting these numbers into the formula makes it look like this:

bitrate x 4800 = 16000Mb

now we solve for the bitrate with simple math by dividing the file size in Mb, by the duration in seconds, to get a Mbps.

16000/4800 = 3.33333 Mbps

To allow for some error I would alot a 10% to 15% buffer on the number, meaning your maximun bitrate should be in the 2.8 to 3 Mbps area, but you can indeed go less. If you are outputting 1280x720, these files can often look acceptable at bitrates down as low as 1.2Mbps, depending on the encoder, content, motion, noise, and of course what is acceptable for your purpose.

This is a big answer with all parameters.... waouh, I did not expect so much details but it is welcome ... it gives tools for the future.

The most interesting is first to convert first in seconds both side 2000*8 and 80'*60... and this give a precize calculation. I like also the prudency of staying 10 to 15 % under the result.

Thanks 2000*8

[kpot]

It's a relatively simple bit of math, but there are a couple of things to remember before doing the math....

Hi BernH:
One question:
In order to be very accurate, would one have to calculate the data rate for the audio part separately and subtract it from the data rate of the video?
Regards kurt

[BernH]

Hi BernH:
One question:
In order to be very accurate, would one have to calculate the data rate for the audio part separately and subtract it from the data rate of the video?
Regards kurt

Yes, you would if you want to calculate very accurately what bitrate you can use for each stream in the file.

The formula I gave is for the overall bitrate as it relates to file size. If you want extreme accuracy, you need to do the same calculations for audio and video, and also the amount of data used for the wrapper/container.

In order to do this, you need to decide on what audio compression you are using and the number of audio channels, subtract that from the overall bitrate and the remainder is what you can use for video, minus a small amount for the wrapper/container. (or vice versa if, by some strange method, the bitrate on the audio is flexible but the bitrate on the video is not.)

It is probably easier and close enough to encode a minute of audio/video so you can have look at/listen to the quality, and if it is acceptable then multiply by your duration in minutes to get a fairly accurate estimation of file size.

Usually that 10% to 15% buffer I mentioned is adequate to handle the audio and container, but the test export of 1 minute with the multiplication by duration will confirm.

[kpot]

... It is probably easier and close enough to encode a minute of audio/video so you can have look at/listen to the quality, and if it is acceptable then multiply by your duration in minutes to get a fairly accurate estimation of file size ...

I would prefer the above ;-)
Thanks for your answer - kurt

[BernH]

I would prefer the above ;-)
Thanks for your answer - kurt

Me too ;-)

Though I would do the overall bitrate calculation to get your first 1 minute test in the ballpark.

Once you do it a few times, you can forgo the calculation as long as you remember what bitrate worked for that 1 minute test encode to get you at your target file size for a given duration.

If you routinely have to deliver files around a given duration, such as 90 minutes, you could use the same setting for anything up to that duration and you would be safe, as long as the quality is good for the purpose.

[antonsvideo]

here is what I would do:

1. mark in and out on 80min timeline
2. open diskburner and go to movie tab and reduce video bitrate until total space needed is less than 2GB
3. remember the video and audio bitrate value for your mp4 export

https://www.videoproductions.com.au/edius90/bitrate-calculation.png

[BernH]

here is what I would do:

1. mark in and out on 80min timeline
2. open diskburner and go to movie tab and reduce video bitrate until total space needed is less than 2GB
3. remember the video and audio bitrate value for your mp4 export
https://www.videoproductions.com.au/...alculation.png

Thats a good tip about using the disk burner to calculate. I personally never use it, as I prefer doing my disc authoring in actual authoring software like Encore, so it never occurred to me to just use it as a calculator for MP4/H264

However, knowing the way the math works can be beneficial if you are using a different encoder that will not give you an estimated file size.

I use Edius at home, but at work I am faced with Media Composer, Episode, Resolve, Compressor, Mistika, Sorenson Squeeze, and a few other potential encoders, which don't always give estimated sizes. Additionally, I am not always encoding MP4/H264/MPEG2-IBP, so a lot of the online calculators are relatively useless, unless I can customize the bitrate settings. This is where knowing the basics of the math can help.

I personally think that anyone who is doing encoding should be able to estimate a file size in this method.

As long as you can tell time (knowing that there are 60 seconds/minute and 60 minute/hour), and know the bits<-->Bytes factor of 8 and Kilo<-->Mega<-->Giga factor of 1000 conversions, it is a simple calculation, that can be done in a few seconds. Of course there are also some calculators available for iPhones/Android Phones, but once again, if they don't have the predefined bitrates and don't allow custom settings, doing the math yourself is easy.

I have used this at work when estimating a ProRes encode from a Linux/Resolve system to discover that ProRes from ffmpeg is larger than ProRes from Apple's Quicktime (by about 15% if I recall correctly). After doing some testing, I also discovered that ProRes from the beloved but now defunct Miraizon encoder is almost identical in size to Apple's ProRes, and was the only one out of 3 or 4 Non-Apple ProRes encoders that I tested that i would be comfortable in calling ProRes based on the file size. Without having an idea of how big a file should turn out, I would not have noticed this. (This was a few years ago, so I don't know if the newer versions of ffmpeg are any closer)

[kpot]

here is what I would do:

1. mark in and out on 80min timeline
2. open diskburner and go to movie tab and reduce video bitrate until total space needed is less than 2GB
3. remember the video and audio bitrate value for your mp4 export
https://www.videoproductions.com.au/...alculation.png

"As You Like It" (Shakespeare).
So now both - arithmeticians and practitioners - have nice methods to reach their goals.
As I have already mentioned, I will follow Antons practical version
(because I studied mathematics a few decades ago and there are other interesting areas in this field :-) ).
Thanks Anton!
kurt

[Haddock]

here is what I would do:

1. mark in and out on 80min timeline
2. open diskburner and go to movie tab and reduce video bitrate until total space needed is less than 2GB
3. remember the video and audio bitrate value for your mp4 export
https://www.videoproductions.com.au/...alculation.png

Very, very, very clever Anton. In fact with this method we have an integrated calculation system.

Just a question to be more aware... This is for CBR.
Can we expect a beter quality result in VBR ?.... and is your method also reliable....

In other words, is the codec calculated for BD-R/RE exactly the same then the one stored by MP4 ?

General remark. Thanks to all people involved in this question, I did not expect so much interest....

[BernH]

Very, very, very clever Anton. In fact with this method we have an integrated calculation system.

Just a question to be more aware... This is for CBR.
Can we expect a beter quality result in VBR ?.... and is your method also reliable....

In other words, is the codec calculated for BD-R/RE exactly the same then the one stored by MP4 ?

General remark. Thanks to all people involved in this question, I did not expect so much interest....

VBR file size can not be calculted, it can only be estimated based on the target bitrate. This is because VBR, which stands for Variable Bit Rate, allows the bits per second to change depending on the requirements of the content on a frame by frame basis. If you have an average video that you encode at 3Mbps VBR, it will probably stay close to your targets, but a video that is just a talking head will turn out smaller, as it may allow the bitrate to drop to less that 1Mbps if there is no motion that requires the extra bitrate. Conversely a high motion video will turn out larger that you estimate.

VBR tends to give equal quality at a smaller file size, or better quality at an equal file size

In either case, the codec, storage medium, frame size, etc are irrelevant to the file size calculation. The formula (bitrate x duration = filesize) works on any codec and any frame size. The difference is if it is a finite calulation (CBR) or an estimate (VBR). The reason it is codecs or frame size irrelevant is simple:

Bytes are made from bits, and minutes are made from seconds. The bitrate (bits per second) dictates how many bits are used to store 1 second of video regardless of frame size. It has no provision for frame size, container or storage medium in the equation. Yes larger frame sizes make larger files, but this is because they usually require more bits to store that given 1 second of video.

To better illustrate this point, let's consider Standard Definition DV video versus High Definition HDV video. Everything about them, (medium, bitrate, and file sizes) are the same except frame size and codec used.

DV is 720x480 NTSC or 720x576 PAL at approximately 25Mbps (hence the DV25 name sometimes used to describe it)
HDV is 1440x1080 at approximately 25Mbps
Both formats use the same storage medium. (mini-DV tape)
Both formats create files of about the same size (around 1GB/5 Minutes) because the file size is dictated by the bitrate.

The reason that the HDV is higher resolution and quality is because the codec/compression is more efficient and can encode around 4 times as many pixels using the same bitrate. If you were to encode the SD footage with the same kind of codec used for the HDV footage you would get a file 1/4 or less in size.

The codec in this regard dictates how efficiently a given bitrate can be used, allowing larger frame sizes to be stored, but does not dictate the bitrate itself, aside from any maximum/minimum bitrate limits that the codec supports.

[Haddock]

Well Bern, this is very interesting.... long but relevant.

I will try to digest your informations.

To respect the final volume desired of the file (less then 2GB), I have to precize the average bitrate (based on the CBR that fits this limit).

I only have to expect a beter quality in VBR if the lowest value (used for simple text on black background) can recuperate enough place to be used at other place by the higher value.

Don't dream