Playing MPEG-4 Stream from IP Camera

[JasonC]

Hi,

I have a SONY SNCRZ25 IP Camera which i am trying to get working with VLC. The camera comes with an OCX for viewing which works fine, however i need to get access to the MPEG-4 stream for recording purposes. The camera supports both MJPEG and MPEG-4, and supports this over HTTP, RTP(UDP) Unicast and Multicast.

I can open the MJPEG stream in VLC over HTTP, however i am having big problems with getting the MPEG-4 bitstream working. I have tried it over HTTP and get the following results:

main debug: adding playlist item `http://10.1.1.4/mpeg4' ( http://10.1.1.4/mpeg4 )
main debug: creating new input thread
main debug: waiting for thread completion
main debug: thread 4208 (input) created at priority 1 (input/input.c:261)
main debug: `http://10.1.1.4/mpeg4' gives access `http' demux `' path `10.1.1.4/mpeg4'
main debug: creating demux: access='http' demux='' path='10.1.1.4/mpeg4'
main debug: looking for access_demux module: 0 candidates
main warning: no access_demux module matched "http"
main debug: creating access 'http' path='10.1.1.4/mpeg4'
main debug: looking for access2 module: 7 candidates
access_http debug: http: server='10.1.1.4' port=80 file='/mpeg4
main debug: net: connecting to 10.1.1.4 port 80
main debug: connection in progress
access_http debug: protocol 'HTTP' answer code 401
access_http debug: Server: Boa/0.94.14rc18
access_http debug: Content-Type: text/html; charset=ISO-8859-1
access_http debug: authentication failed
access_http debug: retrying with user=admin, pwd=admin
main debug: net: connecting to 10.1.1.4 port 80
main debug: connection in progress
access_http debug: protocol 'HTTP' answer code 200
access_http debug: Content-Type: video/mpeg
access_http debug: Pragma: no-cache
main debug: using access2 module "access_http"
main debug: pre-buffering...
main debug: received first data for our buffer
main debug: pre-buffering done 43525 bytes in 0s - 108 kbytes/s
main debug: creating demux: access='http' demux='' path='10.1.1.4/mpeg4'
main debug: looking for demux2 module: 44 candidates
main debug: looking for packetizer module: 17 candidates
main debug: using packetizer module "packetizer_mpegvideo"
main debug: selecting program id=0
main debug: using demux2 module "mpgv"
main debug: looking for a subtitle file in C:\Program Files\VLC\
main debug: looking for decoder module: 27 candidates
main debug: using decoder module "libmpeg2"
main debug: thread 4896 (decoder) created at priority 0 (input/decoder.c:159)
main debug: `http://10.1.1.4/mpeg4' successfully opened
packetizer_mpegvideo debug: waiting for sequence start
packetizer_mpegvideo debug: waiting for sequence start
packetizer_mpegvideo debug: waiting for sequence start
packetizer_mpegvideo debug: waiting for sequence start

It seems to be finding the stream ok once i enter the authentification info for the camera, but then sits there waiting for the sequence to start. The documentation on the camera says that once the HTTP command has been issued the camera "sends the MPEG4 raw data as its response", is this how vlc expects it?

If i try and use RTP Unicast, by starting VLC and opening a UDP/RTP stream on port 30000, then go to a browser and instruct the camera to do a MPEG-4 bitstream to port 30000 (using url: http://10.1.1.4/mpeg4?UdpMode=unicast&UdpPort=30000) i get the following:

main debug: adding playlist item `rtp://@:30000' ( rtp://@:30000 )
main debug: creating new input thread
main debug: waiting for thread completion
main debug: thread 4944 (input) created at priority 1 (input/input.c:261)
main debug: `rtp://@:30000' gives access `rtp' demux `' path `@:30000'
main debug: creating demux: access='rtp' demux='' path='@:30000'
main debug: looking for access_demux module: 0 candidates
main warning: no access_demux module matched "rtp"
main debug: creating access 'rtp' path='@:30000'
main debug: looking for access2 module: 6 candidates
access_udp debug: opening server=:0 local=:30000
main debug: net: connecting to '[]:0@[]:30000'
main debug: looking for network module: 1 candidate
ipv6 warning: cannot create socket (Winsock error 10047)
main debug: using network module "ipv6"
main debug: removing module "ipv6"
main debug: looking for network module: 1 candidate
ipv4 debug: resolving :30000...
main debug: using network module "ipv4"
main debug: removing module "ipv4"
main debug: using access2 module "access_udp"
main debug: pre buffering
access_udp debug: no RTP header detected
main debug: creating demux: access='rtp' demux='' path='@:30000'
main debug: looking for demux2 module: 44 candidates
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\VLC\
access_udp warning: unimplemented query in control
main debug: `rtp://@:30000' successfully opened
ps warning: garbage at input, trying to resync...

No idea what the problem is here, its clearly going to the correct port as vlc detects the stream once i have entered the url in the browser but can't seem to process it.

Having trawled round the net and these forums etc i have discovered info about how MPEG-4 bitstreams do not contain decode info and often SDP files are required, is that what my problem is in this case? VLC detects the stream but can't decode (or in the case of over HTTP doesn't get more data for some reason). I've read a few RFCs (3016, 3640 etc) and it seems it can be sent in-band rather than out of band (in an SDP file or the like) but the info i have on the cameras doesn't say if it does either so i'm stumped as what my next move should be. I could try and write my own sdp file but without knowing much about the bitstream this camera is sending that would be difficult and possibly big waste of time given i don't even know if this is the problem and given how complicated SDP files look


Any ideas or suggestions on how i can figure out what is going on?

Thanks alot & kind regards.
Jason

[jclark]

Hi,

I have a SONY SNCRZ25 IP Camera which i am trying to get working with VLC. The camera comes with an OCX for viewing which works fine, however i need to get access to the MPEG-4 stream for recording purposes. The camera supports both MJPEG and MPEG-4, and supports this over HTTP, RTP(UDP) Unicast and Multicast.

I have the same problem and my attempts to create a 'sdp' file has not been successfull.

[JasonC]

jclark: good to know i'm not the only one, hmm perhaps i won't bother creating an SDP file then. I emailed sony security support i'll let you know if i get a response. Looks like i'm gonna have to program something myself to get the stream and decode it etc. argh was hoping to be able to test it with existing software first, oh well

[DJ]

I have noted some inconsistencies here. You stated that the output was raw mp4 data. If I remember correctly this is .cmp (.m4v or .mp4v = raw mp4) where as MJPEG is different.

A few people have expressed problems with MJPEG starting with VLC 0.8.5 and have resolved this by going back to 0.8.4 You could also check the nightly builds to see if this has been addressed.

I don't know if .cmp (m4v mp4v) is supported by VLC as I believe this can be any compressed MP4 form. MJPEG is not considered raw when in a MP4 container.

http://downloads.videolan.org/pub/videolan/
To find VLC 0.8.4 or 0.8.4a

http://nightlies.videolan.org/
To check out nightly builds

http://www.videolan.org/vlc/features.html
Supported Formats

[jclark]

I have noted some inconsistencies here. You stated that the output was raw mp4 data. If I remember correctly this is .cmp (.m4v or .mp4v = raw mp4) where as MJPEG is different.

The Sony information, and 'support' is very limited on details of their mpeg-4 implementation, other than explicit statements in glossy brochures that they support this format.

When I was experimenting with using Qucktime, and hacking an SPD spec, I was able to get some pretty bizarre results, but no correct display. The 'fmpt config' item in the SDP is pretty complex to 'hack', so I then called Sony 'support', and basically got a 'using anything other than their web based widgetry is not supported' (Oh, yes, you can buy a chunk of software that allows access for 'professionals'... Their API doc basically only describes how to access certain functionality via HTML-CGI or similar.

I now have an even more bizarre complaint about this device. When it is accessed 'correctly', it expects RTCP responses from receiver nodes, even when it is multcast streaming mode. This is pretty much a killer for most of my apps for this device, which is usually one-way streaming, and multicast definately should not require any node to respond to maintain the streaming media. Another problem that I've found out is that I can not seem to get it to respond correctly through routers. I have no clue as to what that is all about. It's not a matter of a 'firewall' or what have you, as I'm at the moment routing from one incoming linux ethernet interface and out another, monitoring the packet data between the camera and the browser, and the stream 'just stops' after an initial few http transactions...

At the moment, unless Sony 'support' gives me a call back with details the only thing this device seems to be good for is a paper weight, as it's not heavy enough for a boat anchor, unless of course one's needs are so minimal that the browser interface is sufficient.

[JasonC]

DJ: Yeah i know MJPEG (motion JPEG) and MPEG-4 are different, the camera in question supports both. The MJPEG funnily enough is the one which works with VLC unfortunately its the MPEG-4 streaming i need

jclark: Yeah the sony documentation is pretty sparse, i haven't gotten a response from Sony Support and certainly aren't counting on one anymore either.

Its good to know you tried the SDP approach since that was the next thing i was going to try, but yeah some of those fields look quite complicated. Other companies which have IP camera gear such as Axis, have good documentation and have libraries to do pretty much everything you need. They explicitly say that they support streaming to 3rd part apps such as vlc and quicktime so perhaps its not a common feature, i just assumed it (VLC, quicktime etc) should be able to play it somehow.

I guess my only recourse from here is to build my own library for accessing the stream, i would have had to do that at some point anyway i guess, but would have been nice to test it using vlc. It should just involve listening on a certain port (a RTP(unicast) one) getting the RTP header, getting the payload, taking the MPEG4 header and payload out. The one detail i'm fuzzy about is what all this commotion about SDP files is. They are meant so the decoder can decode the MPEG4 data, i originally thought all that info would be in the MPEG4 header, and some RFC's indicate decode info can be sent "in-band", however with the limited info about this sony camera its hard to know, i'm still a little fuzzy on those details but i guess i'll find out soon enough when i start programming this thing.

[jclark]

The one detail i'm fuzzy about is what all this commotion about SDP files is. They are meant so the decoder can decode the MPEG4 data, i originally thought all that info would be in the MPEG4 header, and some RFC's indicate decode info can be sent "in-band", however with the limited info about this sony camera its hard to know, i'm still a little fuzzy on those details but i guess i'll find out soon enough when i start programming this thing.

Well, I posted my discontent with the Sony device. What is really 'odd' is that about an hour ago I got a call from someone at Sony... told him about my lack of enthusiasm for the product, given the lack of documentation, etc. He said something to the effect of 'Oh, don't know you know about the ISV program??', "Uh, no, what's that, the 'support' person didn't mention anything more than what was on the website documentation.'

So, perhaps you could pursue that line. As for me, I got an equivalent Axis device, their 214 PTZ model, which basically 'does the right thing' relative to RTP/MPEG4/RTSP and produces the SDP appropriate for the mpeg4 stream configuration.

Both Quicktime and VLC work with it, 'out of the box', after the usual network configuration.

If you don't have the ability to change the device, I don't know how much you can do. RTP is a 'transport' method... Mpeg-4 is a 'container' for potentially a myriad of formats... the use of the SDP information data is to allow for server and player to 'agree' on how to interpret the data.

It may be that some mpeg-4 streams do contain information which would allow you to reconstruct the info provided in the SDP data, but I think it is going to be tough with the Sony device, unless by signing an NDA and getting whatever 'integrator' information they have, that does give you enough.

I'm sure there are problems with the Axis device, and who knows, perhaps the devices are all made at the same factory in China, but at the moment it seems to be a better solution for the custom integrator, than the Sony.

[dregzzen]

Hello,

We are working with the same camera and we are finding the same problems than yours. We are using the cgi to establish the control of the device, but when we try to retrieve the stream, vlc cannot establish the session with the camera device and it cannot open de vlc display.
Are you found any solution already? or the only solution (instead change the camera, of course) is to build a new session file properties to reach the connection?


Thanks and regards

(Oh, sorry for my english style, but is not my natural language )

[JasonC]

Its been a while so thought i'd give an update for anyone who is currently having this problem.

In short SDP seems like a bit of a mission to get working for this, but would be required to make vlc play this.

The solution we have found was to make an RTP directshow filter which gets this stream in and then hands it off to a decoder to decode it.

So basically forget getting this camera to work in vlc (easily at least), as jclark mentioned other brands such as Axis support playing via 3rd party apps such as vlc and quicktime etc outa the box, but the support on this product from sony is pitiful, so unless you are just gonna use the activex component they supply its alot more hassle than its worth.

Kind regards.