optimalt 10 Posted January 29, 2017 Share Posted January 29, 2017 (edited) Don't know if this problem is related to Emby in general or the MediaPortal-plugin, but interlaced SD-channels won't play in Chrome or Chromecast. I'm not sure, but I think that Chrome and CC does not support interlaced video and that the channels should be transcoded, but instead they are remuxed. In Chrome I just get a black screen and on Chromecast I only get sound. HD-channels works fine. Provided are the serverlogs and mediainfo from the mediaportal timeshift folder. Thank you. Mediainfo.txt ffmpeg-remux-f8ebdaa4-9d86-451c-aad2-adb73637eeaf.txt server-63621244800.txt Edited January 29, 2017 by optimalt Link to comment Share on other sites More sharing options...
Luke 36999 Posted January 29, 2017 Share Posted January 29, 2017 Thanks for the report. Link to comment Share on other sites More sharing options...
pünktchen 1251 Posted January 29, 2017 Share Posted January 29, 2017 I often also see that interlaced detection by ffpobe fails. As a further rule i would suggest, that if the average framerate is exactly the half of the real framerate, then it must be interlaced content. 1 Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 7, 2017 Author Share Posted February 7, 2017 (edited) Is this fixable? Can I expect future versions of Emby server to be able to detect and transcode interlaced tv channels? Edited February 7, 2017 by optimalt Link to comment Share on other sites More sharing options...
Luke 36999 Posted February 7, 2017 Share Posted February 7, 2017 Can you please provide a new set of logs with the latest server version? Thanks ! Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 7, 2017 Author Share Posted February 7, 2017 Can you please provide a new set of logs with the latest server version? Thanks ! Sure! Mediainfo.txt ffmpeg-remux-e9dccff3-d1b2-4453-af28-0c2113f50758.txt server-63622022400.txt Link to comment Share on other sites More sharing options...
Luke 36999 Posted February 8, 2017 Share Posted February 8, 2017 @@pünktchen there is no interlaced detection when probing, because it is just too slow. we will just have to assume interlaced for the external live tv plugins. Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 14, 2017 Author Share Posted February 14, 2017 I think tv channels are either interlaced or not and that this does not change over time. So maybe a one-time (slow and accurate) probing per channel would work? The result from the one time probing could be stored and reused by the server. Maybe "tv-channel-probing" could be a scheduled task as well. Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 16, 2017 Author Share Posted February 16, 2017 @@Luke. Did you change something in Version 3.2.1.0? Now all tv-channels transcodes, even progressive HD and other non interlaced channels. The quality is really bad in Chrome and Chromecast and my tvserver can't handle transcoding even one 1080p 50hz channels. In 3.2.0.0 everything direct played and all was good (except interlaced channels). Please change it back. I would much rather have Emby not detecting deinterlaced channels than the way it is now. Thank you. Link to comment Share on other sites More sharing options...
Luke 36999 Posted February 16, 2017 Share Posted February 16, 2017 I thought you said it couldn't play at all before? Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 17, 2017 Author Share Posted February 17, 2017 Sorry if I was unclear: Interlaced channels couldn't play (and still can't with 3.2.1.0 so nothing is solved). All other channels (720p/50fps and 1080p/50fps) played perfect. Now everything is transcoded in bad quality and my tv-server can't cope. Link to comment Share on other sites More sharing options...
Luke 36999 Posted February 17, 2017 Share Posted February 17, 2017 ok, we'll remove it. the browsers and chromecast don't have any deinterlacing so if we send them the original video and it doesn't play, there's nothing we can do other than transcode it. Link to comment Share on other sites More sharing options...
optimalt 10 Posted February 17, 2017 Author Share Posted February 17, 2017 Ok, understood. Thank you for removing and trying to fix. Link to comment Share on other sites More sharing options...
Luke 36999 Posted March 8, 2017 Share Posted March 8, 2017 @@optimalt what kind of tuner do you have? Link to comment Share on other sites More sharing options...
optimalt 10 Posted March 9, 2017 Author Share Posted March 9, 2017 @@optimalt what kind of tuner do you have? For terrestrial? A TBS6290 DVB-T2/T/C Dual Tuner Dual CI PCIe Card Link to comment Share on other sites More sharing options...
optimalt 10 Posted April 11, 2017 Author Share Posted April 11, 2017 @@Luke The unnecessary live-tv-transcoding which makes Emby unusable for me (mentioned in post #11) is back in server 3.2.11.0 and 3.2.12.0. No matter what bitrate setting I use everything is transcoded in (very) bad quality and my tv-server can't cope. In 3.2.7.0 all HD-channels direct played. Link to comment Share on other sites More sharing options...
Luke 36999 Posted April 13, 2017 Share Posted April 13, 2017 @@optimalt can you please attach an ffmpeg log? thanks ! Link to comment Share on other sites More sharing options...
optimalt 10 Posted April 14, 2017 Author Share Posted April 14, 2017 Logs are attached. This HD-channel (720p 50fps aprox. 14Mbps) direct plays in Chrome and on a Chromecast with server version 3.2.7.0. With the latest stable version it transcodes to 3 Mbps no matter the bitrate setting. The quality loss going from 14 to 3 Mbps is bery big. The logs are from a test with the latest stable server. ffmpeg-transcode-a6b6af89-899e-4380-bfca-4914079cc352.txt server-63627803427.txt Link to comment Share on other sites More sharing options...
Luke 36999 Posted April 14, 2017 Share Posted April 14, 2017 It transcodes to 3mbps because that's the bitrate we have on file for it. It looks like the process of probing did not produce a bitrate and so we dummied it up at 3mbps, although we can raise that dummy value. Link to comment Share on other sites More sharing options...
Luke 36999 Posted April 14, 2017 Share Posted April 14, 2017 i doubt the input is actually 14mbps though. Where are you getting that from? Input #0, mpegts, from 'https://#REPLACED#/Stream/TV?item=162&transcoder=Direct': Duration: N/A, start: 0.138167, bitrate: N/A Program 137 Stream #0:0[0x30]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Stream #0:1[0x40]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s Link to comment Share on other sites More sharing options...
optimalt 10 Posted April 14, 2017 Author Share Posted April 14, 2017 Mediainfo Link to comment Share on other sites More sharing options...
optimalt 10 Posted April 14, 2017 Author Share Posted April 14, 2017 I'ts actually closer to 15. 14 is The video only. Link to comment Share on other sites More sharing options...
Luke 36999 Posted April 17, 2017 Share Posted April 17, 2017 To be honest, this is really the correct behavior because chromecast does not have any deinterlacing support. This is what we should be doing by default. In your case, you'd rather live with the interlaced video than transcode it on the server, and we currently just don't have a setting to allow you to specify that. Link to comment Share on other sites More sharing options...
optimalt 10 Posted April 17, 2017 Author Share Posted April 17, 2017 I think tv channels are either interlaced or not and that this does not change over time. So maybe a one-time (slow and accurate) probing per channel would work? The result from the one time probing could be stored and reused by the server. Maybe "tv-channel-probing" could be a scheduled task as well.What about this suggestion? Link to comment Share on other sites More sharing options...
Luke 36999 Posted April 18, 2017 Share Posted April 18, 2017 Well we probe anyway to determine other information such as available audio streams, available subtitle streams, etc. So if we move to a one-time probe then we lose that program-specific data. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now