Print

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

[JimH]

I received this in e-mail earlier today:

[In a test build] Gizmo has an option to enable HTTP Live Streaming, so you can quickly test if the old method still fails, and the new one succeeds.
Its by default off.

Bob and I tested it successfully.  My Note 3 has never played video from MC.  Now it does.

Hendrik has some cleanup to do.  It requires the next build of MC, too.  But it may show up this week if all goes well.

[jmone]

my F5 key is broken.  I keep mashing but can not find the Gizmo/MC updates as I can not wait to try on my gear. 

Well done Hendrik!

If all the stars align with Robert, is this new streaming method going to help out with Video to iOS as well?

[Hendrik]

HTTP Live Streaming (or HLS for short) is a protocol developed by Apple, so I would hope it works on their devices.

Right now the implementation only offers a "Live" playlist, which means there is no "native seeking", so if you want to seek, you have to tell MC to start encoding from a different point in time, like Gizmo does (and always did) - so it needs a tiny bit of custom handling here, otherwise I don't see any big problems trying to make use of it on iOS devices.

Another idea might be to get WebGizmo to use it, since WebGizmo is still stuck on a rather old video streaming format as well. But all in due time.

PS:
And there will be nothing ready today, if everything works out maybe tomorrow evening, to test over the weekend.

[glynor]

This is fantastic news!!!

Great job, Hendrik!  I was actually just thinking about this and looking up old threads from you on the subject.

[datdude]

Woooo Hooooo

[Hendrik]

Both Gizmo and MC are now available for testing.

[mojave]

Another idea might be to get WebGizmo to use it, since WebGizmo is still stuck on a rather old video streaming format as well. But all in due time.

I've never gotten WebGizmo to work very well when streaming video. However, I have downloaded Bluestacks which lets you run Android apps on the PC. I just installed Gizmo 19.0.113 and started playback of a recorded NFL game. It played back much better than in the past, but seeking didn't seem to work. I haven't installed 19.0.113 on my home PC that I was streaming from so I don't think it was using HTTP Live Streaming.

Using Gizmo on the PC is cool, though. If WebGizmo looked like this it would be awesome for PC tablets.

[mwillems]

Note that I do not expect the HLS support to be entirely flawless yet. I tested it on my tablet and my phone, and Jim and Bob tested it briefly, but it has by far not seen a wide range of testing yet.
If all else fails, Gizmo has a option to disable it until issues are resolved.

[Not sure if this should be here or in the Gizmo thread]

I tried the new 113 builds of Gizmo and Media Center.  Video playback through Gizmo works very well with my Samsung Note 3 for all of the video I tested, and it had never worked previously.  Seriously great news, thanks much for implementing this!

Two issues I had:

1) If I navigated away from a video and then tried to come back to playing now there was no way to "recover" the video (I'd just see what looked like an audio track playing with no video playback).  The "Resume playback" button started the audio playing but not the video, and stopping and restarting didn't help. I had to navigate to the library entry and restart it from there way to get video again.

2) I tried to play a video that was ripped to a DVD directory structure.  In MC if I just hit play on that particular library entry it just starts playing the episodes back to back; in Gizmo it did the same thing except with commentary tracks on and no way to disable them.  Obviously playback of DVDs ripped that way is going to be a little odd without being able to access the menus, but I thought I'd mention it.

[jmone]

Quick test and it look pretty good!

Playback looks good and as mentioned by Hendrik seeking with the method has some drawback but from what I have found so far:
- HLS is enabled by default
- Speed of Seeking, I think it is OK but to me seems longer than starting playback.  Also it seems to be no quicker going back even though there is already a Chunk sitting in the Temp directory.  Overall I'm fine with the delay and I'm sure most others would be but for those that jump all around it will be noticeable.  
- Seeking is problematic in that for me it mostly just crashes Gizmo (straight back to the Andriod IF).  
- When resuming playback the Seekbar is at 0 (so you can not seek to the begining of the file).
- (Still) Does not honour the playback segment of a Particle (you get the whole BD instead of just the corresponding bit).

I also like how you keep the chunks and reuse them / continue on from the last chunk when you restart playback.  Are any of these chunks held in the Gizmo Cache or are they immediately discarded?

Thanks
Nathan

[Hendrik]

Seeking and starting can be a bit slower then before because it needs to finish encoding the first chunk before Gizmo can start playing. Thats just inherent to HLS and can't really be fixed with the way it does live encoding. The way streaming is handled in MC, old chunks are not recycled even if you go back, thats just not in the architecture.
Otherwise, Gizmo itself really doesn't do much itself, it just tells the MediaPlayer component to open the URL. So any caching or whatnot is done by an Android component, and not controlled by Gizmo.

Please don't (ab)use this change to report issues that also apply to the old streaming. We will get to them, but please keep this to HLS specific things.

[jmone]

Please don't (ab)use this change to report issues that also apply to the old streaming. We will get to them, but please keep this to HLS specific things.

Give us a break, it is all part of the testing to go back and see what (if anything) changes with the old bugs.  I just run though my test files and report back.  It is not like we know what parts of the code gets updated where in MC and what may have been resolved, or impacted.

[Hendrik]

Its just a new way to encode the data, the way its otherwise handled isn't impacted by this - if anything else changes, its not intended. Once this is all done, i'll definitely look into other aspects of video serving, just be a little more patient until then.

PS:
I just fixed a bug in HLS that caused video to sometimes be a bit glitchy on one of my test phones. Not sure why only on one and not the other, considering they are both Nexus phones (4 and 5), but its fixed!

[jmone]

I really was not nagging (...this time    ).  

Excellent! - I also saw video breakup on one of my phones too (Nexus 7, fine on LG G2) but I figured that it must have been WiFi issue as when I checked the chunks on the Server they were fine.

Do you see the seek = crash about 80% of the time?

[Hendrik]

I tried seeking quite a lot since on the MC side its a bit tricky to handle, and never really had it crash.
Might try more tomorrow.

PS:
Nexus 7 is not a phone!

[jmone]

True!

My Gizmo seeking = Crashes Gizmo is really repeatable, is there any pattern or testing you want me to do?  Or logs (from the Andriod side I guess but I have no idea what to collect).  Also I just got a MC crash as well "C++ Runtime Library - Runtime Error" in Media Centre 19.exe "this application has request the Runtime to terminate it in an unusual way".

[jmone]

Attached is the log from MC Crashing - the only thing I can see is:

Code: [Select]

4406984: 8032: Playback: CDShowFilterGraph::Pause: Start
4406984: 8032: Playback: CDShowFilterGraph::Pause: Pausing graph. hr=x0
4406984: 8032: Playback: CDShowFilterGraph::Pause: Finish (0 ms)
4406984: 8032: Playback: CDShowFilterGraphNotifyWindow::OnDXEvent: Start
4406984: 8032: Playback: CDShowFilterGraphNotifyWindow::OnDXEvent: Event: 14 (0x0e), 0, 0.  Callback 0xb923e10
4406984: 8032: Playback: CDShowFilterGraphNotifyWindow::OnDXEvent: Unhandled DX event: 0x0e
4406984: 8032: Playback: CDShowFilterGraphNotifyWindow::OnDXEvent: Finish (0 ms)

[mwillems]

Please don't (ab)use this change to report issues that also apply to the old streaming. We will get to them, but please keep this to HLS specific things.

Sorry if either of my reports fall into that category; video playback never worked on my device before so I don't have a standard for comparison about what used to work and what didn't 

[Hendrik]

Also I just got a MC crash as well "C++ Runtime Library - Runtime Error" in Media Centre 19.exe "this application has request the Runtime to terminate it in an unusual way".

Did this also happen when you were seeking a lot?
One thing I know is that every encoder instance takes quite a bit of memory, depending on quality level. In High its like 400mb per encoder, and when you seek a new encoder gets built, while the old one doesn't get destroyed immediately, but only around 10-20 seconds later.

So if you seek really a lot in quick succession, it might be possible to get into memory trouble, but due to how slow seeking is, I would think it wouldn't be possible to reach this point. Unless you also stream to several devices at the same time at high quality.

Anyhow there is nothing in the log, and sadly also no crash dump, so it doesn't really tell me anything.

PS:
Gizmo still not crashy here.

[jmone]

Thanks I'll test more later, oddly watching content at present!

[jmone]

Used High Quality for settings for Audio and Video
- Did multiple quick seeks.  CPU Can hit 99% but no crashes of MC (so a 1 off with some luck!)

Testing on the LG G2 (stock but rooted 4.2.2) - does not work with the old method
- Seemed more stable in that Gizmo did not crash once but I had multiple instances where post a seek it would drop back to the Gismo IF instead of playing from the new point
- Post a seek that works you (sometimes but not always) get an OSD saying "loading" that flashes quickly on and off then after a bit playback starts from the new seek point
- Post a seek that does not work it immediately goes back to Gizmo (or Andriod) with no OSD msg at all.


Testing on a Nexus 7 (custom kernal, rooted, 4.4.2)
- No probs at all
- Post a seek you get an OSD saying "preparing" that stays till the video starts playing

Is the OSD "preparing" vs "loading" a Gizmo or Player thing?

Saw the video break up as discussed

Also it is sometimes hard to seek back to the beginning.  You can try to seek back but playback starts from later on. Sometimes you get all the way back.

[jmone]

Mmm  - not seen this before and may be unrelated but, while typing the above I had my Nexus 7 freeze and become unresponsive.  After holding down the Power button I got an Andriod OS msg "Process com.andriod.systemui isn't responding.  Do you want to close it?".  I "think" it was with the video paused as I did not notice what the tablet was doing.

[jmone]

Regardless of the above, I'm very pleased with the new system for Video Streaming as it basically works.... and on all Driods!  It's not as if we all hammer seeking anyway.

[Hendrik]

Also it is sometimes hard to seek back to the beginning.  You can try to seek back but playback starts from later on. Sometimes you get all the way back.

Thats the seekbar being a bit complicated and your fingers being too fat.  
You can actually push down on the seekbar and hold, and then drag the seek knob, if you then drag it back all the way to the start, it seems more reliable to get to exactly zero.

Might also be a small bug in there somewhere.

[jmone]

  Used a small finger this time and still can not get it all the way back.  It also seems the more you have seeked forward the less you can then seek back (if that makes sense).

[InflatableMouse]

Gizmo crashes on my nexus 5, sometimes after 10-30 seconds, sometimes after few minutes of playback. But it always crashes.

When I came home back on wifi Gizmo had trouble communicating to the server. I used Mode to select the server again and it reconnected but choosing the video I was playing gave the same error.

After I played something else (coincidence?) it suddenly played the video again, but still crashed after a short while.

[glynor]

It's not as if we all hammer seeking anyway.

I can't speak to or help with Android, sorry.  Not right now anyway.  I'll ask at work if we have any devices I can play with.

But, one thing...

I do actually hammer on the seeking in AirVideo currently on my iOS devices, to skip commercials.  It is flaky there too, but works most of the time.  This style (re-starting the encoding) might be too low performance to work well in this kind of 30-second-skip-ahead/10-second-back configuration (actually, AirVideo is 30-ahead/30-back which is annoying).

I basically only ever use the slider to seek when the auto-resume function fails, which it often does on AirVideo and I don't know why, or when I switch back and forth between playing a particular video in MC and my iPad.

Not sure if you already have or are planning to implementing any kind of 30-ahead/10-back functionality, but I'd really prefer it for ad skipping.  It sounds like it might be difficult with this architecture (or maybe it is already done).  But, if not...

Perhaps if you buffer enough video and hold it?  When the user requests a particular seek point, you could actually always seek the encoder 20-seconds-or-so of play time prior to that and buffer up a a bit of the file before playing.  Assuming the connection speed was fast enough (and the device had enough RAM, I suppose), you could probably buffer at least a few minutes or so "around" the playhead, and allow the user to seek within that margin without re-starting the encoding.

That would improve reliability of playback, I think, and provide some amount of "fast seeking" of the type I typically use the most.  Since, I assume, this would auto-resume properly using the Library data, that would be almost all of my need to seek around files, and I think it could be a very good user experience in practice, even with the limitation of re-starting the encoding.

[glynor]

When the user requests a particular seek point, you could actually always seek the encoder 20-seconds-or-so of play time prior to that and buffer up a a bit of the file before playing.

To be clear, I'm suggesting you do this server-side.  When a client asks for a seek, you actually start re-encoding some set number of "slices" back from that point (at least 20 seconds play time, for two "skip backs" would be ideal, I'd think), and then the client knows (or is told) to keep those pieces and start playing on slice #3 for their section.

Of course, I have no idea if you'd have this much flexibility on Android.  Perhaps that kind of seeking is what is broken largely.  I'm reasonably sure it would work well on iOS though.

[Hendrik]

Thats not going to work for numerous reasons. Android doesn't offer that kind of control (in fact, HLS itself doesn't specify any control whatsoever for Live playlists), and it would make seeks even slower, encoding 30 seconds or even 2 minutes before playback starts can actually take up to that time if your server can just about do real-time, thats not even close to acceptable.

Like I mentioned earlier, we have absolutely zero control about the actual playback, because it uses the Android MediaPlayer component. All we can do is give it a URL to play. If this URL starts 20 seconds earlier, then it'll also play 20 seconds earlier.

Gizmo will not be able to offer such seeking responsiveness when it needs to re-encode (which right now it always needs to).

Right now the MC architecture doesn't even allow re-using the already created segments if you seek backwards, or allow seeking into the around ~30 seconds it encodes into the future. Any seeks will always open a new encoder, because thats how the architecture is setup, and re-factoring this to try to recycle the content is not going to be something easy or soon, especially because it only fixes a fraction of the issues, and it still needs to open a new encoder if say you seek into the far future.

[glynor]

Thats not going to work for numerous reasons.

Bummer.  I trust you, of course, on Android.

Thats not going to work for numerous reasons. Android doesn't offer that kind of control (in fact, HLS itself doesn't specify any control whatsoever for Live playlists), and it would make seeks even slower, encoding 30 seconds or even 2 minutes before playback starts can actually take up to that time if your server can just about do real-time, thats not even close to acceptable.

The spec does allow for re-using segments already encoded and downloading for backwards seeking with an event-type playlist.  This is the same exact thing as a Live playlist, but you can only append to the file (and not change what has already been streamed).  So, if the server keeps track and knows the seek requested is within the pre-encoded buffered area, it just adds to the playlist re-uses the old segments and then keeps going.

Such as if, the original index is:

Code: [Select]

#EXTM3U
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10.0,
http://media.example.com/segment1.ts

#EXTINF:10.0,
http://media.example.com/segment2.ts

#EXTINF:10.0,
http://media.example.com/segment3.ts

And then, if the client requests a seek within the back-buffer, you just go "backwards" with the M3U8...

Code: [Select]

#EXTM3U
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://media.example.com/segment1.ts

#EXTINF:10.0,
http://media.example.com/segment2.ts

#EXTINF:10.0,
http://media.example.com/segment3.ts

#EXTINF:10.0,
http://media.example.com/segment4.ts

#EXTINF:10.0,
http://media.example.com/segment2.ts

#EXTINF:10.0,
http://media.example.com/segment3.ts

#EXTINF:10.0,
http://media.example.com/segment4.ts

#EXTINF:10.0,
http://media.example.com/segment5.ts

#EXTINF:10.0,
http://media.example.com/segment6.ts

The client just keeps reading forward.  Now, of course, if you jump outside of the pre-encoded area (like to "segment zero" or "-4" in the above example), you'd have to shut it down and start over.  But for little seeks it could work.  There might be a lag with 10 second segments (if the player just started playing a particular segment), so you'd have to experiment.  I bet 2-3 second segments might be acceptable though.  How often would you seek right at the beginning of a segment?

Or, does it really only support Live-type playlists, instead of Event (which is the same system as Live but doesn't re-write any old files)?  How come?  An Android limitation in the client?  Or, is Android not using the M3U8 index at all and the URL is the file itself via HTTP?  Otherwise, it seems like mostly server-side smarts, if the client does what the spec calls for...  That's precisely the type of stream you need:
https://developer.apple.com/library/ios/technotes/tn2288/_index.html

I'm not sure what kind of settings you're using to encode, of course.  AirVideo basically throws quality to the wind and drives it as fast as it can, when live encoding.  I'm not sure, but I think I get 200-300% of real-time performance on my machine (a stock 3770 Ivy Bridge), so pre-buffering 20 seconds would probably be tolerable.  But, of course, if you're encoding a nicer quality output, then you wouldn't be able to get acceptable performance on that, for sure.

[glynor]

Apple uses Event-style playlists with all of their keynote broadcasts and whatnot, and our Wowza server at the office is set to do that for live streaming, so that you can always seek backwards (back to the beginning of when you started watching), just not forwards.

If you did it this way, they wouldn't be "real" events (the client couldn't seek back locally, and re-use already downloaded content), but since you have full control of the server-side capabilities (not that it wouldn't take work, mind you) I thought there was probably a way to "fake" it.  Assuming Android doesn't work with real event style playlists, so the client would handle reverse seeking and you'd never have to "go backwards", which seems to be the case.

But not if Android isn't using M3U8s at all, I suppose.

[Hendrik]

I don't know what the server would even need to do here. It just appends segments to the playlist. If a player wants to read old segments which are part of this playlist (ie. seek backwards), there is nothing really stopping it without telling the server a thing.
That is, if you never seeked forward.

Once you seek forward (outside of the area which was already encoded), the old segments don't exist anymore, since it creates a new encoding job which starts from the time you seeked to. You could of course let it play a bit, and then seek backwards again, as long as you don't cross the point you seeked to first.

The whole experience would be very inconsistent and I can already see the questions popping up why seeking sometimes is fast and sometimes slow.
Once you combine the whole idea with actual free seeking into the future, it gets all weird and mushy.

I suppose it might be worth trying, but its important to note that you can only seek back into an area which you've already watched, and seeking into the future counts as a fresh "starting to watch" all over again, as it complete resets anything the encoder has.
(That is assuming Android even supports seeking in such streams, which is a rather dangerous assumption)

[Hendrik]

Also important to note that seeking isn't much better in the old streaming implementation, and Gizmo has no plans to drop support for the old way, so the more HLS specific hacks I can avoid, the better.

[glynor]

That is, if you never seeked forward.

Right.  If you seek past where the encoder had gotten to, then it would have to, essentially do what it is doing now (stop everything, throw the buffers away, and send a new stream).  This would apply to both forward and back (back past the point where you "started" watching, essentially, or forward past where the encoder had "gotten to").

But if your computer is fast enough to "get ahead" of "live" by a substantial margin, eventually it would finish the encoding and you could seek ahead and back (to the point of origin) without re-encoding anything, right?  The server would have to map the "internal" requests for a particular timecode, into a particular segment.  Seeking would be a little sloppy (segment-sized increments), but that's fine on a mobile device with fat-fingers anyway, right?

But, I'm talking out of my rear-end here a bit.  Sorry.  I've dealt with the server admin side of this and how FlowPlayer and jwplayer react, but that's it, and we've largely ignored Android (some of them work okay, though, I think).

Also important to note that seeking isn't much better in the old streaming implementation, and Gizmo has no plans to drop support for the old way, so the more HLS specific hacks I can avoid, the better.

Fair enough.  Just thinking out loud mostly.

(Well, and I'd like to be able to skip commercials.) 

[Hendrik]

Fun fact: if you don't keep requesting segments close to the "live" position, it won't encode them, so that the CPU isn't unnecessarily pegged, to better support streaming to multiple clients.
So if you watch a show half through, and then seek back the beginning, it will not encode the second half until you get there again.

Additionally, I have no clue if I could even get the info out of the Android MediaPlayer how much content ahead is available in the playlist, to even attempt a HLS seek over a MC-seek.

Assuming you actually have a full playlist encoded, then the server doesn't have to do anything anymore. It can just serve out the existing segments, and based on the playlist the player can decide on its own which segments it wants for a particular time.
However, its unlikely you will ever have the full file encoded, unless you actually watched it completely.

So without completely breaking MCs encoding server, all you could do is seek backwards within what you already watched. Not sure that helps your commercial skipping much. It would allow you to watch the commercials again, isn't that also something?

Maybe in the long run its worth considering to re-design how seeking works.
The problem is that seeking in the source files can be very inaccurate, so I can't encode the first 5 minutes, then encode minutes 10-15, and later come  back and encode the missing minutes 5-10 - they wouldn't stitch together perfectly.

In the short to mid-term, I would rather focus resources on other parts of the streaming chain though. So many things to do!

[Hendrik]

I posted a new Gizmo version which fixes a few of the issues, some more changes are in the next MC build which is also coming soon.

[jmone]

Tested on the LG G2 (the one showing most issues) and can confirm as fixed:
- Seek back to Start
- Corrupted playback

I still get playback dropping back to the GUI post a seek about half the time.  Apart from sending you my phone, is there any detail I can collect and provide that helps?

Thanks
Nathan

[Hendrik]

From what I can tell, if that still happens now then its Android refusing to play the URL for whatever reason.
Does it at least happen less frequently now?

I managed to reproduce it occasionally on my tablet, but after the changes I made it was fixed.

I wonder if completely destroying the MediaPlayer object and re-building it has any negative side-effects, or if thats something that could help.
Might post an "unofficial" test version here tomorrow with that changed.

[jmone]

It does seem to be client side as post a seek (that fails straight back to the GUI), the new segments are being built on the Server Side.  Unfortunately it is not consistent.  I my first test it failed the on the first 3 attempt to seek, then on the next test it worked find for say half a dozen before failing.  Happy to test a various revisions.

[glynor]

Fun fact: if you don't keep requesting segments close to the "live" position, it won't encode them, so that the CPU isn't unnecessarily pegged, to better support streaming to multiple clients.
So if you watch a show half through, and then seek back the beginning, it will not encode the second half until you get there again.

That makes sense, of course, but it does hurt "energy consumed performance" in the race to sleep department.  Although, the "startup overhead" for continuing the transcode is probably very limited.  And, I suppose if the client never does come back and request those unencoded segments, then you win, so that might be a wash.  And (of course) makes my idea impossible to implement.  I see...  Bummer.

[Hendrik]

Happy to test a various revisions.

This version creates a new MediaPlayer object everytime for video, give it a swing?
Only did brief testing on it, that it doesn't explode completely.

[jmone]

The version is much more robust on the Gizmo end.  I could seek and it worked 100% of the time on the LG G2 (will test later on the Nexus 7).

I did find two time there were issues at the server end with this version post a Seek:
1) It started making chunks that were only 600K in size and they have one video frame and audio.  It did about 10 of them before reverting to proper 4M chunks.  From Gizmo's end you just get the still frame of course

2) It created a new stream, and the first chunk but it did not fill it (stayed at 0bytes).  After a while the G2 when back to Gizmo.

Apart from those two oddities, all pretty good.
Thanks
Nathan

[AndrewFG]

But if your computer is fast enough to "get ahead" of "live" by a substantial margin, eventually it would finish the encoding and you could seek ahead and back (to the point of origin) without re-encoding anything, right?  The server would have to map the "internal" requests for a particular timecode, into a particular segment.  Seeking would be a little sloppy (segment-sized increments), but that's fine on a mobile device with fat-fingers anyway, right?

Techno warning on the following...

FWIW this is what I do in Whitebear. There are basically two types of seek destinations, namely 1) those that are within the time range that the current running transcoder has already written to its local cache, and 2) those that are not. In case 1) seeks my server just satisfies the request from cache, and I let the current running transcoder continue unmolested. Whereas in case 2) seeks my server has to start a new transcoder that starts at the given time offset. In case 2) I always let the original first started transcoder run through to the end of the media, so that the local cache always contains one clean transcoded instance of the full stream from start to finish. But if a subsequent case 2) seek request interrupts an already running case 2) seek session, then I kill that transcoder and discard its cache...

[connersw]

Thanks again Hendrik for all your work on Gizmo. 

Quick question: If your device supports both the old playback and HTTP Live Streaming, is there any advantage to one over the other?  It seems that the quality settings are the same.  Is one less intensive on the server CPU?  Easier to seek?  (I got lost in the discussion back and forth w/ Glynor on what is implemented vs what is suggested vs what is possible).

[Hendrik]

The old way may seek slightly quicker right now (but maybe not for ever), but in general there is no big difference.