[Ssc-dev] New Example

[Shawn Van Every]

I agree, FFMPEG is probably the best bet.

Right, we don't have to use MOV, we can use just about any container we like with just about any compression we like.  

Yes, the code now is making saving preview frames out as JPEGs (I thought I choose lossless but I think I might be wrong about that) and then compressing with ffmpeg (I specify an mjpeg but it seems to be ignoring my wishes and creating and compressing as MPEG-4).

It is definitely doing an uncompress/recompress more than once in the overall chain. I think we might be able to get FFMPEG to read in raw YUV images and not have to loose so many generations.  That's the hope at least.

I agree that the real power comes in by using the native compressor and having ffmpeg process it afterwards.  I'll add your notes about the filter to the wiki under that section.

Thanks all!

-s

On Jul 29, 2011, at 1:07 PM, Andrew Senior wrote:

> This is great. FFMPEG seems like a good way forward.
> I've not followed the argument fully. With ffmpeg there's no need to use MOV container or MJPEG compression is there? I didn't follow the code too closely, but I think you're saving the preview frames as JPEGs then compressing them to an mjpeg with ffmpeg. In this scenario does FFMPEG reencode the jpegs, or just embed them in the container stream? The latter presumably means the video is constructed with negligible CPU- the CPU is all in the decompression / recompression of the original frames at recording time.
> 
> With ffmpeg we could transcode a recorded video (full native format & framerate) and make our own 
> filter (http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_HOWTO) that does the redaction based on a second file that stores the redaction regions. It could also dump the redacted information to a separate stream, and with ffmpeg we might be able to embed this, encrypted into the container. 
> 
> Redacting a video after recording has the advantage of allowing the same workflow that we have in the current release - you cn redact previously - recorded content. 
> 
> Andrew
> 
> 
> On Fri, Jul 29, 2011 at 12:29 AM, Nathan of Guardian <nathan at guardianproject.info> wrote:
> On 07/28/2011 11:58 PM, Shawn Van Every wrote:
> > Runtime exec for now.  NDK/JNI down the road.
> 
> Runtime is fine with me! That is what we do for Orbot
> .
> >> What are the settins you are using at this point?
> > I think the problem has to do with the YUV/JPEG/JPEG/MP4 compression chain.  We'll have to skip some of these steps..
> 
> It would be great to get a sense of "maximum possible quality" vs
> "estimated time for processing each frame".
> 
> > Some issues:
> > 1: I reinstall ffmpeg every time
> 
> Yes, that should be fixed.
> 
> > 2: It is way big (>20MB)
> 
> Eh. Not so bad.
> _______________________________________________
> Ssc-dev mailing list
> 
> Post: Ssc-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
> 
> To Unsubscribe
>        Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>        Or visit: https://lists.mayfirst.org/mailman/options/ssc-dev/andrew.senior%40gmail.com
> 
> You are subscribed as: andrew.senior at gmail.com
> 

Shawn Van Every
vanevery at walking-productions.com
Mobile and Streaming Consulting
http://www.walking-productions.com/notslop
Author: Pro Android Media: http://amzn.to/eYb48C