[vlc] RE: [vlc] Rép. : [vlc] H263 payload sizes

[chris.2.dobbs at bt.com]

yes I did but and eariler posting to your NG suggested I use RFC4269 instead as this was the latest revision.
Are you saying that VLC expects RFC2190? 
my real q is simply how to packetise RTP/H63 packets from a file based H263 bitstream (which VLC will play fine fromt he file directly)
I can't seem to figure out how to delimit records sizes from the file into frames and such like...
-Chris

________________________________

From: vlc-bounce at videolan.org [mailto:vlc-bounce at videolan.org] On Behalf Of Philippe Coent
Sent: 01 March 2007 16:22
To: vlc at videolan.org
Subject: [vlc] Rép. : [vlc] H263 payload sizes


Hi,
Did you have a look to RFC2190 ?
 
Here's an extract :
"H.263 Payload Header

   For H.263 video streams, each RTP packet carries only one H.263 video
   packet. The H.263 payload header is always present for each H.263
   video packet.

   Three formats (mode A, mode B and mode C) are defined for H.263
   payload header. In mode A, an H.263 payload header of four bytes is
   present before actual compressed H.263 video bitstream in a packet.
   It allows fragmentation at GOB boundaries. In mode B, an eight byte
   H.263 payload header is used and each packet starts at MB boundaries
   without the PB-frames option. Finally, a twelve byte H.263 payload

   header is defined in mode C to support fragmentation at MB boundaries
   for frames that are coded with the PB-frames option.

   The mode of each H.263 payload header is indicated by the F and P
   fields in the header. Packets of different modes can be intermixed.
   All client application are required to be able to receive packets in
   any mode, but decoding of mode C packets is optional because the PB-
   frames feature is optional.

   In this section, the H.263 payload format is shown as rows of 32-bit
   words. Each word is transmitted in network byte order. Whenever a
   field represents a numeric value, the most significant bit is at the
   left of the field.
"
 
HTH
Philippe




>>> chris.2.dobbs at bt.com jeudi 1 mars 2007 16:39:27 >>>


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/2bda1161/attachment.html>