-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Freezed VOD stream and lot of audio discontinuities on Samsung Tizen 2017 #1415
Comments
Hi @TomaszKowalik, I think this is the known samsung issue we had countless times where we attempt to seek forward over an audio discontinuity but samsung silently seek-back to some reference video frame before that audio discontinuity and so on, in a loop. Here you encounter it with that content as it seems the audio starts at We very frequently tried to work around that behavior, and it may be already fixed in the I'm also even more confident that it cannot be reproduced in the |
@peaBerberian
|
Hi @TomaszKowalik, The problem appears to be a little different with the v4 here, as it's now the HTMLMediaElement's Do you see a frame on the screen or does it stays completely black here? |
Screen was all black |
OK thanks, so for the v4, I would more probably explore DRM issues. Is it the same content in both tests? I see different bitrates in the logs. Is is possible to lock the lowest possible video bitrate and re-do the test (just to eliminate some multi-key contents scenarios)? To lock the video representation with the lowest bitrate, do before the loadvideo something like (I did not test that code, so typos possible): // Each time new track choices are made available (which coincides with new Periods)
rxPlayer.addEventListener("newAvailablePeriods", (periods) => {
for (const period of periods) {
// Get initially-chosen video track for that Period
const videoTrack = rxPlayer.getVideoTrack(period.id);
if (videoTrack == null) {
continue;
}
const representations = videoTrack.representations;
// Find the Representation in that video track with the lowest bitrate
const lowestBitrateRep = representations.reduce((acc, representation) => {
if (acc?.bitrate === undefined) {
return representation;
} else if (representation.bitrate > acc.bitrate) {
return acc;
} else {
return representation;
}
}, undefined);
// Force to only load that Representation
rxPlayer.lockVideoRepresentations({
periodId: period.id,
representations: [lowestBitrateRep.id],
});
}
}); |
@peaBerberian This was the different stream, but it was from the affected provider. We did some tests; on the lowest bitrate, the error was persistent. The only way to fix it was to change from DASH to MSSS. Surprisingly, that fixed the issue for RX 4.0 and also for older versions. For this particular Tizen model, looks like we would need to use an even older RX version: 3.29 due to some discontinuity errors for some streams...
|
Hi, For that second issue, nothing seems to be problematic from reading the logs sadly :/ Here also, I would first guess that this is DRM related, e.g. it could be that the ad is unencrypted, the VOD is, and that those tizen models have issues when requiring a key for en encrypted content when playback of unencrypted content already started. To fix this, we could think of multiple potential work-arounds:
For the first solution, I have created a branch ( For the second solution, maybe we could test it by profiting from the fact that the RxPlayer caches DRM MediaKeySession by default. |
Yes, I think that's the DRM issue. It seems that our ads are not encrypted... So in the manifest we have unencrypted period first and then the encrypted. But actually, it works the other way around than: I was experimenting with the I also tested your branch, but the issue still occurs there. Maybe there is some other option that could work? |
I was even thinking - just for the test for now - to just reload after the license has been fetched from the beginning and then re-play both the ad and the content. As for reloading at a specific position, sadly tizen is a nightmare in that area, they are the only devices where precise seeking is not really doable, so that may be why you have things like reloading loop here.
The audio playing but video not playing issue? I added logs to that branch today ( |
I'm checking the RX versions: For every version, the transition from the unencrypted period to encrypted causes audio loss and artifacts/flickering/green screen. Calling reload after the license request is not fixing that issue. The only thing that seems to be partially working so far is workaround, where I'm using reload when the unencrypted part ends. However, for live streams, it's not working at all, and for linear assets, it randomly doesn't work (loops the ad), probably related to the Tizen precision issues you mentioned. Regarding live assets, I think changing the player state to I tested it with DASH/WV and DASH/PR with the same result for every tested rx version :( |
OK :/ Maybe that's an issue with those TV models, Canal+ do not target those older 2017 Tizen models so I don't have enough data about them. |
Hi
This issue is specific to Samsung Tizen 2017 models. We are using 3.23.1 Rx version.
When attempting to play a VOD stream from one of our streaming providers, the RxPlayer freezes indefinitely and fails to play the content. I investigated both Widevine and PlayReady DRM's. For WV, I encountered the following error:
EncryptedMediaError (LICENSE_SERVER_CERTIFICATE_ERROR) InvalidAccessError: Failed to set the server certificate
on every attempt. However, for the PlayReady license server seemed to be ok, yet the stream still couldn't start. Upon enabling debug mode for RxPlayer, I noticed numerous audio discontinuities.What's interesting: it only happens when we are trying to play a stream from the beginning. If there is a stop marker set in some further position, then it will play without any issues.
We have such adaptation for that audio track :
<AdaptationSet id="1" group="1" contentType="audio" lang="en" segmentAlignment="true" audioSamplingRate="48000" mimeType="audio/mp4" codecs="mp4a.40.2" startWithSAP="1">
What might be the cause of such issues and how can we fix that?
Below are the relevant logs:
The text was updated successfully, but these errors were encountered: