You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide ForwardingMediaSource to simplify custom implementations #7279
Current implementation of HlsMediaSource starts with default position:
We attempt to set the default start position to be at least twice the target duration behind the live edge.
So, if HLS has lots of segments or they are long enough - default start position will be pretty far from it's 0. This is desired behavior when playing "live" media.
But, for example, "catchup" of IPTV services is implemented in the way, when url identifies specific time (wall clock), and when player starts playback - it should start from 0 instead of "live edge" to match target wall clock.
Alternatives considered
I have tried:
MediaItem.ClippingProperties - does not work (since it clips only)
I think that some functionality can be provided by library itself:
fully functional CustomStartPositionSource
or at least easy-to-extend delegating media source. Otherwise CompositeMediaSource should be used (the same as it's used by ClippingMediaSource), which looks a bit of overkill.
Honestly speaking diving into whole sources/timelines/periods/windows is pretty hard stuff, when you have no experience with it. And since source code in the example is a bit out of date - I was looking for existing solutions, which wraps another MediaSource. So there were SingleSampleMediaSource, ClippingMediaSource, test implementation in delegatingMediaSourceApproach I started with.
Maybe, after doing CompositeMediaSource -> BaseMediaSource, it will be much easier to get it right purely on MediaSource for me.
But, looking to ClippingMediaSource I was thinking why it's based on CompositeMediaSource and if there is any real need in it, cause it looks like wrapping source, but there is no ready-to-use base class for it.
So it solves my problem, but I think that custom "default playback pos" strategy for HLS can be pretty useful.
And having some delegating media source base class would remove boilerplate and maybe simplify some existing implementations (ClippingMediaSource?)
About adding a ForwardingMediaSource in order to simplify custom media sources: @tonihei, can you give your opinion on that? Do you think this would be helpful for many use cases?
Maybe, after doing CompositeMediaSource -> BaseMediaSource, it will be much easier to get it right purely on MediaSource for me.
But, looking to ClippingMediaSource I was thinking why it's based on CompositeMediaSource and if there is any real need in it, cause it looks like wrapping source, but there is no ready-to-use base class for it.
When wrapping one or more other media sources you should use CompositeMediaSource (as in your first code example) because it takes care of some event forwarding logic and does not reinvent the wheel.
About adding a ForwardingMediaSource in order to simplify custom media sources: @tonihei, can you give your opinion on that? Do you think this would be helpful for many use cases?
Sounds like a helpful addition for cases where MediaSources forward to exactly one other source and only make small adjustments. I've seen some examples that repeat the same boilerplate forwarding code and would benefit from this. So I'll mark as an enhancement to implement this.
changed the title [-]Ability to start HLS playback from custom position[/-][+]Provide ForwardingMediaSource to simplify custom implementations[/+]on Apr 23, 2020
because it takes care of some event forwarding logic and does not reinvent the wheel.
@tonihei, there is message forwarding in CompositeMediaSource, but all of messages come from MediaSourceEventListener, DrmSessionEventListener. So, I'd expect that all of it is covered with direct forwarding of add|removeEventListener, add|removeDrmEventListener to wrapped source.
Please correct me if I'm wrong here.
Should probably work. It's still easier to rely on an existing wrapper for boilerplate code mostly because code changes in the future will automatically update the base classes, whereas if you implement the interface directly, you need to update your implementation manually.
@tonihei. You were right. :)
Even when it looks simple - it is not. Got memory leak due not-matching callers (HLS media source wrapped by CustomStartPositionSource based on MediaSource from my example above)
Activity
stari4ek commentedon Apr 22, 2020
Proof of concept implementation looks like:
stari4ek commentedon Apr 22, 2020
Another one, purely on
BaseMediaSourcekim-vde commentedon Apr 23, 2020
Can you clarify why you would extend
CompositeMediaSourceorBaseMediaSourceinstead ofMediaSource(as in #2403)?stari4ek commentedon Apr 23, 2020
Honestly speaking diving into whole sources/timelines/periods/windows is pretty hard stuff, when you have no experience with it. And since source code in the example is a bit out of date - I was looking for existing solutions, which wraps another MediaSource. So there were
SingleSampleMediaSource,ClippingMediaSource, test implementation indelegatingMediaSourceApproachI started with.Maybe, after doing
CompositeMediaSource->BaseMediaSource, it will be much easier to get it right purely onMediaSourcefor me.But, looking to
ClippingMediaSourceI was thinking why it's based onCompositeMediaSourceand if there is any real need in it, cause it looks like wrapping source, but there is no ready-to-use base class for it.stari4ek commentedon Apr 23, 2020
ok, here is
MediaSourcebased:So it solves my problem, but I think that custom "default playback pos" strategy for HLS can be pretty useful.
And having some delegating media source base class would remove boilerplate and maybe simplify some existing implementations (
ClippingMediaSource?)kim-vde commentedon Apr 23, 2020
CustomStartPositionMediaSource: I will mark this issue as duplicate of Allow playlist items to specify a start position #6373 (as a single media item is a special case of a playlist).ForwardingMediaSourcein order to simplify custom media sources: @tonihei, can you give your opinion on that? Do you think this would be helpful for many use cases?tonihei commentedon Apr 23, 2020
When wrapping one or more other media sources you should use
CompositeMediaSource(as in your first code example) because it takes care of some event forwarding logic and does not reinvent the wheel.Sounds like a helpful addition for cases where
MediaSourcesforward to exactly one other source and only make small adjustments. I've seen some examples that repeat the same boilerplate forwarding code and would benefit from this. So I'll mark as an enhancement to implement this.[-]Ability to start HLS playback from custom position[/-][+]Provide ForwardingMediaSource to simplify custom implementations[/+]stari4ek commentedon Apr 23, 2020
@tonihei, there is message forwarding in
CompositeMediaSource, but all of messages come fromMediaSourceEventListener,DrmSessionEventListener. So, I'd expect that all of it is covered with direct forwarding ofadd|removeEventListener,add|removeDrmEventListenerto wrapped source.Please correct me if I'm wrong here.
tonihei commentedon Apr 23, 2020
Should probably work. It's still easier to rely on an existing wrapper for boilerplate code mostly because code changes in the future will automatically update the base classes, whereas if you implement the interface directly, you need to update your implementation manually.
stari4ek commentedon May 2, 2020
@tonihei. You were right. :)
Even when it looks simple - it is not. Got memory leak due not-matching callers (HLS media source wrapped by
CustomStartPositionSourcebased onMediaSourcefrom my example above)Implement MappingAudioSource on Android
tonihei commentedon Jan 12, 2023
This issue has been addressed by androidx/media#123.