player.play error: mediadecodeerror: Playback failure

[Noodlewasser 68]

Hi,

I first posted this in the server section because I thought it was a server issue, but I now realized it is a problem with the web app. I cannot play multiple episodes of a particular season of a show that I am currently watching.

When I try to start playing the episodes in Firefox, the stream never starts to play but quits after a few seconds of loading with the message "No compatible streams are currently available. Please try again later or contact your system administrator for details." If I try it a couple of times I get an error saying that I exceeded my streaming limit (I have set the number of simultaneous streams for my user to two).

In Firefox the files do not direct play, but get remuxed video and transcoded audio. In edge it works fine to direct play, but when i reduce the quality to force a transcode, I get the same error.
It seems to be a playback error in the browser (see the attached log of the console).

After the playback error, the web app sends a request to /Videos/ActiveEncodings/Delete, which stops the transcode. It then tries to recover from the error, but this doesn't work as the transcode session has already exited, hence the FileNotFound exception in the logs. Interestingly, a different episode that shows the same media info (except for a slightly lower bitrate) works perfectly.

Here is a screenshot of the media info:


I don't know how to debug the playback issue in the browser, unfortunately.

firefox-console-export-2023-11-17_12-11-34.txt ffmpeg-transcode-7a567c36-07b2-45ff-8b9e-fce49747c97b_1.txt ffmpeg-remux-7648984d-9cfd-4db4-987a-fc7b7c93f0db_1.txt embyserver.txt

[Noodlewasser 68]

Update:
I have copied the ffmpeg command from the logs and run the transcode command manually inside the embyserver container. I then downloaded the output to my PC and verfied that it plays correctly with the VLC player, so the transcode seems to work fine and the issue must be with the player.

[Noodlewasser 68]

Update 2: I get the same error on the latest beta (4.8.0.59).

[Luke 42081]

Quote

After the playback error, the web app sends a request to

This isn't the problem. The problem is what happens earlier, which is the firefox video player triggers an error, and so we end up stopping and aborting playback.

Hi, how does Chrome compare?

[Noodlewasser 68]

Chrome behaves the same.

[softworkz 5072]

Is it always with the same file?

 

The one in the logs has an issue:

The Start-Offset between Audio and Video is > 1.200ms

The video start-time is 2.068ms
The audio start-time is 30ms
=> Offset is 2.038ms

This is often an indication for badly authored files!

When audio and video stream have different start times, then there's something missing at the start from one or the other.
This can cause problems with certain output formats - specifically HLS.
The segments need to be aligned and synced and when a larger part from one stream is missing, the muxer has to decide about how long to wait for (potentially late) frames. With segment sizes of 3 seconds, there's not much time to wait.

This CAN but DOESN'T HAVE TO BE an indication for a large muxing offset between audio and video, even though this is something very different:

- Start Offset Difference
  means something is missing at the beginning from one of the streams - playback will start with with the earlier stream (solo) and the other stream will join and start to play slightly later

- Muxing Offset
  means the timestamp difference between packets from one and another stream at the same/adjacent point in the source-bitstream

- All cases are possible
  - No muxing offset but start-time offset
  - No start-time offset but muxing offset
  - Both combined

 

Identifying the Cases
When it's a pure start-time offset issue, then it should be possible to play the video after seeking or skipping forward, as the start-time offset won't matter anymore in that case. 
Otherwise it's probably a combination of both

[Noodlewasser 68]

Thanks a lot for the detailed explanation. It is happening with all files in this particular season, except for episodes one and two. So it seems likely that a misconfiguration was introduced when creating episode 3 and then carried over to the subsequent episodes.

I tried skipping forward as soon as possible but I still get the error. What I find surprising is that it does not happen when the file is direct played e.g. in Microsoft Edge. If I then reduce the quality to force a transcode during playback it works fine as well, but if I start playback with reduced quality I get the same error.

[softworkz 5072]

When direct playing, the file is handled differently. When transcoding, we use the HLS streaming protocol which works by chopping the output into individual segments, each of 3s length. 

It is normal that the audio is a little earlier than video, because players use audio as the synchronization source (clock) and present the right video frames accordingly. But two seconds is a bit too large as it's 66% of the segment time. Also it's outside the spec for Broadcast TV signals, which is provisioning for the most downlevel (cheap) devices, and those are unable to store 60 video frames in memory before showing the first frame. Means in turn, something has been done to the video during or after recording which has caused that.

We see that case being reported sometimes but not very often, so it's definitely an issue with the video material, even though some players can take it. 

Would you be able to (privately) provide one of the videos for testing? We are updating the client-side HLS implementation soon, and I don't know whether I still have an example file for this case.

Thanks

[Noodlewasser 68]

I see, thanks! I will send you a pm.

[Luke 42081]

Did you find anything?

[softworkz 5072]

16 hours ago, Luke said:

Did you find anything?

On 11/19/2023 at 9:29 PM, softworkz said:

Would you be able to (privately) provide one of the videos for testing? We are updating the client-side HLS implementation soon, and I don't know whether I still have an example file for this case.

He provided a video for testing once we get to update our HLS implementation, there's nothing more for him to "find".