Jump to content

avi-mp4-mkv question on container and size


Gilgamesh_48

Recommended Posts

Gilgamesh_48

First I am not looking for any recommendations about the containers but rather I trying to understand a few little oddities.

First I will state what brought on this question:
I am doing some conversions and I am using "replace original file" options. The files involved were created many years ago using some software that only wrote avi. Also I tested with the quality set to "Mobil" and with it set to "TV," the behavior is mostly the same.

Link to comment
Share on other sites

Gilgamesh_48
52 minutes ago, Luke said:

Hi, what exactly is the question?

Well the first question is "why did I not ask a question in the earlier post?" I plead "Old Brain Syndrome."

Now the real question is, Is there anything in the container specifications that would cause the mp4 files created from the conversion process to be twice a large as the avi they came from? I do not remember if there are any differences between containers that effect size.

I have not tested this much and I have plenty of storage but it just seems strange that a 500 mb avi file should become a 1 gb mp4.

I am sorry that I did not properly ask the question. I "think" I was still composing and something distracted me and I submitted the post before it was ready. :( "Premature submission" is just another problem to be faced by the aged.😇

Link to comment
Share on other sites

Happy2Play

@Gilgamesh_48 Would need logs from a specific example with logs but see the same as the size almost tripled converting Original Quality.

Hardware Conversion

bitrate: 1124 kb/s

bitrate max/min/avg: 2872488/0/2872488

image.png.ee75efb484e146784aac06bd0cfc3571.png

ffmpeg-transcode-8ab15840-2493-4cd3-91f2-65894ad0412b_1.txt

 

Software Conversion (conversion was actually smaller)

bitrate max/min/avg: 2872000/0/0 buffer size: 5744000 vbv_delay: N/A

image.png.4d23b32292225914d92c2708846deb34.png

ffmpeg-transcode-7c0081e4-97cd-456d-ba27-235395b41cc2_1.txt

So there are Software vs Hardware differences also in the conversion encoding methods also.

-c:v:0 h264_qsv -b:v:0 2872488 -g:v:0 144 -maxrate:v:0 2872488 -bufsize:v:0 5744976 (Hardware)

-c:v:0 libx264 -g:v:0 144 -maxrate:v:0 2872488 -bufsize:v:0 5744976 (Software)

But the FFMPEG gods would have to comment further on why the different methods are used.

image.png

Link to comment
Share on other sites

Doesn't hardware encoding typically favor speed at the expense of quality and file size?

Link to comment
Share on other sites

Gilgamesh_48
8 minutes ago, Happy2Play said:

But the FFMPEG gods would have to comment further on why the different methods are used.

Do they even lower themselves to the point of communicating with us mortals?

But, regardless, I have enough answer. It was not an important question and I am not sure what I was really expecting to learn from this. I think my mind is reaching capacity. I feel like the boy in the Far Side comic where he is sitting in the back of a classroom and raises his hand and says: "Mrs. Brown, can I go home now? My brain is full." ;) :D

Link to comment
Share on other sites

rbjtech

Remember that AVI is just a container.

The real question is what CODEC was used in that container - being AVI, it is likely MPEG4 or Divx.

A conversion from this Mpeg4 to h264 will need an increased bitrate to keep the same comparable quality.   

There is a lifetime of reading over on doom9 as to why - but in summary - this is the price you pay for the 'new' codec.

Link to comment
Share on other sites

Gilgamesh_48
7 hours ago, rbjtech said:

Remember that AVI is just a container.

The real question is what CODEC was used in that container - being AVI, it is likely MPEG4 or Divx.

A conversion from this Mpeg4 to h264 will need an increased bitrate to keep the same comparable quality.   

There is a lifetime of reading over on doom9 as to why - but in summary - this is the price you pay for the 'new' codec.

I do not care much about what the codec is or even about the container that is used but this discussion makes me question if the "new" codecs are really better. Is it really an "improvement" if size must increase to maintain quality? I now have few avi files left on my server but I do wonder if, transcoding aside, if I have gained anything in all the conversions.

But it does not really matter much as my storage space is large and my files are quite watchable but, from what has been said, people could save a lot of space if avi (and the codecs involved) was fully supported in both Emby and various hardware platforms. Of course the "newer is always better" stupidity runs throughout the electronic world.

Link to comment
Share on other sites

Happy2Play

No different than h265 being so compress that if needing converted to h264 the bitrate is doubled to try and maintain quality.

But your issue is the methods Emby uses for conversions as Hardware encodes to specific bitrate (higher) while Software encodes to a maxbitrate (usually equal to or lower).

-c:v:0 h264_qsv -b:v:0 2872488 -g:v:0 144 -maxrate:v:0 2872488 -bufsize:v:0 5744976 (Hardware)

-c:v:0 libx264 -g:v:0 144 -maxrate:v:0 2872488 -bufsize:v:0 5744976 (Software)

So Custom values vs Original quality is probably the key here.

So converting outside of Emby will/could give you different results depending on the code used for the conversion.

Edited by Happy2Play
Link to comment
Share on other sites

my 2cents:

The 'container' only 'really' matters if it supports the codec's and 'tags' ( Ok a bit more but ) that You want.

The codec's control the quality and size..

i.e  ffmpeg will make any container file(s) about +- the same size if the -c copy and all streams are copied is used. 

Edited by TMCsw
Link to comment
Share on other sites

Happy2Play
2 minutes ago, TMCsw said:

i.e  ffmpeg will make any container file(s) about +- the same size if the -c copy and all streams are copied is used.

Yes from a copy/remux standpoint you will be about the same, but Emby Conversion is not doing that.  So ideally one will have to convert outside Emby or possibly used custom variables depending on Hardware or Software conversions.

"Media will be converted for compatibility with all devices, including web browsers. Video files will target MP4 with H264 video and AAC/MP3 audio. Audio files will target MP3."

Link to comment
Share on other sites

  • 3 weeks later...
unisoft
On 16/09/2022 at 00:55, roaku said:

Doesn't hardware encoding typically favor speed at the expense of quality and file size?

Old nvidia graphics card with CUDA is yes, newer cards like 1080ti and above it's no.

Link to comment
Share on other sites

unisoft
On 16/09/2022 at 19:13, rbjtech said:

Remember that AVI is just a container.

The real question is what CODEC was used in that container - being AVI, it is likely MPEG4 or Divx.

A conversion from this Mpeg4 to h264 will need an increased bitrate to keep the same comparable quality.   

There is a lifetime of reading over on doom9 as to why - but in summary - this is the price you pay for the 'new' codec.

I found that if I have a 5mbps h264 file and want to edit a new copy without using intra coding format, it's typically double the original bit rate to keep same quality as in original. That's with at least 4 ref frames set.

Link to comment
Share on other sites

  • 1 month later...
visproduction

Maybe this comparison will make sense. 

Compare encoding media to a painter making a copy of an original master.

If a good painter makes the copy, 4 times larger than the original.  The new owner can stand back 20 feet and look at the painting above the fireplace.  It will look very nice..

if the painter needs to copy everything at the same size, down to the last little stroke around a face,  the painter will need more time and effort to make the copy. The new owner can now examine the painting, up close and enjoy all the details.

There are many dozens of encoding options, just like the painter's choice of brush size, mix of paints, layering of colors. Each choice can have multiple sub choices.  You can easily mistake the encoding process to be much simplier, if you just look over the shoulder of the painter --- like looking at User checkboxes and some pull down encoder choices.  A lot of the encoding choices are combined with a single checkbox, a pull down option, or with each command line dash and a number.  

So, you cannot compare transcoder setup to software or command line encoding.  The more details the painter or encoder needs to do, the longer it takes.  The complete set of options are hidden by the program.   You are only watching the painter from behind.  You have to study the command line and all the variable settings, to even hope to  understand what is being done.  This is why transcoding settings with possible hardware assistance is not going to be the same file size, bit rate or duration as a software encoding of the same media even when the setting summary looking similar.

Anyway, hopefully that helps and is not just more confusing. Ha!

Edited by visproduction
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...