[Matroska-devel] New elements
steve.lhomme at free.fr
Wed Jan 7 13:25:18 CET 2004
Christian HJ Wiesner wrote:
> Its ESSENTIAL that we are 100% sure about what we are doing here. Have
> we thought about :
> - inaccurate sampling rates, like 44055 Hz, as caused by inferior
> soundcards doing live recordings ? For the time being, many analog
> capture fans convert from AVI/MPEG to matroska, because our container
> will keep sync in any case, while the sample rate based containers fail
> very often on keeping sync for analog capturing, especially with bad
I agree there is a problem if the number of samples doesn't meet the
timecode*sampling freq. But there will be a playback problem in this
case anyway. And this problem will only exist for "live" recordings
where the timestamp is taken from the general clock and the sample count
computed on the fly. Maybe this sample count should not be written in
the case of "live" recordings ? Because for offline computing, the
timecode should be computed from sample count / sampling freq. This is
always the case when muxing data from external audio files.
> - if a player, say its foobar2000, wants to do gapless playback of
> multiple MKA tracks in its playlist, and the file it has to play was
> made with VirtualdubMod or the matroska muxer on DirectShow for example,
> we cant have that because your new elements are not supported in the old
> files. Thats sucks ! In short, there will be some files that play
> gapless, some wont. And as our specs will *always* allow both ways to
> make MKA files, the users will never be able to trust that gapless MKA
> playback works.
Well, as Matroska was yesterday, it can't ensure gapless playback. At
least the way it's done in foobar2k. Ie jump to a specific location in
the file when the previous part is done. So it's not a question wether
old tools don't support this. They never did. They need to be updated if
they want to support gapless playback.
> Have we really investigated *ALL* possibilities to make sample accurate
> seeking possible with any MKA file, even with a lower timecode accuracy
> ? What about putting some intelligence into the players here ?
The sample count *is* the absolute truth for sample accurate handling.
As said before all the data we have now in Matroska are not enough.
That's why we needed more. And I think we need more in Cues too.
> - if you are using special timecode scaling for every single track in a
> matroska file, depending on its sampling rate, and lets say the file has
> 5 or more tracks, wont it be pretty complicated and CPU intensive to
> parse these matroska files ? Dont forget, our matroska splitter will
> expose all audio streams on DirectShow, and its up to the
> player/switcher to select one of them, but still *ALL* tracks are parsed
> in the parser filter.
There should be no problem. The muxed files should be muxed as if all
data had the same "final" clock. So there won't be a parsing problem
when keeping things in sync.
And on playback the timecode is recomputed all the time from the scales.
That's already handled (or should be). There's no problem here.
> - accurate video editing with PCM sound might require to cut *exactly*
> the right PCM sample at the end of a video frame. If both tracks have
> the same timescale, thats no problem at all. If you start using
> different scales for each track, things might get complicated. You might
> find yourself in a situation where a specific PCM sample is added to
> both halfs of the splitted movie, and when these parts are concatenated
> again you are loosing sync ( ok, its only one sample ) because of the
> repeated sample.
Actually there's not much problems with PCM, if it is treated as such
(you know how to cut inside a frame). But IMO that's a bit too much
asking for such a precision. Because in the end you don't know it the
timecode of the video is precise or not. So asking for the PCM to be
more accurate than its reference is stupid.
There *is* a problem with audio-only files. If you want to cut this file
from sample X to sample Y, you can't. Because the sample X can be inside
a frame, as well as sample Y can be the first sample of another frame.
(like MP3, AAC or Vorbis frames). If you want to do that losslessly (no
reencoding) you need to keep the frame containing sample X, sample Y and
all frames in between. And in the resulting file you need to be able to
say that the frame with X should start playback at offset XX and that
the frame with Y should stop playback at offset YY (in the frame).
That means what I added yesterday is just half of it... It's just the
sample counter for the first sample of the (first) frame. But there
should also be somewhere the start and stop sample counts. Each with a
default value to 0 and "max" respectively. IMO that should be combined
with the TimeSlice.
More information about the Matroska-devel