BluRay on Linux thread - Page 2

I don't have anything to test with ATM, but BD+ is implemented in MakeMKV:


Source

People, does anyone knows or have tried DVDFab Passkey on wine? I have it installed on a win7 partition for testing and it looks good. I've rent a Bluray that was AACS17 and BD+ and it worked fine. I need it or AnyDVD HD running on Linux to be able to use my Sony Optiarc BC-5500S drive on Linux. Once my BD drive is OEM it can't decrypt the discs but if I have DVDFab Passkey or AnyDVD HD running in background and decrypting the disc I can play them fine on Win7.

I could install DVDFab Passkey on wine and after some struggle (to set the dvd drive) it can launch but it doesn't decrypt when there is a disc inserted. But it's the beginning... At least it could be installed on wine and I could get it running, playing around with settings etc, without errors...

Still no luck with streaming for me.. anyone gotten it to work?

I tried mplayer, smplayer, and VLC.

I can connect to the webserver.. but when I click on a ts file to stream it, it looks like its going to download the whole file before sending it to the player..

People, I'm looking for someone that is trying to get DVDFab Passkey running on Linux through Wine. I could get it installed and running with no error, but when I insert a disc it doesn't decrypt it.

^^^ or MakeMKV. It's native Linux and works great.

@zim: I've only tried streaming locally with smplayer, and that worked fine (it didn't try to load the whole file first).

can you use small words and describe your process?

I selected the track in makemkv and hit stream... it seemed to queue up and wait for something to attach

then in smplayer/mplayer/VLC I entered both flavors of URL ... ie. http://192.168.0.3:51000 and http://localhost:51000

Looking at the tutorials it looks like I should have added something like stream/title0.ts to the end of that URL.

Yep. http://www.avsforum.com/avs-vb/showt...8#post19040838

While the news is certainly good in general, it really has nothing to do with Linux, Linux doesn't use HDCP and that's a good thing, there is nothing to be gained for the user from using HDCP.

It won't make BD playback any easier for Linux, there is no need to enable HDCP in order to output HD video (which Linux already does) or HD audio.

It would have been more useful if the AACS master key (if such a thing exists, don't know enough about AACS) had been made public!

I don't know if such cards could be cheaply made, we are talking about capturing and handling a data stream which is multiple Gigabits per second (remember this is a full uncompressed HD video stream, plus the audio), this would require a lot of processing power.

Not to mention a LOT of HDD space. Every time I start to get interested in doing uncompressed HDMI capture, I start to question whether it is worth it to build a RAID array big enough and fast enough to handle uncompressed HD video (and audio). I captured uncompressed SD video years ago (S-video out from Dish Network box), and it was such a relief to go to HD (FusionHDTV capture card) where everything was captured in its "still compressed" form. Not to mention, these HDCP breaking devices will not be easy to come by (local electronics stores probably couldn't sell them), but at least if the master key is known, revocation would become a non-issue. Meaning, if you get one that works based on this new info, it should continue to work forever.

Why would such a proposed device be any different than an HD-PVR? This is just a "digital-hole" as opposed the the "analog-hole". But perhaps you mean 1080p since the HD-PVR is 720p/1080i or that some company would never be able to actually come out with a device using the hacked key.

Does anyone know how the HDFury actually works? It was always my backup plan when Big Media gets Congress/FCC to close the analog-hole. Just didn't want to spend money on HDFurys until I had too.

A HD-PVR records a compressed mpeg2 or h.264 stream (without any need for encoding or processing), while a 1080i hdmi stream would be 11GBytes a minute (1920 x 1080 x 30frames x 3byte x 60sec), almost 700GBytes an hour!
It would only work if the card contains a chip that encodes the raw stream as mpeg2 or h.264 in real-time, which would make it very expensive.

I am confused about this point. Given that a blu-ray has up to ~50 GB capacity, sends out 1080p and can contain a 2.5 hour movie, how does a 1080i HDMI stream end up requiring 700 GB/hr?

Actually the HD-PVR takes raw component video (YCrCb or YPrPb) and makes h.264 in real-time.

http://www.hauppauge.com/site/products/data_hdpvr.html

So it seems doable to me. Of course I could be confused - it's not an uncommon occurrence.

Because the stream that is sent across HDMI is the decompressed and decoded data not the compressed data that is on the BD. So for an H264 encoding at a fairly conservative compression ratio of 50:1, a full 50GB BD would generate about 2.5TB of traffic over the HDMI bus.

Thanks for the explanation. I guess I just didn't really how compressed BDs are.

I misunderstood you, when you said HD-PVR I took it as the generic term for HD personal video recorder standalone units or PC cards, i.e. those that record digital broadcast streams from satellite, cable or OTA directly onto a hard disk, I wasn't aware of this specific product from Hauppauge.

I guess the feasibility of a digital (hdmi input) version of the Hauppauge HD-PVR depends on the availability of a chip that can convert a raw uncompressed hdmi video stream into h.264. I'd guess the chip that the HD-PVR uses isn't capable of handling a digital rather than an analog input.

An analog signal is quite different from a digital signal, so a digital signal requires a chip that is explicitly made to deal with it. I'm not saying that a chip capable of handling a raw digital signal can't be made or doesn't exist, but simply that the chip used in the HD-PVR is unlikely to be also able to deal with a digital signal.


The big deal is the availability of a chip that does such a thing, you can't just combine random chips that were intended for different purposes together. Chips are easy and cheap to mass produce, but cost a lot to design, so manufacturers like Hauppauge generally base their products on existing chips, they rarely have the expertise to design their own chips, and even if they do, they would do that only if the product has a big enough market (which is hardly the case for a product that most likely would be illegal in the US and probably the EU too).

The processing power required for capturing is not particularly heavy; indeed, its negligible all things considered. Storage capacity and STR performance, on the other hand, is quite high (as has been noted).

Processing power becomes an issue after the fact -- i.e. how you are going to manipulate that ginormous file you've written to disk from the uncompressed bitstream you've "captured".


of course; you have to do ADC on the former, and voila, you're left with the same format as the later.


While I'm not up on the varying capabilities of most of the available existing decoder chips, it is by no means a stretch in technology for anyone to include a "raw digital input" interface (in addition to a dedicated TS interface) -- "all you would need to do" (famous last words) is include a FIFO pool with enough capacity and DMA channel to put it out on the system bus ... such a feature has likely been lacking on decider chipsets simply because of the prior deficiencies in storage and processing technologies that made the application (uncompressed capturing) unpractical.


no. it's capable: http://www.analog.com/en/analog-to-d...s/product.html

Interesting thanks for the link, it really appears to be able to deal with a digital hdmi/dvi input stream too.

That still leaves the legal issue (just because the master key is out there that doesn't mean it's legal to use in a commercial product), therefore I'd imagine that only some noname chinese manufacturer will produce something like this, not companies like Hauppauge.