[Live-devel] openRTSP questions....

[Karl Denninger]

On 5/24/2018 16:29, Karl Denninger wrote:
>> On 5/24/2018 15:38, Ross Finlayson wrote:
>>> Karl,
>>>
>>> I can’t help you with your problem with the MP4-format file; however:
>>>
>>>> 2. Attempting to extract just the video track ("-v") appears to work, and a file command shows "test.h264: JVT NAL sequence, H.264 video @ L 50", which should be ok.  However, I cannot play that with *any* of the tools in question, including VLC
>>> The latest version (3.0.1) of VLC has a known bug that makes it unable to play “.h264” (i.e., raw H.264) video files.  However the previous version (2.2.8) of VLC should work OK.
>> Unfortunately it appears that the base ExoPlayer can't decode it,
>> which strongly implies that whatever is in that file is no good (I
>> took the ExoPlayer demo code, added a link to the H.264 file, and it
>> threw up on it) since the same source, hit with the (newly-available)
>> RTSP client over UDP on the same network gets the same stream from
>> the same camera and decodes and displays it just fine.
>>> Also, if you have “ffmpeg” installed, then you *might* be able to creating a working MP4-format file from the “.h264” file by running:
>>> 	ffmpeg -i vid.h264 -c copy vid.mp4
>>> (You might also need to add “-r <number-of-frames-per-second>” (e.g., “-r 10”) before the “-i”.)
>>>
>> That doesn't help me since MP4 cannot be written as a stream (the
>> output must be seekable since on close there is header information, I
>> presume the length and similar, written.)
>>
>> That DOES, however, produce a playable MP4 file -- ExoPlayer is happy
>> to "eat" it.  The difference in "file" output is:
>>
>> test.mp4:  Apple QuickTime movie (unoptimized)
>> testx.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]
>>
>> And ffmpeg *does* know how to eat the raw H.264 file produced; the
>> data produced here is correct (note the fps rate is right, etc):
>>
>> Input #0, h264, from 'test2.h264':
>>   Duration: N/A, bitrate: N/A
>>     Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709,
>> progressive), 1920x1080 [SAR 1:1 DAR 16:9], 10 fps, 10 tbr, 1200k
>> tbn, 20 tbc
>>
>> So the H.264 file is good -- but ExoPlayer doesn't know how to
>> consume it as it sits.
>>
>> testx.mp4 is playable on Android's ExoPlayer, "test.mp4" (which is
>> what comes out of the openRTSP -4 command "nude") is not.  To make
>> testx.mp4 I took the raw (openRTSP -v rtsp:.... >out.h264) file as input.
>>
>> Interestingly enough a ".ts" file is also consumable although a
>> "file" on it says it's a raw data file, so if can come up with a
>> *streamable* output from the original H.264 format that works I'm
>> golden..... Any idea on what the correct magic incantation is to use
>> to produce that format out a stream (e.g. to stdout) rather than a
>> file; the obvious ("-f ts") produces a complaint that it is not a
>> proper format.
>>
>> Essentially what I need to be able to do is generate a video stream
>> that remains a stream (can be piped); the intent is to provide a
>> means to take camera data from devices that can't support secured
>> data paths (e.g. RTSP but no SSL support, etc) and pass it through an
>> SSL/TCP channel.
>>
Well this has turned into a "barricaded door" sort of thing now.

I ran some tests after figuring out how to feed ffmpeg a live stream and
recoding it (which it says is really only repackaging, as the in and out
codecs are still H.264!) and not only does it pull a full CPU's worth of
data on my AMDx64 Xeon machine it *also* grabs nearly a gigabyte and a
half of RAM while doing it. (eek!)  Lightweight and fast (so claims
ffmpeg) my tailfeathers.

Uh, not on a little embedded computer... no, that's not going to work :-)

Back to the drawing board I go.  I'm trying like the devil to avoid
having to compile up the library for Android directly, which I know
others have done (e.g. TinyCam) because doing so makes the code
architecture-specific.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20180524/64628cbb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20180524/64628cbb/attachment-0001.bin>