Streaming Binary Data
Matt Schuckmannn
data, i.e. not audio or video. In my case I want to stream GPS meta data
from an rtp source to a RTMP destination but it seems like this concept
could be extended to stream other types of data or protocols (e.g.
closed caption text, interactive elements, etc)
However, it seems that at the heart of RTMPD it is assumed that
everything is ether audio or video (i.e. BaseStream::FeedData() has a
isAudio parameter, if it's not audio it's assumed to be video) so I
don't understand how I could extend the functionality without changing a
lot of the internals or cut and copying much of the existing classes.
I'm happy to do the work but I want to know or at least start the
conversation on what direction I should take. Or if I'm wrong and it is
easy to do what I want I need a little nudge in the right direction.
Thank you very much for any feedback,
Matt Schuckmann
C++ RTMP Server
On Jul 13, 2011, at 10:01 PM, Matt Schuckmannn wrote:
> I'm really kind of stuck here, I really want to be able to stream binary data, i.e. not audio or video. In my case I want to stream GPS meta data from an rtp source to a RTMP destination but it seems like this concept could be extended to stream other types of data or protocols (e.g. closed caption text, interactive elements, etc)
> However, it seems that at the heart of RTMPD it is assumed that everything is ether audio or video (i.e. BaseStream::FeedData() has a isAudio parameter, if it's not audio it's assumed to be video) so I don't understand how I could extend the functionality without changing a lot of the internals or cut and copying much of the existing classes.
No, is not. You can transfer other kind of data. Depending on the types of subscribed streams, you can also get your hands on the corresponding protocol and send additional data if the target protocol supports it. Streaming is transporting A/V data while protocols can transport streams and other data (like your case, GPS data).
Indeed, the current RTSP structure is not flexible enough so one can write code in his/her app without touching the core library. But after fixing that, getting the custom data out of the RTP channel is pretty simple. Also, sending that particular data further on subscribers (if it is permitted by the subscriber's protocol) is also easy. I will try to offer you an example of such customization. In the mean time, here are some hints:
>
> I'm happy to do the work but I want to know or at least start the conversation on what direction I should take. Or if I'm wrong and it is easy to do what I want I need a little nudge in the right direction.
>
> Thank you very much for any feedback,
> Matt Schuckmann
>
>
>
>
>
> You received this message because you are subscribed to "C++ RTMP Server" mailing list.
> To post to this group, send email to c-rtmp...@googlegroups.com
> To unsubscribe from this group, send email to
> c-rtmp-serve...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/c-rtmp-server?hl=en
------
Eugen-Andrei Gavriloaie
Web: http://www.rtmpd.com
Andriy
Thoretically you can use SDP from RTSP protocol. This is more flexible
way I think.
Matt Schuckmann
On Jul 13, 1:04 pm, C++ RTMP Server <crtmpser...@gmail.com> wrote:
> On Jul 13, 2011, at 10:01 PM, Matt Schuckmannn wrote:
>
> > I'm really kind of stuck here, I really want to be able to stream binary data, i.e. not audio or video. In my case I want to stream GPS meta data from an rtp source to a RTMP destination but it seems like this concept could be extended to stream other types of data or protocols (e.g. closed caption text, interactive elements, etc)
> > However, it seems that at the heart of RTMPD it is assumed that everything is ether audio or video (i.e. BaseStream::FeedData() has a isAudio parameter, if it's not audio it's assumed to be video) so I don't understand how I could extend the functionality without changing a lot of the internals or cut and copying much of the existing classes.
>
> No, is not. You can transfer other kind of data. Depending on the types of subscribed streams, you can also get your hands on the corresponding protocol and send additional data if the target protocol supports it. Streaming is transporting A/V data while protocols can transport streams and other data (like your case, GPS data).
>
> Indeed, the current RTSP structure is not flexible enough so one can write code in his/her app without touching the core library. But after fixing that, getting the custom data out of the RTP channel is pretty simple. Also, sending that particular data further on subscribers (if it is permitted by the subscriber's protocol) is also easy. I will try to offer you an example of such customization. In the mean time, here are some hints:
>
> http://pastebin.com/nbEMsUdp
>
it into a custom InNetRTPStream class and had the new code called when
new data comes in for my binary stream, I had to make changes to the
existing RTP infrastructure but I think they are good changes that I
can share, it will take a while longer to get things cleaned up sane
for sharing but I will.
One thing I just discovered is that sending rtmp notify messages is
currently not supported by the code, or at least not in the way you
suggested in your example code.
The problem I ran into is BaseRTMPAppProtocolHandler::SendRTMPMessage
doesn't have a case for RM_HEADER_MESSAGETYPE_NOTIFY messages so it
just fails to send the message.
So I'm wondering if I should be taking another path here or just add a
case for the NOTIFY type that just sends the message like most of the
other message types?
Thanks.
Matt S.
Matt Schuckmann
Matt S.
C++ RTMP Server
On Jul 15, 2011, at 2:16 AM, Matt Schuckmann wrote:
>
>
> On Jul 13, 1:04 pm, C++ RTMP Server <crtmpser...@gmail.com> wrote:
>> On Jul 13, 2011, at 10:01 PM, Matt Schuckmannn wrote:
>>
>>> I'm really kind of stuck here, I really want to be able to stream binary data, i.e. not audio or video. In my case I want to stream GPS meta data from an rtp source to a RTMP destination but it seems like this concept could be extended to stream other types of data or protocols (e.g. closed caption text, interactive elements, etc)
>>> However, it seems that at the heart of RTMPD it is assumed that everything is ether audio or video (i.e. BaseStream::FeedData() has a isAudio parameter, if it's not audio it's assumed to be video) so I don't understand how I could extend the functionality without changing a lot of the internals or cut and copying much of the existing classes.
>>
>> No, is not. You can transfer other kind of data. Depending on the types of subscribed streams, you can also get your hands on the corresponding protocol and send additional data if the target protocol supports it. Streaming is transporting A/V data while protocols can transport streams and other data (like your case, GPS data).
>>
>> Indeed, the current RTSP structure is not flexible enough so one can write code in his/her app without touching the core library. But after fixing that, getting the custom data out of the RTP channel is pretty simple. Also, sending that particular data further on subscribers (if it is permitted by the subscriber's protocol) is also easy. I will try to offer you an example of such customization. In the mean time, here are some hints:
>>
>> http://pastebin.com/nbEMsUdp
>>
>
> Ok I've made some good progress today, I took your code and integrated
> it into a custom InNetRTPStream class and had the new code called when
> new data comes in for my binary stream, I had to make changes to the
> existing RTP infrastructure but I think they are good changes that I
> can share, it will take a while longer to get things cleaned up sane
> for sharing but I will.
>
> One thing I just discovered is that sending rtmp notify messages is
> currently not supported by the code, or at least not in the way you
> suggested in your example code.
> The problem I ran into is BaseRTMPAppProtocolHandler::SendRTMPMessage
> doesn't have a case for RM_HEADER_MESSAGETYPE_NOTIFY messages so it
> just fails to send the message.
Yeah, you are right. That is a bug. At line 1669 after "case RM_HEADER_MESSAGETYPE_ABORTMESSAGE", just add "case RM_HEADER_MESSAGETYPE_NOTIFY". It should do the trick
Matt Schuckmann
>
> Yeah, you are right. That is a bug. At line 1669 after "case RM_HEADER_MESSAGETYPE_ABORTMESSAGE", just add "case RM_HEADER_MESSAGETYPE_NOTIFY". It should do the trick
>
modifications to you example code.
The simple one was the message name is "onCuePoint" not "cuePoint"
The other has to do with the first 2 parameters to the GetNotify()
method, you used 3 for the channelId and 0 for the streamId and those
didn't work.
By looking at what is used for sending the metaData when the video
starts I found that 20 for the channelId and 1 for the streamID works.
Of course that isn't the end of the story, because for sending the
metaData those values are determined from member variables of
BaseOutNetRTMPStream which I don't think I have any access to in my
InNetRTPStream class. So I guess I'm asking how should I determine
what channelID and streamID to send the cuePoint message on?
I'm also wondering what the timestamp parameter for GetNotify is for
and if it might be used to help synchronize my GPS data with my real-
time video?
Thanks,
Matt S.
C++ RTMP Server
On Jul 15, 2011, at 5:36 AM, Matt Schuckmann wrote:
>
>>
>> Yeah, you are right. That is a bug. At line 1669 after "case RM_HEADER_MESSAGETYPE_ABORTMESSAGE", just add "case RM_HEADER_MESSAGETYPE_NOTIFY". It should do the trick
>>
>
> Thanks for confirming that, and that did work after a couple more
> modifications to you example code.
> The simple one was the message name is "onCuePoint" not "cuePoint"
> The other has to do with the first 2 parameters to the GetNotify()
> method, you used 3 for the channelId and 0 for the streamId and those
> didn't work.
> By looking at what is used for sending the metaData when the video
> starts I found that 20 for the channelId and 1 for the streamID works.
> Of course that isn't the end of the story, because for sending the
> metaData those values are determined from member variables of
> BaseOutNetRTMPStream which I don't think I have any access to in my
> InNetRTPStream class.
Actually, you do. InNetRTPStream has access to the list of subscribers (outbound streams).
When cycling over them to send that metadata, you test the type of the stream. Since you know for sure that the stream is ST_OUT_NET_RTMP, is safe to cast it to BaseOutNetRTMPStream. You can now extract your data of interest (channel ID and stream ID). I think there are some getters in there already (for getting the stream id). The channel number doesn't really counts. It should work on channel 3 just fine.
Cheers,
Andrei
> So I guess I'm asking how should I determine
> what channelID and streamID to send the cuePoint message on?
> I'm also wondering what the timestamp parameter for GetNotify is for
> and if it might be used to help synchronize my GPS data with my real-
> time video?
>
> Thanks,
> Matt S.
>
C++ RTMP Server
uint32_t BaseOutNetRTMPStream::GetCommandsChannelId();
Are your friends
On Jul 15, 2011, at 5:36 AM, Matt Schuckmann wrote:
Matt Schuckmannn
You can checkout out a quick demo of what I've accomplished so far at
http://geonetweb.imoveinc.com/geonet/Flash/index.php?source_id=ladybug3_15fps&video_kbps=300&video_gop=200&video_fps=15
You'll need the GoogleEarth plugin installed and once the video loads
you need to manually zoom into the Portland, OR region to see the
moving marker, after that the map should follow the video. Double click
on the a point in the video to pan the view around 360deg or use the
zoom buttons to zoom in our out.
It's far from finished, or bulletproof but it's a good start. For right
now the video and GPS Cuepoints aren't very well synchronized, simply
sending them both out as fast as I can and putting things on the screen
as soon as possible. This works well under light load and a local
network but I don't know how well it will scale. I'm all ears on ways
to keep the latency down and keep things synchronized. Like I said
before I'm new to this Flash stuff.
Ma
tt S.