write to MP4

[cedricve]

It's referenced that go-mp4 is being used, and I'm currently trying out to use gortsplib to read a stream (this works) and dump the h264 payload into a mp4 container. I'm struggling a bit setting up the MP4 header and trailer. Do you have any guidance @aler9 ?

[cedricve]

Found this example (https://github.com/bluenviron/gortsplib/blob/main/examples/client-read-format-h264-save-to-disk/mpegtsmuxer.go), but curious to see how that would work for mp4.

[aler9]

Hello, go-mp4 is used in gohlslib to generate fragmented MP4s for HLS, code is here:
https://github.com/bluenviron/gohlslib/blob/main/muxer_segmenter_fmp4.go

I'd like not to include MP4-related utilities or MPEG-TS-related utilities into this library, in order to keep it lightweight and minimize maintenance efforts. There are other projects that provide such utilities. I know that putting everything together could be a little difficult, but it's a design choice.

[cedricve]

thanks for the comment, yes I agree. That link is already a good starting point. I know integrating that in the core library doesn't make sense, I was more or less interested in some examples. Not sure if we need a "playground" repo for that.

[cedricve]

I'm currently using this library for writing MP4s. Very nice SDK to integrate.
https://github.com/yapingcat/gomedia

[cedricve]

After 1 year I'm still using the combination golibrtsp and gomedia. Interestingly I just moved some from PacketPTS to PacketPTS2, and I noticed the duration of the MP4s are no longer correct. I see the PTS2 is running behind PTS which (from my opinion) is more accurate.

For a 20 second recording, PacketPTS will result in 20000ms, where PacketPTS2 will results in 17994ms (or something around).

The longer the recording being made, the larger the delta will become. Any thoughts on this @aler9?

[aler9]

@cedricve PacketPTS2 was indeed introduced in order to increase precision since it allows to skip conversion to time.Duration, which introduces division errors.

Timestamps in most protocols are represented as integers, that can be divided by a clock rate (usually 90000) in order to obtain seconds.. Previously, these timestamps were converted to time.Duration and then converted to the destination format. This double conversion introduces division errors. For instance, this is the conversion of a 90khz timestamp (coming from RTSP) to time.Duration:

123456 (original timestamp with clock rate = 90khz) / 90000 = 1.37173333333
1.37173333333 truncated to nanoseconds (resolution of time.Duration) = 1.371733333

and this is the conversion from time.Duration to a 90khz timestamp (for instance a MP4 file):

1.371733333 (time.Duration) * 90000 = 123455

So if you want to store a RTSP stream to an MP4 file with the legacy PacketPTS, 123456 becomes 123455.

If instead you use PacketPTS2, 123456 will pass through and remains 123456. Just avoid using time.Duration in the rest of your code.

[cedricve]

Hey @aler9, I wish I had your brain ;) Thanks for the delicious explanation again. Makes a lot of sense now!