<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Sorry for the top-post but wanted to flag this -- I was wrong about
    the ".ts" file being able to be consumed, it is not --<br>
    <br>
    05-24 16:58:24.496 12619-12619/com.google.android.exoplayer2.demo
    D/EventLogger:   Renderer:0 [<br>
            Group:0, adaptive_supported=N/A [<br>
              [ ] Track:0, id=1/256, mimeType=video/mpeg2,
    res=1920x1080, supported=NO_UNSUPPORTED_TYPE<br>
            ]<br>
          ]<br>
        ]<br>
    05-24 16:58:24.511 12619-12619/com.google.android.exoplayer2.demo
    D/EventLogger: loading [0.44, 0.00, window=0, period=0, false]<br>
    <br>
    ExoPlayer sees it, but can't play it.<br>
    <br>
    On 5/24/2018 16:29, Karl Denninger wrote:<br>
    <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>
        -- <br>
        Karl Denninger<br>
        <a href="mailto:karl@denninger.net" moz-do-not-send="true">karl@denninger.net</a><br>
        <i>The Market Ticker</i><br>
        <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
      </div>
      <!--'"--><br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
    </blockquote>
    <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>