Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Why is start 5.3 in the specification? #168
Why is the language of
Recording multiple tracks was intended to be possible from day one. Many formats handle multiple tracks.
When it was pointed out that a lot of container formats couldn't handle increasing the number of channels mid-recording, we were left with two choices:
I am not aware of any change in the landscape of container formats that seems to indicate that varying the number of tracks is a generally available option. If you know of such changes, please provide references.
As for the "replace track" option - I don't think anyone thought about that possibility at the time.
That intention should not be abandoned. Or state clearly to abandon all hope of multiple tracks
From a novice front-end perspective (within the context of the use case of not stopping
Again, from a novice front-end perspective with little experiece reading (https://gist.github.com/guest271314/f942fb9febd9c197bd3824973794ba3e ; https://gist.github.com/guest271314/17d62bf74a97d3f111aa25605a9cd1ca) and no experience writing media containers, given that the decoder/encoder/writer must write in sequential, linear order, it should not make any difference what the input media is. Each media container (and codec) that
@alvestrand For clarity, the use case is not necessarily to record and write multiple individual tracks, but to write a single video track, which is already possible for audio using
Is the concern variable video width, height, and audio channel and playback rate, etc.?
What exactly do you mean by "varying the number of tracks"?
From a cursory point of view one of the WebM VOD patterns http://wiki.webmproject.org/adaptive-streaming/webm-vod-baseline-format should be able to achieve the requirement?
Have been considering composing a very basic media container format (not necessarily with compression as the model, but creation in modern FOSS browsers using only the API's shipped with FOSS browsers), where for every 1 second N (e.g., 25; 30; 60) images and 1 or more audio are in 1 "packet"; the images can have any
Ultimately trying to do something like
for static files and/or live "media streams".
Not a novel concept.
Would be unnecessary if the media encoder, media decoder, webm writer and web media player internal code was exposed as API's, for users to decode, encode and write their own media, without the boundaries of specifications or implementation of the day.
FWIW, the WebRTC and Media Capture and Streams API's are ingenious
If reading the below links correctly apparently Matroska supports multiple tracks in the same file
See Select Video Stream from multi-video MKV https://forum.kodi.tv/showthread.php?tid=152756&pid=2567118#pid2567118 at https://forum.kodi.tv/showthread.php?tid=152756&pid=2567118#pid2567118 (implementation FernetMenta/xbmc@d05b884)
followed from Multi-Angle / Multi-Video Track MKV Support and Recommendations https://emby.media/community/index.php?/topic/46826-multi-angle-multi-video-track-mkv-support-and-recommendations/