[Mesa-dev] [PATCH 1/2] st/vdpau: add VC-1 startcode if none is found in the stream
Christian König
deathsimple at vodafone.de
Thu Mar 15 08:42:11 PDT 2012
Hi Emeric,
On 15.03.2012 15:13, Emeric Grange wrote:
> I actually made some code that does exactly the opposite, for H.264
> and VP8, removing the start code from the first buffer containing it
> (so the first buffer alltoghether or just the 3 first bytes of the
> first buffer). I think the start codes, at least for H..264 are just
> here so the decoding application (in this case the state tracker) can
> make sure the buffers are valid video buffers, and are not used in the
> decoding process.
At least for H264 and AMD hardware that isn't such a good idea. The
startcodes are the indicators for the hardware decoder where slices
actually starts and ends (hence the name), so if the decoder doesn't
sees a startcode at the beginning of the buffer it will just skip
forward until it finds something that looks valid. And if I understood
Maarten Lankhorst correctly the nvidia hardware is doing this in a very
similar way.
> In my VP8 implementation I require a 0x9D012A start code, similar to
> H.264 that requires a 0x000001. I asked on the VDPAU mailing list if
> it was a good idea, and what was the purpose of these start code in
> the first place but I did not get an answer.
The idea behind startcodes is to have something that doesn't normally
occur in the encoded bitstream, so you can do network/transport
synchronization with it. In most of the modern codecs (MPEG2, MPEG4,
H264, VC-1) there seems to be some kind of consensus to use the bytes
0x00 0x00 0x01 + some code for that, but it could actually be any unique
combination of bytes.
So when a network error occur (for example cause it is a satellite, DVB,
whatever wireless broadcast transmission) the decoder can always
fallback to search for the next start code and so resynchronize the stream.
> However I have no idea if a VC1 decoder requires the presence of start
> codes, and your implementation is fine by me, I can still hook a
> vlVdpDecoderRemoveVP8Startcode() function similar to
> vlVdpDecoderFixVC1Startcode().
Well, the problem with VC-1 is that certain container formats (IIRC WMV)
doesn't use start codes, so they are not suited for streaming/broadcast
transmission, but on the other hand safes 4 bytes of space for each
frame (yeah another great Microsoft invention). So since the hardware
decoders seem to need the start codes we must add them manually.
Honestly I have no idea what to do in the VP8 case, so do whatever you
think is right there.
Christian.
More information about the mesa-dev
mailing list