[Ffmpeg-devel-irc] ffmpeg-devel.log.20180429

[burek]

[00:13:34 CEST] <durandal_1707> ubitux: fixed also TODO in fieldmatch
[00:14:41 CEST] <durandal_1707> and learned new thing about lavfi and referencing supported pixel formats in query formats
[00:16:28 CEST] <durandal_1707> also fixed leaks spotted
[02:53:01 CEST] <kierank> atomnuker: do you think in vc2enc we could do some ratecontrol across a row of slices
[03:14:42 CEST] <atomnuker> kierank: yeah, no point in doing something complicated if you've got a limit on the max cost per slice (bitrate/slice_nb)
[03:15:00 CEST] <atomnuker> what you should do is just have a single lambda value and treat each slice as if its a new frame
[03:15:37 CEST] <atomnuker> do some basic rdo, where you measure the distortion of the slice and its cost, mult them, mult that by the lambda
[03:16:27 CEST] <atomnuker> since you approximately know how much distortion you'll gain/lose if you change the quant you can just make some basic per-qp weights
[03:16:57 CEST] <atomnuker> so you can save time and do just 1 or 2 distortion/cost calculations per slice
[03:17:50 CEST] <atomnuker> by just interpolating with the weights (and you'll probably need to work the energy of the slice in there somehow since the curves will change depending on the energy of the slice)
[03:18:25 CEST] <kierank> hmmm ok
[03:19:07 CEST] <kierank> when we get it all working I'll ask jdarnley to look at that or do it myself
[03:19:20 CEST] <kierank> I'd like to do AQ across a row of slices
[03:19:26 CEST] <kierank> because the whole fixed slice size thing is dumb
[03:19:30 CEST] <atomnuker> well that pretty much does that
[03:20:16 CEST] <atomnuker> since you can't get away with just a single qp per slice in vc2 unless you want hardware encoder-tier quality
[03:21:06 CEST] <atomnuker> its not difficult, all the functions are there
[03:21:35 CEST] <kierank> we are also putting a slice in an rtp packet so we need to modify the ratecontrol to be exact
[03:21:37 CEST] <atomnuker> all you'll have to change (from the git master of the encoder) is make count_slice or whatever it was get you the slice energy while you're at it
[03:21:38 CEST] <kierank> and never go over
[03:21:58 CEST] <kierank> (like opus)
[03:22:59 CEST] <atomnuker> yeah, if you calculate your weights on a few videos and make sure to compensate with the energy you'll likely never need to do more than 1-2 dist measurements per slice
[03:23:27 CEST] <atomnuker> (to make sure you're fulfilling the specified rate and not going above)
[03:24:17 CEST] <atomnuker> the hardest part will be using the lambda value at the start of the frame to calculate the slice padding/that weird multiplier
[03:24:27 CEST] <atomnuker> because if its too big you'll waste a lot of bits
[03:25:15 CEST] <atomnuker> but that can come later, you can stick with the default value of 2048 (I think, from memory it was usually hovering around that)
[04:16:19 CEST] <cone-945> ffmpeg 03Jerome Borsboom 07master:19c3df0cd6dd: avcodec/vc1: fix mquant calculation
[10:08:43 CEST] <cone-484> ffmpeg 03Paul B Mahol 07master:70d25b89db9b: avfilter/vf_overlay: use slice_end in alpha_composite()
[13:05:16 CEST] <BtbN> I have been staring at this CUstream API for a while now, and I still don't understand it.
[13:26:39 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:889d858491ac: avfilter: add amplify filter
[13:53:28 CEST] <durandal_1707> ubitux: ppsrc option of fieldmatch is completly broken, it does not work with input from telecine filter
[14:03:22 CEST] <ubitux> it's supposed to work with filter that do not affect the pts
[14:03:38 CEST] <ubitux> like, does it work with a denoiser such a nlmeans?
[14:04:05 CEST] <ubitux> iirc that's the purpose
[14:04:24 CEST] <ubitux> pre-filtering the graphics to help the fieldmatch heuristics
[14:05:25 CEST] <durandal_1707> ubitux: it is broken because it will call filter_frame when there is already frame, so it will just overwrite it, one of lavfi improvements broke it
[14:05:45 CEST] <durandal_1707> guess will need transform to activate
[14:06:20 CEST] <durandal_1707> ubitux: i test only with split, which should give same result
[14:07:32 CEST] <durandal_1707> i now see how Nicolas is very incompetent for his position
[14:07:53 CEST] <ubitux> i haven't tested the filter since its introduction
[14:07:58 CEST] <ubitux> i'm not sure we even have a fate test&
[14:08:15 CEST] <ubitux> if so, we should probably have at least 2 tests
[14:10:38 CEST] <durandal_1707> ubitux: should it use framesync2 or not? definetely need converting to .activate
[14:12:41 CEST] <ubitux> the expected usage is: "split=2[src][extra]; [extra]nlmeans[pp]; [src][pp] fieldmatch=ppsrc=true"
[14:13:04 CEST] <ubitux> fieldmatch is supposed to use [pp] to analysis
[14:13:13 CEST] <ubitux> and picking the corresponding from [src]
[14:13:22 CEST] <ubitux> i don't know if framesync2 would help
[14:13:58 CEST] <ubitux> (nlmeans or whatever filter that would help the heuristics)
[14:14:12 CEST] <durandal_1707> ubitux: even simply do nothing does not work
[14:14:13 CEST] <ubitux> (as long as it doesn't break the pts sync)
[14:14:23 CEST] <durandal_1707> pts are unchanged
[14:14:39 CEST] <durandal_1707> ubitux: i'm sure it worked before
[14:14:47 CEST] <ubitux> maybe a regression was introduced in the past years
[14:14:50 CEST] <ubitux> i never use that filter
[14:14:51 CEST] <durandal_1707> yes
[14:21:23 CEST] <wm4> ubitux: can you ok my HLS patch? (it's somewhat related to your avoption deprecation thing)
[14:23:54 CEST] <ubitux> maybe dashdec and rtsp should actually be updated as well
[14:32:42 CEST] <wm4> thanks
[14:33:18 CEST] <wm4> now if only dashdec weren't just most of hls copy&pasted or something
[14:33:32 CEST] <JEEB> yea, they could just share a lot of base logic
[14:33:41 CEST] <wm4> with some weird differences
[14:34:12 CEST] <JEEB> and same for hlsenc and dashenc, they could also just share a lot of stuff
[14:34:13 CEST] <nevcairiel> they even share a lot now because dashenc can also create a hls playlist on the side
[14:34:32 CEST] <JEEB> yea, but they don't share all of the non-string creation stuff
[14:34:39 CEST] <wm4> dashenc!=dashdec
[14:34:40 CEST] <JEEB> but they do share some stuff, yes
[14:34:57 CEST] <wm4> oh you changed topic, nvm
[14:34:57 CEST] <nevcairiel> obviously encoder != decoder, your point? :p
[14:35:09 CEST] <JEEB> the decoder was being discussed
[14:35:12 CEST] <JEEB> and IIRC that shares less
[14:35:14 CEST] <JEEB> or they
[14:35:29 CEST] <nevcairiel> those people interested in the encoders are not really interested in making nice and clean things
[14:35:34 CEST] <nevcairiel> much corporate in there
[14:35:41 CEST] <wm4> it seems like dashdec started out with a copy of hls that was then heavily modifed
[14:35:41 CEST] <JEEB> yup
[14:36:06 CEST] <nevcairiel> probably, dashdec was one of those big monsters noone dared to really review anyway
[14:36:27 CEST] <JEEB> yea
[14:37:20 CEST] <wm4> well many reviewed it a bit, but I think they could pick out only minor things, not criticize the architecture
[14:37:41 CEST] <wm4> can't exactly say "please rewrite it in a way that as much logic as possible is shared with hls"
[14:37:50 CEST] <nevcairiel> why not
[14:42:43 CEST] <wm4> because it'd require being a dick
[14:43:11 CEST] <wm4> not that much of a problem in ffmpeg, but still
[14:44:19 CEST] <nevcairiel> if devs want to a void that, they ask about architectural feedback before writing thousands of lines of code
[14:44:36 CEST] <JEEB> true
[15:04:09 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:a5b2d85f18b3: avfilter/vf_fieldmatch: switch to activate
[15:04:10 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:ad164237047d: avfilter/vf_fieldmatch: add support for >8 bit depth in ppsrc
[15:18:51 CEST] <JEEB> holy crap
[15:19:04 CEST] <JEEB> just noticed this one guy implemented an ARIB subtitle decoder in lavc
[15:19:16 CEST] <JEEB> now I don't know if I should rework that one, or use libaribb24
[15:19:21 CEST] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/7757871426c285c913a27771c11e9c0e5c80259d
[15:20:18 CEST] <durandal_1707> JEEB: that is old one, couple days passed
[15:21:07 CEST] <JEEB> yes, I know I had looked at that repo before but I hadn't noticed this :D
[15:21:14 CEST] <atomnuker> JEEB: looks fine, tables aren't huge
[15:21:53 CEST] <JEEB> I think he started using some forked libass features to show it
[15:21:59 CEST] <JEEB> but having this internal is pretty cool
[15:22:21 CEST] <JEEB> also this repo taught to me that iconv seems to have the ARIB-B24 coding as well?
[15:22:29 CEST] <JEEB> iconv_open("UTF-8", "ARIB-STD-B24");
[15:22:33 CEST] <JEEB> which is good if true
[15:24:15 CEST] <wm4> not here btw.
[15:24:17 CEST] <wm4> iconv -l
[15:24:28 CEST] <JEEB> yes I was kind of afraid it was this guy's fork
[15:24:32 CEST] <wm4> it has shitjizz (aka SHIFT_JIS) but no arib
[15:24:32 CEST] <JEEB> since he has a gconv module for it
[15:24:44 CEST] <JEEB> yea, shift-jis and iso2022jp families with euc-jp are there
[15:26:35 CEST] <JEEB> but yea, this 0p1pp1 dude seems to have poked all the things
[15:26:42 CEST] <JEEB> iconv, FFmpeg, libass, mpv
[15:27:12 CEST] <wm4> he probably wouldn't mind if someone took it and cleaned it up
[15:27:25 CEST] <JEEB> yea
[17:40:03 CEST] <JEEB> wm4: seems like one .jp guy already posted both European and ARIB text codings to gconv in 2015 https://sourceware.org/ml/libc-help/2015-03/msg00006.html
[17:40:20 CEST] <JEEB> not sure if it ever went into the repo
[17:41:10 CEST] <JEEB> wonder what happened to those patches as they contain both DVB and ARIB
[17:42:27 CEST] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00027.html
[17:42:32 CEST] <JEEB> > they are domain-specific so GTFO
[17:42:35 CEST] <JEEB> asdf
[17:43:12 CEST] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00016.html
[17:44:31 CEST] <durandal_1707> where is GTFO written?
[17:45:03 CEST] <JEEB> paraphrasing
[17:45:37 CEST] <JEEB> but basically "thanks, they look largely straight forward.  unfortunately, i think most likely we're going to pass on them.  it's nothing personal ... we most likely won't accept any more gconv modules unless it's computing related (as vague as that sounds) and makes a strong case as being relevant."
[17:46:05 CEST] <JEEB> "a quick scan of our current modules shows they're all focused on encodings that were used historically (IBM/DOS/Windows/etc...) or active today (UTF8/etc...).  encodings used in broadcast tv don't really fall into these buckets."
[17:46:25 CEST] <durandal_1707> shame
[17:47:00 CEST] <wm4> seems arbitrary
[17:47:09 CEST] <JEEB> like
[17:47:22 CEST] <JEEB> is every goddamn project supposed to have their own thing embedded?
[17:49:06 CEST] <wm4> anyway it wouldn't help ffmpeg anyway
[17:49:15 CEST] <wm4> it can't rely on the system iconv having this
[17:50:06 CEST] <JEEB> then the alternatives are to use patched iconv, or using aribb24 for ARIB and ?!? for DVB
[17:50:18 CEST] <JEEB> or NIH'ing the code from another project and having the N'th copy of a similar text conversion code
[17:52:29 CEST] <wm4> maybe making a small lib?
[17:52:51 CEST] <JEEB> for ARIB aribb24 seems to be that
[17:52:57 CEST] <JEEB> DVB I just have no idea
[18:00:35 CEST] <durandal_1707> kierank: shouldn't because alpha can be 16 bit in ProRes, we do 16bit instead of 12?
[18:01:10 CEST] <kierank> I guess
[18:04:17 CEST] <wm4> jamrial: is it ok if I push my VS wrapper?
[18:04:22 CEST] <cone-644> ffmpeg 03Michael Niedermayer 07master:da038c07f02d: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo()
[18:04:22 CEST] <cone-644> ffmpeg 03Michael Niedermayer 07master:6e95d80e6fae: avcodec/wavpack: Fix integer overflow in DEC_MED() / INC_MED()
[18:04:34 CEST] <durandal_1707> wm4: not ok
[18:05:45 CEST] <wm4> durandal_1707: why?
[18:08:14 CEST] <durandal_1707> we should remove avisynth support, vapoursynth support is not needed
[18:22:48 CEST] <durandal_1707> so i can not pass struct to x86 asm?
[18:23:20 CEST] <wm4> durandal_1707: are you blocking my patch?
[18:26:40 CEST] <atomnuker> JEEB: its not that much code and it'll mathematically always be valid tbh
[18:27:05 CEST] <JEEB> yea, as long as someone goes through the validation
[18:27:07 CEST] <atomnuker> its not really nih, someone else wrote it too :)
[18:27:24 CEST] <jamrial> durandal_1707: you can, see fft
[18:27:43 CEST] <JEEB> I'm not sure if I have the patience to make sure all entries match their pretty pictures at the end of the ARIB PDF :D
[18:28:00 CEST] <JEEB> I just have to trust and see that most of the code makes sense
[18:28:04 CEST] <JEEB> maybe add a few tests
[18:29:08 CEST] <jamrial> wm4: i have no opinion on vapoursynth other than i'd prefer if you could do like avisynth and export as rawvideo instead
[18:29:50 CEST] <jamrial> lets try to not increase the amount of modules depending on sizeof(avframe)
[18:30:16 CEST] <wm4> I can send a patch to fix that for all modules afterwards
[18:30:24 CEST] <wm4> my idea is to store a AVFrame* instead
[18:30:31 CEST] <wm4> (why isn't that done currently anyway)
[18:30:38 CEST] <durandal_1707> wm4: no, is this sponsored work?
[18:30:45 CEST] <wm4> durandal_1707: no
[18:30:59 CEST] <wm4> durandal_1707: I'm just trying to fight avisynth
[18:31:07 CEST] <durandal_1707> lol
[18:31:09 CEST] <jamrial> wm4: any such change couldn't be done until we bump major again anyway
[18:31:29 CEST] <wm4> jamrial: depending on what we think about we might have to add a new codec ID
[18:32:26 CEST] <wm4> or the avpriv_get_avframe_size() idea
[18:33:21 CEST] <jamrial> is it too hard to assemble rawvideo pakets with the methods vapoursynth provides?
[18:33:23 CEST] <durandal_1707> jamrial: even for "struct weighted_avg wa[HUGE_NUMBER]" ?
[18:33:58 CEST] <wm4> jamrial: vapoursynth only provides an AVFrame-like object
[18:34:29 CEST] <wm4> though I'm copying the video anyway, because otherwise I'd probably have to attach python to the refcount thing (lol)
[18:34:39 CEST] <wm4> or well I'd have to refcount the core
[18:34:42 CEST] <durandal_1707> ubitux: i gonna write nlmeans SIMD
[18:34:45 CEST] <wm4> might actually do that later
[18:34:52 CEST] <ubitux> durandal_1707: i'm actually doing it right now
[18:35:03 CEST] <ubitux> for aarch64 though
[18:35:10 CEST] <ubitux> but the infrastructure + tests is there
[18:36:21 CEST] <durandal_1707> ubitux: i write for x64
[18:36:38 CEST] <ubitux> are you going to blind it
[18:36:39 CEST] <ubitux> ?
[18:36:58 CEST] <ubitux> i'll poke you when the branch is ready for adding simd
[18:37:34 CEST] <durandal_1707> ubitux: you have additional changes?
[18:37:53 CEST] <ubitux> yeah sure, the callback system + checkasm test
[18:38:17 CEST] <ubitux> tests are a bit tricky so i need to start writing stuff to make sure they work
[18:42:15 CEST] <durandal_1707> well code that does doubles doesn need checkasm, only last averaging needs doubles
[18:44:14 CEST] <ubitux> what doubles?
[18:44:25 CEST] <ubitux> the simd i'm writing is for the integral part
[18:44:50 CEST] <ubitux> compute_safe_ssd_integral_image(_c)
[18:48:23 CEST] <durandal_1707> ubitux: final averaging
[18:49:30 CEST] <ubitux> ah, okay
[18:49:38 CEST] <ubitux> well we shouldn't have too much conflict then
[18:50:41 CEST] <ubitux> i went with a NLMeansDSPContext dsp at the end of NLMeansContext
[18:50:51 CEST] <durandal_1707> ubitux: well, i want to write other one too, for x64
[18:50:56 CEST] <ubitux> addition of a libavfilter/vf_nlmeans.h, usual stuff
[18:51:04 CEST] <ubitux> sure
[18:51:12 CEST] <ubitux> i don't plan to write any x86 simd
[18:51:25 CEST] <ubitux> but if we can do the infrastructure work once that would be best
[18:51:36 CEST] <durandal_1707> just post patch when you write infrastructure
[18:51:37 CEST] <ubitux> i'll give you the branch with that done in a moment
[18:51:59 CEST] <ubitux> yup, it's written but i did that months ago i need to check what's the status of it (if it does even work/compile)
[18:52:06 CEST] <ubitux> give me 30 min - 1h
[18:53:18 CEST] <durandal_1707> wm4: have you read post on d9, your patch was mentioned there, and it have bug
[18:54:15 CEST] <durandal_1707> probably python environment variable is needed because thats what i need for vspipe and mpv's vs filter
[18:59:40 CEST] <wm4> I don't read d9
[19:04:35 CEST] <durandal_1707> https://forum.doom9.org/showthread.php?t=175341
[19:07:27 CEST] <wm4> that doesn't seem to be related to anything, just someone fighting windows
[19:09:34 CEST] <jamrial> there's a version using rawvideo posted there as well
[19:09:42 CEST] <jamrial> from April 3rd
[19:10:10 CEST] <jamrial> doing the same as the avisynth wrapper, nice
[19:18:23 CEST] <jamrial> Gramner: ^ ticket 7177 looks like a x264 bug
[19:40:27 CEST] <cone-644> ffmpeg 03Paul B Mahol 07master:c0f2abcc8d2a: avfilter/vf_mix: make setting weights more user friendly
[19:40:28 CEST] <cone-644> ffmpeg 03Paul B Mahol 07master:02470814b595: doc/filters: add tmix examples
[19:45:44 CEST] <ubitux> /home/ux/ffbuild/aarch64/src/libavcodec/v4l2_m2m.c:72: undefined reference to `sem_init'
[19:45:48 CEST] <ubitux> is this known?
[19:47:45 CEST] <jamrial> sounds like pthreads was not properly detected?
[19:48:03 CEST] <jamrial> or that v4l2_m2m is missing the relevant dep in configure
[19:48:48 CEST] <ubitux> yeah i disabled pthread on purpose
[19:49:02 CEST] <ubitux> i guess that's the reason
[19:50:38 CEST] <jamrial> ubitux: maybe https://pastebin.com/czWavj0C ?
[19:51:25 CEST] <jamrial> guess checking for sem_timedwait is enough since that's only enabled if pthreads is enabled
[19:54:37 CEST] <jamrial> so maybe https://pastebin.com/rEjms3vY
[19:57:07 CEST] <ubitux> durandal_1707: WIP @ https://github.com/ubitux/FFmpeg/tree/nlmeans-dsp
[19:57:11 CEST] <ubitux> jamrial: i'll test in a second
[19:57:30 CEST] <jamrial> sure, no hurry
[20:01:13 CEST] <ubitux> jamrial: seems to fix compilation with --disable-pthreads here
[20:01:15 CEST] <ubitux> thanks
[20:02:19 CEST] <jamrial> no prob
[20:06:27 CEST] <cone-644> ffmpeg 03James Almer 07master:cae6f806a636: configure: add missing pthreads dependency to v4l2_m2m
[20:33:10 CEST] <JEEB> wm4: someone actually seems to have tested your thing https://forum.doom9.org/showthread.php?p=1840663#post1840663
[20:33:15 CEST] <JEEB> (vapoursynth)
[20:33:56 CEST] <wm4> fuck that person
[20:34:03 CEST] <wm4> "it doesn't work"
[20:34:29 CEST] <JEEB> yes, not exactly a good report
[20:34:54 CEST] <wm4> also something about windows builds
[21:10:57 CEST] <wm4> jamrial: what's your beef with wrapped avframe?
[21:11:23 CEST] <durandal_1707> wrapped avframe is faster?
[21:11:48 CEST] <wm4> it can be made faster and it doesn't have these alignment issues
[21:12:01 CEST] <jamrial> it's ugly, that "trusted" pkt stuff is kinda sketchy, it uses sizeof(avframe)
[21:12:34 CEST] <jamrial> i'm not blocking your patch, just would prefer if you can do like avisynth and just export normal rawvideo packets
[21:13:19 CEST] <atomnuker> it would have been nice to have an api which could make lavf and lavd output avframes but that could go wrong
[21:13:50 CEST] <wm4> there's already such an API and it sucks
[21:13:59 CEST] <wm4> I prefer the wrapped_avframe hack
[21:14:07 CEST] <durandal_1707> ubitux: why aarch64 specifically?
[21:14:25 CEST] <atomnuker> wm4: there is? which one
[21:14:34 CEST] <wm4> oh wait, the uncoded stuff is for muxing only
[21:14:36 CEST] <wm4> no demuxing
[21:14:54 CEST] <wm4> but I guess you could argue demuxing could be added
[21:20:35 CEST] <kierank> We should have a unified type for frame and packet
[21:20:43 CEST] <kierank> Would solve a lot of issues
[21:20:56 CEST] <wm4> just make AVFrame carry packet data
[21:21:17 CEST] <wm4> you can bet someone will suggest this
[21:33:04 CEST] <ubitux> durandal_1707: because that's the easiest one
[21:38:19 CEST] <durandal_1707> ubitux: you actually have way to test?
[21:45:14 CEST] <jamrial> there are some commercial aarch64 boards, but last time i remember them being mentioned they kinda sucked for dev work
[21:45:22 CEST] <jamrial> crappy/old kernels or some such
[21:46:56 CEST] <atomnuker> the c2 is alright _when it works_, the latter being a question of distros
[21:48:04 CEST] <atomnuker> the pi3 with arch (aarch64) also works fine, though its a few times slower than the c2
[21:48:37 CEST] <atomnuker> (the plus being you won't get ripped off with customs fees, at least for now, because the c2 is korean made)
[21:55:33 CEST] <Gramner> jamrial: nope, it's not
[21:55:43 CEST] <Gramner> an x264 issue that is
[21:57:05 CEST] <jamrial> but shouldn't x264 gracefully reject weird input like the kind sent with that vf_scale combination instead of hard crashing with an assert?
[21:57:13 CEST] <Gramner> I guess x264 could fail more gracefully in case of invalid output instead of failing some random assert though
[21:57:23 CEST] <jamrial> yeah
[21:59:41 CEST] <Gramner> would probably have to do it in the plane copying functions to not affect performance, which would require modifying asm for at least 4 archs though, so somewhat of an effort required
[21:59:59 CEST] <Gramner> e.g. checking that all input pixels are in a valid range
[22:01:25 CEST] <wm4> I can't forgive C2 its video API
[22:02:15 CEST] <ubitux> durandal_1707: yeah i have a few aarch64 boards
[22:02:42 CEST] <ubitux> i'm using qemu for testing initially though, i use real boards when benchmarking
[22:04:00 CEST] <durandal_1707> ubitux: strange, i wrote asm that does nothing and speed does not changes, i expect perf gain by doing nothing
[22:04:40 CEST] <ubitux> maybe it's already zomg fast?
[22:06:39 CEST] <durandal_1707> ubitux: maybe algo does not like searching zeroes?
[22:09:07 CEST] <atomnuker> wm4: the c2 has a video api? first I've heard
[22:09:52 CEST] <wm4> atomnuker: yes, in /sys/
[22:10:24 CEST] <atomnuker> next you'll tell me it has hardware encoders and decoders using relatively standard APIs for embedded systems like v4l
[22:10:49 CEST] <durandal_1707> ubitux: actually i had bigger numbers with averaging, so that one might be better for perf gain
[22:11:08 CEST] <wm4> atomnuker: apparently you're not understanding the horror of it
[22:13:11 CEST] <atomnuker> probably not, I don't remember what it was like before I used a standard kernel without binary blobs
[22:17:06 CEST] <wm4> you control video decoding and display by writing into special files in /sys/
[22:17:49 CEST] <wm4> there's also an open source library (provided by the firmware vendors) that controls it, but it's pre-beginner level shit C that does almost nothing anyway
[22:17:53 CEST] <nevcairiel> thats hardly an API, thats more like a CLI interface :P
[22:18:00 CEST] <wm4> other than opening special files and then leaking FDs
[22:18:17 CEST] <wm4> nevcairiel: kind of, but it's the kernel interface
[22:26:08 CEST] <kierank> michaelni: did you even read the spec when you wrote the patches
[22:29:57 CEST] <michaelni> kierank, yes
[22:30:06 CEST] <kierank> you reorder a lot of things
[22:31:02 CEST] <kierank> you break encoders which want to send custom quant matrix afaik
[22:31:38 CEST] <michaelni> none of the samples breaks, and one of them uses custom matrixes
[22:32:04 CEST] <kierank> michaelni: you break encoders which want to send them in a particular way
[22:32:17 CEST] <kierank> you make assumptions based on samples instead of the spec
[22:32:55 CEST] <kierank> it seems there are conformance samples
[22:34:03 CEST] <michaelni> kierank, if you have more sampels, please provide them. I dont see where my changes break the spec but the code before certainly doesnt follow the spec
[22:34:15 CEST] <kierank> it follows the spec exactly
[22:34:32 CEST] <kierank> you have made assumptions about particular ordering
[22:36:06 CEST] <kierank> table 6.2.2
[22:37:39 CEST] <kierank> michaelni: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/studio/
[22:37:42 CEST] <kierank> I only just found these now
[22:38:13 CEST] <michaelni> ehm, the code before had many assumtations on ordering that are removed by the patches
[22:38:25 CEST] <kierank> exactly the spec says they must be ordered like htat
[22:38:48 CEST] <kierank> you allow studiovisualobject to be anywhere in the bitstream now
[22:40:16 CEST] <michaelni> the code before didnt implement the specs ordering at all
[22:40:33 CEST] <kierank> ????
[22:40:35 CEST] <kierank> it did exactly
[22:40:58 CEST] <michaelni> for example theres a loop in that user/ext data thing on the spec but not in the code
[22:42:14 CEST] <michaelni> thanks for the link btw, ill make sure anything that works isnt broken by any changes i make
[22:42:41 CEST] <kierank> michaelni: ok, sure but that's an unrelated patch
[22:42:56 CEST] <kierank> nothing to do with allowing studiovisualobject anywhere in the bitstream
[22:43:57 CEST] <kierank> michaelni: ????
[22:44:12 CEST] <kierank> it's not about samples breaking with your changes, it's about following the spec
[22:45:54 CEST] <michaelni> the way the mpeg4 decoder is written is that the header is parsed in a loop, its messy if parts of it bypass the loop, also the ordering is really not enforced before, lots of stuff where and are parsed at random places or parsed twice if thats how they are stored
[22:46:31 CEST] <kierank> sunk cost fallacy
[22:47:22 CEST] <durandal_1707> what instruction to use to move 32bit unsigned from memory to stack variable?
[22:48:03 CEST] <nevcairiel> durandal_1707: "mov"? :)
[22:48:45 CEST] <nevcairiel> although you cannot do memory->memory, need to go into a register once
[22:49:14 CEST] <durandal_1707>    mov       accd, [dstq-dst_linesized*4-4]
[22:49:47 CEST] <durandal_1707> impossible combination of address sizes, invalid effective address
[22:50:06 CEST] <nevcairiel> that might also be too much math
[22:50:18 CEST] <kierank> durandal_1707: movd I think
[22:50:42 CEST] <nevcairiel> and as said, you cannot do  mem->mem moves, so if accd is on the stack, you need a register in between first
[22:51:24 CEST] <wm4> movd as in the string instruction? seems overkill
[22:52:07 CEST] <nevcairiel> he probably thinks about the simd movd
[22:52:20 CEST] <nevcairiel> but that also only works if one of those is a simd reg
[22:52:25 CEST] <kierank> ah
[22:52:54 CEST] <nevcairiel> for GPR stuff, mov is the right choice, but it has certain limitations - like no mem->mem
[22:53:03 CEST] <nevcairiel> so no heap->stack
[22:55:37 CEST] <jamrial> durandal_1707: lea, not mov
[22:56:33 CEST] <durandal_1707> mov doesnt like negative number
[22:57:50 CEST] <jamrial> use lea instead of mov and the above should work
[22:58:03 CEST] <nevcairiel> except it wont actually load the data :p
[22:58:31 CEST] <durandal_1707> i get invalid effective address
[22:58:44 CEST] <durandal_1707> so it can go only forward?
[22:58:54 CEST] <durandal_1707> this is not rust :)
[22:58:55 CEST] <jamrial> you may need to use dst_linesizeq, but yeah, what nevcairiel said is true in any case
[22:59:27 CEST] <durandal_1707> i tried that one already
[22:59:53 CEST] <durandal_1707> and acc is defined with call arguments
[23:00:22 CEST] <durandal_1707> so it can be both, but probably is on stack
[23:02:25 CEST] <nevcairiel> you can subtract constants, not sure you can subtract registers
[23:02:28 CEST] <nevcairiel> maybe only add
[23:04:15 CEST] <kierank> might work as adding twos complement number
[23:04:35 CEST] <kierank> oh it's the register
[23:04:40 CEST] <kierank> yeah don't think you an do that
[23:04:45 CEST] <kierank> neg the linesize
[23:27:48 CEST] <Gramner> x86 addressing is [base+index*(1,2,4,8)+offset] where offset is a constant. any one of them can be omitted
[23:28:29 CEST] <Gramner> offset can be negative, but not registers
[23:29:57 CEST] <Gramner> and always use native sizes (e.g. q suffix) in addressing operands even if using 32-bit is technically allowed
[23:30:25 CEST] <Gramner> even when using lea with a 32-bit destination register (shorter opcode in most cases)
[23:30:56 CEST] <atomnuker> you can neg either register though, preferably at the start of the function (its how you can save a register by not needing a counter if you count backwards)
[23:43:06 CEST] <durandal_1707> i forgot what to use to unpack bytes into words
[23:44:03 CEST] <Gramner> punpck(l/h)bw?
[23:44:21 CEST] <Gramner> http://www.felixcloutier.com/x86/
[00:00:00 CEST] --- Mon Apr 30 2018