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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
