Apollo raw multistream sample MOV?
 

Anyone have a short 10sec raw Apollo multistream file? (unsplit and not demuxed from the SSD) I want to test something with FFmpeg and hopefully make a tutorial for people familiar with FFmpeg. If it's a standard way of muxing multiple streams, FFmpeg might be able to demux it.

Re: Apollo raw multistream sample MOV?
 

Dear Jack,

We could create a short file, for you.

Please send me a Private Message with your email address.

Or you may call me at:

seven one nine --- nine three zero --- one three seven six

Respectfully,

Re: Apollo raw multistream sample MOV?
 

Dear Jack,

Our file format is actually an Apple ProRes 422 (HQ, 422, or LT) standard format for multi-cam.

It is just not widely used for multi-cam.

Thus, our CD Apple ProRes Transfer Utility during the upload splits out the individual camera angles and our fifth channel (Live Switch or Quad Split) into separate Apple ProRes files.

Note, there is no time penalty for using our Utility.

Respectfully,

Re: Apollo raw multistream sample MOV?
 

No, the concern isn't time penalty, it's the fact it was written in Java. Java is being deprecated on many modern operating systems as a security vulnerability. If the tool were rewritten in something like, say, C#, you could release a Windows program and easily convert the code for use on the Mac App Store.

I was trying to find a stopgap to demux the Apollo streams using FFmpeg until your team recodes it in a more modern codebase.

Re: Apollo raw multistream sample MOV?
 

Well, good news everyone:

FFmpeg CAN handle Apollo multistream files.

The bad news:

Reliably concatenating Apollo files is simply impossible in FFmpeg. The problem is a non-monotonous DTS timestamp between files because FFmpeg detects an invalid packet in one of the streams when transitioning files. Video stream 1 may be able to maintain a steady frame rate, but all other streams suffer the consequences of being thrown into variable frame rate land. This is also the best case scenario with all 5 streams present. If a stream is present but with no data sent to it, (the simple A/B/C/D record mode with no LS/QS) the errors crossing file borders get even more interesting, since there are always 5 streams present even if the LS/QS mode is not activated.

The only solution is to separately split out the streams on the clip segments only in FFmpeg, then re-assemble and concatenate using a bitstreaming (AKA Smart Rendering) capable NLE. Convergent has been good in the past to making seamless file borders and separating the streams only on clip segments without using FFmpeg to concatenate seems to work. I even converted the stream to DNxHD and it was able to maintain it's seamless file borders.

Is there any way to make Apollo files heed packet warnings so that FFmpeg won't throw a spasm? And can handling of blank streams with no data in Apollo files in FFmpeg be improved?

A simple solution would also be this: License exFAT and no longer worry about file borders within a single SSD. exFAT is compatible across both Windows and Mac and is starting to see wide use in SDXC cards. Then the only place a file border would be of concern is going between SSDs for seamless recording. But by then the segments are only limited by the size of the SSD, so longer segments mean less legwork to split the Apollo streams.

If exFAT is not implemented for single stream recording, that's fine cause FFmpeg Concatenate works fine for those files, but exFAT is desperately needed for Apollo recordings because of this issue.