[vlc] H263 payload sizes

[chris.2.dobbs at bt.com]

Sorry to be a pain but can anyone verify that the following assumtions
are correct when packetising H263 into RTP packets

Caveat here is that I have the H263 data in a file (hence I don't know
what size each indivual h263 encoded frame is) and am reading this in to
stream out to VLC 

1. The first packet shall have the h263 header P bit set to one. (bit 6)

2. Subsequent packets shall have P bit set to zero

3. When a record from the file contains a start of next frame marker
(which I am assuming is the 2 bytes of zeros I see sprinkled thoughout
the file ) I set the M bit in the RTP header to signal end of frame for
current frame.

I am struggling to understand how to correctly packetise as I get 'some'
results by playing this stream with VLC but it seems to taking far too
long in the RTP/demux stage before actually attempting to display frames
- I get errors like this:


main error: picture 00BDBD98 refcount is -1
ffmpeg warning: Error at MB: 3
 (h263 at 00B1E370)
ffmpeg debug: concealing 99 DC, 99 AC, 99 MV errors


The video sequence freezes at this point but continues again after 3-5
sec, then does the same
I suspect the demuxer is grabbing in RTP packets and not knowing when
the eof frame is so it just keep gobbling them up and when it's buffer
is full it hands them off to the h263 decoder...?!!

I used RFC4269 as a reference but it reads like stereo instructions and
seems to assumeI understand the H263 encoder which I don't. It states
that the P bit is start of picture marker but what does this mean? Start
of entire h263 video sequence or start of frame which is comprosed of
some unknown number of coded blocks?

Help please....

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20070301/f873eb4c/attachment.html>