Jump to content

Conversion settings


rtfmoz

Recommended Posts

rtfmoz

Hi all,

I am converting some SD quality AVI files to TV format at 1.5MB/s. However these are coming out 100MB larger. So 366MB->491MB. Can I get some help with the settings for the following...

H.264 encoded MKV Files
SD 480p ~350MB
HD 720p ~ 1 GB
FHD 1080p ~ 2-3 GB

Appreciated.

Edited by rtfmoz
Link to comment
Share on other sites

  • 1 month later...
rtfmoz

Wasn't worth the effort going through hoops to get you guys to look at something. I've just noticed that any transcoding job seems to convert any smaller source material to ~ 1GB in size. This really isn't ideal in any home setting. I would expect smaller files would stay small and this clearly isn't the outcome. Given the myriad of possible reasons for these transcoding choices I feel its pointless progressing (arguing) this any further so haven't updated  this issue. 

Edited by rtfmoz
  • Like 1
Link to comment
Share on other sites

rtfmoz

Actually TBH I am completely over spending hours diagnosing something only to be told its not in the dev roadmap, not critical, not important so unless you can indicate to me its something Emby dev is actually interested in diagnosing lets leave it there.

  • Like 1
Link to comment
Share on other sites

aaronsomek
25 minutes ago, rtfmoz said:

Actually TBH I am completely over spending hours diagnosing something only to be told its not in the dev roadmap, not critical, not important so unless you can indicate to me its something Emby dev is actually interested in diagnosing lets leave it there.

Well if you don't go through the proper procedure to report an issue with all the relevant information how do you expect the devs to fix/address the problem?

Link to comment
Share on other sites

Yes we're happy to help you resolve this issue if you can provide a little more information. Thanks.

Link to comment
Share on other sites

rtfmoz

The exact steps I am doing inside Emby.

1. From Emby Dashboard go to the Metadata manager.
2. Drill down to the single episode I wanted to test conversion on.
3. Click the three dots on the top right and select convert.
4. Choose my conversion settings then select convert.

The two images attached represent the Emby conversion settings and the outcome. The two files attached are the serverlogs and ffmpeg logs, there has been only one conversion today. Essentially for some reason Emby is choosing to re-encode a 973kb/s video at nearly 3MB/s. The outcome is nearly 1GB. So my question is.. what does the Original Quality setting actually mean/do? Since clearly it does not seem to keep original bitrates intact.

Conversion settings.png

Converted Files - Original.png

ffmpeg-transcode-a0dd4aa0-cce4-4e99-9e36-76d7599cc2e1_1.txt embyserver.txt

Edited by rtfmoz
Link to comment
Share on other sites

rbjtech

Generally speaking, to convert an older CODEC (Divx etc) to h264 and maintain the original quality (as much as possible), you do have to increase the bitrate vs the original file to cater for the re-encoding losses.  

Video conversion is a fine art - settings for one video may work great, but try them on another file and they look poor.

Your best course of action is to re-encode directly from the source to h264, but if that is not available - then an increased bitrate is going to buy you compatibility and with storage so cheap, is probably not going to cause you any issues with the increased file size ?

 

Link to comment
Share on other sites

rtfmoz

Why are they re-encoding in the first place? Its MPEG4, should be a copy and repackage. I was going to raise this later on in the discussion but since you brought re-encoding up.

Link to comment
Share on other sites

3 hours ago, rbjtech said:

Generally speaking, to convert an older CODEC (Divx etc) to h264 and maintain the original quality (as much as possible), you do have to increase the bitrate vs the original file to cater for the re-encoding losses.  

Video conversion is a fine art - settings for one video may work great, but try them on another file and they look poor.

Your best course of action is to re-encode directly from the source to h264, but if that is not available - then an increased bitrate is going to buy you compatibility and with storage so cheap, is probably not going to cause you any issues with the increased file size ?

 

That or set a CRF and allow the transcoder to make the bitrate allocations as needed.  That almost always works better than trying to guess bitrates as the CRF setting will tell it to use what it needs.

  • Like 1
Link to comment
Share on other sites

rbjtech
7 hours ago, rtfmoz said:

Why are they re-encoding in the first place? Its MPEG4, should be a copy and repackage. I was going to raise this later on in the discussion but since you brought re-encoding up.

Xvid/DivX (MPEG4) is not compatible with h264, so you have to re-encode, you cannot just demux.   If the AVI container did just contain raw h264, then you could just re-mux to a .mkv without losing any quality at all.

 

Link to comment
Share on other sites

rbjtech
4 hours ago, cayars said:

That or set a CRF and allow the transcoder to make the bitrate allocations as needed.  That almost always works better than trying to guess bitrates as the CRF setting will tell it to use what it needs.

Sure - I wasn't saying to use VBR/CBR/Multi-pass - CRF (which is what I assume emby/ffmpeg is using for this function) WILL use a higher bitrate than the original to meet it's standard CRF value (of 22/23 - whatever emby uses).  In my experience (my eyes) - I can tell the difference between the two - so I usually opt for CRF = 18 (lower = better), but this is an increased filesize of course.   But this is just my experience.

As I said, there are so many factors at play here, that giving advice on encoding is a lifetimes work - doom9.org is where to go if you want to learn a lot more ..

Edited by rbjtech
Link to comment
Share on other sites

rtfmoz
On 7/22/2020 at 10:59 AM, rbjtech said:

an increased bitrate is going to buy you compatibility and with storage so cheap, is probably not going to cause you any issues with the increased file size ?

 

From 358MB -> 952MB? Thats a tad excessive.

Back again to my original question, what is Original quality supposed to do here?

Edited by rtfmoz
Link to comment
Share on other sites

rtfmoz
On 7/22/2020 at 6:56 PM, rbjtech said:

Xvid/DivX (MPEG4) is not compatible with h264, so you have to re-encode, you cannot just demux.  

 

Thanks for the explanation.

Link to comment
Share on other sites

9 minutes ago, rtfmoz said:

From 358MB -> 952MB? Thats a tad excessive.

Back again to my original question, what is Original quality supposed to do here?

It looks at your source file and tries to pick a reasonable close set of conversion settings to match so quality stays as close as possible.

Link to comment
Share on other sites

rtfmoz
7 minutes ago, cayars said:

It looks at your source file and tries to pick a reasonable close set of conversion settings to match so quality stays as close as possible.

So why are we doing 2919kb/s on a 973kb/s video...
Input Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 624x352 [SAR 1:1 DAR 39:22], 973 kb/s, Level 5, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc

Output Stream #0:0: Video: h264 (h264_vaapi) (High) (H264 / 0x34363248), vaapi_vld, 624x352 [SAR 1:1 DAR 39:22], q=-1--1, 2919 kb/s, Level 30, 23.98 fps, 1k tbn, 23.98 tbc

I'd understand an slight increase given what has been said but that's triple the bitrate. Surely that can't be right.

Edited by rtfmoz
Link to comment
Share on other sites

Original QUALITY not size or bitrate.

A good example would be a film where the film grain is intentional by the director.  When you re-encode something like this trying to hold the original quality it will take a lot more bits to reproduce this than say clean looking footage.  It's the nature of encoding.

Link to comment
Share on other sites

rtfmoz
4 minutes ago, cayars said:

Original QUALITY not size or bitrate.

A good example would be a film where the film grain is intentional by the director.  When you re-encode something like this trying to hold the original quality it will take a lot more bits to reproduce this than say clean looking footage.  It's the nature of encoding.

Well therein lies my problem. Tripling the bitrate is poor encoding choices. Hence the original reason for this post. Here is the input stream vs the output stream.

Input Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 624x352 [SAR 1:1 DAR 39:22], 973 kb/s, Level 5, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc
Output Stream #0:0: Video: h264 (h264_vaapi) (High) (H264 / 0x34363248), vaapi_vld, 624x352 [SAR 1:1 DAR 39:22], q=-1--1, 2919 kb/s, Level 30, 23.98 fps, 1k tbn, 23.98 tbc

And no, your answer is simply not acceptable.

Link to comment
Share on other sites

Well it's not a problem but a fact of how some videos need to be encoded.  You're causing the files to be bigger by using the Original setting.  What this is doing is using a very inefficient file like an AVI/xvid to base "original" on.    You're then converting to h.264 which is much more efficient and doesn't need original quality.

I know that sounds like I'm almost contradicting myself but encoding is tricky especially if using VBR vs CRF.  Emby's built in converter is designed mostly to limit bitrates to fit a certain pipe side vs trying to make small files for storage.  It's a different objective.

I personally don't use it as it's not customizable enough for my needs and doesn't function for my purposes which are storage related.  I want CRF control so that I set a CONSTANT QUALITY (CRF) and codecs and the conversion uses only as many bits as needed. If it would do this PLUS allow a max bitrate cutoff setting it would be close to perfect for my needs.

If your objective is to convert files to reduce storage space you want to do your conversions a different way (same as me) as your needs are different.  You can script ffmpeg to do this or can use a set of scripts such as "sickbeard mp4 converter" that will allow you to set parameters you're looking for and the scrips will analyze each file and make ffmpeg command line changes to make this happen.  OR you could try a tool like Xmedia Recode which has a nice GUI and allows you to stack many files to convert.

 

Link to comment
Share on other sites

rtfmoz

That's a much better explanation, thank you.

43 minutes ago, cayars said:

I want CRF control so that I set a CONSTANT QUALITY (CRF) and codecs and the conversion uses only as many bits as needed.

So why can't Emby offer this?

Not every individual setting of course but there are some meta settings available through ffmpeg which should be selectable in an advanced option pane. CBR is a good example. CBR on and the user can specify a bitrate. This translates directly to an ffmpeg setting and should automatically turn off VBR settings. As for max bitrate the option is already there in ffmpeg -maxrate:v:0 2919258 . That can simply be another on/off with user specified bitrate. While it would be counterproductive to try and get all settings there are some very common ones that would be extremely useful.

In fact user defined encoding profiles is something I would suggest as a feature for Emby. So you can configure encoding the way you want and save those settings. Then we can potentially associate them with meta entries. Metadata folder XYZ should be converted using user defined profile ABC.

Edited by rtfmoz
Link to comment
Share on other sites

Honestly I don't know but it could be that people haven't asked for it and the current functionality is what most people are looking for? 

Both you and I are looking for something different but I've never asked for different functionality as  I do my conversions outside of Emby before I ever add the media to my libraries so it hasn't personally bothered me. I know many others who do the same preparing the media OUTSIDE of Emby as well.

You could make a feature request here: https://emby.media/community/index.php?/forum/98-feature-requests/ but check to see if there is already request.

Link to comment
Share on other sites

rbjtech

There are many professional (but free) tools out there that do a much better job than emby of converting media to whatever format you like and whatever settings you wish to set.

Emby is a media player - it is not a full bells and whistles media convertor nor does it make claims to be one.  If the format is incompatible for emby playback, then it's internal real time transcoding function will allow the file to be played.

The Emby team (imo) should invest time in getting it's core playback functionality working perfectly - not side tracking into functionality, which given it's complexity, they will never match with other free tools out there.

An option which I have floated before is ask Emby to produce the 'input' files for these other tools - thus automating the process, but at the same time, handing the responsibility of the conversion over to the more specialist tools.

 

 

Edited by rbjtech
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
Quote

Generally speaking, to convert an older CODEC (Divx etc) to h264 and maintain the original quality (as much as possible), you do have to increase the bitrate vs the original file to cater for the re-encoding losses.  

Yes this is the reason for the increased bitrate with the converted file. When we use the same bitrate we often end up with users complaining that the converted version is lower quality.

Of course you can control this by explicitly setting the conversion quality level.

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