Live TV initial pause, pixelation, and long pauses

[mwongjay 64]

 

Can you please see if the specific issue of the stream pausing after only a second or two is improved with the beta version 1.4.10?  Thanks.

 

 

Before 1.4.10 - Clicking on a channel to actually viewing the stream was quick. However, as mentioned earlier there would be a long delay mid-stream.

After 1.4.10 - Clicking on a channel to actually viewing the stream is NOT quick. Takes about 4 seconds, however, there no longer is a delay mid-stream. 

 

 

[mwongjay 64]

1.4.10 does not seem to fix the picture issues I posted about earlier. I'm still seeing a lot of picture distortion. Is this issue planning on being resolved before the official version is released? 

 

Attached are the logs. Picture issues were occurring for sure from 7:40PM - 7:44PM

 

 

Edited May 30, 2017 by mwongjay

[maegibbons 1267]

Hi @@ebr

 

In relation specifically to the pause issue a few seconds in. 1.4.10 has fixed it for me.  I do not suffer from the picture issues.

 

However, I would say 1.4.10 adds about 2 seconds to HDhomerun stream startup time which means we are at about 12-13 seconds now.  IPTV streams conversly are super snappy in the 2-3 seconds start time range.

 

Krs

 

Mark

[ebr 14903]

1.4.10 does not seem to fix the picture issues I posted about earlier. I'm still seeing a lot of picture distortion. Is this issue planning on being resolved before the official version is released? 

 

Attached are the logs. Picture issues were occurring for sure from 7:40PM - 7:44PM

 

I don't believe those are related to the app so I don't think there is anything the app can do about it.  We are looking at the server side.

[ebr 14903]

 

 

 

 

Before 1.4.10 - Clicking on a channel to actually viewing the stream was quick. However, as mentioned earlier there would be a long delay mid-stream.

After 1.4.10 - Clicking on a channel to actually viewing the stream is NOT quick. Takes about 4 seconds, however, there no longer is a delay mid-stream. 

 

 

Hi @@ebr

 

In relation specifically to the pause issue a few seconds in. 1.4.10 has fixed it for me.  I do not suffer from the picture issues.

 

However, I would say 1.4.10 adds about 2 seconds to HDhomerun stream startup time which means we are at about 12-13 seconds now.  IPTV streams conversly are super snappy in the 2-3 seconds start time range.

 

Krs

 

Mark

 

Pick your poison - Either we start playing the stream before it is really ready and, thus, cause the player to have to wait a couple seconds at some point after it starts, or we wait until the stream is truly ready and there is no pause.

[maegibbons 1267]

Hi

 

It is probably best to wait till its ready.

 

My main observation was that the length of time 12-13 seconds is a long time for a HDHomerun stream especially compared to 2-3 seconds for a IPTV stream.

 

Krs

 

Mark

[FordGT90Concept 61]

Direct TV off: It took a *really* long time to tune (20 seconds probably, unacceptable) then frequently pixelated thereafter.

 

Direct TV on: It tuned fast (4 seconds maybe, hugely improved from previous), pixelated thereafter.

 

HDHomeRun (direct TV only): It tuned the fastest (2 seconds maybe), no pixilation but minor audio hiccup (much more acceptable than pixilation) then fine.

 

Still set to MPEG4 heavy profile in the HDHomeRun EXTENDs.

[ebr 14903]

Direct TV on: It tuned fast (4 seconds maybe, hugely improved from previous), pixelated thereafter.

 

We're pulling the stream directly from the tuner in this case so any visual anomalies either have to be in the stream transport or the processing that is being done by the player involved.

 

Can you try with the option to use VLC both on and off (with the direct option also on)?

[FordGT90Concept 61]

VLC was enabled for the above testing.  With VLC disabled and Direct TV enabled, the stream took longer to load than Direct TV disabled, there was visible tearing, minor audio glitches, and and bad pixelation. In my estimation, disabling VLC is worse by every metric.

 

Friendly reminder, my testing on a Shield TV 2017.

Edited May 31, 2017 by FordGT90Concept

[ebr 14903]

VLC was enabled for the above testing.  With VLC disabled and Direct TV enabled, the stream took longer to load than Direct TV disabled, there was visible tearing, minor audio glitches, and and bad pixelation. In my estimation, disabling VLC is worse by every metric.

 

Friendly reminder, my testing on a Shield TV 2017.

 

I'm at a loss as I always use the internal player and never see any issues like that.

[FordGT90Concept 61]

Uh, what should the transcoding folder look like?  Because there's only one active stream, a ffmpeg remux log, and the transcoding-temp file is getting a crapload of small files made (one every second or two probably).

 

I think those little files might be the source of the problem.  The big file you see is the only one that should exist.  I can't confirm this but I think all those little files are where the pixelations occur.

 

 

 

So I tried a bunch of settings.  So far, it looks like the best is disabling direct, VLC, and forcing direct audio.  This leads to the cleanest picture but starting the stream takes 10+ seconds and the initial pause still occurs (it wasn't supposed to in this build, right?).

Edited May 31, 2017 by FordGT90Concept

[Luke 37007]

 The big file you see is the only one that should exist.

That isn't true. They serve different purposes.

[FordGT90Concept 61]

I'm no expert on the matter but this is Server 2012 R2 with Active Directory running.  Creating any new files invokes quite a lot of file system overhead that could easily lead to problems with streaming.  If Emby can get by with one growing file, it should because that eliminates most of the file system overhead.  No idea if that's the root of the issue or not though.

[FordGT90Concept 61]

Through the web app, it actually appears to be working decent right now.  I don't know what changed in the last 24-48 hours but, yeah.

 

 

That said, this has bothered me for a while.  It appears that Emby's player doesn't deinterlace where, for example, MPC-HC does.  I was playing Emby through web + MPH-HC direct from HDHomeRun side by side and took a screenshoot.  Put a red box around the really bad spot, for example, but look all over the picture and it's there. I kept it PNG so JPEG compression won't smudge it anymore than it already is so it's a big picture.

[mwongjay 64]

I'm at a loss as I always use the internal player and never see any issues like that.

 

I've been changing lots of settings to test various things. Nothing seems to make the picture better. It appears you are not experiencing the same issues. Would you tell me what settings, related to picture quality, you have your server and client set on so I can see if these issues go away or is it not that simple? 

[mwongjay 64]

Also, is there a way to transcode 100% of the time for all content? It seems that anything that is transcoded appears to play fine at this point although I'd need to test further. I used to be running Emby in a docker without hardware acceleration. I have since switched my setup to a VM to leverage a gpu for hardware acceleration to see if that would help with the pausing and/or picture issues. In my case I don't think this would cause any additional streaming issues as the speed identified in the transcoding log is between 20-80x 

[FordGT90Concept 61]

I've been changing lots of settings to test various things. Nothing seems to make the picture better. It appears you are not experiencing the same issues. Would you tell me what settings, related to picture quality, you have your server and client set on so I can see if these issues go away or is it not that simple? 

 

I really didn't change anything in the server but basically...

 

HDHomeRun Extent: heavy transcode profile

 

Server: pretty much everything in regards to transcoding/live TV is default.  HDHomeRun's are set to enable their internal hardware transcoding so it delivers the profile above.

 

Android TV:

​-Bandwidth: Auto

-Audio: Direct (to be honest, doesn't make much difference I think)

-Direct: false

-VLC: false I think this is most important.​ It's really the only thing I changed.

-External: false

Edited May 31, 2017 by FordGT90Concept

[mwongjay 64]

I really didn't change anything in the server but basically...

 

HDHomeRun Extent: heavy transcode profile

 

Server: pretty much everything in regards to transcoding/live TV is default.  HDHomeRun's are set to enable their internal hardware transcoding so it delivers the profile above.

 

Android TV:

​-Bandwidth: Auto

-Audio: Direct (to be honest, doesn't make much difference I think)

-Direct: false

-VLC: false I think this is most important.​ It's really the only thing I changed.

-External: false

 

Sorry, I suppose I should've been more clear. I was directing my question at ebr since I believe he said he doesn't have any picture issues.

 

The other day I tried looking for the heavy transcode profile, but couldn't find it in Emby settings or on the HDHomeRun devices. My tuners are HDHomeRun Primes which I suspected is the reason I couldn't find it. The only options I have for transcoding is from the Emby server live tv settings that allows the tuners to transcode unless I'm missing something.

[FordGT90Concept 61]

Only the HDHomeRun EXTEND transcodes.  Other models lack the transcoding options.

 

I had CONNECTs and changed to EXTENDs because whenever my server started transcoding, video problems would occur.  Still don't know why (Xeon E5-1230V3) because it's more than capable of doing it.  It could easily be that transcoding is your problem as well.  My server has other stuff to do as well so taking the transcoding load off it was a win all around.

Edited May 31, 2017 by FordGT90Concept

[ebr 14903]

I have an HDHR Connect which is the OTA version without internal transcoding.  My server Live TV settings are at default and I usually have direct stream turned off in the app because that enables trick play (pause, rewind, ff).

[mwongjay 64]

I have an HDHR Connect which is the OTA version without internal transcoding.  My server Live TV settings are at default and I usually have direct stream turned off in the app because that enables trick play (pause, rewind, ff).

 

Does Emby identify whether the tuner is capable of hardware transcoding? The settings for each tuner on my server show an option to allow internal transcoding on the Primes. If Ford is right and the Primes don't have internal transcoding does that option make any difference -- does it negatively impact anything? 

Edited May 31, 2017 by mwongjay

[Luke 37007]

Does Emby identify whether the tuner is capable of hardware transcoding? The settings for each tuner on my server show an option to allow internal transcoding on the Primes. If Ford is right and the Primes don't have internal transcoding does that option make any difference -- does it negatively impact anything? 

 

Yes we do identify that. Nothing to worry about here.

[FordGT90Concept 61]

So, the pixelation is back with a vengence today.  I think version 3.2.17.20 beta was fine.  I'm on 3.2.18.1 beta right now.  I see 3.2.19.0 available so I'm installing that now...

 

 

Edit: 3.2.19.0 appears to have fixed everything but the long time to tune.  I can live with that though.

Edited June 1, 2017 by FordGT90Concept

[mwongjay 64]

So, the pixelation is back with a vengence today.  I think version 3.2.17.20 beta was fine.  I'm on 3.2.18.1 beta right now.  I see 3.2.19.0 available so I'm installing that now...

 

 

Edit: 3.2.19.0 appears to have fixed everything but the long time too tune.  I can live with that though.

 

 

Emby Server: v3.2.19

Fire TV Box: v5.2.4.1

Fire TV App: v1.4.12a

 

Dang, you had me excited to get home to update and test. Unfortunately, I still have deinterlacing issues. In my situation it takes about 4-5 seconds to begin streaming which was about the same as 3.2.17

 

Also, decided to try using the VLC player. Doesn't make any difference.

Edited June 1, 2017 by mwongjay

[mwongjay 64]

Finally looked into the issue of interlaced video and I reviewed my most recent transcoding log which showed this 

{"Protocol":"Http","Id":"74f494ac0c874bb2b1b410751942e3ea_native_5267ad3b1291e13ac30f93c5fa45d0a2_258d83507050d7a2a0f9fbbe9e4671be","Path":"http://127.0.0.1:8096/LiveTv/LiveStreamFiles/44e0e712e3b34ae4a38dfe8f572fdc99/stream.ts","Type":"Default","Container":"mpegts","IsRemote":false,"ReadAtNativeFramerate":false,"IgnoreDts":true,"IgnoreIndex":false,"GenPtsInput":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":false,"IsInfiniteStream":true,"RequiresOpening":true,"RequiresClosing":true,"SupportsProbing":true,"LiveStreamId":"a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_74f494ac0c874bb2b1b410751942e3ea_native_5267ad3b1291e13ac30f93c5fa45d0a2_258d83507050d7a2a0f9fbbe9e4671be","BufferMs":0,"RequiresLooping":false,"MediaStreams":[{"Codec":"mpeg2video","TimeBase":"1/90000","CodecTimeBase":"1001/30000","IsInterlaced":true,"BitRate":20000000,"RefFrames":1,"IsDefault":false,"IsForced":false,"Height":1080,"Width":1920,"AverageFrameRate":29.97003,"RealFrameRate":29.97003,"Profile":"Main","Type":"Video","AspectRatio":"16:9","Index":0,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"PixelFormat":"yuv420p","Level":4,"IsAnamorphic":false},{"Codec":"ac3","Language":"eng","TimeBase":"1/90000","CodecTimeBase":"1/48000","DisplayTitle":"Eng Dolby Digital 5.1","IsInterlaced":false,"ChannelLayout":"5.1","BitRate":448000,"Channels":6,"SampleRate":48000,"IsDefault":false,"IsForced":false,"Type":"Audio","Index":1,"IsExternal":false,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Level":0}],"PlayableStreamFileNames":[],"Formats":[],"Bitrate":20448000,"RequiredHttpHeaders":{},"AnalyzeDurationMs":2000,"DefaultAudioStreamIndex":1}

"IsInterlaced":true

 

It appears interlace detection is working appropriately, however, when I review the command for ffmpeg it doesn't appear to be doing deinterlacing with yadif. 

/var/lib/emby-server/ffmpeg/20170308/ffmpeg -analyzeduration 2000000 -fflags +igndts -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/44e0e712e3b34ae4a38dfe8f572fdc99/stream.ts" -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 copy -flags -global_header -vsync cfr -codec:a:0 aac -strict experimental -ac 2 -ab 128000 -af "volume=2" -f segment -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_list_entry_prefix "hls/accf77caa71196bfdf9c7e5f1232bec4/" -segment_list_type m3u8 -segment_start_number 0 -segment_list "/var/lib/emby-server/transcoding-temp/accf77caa71196bfdf9c7e5f1232bec4.m3u8" -y "/var/lib/emby-server/transcoding-temp/accf77caa71196bfdf9c7e5f1232bec4%d.ts"

In contrast, this is from a command when I had an issue with something else, but live tv WAS being deinterlaceds and working (Dec 2016): https://emby.media/community/index.php?/topic/43181-live-tv-transcoding-failing/?p=402368

/bin/ffmpeg -fflags +genpts -i "http://127.0.0.1:8096/LiveTv/LiveStreamFiles/03daf6e6462648fa86926d9650635fad/stream.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 23 -tune zerolatency -maxrate 3000000 -bufsize 6000000 -vsync -1 -profile:v high -level 4.1 -force_key_frames "expr:gte(t,n_forced*3)" -vf "yadif=0:-1:0" -flags -global_header -fflags +genpts -sc_threshold 0 -codec:a:0 aac -strict experimental -ac 2 -ab 384000 -af "adelay=1,aresample=async=1,volume=2" -hls_time 3 -start_number 0 -hls_list_size 0 -hls_base_url "hls/350eaa8a3fe5ddc1f8fc1be06c1cf380/" -y "/config/transcoding-temp/350eaa8a3fe5ddc1f8fc1be06c1cf380.m3u8"

"yadif=0:-1:0"

 

As you can see the server was at one point using yadif to deinterlace the stream. What is the reason or what are the reasons for having removed this parameter? More importantly though, if nothing else is currently doing the deinterlacing can we just add this parameter back?

Edited June 1, 2017 by mwongjay