On Tue, 25 Feb 2014 11:42:06 -0500 "[email protected]" <[email protected]> wrote: > On Tue, Feb 25, 2014 at 9:40 AM, Manuel Braga <[email protected]> > wrote: > > On Mon, 24 Feb 2014 19:38:46 -0500 "[email protected]" > > <[email protected]> wrote: > >> On Mon, Feb 24, 2014 at 6:21 PM, Manuel Braga <[email protected]> > >> wrote: > >> > On Mon, 24 Feb 2014 16:17:31 -0500 "[email protected]" > >> > <[email protected]> wrote: > >> >> Compare it to these public Dropcams. They are using a slightly > >> >> better image sensor - OV5630. 500Kb/s 720P h.264 high encoding. > >> >> https://www.dropcam.com/cameras/featured > >> >> > >> >> CPU - http://www.ambarella.com/ > >> >> > >> >> I'd love to get that good of quality recording. > >> > > >> > You know who to go complain => Allwinner > >> > >> What I can't tell is if the hardware is good and the software is > >> just messed up, or if the hardware is fundamentally broken. > >> > >> So maybe I can do an experiment. First I can save some uncompressed > >> stills to assess the camera. > >> > >> Second, there is uncompressed test 720P video here. > >> https://media.xiph.org/video/derf/ > >> > >> I can feed it through the compression hardware and compare to x86 > >> software encoders. This works since there is no requirement to > >> compress in real-time. There is no way to save real-time > >> uncompressed video on the A20. It is just too fast. Would you > >> happen to already have an app written that can compress the raw > >> video? > > > > https://github.com/patrickhwood/h264encoder > > This is it, remenber NV12 format, both width and height must be a > > 32 multiple. > > 720 is 16 multiple. Is that easy to change?
Is explained in the README. You can use avconv(from libav ) or ffmpeg, to convert any video file into the right format. But looking at it, is only padding width, needs (not tested) -vf pad="trunc((iw+31)/32)*32:trunc((ih+31)/32)*32" Example: a video 1200x720, round up the sizes to a multiple of 32 becoming 1216x736, convert this way avconv -i originalvideo -vf pad=1216:736 -pix_fmt nv12 -f rawvideo \ rightformatrawvideo_1216x736.nv12 naming the rightformatrawvideo this way with the sizes and nv12 extension is required, this is were the encoder gets the size to configure the hardware. simpleencoder.static rightformatrawvideo_1216x736.nv12 -o video.mkv > > NV12 is same as YUV 4:2:0, right? > There are uncompressed YUV 4:2:0 720P samples here. > https://media.xiph.org/video/derf/ > No. It is similar, but the difference is in how the pixel data is packed. -- -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
