@KarlDag said:
What are you trying to show me, please? I see bitrate, doesn’t mean image quality has changed… What am I missing?
The quality of both files is the same but at the bottom check the MIN, MAX and AVG values (these are bitrates) and the filesize.
@an3k said:
@KarlDag said:
What are you trying to show me, please? I see bitrate, doesn’t mean image quality has changed… What am I missing?The quality of both files is the same but at the bottom check the MIN, MAX and AVG values (these are bitrates) and the filesize.
Nobody disagrees with this. That’s why in the OP post I said we need to be able to control both the preset and the quality. We got half the recipe now. 
However, take a look at the resolution of both files before comparing bitrates. Plex is doing some “nasty” stuff behind the scenes changing resolutions for certain combinations. IE 720p isn’t always 720p and often smaller.
Hint: convert one file with the “Optimize with Mobile 4Mb at 720p” setting and look at both the bitrate and the resolution after the file is generated. Neither is correct. Same with other settings.
If you look at the server log and look at the commands sent to the transcoder they are wrong and you can’t guarantee they bitrate outcome the way they are using “ffmpeg”.
They are playing to much and trying to “anticipate” what we want or how it should work instead of just giving us control to actually produce “true” files of the anticipated size/bitrate that are worth archiving and keeping as part of our collection.
@an3k said:
@KarlDag said:
What are you trying to show me, please? I see bitrate, doesn’t mean image quality has changed… What am I missing?The quality of both files is the same but at the bottom check the MIN, MAX and AVG values (these are bitrates) and the filesize.
OK, so as predicted slower gives more quality per bitrate. Since we ask plex for a specific bitrate, can’t it fit more quality in the same file size?
Normally for the same given preset (eg veryslow), lowering (better quality) the constant rate factor will increase file size and will typically use more bits.
@cayars said:
@an3k said:
@KarlDag said:
What are you trying to show me, please? I see bitrate, doesn’t mean image quality has changed… What am I missing?The quality of both files is the same but at the bottom check the MIN, MAX and AVG values (these are bitrates) and the filesize.
Nobody disagrees with this. That’s why in the OP post I said we need to be able to control both the preset and the quality. We got half the recipe now.
I just posted a comparable example for @KarlDag to answer his question Both examples were encoded natively with x264, no Plex, ffmpeg, AviSynth or whatever was involved.
However, take a look at the resolution of both files before comparing bitrates. Plex is doing some “nasty” stuff behind the scenes changing resolutions for certain combinations. IE 720p isn’t always 720p and often smaller.
Hint: convert one file with the “Optimize with Mobile 4Mb at 720p” setting and look at both the bitrate and the resolution after the file is generated. Neither is correct. Same with other settings.
That’s nasty. Didn’t know that even the very basic settings are not matched.
If you look at the server log and look at the commands sent to the transcoder they are wrong and you can’t guarantee they bitrate outcome the way they are using “ffmpeg”.
They are playing to much and trying to “anticipate” what we want or how it should work instead of just giving us control to actually produce “true” files of the anticipated size/bitrate that are worth archiving and keeping as part of our collection.
Fun Fact: I offered them my help with the encoding presets and commands but all they said is “keep up the good work in the forums and you may be promoted to a Ninja”. I was also told that Ninjas have a more direct line to the developers, provide continuous feedback and have access to GitHub Issues.
The real Fun Fact is that Plex is not listening at all regarding the encoding presets / command line options. They think they know everything but in fact - as we can clearly see - they absolutely have no clue about audio/video encoding. I wish someone would do a hostile fork of PMS!
@an3k yea I agree. Here’s some other “fun things” to think about. I’m sure you know this but others might not so I’ll post some info concerning MO and why it’s the way it is.
VBR=Variable Bit Rate. The file is encoding using the amount of bits needed to match the target quality. Some frames will use less bits while others will use more bits. But all frames/scenes should match a certain quality “standard”. You can’t calculate file size.
CBR=Constant Bit Rate. There is an imposed bitrate set for all frames. You can calculate file size pretty easily since you know the time of the file and the bitrate that will be used. You can pretty much assure this file can be streamed within a certain bandwidth limit. All frames pretty much use the same bitrate. The problem with this is that not all frames need X bitrate and other frames need more than X bitrate to match a certain quality. So some frames will be capped and will be blocky on playback given there isn’t enough bits to convey what’s going on.
SOME OF THE USES OF MEDIA OPTIMIZER:
1: the "raw archiver. The op who rips blu rays and wants to keep the original online. Has some devices that can’t play these raw files due to bitrate or codecs and will get lots of buffering during transcoding (ie bitrate exceeds device limit or VC-1 codec and one CPU core limit of ffmpeg). This person will want to create an mp4/h.264/aac/ac3 type files. At present MO won’t keep more than 2 audio channels so “surround sound is lost” with MO.
Person with limited upload speed or with monthly data caps that shares their server. Needs will slightly differ but this person will probably want the highest quality video they can “stuff” into something like 720p/4Mb for remote sharing and will keep/use their original media for in house use. This person could also be a #1 user above as well.
Person wants to stream to small screen devices such as smart phone or tablet. Maybe just wants to have a version pre-transcoded that will sync without the wait. This same person could also have the need for #1 and #2 above.
Now here’s the rub. Say your main “objective” was to use the lowest bitrate you could for the quality you expect to have. You try and create a 720p/3Mb version of a file (with current settings) but notice it’s almost good enough but you see “blocking” or artifacts in some scenes. You have to go back and try 720p/4Mb which now looks better to you. So because you have no control over CRF during file creation you settle on 4Mb version.
The problem:
Here is the major problem. Typically when we convert our files externally using my scripts, handbrake,
xMedia recoder, etc we convert/transcode these files using VBR and a target CRF. Variable Bit Rate in a nutshell only uses enough bits to convert the media while meeting the CFR we set. So you can’t calculate what the bitrate will be or the file size (unless doing a two pass encoding). What we can expect is that the media (regardless of bitrate or size) will encode to the quality level we set with the CRF. The level of compression you achieve depends on the source material. If it’s “grainy” looking for example it’s going to take a lot more bits. If it’s an animation it’s most likely going to require far less bits.
Now these VBR files are totally fine when playing back locally or usually when streamed locally. They will usually even play just fine remotely assuming the bandwidth in between is sufficient.
If you now put a limit on bandwidth available (client or server) things change drastically in the Plex world (maybe not as much on other platforms). Here is what I’m getting at. Assume there is only 4Mb pipe available and we are doing a progressive download of an MP4/264/AAC video:
If I put a file with an average 4Mb encode on my webserver and give you a link you will probably be able to play it without much issue. If you watch the same video via Plex it will probably stop/start/stutter a great deal. Any of the frames with higher than 4Mb bitrates won’t get to the client fast enough and will cause stuttering.
The web based version might also stutter once or twice but nothing like the Plex served version. Why?
Plex does not BUFFER content like most other services. Remember when you had limited bandwidth and wanted to watch a YouTube video you would start it then pause it to let the video download a bit before watching it? Plex doesn’t do this.
So the 4Mb version played back via the browser/webserver will be buffering the content. Since the content is variable the browser will be filling the buffer during lower bitrate frames to try and stay ahead of the frame you are viewing. This gives you much more “wiggle room” with videos that have spikes in the bitrate.
Now coming back to the Plex world. Since we don’t have this buffering we can’t do the same. These bitrate spikes cause us much more problems. We have to take a different approach than VBR (variable bit rate) and need to move to CBR (constant bitrate) encoding. This means we will “CAP” the bitrate at 4Mb in this case to assure that no scene uses more than this. Scenes that don’t really need this 4Mb rate will still use it. It’s basically “leveled” at 4Mb.
So without a “buffer” you can’t ride out the higher spikes and need to “chop” or limit the bits which causes blocking or lower quality scenes especially in fast action sequences. Quality of video always suffers using this approach.
All of this is an over simplification but illustrates a few things.
Why do I bring this up? Plex is designing MO to function in the CBR camp and not the VBR which might be perfect for many people. It depends on WHY people are using MO in the first place. Plex is totally ignoring what we MAY WANT.
VBR would be better for those:
a. just trying to be able to pre-encode problem files that contain codecs which force transcoding and only use a single core such as VC-1. Quality is still the biggest concern to this user.
b. those trying to pre-transcode files to limit the amount of monthly bandwidth used. Examples are those on Comcast with a 300Gb monthly limit. VBR is better than CBR in this case because it’s not a “pipe” issue but an overall usage limit you are trying to achieve. You want the bits spread around the file where they are needed for quality and not artificially limited only at the frame level. Quality is most important while “fitting” an average bitrate for the file.
c. those trying to pre-transcode stuff for SYNCing. This is similar to the above situation. You want something with good quality you can transfer to your device in a timely manner but want the bits spread throughout the file where needed. Again you want the highest quality you can get for X overall size file.
d. IF AND ONLY IF we had “normal buffering” in the plex clients then VBR could very well be better for those with true “pipe” limits. The VBR encode will have many frames using much less than the average so the buffer builds. Those frames that go above the average will cause the buffer to get smaller. As long as there is some bits in the buffer then client will play without stuttering or pausing.
CBR is better when:
a. you have a fixed pipe available that absolutely can’t be exceeded at any time AND there is no concept of client buffering to help ride out the spikes in bitrate.
So while many of us may prefer to pre-transcode using VBR we are stuck in CBR land with MO at present. We get degraded quality because of this.
I go back to the OP post and request we get the configurations PER JOB (not global) to setup the transcode based on OUR SPECIFIC NEEDS.
Carlo
@cayars said:
SOME OF THE USES OF MEDIA OPTIMIZER:
1: the "raw archiver. The op who rips blu rays and wants to keep the original online. Has some devices that can’t play these raw files due to bitrate or codecs and will get lots of buffering during transcoding (ie bitrate exceeds device limit or VC-1 codec and one CPU core limit of ffmpeg). This person will want to create an mp4/h.264/aac/ac3 type files. At present MO won’t keep more than 2 audio channels so “surround sound is lost” with MO.
Carlo
For the record, I’ve tried just that last night, optimized a file that has 2 5.1 ac3 tracks (french+english) and MO kept the 5 channels.
On another note, many people have issues streaming outside their networks because of lacking upload speed, making them want to optimize their media and using CBR makes sense (interesting point of view about the buffering though, didn’t know that).
I think Cloud Sync could alleviate many issues if we could simply upload our most requested media to the cloud and the server would send that to our external clients in a transparent manner…streaming from a cloud provider would be one way remove the need for limited bitrate/cbr.
Plex doesn’t seem to care too much for cloud sync, but their competitor seems to be doing basically what I want regarding this… I really hope Plex gets their stuff together soon enough or I’ll have to switch to get a better experience… And I don’t think I’ll be alone.
@an3k said:
Fun Fact: I offered them my help with the encoding presets and commands but all they said is “keep up the good work in the forums and you may be promoted to a Ninja”. I was also told that Ninjas have a more direct line to the developers, provide continuous feedback and have access to GitHub Issues.
The real Fun Fact is that Plex is not listening at all regarding the encoding presets / command line options. They think they know everything but in fact - as we can clearly see - they absolutely have no clue about audio/video encoding. I wish someone would do a hostile fork of PMS!
That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.
@KarlDag said:
@cayars said:
SOME OF THE USES OF MEDIA OPTIMIZER:
1: the "raw archiver. The op who rips blu rays and wants to keep the original online. Has some devices that can’t play these raw files due to bitrate or codecs and will get lots of buffering during transcoding (ie bitrate exceeds device limit or VC-1 codec and one CPU core limit of ffmpeg). This person will want to create an mp4/h.264/aac/ac3 type files. At present MO won’t keep more than 2 audio channels so “surround sound is lost” with MO.
CarloFor the record, I’ve tried just that last night, optimized a file that has 2 5.1 ac3 tracks (french+english) and MO kept the 5 channels.
Yea, my bad. I’m sure this is based on the MO profile you choose. I’ve been playing with the mobile and 720p custom stuff.
On another note, many people have issues streaming outside their networks because of lacking upload speed, making them want to optimize their media and using CBR makes sense (interesting point of view about the buffering though, didn’t know that).
Yep
I think Cloud Sync could alleviate many issues if we could simply upload our most requested media to the cloud and the server would send that to our external clients in a transparent manner…streaming from a cloud provider would be one way remove the need for limited bitrate/cbr.
Plex doesn’t seem to care too much for cloud sync, but their competitor seems to be doing basically what I want regarding this… I really hope Plex gets their stuff together soon enough or I’ll have to switch to get a better experience… And I don’t think I’ll be alone.
Wow, totally forgot about cloud streaming as I don’t use it. Of course you’re right about that.
Yep, Plex was first with Sync and with Cloud Sync but the other company is doing it better. Guess this is one of the cases where being first isn’t as important as doing it right.
@KarlDag said:
@an3k said:
Fun Fact: I offered them my help with the encoding presets and commands but all they said is “keep up the good work in the forums and you may be promoted to a Ninja”. I was also told that Ninjas have a more direct line to the developers, provide continuous feedback and have access to GitHub Issues.
The real Fun Fact is that Plex is not listening at all regarding the encoding presets / command line options. They think they know everything but in fact - as we can clearly see - they absolutely have no clue about audio/video encoding. I wish someone would do a hostile fork of PMS!That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.
I agree. I really wish Plex would change or expand the Ninja program to include about a half dozen people from the present forums. They could get a lot of good feedback during the design phase (before time/effort is wasted) on how exactly people will use the features and what is really needed. If some things were done just a bit differently the overall product could be much more powerful and usable. In some cases this would even save development time.
Sad to hear that Plex doesn’t want help from obviously skilled people. Hope that will change @elan
@KarlDag said:
That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.
If I’m the Mike you mean with this, I’ve pretty well burned that bridge with some of the rather scathing remarks I’ve made in the past regarding the Dev Team’s priorities. I have never spoken with any of the Devs, but I’m sure most of them know who I am. And most of them are likely as not to roll their eyes when they hear my name pop up in a conversation or thread. “Oh, yeah, THAT guy!” would probably be the likely response…
Case in point… Backlisting for exclusions… I would use it if it were available now, but, honestly, I was just trying to help @cayars out in that infamous “Venting” thread when @elan tried to stuff the feature back at me. Now I’m one of the biggest possible supporters of the idea. @elan did that… Not because I feel we need it, (which I do) but because his response specifically singled me out in a thread that basically said that the Devs are losing touch with the users. Look on the forums now for the people requesting that this functionality be added. It wouldn’t be the issue it is now had the Team actively sought out the opinions of a few people before the feature went live.
There is no excuse when the Team starts working on a new feature they don’t actively approach certain members here for their input into how that feature should be implemented. There is no excuse that some members here aren’t brought on-board for a specific feature to test it before it hits Pass versions to wring out potential bugs. If @cayars can’t break something on his mega-system, the odds are pretty strong the little mom’s and pop’s aren’t going to break the same feature on their much smaller systems.
@MikeG6.5 said:
@KarlDag said:
That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.If I’m the Mike you mean with this, I’ve pretty well burned that bridge with some of the rather scathing remarks I’ve made in the past regarding the Dev Team’s priorities. I have never spoken with any of the Devs, but I’m sure most of them know who I am. And most of them are likely as not to roll their eyes when they hear my name pop up in a conversation or thread. “Oh, yeah, THAT guy!” would probably be the likely response…
Case in point… Backlisting for exclusions… I would use it if it were available now, but, honestly, I was just trying to help @cayars out in that infamous “Venting” thread when @elan tried to stuff the feature back at me. Now I’m one of the biggest possible supporters of the idea. @elan did that… Not because I feel we need it, (which I do) but because his response specifically singled me out in a thread that basically said that the Devs are losing touch with the users. Look on the forums now for the people requesting that this functionality be added. It wouldn’t be the issue it is now had the Team actively sought out the opinions of a few people before the feature went live.
There is no excuse when the Team starts working on a new feature they don’t actively approach certain members here for their input into how that feature should be implemented. There is no excuse that some members here aren’t brought on-board for a specific feature to test it before it hits Pass versions to wring out potential bugs. If @cayars can’t break something on his mega-system, the odds are pretty strong the little mom’s and pop’s aren’t going to break the same feature on their much smaller systems.
I still like you 
hehe, My life is complete, now… 
@MikeG6.5 said:
@KarlDag said:
That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.If I’m the Mike you mean with this, I’ve pretty well burned that bridge with some of the rather scathing remarks I’ve made in the past regarding the Dev Team’s priorities. I have never spoken with any of the Devs, but I’m sure most of them know who I am. And most of them are likely as not to roll their eyes when they hear my name pop up in a conversation or thread. “Oh, yeah, THAT guy!” would probably be the likely response…
Oh, you were that guy who helped me burning down that bridge?! This is actually also a very good description of the relationship between me and Plex Devs. Do we have a Club House?
@MikeG6.5 said:
There is no excuse when the Team starts working on a new feature they don’t actively approach certain members here for their input into how that feature should be implemented. There is no excuse that some members here aren’t brought on-board for a specific feature to test it before it hits Pass versions to wring out potential bugs. If @cayars can’t break something on his mega-system, the odds are pretty strong the little mom’s and pop’s aren’t going to break the same feature on their much smaller systems.
I don’t think it’s so much about “breaking” things but about getting the design correct before code is written. Really I think it’s a lack of understanding of how the users really use the software (or could use the software). Many of the features that have been released in the last couple of years just seem unfinished or not well thought out in how the users will actually use the features. Plex gets the feature about 60-70% good but not more. Some cases in point: Sync, Cloud Sync, Users/sharing, sharing filters/restrictions, Media Optimizations and I’m sure bandwidth restrictions will end up being the same.
It seems to me Plex goes into feature design with “blinders on” or with “tunnel vision” and don’t see the “big picture”. They often miss obvious things how one feature can help other parts of the system. Instead it feels like they rush releases just to say they have “feature x”. This makes it extremely hard to go back and “fix/expand” them later.
I think some of the guys running big systems get to “feel the pain” more than those with small systems but it’s probably more a case of just being around the block enough to know… IMHO, there are at least a half dozen guys in this forum who really get “the problems” and can see the big picture as I put it.
I agree. There are a lot of things that feel half-done, and not just with the ideas you posted about. I could make a list of things that feel half-done and add another 8-10 items over your list. Just because Plex may be the first to bring out a feature doesn’t mean it’s the right way to do it. If the cake is half-baked when it comes out of the oven, you put the thing back in until it’s done. We aren’t seeing that with Plex. We’re being served something that’s not quite right and then have to wait for a later, undisclosed date for that feature to be finished.
We seem to get a lot of half-baked cake served to us, lately…
@an3k said:
@MikeG6.5 said:
@KarlDag said:
That’s almost insulting. Keep up the good work man, we need people with your knowledge to spread good information around here! I’m sure you could help improve the product, as could Carlo, or Mike.If I’m the Mike you mean with this, I’ve pretty well burned that bridge with some of the rather scathing remarks I’ve made in the past regarding the Dev Team’s priorities. I have never spoken with any of the Devs, but I’m sure most of them know who I am. And most of them are likely as not to roll their eyes when they hear my name pop up in a conversation or thread. “Oh, yeah, THAT guy!” would probably be the likely response…
Oh, you were that guy who helped me burning down that bridge?!
And a secret handshake…
@MikeG6.5 said:
We aren’t seeing that with Plex. We’re being served something that’s not quite right and then have to wait for a later, undisclosed date for that feature to be finished.
If ever. Do you think we’ll ever get negative filtering? Been over a year since it’s release and this is a trivial change in the scheme of things that would actually make it quite usable.
Carlo
PS @MikeG6.5 I bet after you add your 8 to 10 items I could in turn add another dozen. I just try and “pick my battles” for things I think the large majority of people would benefit from. If I add my “personal” items it would be a long, long list.
While slightly off target and already covered in this thread by me:
I just want to get a bit more exposure and ask that Plex incorporate the “-force_key_frames” option during all media conversions so there won’t be a problem using them as HLS streams down the road.
Carlo
@cayars said:
While slightly off target and already covered in this thread by me:
https://forums.plex.tv/discussion/191972/dropped-frames-and-visual-artifacts-on-sony-warner-bros-mpeg-4-avc-blu-rays/p5I just want to get a bit more exposure and ask that Plex incorporate the “-force_key_frames” option during all media conversions so there won’t be a problem using them as HLS streams down the road.
Carlo
I was able to play the HLS live streams of the 32C3 without a problem on my Xperia Z4 but I wasn’t able to play any Plex created HLS stream.
Yep, it’s a problem for many people. To me it’s pretty obvious why this is happening. Now to convince those that matter.
sorry posted in wrong thread.
