Streaming an encrypted video file to a VideoView about conceal HOT 8 CLOSED

Android has transparent whole device encryption (which can be enforced by your app through the use of a DeviceManager), like iOS, but does not have support for encrypted storage on an app by app basis (there is no app Data Protection equivalent).

The only way I know of to have an encrypted directory/folder on Android is to use something like IOCipher. I say like IOCipher, but really I'm not aware of any other options, and as far as I'm aware it's not compatible with iOS, and I don't know if it supports random access/streaming, as it's based on SQLite/SQLCipher.

You might be able to use an uncompressed zip file, or tar file, but each individual file would need to be encrypted separately. That's actually not a half bad idea for bundling the IV along with the file contents.

Regardless, you need to ensure your video files are encoded in a stream friendly format to prevent long delays before playback, if you do get something to work. Since you're downloading from the server, you should be able to run ffmpeg or something on them before compressing to change the atom order - you don't have to reencode them or anything, it just moves some bits around inside the file.

from conceal.

expanded error messaging

01-23 12:17:32.479  29925-20029/? E/OMX-VDEC-1080P﹕ delay ETB for 'empty buffer with EOS'
01-23 12:17:32.489  29925-20029/? E/OMX-VDEC-1080P﹕ delay ETB for 'empty buffer with EOS'
01-23 12:17:32.499  29925-20029/? E/﹕ ERROR: In boolean H264_Utils::extract_rbsp(OMX_U8*, OMX_U32, OMX_U32, OMX_U8*, OMX_U32*, NALU*)() - line 260
01-23 12:17:32.499  29925-20029/? E/﹕ ERROR: In bool H264_Utils::isNewFrame(OMX_BUFFERHEADERTYPE*, OMX_U32, OMX_BOOL&)() - extract_rbsp() failed
01-23 12:17:32.519  29925-20029/? E/OMX-VDEC-1080P﹕ Rxd i/p EOS, Notify Driver that EOS has been reached
01-23 12:17:32.519  29925-20029/? E/OMX-VDEC-1080P﹕ INPUT EOS reached
01-23 12:17:32.619  29925-20029/? E/OMX-VDEC-1080P﹕ Output EOS has been reached
01-23 12:17:32.619  29925-20029/? E/﹕ not in avi mode
01-23 12:17:32.619  29925-20029/? E/OMX-VDEC-1080P﹕ Rxd OMX_COMPONENT_GENERATE_EOS_DONE
01-23 12:17:32.699  19918-19930/com.github.browep E/MediaPlayer﹕ error (1, -1004)
01-23 12:17:32.699  19918-19918/com.github.browep E/MediaPlayer﹕ Error (1,-1004)

from conceal.

This is a general problem in android. I believe VideoViews also take URIs as input. Since you can't set up a custom filesystem in android, the next best thing to do would be to run a small HTTPServer inside your app and point your videoview at this server. Then run conceal in this server as it decrypts the bytes to serve the video request. Conceal already has a streaming api, so it should work fine.

from conceal.

I'm going to close this for now. Please feel free to reopen if you have more questions.

from conceal.

@browep I'm also interested, did you find a solution?

My use case is similar, I have a bunch of MP3 and MP4 files compressed and encrypted using LZ4 and AES, each file is decrypted and decompressed on-the-fly, so that streams are non-seekable.

MP3 files are fed to an AudioTrack instance through a JLayer's mp3 stream decoder, which spits PCMs.

However with MP4 it seems there is no way to do that directly with a non-seekable stream. I've been suggested to use a local server, but that would add latency, and some people say delay is unpredictable and inconsistent across devices?

from conceal.

Streaming video is a complicated subject. You can glean some ideas perhaps from libMedia (http://libeasy.alwaysdata.net/network/). They lay out a pretty good overview of some of the challenges. I haven't used the library myself, but I have heard good things (although their examples use an empty IV, and I wouldn't recommend that).

For best results with video, you would need to use AES/CFB/NoPadding or AES/CTR/NoPadding for the encryption, and all your meta data, including the IV, would need to be stored separately from the file. This is because you need to know the correct file size - any information prefixed to the encrypted stream would make that incorrect, and would then have to be compensated for during seeking, and you need the ability to read randomly from the file in order to support seeking.

I don't think conceal is very a good fit for this particular task. It prepends the meta data to the file (conceal version, IV, etc.), and uses GCM which requires a full file read to perform authentication.

You really should also pre-process the files to make them streaming friendly - i.e., put the moov atom before the mdat atom, otherwise you will have a long delay (something like 1 delay second per megabyte of video) before playback can be started. (e.g., 60MB video would have something like a ~1 minute playback delay!), as it will have to read and decrypt all the bytes until finds the moov atom. Even worse if you're attempting to stream this from a server - in which case you will have to stream the entire file before playback can begin, even if you don't care about seeking.

@rraallvv It seems to me that MP3 and MP4 are already compressed, so you're just going to add more headache and overhead with an additional decompression step on the fly. Compressing the encrypted files for transport over the network might be ok, but you should probably uncompress as they're downloaded, leaving just the encrypted file locally.

from conceal.

@mandrachek thanks for helped me out to get a better understanding on the matter. What I'm trying to do is to implement a container to store all the application assets in both iOS and Android, each file is compressed using LZ4 and encrypted with AES, the directory information is also encrypted. As for now the implementation allows me to extract each individual file on-the-fly without having to store a temporal copy in the files system. Each individual file is not encrypted but the whole files container is, except for the databases, which do need to be stored somewhere in the file system after extracted in order for the application to work. The app downloads the same asset packages from internet, independently of the platform.

from conceal.

@mandrachek I ended up using qtfaststart to move the atom to the start of the file, and ExoPlayer with a customized AssetDataSource to read the data from the input stream. As for the custom container, I think I'll stick to LZ4 + AES, and SQLite with encryption, which could be easily ported to any platform or language. Thanks for your suggestions, it's very much appreciated.

from conceal.