MPEG2 Support in Android MiniClient

[stuckless]

You may be aware that the Android MiniClient has 2 media players... ExoPlayer (google) and IJKPlayer (ffplay based).

I have confirmation that IJKPlayer does not support hardware decoding of mpeg2 video, even if the device supports it.

It is possible that IJKPlayer could support hardware decoding of MPEG2 video... but it would take some work, and preferably work from someone that knows C code and understand mpeg handling. You can see in this file, is where IJKPlayer is conditionally handling H264 and HEVC. When I get time, I'll try to see what I can do here... It looks like he's just delegating to the android MediaCodec api, but there could be more going on.

I'm still waiting to hear if ExoPlayer supports MPEG2 video, since I have 2 MPEG2 videos and neither of them play on my NVidia Shield TV.

[dinki]

I haven't tried the latest beta, but do you have logic built in that can force transcoding for unsupported stream types? From my experience, and you've confirmed it in another thread, MPEG2 streams at 1080i play fine but 720p do not. Is there a way you can force 720p MPEG2 be transcoding on the server and pass 1080i as is? If not, can you force transcoding of all MPEG2 encoded files? This could provide playback, albeit at a cost, while MPEG2 support is being worked on.

Thanks again.

[nyplayer]

The ExoPlayer plays fine on my Nexus Player it plays both 1080I and 720P perfectly no pixilation at all. LiveTv plays great. This is using OPenDCT to create the files. So it appears it is the way SageTV muxes OTA channels those I cannot View.... But anything created by OpenDCT plays fine with no glitches.

So it appears that mpeg2 files created by sagetv muxing is a problem.

Great job by the way as I can watch crystal clear TV from my Hdhomerun Cable tuner and OpenDCt. I am sure that anyone that is using OpenDCT can use the Android Sagetv app.

[stuckless]

Originally Posted by dinki

I haven't tried the latest beta, but do you have logic built in that can force transcoding for unsupported stream types? From my experience, and you've confirmed it in another thread, MPEG2 streams at 1080i play fine but 720p do not. Is there a way you can force 720p MPEG2 be transcoding on the server and pass 1080i as is? If not, can you force transcoding of all MPEG2 encoded files? This could provide playback, albeit at a cost, while MPEG2 support is being worked on.

I suspect the issues with 720p MPEG2 is that the software decoder can't keep up. But, yeah, I still need to dynamically tell sagetv which containers and codecs are supported. I've started the work on this, which is why I now show the supported hardware decoders in the preferences. I now need to update the client connection to pass ONLY the formats that we can play. It's not hard, but not not super easy either, since I need to read the hardware codec list and convert those names into something that sagetv can understand.

Originally Posted by nyplayer

The ExoPlayer plays fine on my Nexus Player it plays both 1080I and 720P perfectly no pixilation at all. LiveTv plays great. This is using OPenDCT to create the files. So it appears it is the way SageTV muxes OTA channels those I cannot View.... But anything created by OpenDCT plays fine with no glitches.

So it appears that mpeg2 files created by sagetv muxing is a problem.

Great job by the way as I can watch crystal clear TV from my Hdhomerun Cable tuner and OpenDCt. I am sure that anyone that is using OpenDCT can use the Android Sagetv app.

That's awesome news.

[nyplayer]

Yep recorded TV and LiveTV using OpenDCT Definitely works ... I am going to test some OTA recordings and remux them to TS files and see if they work ... Hopefully before I start drinking Champagne. Now I can watch the college playoffs on my nexus player.

[nyplayer]

Sean,

Here are my findings ExoPlayer does hardware decoding with files created by OpenDCT which uses ffmpeg to remux as they are being written.

Anything that SageTV creates such as OTA etc... will not play in ExoPlayer .. Sage muxing to mpg is quite old. Also if I set to create TS and not mpg files they still do no play. So SageTV either needs to be updated or any OTA recordings will have to be remuxed.


I tested the remuxing using mcebuddy on mpg's created by SageTv and they play just fine both 720P and 1080I with hardware acceleration.

So trying to get Exoplayer to play files created by SageTV just will not happen until SageTV muxing is fixed.

[jm9843]

My quick impressions with ExoPlayer enabled on the Shield Android TV:

720p/1080i (MPEG2-TS) from OpenDCT/CableCard - video playback is great, looking noticeably better than IJKPlayer's software decoding from previous builds. I'm assuming this can be attributed to hardware decode & deinterlacing of the Shield.

But I'm not getting any sound (AC3 5.1). I'm thinking that this may have something to do with running the Shield directly to the TV such that something is preventing the audio track from simply being passed-through.

Is that something that would get logged by the MiniClient if 'log to file' option is enabled?

[stuckless]

Originally Posted by jm9843

My quick impressions with ExoPlayer enabled on the Shield Android TV:

720p/1080i (MPEG2-TS) from OpenDCT/CableCard - video playback is great, looking noticeably better than IJKPlayer's software decoding from previous builds. I'm assuming this can be attributed to hardware decode & deinterlacing of the Shield.

But I'm not getting any sound (AC3 5.1). I'm thinking that this may have something to do with running the Shield directly to the TV such that something is preventing the audio track from simply being passed-through.

Is that something that would get logged by the MiniClient if 'log to file' option is enabled?

I'm not sure about this. I have no idea what ExoPlayer does for audio pass-through, or even it supports it. I could ask a question to the Exo devs, but they are not exactly a forthcoming bunch. I have 2 outstanding questions from a couple weeks back. It's one of the reasons I really like IJKPlayer... The main dev may not be willing to make a change I need (or want), etc, but at least he'll actually talk to you

I have a feeling for ExoPlayer, it will be what it is... and over time as Google updates it, it may fix things that we want, but I have zero optimism that they'll actually help in any way.

[jm9843]

Originally Posted by stuckless

I have no idea what ExoPlayer does for audio pass-through, or even it supports it.

ExoPlayer does support audio pass-through, even the lossless formats (DTS-MA/TrueHD) in Marshmallow which Nvidia back-ported to Lollipop for the Shield. I'm hoping to test with a receiver soon to see if my suspicions are correct.

But staying on topic: MPEG2 is looking dramatically improved for the files produced by PrimeNetEncoder/OpenDCT from CableCard.

[nyplayer]

Originally Posted by jm9843

ExoPlayer does support audio pass-through, even the lossless formats (DTS-MA/TrueHD) in Marshmallow which Nvidia back-ported to Lollipop for the Shield. I'm hoping to test with a receiver soon to see if my suspicions are correct.

But staying on topic: MPEG2 is looking dramatically improved for the files produced by PrimeNetEncoder/OpenDCT from CableCard.

The problem is that seeking does not work but the Video plays great.

[cncb]

Originally Posted by nyplayer

The problem is that seeking does not work but the Video plays great.

Same results here with MPEG2 .ts files recorded in NextPVR. I have tried both "Dynamic" and "Pull" and I can't jump around/seek in the recording.

Regarding audio passthrough, using ExoPlayer in the miniclient I am able to get AC3 5.1 when playing back these .ts files. Also, I am able to get DTS playback (core DTS of DTS-HD) in MKV files I have tried.

[stuckless]

Originally Posted by nyplayer

The problem is that seeking does not work but the Video plays great.

Originally Posted by cncb

Same results here with MPEG2 .ts files recorded in NextPVR. I have tried both "Dynamic" and "Pull" and I can't jump around/seek in the recording.

Regarding audio passthrough, using ExoPlayer in the miniclient I am able to get AC3 5.1 when playing back these .ts files. Also, I am able to get DTS playback (core DTS of DTS-HD) in MKV files I have tried.

Yeah, in PULL mode, for ExoPlayer, you will never be able to Seek in TS files. They are adamant about not polluting the playing with non-standard stuff, and TS files are not seekable, so they will not allow it in the player.

In PUSH mode, the seeking happens on the server side, which is great, but, there is an issue with clearing the video buffer, and, maintaining the time code. This issue exists in both players, but in ExoPlayer, you can probably seek around, since the internal player code will approximate the seek requests (and sometimes do multiple requests to get the correct time). I think in the latest build, if you seek in push mode, it will seek, once, but then the time code gets reset back to 0, and then if you try to seek again, it will seek from 0.

[Gustovier]

Originally Posted by stuckless

Yeah, in PULL mode, for ExoPlayer, you will never be able to Seek in TS files. They are adamant about not polluting the playing with non-standard stuff, and TS files are not seekable, so they will not allow it in the player.

In PUSH mode, the seeking happens on the server side, which is great, but, there is an issue with clearing the video buffer, and, maintaining the time code. This issue exists in both players, but in ExoPlayer, you can probably seek around, since the internal player code will approximate the seek requests (and sometimes do multiple requests to get the correct time). I think in the latest build, if you seek in push mode, it will seek, once, but then the time code gets reset back to 0, and then if you try to seek again, it will seek from 0.

The buffer problem. That can be resolved on the client side or does work have to be done server side? I wonder if we can have sage start recording the mpeg2 (or h264 if your cable company has started to switch) to mkv (or MP4?) container instead since I think those containers support indexing (this is an assumption btw)

[stuckless]

Originally Posted by Gustovier

The buffer problem. That can be resolved on the client side or does work have to be done server side? I wonder if we can have sage start recording the mpeg2 (or h264 if your cable company has started to switch) to mkv (or MP4?) container instead since I think those containers support indexing (this is an assumption btw)

My statement was a little confusing, after a re-read, mainly because I mixed a "pull" issue with the "push" statement that I started.

In PUSH mode, the player (ie, the Android MiniClient), just receives a bunch data that is sent from the server to the player (ie pushed). When a user seeks, sagetv sends a FLUSH command to the client, and then immediately starts sending new data. The Client needs to tell the player to clear its video buffer, and then start processing the new data. The "flow" of this is completely implemented in the Android MiniClient. But, there is a problem that, even if I completely flush the video buffer, the player, resets it's timecode, and does not null the timecode from the stream. The net effect to this, is that on a seek, the player will actually seek, once, but then the time code will be set to 0. This means that while the player is playing the new position, it "thinks" it is starting back to 0. If you seek again, it will no seek from 0. If you resume, the video will resume at the correct location, but the time code will be 0. In these cases, this is entirely a player issue, in that the player does read the timecode from the ts stream, but it maintains it's own clock and doesn't update it with the timecode from the ts stream.

Because TS files are not seekable, normally, they are ideal candidates for SageTV's PUSH technology. ie, SageTV manages the seeking so that the client doesn't need to. It's also an idea technology for LiveTV, since the player never gets an end of file, since, the player is not reading a fixed stream as it does with PULL modes.

SageTV's PUSH technology pre-dates other protocols, such as HLS, that also solve this same issue by segmenting TS files and using a separate "index" file. I've worked with HLS and in all fairness to SageTV, the PUSH protocol that Jeff created, is far simpler to implement and work with than the HLS standard. (But, HLS is a standard, for the most part, so many player actively support it)

So, PUSH exists to solve 2 primary problems.
1. Some files, such as TS files, are not seekable without implementing player hacks.
2. LiveTV is hard because you are always hitting the end of stream (EOS), and having a player play a LiveTV stream is hard when you keep hitting EOS, without putting in lots of hacks in the player to handle this.


SageTV's other protocol, PULL, is a very simple protocol and is analogous to virtualizing a Random Access File, and this mode is ideal for all other file types, and especially file types that are "complete" (ie, not LiveTV), and file where you need to jump around. For example, when you play a MP4 file or MKV, the player might read a few bytes from the start of the file, and then immediately jump to the end of the file, and read some other metadata, and then jump back to the beginning, and continue playing. SageTV's PULL method supports this type of random access to a stream.

So, with all that out of the way, I don't think that just recording to a different format is going to solve the problem. If you record to mp4 or mkv directly, you'll likely have to have SageTV PUSH that data (whereas today, it would PULL it). PUSHing the mp4/mkv is not an issue, but, if the player needs to "jump around" (as it does today), then it can't do that in PUSH mode.

I think a better solution, if we can't get PUSH to work, would be to resurrect SageTV's HLS server (yeah, it has a HLS server that's never used), and see about producing HLS stream for LiveTV and TS files in general.

[aklaro]

I just tried android-debug-0.02-BETA version. I don't know why but .TS (hd-pvr) videos and .MPG (atsc) videos don't play anymore on any of my tablets. They were playing very well on either my Nexus 7 (2013) Marshmallow, my Samsung TabPro 10.1 Kit-kat or my Samsung NotePro 12.1 Lollipop under android-debug-0.01.1-BETA version.

Thank you for your efforts to create this client.

[stuckless]

Originally Posted by aklaro

I just tried android-debug-0.02-BETA version. I don't know why but .TS (hd-pvr) videos and .MPG (atsc) videos don't play anymore on any of my tablets. They were playing very well on either my Nexus 7 (2013) Marshmallow, my Samsung TabPro 10.1 Kit-kat or my Samsung NotePro 12.1 Lollipop under android-debug-0.01.1-BETA version.

Thank you for your efforts to create this client.

Which player? Is ExoPlayer enabled in the preferences? Are you using PULL mode or Dynamic?

[stuckless]

There were quite a few changes between beta-1 and beta-2, but mainly around the key press handling. There are couple of other player changes as well, but I tested this on both my phone and the NVidia Shield TV, and I don't nothing anything unusual.

I've done a clean build and uplaoded a beta-0.2.1 to see if maybe the build was just bad.

[stuckless]

I just did a BETA-02.2 build because I did find something that would have affect ExoPlayer only... So changed that code. (This part I was able to verify was not working on Shield but does work now)

[aklaro]

Which player? Is ExoPlayer enabled in the preferences? Are you using PULL mode or Dynamic?

Just installed apk and tried. No change in the parameters. Exoplayer was not enabled.

[aklaro]

Just gave a it a new try on my Samsung NotePro 12.1 :

0.01.1-BETA installed : works
uninstalled 0.01.1, installed 0.02 : sage.PlaybackException
uninstalled 0.02, installed 0.02.2 : was kick out of the server connection
uninstalled 0.02.2, re-install 0.01.1 : works again

No changes to preferences : ExoPlayer not checked, Dynamic default.

Sorry. Maybe I did something wrong, but I cannot see where.