![]() ![]() MCIAVI, as it turns out, seems to read almost anything correctly, and will even play Nandub MP3-compressed files even when ![]() You can get Tsunami to work, however, if you force it to use DirectShow to read the source AVI. Tsunami MPEG Encoder 2.0's OpenDML parser doesn't like the files either and either reads no audio or badly broken audio when faced with Like Sasami2k, which are basically the same DirectShow engine with some add-ons.) The files are useless for editing. (This also applies to the many DirectShow-based players out there, No offense to Nando, since it's a pretty neat trick, but the truth is that it just doesn't work forĪnything other than playing in Windows Media Player. ![]() The eventual point of all of this is that the AVI files are basically Value when AVIStreamLength() is called, this generally results in some nice errors when AVIFile-based applicationsĪttempt to read the files and can't get any samples at all. Because AVIFile reports the dwLength header Thus, AVIFile sees zero samples where DirectShow sees one, and as a resultĪudio samples at all from a Nandub MP3-based AVI file. The killer, though, is that AVIFile's parser rounds down instead of up when it sees blocks that aren't a multiple of Works if you disconnect the audio stream or decompress it, or use a regular AVI file. In a direct copy configuration (File reader -> AVI splitter -> AVI mux -> File writer), even though it Second, neither DirectShow norĪVIFile will write out an audio stream in this way, so nearly any other program will trash the AVI file when it's rewritten.ĭirectShow actually refuses to rewrite the stream with an "The data is invalid" error if you try using GraphEdit So everything is hunky dory and we can use VBR audio, right? Unfortunately, not really.įirst, DirectShow's buffering does not seem to react very quickly to VBR audio, and if you have high variance in theĪudio stream, it can cause the video playback to suddenly speed up or slow down. ![]() In actuality, any nBlockAlign value will work as long as it is as least as large as the biggest Larger, this causes DirectShow to seek as if every MPEG frame was a sample, which gives accurate seeking even with VBR Since no MPEG frame created by the MP3 codec is 1152 bytes or Purposes, rounds up all of the chunk sizes. This ends up interacting with an interesting bug/feature in the DirectShow AVI parser, which, for seeking The odd thing here is that this causes all of the audio chunks to be smaller than the nBlockAlign Ordinarily, this is a bad idea because itĬauses multiple audio blocks to be written for each video frames and consumes a couple of additional % in the AVI for Nandub writes each MPEG audio frame as a separate chunk in the file. Stream should be horribly desynchronized.Įxcept for the strange nBlockAlign value and the way that Nandub writes out audio samples. Independent of bitrate here, so with a fixed blocksize and a compressed sample rate regardless of bitrate, the audio Now, you'll notice that dwRate/dwScale is Streams, but those are usually low bitrate and seldom used. The significance of the dwRate/dwScale fraction is that MPEG-1 audio framesĭecompress to 1152 samples each it turns out that this is incorrect for MPEG-2 (16-24KHz) and MPEG-2.5 (8-12KHz) Streams, so setting it to zero for VBR operation doesn't work at all - the AVI parsers use the nBlockAlign
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |