video encryption playing

Reproducción de video encriptado



encryption playing (4)

Lo que quiero hacer es lo siguiente: necesitamos proteger el contenido del video (cifrarlo) y poder reproducirlo.

Lo difícil es que no queremos cargar todo en la memoria de una vez y descifrarlo allí (aunque eso también es una opción)

Lo que esencialmente busco es la solución para que nosotros reproduzcamos contenido de video encriptado, desde HDD, de manera que solo nuestra APLICACIÓN pueda reproducir ese video.

Sin embargo, debería leer el archivo de bloque a bloque (porque si se trata de un archivo de 2GB, no debería cargarse en la memoria de una sola vez).

Por favor, háganos saber, ¿cuáles son las formas posibles?

  • SilverLight4 DRM: está bien, esta parece una solución razonable, lo suficientemente flexible para nuestras necesidades. Sin embargo, PlayReady SDK cuesta alrededor de $ 30,000 y no queremos usar SilverLight. Presumiblemente C # o C ++

  • Bueno, una idea que teníamos era dividir un gran archivo de video para separar los archivos de video encriptados (como la secuencia) y luego cargar cada archivo ("bloque") directamente en memoria / descifrarlo y reproducirlo desde la memoria (y alternar entre los archivos de secuencia), este parece ser el más fácil hasta ahora y probablemente el que realmente podría hacerse. Sin embargo, ¿qué libs son capaces de reproducir archivos de video desde memoryStream? Creo que VLC debería poder hacerlo ...?

  • Otra idea era simplemente tomar AVI sin comprimir, procesar video cuadro por cuadro, modificar cada cuadro (cifrarlo de alguna manera), ahora cuando reproducimos el video, reprocesamos el cuadro en la memoria y lo desencriptamos.

  • Tratar con un solo códec específico y escribir una solución personalizada para él: en realidad, suena genial, pero me temo que nos llevará demasiado tiempo, pero déjenos saber acerca de este enfoque.

  • El otro, usando VLC para reproducir stream encriptado desde localhost (por ejemplo, APPLICATION está transmitiendo un archivo HDD encriptado al localhost: 800 / BLAHBLAH) y la misma aplicación tiene control VLC allí para descifrar la transmisión encriptada. Todavía no sabemos si el archivo en el disco duro también se puede encriptar (para que el usuario no pueda reproducir ese archivo en otro reproductor), además de que VLC es GPL, lo cual no es bueno para nosotros.


Gracias a todos por los ansers. Soy un tipo que pasó por diferentes enfoques.

Escribí mi propio Videoplayer usando openGL + FFMPEG que podría reproducir mp4 y descifrar cada fotograma en la GPU usando shaders. También experimenté con otras posibles soluciones, como la transmisión desde un servidor web usando VLC. (VLC ofrece algún tipo de encriptación / descifrado cuando se trata de transmisiones), y yada yada yada.

También una solución fue usar 4 elementos medievales (WPF) y el video real se dividió virtualmente en 4 áreas y cada área se rotó para que el video no se viera. Una vez que haya cargado el video en 4 elementos multimedia, puede trazar un mapa de la parte que desea mostrar y también girarla hacia atrás. Pero honestamente, MediaElement es malo.

Sin embargo, terminé exactamente con lo que RomanR dijo. Construí el gráfico de DirectShow usando mp4splitter, ffdshow, videorenderer y modifiqué el filtro de fuente mp4splitter. La lectura ocurre en BaseSplitter / AsyncReader.cpp (solo modifica la función SyncRead) que usa mp4splitter.

Si desea implementarlo usted mismo, simplemente use el proyecto MPC-HC y modifique los filtros como desee. Me tomó un tiempo entender el concepto de DirectShow, pero una vez que lo entiendes, se convierte en una gran arma.

http://sourceforge.net/apps/trac/mpc-hc/


Casi todos los algoritmos de encriptación ampliamente utilizados funcionan en bloques de tamaños entre 128 y 256 bits, y descifrarán felizmente solo algunos de ellos a la vez, muy bien para la transmisión. Vea, por ejemplo, Crypto ++ para una biblioteca de software que tiene interfaces de transmisión. (Es decir, acaba de abrir un archivo, poner un filtro de descifrado alrededor de eso, y luego simplemente continuar como con cualquier otro archivo).


La tubería de reproducción suele ser un conjunto de componentes conectados entre sí. En DirectShow , una de las API y la más popular, se utilizan lectores, divisores, códecs, postprocesamiento y partes de presentación conocidas como filtros, y todo se reproduce. Es posible sustituir al lector con su propio reemplazo, que lee contenido cifrado y decodifica sobre la marcha. Puede decodificar fácilmente bajo demanda, sin necesidad de decodificar todo el bloque de 2 GB para, por ejemplo, obtener un primer fotograma o una miniatura.

Habiendo enganchado solamente la parte del lector, puede elegir el método de encriptación, entre el algoritmo personalizado, uno conocido, API o biblioteca externa.

Aún así creo que esta y otras (al menos la mayoría de las otras) formas no te dan una garantía a prueba de balas que el contenido codificado no se puede revertir. Alguien más todavía puede engancharse en la tubería y tomar el contenido decodificado desde allí. Si está contento de que esto al menos requerirá complejidad y experiencia para implementarlo, entonces dicho cifrado funcionará bastante bien.


Ok, así es como lo hice. (Androide)

El video cifrado se coloca en una tarjeta SD. RC4 encriptado, por lo que se puede convertir sobre la marcha durante la transmisión. Luego creé un servidor de archivos local que se ejecuta en el dispositivo (como un servicio). El flujo de salida hace algo extra antes de enviar datos, lo filtra a través de un desencriptador RC4 antes de escribirlo en el búfer. Luego, simplemente apunte el reproductor multimedia a la url del video (http: // localhost: port / abc.3gp "). Como resultado, el video de la tarjeta SD permanece seguro, no puede reproducirlo a menos que tenga la clave, lo cual debe ser diferente para cada video para mayor seguridad.