BUFFER_APPEND_ERROR on Tizen with multiple codecs (AVC & HEVC)

Hi RxPlayer team !

I have streams with mixed avc & hevc codecs with widevine protection.

The player try to switch between avc to hevc (or vice versa) but the video streams stop with the error Stream: video Stream crashed. Stopping playback. t: MediaError (BUFFER_APPEND_ERROR) Error: An unknown error occured when doing operations on the SourceBuffer

Is there a way to avoid switching between codecs ? I have tried transportOptions.representationFilter but at this stage I don’t have an overview of all representations to be able to avoid one or other codec. I have tried keySystems { onCodecSwitch: 'reload' }, no change

[el-gringo]

After investigation, the missing reloading issue is also because of mixing codecs in adaptation.

in get_adaptation_switch_strategy.ts

function hasCompatibleCodec(
  adaptation : Adaptation,
  segmentBufferCodec : string
) : boolean {
  return adaptation.getPlayableRepresentations().**some**(rep =>
    areCodecsCompatible(rep.getMimeTypeString(), segmentBufferCodec));
}

In my case the will be some representations with compatible codecs. So I still I have to clarify with the one in charge of streams. Right now, is more than busy ! So that’s not priority.

[peaBerberian]

I have to check with the one who create streams about adaptation-set-switching to avoid mixing AVC & HEVC in the same AdaptationSet

The fact that the RxPlayer merge all of those DASH AdaptationSet into one RxPlayer Adaptation is purely due to our implementation. What really is done by adding the supplemental adaptation-set-switching property is telling players that they can technically switch between all those AdaptationSet (e.g. with the player’s adaptive streaming logic).

The DASH-IF envisages your case (multiple codecs in multiple AdaptationSet all linked through an adaptation-set-switching supplemental property), so it’s not really an issue that needs to be fixed.

The real issue here is that some browsers does not handle that type of codec switching well. The RxPlayer thus might need to first “reload” before doing so (why it doesn’t work/doesn’t seem to reload here is another issue to look at as you noted).

From here, we’re not sure how to move forward, so that’s what we need to discuss in the RxPlayer team. For example, a solution might be to allow an application to tell the RxPlayer that is should keep those as several “tracks”/Adaptations so they cannot be switched between one another without an explicit setVideoTrack call.

Thanks for your time. For now the patch I pushed totally fit my needs. I know SmartTVs are a bit exotic 😉

Yes, they sometimes showed surprising behaviors! Though we tried to handle them better recently (from the end of last year).

Tizen is one of the TV platform we aim to fully support (the RxPlayer runs in production on them through the Canal+ application).