TopSideControl 11 Posted November 14, 2016 Share Posted November 14, 2016 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. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted November 17, 2016 Author Share Posted November 17, 2016 Anyone? Link to comment Share on other sites More sharing options...
ebr 14958 Posted November 17, 2016 Share Posted November 17, 2016 I believe this is just the video player adapting its playback while it buffers in enough content to show at full resolution. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted November 20, 2016 Author Share Posted November 20, 2016 So there is no way to buffer before starting the playback? Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted January 18, 2017 Author Share Posted January 18, 2017 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? Link to comment Share on other sites More sharing options...
Luke 37232 Posted January 18, 2017 Share Posted January 18, 2017 This is improved for the next release of emby server, thanks. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted January 18, 2017 Author Share Posted January 18, 2017 Is this in the beta or dev branch or do you mean further than that? Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 12, 2017 Author Share Posted June 12, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 12, 2017 Share Posted June 12, 2017 hi @@TopSideControl, it's something we'll look to improve in a future update, thanks ! Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 12, 2017 Author Share Posted June 12, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 12, 2017 Share Posted June 12, 2017 Can you please provide a new ffmpeg log? I am not seeing this to the extent that are you describing. Thanks. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 13, 2017 Author Share Posted June 13, 2017 Logs attached. Started playing fine and then I selected 3 points along the duration to seek to and reproduce the issue. Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 13, 2017 Share Posted June 13, 2017 Where are they attached? thanks. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 13, 2017 Author Share Posted June 13, 2017 Sorry my bad, forgot to click the button. Should be there now. logs.zip Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 13, 2017 Share Posted June 13, 2017 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. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 13, 2017 Author Share Posted June 13, 2017 Done and problem still remains. Logs attached again. logs.zip Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 13, 2017 Share Posted June 13, 2017 can you provide a sample video for testing? thanks. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 13, 2017 Author Share Posted June 13, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 14, 2017 Share Posted June 14, 2017 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. Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 14, 2017 Author Share Posted June 14, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37232 Posted June 14, 2017 Share Posted June 14, 2017 In what app? Link to comment Share on other sites More sharing options...
TopSideControl 11 Posted June 14, 2017 Author Share Posted June 14, 2017 All that I tested so far, web player, app.media.envy, theater app. Sent from my SM-G920F using Tapatalk Link to comment Share on other sites More sharing options...
Pittiplatsch 2 Posted July 2, 2017 Share Posted July 2, 2017 (edited) 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 Link to comment Share on other sites More sharing options...
Pittiplatsch 2 Posted July 2, 2017 Share Posted July 2, 2017 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 Link to comment Share on other sites More sharing options...
Luke 37232 Posted July 2, 2017 Share Posted July 2, 2017 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. 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