search

ffmpeginteropx / FFmpegInteropX

FFmpeg decoding library for Windows 10 UWP and WinUI 3 Apps
Apache License 2.0
205 stars 52 forks source link

Multiple input files #428

Open brabebhin opened 4 months ago

brabebhin commented 4 months ago

Hello @lukasf

I've been playing around with a new feature: add multiple input files to the FFmpegMediaSource. This PR showcases a working prototype.

Some notes and open questions:

  1. It is not possible to add the extra streams during playback (unfortunately). I realize that it should be impossible to add external subs this way, if we are to ever implement subs through winRT APIs we need to keep this in mind.
  2. How do we handle files that have different media durations? at this point I do not update the overall length of the MediaStreamSource when a longer file is added, so the automatic increment kicks in.
  3. It appears that syncing the multiple ffmpegreaders in the onStarting event is enough to keep them in sync (the event happens when stream switching and when playback starts / resumes)
  4. Metadata tags will have to be merged / handled somehow
  5. We need an additional property in StreamInfos so that consumers know which IO context they belong to (I am thinking some sort of user provided key and we can also group metadata by that key)
  6. Fast seeking will not work on ffmpeg readers that do not have an active video stream. This will eventually be fixed, not a big deal atm.
  7. Probably weird bugs hidden in the bushes.
  8. This PR is based on the ffmpeg 6 / 7 branch
  9. Feedback is welcome :)
lukasf commented 3 months ago

Interesting solution. I had a prototype implementation of this years back. I used a different approach: I just created additional "child" instances of the FFmpegMediaSource. In the main instance's OnSampleRequested, if the requested stream was not found in the current source, I'd search any child sources for the stream and call their SampleRequested method. The upside was that the required amount of changes was pretty small (ofc, that does not neccessarily mean that it is the better approach).

brabebhin commented 3 months ago

Hmm interesting, I haven't thought of that, but it makes sense. Yes it should be a smaller changeset, and that should also make it easier to handle.