FFMPEG - How to detect correct params for different videos?

[asterixvader]

I was trying to find commands to do a nice conversion to flv or mp4 with FFMPEG that keeps quality and reduces file size, and found this: http://flowplayer.org/forum/7/12671

I tried the params in the first reply to convert some videos and it worked wonderfully, until I tried to convert videos from YouTube (just for testing, to see what happens). I it took a lot of time and the size of the output file increased instead of going down. So realized the obvious: I can't use the same params for all videos.

I tried to find differences between the first videos I converted against the videos from YouTube, and the only relevant difference I noticed is that the first videos have "Format settings, CABAC: No" according to the MediaInfo provided by Media Player Classic, while YouTube videos have "Yes". In the output files from conversion, the "No" is turned to "Yes", so I made my first conclusion: when converting YouTube videos, I'm trying to... apply CABAC (? I'm not sure what it is) to a video that already has it, that's why it doesn't work fine.

But then I tried to convert a video I previoulsy compressed with VirtualDub, using Xvid. The MediaInfo didn't mention anything about CABAC in this file, but it had the same behavior than YouTube videos, it took a while to convert and the size increased. Second conclusion: I can't convert (and compress) an already compressed video. The first videos I tried to compress, and that did compress nicely, weren't heavily compressed (it says "h264 (Main)", after compression it says "h264 (High)"), so yeah.

Aaand all this makes me wonder, is there a way to tell the correct parameter for different videos? How can I tell if a video is already... highly compressed?

[v491138]

For what you seem to want to do, I use Tipard Studio. Friends love the results.
I am NOT in the same class as others here, but no complaints has to count for something. <G>

[Baldrick]

You check the file size compared the running time or the video bitrate to see if it's heavily compressed. But ALL youtube videos are already heavily compressed.

What is your goal with this?

[jagabo]

-b 1600k

file size = bitrate * running time

If you want a smaller file, use lower bitrate.

[asterixvader]

@v491138, I need command line.

@Baldrick, yeah I was only testing the params with different videos, I'm not trying to re-compress videos from YouTube.

Okay so... I'm not sure how to do the math.

Bitrate * running time = uncompressed filesize?

I have this video:
Overall bit rate: 3147 kbps
Duration: 16m 0s
File size: 360mb

file size = 3147 * 960 = 3021120 / 1024 = 2950.31mb ?

If this is the uncompressed filesize, then the standard filesize (360mb) is 12% of the uncompressed size.
That would mean the video's been compressed 88% ?
And if that's correct, I could do this to check how much videos have been compressed?
I just tried this with some videos and all of them, highly compressed and not, drop 88% of compression.

I believe I'm doing something wrong here.

[poisondeathray]

no

filesize = bitrate x running time

It's just simple math. That says nothing about quality or compression.

There is no "standard" file size. Compression is a relative term; it's always in comparison to a source file

You use your eyes, if it looks like crap, it's crap

Garbage in = Garbage out

[Gavino]

Bitrate * running time = uncompressed filesize?

The bitrate refers to the output file (how could it be anything else?), ie compressed size.

Overall bit rate: 3147 kbps
Duration: 16m 0s
File size: 360mb

file size = 3147 * 960 = 3021120 / 1024 = 2950.31mb ?

If this is the uncompressed filesize, then the standard filesize (360mb) is 12% of the uncompressed size.
That would mean the video's been compressed 88% ?
And if that's correct, I could do this to check how much videos have been compressed?
I just tried this with some videos and all of them, highly compressed and not, drop 88% of compression.

I believe I'm doing something wrong here.

Yes, your calculations are out by a factor of 8.
Bitrate is measured in bits, while file size in bytes: - 1byte = 8 bits.
2950.31 / 8 = 360 MB approx.

[asterixvader]

2950.31 / 8 = 360 MB approx.

Yeah, that's exactly the size of the file. Gonna go do some more testings...

Is there a guide somewhere that explains the relation between bitrate and filesize and this stuff?


@Gavino down there.
Yeah, I knew I had to do something with 8, since it says bits, but I didn't know where.

[Gavino]

I just explained that.
The calculated file size is 2950 megabits.
Divide that by 8 to convert to bytes and you get (roughly) 360 megabytes, which is the same as the actual size.

Your calculations for other files also had the same error, giving a result 8 times bigger than it should.
This led you to think that the calculated size was the uncompressed size, when it is actually the compressed size. It also explains why you always found the same ratio (1/8).

So the relationship is quite simple.
Filesize (bytes) = bitrate (bits/s) * running time (secs) / 8

[asterixvader]

You check the file size compared the running time or the video bitrate to see if it's heavily compressed.

What would I do in this case:

I got 2 videos. They're the same videos, but one has the resolution reduced to 50%.

The bitrate is the same, both are compressed, but the filesize differs.

How would I know they're compressed, if I'm only checking the filesize and length of the videos?

[poisondeathray]

You check the file size compared the running time or the video bitrate to see if it's heavily compressed.

What would I do in this case:

I got 2 videos. They're the same videos, but one has the resolution reduced to 50%.

The bitrate is the same, both are compressed, but the filesize differs.

How would I know they're compressed, if I'm only checking the filesize and length of the videos?

Not possible.

If the bitrate is the same, the filesize is the same, assuming they are the same videos (same duration)

You already know they are compressed. Uncompressed filesizes are many many times larger

Use mediainfo view=>text and it will identify the type of compression e.g. h.264, xvid

[jagabo]

Note that many programs only read the header information when reporting bitrates. That value may not reflect the true average bitrate of the video. It may be the max bitrate, or something else. Bitrate Viewer is pretty good about reporting true average bitrates for a variety of containers and codecs. And don't forget there's audio too.

file size = (average audio bitrate + average video bitrate) * running time

Usually the audio is at a much lower bitrate than the video so it can be ignored for a quick dirty calculation. But not always. Then there's different container overhead, subtitles, chapter tables, etc. Again, those are usually pretty small.

[asterixvader]

If the bitrate is the same, the filesize is the same, assuming they are the same videos (same duration)

Well, the resolution also plays a role in file size right? Bigger images occupy more space.

These 2 videos are exactly the same (same length, same compression method and everything) but one had the resolution reduced, one ended up being a 38.2mb file, and the other one a 13.5mb file. So I was saying... with only the filesize + running time you can't tell if a video is compressed.

Anyway. I'm working on a website (that uses FFMPEG) that will receive all kind of videos from users that will be processed for compression and conversion. But as you can see I'm not too into videos, so I can't think of a way to know what will be the most accurate parameters to convert those different videos. Applying the params I mentioned on the first post to a video that hasn't been previously heavily compressed will work fine, but what if the user uploads a compressed video? I will end up with a bigger file rather than a smaller file, unless I use different params.

[poisondeathray]

Well, the resolution also plays a role in file size right? Bigger images occupy more space.

Nope. Resolution is independent of filesize

Again,

filesize = bitrate x running time

(Notice, resolution isn't mentioned in the equation)

Now, to maintain a certain level of image quality for a larger resolution, it is true a higher bitrate is required, all other conditions being equal.

These 2 videos are exactly the same (same length, same compression method and everything) but one had the resolution reduced, one ended up being a 38.2mb file, and the other one a 13.5mb file. So I was saying... with only the filesize + running time you can't tell if a video is compressed.

They are compressed, because filesizes will be easily 10x larger if you used uncompressed (i.e. no compression)

The difference in the 2 videos is the bitrate. Look at the equation again.

Anyway. I'm working on a website (that uses FFMPEG) that will receive all kind of videos from users that will be processed for compression and conversion. But as you can see I'm not too into videos, so I can't think of a way to know what will be the most accurate parameters to convert those different videos. Applying the params I mentioned on the first post to a video that hasn't been previously heavily compressed will work fine, but what if the user uploads a compressed video? I will end up with a bigger file rather than a smaller file, unless I use different params.

There is no "accurate parameter". It depends what you mean by that

A better way would be to use CRF or quality based encoding. More complex videos will get higher bitrate, simple content will get allocated lower bitrate accordingly. Use search, this topic is discussed very frequently

[asterixvader]

After checking out about CRF... or CBR... I added/changed these parameters -bufsize 190k -maxrate 500k -minrate 500k and now these params can compress YouTube videos even more, without losing quality. Nice huh? (Again, it's not like I'm gonna re-compress YT videos, I was just testing).

Now I hope I won't have problems compressing what is already compressed....

Thanks everyone who posted here. I still would like to learn more about videos though.

[poisondeathray]

After checking out about CRF... or CBR... I added/changed these parameters -bufsize 190k -maxrate 500k -minrate 500k and now these params can compress YouTube videos even more, without losing quality. Nice huh? (Again, it's not like I'm gonna re-compress YT videos, I was just testing).

Those settings will severely limit bitrate and lower quality, unless the dimensions are very low

Now I hope I won't have problems compressing what is already compressed....

everything you encounter that people upload will already be compressed. You will not encounter uncompressed video. Even the videos before youtube re-encodes them are usually compressed. Even a blu-ray or dvd source is compressed. Everything you usually encounter is compressed

Lossy compression means everytime you re-encode you lose quality

[jagabo]

I added/changed these parameters -bufsize 190k -maxrate 500k -minrate 500k and now these params can compress YouTube videos even more, without losing quality.

Maybe the particular video you tested with didn't look too bad but that's a very low bitrate for anything much more than a VCD source. Try it with a 1080p video. It will look like crap. Even with a DVD rip it won't look great.

And CBR encoding (essentially what you're doing by setting the min and max to the same bitrate) is inferior to VBR encoding (where the encoder can use more bitrate where it's needed most, and less where it isn't needed).

[asterixvader]

Yes, that 500k bitrate will be used for low res videos. For higher dimensions I may use a higher rate, but for now I'm gonna work with low res.
(I just checked that 500k and 190k are too low, I'm gonna increase the values a little...)

I've read CBR is prefered for online streaming, and that's what I'm gonna do.

I'm slowly understanding this stuff. For now this is working and I need something that works (now), so I'm gonna go with this, hehe. I want to learn more about this though, but don't know where.

@poisondeathray I got confused because re-compressing already compressed videos with the first params would output bigger files. I guess it was because the bitrate.

Both replies above mentioned resolution. That means resolution also plays a role in the quest to know if a video is too compressed or not. If 2 videos have the same duration and same bitrate, but one is bigger resolution than the other, then the bigger one is expected to be lower quality. Of course both could have bad quality, but in a perfect scenario...

[poisondeathray]

Yes, that 500k bitrate will be used for low res videos. For higher dimensions I may use a higher rate, but for now I'm gonna work with low res.
(I just checked that 500k and 190k are too low, I'm gonna increase the values a little...)

I've read CBR is prefered for online streaming, and that's what I'm gonna do.

For true rtmp/rtsp streaming, not http progressive download, CBR is preferred. This is only if you have set bandwidth parameters and number of connection that you need exact payload specifics. For regular streaming, it's significantly worse in terms of quality, much less efficient

If 2 videos have the same duration and same bitrate, but one is bigger resolution than the other, then the bigger one is expected to be lower quality. Of course both could have bad quality, but in a perfect scenario...

If by "bigger" you mean larger resolution , yes. Since they have the same bitrate and duration, the filesize will be the same

So yes, if they were derived from the same identical source, and the same generation , the larger dimension video will be lower in quality

[jagabo]

Pretty much every video you find will be compressed. Uncompressed video files are huge. An hour of standard definition (720x480, 30 fps) video is about 112 GB as uncompressed RGB. An hour of full HD (1920x1080, 30 fps) is over 600 GB.

A typical strategy for very low bitrates is to reduce the resolution. In that case you are giving up resolution to get better image quality for what's left.

[asterixvader]

@poison lol, oh man you've confused me again. Then I'll set -maxrate and take out -minrate? As long as it keeps a low filesize with low resolution.

@jagabo yes, it's like images, if you let me, bmp vs jpg.

[jagabo]

Then I'll set -maxrate and take out -minrate? As long as it keeps a low filesize with low resolution.

Normally, you set the average bitrate and leave the min/max at their defaults. You use the min/max settings when you have hardware limitations. Like a cell phone that can't handle high bitrate peaks. Or Blu-ray disc which are limited to about 50,000 kbps.