<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 5/24/2018 16:29, Karl Denninger wrote:<br>
<blockquote type="cite"
cite="mid:64cc31f4-5800-422d-c43d-2c8a34c07175@denninger.net">
<blockquote type="cite"
cite="mid:e4a7d495-4bf1-49cb-29a2-053be6682f1e@denninger.net">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
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>
</div>
</blockquote>
</blockquote>
Well this has turned into a "barricaded door" sort of thing now.<br>
<br>
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.<br>
<br>
Uh, not on a little embedded computer... no, that's not going to
work :-)<br>
<br>
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.<br>
<br>
<div class="moz-signature">-- <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>