[FFmpeg-devel] Realmedia patch

[Luca Abeni]

Hi Ronald,

Ronald S. Bultje wrote:
[...]
> So... I made one modification in this patch, it allowed me to get
> video to work, but it's kind of ugly:
> 
> in rtsp_read_packet():
> 
> @@ -1246,6 +1246,8 @@
>      ret = url_readbuf(rt->rtsp_hd, buf, len);
>      if (ret != len)
>          return -1;
> +    if (rt->server_type == RTSP_SERVER_RDT)
> +        id = (buf[0] >> 1) & 0x1f;
> 
>      /* find the matching stream */
>      for(i = 0; i < rt->nb_rtsp_streams; i++) {
> 
> I just found out that the byte after $ is always 0, which is maybe why
> Luca was confused and thought they only contain one stream. However,
> they really contain multiple streams, but the RTP^d^dDT header
> apparently uses the 4th byte after the $ for the stream, as per above.

Ugh... This confirms that real rtsp is _really_ a mess... According to
RFC 2326,
"  Stream data such as RTP packets is encapsulated by an ASCII dollar
    sign (24 hexadecimal), followed by a one-byte channel identifier,
    followed by the length of the encapsulated binary data as a binary,
    two-byte integer in network byte order. The stream data follows
    immediately afterwards, without a CRLF, but including the upper-layer
    protocol headers. Each $ block contains exactly one upper-layer
    protocol data unit, e.g., one RTP packet."
So, the byte that you are parsing for getting the id is really part
of the "stream data". That is to say, it is part of the RDT header...
This confirms that audio and video are really mixed in the same stream,
and you must read the RDT header to make a distinction between audio
and video.


> I can move this to ff_rdt_parse_packet() if you prefer it there

Yes, this belongs to ff_rdt_parse_packet(), since it has nothing to
do with RTSP...


				Luca