[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
Tue Mar 20 02:24:11 PDT 2012


On 15.03.2012 20:09, Emeric Grange wrote:
> As far as I know only MPEG TS uses the 0x000001 start code for 
> network synchronization purpose as you said (I'm not even sure it's 
> really for resync). The H.264 Annex B is also the only "container 
> format" that uses these start codes. MKV or MP4 and probably every 
> other modern container formats doesn't uses start codes.
Oh that's interesting, I always thought that this is something only 
WMV/VC-1 does.

>         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.
>
>
> Well the start codes are not required by the video formats themselves, 
> that's why I was supposing the hardware decoders will not use them.
>
> As example, when mplayer decode a H.264 stream through VDPAU it just 
> hardcode the start code into a separate buffer, because it will not 
> find that code into the H.264 bitstream. So what is the difference 
> with the WMV case ? I think you should extend your mechanism (with 
> a different start code however) to H.264 as well.
Well, I have no idea why the start codes for VC-1 aren't handled in the 
same way as H.264, all I can tell is that the hardware definitely needs 
them.

>     Honestly I have no idea what to do in the VP8 case, so do whatever
>     you think is right there.
>
>
> The VP8 "uncompressed frame header" requires the presence of a 
> 0x9D012A start code for key frames, so let's just use this one as 
> mandatory VDPAU start code. This is a weird case because the start 
> code is only present in key frames, and not even at the start of the 
> frame header. Besides who stream VP8 not through webm files and tcp 
> networks ? Seems like a wast of space to me...
You're forgetting things like H.323, SIP, Skype etc... those are usually 
using RTP as their transport layer, and that thing is udp based, and so 
whatever codec is used for audio/video must be capable of handling lost 
or reordered packets. Also 4 extra bytes once every key frame doesn't 
sound like so much extra data...

Anyway, apart from the fact that the missing start code should only be 
added for VC-1 advanced profile the patch seemed to be valid. So I'm 
going to commit it.

Thanks for the comments,
Christian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120320/28b5e04a/attachment.html>


More information about the mesa-dev mailing list