Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

It can.  You can send a M3U8 with one giant segment defining the entire file and it'll play it.

Then that's what we should start with.

I don't know how it works with seeking though.

I think it's best to use custom code to handle seeking, just like Gizmo.

There's no reason JRemote couldn't do that, and I would think WebGizmo could as well using Javascript (paging javascript wizards).

[glynor]

I think it's best to use custom code to handle seeking, just like Gizmo.

There's no reason JRemote couldn't do that, and I would think WebGizmo could as well using Javascript (paging javascript wizards).

I don't disagree at all.

Should work.  Nothing in the documentation says the segments are size-limited (in fact, it says the opposite, just that they should be "equal").  I think I found some stuff on Stack Exchange earlier (maybe even those threads I linked before) where people said they could serve the TS as one big segment, they were complaining about needing to serve it via HTTP.  But that's not your problem.

And, you're right, you could handle WebGizmo through JavaScript, since your "server is smart" and knows how to generate the TS file at the right point as it goes.  In fact, JRemote could just use the MU38 to "get it going" and ignore it for all seeks, and just restart via MCWS.  That might work more reliably, and you wouldn't have to worry about the byte-boundary stuff at all.  You'll probably need to set the segment to be the length of the file, though (or 10 hours or something absurdly long to support live TV recording/rebroadcasting).  But who cares, because JRemote can just re-request via MCWS if it "runs out" of stream and hits the end.

Yep, that should be easy-peasy.  Set the segment length to the duration of the file (not the stream so-far, but the whole file, you know how long it is except live recording maybe), and send it...

EDIT: I took my previous post out (about recording byte-boundaries as you go) as I thought about it and I was wrong again.  You don't need to worry about it, I don't think, if you wrap the whole thing in one big one the full duration of the file itself, and use the "regular style" (simpler) M3U8 files.

[glynor]

Only way to know, really, is to try.  If you tell me what exact FFMPEG command you're using to generate the stream, I can easily do a test.  I could encode a little TS file (fully) via the same mechanism, put it on my web server, and hand-code a M3U8 file with a single giant segment and try to load it via Mobile Safari.

Of course, you might be able to try it even easier, so... Meh.

EDIT:  On second thought, I don't see FFMPEG in the install directory anywhere anymore, so you might be doing something different now (obviously).  Well, I suppose I could just use MCWS to make it give me one directly, and then just find it on disk and copy it.

Suggestions on the command URL to use?  I've never used MCWS before...

[glynor]

I figured it out.

I tried putting the MCWS URL directly in the M3U8, like this:

Code: [Select]

#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:1045
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:1045.0,
http://myserver.glynor.com:66666/MCWS/v1/File/GetFile.ts?File=9513888&FileType=Key&AndroidVersion=1&Token=XXXXXXX
Both with and without the Ending tag, with and without the TS after GetFile (and some other things), and it didn't work.  It "loads" in Safari and looks like it is going to play the video, but then throws a generic "operation could not be completed", which suggests the response from MCWS isn't quite what it expected.  It doesn't seem to be the length, as I also tried setting it to various times shorter than the full length.

I suspect it is either MIME Types or encoding.

When I downloaded the file in my browser, it came through as a MP4 file, which suggests you're setting the MIME Type to something?  I don't know enough about web programming to know how that works, really.

I saw something about that, though (read down to the second answer too):
http://stackoverflow.com/questions/11986313/http-live-streaming-for-iphone-and-why-we-use-m3u8-file

Or the encoding isn't quite right.

I'm uploading an encode to test.  I'll try a separate one that is "known good" to work on the iPhone (I can make one in FFMPEG or VLC pretty easily).

[jmone]

FYI:
- The transcoded files are stored in - C:\Users\[USERNAME]\AppData\Roaming\J River\Media Center 18\Temp
- AVCODEC files are stored in - C:\Users\[USERNAME]\AppData\Roaming\J River\Media Center 18\Plugins\avcodec

I'm not sure with the AVCODEC profile stuff is anymore (I can no longer find it but I used to manually edit it when first testing the DLNA stuff out years ago) but it may be buried in here - C:\Program Files (x86)\J River\Media Center 18\Data\Library Server\Gizmo\Default

[glynor]

Yeah... I found the storage spot.  But honestly, it was easiest just to download it right through the browser I was using to "trigger" the conversion anyway.

I haven't gotten it working yet.  I suspect the conversion settings being used aren't quite right, but I'm not sure how yet.  I need to test more, but this is my last day before we go away for a holiday, so I don't know how much time I'll have for the next few days.