Hi On Thu, Aug 23, 2007 at 05:01:22PM -0400, David Conrad wrote: [...] > > the slice_offset/slice_count should be deprecated, it was bad > > design ... > > > > the standard h.264/mpeg1/... way is that there is a startcode which > > does not > > occur anywhere in the bitstream so you just search for that if you > > need to > > know where the slices start, i guess that doesnt work with rv40 ... > > > > the second simple solution is just to decode slice after slice if > > thats > > possible without knowing where the slices start and end > > > > the third solution is to make the demuxer (which knows where the > > slices > > start put this data in the returned packet, like > > 32bit length of first slice, 32bit length of second slice, ... > > (you know where the list ends from the fact that theres no space left) > > of course there are a million other possible solutions > > The third would make supporting muxing Real video in Matroska easier :) > > I think Matroska is supposed to use the packed bitstream format > described at http://www.bunkus.org/videotools/librmff/doc/index.html > but the samples I have don't seem to correspond to this. Instead, the > first byte is the number of slices minus one, then for each slice > there's 4 bytes of something (always 0x01 0x00 0x00 0x00 in my > samples) and a 32bit LE offset to where the slice starts, then the > slice data after this header. See http://samples.mplayerhq.hu/ > Matroska/realaudio/nosound.mkv for an example.
ok then it would likely make sense if our real demuxer would generate the same simplifies interoperability and we dont introduce a new redundant packing ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
