Interlaced SD-channels won't play in Chrome or Chromecast

[optimalt 10]

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

[Luke 42077]

Thanks for the report.

[pünktchen 1409]

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.

[optimalt 10]

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

[Luke 42077]

Can you please provide a new set of logs with the latest server version? Thanks !

[optimalt 10]

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

[Luke 42077]

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

[optimalt 10]

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.

[optimalt 10]

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

[Luke 42077]

I thought you said it couldn't play at all before?

[optimalt 10]

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.

[Luke 42077]

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.

[optimalt 10]

Ok, understood. Thank you for removing and trying to fix.

[Luke 42077]

@@optimalt what kind of tuner do you have?

[optimalt 10]

@@optimalt what kind of tuner do you have?

For terrestrial? A TBS6290 DVB-T2/T/C Dual Tuner Dual CI PCIe Card

[optimalt 10]

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

[Luke 42077]

@@optimalt can you please attach an ffmpeg log? thanks !

[optimalt 10]

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

[Luke 42077]

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.

[Luke 42077]

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

[optimalt 10]

Mediainfo

[optimalt 10]

I'ts actually closer to 15. 14 is The video only.

[Luke 42077]

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.

[optimalt 10]

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?

[Luke 42077]

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.