[Solved] Video playback is jerky or stops immediately on specific videos

[the_57th_bob 0]

I have a bizarre problem with playback of some videos. It consistently occurs with the same videos, but the symptoms are different depending on the video. When one video has the problem, the others do to. The problems only appear on some client apps, but which clients the problems appear on is also consistent.

Here are two videos that exhibit the two problems.

The first is the video starting, then stopping immediately, or playing the sound only.

The server log for this problem is server-63635241600_hobbit.txt. server-63635241600_hobbit.txt

ffmpeg-remux-8f75321d-20d6-4e36-9e66-4b6d5c93f046.txt is transcoding for Safari on iOS 10, where playback stops immediately without playing any of the video or sound, and the interface returns to the video information page, as if the video had finished playing to the end normally. I see the same behaviour in the Emby iPad app. The relevant lines in the server log are 1 to 40. ffmpeg-remux-8f75321d-20d6-4e36-9e66-4b6d5c93f046.txt

ffmpeg-remux-788b2900-4fd1-4e8c-8e21-8698a1a222b4.txt is transcoding for Safari on MacOS, where the sound plays but there is no video, just a black screen with the interface showing when clicked.  The relevant lines in the server log are 41 to 141. ffmpeg-remux-788b2900-4fd1-4e8c-8e21-8698a1a222b4.txt

ffmpeg-remux-d022bd9f-0502-46dd-9782-2de4cdeaafda.txt is transcoding for Firefox on Linux, where playback works without a problem. The relevant lines in the server log are 142 to the end. ffmpeg-remux-d022bd9f-0502-46dd-9782-2de4cdeaafda.txt

The above behaviour is highly consistent (there are very rare occassions when it works, but I don't know what triggers them), and always happens on this video.

The second problem, which happens on a different video, is the playback being jerky. The sound continues normally without stopping, while the video plays for half a second or so, then stops for a second or so, then jumps to catch up with where it should be. When the video jumps there is sometimes blockiness, which suggests to me missing data in the video stream.

The server log for this problem is server-63635241600_avatar.txt. server-63635241600_avatar.txt

ffmpeg-remux-d15fda75-1e56-4590-8810-cdf1724e7127.txt is transcoding for Safari on iOS 10, where the video is jerky. The relevant lines in the server log are 1 to 78. ffmpeg-remux-d15fda75-1e56-4590-8810-cdf1724e7127.txt

ffmpeg-remux-88a52558-8b56-404b-98ff-2f9cad9adf47.txt is transcoding for Safari on MacOS, where playback works without a problem. The relevant lines in the server log are 79 to 174. ffmpeg-remux-88a52558-8b56-404b-98ff-2f9cad9adf47.txt

ffmpeg-remux-86a924fb-aa6c-496d-8737-27fa10fe879f.txt is transcoding for Firefox on Linux, where playback works without a problem. The relevant lines in the server log are 175 to the end. ffmpeg-remux-86a924fb-aa6c-496d-8737-27fa10fe879f.txt

 

As with the first problem, the above behaviour is highly consistent, and always happens on this video.

Both the iPad and MacOS are streaming over wifi, through the same access point (but not at the same time) while Firefox is running on a desktop with a wired connection.

Is this perhaps a problem with available codecs on the server? The server is running on Debian Linux 9. I don't think it's a hardware problem because I have other videos which are also HD with DTS audio that play fine on all clients, and the transcoding logs show that transcoding is well ahead of the playback rate. The hardware is a Xeon D-1521 at 2.4GHz.

Edited July 11, 2017 by the_57th_bob

[Happy2Play 8238]

Does this only happen on high bitrate files?  What is your wifi speed?

[the_57th_bob 0]

The wifi is IEEE 802.11n/a, which Wikipedia tells me has a theoretical bandwidth of 600 Mbps. I doubt I get that, but I get more than enough bandwidth to stream HD video.

 

Other high bitrate files play fine, I think. I'm not sure which bitrate I should be looking at to check. Attached is the log for another HD video with nearly the same format (it apparently has one extra channel in the sound), a similar input bitrate (36153 kb/s, the other two discussed above are 44771 kb/s and 29428 kb/s) and apparently getting transcoded to the same output. It plays smoothly.

 

I'm not sure if it happens on low bitrate files, but I haven't seen it on the ones I have tried. I will need to check every file I have to be sure it doesn't happen on any low bitrate ones.

ffmpeg-remux-fellowship-ipad.txt

server-63635327999.txt

Edited July 11, 2017 by the_57th_bob

[Luke 36997]

You could try lowering the in-app quality setting to force a lower bitrate with transcoding, and see how that affects it.

[the_57th_bob 0]

For the video that stops immediately, I can't reduce the bitrate because the video playing interface is never available. Is there somewhere other than during playback where the quality can be reduced?

​

​For the video that has jerky playback, I tried reducing the quality (sorry for the misunderstanding earlier, I was thinking of the wrong bitrate). At 30 Mbps it was jerky, at 25 Mbps it was perfectly smooth. I don't think this is a bandwidth issue, though. Firstly because other HD videos play fine at the maximum bitrate (60 Mbps; I tested several, and I think they are using the same codec on the output side of transcoding too), and secondly because a MacBook on the same wifi network in the same place as the iPad has no problem playing the videos.

​

​I noticed while trying to change the bitrate in the jerky video that the interface response was similarly jerky, as if it was running in sync with the video. When the video was smooth, the interface was also smooth.

 

One thing that interests me for the video that stops immediately is this part of the server log:

​

2017-07-10 20:41:19.4952 Info HttpServer: HTTP POST http://boxodata:8096/emby/Sessions/Playing/Progress. UserAgent: Mozilla/5.0 (iPad; CPU OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.0 Mobile/14F89 Safari/602.1
2017-07-10 20:41:19.4993 Info HttpServer: HTTP Response 204 to 192.168.0.134. Time: 4ms. http://boxodata:8096/emby/Sessions/Playing/Progress 
2017-07-10 20:41:19.5005 Info HttpServer: HTTP Response 204 to 192.168.0.134. Time: 6ms. http://boxodata:8096/emby/Sessions/Playing/Progress 
2017-07-10 20:41:19.8430 Info HttpServer: HTTP POST http://boxodata:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (iPad; CPU OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.0 Mobile/14F89 Safari/602.1
2017-07-10 20:41:19.8461 Debug App: ReportPlaybackStopped PlaySessionId: 8e9b1c14aab345f695a1969d51c80ab6
2017-07-10 20:41:19.8461 Debug App: KillTranscodingJob - JobId 82c4d475269a4fbe92e38a82ca1c8430 PlaySessionId 8e9b1c14aab345f695a1969d51c80ab6. Killing transcoding
2017-07-10 20:41:19.8461 Info App: Stopping ffmpeg process with q command for /var/lib/emby-server/transcoding-temp/50a087b7d9e1bb32446e5e53d7de3c00.m3u8

​

​It looks, to my untrained eye, like the client is requesting that the video stop, rather than the server stopping the video on its own.

[ebr 14902]

Those are very high bitrate files - something the streaming world would never see so it is possible that the device itself is having trouble with bitrates that high.  I know something like a Fire TV would (it is spec'd at a max of 21Mbs).

[the_57th_bob 0]

​Yes, I'm starting to get that impression. After discovering that the quality setting holds over from one video to the next, I tried setting it to 25 Mbps on a working video, then played the video that has been stopping immediately. It worked fine. So I think this can be marked as "understood", at least, if not "solved". I think there are some usability improvements that can be made in handling playback that is too high bitrate for the device (stopping straight away isn't a great look), but I won't even pretend to know how such situations can be handled.

​

​Thanks all for the help.

[Luke 36997]

Thanks for the feedback.