Demux H264 from (already recorded) raw RTSP stream on HDD

Question

I once had to record a video from an IP camera (Sony SRG 300SE) in a hurry. I did so by launching

gst-launch-1.0 rtspsrc location="rtsp://192.168.0.100/video1" ! filesink location="recording.raw"

which ran flawlessly. Now, I would like to demux the audio and video (aac and h264) from that file. I now know that it would have been much smarter to do that right when receiving the stream, but well, I didn't.

I already tried

1. gst-launch-1.0 rtspsrc location="recording.raw" ! ..., which results in "No valid RTSP URL was provided" (GStreamer 1.10.2);
2. ffmpeg -i recording.raw -c:v copy -c:a copy recording.mp4, which only leads to "Invalid data found when processing input" (ffmpeg 3.2.2)
3. gst-launch-1.0 filesrc location="recording.raw" ! application/x-rtp ! rtph264depay ! h264parse ! matroskamux ! filesink location=out.mkv, leading to WARNING: from element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: Could not decode stream. Additional debug info: gstrtpbasedepayload.c(503): gst_rtp_base_depayload_handle_buffer (): /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: Received invalid RTP payload, dropping

Is there any way I get at least the video out of that stream?

Update: 4. cat recording.raw | ffmpeg -i - -c:v copy -c:a copy recording.mp4 leads to pipe:: Invalid data found when processing input in ffmpeg 3.2.2, and to the following in an older build:

[aac @ 0x2d4b3a0] Format aac detected only with low score of 1, misdetection possible!
[aac @ 0x2d4c180] More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.                                                                                                                                            
[aac @ 0x2d4c180] Sample rate index in program config element does not match the sample rate index configured by the container.                                                         
[aac @ 0x2d4c180] Reserved bit set.
[aac @ 0x2d4c180] Prediction is not allowed in AAC-LC.
[aac @ 0x2d4c180] channel element 3.10 is not allocated
[aac @ 0x2d4c180] Assuming an incorrectly encoded 7.1 channel layout instead of a spec-compliant 7.1(wide) layout, use -strict 1 to decode according to the specification instead.
[aac @ 0x2d4c180] channel element 1.6 is not allocated
[aac @ 0x2d4c180] channel element 2.5 is not allocated
[aac @ 0x2d4c180] channel element 2.8 is not allocated
[aac @ 0x2d4c180] channel element 2.12 is not allocated
[aac @ 0x2d4c180] channel element 3.2 is not allocated
[aac @ 0x2d4c180] channel element 2.10 is not allocated
[aac @ 0x2d4c180] Reserved bit set.
[aac @ 0x2d4c180] Prediction is not allowed in AAC-LC.
[aac @ 0x2d4c180] Reserved bit set.
[aac @ 0x2d4c180] TNS filter order 15 is greater than maximum 12.
[aac @ 0x2d4c180] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x2d4c180] Inconsistent channel configuration.
[aac @ 0x2d4c180] get_buffer() failed
[aac @ 0x2d4c180] Reserved bit set.
[aac @ 0x2d4c180] Prediction is not allowed in AAC-LC.
[aac @ 0x2d4c180] channel element 1.5 is not allocated
[aac @ 0x2d4c180] Reserved bit set.
[aac @ 0x2d4c180] Pulse tool not allowed in eight short sequence.
[aac @ 0x2d4c180] Number of bands (30) exceeds limit (21).
[aac @ 0x2d4c180] Number of bands (16) exceeds limit (14).
[aac @ 0x2d4c180] Assuming an incorrectly encoded 7.1 channel layout instead of a spec-compliant 7.1(wide) layout, use -strict 1 to decode according to the specification instead.
[aac @ 0x2d4c180] Sample rate index in program config element does not match the sample rate index configured by the container.

...thus creating a AAC only file. As far as I can see, the AAC is silence (which could have be the case, though).

Thanks in advance, Pascal

Answer 1

gstrtspsrc examples such as these suggest that gstrtspsrc itself acts as a demuxer. What that means is that the output of a command like ...

gst-launch-1.0 rtspsrc location="rtsp://192.168.0.100/video1" ! filesink location="recording.raw"

... is just the first (RTP) stream contained in the RTSP session. Given the debug when playing the recorded file, this was likely the AAC stream. As for the other streams (e.g. the H264 stream) that may or may not have been part of the RTSP session, it simply ignored them and discarded the packets. As for the AAC data, it's likely not recoverable since the AAC packet boundary data is lost, and so parsing complete AAC packets from the RTP-encapsulated data would be nearly impossible. You could try filesrc location=recording.raw ! rtpaacdepay ! [ regular decoding elements ], but I give it a low chance of success, unfortunately...