<libv>
there is nothing in the dts that pertains to the encoder
<swiftgeek>
a test input known to work would be nice to have (i guess captured output of ffmpeg before h264enc would work fine)
<libv>
this is i think what is still valid in the readme
<libv>
the rest in the readme is not relevant at all
<swiftgeek>
welp right now I have no way to tell whether I'm feeding h264enc the right data
<swiftgeek>
unless everything works fine
<swiftgeek>
so with known good input (i guess few raw nv12 frames?) in git repo or sth, there would be less to worry about
<swiftgeek>
and even if I try to put ffmpeg output somewhere, ffprobe doesn't recognize nv12 anywhere in it
ftg has joined #linux-sunxi
<swiftgeek>
I mean something like ./h264enc ~/infile_640x360.nv12 640 360 /tmp/test.x264 with infile_640x360.nv12 being in repo
bauen1 has joined #linux-sunxi
<swiftgeek>
yeah
<swiftgeek>
looked at other side, and nv12 is definitely not right xD
<swiftgeek>
0x10 there
<libv>
the bit of big buck bunny as nv12 that i use is 1.5GB
ftg has quit [Ping timeout: 480 seconds]
<libv>
for 1k frames
<libv>
1280*720*1.5 / 1024 = 1350MB
<swiftgeek>
yeah but just some few frames for such test case would be enough
<libv>
the last bit of work i did was thumbnailing
<libv>
which is needed for the fosdem video box lcd
<libv>
to vastly decrease memory bandwidth usage
<libv>
upcoming work will be adding full sysfs config and io, and then add dmabuf input
<libv>
and then i can tie it in with the rest of the fosdem video pipeline
<swiftgeek>
ffmpeg has -frames so it should be possible to seek somewhere in the middle and output few nv12 frames precisely
<libv>
swiftgeek: i just took big buck bunny and used that documented ffmpeg command to generate the file
<libv>
there was nothing to it
<libv>
and i too initially went through that emotion that you have now
<swiftgeek>
yeah when it works there is nothing to it xD
<swiftgeek>
but few frames in repo would save many emotions
<libv>
again, this is not meant for users
<libv>
this is a step along the long road to build the fosdem video box
<swiftgeek>
well making it easier to reproduce working is still a good thing
<libv>
which is capturing an hdmi signal, then displaying on hdmi-out while turning some frames into nv12 using G2D, then encoding it to h.264, and sending the result over the network while displaying some 4x scaled down frames on the status lcd
<swiftgeek>
and if output is deterministic, then it's also a simple pass/fail
<libv>
patches are welcome
<swiftgeek>
welp I need to reproduce it first ;D
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
<swiftgeek>
and I don't even know whether it would work with just one frame or whatever, and while I can grab big buck bunny, "bigbuckbunny.mpg" in google resolves to just your repo :D
<libv>
there is little i can do here.
<libv>
*sigh* let me put this on our dl server.
<libv>
it will take 10mins
<libv>
at leastt
<swiftgeek>
tried creating nv12 frame with webcam until it looked fancy in xxd, still getting 0x00 on output side xD
<gamiee>
without cedar kernel module, any usage of encoder locks up ?
<libv>
i do not have the hw setup, it's been 18 months since i touched this
<libv>
swiftgeek should know more
<swiftgeek>
without cedrus module i just get 0x00 (or cedrus loaded after cedar)
<swiftgeek>
and I didn't try other repo stuff meant for primarily S3, together with cedrus yet (coz i commented out that section)
<swiftgeek>
Though not sure if i can have video-engine@1c0e000 and video-codec@1c0e000 together, that sounds like a conflict
JohnDoe_71Rus has joined #linux-sunxi
<swiftgeek>
and reg portion is different , not sure if i can extend it like that cedrus
<swiftgeek>
I guess I should bother xunlong about boardview export in GenCAD format with artwork stripped, so I can revive H3 board without much stress
<swiftgeek>
would be nice if they had IRC contact xD
<libv>
good point, i should pry this ve_mode register apart, at least document this
<libv>
but this is always written
<libv>
so that cannot be the cause
<swiftgeek>
would be nice to know whether they used allegro for layout, then i could provide instructions for that exactly
aggi has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
cnxsoft1 has quit []
aggi has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
buZz has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<jernej>
wiki seems to be down
Daaanct12 has joined #linux-sunxi
ftg has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
Daaanct12 has quit [Ping timeout: 480 seconds]
<libv>
jernej: indeed, machine is called maxima
<libv>
15:14 < libv> hrm, maxima seems gone now
<jernej>
ah, I didn't know
<libv>
nothing i can do about it atm, mnemoc needs to get involved there
Guest6561 is now known as palmer
bauen1 has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Read error: Connection reset by peer]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
bauen1 has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
hlauer has joined #linux-sunxi
moteen has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
moteen has quit [Ping timeout: 480 seconds]
gsz has quit [Quit: leaving]
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
sunshavi has joined #linux-sunxi
Luke-Jr has joined #linux-sunxi
ftg^ has joined #linux-sunxi
moteen has joined #linux-sunxi
HERIC has joined #linux-sunxi
gamiee_ has joined #linux-sunxi
pg12_ has joined #linux-sunxi
ftg^ has quit [charon.oftc.net coulomb.oftc.net]
hlauer has quit [charon.oftc.net coulomb.oftc.net]
ftg has quit [charon.oftc.net coulomb.oftc.net]
gamiee has quit [charon.oftc.net coulomb.oftc.net]
pg12 has quit [charon.oftc.net coulomb.oftc.net]
z3ntu has quit [charon.oftc.net coulomb.oftc.net]
psydroid[m] has quit [charon.oftc.net coulomb.oftc.net]
Arthur[m]123 has quit [charon.oftc.net coulomb.oftc.net]
Tooniis[m] has quit [charon.oftc.net coulomb.oftc.net]
hlauer has joined #linux-sunxi
karlp has quit [Ping timeout: 480 seconds]
moteen has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
hlauer has quit [Read error: Connection reset by peer]
hlauer has joined #linux-sunxi
bauen1 has joined #linux-sunxi
karlp has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
psydroid[m] has joined #linux-sunxi
z3ntu has joined #linux-sunxi
mnemoc has joined #linux-sunxi
<swiftgeek>
looks like libv cedar module kicked in with combined DT section like this https://bpa.st/4OPQ , and so does cedar_ve from the other repo. but cedar_ve/cedar and sunxi-cedrus don't work together - only first one that is loaded works
<swiftgeek>
so since it applies to both maybe I should strip reg stuff and try again
<libv>
swiftgeek: there are no changes to the dtses for the fosdem device that relate to cedarx
<libv>
for me
<swiftgeek>
lol can't reproduce what i had just few hours ago xD
<swiftgeek>
oh nvm, i just didn't read properly what happened
<swiftgeek>
so load sunxi-cedrus, unload, load cedar(ve) ?
<swiftgeek>
yeah so loading cedar directly after boot gives me constant"35 bytes"/0x00, loading sunxi_cedrus after that does nothing, but loading sunxi_cedrus, unloading it then loading cedar makes cedar+h264enc provide proper output