Poor quality when transcoding and time scrubbing

[TopSideControl 11]

Version 3.0.8500.0

 

I can't remember if this came up before or not. I've tested both firefox & chrome. When starting a video or when seeking the video goes very pixelated for some time (maybe twenty seconds) and then goes perfect. Seems to happen to all media. Transcoding it enabled as I'm remote to the media server. 

 

 

[TopSideControl 11]

Anyone?

[ebr 16169]

I believe this is just the video player adapting its playback while it buffers in enough content to show at full resolution.

[TopSideControl 11]

So there is no way to buffer before starting the playback? 

[TopSideControl 11]

Sorry to bump this but I've been travelling a lot lately so using the web client much more and I'd like to try and resolve it if possible. 

 

If there anything I can do to improve or prevent this?

[Luke 42077]

This is improved for the next release of emby server, thanks.

[TopSideControl 11]

Is this in the beta or dev branch or do you mean further than that?

[TopSideControl 11]

Hi All, 

 

I posted about this issue before and I've seen a few other posting similar issues about quality during transcoding. My old thread is here for reference, https://emby.media/community/index.php?/topic/41406-pixelatedblocky-on-start-or-seek/

 

I mainly use emby to access my system remotely and I have the same issue using any client (kodi, web browser, app.emby.media, & the theater player) to access my media. I also have DVBlink server installed to manage my physical tuners & IPTV. 

 

When I try to watch any media remotely (including recorded TV) via the emby transcoding process, playback will start OK but if I try to seek the video pixelates badly and it takes around 40 seconds before it returns to normal. 

 

If I watch the same recorded TV via the DVBlink player (and still transcoding using ffmpeg) I can seek without an issue. 

 

I've tried changing all sorts of transcoding settings but none seem to improve it. Is there anything that can be done to resolve this within Emby? Since playback begins OK why is there only an issue when seeking?

 

Thanks

Brian

[Luke 42077]

hi @@TopSideControl, it's something we'll look to improve in a future update, thanks !

[TopSideControl 11]

Hi @@Luke,

 

Is there anything more concrete than a future update? It's probably the only reason I'm paying for premium and I was told 'next update' back in January. 

 

Thanks

Brian

[Luke 42077]

Can you please provide a new ffmpeg log? I am not seeing this to the extent that are you describing. Thanks.

[TopSideControl 11]

Logs attached. 

 

Started playing fine and then I selected 3 points along the duration to seek to and reproduce the issue. 

[Luke 42077]

Where are they attached? thanks.

[TopSideControl 11]

Sorry my bad, forgot to click the button. Should be there now. 

logs.zip

[Luke 42077]

Try deleting this folder

C:\emby.windows\ffmpeg\20160410

on next startup the server will re-download and it will be newer. see if that helps.

[TopSideControl 11]

Done and problem still remains. 

 

Logs attached again. 

logs.zip

[Luke 42077]

can you provide a sample video for testing? thanks.

[TopSideControl 11]

You can download a ts recording from the dropbox url but to be honest you can reproduce this easily. 

 

https://www.dropbox.com/s/8fhu2zhszist79c/Neighbours.1345.20170609.Channel%205.ts?dl=0

[Luke 42077]

We'll continue looking at it. in this file, yes, it is a little worse than my test recordings, although i'm not yet sure what the difference is. I have .ts recordings with mpeg2video and interlaced, and the pixelation on seek only lasts a second or two and is much less noticeable, really to the extent that it's a non issue. This file for whatever reason is a little different. It is lower resolution so that could be a factor.

[TopSideControl 11]

If it was just my recordings then I'd be willing to understand that but it's every video I have, including over a 1tb of torrents. Thanks for following up though.

 

Sent from my SM-G920F using Tapatalk

[Luke 42077]

In what app?

[TopSideControl 11]

All that I tested so far, web player, app.media.envy, theater app.

 

Sent from my SM-G920F using Tapatalk

[Pittiplatsch 2]

Hi there,

 

I'm running Emby server (3.2.20.0) within a Docker container on a Ubuntu host on a small NAS (Intel Pentium G4600 HT, 16GB RAM).

 

My source files are usually MKV's (h264) with multiple audio (AAC) and subtitle (VobSub or PGS) tracks. I'm using Emby's web interface (Firefox 54 32-bit on Windows 7) to play the media back. As long I don't display the subtitles everything is working fine because 'Direct Streaming' is used. With subtitles enabled Emby is using transcoding to burn in the pictured based subtitles. I fully understand why 'Direct Streaming' isn't available here. If I start the movie from the beginning (with subtitles enabled) everything is working fine as well, the video quality is quite good, almost like the original encoding. The burnt-in subtitles are a bit blurry, it would be nice if I could improve this too, but on the other hand I think I could live with it.

 

But problems are coming up when jumping in time, no matter if a use the resume playback feature of Emby, the chapter selection or just scrubbing the time slider. The video quality is getting really poor and it takes up to 4 minutes of continuous playback before it is returning to a 'normal' level. It's a bit of annoying, because all the methods I mentioned above are quite useful in certain circumstances.

 

I already played around with the transcoding settings in Emby. It seems influence the time period before the video playback quality is becoming better again a little, esp. the H264 encoding profile settings, but won't affect it too much in a acceptable manner. It would be alright, if it would take a couple of seconds only before the video quality is getting better. I think we are used to a similar behavior with video streaming in general and I absolutely could live with it. But waiting multiple minutes isn't that great at all.

 

I also transcoded the source video manually by executing ffmpeg with the settings taken from the transcoding log. The resulting quality was actually okay and quite fast, so I assume the actual transcoding settings might not be the problem here?

 

Any ideas what I can do to improve it?

 

Thanks a lot,
Peter

server-63634595382.txt

ffmpeg-transcode-14909a08-d7e8-423c-85fa-e97e93f0f60b.txt

Edited July 2, 2017 by Pittiplatsch

[Pittiplatsch 2]

Hi again,

 

in the meanwhile I had a closer look at the transcoding log. I'm not that familiar with ffmpeg, but I wonder whats going on in the first 1000 frames:

frame=  153 fps=0.0 q=32.0 size=N/A time=00:51:21.27 bitrate=N/A speed=6.16e+03x    
frame=  311 fps=310 q=25.0 size=N/A time=00:51:27.59 bitrate=N/A speed=3.08e+03x    
frame=  470 fps=313 q=24.0 size=N/A time=00:51:33.95 bitrate=N/A speed=2.06e+03x    
frame=  622 fps=311 q=30.0 size=N/A time=00:51:40.03 bitrate=N/A speed=1.55e+03x    
frame=  783 fps=313 q=33.0 size=N/A time=00:51:46.47 bitrate=N/A speed=1.24e+03x    
frame=  925 fps=307 q=35.0 size=N/A time=00:51:52.17 bitrate=N/A speed=1.03e+03x  

Is q=* indicating the resulting quality? Is it the same 'measurement' you would usually do with h264 by defining the target quality with CRF? So a value of 32 or even higher might indicate a very bad quality, because a good result would usually achieved with a value something between 18 and 23?

 

Thanks,
Peter

[Luke 42077]

hi @@Pittiplatsch, in my experience testing this, it is seconds and not minutes that this occurs after a seek. can you test Chrome? how does that compare? thanks.