Transcoded stream consistently stop-starts every (x) minutes. (Win10 64bit, Java 8 64bit, UMS 6.2.0)
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
-
savoirvivre
- Posts: 2
- Joined: Mon Mar 21, 2016 3:26 pm
Transcoded stream consistently stop-starts every (x) minutes. (Win10 64bit, Java 8 64bit, UMS 6.2.0)
Hi,
Love UMS. Have had relatively flawless playback until recently when I changed the transcoding encoder from MPEG2 (automatic wireless) to h264 (automatic wireless). Maximum bandwidth is currently set to 100Mbps, but seems to have no impact whatsoever. At first the stream would stop completely a minute or two into any given stream, at which point I increased both the amount of memory Java could address (to 4096Mb) as well as the transcoding buffer size (to 3072Mb) -- after doing so the stream fails consistently every ~28 minutes. The buffer size seems key. I am using ffmpeg64 as the transcoder. I also modified an existing LG renderer config to fit my television -- an LG 60PB6900 plasma with SmartShare. I have adjusted the max bitrate within the renderer config file to no avail -- the lower the bitrate the longer the stream will play without stop-starting, but it will, eventually, stop-start. The lower the transcoder buffer the higher likelihood of the stream failing outright with an "unsupported file format" notice on my television.
The PC on which UMS operates is a Windows 10 Professional 64 bit system with 16Gb of ram, SATA III 7200RPM drives (separately mirrored data and storage drives), and an AMD 1055t. The machine is wired to a Gigabit router, while the television is connected via 802.11n (usually ~250Mbps). Transcoding performance does not seem to be an issue.
The attached logs are for an attempted transcode and stream of a 10 bit HEVC, 6 channel AAC encode of Battlestar Galactica (to h264/6 channel AC3) -- the first log is for a "MaxVideoBitrateMbps = 20" stream while the second log is for a "MaxVideoBitrateMbps = 50" stream, both failed at exactly the same time in exactly the same way. However, the failure is present regardless of the input format -- it fails just as readily on age old MPEG2 dvd rips. The modified config file is also present, as is the UMS config file.
The failure is replicable to a degree on other devices -- BubbleUPnP on a Nexus 6 fails at the exact same time (~500Mbps speed wifi), as does my Chromecast (~144Mbps via wifi), but it isn't a stop-start failure, the video freezes while the audio keeps playing.
I would have no issue continuing to use MPEG2, but increasing the bitrate causes the stream to fail in, you guessed it, the exact same fashion, just at a different time. The default MPEG2 bitrate leaves the stream looking blocky/blurry, but it performs without issue -- at least, it did in UMS 6.1.0.
I've included all of the info I can think of. If I can do any additional troubleshooting/testing, please instruct me.
Thank you!
Love UMS. Have had relatively flawless playback until recently when I changed the transcoding encoder from MPEG2 (automatic wireless) to h264 (automatic wireless). Maximum bandwidth is currently set to 100Mbps, but seems to have no impact whatsoever. At first the stream would stop completely a minute or two into any given stream, at which point I increased both the amount of memory Java could address (to 4096Mb) as well as the transcoding buffer size (to 3072Mb) -- after doing so the stream fails consistently every ~28 minutes. The buffer size seems key. I am using ffmpeg64 as the transcoder. I also modified an existing LG renderer config to fit my television -- an LG 60PB6900 plasma with SmartShare. I have adjusted the max bitrate within the renderer config file to no avail -- the lower the bitrate the longer the stream will play without stop-starting, but it will, eventually, stop-start. The lower the transcoder buffer the higher likelihood of the stream failing outright with an "unsupported file format" notice on my television.
The PC on which UMS operates is a Windows 10 Professional 64 bit system with 16Gb of ram, SATA III 7200RPM drives (separately mirrored data and storage drives), and an AMD 1055t. The machine is wired to a Gigabit router, while the television is connected via 802.11n (usually ~250Mbps). Transcoding performance does not seem to be an issue.
The attached logs are for an attempted transcode and stream of a 10 bit HEVC, 6 channel AAC encode of Battlestar Galactica (to h264/6 channel AC3) -- the first log is for a "MaxVideoBitrateMbps = 20" stream while the second log is for a "MaxVideoBitrateMbps = 50" stream, both failed at exactly the same time in exactly the same way. However, the failure is present regardless of the input format -- it fails just as readily on age old MPEG2 dvd rips. The modified config file is also present, as is the UMS config file.
The failure is replicable to a degree on other devices -- BubbleUPnP on a Nexus 6 fails at the exact same time (~500Mbps speed wifi), as does my Chromecast (~144Mbps via wifi), but it isn't a stop-start failure, the video freezes while the audio keeps playing.
I would have no issue continuing to use MPEG2, but increasing the bitrate causes the stream to fail in, you guessed it, the exact same fashion, just at a different time. The default MPEG2 bitrate leaves the stream looking blocky/blurry, but it performs without issue -- at least, it did in UMS 6.1.0.
I've included all of the info I can think of. If I can do any additional troubleshooting/testing, please instruct me.
Thank you!
- Attachments
-
- ums.rar
- (536.59 KiB) Downloaded 211 times
-
savoirvivre
- Posts: 2
- Joined: Mon Mar 21, 2016 3:26 pm
Re: Transcoded stream consistently stop-starts every (x) minutes. (Win10 64bit, Java 8 64bit, UMS 6.2.0)
Clean updated to 6.2.1 and manually set up all of the configs. Issue persists.
I have run a transcode via command line ffmpeg as well as GUI ffmpeg using the same settings that UMS is using to transcode and each file finished transcoding in 20-30 minutes, well ahead of the 43 minute runtime. The 8bit HEVC is decoded using DXVA (for GUI ffmpeg, anyway) so as to eat less CPU while 10bit HEVC is all CPU -- the issue persists regardless of which file is used.
Plex does not have an issue transcoding for what visually appears to be the same quality and it uses ffmpeg as well.
Some help with this would be great. Are there any more logs I can offer for troubleshooting?
I have run a transcode via command line ffmpeg as well as GUI ffmpeg using the same settings that UMS is using to transcode and each file finished transcoding in 20-30 minutes, well ahead of the 43 minute runtime. The 8bit HEVC is decoded using DXVA (for GUI ffmpeg, anyway) so as to eat less CPU while 10bit HEVC is all CPU -- the issue persists regardless of which file is used.
Plex does not have an issue transcoding for what visually appears to be the same quality and it uses ffmpeg as well.
Some help with this would be great. Are there any more logs I can offer for troubleshooting?