12 replies to this topic

[malakudi]

I am thinking to try implement support for some V4L2 devices that output TS (like Hauppauge HD PVR or Hauppauge WinTV PVR USB2) inside enigma2. Boxes with 3.x kernels might already support such devices, so what needs to be done is to support channel definitions that use /dev/videoX TS source inside user bouquets. Does this interest anyone else than me?

You could then use such devices to control an external STB through your enigma2 box and display them like standard enigma2 services in bouquet list.
Hauppauge HD PVR features H.264 hardware encoder, older Hauppauge WinTV PVR USB2 features MPEG2 hardware encoder.

[Erik Slagter]

It's not enterily clear to me what you mean, please explain?

[malakudi]

Hauppauge HD PVR and Hauppauge PVR USB2 are USB external video capture cards with hardware video/audio encoder, delivering TS (transport stream) via /dev/videoX V4L2 interface. Drivers exist for Linux for both of them. There is a sysfs interface for both of them for tuning capture details (bitrate etc), I will program an E2 plugin for that. Both have IR transmitters, also supported by Linux. So, you could connect an external STB box (from a content provider with secure sillicon protection for example) and control it via E2 box, creating channel list that when selected will send the IR commands for the STB box to change channel and playback source TS content from /dev/videoN. It could also be used as recording service etc.

I am already using such setup with HTPC and MythTV, I will try to implement it in E2.

[Erik Slagter]

Ah I see now. So you're going to decode, encode and then decode again Because of DRM

I have no use for it myself, but I think the idea is interesting.

[MiLo]

Sounds interesting. This allows one to "route" analog video through the box, and record it and so on. Nice for transferring your old VHS tapes to the dreambox's harddisk I guess.

[Erik Slagter]

On a side note, I have a stack of HD recordings that need to be cut and re-encoded. Now I do that using libx264 on my quadcore cpu (slightly overclocked...), for 1080i recordings it can convert in about 0.25-0.50 "real time" (converting an hour of material takes 2-4 hours). This is with maximum efficiency settings.

I always wonder whether a pure hardware "solution" might be better at this. To start with, does this device also take digital input, like yuv4mpeg frames? AFACS it only takes analog input, which is a shame imho.

My DSLR and video camera also record in h264, but the resulting files are quite disappointing in efficiency. If the resulting files are re-encoded using libx264, using same visual quality, the size drops to about 25-10%. So I guess hardware "solutions" are not that favourable after all

Edited by Erik Slagter, 6 March 2012 - 12:16.

[MiLo]

Battery operated encoders will probably have been optimized for low power consumption rather than compression ratio. There's a fair chance that a "normal" powered device does a better job as it does not have to care about a Watt more. But that's just guessing.

As for your encoder, it might help to buy a modern "budget" video card. With appropriate software and drivers, the newer models can also assist in encoding H264 video in addition to decoding. So they claim. No personal experience with that, I just use the card for gaming.

[Erik Slagter]

As for your encoder, it might help to buy a modern "budget" video card. With appropriate software and drivers, the newer models can also assist in encoding H264 video in addition to decoding. So they claim. No personal experience with that, I just use the card for gaming.

You will need microsoft windows for proper support though (trust me, been there...).

Also Intel itself has no real plans to support the encoder capabilities in Ivy Bridge / Sandy Bridge cpu's in Linux. Bastards. Accelerated video decoding does work more or less, but you have to jump through a lot of hoops to get it actually working, it's certainly NOT out of the box.

So I guess I will have to stick to libx264 for the next few years (which does an excellent job, btw).

Edited by Erik Slagter, 6 March 2012 - 13:19.

[MiLo]

The decoder for my ATI card works fine in Ubuntu, installing the (closed source) driver was quite easy for as far as installing a driver in Linux is ever easy...

Having programmed for both platforms, I can understand why they don't want to invest in proper Linux support...

[Erik Slagter]

The decoder for my ATI card works fine in Ubuntu, installing the (closed source) driver was quite easy for as far as installing a driver in Linux is ever easy...

Closed source drivers are out of the question when you're using (like me) self-compiled kernels.

Having programmed for both platforms, I can understand why they don't want to invest in proper Linux support...

????

Anyway, they do not even need to produce anything, they only need to disclose the data!

Edited by Erik Slagter, 6 March 2012 - 14:41.

[pieterg]

Interesting, and as it's 'just' TS, should not be too hard to connect the things together.
Are you thinking in the line of an 'usbtunerhelper', which does rougly the same, pump external TS into a vtuner device, or are you thinking about a 'servicedvb' derivate in e2 itself, which pumps the data to a dvr device?

in e2, with the dvr device, would be the simples aproach to start with I guess, but with vtuner you might even be able to integrate the ir, and make the external stb behave like an actual virtual tuner, to e2.

[Gennar1]

The decoder for my ATI card works fine in Ubuntu, installing the (closed source) driver was quite easy for as far as installing a driver in Linux is ever easy...

Closed source drivers are out of the question when you're using (like me) self-compiled kernels.

Not necessarily true. I compile my own kernels on Ubuntu and the fgrlx closed-source driver works well (or at least as well as any Ati linux driver). If you generate the .deb packages from the self-compiled kernel, the fgrlx module is built automagically when you install the new kernel packages.

[Erik Slagter]

What you very probably do is compile the debian kernel yourself. What I do is get the latest mainline kernel from www.kernel.org and compile that, no distro-crap whatsoever. It almost never happens that a binary only driver is compatible with latest mainline kernel (like 3.2 at the moment).

I have tried to install the nvidia binary only driver on my laptop and failed miserably.

Edited by Erik Slagter, 7 March 2012 - 13:43.