Closed Kethsar closed 1 week ago
mkvmerge muxes such streams without any problem, thus on my setup I switched to using the --write-mux-file option and muxing with mkvmerge myself.
@Kethsar I think it would be beneficial if you add an option to use mkvmerge instead of ffmpeg. I know this is kind of a workaround but nevertheless a much simpler solution to the problem than looking for bad bytes in segments and trying to fix them with the recorder
also IIRC muxing vp9 video into mp4 is not allowed by standard anyways so...
also IIRC muxing vp9 video into mp4 is not allowed by standard anyways so...
I thought so too, but it is. The MP4 container allows just about anything, as long as it's specified properly. ffmpeg itself took issue with putting opus in MP4 when I started this, but that might be less of an issue these days.
I'll consider allowing mkvmerge as an option when muxing to mkv. It's possible ffmpeg 6.0 may have a way around the issue itself though. I still haven't looked into it much.
It's possible ffmpeg 6.0 may have a way around the issue itself though. I still haven't looked into it much.
For what it's worth, I can confirm that ffmpeg 6.1.1 and 7.0 have no problems with putting a VP9 stream with overlapping DTS into an MP4 container. This is in contrast with 5.0.1, which reports the non monotonically increasing DTS and bails with a partial file.
Big if true. I'll re-enable VP9 for my archiving scripts and close this if I don't see any issues after a while.
No issues so far across tens of streams downloaded, good enough for me.
Sometimes a stream having issues will cause VP9 video to break when muxing. This happens because the timestamps between two fragments ends up overlapping, and ffmpeg refuses to make any attempts to ignore the bad data. For some reason this is not an issue for H264.
I'll have to add some debug mode that keeps fragment files in full so I can inspect the offending fragments more easily.