Add a save-to-mp4 OR save-to-mkv example

[tmatth]

Summary

As there exists a https://github.com/pion/example-webrtc-applications/tree/master/save-to-webm it'd be useful to have the equivalent for saving to mp4 or mkv.

Motivation

While the existing example of saving h.264 to disk is helpful, typically you'd see this in a container. mp4 and mkv are fairly ubiquitous and support Opus, so it'd definitely be helpful to show how to mux to it from webrtc using pion.

Describe alternatives you've considered

It's probably also possible to postprocess the elementary streams generated with the existing examples.

Additional context

Happy to help if someone points me in the right direction WRT mp4 muxing in go.

[kevmo314]

Does using ffmpeg work? ffmpeg can take in multiple RTP streams and mux them into a container: https://stackoverflow.com/questions/39411901/how-can-i-merge-two-input-rtp-streams-in-ffmpeg

Since there are a lot of container formats, maybe we should add an ffmpeg muxing example instead of incrementally covering the entire container space? The gstreamer-receive example also works here.

[tmatth]

Does using ffmpeg work? ffmpeg can take in multiple RTP streams and mux them into a container: https://stackoverflow.com/questions/39411901/how-can-i-merge-two-input-rtp-streams-in-ffmpeg

ffmpeg can definitely do that, although in this instance it'd mean doing another network hop + introducing ffmpeg's network stack, which is overkill IMO for just muxing to disk at the end of the day.

Since there are a lot of container formats, maybe we should add an ffmpeg muxing example instead of incrementally covering the entire container space? The gstreamer-receive example also works here.

I wouldn't worry about the "entire container space" as there's a relatively small subset of commonly used container formats that work for common webrtc codec combinations and compatible across a wide range of browsers/players.

But for sure an ffmpeg example would also be useful (and not just for muxing).

[kevmo314]

it'd mean doing another network hop + introducing ffmpeg's network stack

You can avoid this by directly calling libavformat/libavcodec in cgo. We do this here: https://github.com/muxable/sfu/tree/main/pkg/av

I think this starts to get quite complicated for an example webrtc application though. The gstreamer-receive example is much simpler if avoiding a network hop is important.

[evan-cai]

Is this in process?