Closed brabebhin closed 2 months ago
It's been a while and the guy found a different solution already. Still, coming back to this. I did not really like the approach here, it seemed a bit hacky, putting an interface into the config class, to somehow hook into the process...
Now I had a new idea: We already do delay the creation of the MSS and MediaPlaybackItem. So when the FFmpegMediaSource is created, we still have the possibility to change and remove streams! We could easily add a method RemoveStream(IStreamInfo stream)
, which removes the stream from the stream infos list, and the corresponding SampleProvider as well. The method would only work as long as MSS has not been created (after that, it would throw). So devs can create the FFmpegMediaSource, inspect the streams, remove the ones they don't like, and then create the MediaPlaybackItem or MSS. No interface needed, no trouble with async stuff.
I think that would be a clean and simple solution. And it would also be helpful later for potential transcoding scenarios.
Oh right, I completely forgot about this lol.Your idea is also good.
Regarding transcoding, I'd probably do it with ffmpeg APIs and avoid winRT and thus the existing media source completely. It's not even that hard to do, it's a matter of 2 files and a filter graph that can be provided using ffmpeg DSL, the big pain point is the ffmpeg build.
But that once we ship the final winUI build.
This adds a new interface that can be used by applications to decide if a stream should be included in the MediaStreamSource or MediaPlaybackItem.
Users need to implement the interface and pass it in the MediaSourceConfig.General options.
This should enable the scenario described on #425
Open points: