FFMPEG: Transmux mpegts to mp4 gives error: muxer does not support non seekable output

Question

When piping mpegts to ffmpeg, which should convert it to mp4 and pipe to stdout, ffmpeg says: "muxer does not support non seekable output".

After a lot of research I came to the conclusion that mp4 is a bad choice for doing those kinds of on-the-fly transcoding due to seeking. So in essence: MP4 cannot be piped through ffmpeg, which kind of makes sense.

But I do not have a contiguous mpegts stream, I have chunks of 5 seconds. So it's really just like:

• Here is my 1 mb *.ts file
• Please read it from pipe until you hit EOF
• Please transmux it to mp4 (if you really have to seek, well use a buffer)
• Please pipe the complete internal mp4 buffer to stdout

I need these mp4 chunks for a HTML5 MediaSource, the fragmentation is no problem, I use mp4box.js, which works like a charm.

Questions:

• Can FFMPEG do this kind of internal buffering ?
• Is there any better option to consider ?

In essence: Can I (somehow) interact with ffmpeg without using files ? My current solutions works with files and polling for new chunks, which is ugly.

If you are interested in my ffmpeg command, just let me know.

Hula

I just want a way to talk with ffmpeg directly like: Here is my input buffer and please give the output buffer without creating files. Since my program calls ffmpeg as a child process I do not want to waste the computer with files, which are only used once for broadcasting. It really feels like a interface problem with ffmpeg. Is ffmpeg really not able to buffer the output and send it in chunks instead of segment-wise streaming ? I do not want to go all the way down to C just to change the interface... – Hula

Answer 1

Since you mentioned fragmentation then you can just enable it with movflags. Example for fragments starting on each keyframe:

ffmpeg -i segment.ts -c copy -movflags frag_keyframe+empty_moov -f mp4 -

Having an empty moov atom means it doesn't need to seek and thus works with a pipe.

Westfall

While this somehow works, it messes up insertion into the MediaSource since duration will always be 0 and subsequent chunks can not be inserted shortly. This whole mp4 stuff is a big pain in the ass... MediaSource! Why u not support TS !!! Another possibility is using some kind of emscripten-compiled ffmpeg, which has a virtual in memory filesystem. This is basically all I'm looking for... a way to tell ffmpeg to use something in RAM, I don't need the streaming capabilities of ffmpeg, since I'm really only dealing with 5 seconds chunks which are themselves independent of each other. – Hula

Does -copyts make a difference? You can use a RAM disk for the second solution. – Westfall

And MSE should support MPEG-2 TS w3c.github.io/media-source/byte-stream-format-registry.html – Westfall

That's true. But not now as i See it. Maybe in future releases. Currently status quo always suggests transmuxing ts segments to mp4 right in the Browser but its hard to find reliable libs for this. Also in mobile u dont want ti transmuxing stuff... Too cutting edge still – Hula

Firefox didn't love this MP4 rendered this way but chrome loaded it fine. Neat trick either way and also works for MOV – Cavatina

Answer 2

If you can live with not having a true mp4 format, using ismv actually worked even better for me (didn't damage seeking and total duration info in certain players) than manually adjusting the movflags. According to the ffmpeg formats documentation, the ismv format is similar to mp4, but auto adjusts the movflags for streaming and does a better job of it in my opinion.

Tested in: Firefox, Chrome, VLC

ffmpeg -i input.mp4 -f ismv -

Sadly neither this command nor aergistal's answer create a video compatible for upload to twitter as of 19/12/20 due to twitter's video upload validaiton being very strict and requiring what I imagine is the most common of mp4 formats. So as of right now I still have to use ffmpeg to output directly to a file rather than stdout to allow for twitter video upload. But I would love to hear if anyone has figured out a way around this!

Shuck

You can output to a named pipe, that would allow using standard file output but would remain in memory. – Cisco