Francesco Romani wrote: > > On Sat, 2008-02-09 at 21:21 -0600, Carl Karsten wrote: > > What are my chances of merging /dev/video0 and /dev/video1 into one > > container? > [...] > > Roughly zero if you want to do on-the-fly: transcode is limited by > design to process one video stream and one audio stream. Removing this > limitation is not trivial at all and is not planned for any foreseeable > future. > > What can be done, at expense at some disk space, is to run two > contemporary istances of transcode and to merge later, off-line (read: > when recording stops) the two intermediate files.
The following is not intended for the Transcode developers, but for someone who might be interested in creating an intermediate data staging process which handles multiple video and audio streams. It's just my thoughts about the architecture of the problem, and contains no implementation details. Maybe this isn't useful to anyone. I believe that whether this sort of thing is supported in Transcode, or anywhere else, that the first step would be to create an intermediate container muxer for the multiple streams and the necessary metadata, and a demuxer that can make use of the container metadata to present arbitrary streams synchronously to the downstream stage. The grammar required up to this point is minimal. Given the freedom to do this without being bound by an existing standard makes it a *relatively* simple task, and that no information about the FORMAT of any of the streams need be (or should be) managed at this stage. The data container that I work with IRL is something like that, but with several thousand streams. Each stream has type and timing information, and flags for announcing that there are missing data. Missing data can also be handled by zero-padding. The container metadata can also hold arbitrary user supplied values, which is very useful. If you are a masochist, you might pack it up as XML. Maybe mkv is already sufficient to handle all of this this?
