Actually it appear that the file being written is working. mplayer can
play it but vlc can't. It is a raw h264 byte stream and does not
contain FPS data so it plays really fast. Next step is to capture
audio and wrap everything in MPEG TS. That will let me add FPS data.
Am 18.10.2013 11:26, schrieb Enrico:
On "frame.0" ... I forgot to say....
Hi
On Fri, 25 Oct 2013 11:58:10 -0700 (PDT) Patrick Wood
<patric...@gmail.com> wrote:
> I was thinking the same thing. See
> https://github.com/patrickhwood/h264encoder. I pulled out all the
> camera and preview code and read image data instead from frame.N
> files in the main.c loop. The frame.[0-5].xz files in the repo are
> planar YUV420 frames taken from a cedrus/mpeg-test run.
But then you can't change the frame size in a easy way.
Why not same as http://v4l.videotechnology.com/vivi/vivi.c
one function that auto generates frames in the right format that
the hardware requires.
> Unfortunately, when I try to run simplerecorder in an armel chroot, I
> get
>
> E/osal_linux: (329) flush cache fail, range error!
I got this too.
> followed by a segfault. Probably some silly thing on my part with
> virt/phys buffers.
No any more messages?
Did you mounted devtmpfs, as poorly explained here
http://linux-sunxi.org/CedarX/RE_Toolkit
>
> I still need to instrument the cedar_dev driver's ioctl to see what
> it's trying to actually do, but I'm hoping this can be a start for
> others as well.
The tracer also gets the ioctls, and there is also a trace viewer.
But caution, this is not trivial to install, doesn't have error
checking, and is slow very slow.
https://gitorious.org/recedro/recedro/
Hi.
On Wed, 23 Oct 2013 15:55:29 -0700 (PDT) Enrico <ebu...@gmail.com>
wrote:
> Do you think the encoder Jon shared is not minimal enough?
> I have another version for linux that is basically the same, just
> without threads. I don't know if it's possible to make the encoder
> even more simple, any suggestions?
>
> Enrico
>
But this is also a chance to the people that thinks reverse
engineering is too hard, to even try in the first place.
By simply helping in this, will give a useful contribution to pushing
forward the RE effort.
On Fri, 25 Oct 2013 15:31:04 -0700 (PDT) Patrick Wood
<patric...@gmail.com> wrote:
>
>
> On Friday, October 25, 2013 5:50:30 PM UTC-4, Manuel Braga wrote:
> >
> > Hi
> >
> > On Fri, 25 Oct 2013 11:58:10 -0700 (PDT) Patrick Wood
> > <patric...@gmail.com <javascript:>> wrote:
> > > I was thinking the same thing. See
> > > https://github.com/patrickhwood/h264encoder. I pulled out all
> > > the camera and preview code and read image data instead from
> > > frame.N files in the main.c loop. The frame.[0-5].xz files in
> > > the repo are planar YUV420 frames taken from a cedrus/mpeg-test
> > > run.
> >
> > But then you can't change the frame size in a easy way.
> > Why not same as http://v4l.videotechnology.com/vivi/vivi.c
> > one function that auto generates frames in the right format that
> > the hardware requires.
> >
>
> Why would I want to change the frame size?
To easy see which registers in the hardware controls the input frame
dimensions.(when reserve engineering)
You were using fixed frame files, now you don't, so don't mind.
> Anyway, I didn't want to bring in v4l when I can get the frame data
> in the format I want directly from the cedar decoder engine. (Well,
Then i probably misunderstood what you are trying to do.
> here's hoping it's in the format I want -- the documentation and
> cedrus code all agree that it is, but since the output is garbled,
> I'm concerned that it might not be.)
Did you noticed in encoder.c, the function I420toNV12
--
mul
On Sat, 26 Oct 2013 06:04:00 -0700 (PDT) Enrico <ebu...@gmail.com>
wrote:
> >
> I just published my version in [1], to summarize: linux example app,
> captures from webcam and encodes to raw h264 file, no display.
>
> Have a look at the readme and git log to see what i changed, and at
> the video sample to see the problem with the output.
I tested, same result.
I think you need this function.
https://github.com/ashwing920/SimpleRecorder/blob/master/encoder.c#L160
NV12 appears to be what the hardware takes in(i don't have certain)
And v4l devices are limited by the formats that are supported.
> I hope it's simple enough to make tracing a bit faster.
Yes it will help.
But there is still more changes, still up to task?
On Sat, 26 Oct 2013 07:34:52 -0700 (PDT) Patrick Wood
<patric...@gmail.com> wrote:
>
> On Saturday, October 26, 2013 6:04:04 AM UTC-4, Manuel Braga wrote:
>
> I was trying to create the minimal demo program for testing and RE
Great.
Enrico is also doing something, maybe both of you could join, and split
the work.
> and also a launching point for a HW transcoder project. I realize
> that might be a little ambitious, as it may not be possible to switch
> the cedar HW between encoding and decoding on a frame-by-frame basis,
> but it's certainly worth a try!
https://github.com/linux-sunxi/cedarx-libs/tree/master/enc_dec_demo
is doing exactly that, encoder in one thread, decoder in an other
thread.
But i only got partial success, because that source code is missing
the .a cedar libraries, and didn't find ones that compiled.
Only tested the pre-compiled binary there.
--
mul
On Saturday, October 26, 2013 6:04:04 AM UTC-4, Manuel Braga wrote:
To easy see which registers in the hardware controls the input frame
dimensions.(when reserve engineering)
You were using fixed frame files, now you don't, so don't mind.Actually, I'm checking that each new frame has the same size as frame.0, but I can change that if you think it'll help with the reverse engineering efforts. It's just a sanity check right now in case the frames are not properly formatted.
And isn't a usable encoder library useful to people than can't wait to
use the hardware.
Do you mean something like this: https://github.com/patrickhwood/h264encoder/commit/dfda30f51ba6e783fd40668c722e5398f3db6f99
On Thu, 7 Nov 2013 15:25:39 -0800 (PST) Enrico <ebu...@gmail.com>
wrote:
> Il giorno giovedì 7 novembre 2013 22:16:53 UTC+1, Patrick Wood ha
> scritto:
> >
> > Do you mean something like this:
> > https://github.com/patrickhwood/h264encoder/commit/dfda30f51ba6e783fd40668c722e5398f3db6f99
Yes that, (not actually tested)
There is still a lot more to go, but i will show source code.
> We can avoid the conversion if we have frame.0 already in nv12
> format, did you try that?
I don't like reading individual frames from files. I prefer to have a
function that generate colorbars frames, and optional read raw frames
from only 1 file using libavformat
> > On Thursday, November 7, 2013 3:30:47 PM UTC-5, Manuel Braga wrote:
> >> The are now two repositories, better is if everyone worked in one.
> >> The code from SimpleRecorder that Patrick used as base looks
> >> better structured, let's use this one?
Can we have only 1 repository, in which we all have commit access?
Patrick, can you add us as committers, or make a new repository that
will allow this.
--
mul
On Fri, 8 Nov 2013 08:50:08 -0800 (PST) Patrick Wood
<patric...@gmail.com> wrote:
> on the basic version right now, as it's currently possible to build
> and run this program on armhf with a static build, even though it
> must be built with armel tools (running in an armel chroot is OK, but
> not exactly optimal). I'd prefer to have it read just a bunch of
> concatenated raw images from 1 file if needed. I'll be happy once we
Then can be rawvideo?
That way, ffmpeg/libav could be used as this:
avconv -i video.mkv -pix_fmt nv12 -f rawvideo pipe: | h264encoder \
<options to still be defined that include frame WxH, format, framerate>
> have something that can actually be linked with libavformat on
> armhf. Presumably, the endpoint for this work is a libavcodec plugin?
Not for me.
My intention is to only make easy to use various input formats.
> Yes. Please give me your github names and I'll add them to the
> collaborator list.
https://github.com/mulb
Do you prefer that i commit to a separate branch and you do the merge,
or directly to re-project branch is ok?
Okay, I pushed another change that allows it to record NV12 frames from stdin. I tested it with this:avconv -i big_buck_bunny_480p_MPEG2_MP2_25fps_1800K.MPG -vf pad="trunc((iw+31)/32)*32" -pix_fmt nv12 -f rawvideo pipe: | simplerecorder 864 480Note that the raw video width needs to be padded to a multiple of 32 pixels (pad="trunc((iw+31)/32)*32").Pat
On Sun, 10 Nov 2013 08:36:03 -0800 (PST) Patrick Wood
<patric...@gmail.com> wrote:
> Any idea where the bulk of the extra traces are coming from? It's
> most likely one or two specific places where it's occurring.
Is at memcpy in encoder_encode_frame.
In Enrico's encoder the frame data is fread into a cedar buffer
directly. As this looks like to be a copy in the kernel side, the
tracer doesn't see it.
Can you join irc? This kind of talk is more suited to be discussed
there.
I pushed a demo h264 encoding app to:
https://github.com/jonsmirl/cam
It seems to be working, but the output file is just a blank image.
I'll keep working on it, but if anyone can see what is wrong with it
please let me know.
Not much too it, about 1,000 lines of code derived from the
enc_dec_demo program. I basically deleted all of the display code
since it is harder to build and left the encoding code.
--
Jon Smirl
jons...@gmail.com
--
You received this message because you are subscribed to a topic in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/D-2cICv9zbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/D-2cICv9zbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com.