raw H.263 RTP/UDP Input Stream without TS - doesn't work

bbishopski · Postby **bbishopski** » 12 Apr 2006 23:47

I am receiving an H.263 RTP stream. Ethereal correctly decodes it as H.263. It's raw RTP over UDP (no transport stream). This is realtime video from a webcam.

I have searched forums and tried many suggestions, such as specifying SDP - nothing works.

When I use SDP; only profiles 32,33 seem to be supported. I tried using 96 - but I get invalid codec message.

I'm using latest 0.8.5 test2.

It seems like some have gotten this to work with vBrick, using SDP profile 96 (dynamic) - but like I said, I get invalid codec error. When I change to 32 or 33 I get past that error message.

VLC seems to want input over TS or RTSP - is what I'm trying to do even supported?

Here'a couple of SDP files I've tried:

v=0
o=- 2412748169 1 IN IP4 47.142.150.89
s=test.com
p=+234 567 8900
c=IN IP4 47.142.150.89
t=0 0
m=video 50060/1 RTP/AVP 96
c=IN IP4 47.142.150.89
a=rtpmap:96 H263/90000

livedotcom error: no codec supported, aborting
ps error: cannot peek
mjpeg error: cannot peek
ps error: cannot peek
main error: no suitable demux module for `/://h263_2.sdp'

v=0
o=- 2412748169 1 IN IP4 47.142.150.89
s=test.com
p=+234 567 8900
c=IN IP4 47.142.150.89
t=0 0
m=video 50060/1 RTP/AVP 34
c=IN IP4 47.142.150.89
a=rtpmap:34H263/90000
a=fmtp:34 QCIF=3 MAXBR=64 D1 D2 E F

livedotcom error: no codec supported, aborting
ps error: cannot peek
mjpeg error: cannot peek
ps error: cannot peek
main error: no suitable demux module for `/://h263_2.sdp'

*** try to fake out VLC by specifying 33 to get past codec problem***

v=0
o=- 2412748169 1 IN IP4 47.142.150.89
s=test.com
p=+234 567 8900
c=IN IP4 47.142.150.89
t=0 0
m=video 50060/1 RTP/AVP 33
c=IN IP4 47.142.150.89
a=rtpmap:33 H263/90000
a=fmtp:33 QCIF=3 MAXBR=64 D1 D2 E F

ps warning: this does not look like an MPEG PS stream, continuing anyway
main debug: using demux2 module "ps"
main debug: looking for a subtitle file in C:\Program Files\VideoLAN\VLC\
access_udp warning: unimplemented query in control
main debug: `rtp://@47.142.150.89:50060' successfully opened
ps warning: garbage at input, trying to resync...

Thanks!

The DJ · Postby **The DJ** » 13 Apr 2006 12:51

DJ puts on his parrot hat.

eh what OS ???????

bbishopski · Postby **bbishopski** » 14 Apr 2006 13:34

Windows.

This doesn't seem OS specific though. Maybe I just don't know the correct syntax to get this working? Or maybe it's not supported?

Thanks for any advice.

Sheado · Postby **Sheado** » 05 Jul 2006 20:22

hi bbishopski..

i'm having the same problem. I've tried JPEG and H.263 RTP streams (since live555 says it supports them), but neither have worked.

The only RTP streams I can get to work are MPEG-based ones, which makes me wonder if I have to wrap my H.263 packets with TS headers before RTP packetizing them... but that doesn't make much sense!

Anybody have advice on this? I'm still new to the code so I'm totally lost right now =]
do I need to write my own demuxer? do i need to modify the live555 libraries?

Thanks!
Sheado

myid · Postby **myid** » 10 Jul 2006 13:10

Hi all,

I also seem to have the same problem. I am using my own Java/JMF application to capture webcam video and stream it over lan. I have used both JPEG/RTP and H263/RTP formats but I can not receive stream correctly with VLC player.

In both cases it seems like, looking from the VLC message dialog, that the VLC could not detect the RTP header and, thus, could not guess correct video format. However, in both cases, the Ethereal is able to decode UDP payload correctly into RTP with corresponding payload type, i.e. JPEG-compressed video (26) or ITU-T H.263 (34). I also tried to stream some MPEG video with my Java/JMF application and that I was able to receive with VLC.

Any ideas, what am I doing wrong? Is it even possible to receive JPEG/RTP or H263/RTP streams with VLC, or is only MPEG streams supported?

The DJ · Postby **The DJ** » 11 Jul 2006 20:22

links please.

Sheado · Postby **Sheado** » 12 Jul 2006 02:57

Ok.. so I'm still stuck on this. I started looking at the code (which btw could use some comments =P

udp.c shows that it only support three payload types (TS/RTP, MPEG audio/RTP, and MPEG video/RTP), none of which are JPEG/RTP, H263/RTP, or H264/RTP.

So I'm confused, cuz if you look at live555.cpp it has code that adds the 00000001 header which h264.c expects. But if udp.c is never invoking live555.cpp, then how is it supposed to work? Are we supposed to use a more specific command line option? I've been testing with the GUI by openning a udp/rtp stream.
(i'm still new to the code and vlc so sorry if these are dumb questions!)

any help would be awesome! thanks.
Sheado

myid · Postby **myid** » 12 Jul 2006 11:48

links please.

Hi DJ,

Here is a sample of H263/RTP packet sent by my JMF-based webcam application:

Code: Select all

User Datagram Protocol, Src Port: 1234 (1234), Dst Port: 1234 (1234)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    1... .... = Marker: True
    Payload type: ITU-T H.263 (34)
    Sequence number: 3877
    Timestamp: 11250
    Synchronization Source identifier: 1644919918
ITU-T Recommendation H.263 RTP Payload header (RFC2190)
    F: False
    p/b frame: False
    Start bit position: 0
    End bit position: 0
    SRC format: QCIF 176x144 (2)
    Inter-coded frame: False
    Motion vector: False
    Syntax-based arithmetic coding: False
    Advanced prediction option: False
    Reserved field: 0
    Differential quantization parameter: 0
    Temporal Reference for B frames: 0
    Temporal Reference for P frames: 0
    H263 Payload
        0000 0000 0000 0000 1... .... .... .... = H.263 Group of Block Start Code: 0x00000001
        H.263 stream: 9C7CD49554555F9FE6B0B8B2B8FEFFB5F69AF732F2F9E5EA...

And here is error messages outputted by VLC:

Code: Select all

main debug: using access2 module "access_udp"
main debug: pre buffering
access_udp debug: no RTP header detected
main debug: creating demux: access='udp' demux='' path='@'
main debug: looking for demux2 module: 44 candidates
ts warning: TS module discarded (lost sync)
ffmpeg debug: couldn't guess format
ps warning: this does not look like an MPEG PS stream, continuing anyway
main debug: using demux2 module "ps"
main debug: looking for a subtitle file in C:\Program Files\VideoLAN\VLC\
access_udp warning: unimplemented query in control
main debug: `udp://@' successfully opened
ps warning: garbage at input, trying to resync...

Quickly looking from the VLC source code (modules/access/udp.c), it looks like (I am not familiar with the VLC, so correct if I am wrong), that the VLC would only support RTP payload types 14 (MPA), 32 (MPV) and 33 (MP2T); therefore RTP payload types 34 (H263) and 26 (JPEG) would not be supported.

Code: Select all

    switch( i_payload_type )
    {
        case 33:
            msg_Dbg( p_access, "detected TS over RTP" );
            p_access->psz_demux = strdup( "ts" );
            break;

        case 14:
            msg_Dbg( p_access, "detected MPEG audio over RTP" );
            p_access->psz_demux = strdup( "mpga" );
            break;

        case 32:
            msg_Dbg( p_access, "detected MPEG video over RTP" );
            p_access->psz_demux = strdup( "mpgv" );
            break;

        default:
            msg_Dbg( p_access, "no RTP header detected" );
            p_access->pf_block = BlockUDP;
            p_access->info.b_prebuffered = VLC_TRUE;
            return p_block;
    }

Is this really the case, so that it is just impossible to use VLC to receive H263 or JPEG-compressed video streams over RTP?

Sheado · Postby **Sheado** » 12 Jul 2006 20:43

Ok. udp.c seems to be getting in the way of live555 and RTP streams that are supported by live555.

so i tried to route my RTP streams though a streaming server and then use RTSP (rtsp://...) to receive my streams. This invokes the live555 module.

With JMF i can receive JPEG/RTP (payload 26). H263 doesn't work, but as Live555 says, it only supports H263+. I was able to confirm this by receiving a H263-1998 stream (from a non-JMF source. since JMF only does regular H263). Unfortunately though, the streams are playing with a 1 second lag (i think VLC is buffering) - that's probably a question for another thread.

H264 also worked but only if you catch the stream at its beginning. It give the following error otherwise:

[00000378] packetizer_h264 packetizer warning: waiting for SPS

The DJ · Postby **The DJ** » 01 Aug 2006 00:18

on H264

There are two ways to stream.
Annex-b and non annex-b

You seem to be sending the SPS only at the very first (probably straight from a file). If you don't start at the beginning, then VLC cannot retrieve the SPS and cannot display the file.

The solution. Provide the SPS trough the SDP file. (look at some H264 RTSP streams from Apple )
Or interleave the SPS troughout your stream. (quite complicated to do).

Sheado · Postby **Sheado** » 01 Aug 2006 00:34

oh.. I started implementing RFC 3984 (H.264 payload over RTP). Is that not going to work for me:?: It says to disregard the Annex on streaming (I haven't read the H.264 spec yet btw. do i need to for this purpose?).

The RFC doesn't mention anything about SPS. I am just following the instructions on packetizing Single NAL Units and FU-A (fragmentation units) in non-interleaved mode.

btw.. which document talks about interleaving SPS? thanks for the input!!

praveen · Postby **praveen** » 01 Aug 2006 08:44

[quote="Sheado"]hi bbishopski..

Hi all,

please help me getting a c code for client program to receive VLC packets.

The VideoLAN Forums

raw H.263 RTP/UDP Input Stream without TS - doesn't work

raw H.263 RTP/UDP Input Stream without TS - doesn't work

H.263 over UDP

c code for client to receive VLC packets

Who is online