Transcoding Performance vs. That Other Server...

[BAlGaInTl 279]

Hey all...

 

I'm currently transitioning from Plex to Emby.  So far, I really like it.  The server config is so much nicer, and for the most part, it has feature parity.  Even though I'm still testing, I went ahead and purchased Emby Premiere to support the project.

 

The one area I'm having problems with is transcoding.  It seems that Emby is not nearly as efficient.  In particular, I have a lot of OTA recordings from my HDHomerun/TVHeadend that are in *.ts format.  The Plex server doesn't seem to have any problems with transcoding.  Emby on the other hand stutters and skips (especially at the beginning).  There is one recording that I've been using that pauses in exactly the same spots every time with Emby.  

 

This isn't so much an issue here at home where all of my clients can play natively through the Emby apps.  The problem comes for my wife who is in a different location.  The files have to be transcoded due to bandwidth restrictions.

 

Any thoughts on how I can improve this?  I've tried different transcode settings on the server, and nothing seems to make a difference.

 

A few things about my setup.

 

Latest Emby running in Docker

ASRock C2750D41 (Avoton Octacore)

12GB Ram

 

Any thoughts or ideas are appreciated.

[Luke 36997]

Hi, we're sorry to hear about this. The best thing to do is please provide the information requested in how to report a media playback issue. Then we'll take a look at the details. thanks !

[BAlGaInTl 279]

So this only seems to be happening when transcoding my raw TV recordings.  Not sure why my old server could handle it.

 

Does running in a Docker decrease the performace?

 

Anyway...

 

I set the transcoding options back to default and tried again.

 

Here is the server log, as well as a transcode log from one of the offending *.ts recordings.

 

 

 

 

[puithove 208]

An Atom processor is not going to have the performance to do much transcoding in CPU.  Your transcode log shows that ffmpeg is showing that it's only performing at 0.8x - so 80% of real time.  This is on a 1280x720 video so it shouldn't even be having to deinterlace (though it is 59.95fps so it has to transcode more frames per second to keep up).  Deinterlacing a 1080i stream would requite a bit more CPU than this even.

 

So unless you have some hardware to be able to do HW transcoding, you're not really going to be happy with it.  For any clients that are able to playback without transcoding though, there should be no issue.

[BAlGaInTl 279]

An Atom processor is not going to have the performance to do much transcoding in CPU.  Your transcode log shows that ffmpeg is showing that it's only performing at 0.8x - so 80% of real time.  This is on a 1280x720 video so it shouldn't even be having to deinterlace (though it is 59.95fps so it has to transcode more frames per second to keep up).  Deinterlacing a 1080i stream would requite a bit more CPU than this even.

 

So unless you have some hardware to be able to do HW transcoding, you're not really going to be happy with it.  For any clients that are able to playback without transcoding though, there should be no issue.

 

Thanks for taking a look and explaining that.

 

I get that I don't have the most powerful board... what type of magic is Plex doing that it will transcode these streams acceptably on the same hardware, but Emby will not?

 

And you are correct.  There is no problem with direct play.

 

I suppose I could do a lot of work to transcode recordings after they are done and then the server would handle it.  I'll have to check to see if I have anything that can help the transcoding.  I may have a video card laying around that will fit in the x8 slot.  I've read that in theory some x16 cards will fit, but will have reduced performance. 

 

I'd hate to scrap an otherwise useful little server board to go back to something more powerful.

[BAlGaInTl 279]

I do have some complete hardware changes I could do...

 

I have an Intel Core i3-4340 that currently isn't being used.

 

I also have an Xeon E3-1271.  This one is in my main rig and would probably be overkill for my needs.

 

Thoughts on how either of those would handle it?

[puithove 208]

I can't say what Plex might be doing different.  I imagine if it was working, you were probably only doing one stream at a time, and considering we're only talking about needing roughly a 20% difference in efficiency, you might have been just squeaking by with that.  All theory, nothing sold.

 

I believe there's plenty of forum discussions around here about a way of guestimating the transcoding performance from a processor's PassMark score.  Also plenty of Q&A on individual chips' abilities.  I'd guess that Haswell i3 is capable of at probably a couple simultaneous streams of that content in CPU, and shouldn't cost you a whole lot of electric to run it either.  It is also QuickSync capable (hardware transcode), so that could give you a better option.

 

The Xeon (also Haswell) since it's 4 cores should be capable of more in CPU, but at a higher electric cost.

 

I'm not really the best resource on this though, just taking a wild swag here.

Edited March 7, 2017 by puithove

[mastrmind11 717]

The xeon has  a passmark score of 9973, which means it should be capable of 9-10 simultaneous transcodes.

The i3 has a score of 5229, so 5 simultaneous transcodes.

The c2750 has a score of 3800, so a theoretical 3 simultaneous transcodes.

 

These are just estimates based on scores but are generally pretty accurate.  YMMV.

[BAlGaInTl 279]

The xeon has a passmark score of 9973, which means it should be capable of 9-10 simultaneous transcodes.

The i3 has a score of 5229, so 5 simultaneous transcodes.

The c2750 has a score of 3800, so a theoretical 3 simultaneous transcodes.

 

These are just estimates based on scores but are generally pretty accurate. YMMV.

Yeah... I had no problems with transcoding on Plex with the C2750.

 

I don't normally have to do more than one transcode at a time since all my local content streams direct.

 

I'm experimenting now, but haven't found any way to improve it.

 

I'm still not looking back... So far I really like Emby.

 

Any ideas to improve the performance?

 

 

 

 

Sent from my A0001 using Tapatalk

[kjp4756 41]

From what I remember, plex uses their own proprietary version of ffmpeg that's why plex is better at transcoding.  It's likely closed source so nobody but the plex devs will know how it works.

[Luke 36997]

No, the answer is that there are improvements we need to make to our support for hardware accelerated transcoding. thanks.

[BAlGaInTl 279]

I discovered something interesting today.....

 

I was playing around and noticed that even when I'm doing a transcode, CPU utilization is only at about 20-30% for all of my cores.  I've set Emby's transcoding setting to disable throttling.

 

Is this normal?

 

I'm pretty sure my utilization was much higher with plex, and wasn't a big deal since I don't transcode a lot.

 

Why is Emby being so nice?

 

See attached.

 

 

Edited March 8, 2017 by BAlGaInTl

[Luke 36997]

I suppose you can compare transcoding command lines to find that out.

[BAlGaInTl 279]

I suppose you can compare transcoding command lines to find that out.

 

I'll see if I can figure that out tonight.

 

How would one compare those?

 

Last night I disabled my Plex server, but I haven't removed it yet.  So I can fire it up pretty easily.

[Luke 36997]

You would just look at ffmpeg command lines between the two.

[BAlGaInTl 279]

Okay... turns out the Plex Encoder had a similar CPU utilization.

 

If I did this correctly (after some googling) here is what is running:

root@NPAsSbBi:/# ps -eaf | grep 10019
plex     10019  8190 99 17:45 ?        00:03:54 /usr/lib/plexmediaserver/Plex Transcoder -codec:#0x31 mpeg2video -codec:#0x34 ac3 -ss 5.18100023 -i /media/74825452-c994-4fac-b724-0be72133bf4c/media/Videos/TV/Shark Tank/Shark Tank2017-03-03-S08E19.ts -filter_complex [0:#0x31]yadif[1];[1]scale=w=min(720\,iw):h=min(406\,ih):force_original_aspect_ratio=decrease,format=pix_fmts=yuv420p|nv12[0] -map [0] -codec:0 libx264 -crf:0 19 -maxrate:0 1500k -bufsize:0 3000k -r:0 59.939999999999998 -preset:0 veryfast -x264opts:0 subme=2:me_range=4:rc_lookahead=20:me=hex -map 0:#0x34 -metadata:s:1 language=eng -codec:1 aac -ar:1 48000 -channel_layout:1 stereo -b:1 193k -f segment -segment_format matroska -segment_format_options live=1 -segment_time 1 -segment_header_filename header -segment_start_number 0 -segment_list http://127.0.0.1:32400/video/:/transcode/session/rn6bmabmjo7m7diatqmhrggb/seglist -segment_list_type csv -segment_list_size 2147483647 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 chunk-%05d -start_at_zero -copyts -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/rn6bmabmjo7m7diatqmhrggb/progress
root     10130  8058  0 17:47 pts/0    00:00:00 grep 10019

The video is being converted from an mpeg2 ts file to 480p at 1.5 Mbps.  Typical of something that would be streamed on a small screen remotely.  It played smooth as silk, with no skips whatsoever.  I'm not sure what Plex has done to their custom transcoder.

 

Then I did about the same using Emby.  Transcoded the same file to 480p at 1 Mbps (1.5 wasn't an option)  Here is the result:

root@NPAsSbBi:/# ps -eaf | grep 10429
scott    10429  1986 99 17:53 ?        00:03:03 /bin/ffmpeg -f mpegts -codec:0 mpeg2video -codec:1 ac3 -codec:2 ac3 -i file:/media/Videos/TV/Shark Tank/Shark Tank2017-03-03-S08E19.ts -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -pix_fmt yuv420p -preset veryfast -crf 28 -maxrate 10256503 -bufsize 20513006 -vsync -1 -profile:v high -level 4.1 -x264opts:0 subme=0:rc_lookahead=10:me_range=4:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames expr:gte(t,n_forced*3) -vf yadif=0:-1:0 -copyts -codec:a:0 aac -strict experimental -ac 6 -ab 384000 -af adelay=1,aresample=async=1 -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3 -individual_header_trailer 0 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 0 -segment_list /embycache/transcoding-temp/2b86489e7eac692f60bf935c44ebfd2d.m3u8 -y /embycache/transcoding-temp/2b86489e7eac692f60bf935c44ebfd2d%d.ts
root     10580  8058  0 17:54 pts/0    00:00:00 grep 10429

I get the same skips as before.  I did notice that if I pause the video for a few seconds, it seems to play okay and doesn't skip as much or at all.

 

Now I have no idea how to interpret these comands.... Or if they can even be compared.

 

Just thought I would post the results to see if anybody else notices something...

[Luke 36997]

The first command line is using 1.5mbps as the maximum bitrate, the second is using 10.2mbps, so that's a pretty big difference. Try setting the max streaming bitrate in the empy app. If it's on Auto, try setting it to a smaller number. 

[BAlGaInTl 279]

The first command line is using 1.5mbps as the maximum bitrate, the second is using 10.2mbps, so that's a pretty big difference. Try setting the max streaming bitrate in the empy app. If it's on Auto, try setting it to a smaller number. 

 

I was using the web interface/app.

 

I manually changed the streaming from Auto to 480p at 1 Mbps.

 

Is it possible that it's being ignored?

 

I just ran the same test manually changing the quality in the Android App to 480p at 1 Mbps.  The bitrate is very different... still not 1, but I'm not sure how to do the conversions.  The playback was in fact smoother, but there was some skipping.

root@NPAsSbBi:~# ps -eaf | grep 22218
scott    22218 16287 99 22:05 ?        00:02:58 /bin/ffmpeg -ss 00:00:44.206 -f mpegts -codec:0 mpeg2video -codec:1 ac3 -codec:2 ac3 -i file:/media/Videos/TV/Shark Tank/Shark Tank2017-03-03-S08E19.ts -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -force_key_frames expr:gte(t,n_forced*5) -vf yadif=0:-1:0,scale=trunc(min(max(iw\,ih*dar)\,720)/2)*2:trunc(ow/dar/2)*2 -pix_fmt yuv420p -preset superfast -crf 23 -maxrate 616000 -bufsize 1232000 -vsync -1 -profile:v high -level 4.1 -x264opts:0 subme=0:rc_lookahead=10:me_range=4:me=dia:no_chroma_me:8x8dct=0:partitions=none -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 copy -y /embycache/transcoding-temp/90672b74f240616907b52d5eb33e6d90.mkv
root     22286  8058  0 22:07 pts/0    00:00:00 grep 22218

Edited March 9, 2017 by BAlGaInTl

[Happy2Play 8239]

 

I was using the web interface/app.

 

I manually changed the streaming from Auto to 480p at 1 Mbps.

 

Is it possible that it's being ignored?

 

I just ran the same test manually changing the quality in the Android App to 480p at 1 Mbps.  The bitrate is very different... still not 1, but I'm not sure how to do the conversions.  The playback was in fact smoother, but there was some skipping.

root@NPAsSbBi:~# ps -eaf | grep 22218
scott    22218 16287 99 22:05 ?        00:02:58 /bin/ffmpeg -ss 00:00:44.206 -f mpegts -codec:0 mpeg2video -codec:1 ac3 -codec:2 ac3 -i file:/media/Videos/TV/Shark Tank/Shark Tank2017-03-03-S08E19.ts -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -force_key_frames expr:gte(t,n_forced*5) -vf yadif=0:-1:0,scale=trunc(min(max(iw\,ih*dar)\,720)/2)*2:trunc(ow/dar/2)*2 -pix_fmt yuv420p -preset superfast -crf 23 -maxrate 616000 -bufsize 1232000 -vsync -1 -profile:v high -level 4.1 -x264opts:0 subme=0:rc_lookahead=10:me_range=4:me=dia:no_chroma_me:8x8dct=0:partitions=none -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 copy -y /embycache/transcoding-temp/90672b74f240616907b52d5eb33e6d90.mkv
root     22286  8058  0 22:07 pts/0    00:00:00 grep 22218

 

Well that show "-maxrate 616000", that is only shows video bitrate so I would assume the audio biterate was 384000 to equal your 1Mbps limit.

[BAlGaInTl 279]

Well that show "-maxrate 616000", that is only shows video bitrate so I would assume the audio biterate was 384000 to equal your 1Mbps limit.

 

Ah.  I see.  That makes sense.

 

Any thoughts on why the one for the web client is so far off when I try to force to 1Mbps?

[hurricanehrndz 149]

Hey all...

 

I'm currently transitioning from Plex to Emby. So far, I really like it. The server config is so much nicer, and for the most part, it has feature parity. Even though I'm still testing, I went ahead and purchased Emby Premiere to support the project.

 

The one area I'm having problems with is transcoding. It seems that Emby is not nearly as efficient. In particular, I have a lot of OTA recordings from my HDHomerun/TVHeadend that are in *.ts format. The Plex server doesn't seem to have any problems with transcoding. Emby on the other hand stutters and skips (especially at the beginning). There is one recording that I've been using that pauses in exactly the same spots every time with Emby.

 

This isn't so much an issue here at home where all of my clients can play natively through the Emby apps. The problem comes for my wife who is in a different location. The files have to be transcoded due to bandwidth restrictions.

 

Any thoughts on how I can improve this? I've tried different transcode settings on the server, and nothing seems to make a difference.

 

A few things about my setup.

 

Latest Emby running in Docker

ASRock C2750D41 (Avoton Octacore)

12GB Ram

 

Any thoughts or ideas are appreciated.

Yeah... I had no problems with transcoding on Plex with the C2750.

 

I don't normally have to do more than one transcode at a time since all my local content streams direct.

 

I'm experimenting now, but haven't found any way to improve it.

 

I'm still not looking back... So far I really like Emby.

 

Any ideas to improve the performance?

 

 

 

 

Sent from my A0001 using Tapatalk

Do you know if it wad using hardware decoding with plex? Were you using a docker previously?

 

Sent from my ONEPLUS A3000 using Tapatalk

[BAlGaInTl 279]

Do you know if it wad using hardware decoding with plex? Were you using a docker previously?

 

Sent from my ONEPLUS A3000 using Tapatalk

 

I don't believe it was using hardware with Plex.  Not sure if you can tell from the commands above.  I thought that was a feature for PlexPass and I wasn't a subscriber.

 

This is my first time using docker.  The old Plex install is not in a docker.

 

I use OMV, and there is no longer a supported plugin (extra) for Emby on OMV 3.X.  That's why I thought I would "try" it with docker.  Other than the hiccup with my TV recordings, it is working great.  I already bought a lifetime premiere membership and plan to keep plugging at it.

[Jdiesel 1113]

I discovered something interesting today.....

 

I was playing around and noticed that even when I'm doing a transcode, CPU utilization is only at about 20-30% for all of my cores.  I've set Emby's transcoding setting to disable throttling.

 

Is this normal?

 

I'm pretty sure my utilization was much higher with plex, and wasn't a big deal since I don't transcode a lot.

 

Why is Emby being so nice?

 

See attached.

 

EmbyTrancodeSetting.PNG

 

EmbyCPU.PNG

It may just be the difference between the default settings that are automatically selected between Plex and Emby. Plex may just be selecting more conservative transcode settings. It appears by default Emby, when using the "Auto" setting, is defaulting to "veryfast" preset. Try manually selecting "superfast" and see if that improves your performance. I would also try lowering your CRF setting to "26" instead of "28". 

Edited March 9, 2017 by Jdiesel

[BAlGaInTl 279]

It may just be the difference between the default settings that are automatically selected between Plex and Emby. Plex may just be selecting more conservative transcode settings. It appears by default Emby, when using the "Auto" setting, is defaulting to "veryfast" preset. Try manually selecting "superfast" and see if that improves your performance. I would also try lowering your CRF setting to "26" instead of "28". 

 

Maybe I'm thinking of it wrong... but wouldn't dropping from 28 to 26 for the CRF increase load on the CPU? 

[Jdiesel 1113]

I am by no means an encoding guru but my thoughts on CRF are that the closer the value is to 1 the less compression that is applied to the video. As the number increases the filesize decreases at the expense of more compression being applied. Now whether or not applying more compression to a video requires more CPU horsepower is unknown to me as I have never really tested it myself. 

 

It is also worth noting that the CRF is only a target and may not be achievable based on the quality settings the client is requesting. Based on the transcoding log you provided at a requested bitrate of 4 Mbps the CRF is actually 31. I would suggest trying the "superfast" preset as your are almost there with raw live tv feeds.  

Edited March 9, 2017 by Jdiesel