Interesting idea, but a couple if questions come to my mind - what kind of file descriptor is OUT FD in this case? Since it would have to be writable from one end and readable from the other it would have to be some sort of pipe?
I ask because we are only passing the descriptor to the MediaPlayer which would then be accessed independently of any InputStream/ RandomAccess file that created it, giving us little chance to override any of these operations. Bear with me if I am missing the obvious here though. Also, for what it is worth, FD is final, making it hard to override. Ideally, it would be open up a variety of options if the media player allowed for data to be provided as part of a set of callbacks, removing the reliance on support for various transports in the native layer itself. Cheers, Johan On Aug 12, 7:45 am, Daniel Drozdzewski <[email protected]> wrote: > On 12 August 2011 11:28, Sumedh Jiwane <[email protected]> wrote: > > > > > > > > > > > actually not sure what do you want to do. can you be elaborate more. Do you > > want to play local file or remote file. Do you want to stream or download > > and play? > > > On Fri, Aug 12, 2011 at 8:28 AM, Peter Taps <[email protected]> wrote: > > >> Folks, > > >> Our application requires that a H.264 video be kept on the disk in an > >> encrypted format. One should be able to play this video only through our > >> application. > > >> I am seeking ideas on the best way to achieve this. > > >> I looked at VideoView class. Looks like it can only take a file, HTTP or > >> RTSP uri. One thought I had was to implement a RTSP server on the device as > >> part of our application but that may be an overkill. > > >> I would appreciate your thought.. > > >> Thank you in advance for your help. > > >> Best regards, > >> Peter > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Android Developers" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >>http://groups.google.com/group/android-developers?hl=en > > Peter, looking at various available APIs, it seems that you have 1 > choice (maybe 2): > > 1) to decrypt the video into a temporary local file and prepare > MediaPlayer (or VideoView) with URI to this temp file. > It obviously makes you vulnerable to attack, between creation and > deletion of said file. > > possible 2) Extend FileDescriptor class so that it's IN file > descriptor points at encrypted video file > FD.sync() of your extended FD causes read + decrypt + write to OUT FD > (which is what MediaPlayer reads from) of some chunk of the encrypted > file. The resulting amount of decrypted bytes should be big enough to > keep the player occupied. Please also mind that this will all depend > on the 'power' of host hardware. > > Your sync() method should be overriding parts of file that OUT FD > points to, that have been consumed already by the Player with some > random gibberish. You will need to use RandomAccessFile to create the > OUT FD and keep track of its offset for erasing and for playing. > > Good Luck! > > -- > Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
