Jump to content

New transcoding seems much worse


jhs39

Recommended Posts

jhs39

Downloaded Emby Server 3.0.5621 Beta yesterday afternoon.  There is supposed to be a new transcoding method that reduces CPU usage but it is providing poor results compared with the previous version, for me at least--when I'm watching movies that are transcoded now there are artifacts that come and go throughout the entire video which was not an issue before the server update.  The CPU usage is about 30% and nothing else is running but the transcode process is no longer seamless like it was before yesterday's update.  

Link to comment
Share on other sites

It can take a couple minutes before it drops down to slower speeds. This is a major improvement over the previous release. It resolves the looped playback issue of the previous release, resolves stuttering issues, blocks, and makes seeking faster. If you're seeing artifacts then try increasing the bitrate to the highest value you can support.

Link to comment
Share on other sites

jhs39

I have the bitrate set to the highest value and never saw artifacts at that setting before yesterday.  I might need to lower my bitrate setting if this improved transcoding process is permanent because it most definitely isn't offering improved results on my Roku.

Link to comment
Share on other sites

The previous release was stream copying the video in some situations where it should not have been, which was causing stuttering and looped playback issues for other users. So now that this is fixed, that might be why you have this impression.

Link to comment
Share on other sites

BAS

I was on beta, I got the roll of this update Version 3.0.5621.2, with it being a holiday weekend I didn't have time to test, I got multiple texts about skipping audio, and having to hit play multiple times before media would start. I watched as 4 external users and myself internally played content, and I noticed that in the web client that it has a transcoding red line, ffmpeg is firing, then ffmpeg disappears when it gets to where it says they are far enough ahead red line still present, when ffmpeg fires off again the web client transcoding red line disappears and reappears, this is instantly when I see the audio skip or anything of that nature. Overall it does look like a better step forward in a so called throttling method... but this leads me to one thing... I really still want a quick burn thru process 70/85 percent cpu... and it appears that the enable throttling toggle found in playback/transcoding of web client doesn't allow me to use that functionality still. 

 

I went back to official so I could just enjoy my weekend and the playback my users have become use to, and now here I have a official version waiting to install tonight of Version 3.0.5621.3

 

Does turning off the enable throttling toggle in this version allow a user to stay with a quick burn thru transcode process still as this version of transcoding works best in my server / user scenario and maybe for others as well. I'm sure this update will go in and I wont have much choice but to confirm this myself and report logs if problems continue. It seems that there should be a little more time between Beta and Official...

Link to comment
Share on other sites

What we really need are more people willing to run Beta versions and then give us full reports of issues like BAS does.  The reason we are starting to see more of these issues sneak through lately is because the number of people running the beta version of the server has dwindled to almost nothing.  I realize it can be painful to run Beta but, if you can help out by doing so, please consider it.

Link to comment
Share on other sites

CBers

What we really need are more people willing to run Beta versions and then give us full reports of issues like BAS does.  The reason we are starting to see more of these issues sneak through lately is because the number of people running the beta version of the server has dwindled to almost nothing.  I realize it can be painful to run Beta but, if you can help out by doing so, please consider it.

 

You mean update from Official Release to Beta, rather than Dev to Beta ??

Link to comment
Share on other sites

You mean update from Official Release to Beta, rather than Dev to Beta ??

 

Yes.  If you are on Dev then you are already in the testing loop even deeper.  We just need more folks out there willing to run Beta instead of just Release.

  • Like 1
Link to comment
Share on other sites

BAS

Server wise I'm never on developer as I don't have time to post logs and all the additional hassle for my users. I usually always am on beta level for server and almost all my users are Roku client only on beta level, before I could even report this I started noticing posts about playback issues, connection issues etc on forums... and like I said to enjoy my weekend I just put it back on official. There was literally 2-3 days between beta and official. Sorry to hijack this thread my server is set to beta again, .3 is official and beta... so tonight I will find out if the enable throttling is being ignored still and if it is, try to get whatever info is needed I guess for playback issues.

Edited by BAS
Link to comment
Share on other sites

BAS

Ok well throttling toggle definately doesnt work and I have no burn thru process anymore... also my server crashed multiple times this weekend when user transcode/load was at its highest. Can I please have a get it done as quick as possible option? New method is better for those that want to throttle... but between my transcode needs and my user amount I need the good old get er done method. Original poster, are you still having issues?

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

CBers

@@BAS - I agree, transcode throttling needs needs to be re-implemented.

 

I get occasions where playback pauses fir a second or two whilst the ffmpeg process wakes.

 

I posted about it here.

 

No response as yet!

Link to comment
Share on other sites

BAS

@@BAS - I agree, transcode throttling needs needs to be re-implemented.

 

I get occasions where playback pauses fir a second or two whilst the ffmpeg process wakes.

 

I posted about it here.

 

No response as yet!

 

I will post logs on Monday, server has been unstable all weekend under heavy load. Really wish I had a copy of the old official somewhere... oh well.

Link to comment
Share on other sites

jhs39

I get occasional brief glitches in playback of videos but it doesn't seem to be as bad as when I originally posted my message--but considering that my computer is running nothing else, the CPU usage never goes above 30% and that physical memory never goes above 70% it doesn't seem like Embry is using my computer resources well when transcoding a video.  I can't see any reason video playback shouldn't be smooth, I never had this kind of problem before the new transcoder process was implemented and if I rewind the videos the glitches do not occur again in the same places, so it isn't a problem with bad video files.  I'm not a techie but it seems like Embry is now trying very hard to not use computer resources that I would rather use to provide the smoothest playback experience.   

  • Like 1
Link to comment
Share on other sites

farside847

I too am seeing an occasional blip in playback when it transcodes to my roku. Using latest server and roku app. It is transcoding because the mp4 file has 5 reframes. Used to direct play a few versions back without issue.

 

My server is pretty fast with an intel i7 cpu. Let me know if any logs might help you guys lock down the cause.

 

Thanks for your help!

Edited by farside847
Link to comment
Share on other sites

Happy2Play

I too am seeing an occasional blip in playback when it transcodes to my roku. Using latest server and roku app. It is transcoding because the mp4 file has 5 reframes. Used to direct play a few versions back without issue.

 

My server is pretty fast with an intel i7 cpu. Let me know if any logs might help you guys lock down the cause.

 

Thanks for your help!

What is your Roku app version number?  Are you sure it is transcoding because of "reframes"?  I have TV and Movies up to 12 ref frames that all direct play.

Link to comment
Share on other sites

yea the max ref frames is detected based on the roku firmware version.

Link to comment
Share on other sites

farside847

I am always amazed at how great you guys are. I looked back on my log for an example that happened today, and you were absolutely right! It did not transcode because of reframes. It was because of the framerate.

 

The source file was "AverageFrameRate":32.29693,"RealFrameRate":59.94006 and the roku profile was recently updated to transcode anything over 30. Sorry, I got mixed up!

Link to comment
Share on other sites

Interesting. So we need to cap it at 29.97? Based on the above it seems anything over that might not play very well.

Link to comment
Share on other sites

farside847

Yep, actually, it probably should transcode anything that is not 23.97 or 29.97 specifically. Anything in-between like 25fps is not supported either.

 

I totally agree that the server should transcode this file. But when it did I saw a few blips (small stutters). I remember 3 in a 30 minute show. Was this another example of a transcoding issue being discussed?

 

thanks!

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