<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px">
<DIV dir=ltr align=left><SPAN class=770055516-01032007><FONT size=1>yes I did
but and eariler posting to your NG suggested I use RFC4269 instead as this was
the latest revision.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=770055516-01032007><FONT size=1>Are you
saying that VLC expects RFC2190? </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=770055516-01032007><FONT size=1>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)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=770055516-01032007><FONT size=1>I can't seem
to figure out how to delimit records sizes from the file into frames and such
like...</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=770055516-01032007><FONT
size=1>-Chris</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT size=2><B>From:</B> vlc-bounce@videolan.org
[mailto:vlc-bounce@videolan.org] <B>On Behalf Of </B>Philippe
Coent<BR><B>Sent:</B> 01 March 2007 16:22<BR><B>To:</B>
vlc@videolan.org<BR><B>Subject:</B> [vlc] Rép. : [vlc] H263 payload
sizes<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>Hi,</DIV>
<DIV>Did you have a look to RFC2190 ?</DIV>
<DIV> </DIV>
<DIV>Here's an extract :</DIV>
<DIV>"H.263 Payload Header<BR><BR> For H.263 video streams, each RTP
packet carries only one H.263 video<BR> packet. The H.263 payload
header is always present for each H.263<BR> video
packet.<BR><BR> Three formats (mode A, mode B and mode C) are
defined for H.263<BR> payload header. In mode A, an H.263 payload
header of four bytes is<BR> present before actual compressed H.263
video bitstream in a packet.<BR> It allows fragmentation at GOB
boundaries. In mode B, an eight byte<BR> H.263 payload header is
used and each packet starts at MB boundaries<BR> without the
PB-frames option. Finally, a twelve byte H.263 payload<BR><BR>
header is defined in mode C to support fragmentation at MB
boundaries<BR> for frames that are coded with the PB-frames
option.<BR><BR> The mode of each H.263 payload header is indicated
by the F and P<BR> fields in the header. Packets of different modes
can be intermixed.<BR> All client application are required to be
able to receive packets in<BR> any mode, but decoding of mode C
packets is optional because the PB-<BR> frames feature is
optional.<BR><BR> In this section, the H.263 payload format is shown
as rows of 32-bit<BR> words. Each word is transmitted in network
byte order. Whenever a<BR> field represents a numeric value, the
most significant bit is at the<BR> left of the field.</DIV>
<DIV>"</DIV>
<DIV> </DIV>
<DIV>HTH</DIV>
<DIV>Philippe<BR><BR></DIV>
<DIV><BR><BR>>>> chris.2.dobbs@bt.com jeudi 1 mars 2007 16:39:27
>>><BR></DIV><!-- Converted from text/rtf format -->
<P><FONT face=Arial size=2>Sorry to be a pain but can anyone verify that the
following assumtions are correct when packetising H263 into RTP
packets</FONT></P>
<P><FONT face=Arial size=2>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 </FONT></P>
<P><FONT face=Arial size=2>1. The first packet shall have the h263 header P bit
set to one. (bit 6)</FONT> </P>
<P><FONT face=Arial size=2>2. Subsequent packets shall have P bit set to
zero</FONT> </P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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:</FONT></P><BR>
<P><FONT face="MS Shell Dlg 2" size=1>main error:</FONT> <FONT
face="MS Shell Dlg 2" color=#ff0000 size=1>picture 00BDBD98 refcount is
-1</FONT> <BR><FONT face="MS Shell Dlg 2" color=#000000 size=1>ffmpeg
warning:</FONT> <FONT face="MS Shell Dlg 2" color=#0000ff size=1>Error at MB:
3</FONT> <BR><FONT face="MS Shell Dlg 2" color=#0000ff
size=1> (h263@00B1E370)</FONT> <BR><FONT face="MS Shell Dlg 2"
color=#000000 size=1>ffmpeg debug: concealing 99 DC, 99 AC, 99 MV errors</FONT>
</P><BR>
<P><FONT face=Arial size=2>The video sequence freezes at this point but
continues again after 3-5 sec, then does the same</FONT> <BR><FONT face=Arial
size=2>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…?!!</FONT></P>
<P><FONT face=Arial size=2>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?</FONT></P>
<P><FONT face=Arial size=2>Help please….</FONT> </P>
<P><FONT face=Arial size=2>-Chris</FONT> </P><BR></BODY></HTML>