Quality Selection

[roberto188 33]

Please add the ability to select the streaming quality as either 720p or 1080p. I have a lot of 720p TV's with Roku's and my server is needlessly transcoding things to 1080p only to then be displayed on a 720p TV. I can save a lot on CPU power and bandwidth if I am able to select 720p rather than being forced to use 1080p. Also, limiting the bitrate to 4 megabits to "force" 720p isn't a great solution. A lot of the high motion at 4 Megabits @ 720p looks bad.

Edited September 22, 2017 by roberto188

[ebr 14905]

Hi.  What is leading you to believe that the resolution is being altered?

 

Can you post a couple of ffmpeg logs from playback of these items?  Thanks.

[roberto188 33]

I tried it twice this morning. When I select 8 megabits it transcodes the 1080 source to 1080. When I select 4 megabits it's transcodes the same 1080 source to 720. See the below:

 

8 Megabit

 

Input #0, mpegts, from 'http://127.0.0.1:8096/LiveTv/LiveStreamFiles/d93e5766109a4a01a803b428ec6e3bc1/stream.ts':
Duration: N/A, start: 59485.051756, bitrate: N/A
Program 752
Stream #0:0[0x1d61]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 1920x1080 [sAR 1:1 DAR 16:9], Closed Captions, max. 18000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1d62](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream #0:2[0x1d64]: Unknown: none ([5][0][0][0] / 0x0005)
Stream #0:3[0x1d66]: Unknown: none ([5][0][0][0] / 0x0005)
[libx264 @ 0000000003430a60] using SAR=1/1
[libx264 @ 0000000003430a60] MB rate (489110) > level limit (245760)
[libx264 @ 0000000003430a60] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0000000003430a60] profile Main, level 4.1
Output #0, segment, to 'C:\Users\Media Center\AppData\Roaming\Emby-Server\transcoding-temp\transcoding-temp\99dde8cabbc5f54edabd9ef1eacbac33%d.ts':
Metadata:
encoder : Lavf57.32.100
Stream #0:0: Video: h264 (libx264), yuv420p, 1920x1080 [sAR 1:1 DAR 16:9], q=-1--1, max. 7616 kb/s, 59.94 fps, 90k tbn, 59.94 tbc
Metadata:
encoder : Lavc57.34.100 libx264
Side data:
cpb: bitrate max/min/avg: 7616000/0/0 buffer size: 15232000 vbv_delay: -1
Stream #0:1: Audio: ac3, 48000 Hz, 5.1, fltp, 384 kb/s
Metadata:
encoder : Lavc57.34.100 ac3
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (ac3 (native) -> ac3 (native))
Press [q] to stop, [?] for help
frame= 86 fps=0.0 q=30.0 size=N/A time=00:00:01.06 bitrate=N/A dup=45 drop=0 speed=2.14x 

 

VS.  4 megabit

 

Input #0, mpegts, from 'http://127.0.0.1:8096/LiveTv/LiveStreamFiles/cba5e9347bb64b8ab14cf2fcef7477f7/stream.ts':
Duration: N/A, start: 62153.441644, bitrate: N/A
Program 752
Stream #0:0[0x1d61]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 1920x1080 [sAR 1:1 DAR 16:9], Closed Captions, max. 18000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1d62](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream #0:2[0x1d64]: Unknown: none ([5][0][0][0] / 0x0005)
Stream #0:3[0x1d66]: Unknown: none ([5][0][0][0] / 0x0005)
[libx264 @ 00000000037980c0] using SAR=1/1
[libx264 @ 00000000037980c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 00000000037980c0] profile Main, level 4.1
Output #0, segment, to 'C:\Users\Media Center\AppData\Roaming\Emby-Server\transcoding-temp\transcoding-temp\0c385d276a1362f0f8865494d8267188%d.ts':
Metadata:
encoder : Lavf57.32.100
Stream #0:0: Video: h264 (libx264), yuv420p, 1280x720 [sAR 1:1 DAR 16:9], q=-1--1, max. 3616 kb/s, 59.94 fps, 90k tbn, 59.94 tbc
Metadata:
encoder : Lavc57.34.100 libx264
Side data:
cpb: bitrate max/min/avg: 3616000/0/0 buffer size: 7232000 vbv_delay: -1
Stream #0:1: Audio: ac3, 48000 Hz, 5.1, fltp, 384 kb/s
Metadata:
encoder : Lavc57.34.100 ac3
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (ac3 (native) -> ac3 (native))
Press [q] to stop, [?] for help
[ac3 @ 0000000002fe0d60] frame sync error
Error while decoding stream #0:1: Invalid data found when processing input
frame= 108 fps=0.0 q=30.0 size=N/A time=00:00:01.46 bitrate=N/A dup=55 drop=0 speed=2.89x 

[ebr 14905]

Can you please attach the entire log as a file?  Thanks.

[roberto188 33]

 

Here ya go. 

Log1.txt

Log2.txt

[roberto188 33]

Any change on getting this implemented?

[Luke 37029]

It's a possibility for a future update. Thanks !

[Jdiesel 1113]

I would agree with this. Not really a Roku specific issue but Emby should respect the native resolution a little more carefully when transcoding. My preference would be to unlink resolution and bitrate from the quality setting to give users control over both. Like the user above I have 720p content with a bitrate above 4Mbps and any transcoding between 4Mbps and the original bitrate causes the video to be upscale to 1080p.

 

 

Edit: It is my opinion that a good 720p encode looks better than a bitrate starved 1080p encode, especially is the player does a good job of upscaling. As such I have quite a few 5-7Mbps 720p encodes that were made using a CRF value of 17 or 18. So in my case it is a pretty small window where a 6-7Mbps video needs to be transcoded into a 5 or 6Mbps video but it does happen on occasion. 

Edited September 25, 2017 by Jdiesel

[roberto188 33]

Does anyone know why if you set your Roku to 720p display type Emby still encodes to 1080p? Isn't the Roku app supposed to check the Roku "displayType" and if it's set to 720p it's supposed to set the "maxWidth" and "maxHeight" to 1280 and 720, which should presumably tell Emby to transcode everything to no higher than 1280 x 720? I think the Roku app is incorrectly reporting the maximum width and height of the Roku. If this got corrected, we could just set our Roku displays to 720p and that should force emby to not transcode any higher than that. 

[ebr 14905]

Does anyone know why if you set your Roku to 720p display type Emby still encodes to 1080p? Isn't the Roku app supposed to check the Roku "displayType" and if it's set to 720p it's supposed to set the "maxWidth" and "maxHeight" to 1280 and 720, which should presumably tell Emby to transcode everything to no higher than 1280 x 720? I think the Roku app is incorrectly reporting the maximum width and height of the Roku. If this got corrected, we could just set our Roku displays to 720p and that should force emby to not transcode any higher than that. 

 

Yes, we probably should be doing that - but only when we are already going to transcode for other reasons.  That is, I wouldn't want every 1080 video to be transcoded down to 720 on the server when the device can handle it just fine.

[roberto188 33]

Yes. Instead of using "displaytype" to achieve this you should use "videomode." As the current Roku app it is currently configured only if you are using a SD tv does it transcode to 720p. I was able to successfully implement the use of "video mode" to get emby to have a maximum transcode resolution of 720p or 1080 depending on what Roku display setting are set to.