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.
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
