currently we got one issue that cobalt source_buffer feed different encrypted inpput_buffer at same PTS.
after decrypt them by widewine, we get wrong data to decode, the decrypted data also is different.
we have to verify which part is broken.
could you provide us cobalt(release 11) binary that can decrpyt with widewine and decode vp9?
Related
I am designing a generic Java library which needs to Sign messages before Sending and Verify messages before accepting. Sign and Verify needs to work with both of the following constraints;
Use raw 32 characters long key with some additional details like key start date, end date, grace period, the algorithm as raw information (do not have a choice, but have to accept it as raw data).
Use a proper PKI certificate containing a public key
For PKI based secret it is straightforward to use JKS/PKCS12 to store information and use it.
The problem I am facing is how do I manage and store raw information? What should be the data structure? So far my options are;
Use JCEKS provided by JRE to store all the raw information in my own made up data structure as secret properties and resolve at runtime to execute my library
Use JKS/PKSC12 and along with X509 Certificate data structure to store all raw information under its Extensions
What I am really looking for is the best practices for these kinds of versatile requirements i.e. manage un-managed secret properties?
As far as I know, cobalt will support widevine/playready drm playback, and we are trying to port on our platform with TEE support.
We have already done the starboard/player.h porting and I want to say the reference code for player did a great help! But when I try to start starboard/drm.h porting (at Cobalt 6.14197), I only find a little code related to drm. (e.g Starboard_decryptor, some stub implementation for drm.h API).
Do we need to implement our own content decryption module to handle license parsing, policy, etc., or will cobalt provide the reference cdm (which will be great) and we can use our OEMCrypto module to finish the rest part?
Cobalt is able to support any DRM system compatible with the Encrypted Media Extensions, but this has only been fully proven out with both PlayReady and Widevine on deployed products.
Licensing makes it difficult to provide an open-source reference integration with Widevine or PlayReady, so it is currently up to the platform implementer to integrate the code to generate license challenges, install keys, and decrypt samples before decoding. Note that you should not need to change any code in src/media to do this, you should be able to accomplish this by only implementing Starboard player/drm/media APIs.
You may be able to directly contact the business entities involved to get access to a non-open-source reference implementation.
Parse is turning out to be convenient to use. However the service does not allow for streaming videos to the server. I need a service that allows my users to stream videos to the server while they are recording. I was able to find the KickFlip SDK. Does anyone know how I might be able to pair KickFlip with Parse for Video Streaming? Even if I were to use both services, as opposed to just the KickFlip SDk, how would I coordinate the two? Parse provides rich social database but storing a ParseFile video is limiting (no streaming and 10MB max).
Should work on a REST client with a normal POST ( i would not do your scenario without adding something like Heroku/EC2 to parse.com PAAS architecture, but it will work )... I dont know 'flipkick' but you must know low-level protocol details b4 you include this in a solution.
In REST.POST.Headers you would need to include the combo of header values consistent with a client posting a stream on https to parse.( more here ). ie NO length header, ask for chunked encoding, use http 1.1. On a FILE POST to parse, IMO you dont need to worry about a timeout. You will have to append to the end of your posted bytestream the normal http , chunked-encoding , byte sequence signifying END_OF_DATA.
Sample Curl interaction with headers etc.
Observe relevant parse.file.sz. limitations...
I have successfully uploaded the fatca data packets to IDES. I got response from IDES, now I want to decrypt the messages.
Whenever i tried to decypt using our private key it throws "BAD DATA" error.
I have verified my certificate is valid, and we uploaded same certificate to IDES at the time of registration.
I am using c#.net as per IDES guidelines.
What might be the error and any areas which I can cross check?
Maybe a bit late, but I had published a tool for this.
It's the IDES receiver and it's source code is here.
It's written in javascript
I'd recommend to use the official IDES Data Tool, this one has been validated by the IRS and you can download it from https://github.com/IRSgov/IDES-Data-Preparation-Dot-Net.
Install the IDES tool
Open the Decrypt Notification tab
Upload the received Data Packet
Check your Output folder, you should have the Data Packet unzipped, and among others the XML decrypted.
If you have still problems with this process you can also debug this application from the source code.
Is it possible to legally progressive play Windows Media DRM tracks as they are downloaded from a HTTP link?
I've managed to do this without DRM but someone here told me it wasn't possible with DRM. Is this true?
And if so with what set of libraries or technologies?
I'm pretty sure it's possible and not illegal either. Normally, information about content encryption and actual encrypted content is kept separate in the same container. That is to say, metadata is not encrypted but content is. To support progressive download, the content is normally encrypted i small transferable ordered chunks. Your DRM client uses the metadata to locate a license server, next a license and content key is acquired from the license server. Next, your client downloads the content "chunk-per-chunk" ,decrypts each chunk, and renders it as a motion picture while it is downloading.
For information on SDK's, check out the different components here.
Yes it is.