<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 5/24/2018 15:38, Ross Finlayson wrote:<br>
<blockquote type="cite"
cite="mid:63B5FA3F-85EF-4877-B005-39C933F653C6@live555.com">
<pre wrap="">Karl,
I can’t help you with your problem with the MP4-format file; however:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.
<blockquote type="cite"
cite="mid:63B5FA3F-85EF-4877-B005-39C933F653C6@live555.com">
<pre wrap="">
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”.)
</pre>
</blockquote>
<div class="moz-signature">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.)<br>
<br>
That DOES, however, produce a playable MP4 file -- ExoPlayer is
happy to "eat" it. The difference in "file" output is:<br>
<br>
test.mp4: Apple QuickTime movie (unoptimized)<br>
testx.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]<br>
<br>
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):<br>
<br>
Input #0, h264, from 'test2.h264':<br>
Duration: N/A, bitrate: N/A<br>
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<br>
<br>
So the H.264 file is good -- but ExoPlayer doesn't know how to
consume it as it sits.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
</div>
</body>
</html>