Cross-platform full client ideas

[stanger89]

Sounds like it maintains video levels, which is correct for a TV, but often not desirable for a PC monitor.

[Taddeusz]

Originally Posted by stanger89

Sounds like it maintains video levels, which is correct for a TV, but often not desirable for a PC monitor.

AFAIK, computers only output full RGB. Not sure there's a way for a computer to output the restricted color gamuts of NTSC or ATSC.

[stanger89]

There's no difference to the signal between limited and full, it's all about how it's used/interpreted. And we're not talking gamut here (RGB xy coordinates), we're talking levels (what black and white are).

Video defines black at 16 and white at 235, PCs (Windows desktop, etc) set black to 0 and white to 255. The difference is just in how you calibrate it. Most displays (non-computer) have a setting to pick RGB Limted (16-235) or RGB Full (0-255). If all you're doing is video, ideally you calibrate to RGB Limited as that is how video is produced.

If you're using a PC monitor it's probably better to go RGB Full and set the decoders/renderer to expand video to RGB Full (I know madVR has that option, I think LAV decoders do as well).

If you've got some mixed system, it's more complicated.

[SageWizdom]

Originally Posted by Narflex

Modifying the placeshifter client to also have the same full DirectShow playback capabilities as the full client (when you're not transcoding placeshifted video) isn't all that hard to do actually. The reason we never did it was because it didn't seem like that problem needed to be solved...if you're on your LAN and want good Windows playback; then use the full client. If you're remote; then you likely need stuff transcoded due to bandwidth limitations...so use the Placeshifter (and video quality is already compromised due to transcoding, so not much point in going all out with the media player).

But if people really have an interest in making the Windows Placeshifter playback video in high quality on a LAN like the full client does...then go for it...I can provide all the advice you need to do it. The main thing missing is that when you change the decoder settings and such in the UI; those are done in the properties on the server...which the placeshifter client has no access to...but it likely wouldn't be that hard to include a mechanism that solves that problem (where the placeshifter client can query the server for config settings).

Do you think this would also work on a Mac? I'm assuming that the Mac is not using DirectShow, but some similar capability. This might scratch some OSX itches. I could also see this on other embedded systems where it might be easier to port the mini-client.

As a side question:
Out of curiosity what prevents us from updating the HD300 firmware? I know we can not recompile certain sources, but could we update the Sage-CDC.jar with the newest code and have it use the existing compiled .so library binaries?

[Narflex]

Originally Posted by SageWizdom

Do you think this would also work on a Mac? I'm assuming that the Mac is not using DirectShow, but some similar capability. This might scratch some OSX itches. I could also see this on other embedded systems where it might be easier to port the mini-client.

On Mac, the media players we had were for Live mode (i.e. live pass through on some capture cards), DVD playback (Mac had support for that) and then MPlayer handled the rest. So you wouldn't be gaining much on Mac at all because MPlayer would still do basically all of your media playback.

Originally Posted by SageWizdom

As a side question:
Out of curiosity what prevents us from updating the HD300 firmware? I know we can not recompile certain sources, but could we update the Sage-CDC.jar with the newest code and have it use the existing compiled .so library binaries?

You are correct; there is nothing stopping someone from updating the firmware with a new Sage-CDC.jar. The main problem is that the current GitHub codebase is not compatible with that environment. We actually had a fork of the SageTV codebase that was compiled for it...which went through a few iterations. Initially it removed all 'float' operations because there was no FPU on the HD200...then we got rid of that problem on the HD300; but the CVM (embedded JVM we used) doesn't have AWT libs and is also only Java 1.4 compliant. Later I did figure out a way around the AWT problem (it doesn't need to actually use AWT for anything; but it does need to resolve the classes...so I ended up making a set of classes that satisfied all these dependencies later which I could release if needed). But there's now a fair amount of 1.5 constructs in the code...so I don't think it can be compiled for 1.4 anymore (there are 2 different javac params for source level and compiled level; but unless they changed something, they always needed to be the same value in the past so you couldn't compile 1.5 code for 1.4 targets, even if the only incompatibility was the simplified for loops and templates and you didn't even use any 1.5 library calls).

And to update the JAR file you don't even need a new firmware...there's way to do it without that through the 'startupmods' script that it supports on the HD300 (it allows execution of scripts at startup from flash, so you can just mount a new JAR file over the existing one that way).

[stuckless]

Originally Posted by Narflex

On Mac, the media players we had were for Live mode (i.e. live pass through on some capture cards), DVD playback (Mac had support for that) and then MPlayer handled the rest. So you wouldn't be gaining much on Mac at all because MPlayer would still do basically all of your media playback.



You are correct; there is nothing stopping someone from updating the firmware with a new Sage-CDC.jar. The main problem is that the current GitHub codebase is not compatible with that environment. We actually had a fork of the SageTV codebase that was compiled for it...which went through a few iterations. Initially it removed all 'float' operations because there was no FPU on the HD200...then we got rid of that problem on the HD300; but the CVM (embedded JVM we used) doesn't have AWT libs and is also only Java 1.4 compliant. Later I did figure out a way around the AWT problem (it doesn't need to actually use AWT for anything; but it does need to resolve the classes...so I ended up making a set of classes that satisfied all these dependencies later which I could release if needed). But there's now a fair amount of 1.5 constructs in the code...so I don't think it can be compiled for 1.4 anymore (there are 2 different javac params for source level and compiled level; but unless they changed something, they always needed to be the same value in the past so you couldn't compile 1.5 code for 1.4 targets, even if the only incompatibility was the simplified for loops and templates and you didn't even use any 1.5 library calls).

And to update the JAR file you don't even need a new firmware...there's way to do it without that through the 'startupmods' script that it supports on the HD300 (it allows execution of scripts at startup from flash, so you can just mount a new JAR file over the existing one that way).

Is the HD300 ARM based? Oracle has Java 8 builds for ARM... do you think it would be possible to update the CVM to use standard Java 8 JVM, even on the HD300.

As we move forward in the code, I see no reason to keep the java version to 1.5. That would be incredibly limiting from a development point of view... Most developers are annoyed that Android only has limited support for Java 1.7 (that will change soon), so, I can't even imagine being forced to target 1.5 (I'm pretty sure Phoenix has 1.7 min requiremement). I wonder if tools like Retroweaver might be another way to go for this. (basically does bytecode manipulation to enable 1.5 compiled code to run on 1.4 jvm)

EDIT:
- Did the original source drop contain build files for rebuilding the Sage-CDC jar? I don't recall seeing that. Might be worth posting it, if not.

[Fuzzy]

Originally Posted by stuckless

Is the HD300 ARM based? Oracle has Java 8 builds for ARM... do you think it would be possible to update the CVM to use standard Java 8 JVM, even on the HD300.

As we move forward in the code, I see no reason to keep the java version to 1.5. That would be incredibly limiting from a development point of view... Most developers are annoyed that Android only has limited support for Java 1.7 (that will change soon), so, I can't even imagine being forced to target 1.5 (I'm pretty sure Phoenix has 1.7 min requiremement). I wonder if tools like Retroweaver might be another way to go for this. (basically does bytecode manipulation to enable 1.5 compiled code to run on 1.4 jvm)

EDIT:
- Did the original source drop contain build files for rebuilding the Sage-CDC jar? I don't recall seeing that. Might be worth posting it, if not.

What are you actually wanting to change on the HD300 though? I think it already plays back all the formats that the hardware can support, and it renders the UI as good as it can. I see no reason we'd have to touch the HD300's code at all at this point (especially since it is not being manufactured).

[stuckless]

Originally Posted by Fuzzy

What are you actually wanting to change on the HD300 though? I think it already plays back all the formats that the hardware can support, and it renders the UI as good as it can. I see no reason we'd have to touch the HD300's code at all at this point (especially since it is not being manufactured).

Personally, for me, nothing. But, that's not to say others won't want to upgrade the java layer, etc. For me, my efforts will be strictly Android... But I'd hate to see us stick with java 1.5 code requirement, just because of the HD300, which is why I asked about it's capabilities of running newer java versions.

[trk2]

Originally Posted by Fuzzy

What are you actually wanting to change on the HD300 though? I think it already plays back all the formats that the hardware can support, and it renders the UI as good as it can. I see no reason we'd have to touch the HD300's code at all at this point (especially since it is not being manufactured).

Forced subtitles on MKV files

[Narflex]

The HD300 is a MIPS platform...that's problematic for finding another JVM.

And I did not release the code for rebuilding the JAR on the HD300 because it would have been a whole other codebase for me to go through and cleanup and check to make sure it was all OK for redistribution...and the SageTV codebase we did release already took me months of work to prepare...so I'm not inclined to do it again without a really good reason.

I really don't see that much reason to update the JAR on the HD300 because that would really only matter for standalone mode; and basically everyone uses it as an extender...and in that mode that Java code is doing nothing on the HD300.

As for forced subs in MKVs...that can be fixed entirely on the server side and requires no changes to the HD300 firmware (as I commented in the bug that was created for it in GitHub).

[KryptoNyte]

Jeff, is the hardware/firmware on the HD300 capable of h.265? I see one or two cable companies moving to h.264, which it handles fine, but I wonder about upgrades to h.265. Maybe that's years off yet.

[Taddeusz]

Originally Posted by KryptoNyte

Jeff, is the hardware/firmware on the HD300 capable of h.265? I see one or two cable companies moving to h.264, which it handles fine, but I wonder about upgrades to h.265. Maybe that's years off yet.

The SOC that's in the HD300 was created way before H.265 ever existed. So no, it's not capable of H.265 decoding.

[SageWizdom]

Originally Posted by Narflex

And I did not release the code for rebuilding the JAR on the HD300 because it would have been a whole other codebase for me to go through and cleanup and check to make sure it was all OK for redistribution...and the SageTV codebase we did release already took me months of work to prepare...so I'm not inclined to do it again without a really good reason.

More just curiosity, I wasn't sure if it was any or partially the same build (or level of effort to take that build and put on another platform).

Originally Posted by Narflex

... basically everyone uses it as an extender...

Right. Good point.

[wayner]

I believe that SoC is a Sigma Designs SMP8654 which appears to have been released in 2008.

[Galaxysurfer]

not sure of the differences in code but maybe umplayer can help the cause? http://www.umplayer.com/ might be worth a checkout.

[Narflex]

The HD300 chipset does not support H.265 (and there's no hope of it ever since that chipset is outdated and Sigma would never update it to add that support).

[stuckless]

Originally Posted by Narflex

The HD300 chipset does not support H.265 (and there's no hope of it ever since that chipset is outdated and Sigma would never update it to add that support).

Here's a loaded question for you... If you were pick a hardware platform, today, to replace the HD300, what you would choose? and why?

[Narflex]

Originally Posted by stuckless

Here's a loaded question for you... If you were pick a hardware platform, today, to replace the HD300, what you would choose? and why?

I have no idea...I haven't looked into options in awhile (other people on Fiber handle chipset selection). The main drivers before (at SageTV) revolved around codec support and also finding an ODM who could provide us with a complete hardware product that had the capabilities we wanted regarding outputs and codec licensing. (and then also once we started using SigmaDesigns chipsets we wanted to keep using them)

[Fuzzy]

Originally Posted by stuckless

Here's a loaded question for you... If you were pick a hardware platform, today, to replace the HD300, what you would choose? and why?

Some already consumer available product - like a FireTV.. ;-)