Home/ Questions/Q 6581515
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T16:09:45+00:00

i’m trying to write an application to stream videos like SipDroid, but SipDroid only

  • 0

i’m trying to write an application to stream videos like SipDroid, but SipDroid only streams videos with H263 codec.
i would like to stream videos with H264 codec and so i’ve to write a nal header.

i got some informations from here: http://www.networkdictionary.com/rfc/rfc3984.php?page=0%2C0
and i decided to use the fragmented units to stream (5.8. Fragmentation Units (FUs) (page 8)).

i’ve tried to create a nal header like this:

nal header http://www.networkdictionary.com/images/rfc3984f14.gif

with the following values for the indicator:

indicator http://www.networkdictionary.com/images/rfc3984-3.gif

F = 0, NRI = 2, Type = 28;

and the header:

header http://www.networkdictionary.com/images/rfc3984-4.gif

S=0 (1 at first packet), E = 0 (1 at last packet), R = 0, Type = 1;

The values of the packets are set correctly on client and server side. But i can’t read any video stream out of this packets.

the server is a simple java server, that receives the data and write it to a file.
i’ve also tried to show the stream on vlc player, but it also doesn’t work.

Does anybody know what the problem is, or what is missing to get a video stream at the server side?

EDIT:

ok, i think i’ve solved the problem. i’ve tried to get the header values from a (vlc player) rtp stream. in this stream the packet format depends on the frame size. is the frame size small enough for 1 packet so the packet has to be declared as a single nal packet with following values: NAL header: f 0, nri 2, type 1. if the frame size is bigger than the packet size, the packets get split and the format looks like i’ve posted in my question.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Note that RFC 3984 has been superseded by RFC 6184, though that doesn’t affect this question.

    In theory you can have an FU packet with S=1 and E=1, but it’s a waste of bits. A compliant decoder should decode it properly, but it’s a testcase that I doubt is well-exercised.

    Also make sure you’re using packetization-mode=1 in the SDP’s fmtp or the receiver shouldn’t decode it properly (though some might anyways). FU-A isn’t available in mode 0, which is the default.

    • 0