Android/AndroidTV Placeshifter client (Discussion)

[stuckless]

Originally Posted by Gustovier

Yup probably about time to set the indiegogo up.

Stuckless, also what was the issues you had with using exoplayer. I'm a little worried that with it being made by Google and other Devs (such as plex) contributing to it that it might support more features than the ijk player. Such as supporting native hardware decoding / frame rate switching / hardware deinterlace that some players have. For instance the plex devs not to long ago submitted support of trueHD sound to exoplayer. Looking at the github repo exoplayer it seems the devs are very active and respond pretty quickly to possible issues. It also supports some types of drm which might be helpful if dtcp-ip is ever added in so we can get premium channels from silicon dust prime tuners (of course this would require a lot of work , $$, and for the source to go closed)

I just want to make sure that the best player possible is chosen early upfront before a ton more work goes into it.

Ok, so, with ExoPlayer (and I don't doubt it's great), it has issues parsing the .ts files that I was sending it. ExoPlayer relies on MediaCodec for decoding the video, which is what ijkplayer uses as well. The difference is that ijkplayer uses ffmpeg to decode the containers and it delegates to ffplay to actually play the video on an Android Surface. ExoPlayer, appears to do all their own container parsing (they have a .mp4 and .ts parser) but the .ts parser did not work with the .ts files that I gave it.

I'm not opposed to using other players, and the code is architected in a way would supports that notion, which is why I could provide both ijkplayer and vlc players, and I had a exoplayer in there at once as well... the issue for me, is that when I modify the API, I have to update 3 players, which is tedious, which is why I'd like to focus on 1 player that works, and then possibly, add another player later, if time permits, or if there is something severely limiting in ijkplayer.

[Fuzzy]

So is the problem the container, or the decoding? Have you tried remuxing the problem file into a different container and see if the same stream plays better? Might makes sense to simply disable that container's capability in miniclient, and force the server to 'transcode' it to the different, supported, container. This would take some improvements on the server end as well, because I don't believe selective conversion is actually implemented fully - it may not do a stream copy in the current state.

[stuckless]

Originally Posted by Fuzzy

So is the problem the container, or the decoding? Have you tried remuxing the problem file into a different container and see if the same stream plays better? Might makes sense to simply disable that container's capability in miniclient, and force the server to 'transcode' it to the different, supported, container. This would take some improvements on the server end as well, because I don't believe selective conversion is actually implemented fully - it may not do a stream copy in the current state.

I am not a video developer... videos either play, or they don't Unless you are placesifting, you probably don't want videos to be transcoded on the fly, since if they are, then seeking will be potentially slow. For example right now, when you seek in a file it actually seeks 4-5 times (the player does this)... That means each of those seek requests would cause the server stop/start a transcode code.

I might take some time this weekend and add in exoplayer again... people can enable it, and if it works great, and if doesn't, then, not sure what we can do.

ijkplayer actually has an exoplayer wrapper, where I think it will use exoplayer instead of ffplay. Not sure how this works, and I've really looked at it, but I did see ExoPlayer parts in the source.

[nyplayer]

I agree I really do not want the Sever to transcode the files ... if I am using a lan connection. The only problem I have is with 720P recordings.

[Fuzzy]

Originally Posted by nyplayer

I agree I really do not want the Sever to transcode the files ... if I am using a lan connection. The only problem I have is with 720P recordings.

I did not mean for the server to actually transcode the files, but if the container is an issue for the end player, it would make sense to repackage it into a different container for transport.

[stuckless]

Originally Posted by Fuzzy

I did not mean for the server to actually transcode the files, but if the container is an issue for the end player, it would make sense to repackage it into a different container for transport.

I'll give ExoPlayer another shot. It was the first player that I used, and I ran in lots of issues. Next I tried VLC and then finally ijkPlayer. To be honest the underlying streaming code has changed a lot since I first started playing with this, so it wouldn't hurt to re-introduce Exo and see what happens.

Exo is more work to get setup... Whereas IJK and VLC are pretty much just give it a URL, with Exo, you need to actually configure it for which containers will support and register them, etc, so, it isn't quite a plug and play like VLC and IJK.

One of the reasons that I'm keen to re-try Exo is that IJK has a flush buffer issue that I can't seem to solve. I'm hoping that IF Exo works, I can sucessfully have it flush it's buffers during a seek.

[jm9843]

Originally Posted by stuckless

I'll give ExoPlayer another shot.

Having been the first one to suggest ExoPlayer, I hope it works out!

That said, those who need MPEG2 should tamper their expectations until someone submits a pull request for ExoPlayer issue #793. One of the maintainers of the project gives a pretty good explanation of what that work would entail here. Maybe someone from the SageTV community can step up?

[stuckless]

So, I took a couple of hours this morning to add in support for ExoPlayer (Google's homegrown media player framework). I better results than when I first tried, mainly because the streaming framework that I had to create is more stable/mature than when I started, but overall, the player is completely unusable.

TS Files (HD-PVR h264 encoded files 720p) won't play at all... The "TsExtractor" just bombs parsing the stream. (push or pull, doesn't matter).

MKV Files - I got video, but no audio...

MP4 Files - I got video and audio, files play fine.

At this point I don't intend on doing a release with this, because it's not usable, and I don't have the time (right now) to open tickets, troubleshooting, etc. It's quite easy to swap out players, but I don't see the point in even enabling this one, if it only plays one of the sample files that I'm using.

My understanding of ExoPlayer is that it is a player framework that people can use, if they need/want to extend the player and swap out components, etc. This is great if the person consuming it is a "video" developer, but, as I've said in the past, that's not me. I'm sure we can write a TS extractor that works with my sample HDPVR files... but I'm not doing that.

I think if a group of people are really keen on using ExoPlayer, then my suggestion would be to fork this project, then build out the player, and the submit a pull request. I do see value in having greater control over the lower level player... but it's not something that I can dedicate time to, when I know nothing about video playback from a development point of view.

[dinki]

I'll try not to sound too dumb with this as I know zero about mmost things, but are you using a video buffer ? I'm asking this due to what may be loss frames with the MPEG2 720p video issues I'm seeing. Perhaps adding this or even allowing a larger buffer might help with the drop frames?

Would it be possible to measure the network throughput somehow in the logs? I took a closer look at the 720p videos and they report that they are at 60 fps while the 1080i videos that play well are at 29.97 fps. Is it possible that this doubling of frames is causing the issues? Could the app still be starved for data even via a wired connection?

[stuckless]

Originally Posted by dinki

I'll try not to sound too dumb with this as I know zero about mmost things, but are you using a video buffer ? I'm asking this due to what may be loss frames with the MPEG2 720p video issues I'm seeing. Perhaps adding this or even allowing a larger buffer might help with the drop frames?

Would it be possible to measure the network throughput somehow in the logs? I took a closer look at the 720p videos and they report that they are at 60 fps while the 1080i videos that play well are at 29.97 fps. Is it possible that this doubling of frames is causing the issues? Could the app still be starved for data even via a wired connection?

The app does use a 16mb memory buffer (which on an android device is quite significant). The video process basically consists of a player thread that reads the buffer and a server thread that fills the buffer. For PUSH files (ie, .ts files) this is all true. For PULL files (mp4, mkv, etc) the process is slight different and there is a buffer, but, it doesn't work quite the same way.

PUSH and PULL are not terms that I would expect people to be familar with, and I think for troubleshooting these framedrop issues, I'll likely need to add some extra logging. For example, I can detect when frames are dropped, and potentially log it. I can also tell the player to NOT drop frames, but, not sure what the effects of that would be, since in most places it see people enabling that (and it's enabled in this app as well).

Unfortunately other than playing with exo player yesterday, I haven't had much time to play with this, this weekend

[dinki]

Ah great info. Thanks for sharing. Yes, it would be great to try and figure out what's really happening with certain recordings/streams. Additional logging options will hopefully help with this. Many thanks

[tmiranda]

Sean - Is the microphone button on the default nexus player remote mapped to anything? If it isn't, can it be? I was thinking that one way to make the miniclient more usable with the default nexus remote would be to display a "virtual" remote when the microphone buttonwas pressed. (It could be another button but they are at a premium and I'd hate to waste one on this.)

I am thinking you might attract more users if there was a way to navigate the UI without getting a new remote for the (cheap) nexus.

[stuckless]

Originally Posted by tmiranda

Sean - Is the microphone button on the default nexus player remote mapped to anything? If it isn't, can it be? I was thinking that one way to make the miniclient more usable with the default nexus remote would be to display a "virtual" remote when the microphone buttonwas pressed. (It could be another button but they are at a premium and I'd hate to waste one on this.)

I am thinking you might attract more users if there was a way to navigate the UI without getting a new remote for the (cheap) nexus.

I'm sure I can map the microphone button, but I don't have nexus remote, so it'll be hard for me to test it But, I think the idea could work. One the phone, I've been playing around with using a slide out drawer, but there is a problem with how it is rendered.. ie, it renders under the SageTV ui, which is odd. I think the idea could be extended to show an on-screen remote when running in TV mode. I'm working on a "remote" app which could be used here as well for an onscreen remote... hopefully it'll all come together

I'm also been working on the code to send all the standard keys to sagetv to so that external keyboards can work. There are few kinks, but it's almost done.

[stuckless]

This version fixes the long press on enter/options not bringing up the OPTIONS.
Adds external keyboard support (usb, bluetooth).

I was able to test the client as a placeshifter, and the entier UI is blank when placeshifting, so I'm still investigating why that is.

[dranockcir]

Originally Posted by stuckless

This version fixes the long press on enter/options not bringing up the OPTIONS.
Adds external keyboard support (usb, bluetooth).

I was able to test the client as a placeshifter, and the entier UI is blank when placeshifting, so I'm still investigating why that is.

Yep, can log in now. Although I can't see the UI I can navigate and get to Live TV which is Down Arrow once and then Enter. It seems to play although I don't get any audio or video. In the SageTVWeb Interface I can see that I am connected, what I am watching and that I am changing channels. In your Alpha 9 I did see the video and hear the audio.

[stuckless]

Originally Posted by dranockcir

Yep, can log in now. Although I can't see the UI I can navigate and get to Live TV which is Down Arrow once and then Enter. It seems to play although I don't get any audio or video. In the SageTVWeb Interface I can see that I am connected, what I am watching and that I am changing channels. In your Alpha 9 I did see the video and hear the audio.

I'll recheck, but I don't anything changed in terms of the player... This release was all about the keyboard handling.

[brewston]

Alpha10 broke video (live & recorded) playback for me too. I tried clearing cache but it made no difference. I uninstalled and installed Alpha8 and it's OK now

[stuckless]

Originally Posted by brewston

Alpha10 broke video (live & recorded) playback for me too. I tried clearing cache but it made no difference. I uninstalled and installed Alpha8 and it's OK now

I did some checking... I was making some changes to the project to the make player easier to rebuild, and I accidentally set the codec support to minimal I'll try to do another build tonight with the updated codecs.

[panteragstk]

Just tried .9 alpha and one thing that happened in .6 was that when I press play the nexus player will start playing Google music if I have anything paused. I also don't know how is how to right click or press ESC.

[stuckless]

ALPHA-10 accidentally contained a player build with limited codec support. This build restores the codec support.