On Aug 23, 2007, at 2:11 PM, Michael Niedermayer wrote: > Hi > > On Thu, Aug 23, 2007 at 08:06:21PM +0300, Kostya wrote: >> On Thu, Aug 23, 2007 at 06:38:03PM +0200, Michael Niedermayer wrote: >>> Hi >>> >>> On Thu, Aug 23, 2007 at 07:18:08PM +0300, Kostya wrote: >>>> On Thu, Aug 23, 2007 at 06:05:26PM +0200, kostya wrote: >>>>> Author: kostya >>>>> Date: Thu Aug 23 18:05:26 2007 >>>>> New Revision: 1168 >>>>> >>>>> Log: >>>>> Handle case when slice tail is sent as another slice >>>> >>>> Let me elaborate on it a bit. >>>> >>>> Real container stores video frame by slices (controversal >>>> decision to me). >>>> They decided to drop macroblock count in slice, so you need >>>> either to get >>>> next slice, parse its header and set limit or just decode until >>>> end and >>>> hope thet nothing goes wrong. But it appears that sometimes >>>> slice end is >>>> stored as new slice so you need to add it to the end before >>>> decoding. >>>> >>>> In order to workaround this err... design I keep track of last >>>> macroblock >>>> decoded successfully in slice and in case of bit reader reading >>>> past >>>> frame data set mode expecting frame tail, then if it arrives >>>> (without >>>> correct slice header), concatenating it with the previous data and >>>> decoding starting from the last successfully decoded macroblock. >>> >>> you should use a parser which puts these parts back together >>> how should it work with remuxing in another container lets say >>> matroska, i very seriously doubt that it will work if the tail of >>> a slice >>> is in the next frame ... >> >> Not frame, it belongs to the same frame, just resides in separate >> slice. >> Typical RV40 intra frames contain about 11 slices, interframes - >> 2-4 slices. >> Also I doubt that SoC Matroska muxer will be able to do this (but >> I will >> ge happy if proven wrong).
SoC Matroska muxer currently doesn't handle any Real codecs correctly... >>> also are you sure that there are no flags/sizes at demuxer level >>> which >>> could be used to easily combine these parts into slices or frames >>> without needing to look into the codec bitstream? >> >> There seems to be something. At least MPlayer demuxer gathers >> slices for >> one frame (including those loose tails). >> >>>> >>>> I've run my decoder under FFplay and MPlayer and should note >>>> that lavf >>>> demuxer drops some frames (can be clearly seen on title fade out in >>>> test.rmvb), so I will try to fix it. >>> >>> thanks >> >> Can you give some hints on how to operate on slices gathered into >> one frame? >> Setting avctx->slice_offset[] and avctx->slice_count in parser is >> impossible >> because of race conditions. > > 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. _______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
