[Live-devel] H264 RTP stream recording to AVI

[jon.bird at gd-ms.uk]

On 2017-01-06, Ross Finlayson wrote:

>> So rather than using our existing video sources, I've been looking
>> at using
> the OpenRTSP client to record streams from testOnDemandRTSPServer. I
> have a test H264 file in a Matroska container and can (sort of)
> successfully record a "raw" H264 file, playable by VLC using the following:
>> 
>> openRTSP -b 400000 -d 25 rtsp://192.168.204.3:8854/matroskaFileTest
>> 
>> I say "sort of" because I only get between 12-15s worth of video
>> (when I
> specified 25s) and for the first half of the stream, the colours
> appear very much washed out, which may be related to I-Frames (or the
> lack of them possibly).
> 
> Our software doesn’t do any video decoding/encoding, so it shouldn’t
> affect the colours in your video.  This suggests to me that you may
> have a problem with your original "test H264 file in a Matroska
> container”.  (Are you able to play this file directly using a video
> player application (e.g., VLC)?)
> 
> Instead, I suggest starting with a ‘raw’ H.264 video file - e.g., one of
> the “.264” files here: 	http://www.live555.com/liveMedia/public/264/ as
> noted in our FAQ entry here:
> 	http://live555.com/liveMedia/faq.html#264-file and use the
> “h264ESVideoTest” code in “testOnDemandRTSPServer”.
> 

I found one of these after posting my original mail and yes I can capture these ok (I can however also play the .mkv file in VLC but since I only created this for testing I'll not worry about that for now).

> 
>> Looking at the code for openRTSP, a key difference between that and
>> what
> I've done in the testMPEG2TransportReceiver is the passing of
> sPropParameterSetsStr
> 
> I don’t know why you are looking at the code for
> “testMPEG2TransportReceiver”; that code is used for receiving a
> multicast RTP stream that contains *MPEG Transport Stream* data -
> i.e., not what you want.
> 
> You said that your goal is:
>>  the recording of H264 video received over RTP
> 
Correct, I confess it's not clear from the documentation how I'd set this up - this seemed to be the closest I could find to what we want. 

> Does this H.264/RTP video stream have a RTSP server (i.e., a “rtsp://“ URL)?
> If so, then you should just use “openRTSP” (or our “testRTSPClient”
> demo code).  If, however, there’s no RTSP server, then I’m not really
> sure how your H.264/RTP video stream is supposed to be playable,
> because a video player (for a H.264) stream needs to know the SPS and
> PPS H.264 NAL units for the stream.  It usually gets this information
> from the stream’s SDP description (i.e., using the RTSP protocol).
> 
> But if you *really* don’t have a RTSP server, then you’ll need to
> find/figure out the SPS and PPS H.264 NAL units for the stream, and
> pass them to the "H264VideoFileSink::createNew()” function.  Or,
> prepend those NAL units to the H.264 video stream, if you want to do something else with it.
> 
We won't have an RTSP server providing this information however I am expecting to receive multicast SAP/SDP packets which should in theory hold this information, from my brief forage into this, these are I believe the NAL units which are characterized as "Parameter sets" and are generally sent in an "out of band" reliable transport mechanism - ie. RTSP/SAP. 

However what we have working as a prototype at the moment is a gstreamer pipeline which is able to successfully take an RTP stream and record it successfully without needing this additional information - most likely I suspect (from looking at the Wireshark trace) because the NAL data is also present in the RTP stream and it can pick this up from there. Hence my thinking that I should be able to do something similar with the Live555 libraries.

I think from what you've told me at the moment, we need to do a bit more research to make meaningful headway here.

Rgs.


Jon.

> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


--
Jon Bird, CEng MBCS
Software Engineer
Electronic Systems
General Dynamics United Kingdom Ltd.
Castleham Road, St Leonards on Sea, East Sussex, TN38 9NJ

Telephone: +441424798278
Email: jon.bird at gd-ms.uk
Website: www.generaldynamics.uk.com      

------------------------------------------------------------------------------

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.