<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 15.03.2012 20:09, Emeric Grange wrote:
<blockquote
cite="mid:CAMmP6ndiF4uTJHYcdTkDATWm+bmmToMzRpg-ymC02Lg1nkqNqQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">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.
</div>
</blockquote>
Oh that's interesting, I always thought that this is something only
WMV/VC-1 does.<br>
<br>
<blockquote
cite="mid:CAMmP6ndiF4uTJHYcdTkDATWm+bmmToMzRpg-ymC02Lg1nkqNqQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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()..<br>
</blockquote>
</div>
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.<br>
</blockquote>
<div><br>
</div>
<div>
<div>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.</div>
</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAMmP6ndiF4uTJHYcdTkDATWm+bmmToMzRpg-ymC02Lg1nkqNqQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Honestly I have no idea what to do in the VP8 case, so do
whatever you think is right there.</blockquote>
<div><br>
</div>
<div>The VP8 "uncompressed frame header" requires the presence
of <span>a <font face="arial, sans-serif">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...</font></span></div>
</div>
</blockquote>
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...<br>
<br>
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.<br>
<br>
Thanks for the comments,<br>
Christian.<br>
</body>
</html>