[Reuben Martin]

I think there’s some mis-communication in terminology. “Track” is a term more suited for video editing or a DAW.

The breakdown in this case goes: Container Format -> Stream -> Channel

What you want to do is convert from one audio stream with 14 channels to 14 audio streams with a single channel.

This should work. (Can’t test it right now though)


$ ffmpeg -i 14ch.mov -vcodec copy -acodec copy -filter_complex channelsplit -f mov 14str.mov


[Reuben Martin]

The answer can vary depending on how the audio is muxed.

It could be 14 streams with a single channel each, it could be 1 stream with 14 channels, or it could be anything in-between with multiple streams having multiple channels.

[Reuben Martin]

There is also a filter that will give frame info.


ffplay input.mp4 -vf showinfo |& grep 'type:I'


[Reuben Martin]

Supposedly Dolby-E can be muxed in and treated like a stereo audio track, however I’m not sure if MXF has special metadata tags used to indicate that the audio track is Dolby-E. I doubt FFMpeg supports it. A lot of work has gone into fixing MXF encoding and decoding over the last 6-9 months, but I’m not sure Dolby-E has been part of that. Mostly because Dolby-E encoders are not very commonly available to test with.

You might try asking in the ffmpeg developer list. If you have access to such an encoder as well as another tool to properly mux it into an MXF, I’m pretty sure they would love to get their hands on some samples they could play with.

https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/

[Reuben Martin]

Timebase is the resolution of the timestamps in the container. Different formats have different restrictions in what ranges of timebases they support. The sampling rate of audio and frame rate of video also play a role influencing what is optimal timebase.

So if your timebase = 1/90000, then the timestamps on the stream packets are set in increments of 1/90000 of a second.

Not familiar with DVDSP enough to say why it’s complaining. Although I would recommend checking the bitrate. 9000000 bit rate seems to be push against the upper limits of the allowed DVD bitrate if memory serves me correctly.

I generally use mplex from the mjpegtools whenever I have problems muxing for DVDs. It’s output is quite strict and deals well with picky software/hardware.

[Reuben Martin]

Depends on what your are trying to play back the resulting video with. I can tell you right now that if you are trying to play it back with quicktime you are SOL.

[Reuben Martin]

It’s an IP cam. It lies about it’s frame rate. (It says it’s frame rate is 25fps but that’s crap)

When it can’t send the frame in time it just drops it. Playback at a fixed framerate will no ever be quite right, although using the framerate of 8 should be somewhat in the ballpark.

ffmpeg -re -r 8 -i https://c-cam.uchicago.edu/mjpg/video.mjpg -r 8 -vcodec libx264 -preset slower -vprofile high -trellis 2 -crf 22 -pix_fmt yuv420p -an -f mp4 IpCamCapture.mp4

[Reuben Martin]

Don’t know. I’ve never use xsans volumes. Try it and see what happens.

[Reuben Martin]

According to grep -r fallocate ./* from the ffmpeg source tree, it does not preallocate. You might be able to do that manually using cvmkfile.

Seriously doubt it will flatten a QT file. (have never tried to do it though) That is a function that is very specific to Quicktime on Mac OS.

[Reuben Martin]

Generally I’ve stuck with ffmpeg, mostly because the devs who frequent that side of the tracks seem to be a bit more interested in professional/broadcast video formats, while the libav counterparts seem to be more focused towards end-user/distribution formats. I really don’t have anything to back that up with other than that is the impression I get just from observation of mailing lists. However, all the cross pollination between the two generally keeps things in sync.

What makes it somewhat awkward is that I’m a heavy user of Gentoo linux, and there are several hard working maintainers who put a lot of effort into maintaining Gentoo who are also strong proponents and developers for libav as well.

I generally try to skirt the issue as much as possible. There are a lot of bruised egos, and bad blood between various individuals. Getting involved is just poking the hornets nest with a stick.

There are some very talented developers from both sides, but with the personal conflicts involved, it might be that they are both more productive working apart from each other. I hope that someday the two camps will merge back into one project, but that is not going to happen anytime in the near future.