Taftus wrote:I am clueless. Got code from both VC1 and MPEG2. MPEG2 seems to be working fine, just played.vob file and it works. But all of my wmv are still no go, I only hear sounds but no video. I downloaded install it but can't figured out where to activate it? I am using OpenElec from If you are using the raspbian 'wheezy' image from download page, then omxplayer is preinstalled.
Run apt-get update && apt-get upgrade and you will get the latest version that supports all VC1 files (WVC1 or WMV3) For xbmc, the WMV3 files have been fixed in source, but you'll have to wait for a build. Ah so without raspbian I have to wait for OpenElec to build in the fix? Guess I have to wait, but at least I have the key already Thanks for answering. Dom wrote: If you are using the raspbian 'wheezy' image from download page, then omxplayer is preinstalled. Run apt-get update && apt-get upgrade and you will get the latest version that supports all VC1 files (WVC1 or WMV3) For xbmc, the WMV3 files have been fixed in source, but you'll have to wait for a build.
Presumably the same applies to Raspbmc does it? Having to wait for the next 'official' build, that is. I did try and ask the question on 'their' forum, but my posts seem to vanish into a black hole as soon as I add them! Have you tried going back to basics with a freshly imaged SD card and then running apt-get update && apt-get upgrade then applying your license key. Also what are you using to make the changes to your config.txt file. If you use nano via ssh you should be able to cut and paste into the nano to avoid any typo's. I know people have had issues editing via windows or trying to get around vi when amending on the device itself.
The only other thing is have you checked that your serial which you entered to get your license key was correct? DecodeMPG2=0x12345678,0xabcdabcd,0x87654321 How many licences can be specified?
Looks like 3 is the current limit, but it could be increased. How many do you need? Does there have to be an upper limit? I would like to be able to specify about 8 keys for each codec type so that my cards can work in any one of my brothers, several friends or my own Pi's (we have a few by now!). I thought that when booting the GPU would just look through the list supplied to see if any matched and discard the rest? Itimpi wrote: I thought that when booting the GPU would just look through the list supplied to see if any matched and discard the rest?
Do you see the problem with that? If it were unlimited you could have a million keys in your config.sys and as long as one of them worked you wouldn't need to buy a license. I think it would take a lt more than that to cover all possibilities!
An obvious way around that is to make sure it takes a reasonable number of milliseconds per entry. That way anyone with VERY large numbers would never be able to complete the boot in a sensible time.
Having said that with the codec licenses so cheap do you think anyone is going to bother? Itimpi wrote: An obvious way around that is to make sure it takes a reasonable number of milliseconds per entry. That way anyone with VERY large numbers would never be able to complete the boot in a sensible time. Having said that with the codec licenses so cheap do you think anyone is going to bother? An even more sensible and obvious way round it is to have a reasonable limit on the number of possible entries. I can't reasonably think why anyone would need more than 30 (full sized class full) but to be honest, I doubt that many classrooms will be using their RasPis to watch films.
I agree 3 is a bit low. Somewhere between 5-10 would probably be a good balance between secure and flexible. I've read that someone ordered two sets of keys and received them with instructions showing them concatenated, as in: decodeMPG2=0x1234abcd,0xa1b2c3d4 decodeWVC1=0xd2c3a1e4,0x4d1a2c3d Would they actually work like that in the config.txt file?
If the keys were valid and the SDcard were inserted in one or the other of the two RPi's they were coded for, would this work? Or does the decoder just read the first 8 hex digits after the equal sign and truncate the rest? More to the point, why doesn't the Pi store ship the keys with relevant information like this? Order #12345, dated 18 Feb 2013 (for cpu serial # 00000000fce6192e) decodeMPG2=0x1234abcd decodeWVC1=0xd2c3a1e4 (for cpu serial # 00000000b23d4ea6) decodeMPG2=0xa1b2c3d4 decodeWVC1=0x4d1a2c3d.
So that people would know which keys go where? Or would that simply make too much sense? I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP. And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative. Colly wrote: I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP. And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative. Please refrain from insulting the people who give their spare time to this project.
They are not lazy, they are BUSY. And insulting them is hardly likely to get things changed, is it. Colly wrote: I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP. And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative. Please refrain from insulting the people who give their spare time to this project. They are not lazy, they are BUSY. And insulting them is hardly likely to get things changed, is it.
My apologies to the programmers. You are correct - I was out of line. Colly wrote:I've read that someone ordered two sets of keys and received them with instructions showing them concatenated, as in: decodeMPG2=0x1234abcd,0xa1b2c3d4 decodeWVC1=0xd2c3a1e4,0x4d1a2c3d Would they actually work like that in the config.txt file? If the keys were valid and the SDcard were inserted in one or the other of the two RPi's they were coded for, would this work?
That's handy to know! I wonder what the limit is on the number of keys per decode line is? I have seven RPi's so far, but have no idea how that line gets processed. Perhaps 255 bytes for whatever field type and length the two decode variables are defined as? Display posts from previous: Sort.
Wurth wow torrent. Even modern fast CPUs struggle to decode HD video in real time, so modern graphics cards have the ability to do it instead. Graphics processors, or GPUs, have many times more cores than CPUs, but they're a lot simpler. This means they're better suited to drawing video or 3d scenes, where it's usually possible to divide the picture up into pieces that can be processed in parallel. The RPI has a really slow processor, so is even less capable of decoding video itself, known as 'software rendering'. Luckily, because its chip is intended for video oriented set top boxes, it contains a decent GPU that is capable of decoding HD video in the three main video formats used today. However, as rcxdude mentioned, those decoding algorithms are not free, and is controlled with a license key.
Vlc has no access to this video decoding hardware if it's locked, so must use the CPU. That's painfully inadequate on the pi. To expand on the price point: The Raspberry Pi foundation could have opted for a volume license for all Raspberry Pi devices to be licensed from the get go. However while this is fine for Microsoft and the like, it would have gone easily into the multi-thousand-pound range as all they can give is estimated sales and that would have pushed up prices of the unit itself. Considering how cheap it is for individual licenses and the very tinkerer nature of RPi itself, it made more sense to ask users to purchase single device licenses, install them manually and probably save everyone some money overall.
To expand on the 'what is it' point: What you're buying is a license key that the codec itself requires be present before accepting or working on any audio or video stream sent to it. I believe the codec is part of most distros as it's just a few Kb, but without licensing it's essentially useless.
Taftus wrote:I am clueless. Got code from both VC1 and MPEG2. MPEG2 seems to be working fine, just played.vob file and it works.
But all of my wmv are still no go, I only hear sounds but no video. I downloaded install it but can't figured out where to activate it? I am using OpenElec from If you are using the raspbian 'wheezy' image from download page, then omxplayer is preinstalled. Run apt-get update && apt-get upgrade and you will get the latest version that supports all VC1 files (WVC1 or WMV3) For xbmc, the WMV3 files have been fixed in source, but you'll have to wait for a build. Ah so without raspbian I have to wait for OpenElec to build in the fix? Guess I have to wait, but at least I have the key already Thanks for answering. Dom wrote: If you are using the raspbian 'wheezy' image from download page, then omxplayer is preinstalled.
Run apt-get update && apt-get upgrade and you will get the latest version that supports all VC1 files (WVC1 or WMV3) For xbmc, the WMV3 files have been fixed in source, but you'll have to wait for a build. Presumably the same applies to Raspbmc does it? Having to wait for the next 'official' build, that is. I did try and ask the question on 'their' forum, but my posts seem to vanish into a black hole as soon as I add them! Have you tried going back to basics with a freshly imaged SD card and then running apt-get update && apt-get upgrade then applying your license key. Also what are you using to make the changes to your config.txt file. If you use nano via ssh you should be able to cut and paste into the nano to avoid any typo's.
I know people have had issues editing via windows or trying to get around vi when amending on the device itself. The only other thing is have you checked that your serial which you entered to get your license key was correct? DecodeMPG2=0x12345678,0xabcdabcd,0x87654321 How many licences can be specified? Looks like 3 is the current limit, but it could be increased. How many do you need? Does there have to be an upper limit? I would like to be able to specify about 8 keys for each codec type so that my cards can work in any one of my brothers, several friends or my own Pi's (we have a few by now!).
I thought that when booting the GPU would just look through the list supplied to see if any matched and discard the rest? Itimpi wrote: I thought that when booting the GPU would just look through the list supplied to see if any matched and discard the rest? Do you see the problem with that? If it were unlimited you could have a million keys in your config.sys and as long as one of them worked you wouldn't need to buy a license.
I think it would take a lt more than that to cover all possibilities! An obvious way around that is to make sure it takes a reasonable number of milliseconds per entry.
That way anyone with VERY large numbers would never be able to complete the boot in a sensible time. Having said that with the codec licenses so cheap do you think anyone is going to bother? Itimpi wrote: An obvious way around that is to make sure it takes a reasonable number of milliseconds per entry. That way anyone with VERY large numbers would never be able to complete the boot in a sensible time. Having said that with the codec licenses so cheap do you think anyone is going to bother? An even more sensible and obvious way round it is to have a reasonable limit on the number of possible entries.
I can't reasonably think why anyone would need more than 30 (full sized class full) but to be honest, I doubt that many classrooms will be using their RasPis to watch films. I agree 3 is a bit low. Somewhere between 5-10 would probably be a good balance between secure and flexible.
I've read that someone ordered two sets of keys and received them with instructions showing them concatenated, as in: decodeMPG2=0x1234abcd,0xa1b2c3d4 decodeWVC1=0xd2c3a1e4,0x4d1a2c3d Would they actually work like that in the config.txt file? If the keys were valid and the SDcard were inserted in one or the other of the two RPi's they were coded for, would this work? Or does the decoder just read the first 8 hex digits after the equal sign and truncate the rest?
More to the point, why doesn't the Pi store ship the keys with relevant information like this? Order #12345, dated 18 Feb 2013 (for cpu serial # 00000000fce6192e) decodeMPG2=0x1234abcd decodeWVC1=0xd2c3a1e4 (for cpu serial # 00000000b23d4ea6) decodeMPG2=0xa1b2c3d4 decodeWVC1=0x4d1a2c3d. So that people would know which keys go where? Or would that simply make too much sense?
I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP. And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative. Colly wrote: I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP. And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative.
Please refrain from insulting the people who give their spare time to this project. They are not lazy, they are BUSY. And insulting them is hardly likely to get things changed, is it. Colly wrote: I strongly suspect the license key email is being created by a keygen program written by a lazy programmer who inputs the email address and cpu serial number and has the keygen create a small text file (without passing along the relevant serial number or numbers) and emails it directly using SMTP.
Raspberry Pi 2 Vs 3
And the sales people are left with the fallout of complaints from confused customers because the programmer can't be bothered to make the output any more informative. Please refrain from insulting the people who give their spare time to this project. They are not lazy, they are BUSY.
And insulting them is hardly likely to get things changed, is it. My apologies to the programmers. You are correct - I was out of line. Colly wrote:I've read that someone ordered two sets of keys and received them with instructions showing them concatenated, as in: decodeMPG2=0x1234abcd,0xa1b2c3d4 decodeWVC1=0xd2c3a1e4,0x4d1a2c3d Would they actually work like that in the config.txt file? If the keys were valid and the SDcard were inserted in one or the other of the two RPi's they were coded for, would this work? That's handy to know!
I wonder what the limit is on the number of keys per decode line is? I have seven RPi's so far, but have no idea how that line gets processed. Perhaps 255 bytes for whatever field type and length the two decode variables are defined as? Display posts from previous: Sort.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |