[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