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

[burek]

[01:44:10 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:5b0ae88ca6b3: genh: prevent overflow during block alignment calculation
[01:44:11 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:74bd17d31648: epafdec: prevent overflow during block alignment calculation
[01:44:12 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:cba4f0e97ecb: xvag: prevent overflow during block alignment calculation
[02:15:34 CET] <Lutier> Is it possible to add an option to ffplay so that is creates a borderless window? So that it could be used within other programs without hacks like this http://stackoverflow.com/questions/31465630/ffplay-successfully-moved-inside-my-winform-how-to-set-it-borderless.
[02:19:31 CET] <Lutier> like MPlayer's -noborder option
[06:16:02 CET] <Lutier> Am I just asking in the wrong place?
[06:55:06 CET] <Compn> Lutier
[06:55:33 CET] <Compn> Lutier : probably, patch welcome :)
[06:56:06 CET] <Compn> possibly by modifying sdl before compile
[07:17:33 CET] <Lutier> Compn: I don't speak C, so wouldn't know where to start
[07:22:34 CET] <Lutier> Compn: Assuming I'm looking in the right place, looks like there's a way with SDL_WINDOW_BORDERLESS flag in SDL_CreateWindow
[07:48:09 CET] <Lutier> Compn: Would this work? https://github.com/FFmpeg/FFmpeg/pull/249
[07:49:00 CET] <Polochon_street> Lutier: I don't know anything about your problem, but I guess the devs won't be happy https://github.com/FFmpeg/FFmpeg/pull/153
[08:36:59 CET] <wm4> man trolling is hard work
[08:37:23 CET] <nevcairiel> choose the lazy route and don't? :)
[08:37:24 CET] <wm4> too bad serious interaction doesn't work either and you get trolled
[08:37:57 CET] <wm4> what can you do if you churn out a bunch of technical argument, and all what comes back is a mail replying "Rude."
[11:03:13 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:76331361a51b: avformat/sccdec: simplify 2 sscanf calls
[11:03:13 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:036e12b225b2: avformat: add SCC muxer
[11:05:35 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:13564fc24d82: avutil/eval: add atan2 function
[12:04:09 CET] <cone-395> ffmpeg 03Clément BSsch 07master:3a3554871a13: lavc/hevcdsp: fix pretty printing mistake
[12:04:10 CET] <cone-395> ffmpeg 03Clément BSsch 07master:de2f9f4b71ae: doc/libav-merge: add unmerged hevc commits hashes
[12:07:58 CET] <nevcairiel> ubitux: thats just the old commits we skipped, not any new ones, right?
[12:25:17 CET] <ubitux> nevcairiel: yes
[12:25:52 CET] <nevcairiel> how is the merging going? I'm back home now and can probably help soon
[12:26:52 CET] <ubitux> didn't start
[12:27:00 CET] <ubitux> just looked around trying to understand
[12:32:00 CET] <nevcairiel> durandal_1707: the scc fate test fails on all my systems, ie. http://fate.ffmpeg.org/report.cgi?time=20170129223531&slot=x86_64-msvc14-windows-native
[12:36:06 CET] <durandal_1707> nevcairiel: looks like it dumps lines with `
[12:36:29 CET] <nevcairiel> the stderr has some stuff about invalid utf8, not sure if thats related
[12:37:15 CET] <durandal_1707> i dont get such errors at all
[12:37:55 CET] <durandal_1707> and scc have little modified ascii not utf8 at all
[12:39:10 CET] <durandal_1707> nevcairiel: does all your system have memory poisoning enabled?
[12:39:18 CET] <nevcairiel> yes
[12:39:26 CET] <nevcairiel> its default in the fate script we have in the repo
[12:40:27 CET] <nevcairiel> i can try to debug it a bit later
[12:41:07 CET] <cone-395> ffmpeg 03Tobias Rapp 07master:ec33ade7d300: avformat/Makefile: fix compilation of testprogs when networking is disabled
[12:51:50 CET] <durandal_1707> nevcairiel: try to change definition of 0x27 code at line  76 of ccaption decoder to simple '
[12:53:24 CET] <nevcairiel> still seems rather odd, why would it only happen here, its not like there is some external library involved, or is there?
[13:05:18 CET] <durandal_1707> that reverse ` doesnt seem like utf8 to me?
[13:08:43 CET] <nevcairiel> even then why does it not error anywhere else :D
[13:09:36 CET] <nevcairiel> unless the \u escape code is whats messing it up
[13:15:38 CET] <nevcairiel> ccaption_dec.c(86): warning C4566: character represented by universal-character-name '\u2588' cannot be represented in the current code page (1252)
[13:15:41 CET] <nevcairiel> hm plenty of those
[13:23:24 CET] <nevcairiel> newest compiler has a /utf-8 switch to make it work, but older compilers are still screwed .. but then, what do I care about those.
[13:38:10 CET] <rcombs> fuck anyone trying to build ffmpeg with old MSVC
[13:42:35 CET] <nevcairiel> i should shutdown the vs2012 box one of these days anyway, maybe when 2017 comes along
[13:42:47 CET] <nevcairiel> although 2013 would also be affected by this bug
[13:42:48 CET] <kierank> who the hell is bananaman
[13:50:55 CET] <durandal_1707> kierank: man who likes bananas
[15:04:17 CET] <ubitux> what does 'q' and 'e' stands for in qpel, epel? "quad"? "edge"?
[15:06:52 CET] <jkqxz> Quarter, eighth.
[15:07:21 CET] <nevcairiel> eighth looks so wrong of a word with the hth at the end
[15:07:24 CET] <funman> please use metric system: decipel, centipel
[15:07:46 CET] <ubitux> jkqxz: ooh. thanks.
[15:07:55 CET] <jkqxz> 2.5 decipels, 1.25 decipels?
[15:08:12 CET] <funman> yes, just like camera manufacturers do already
[15:09:57 CET] <ubitux> do we need a doc/lexicon where we put a list of "common shorthand we use that don't need a comment"
[15:09:59 CET] <ubitux> ?
[15:23:07 CET] <ubitux> what is fpel and hpel? fullpixel/halfpixel?
[15:25:08 CET] <funman> femtopixel and hectopixel obviously
[15:26:32 CET] <funman> ubitux: fullpel halfpel according to git grep in x264
[15:29:34 CET] <ubitux> ok so i was correct
[15:29:52 CET] <ubitux> http://b.pkh.me/lexicon
[15:29:56 CET] <ubitux> what should i add?
[15:30:38 CET] <nevcairiel> other then the pel's those all seem so obvious
[15:31:07 CET] <ubitux> maybe not for newcomers
[15:31:16 CET] <ubitux> adding sw and hw
[15:31:22 CET] <nevcairiel> if you dont know what dsp is, maybe you are too green =p
[15:31:43 CET] <ubitux> maybe :)
[15:32:38 CET] <kierank> full and half is better notation because some people refer to the pels as already being subsampled
[15:32:46 CET] <kierank> (imo)
[15:39:22 CET] <atomnuker> ubitux: (i)fft, vq (vector quantization), ec (entropy coding), vlc (variable length coding)
[15:40:31 CET] <ubitux> if we add fft, should we add a bunch of common transforms?
[15:41:46 CET] <atomnuker> wavelets don't really have an abbreviation, neither do legendre, gabor, etc.
[15:42:29 CET] <ubitux> lexicon updated
[15:43:30 CET] <atomnuker> oh yeah, add mdct (lapped dct)
[15:44:11 CET] <jkqxz> CABAC, CAVLC, GOP, AC, DC, IDR, I, P, B, VBV, HRD, NAL, RBSP, SAR, DAR?
[15:44:28 CET] <atomnuker> ubitux: and dst (discrete sine transform) and adst (asymmetric discrete cosine transform)
[15:44:38 CET] <jkqxz> CPB, DPB, VCL.
[15:44:42 CET] <atomnuker> *sine
[15:44:48 CET] <nevcairiel> noone really needs to know what cabac stands for, its somewhat of a word on its own :p
[15:45:48 CET] <ubitux> yeah and that's easily googlable
[15:46:09 CET] <ubitux> the 2 or 3 letters ones are often tricky to search
[15:46:16 CET] <jkqxz> Yeah, for a lot of those what it stands for isn't really relevant.  Knowing what they are is still helpful.
[15:48:25 CET] <rcombs> I know what CABAC stands for but not CAVLC
[15:48:43 CET] <ubitux> atomnuker: adst = asymmetric discrete (co?)sine transform :)
[15:48:51 CET] <jkqxz> It's just CABAC - BAC + VLC.
[15:48:54 CET] <nevcairiel> rcombs: the CA is the same, and VLC is what its always is
[15:49:07 CET] <atomnuker> yeah, its sine, not cosine, typo'd
[15:51:48 CET] <kierank> atomnuker: ec clashes with error concealment
[15:52:06 CET] <ubitux> jkqxz: don't assume i know all of them ;)
[15:56:48 CET] <ubitux> anyway, good enough for a first version, i'll let you ppl add more
[16:03:36 CET] <ubitux> we could add some nicknames in that file :°
[17:35:41 CET] <cone-457> ffmpeg 03bnnm 07master:ebb83e2dc0b4: avformat/msf: fix codec 4 (joint stereo ATRAC3) and align
[18:07:50 CET] <Chloe> ubitux: fdct = forward dct
[18:24:09 CET] <BBB> atomnuker: sorry, had to run yesterday, pthread api still works, so you can just use that directly with mutex objects that exist in the per-slice data structs
[18:24:17 CET] <BBB> (or global, if you want it shared)
[18:24:24 CET] <BBB> (i.e. in the priv_data object)
[18:25:25 CET] <BBB> atomnuker: I think the loopfilter would just run as an extra thread, the overhead of loopfilter on top of slice decoding should be small so a user should barely notice it
[18:26:30 CET] <BBB> atomnuker: maybe wed want to enhance the slice threading api to give a decoder control back of the main frame decoding thread when the per-slice threads have started, so the main thread could do lpf and await the slice threads as it does that, so that itd be a more interactive form of blocking for the slices to be done decoding
[18:26:49 CET] <BBB> (which reminds me, frame+slice combination would be fun to try)
[18:30:00 CET] <nevcairiel> someone did that for hevc, but it might not have been worth it for the complexity
[18:30:35 CET] <nevcairiel> so it never arrived here
[18:32:05 CET] <kierank> it's useful for encoding high bitrate h264
[18:32:13 CET] <kierank> like gigabit h264
[18:32:21 CET] <atomnuker> BBB: is there anything that needs to be done on the slice threads after the loop filter has been applied?
[18:32:36 CET] <atomnuker> sounds like its better to just do it in the main thread after slice decoding
[18:33:02 CET] <BBB> that would increase latency a bit
[18:33:11 CET] <BBB> so overall decoding time would go up
[18:33:29 CET] <BBB> the goal of threading is to bring back wall clock time as much as possible, right?
[18:33:42 CET] <BBB> so deinterleaving slice decoding and lpf would be a little bit strange in that context
[18:34:08 CET] <BBB> slice threads dont have to do anything after lpf, in the reference decoder the lpf is done after the whole frame has been reconstructed
[18:34:22 CET] <atomnuker> oh so you mean execute the loop filter inside the slice threads but sync them so that they don't overlap?
[18:34:25 CET] <BBB> vp8 was the same, ffvp8 interleaves lpf with main decode loop but libvpx does it post-decode-frame
[18:34:31 CET] <BBB> right, exactly
[18:34:52 CET] <BBB> you want the loopfilter for row=0 to only run after all slices have decoder row=0 for their respective columns
[18:35:09 CET] <BBB> if vp9 did what h264 does and skip loopfilter at tile boundaries, you wouldnt need any of this
[18:35:29 CET] <BBB> (slice boundaries in case of h264, but same idea)
[18:35:47 CET] <atomnuker> right, well if you have access to a mutex somewhere that's doable
[18:35:56 CET] <BBB> right, its fairly trivial
[18:36:05 CET] <BBB> in fact like you said, its just like the frame threading api
[18:36:21 CET] <BBB> except the progress is per-tile column instead of per field/frame row
[18:45:21 CET] <cone-457> ffmpeg 03Paul B Mahol 07master:acf1dd5b74ab: avfilter: add threshold filter
[20:15:53 CET] <kierank> peloverde: do you know where the vp9 in ts repo is?
[20:18:01 CET] <peloverde> It's in libwebm, I think it's still half finished though
[20:43:27 CET] <Chloe> Is there a more efficient algorithm to do zigzag matrix traversal other than the logical method?
[20:47:22 CET] <kierank> there is simd iirc
[20:47:41 CET] <kierank> or you just merge it into your coefficient unpack
[20:51:11 CET] <Chloe> kierank: It's a little off-topic (idk where else anyone is knowledgeable on this), to give some context--I'm writing an JPEG codec in Rust, trying to do it straight from the spec. I was thinking to go from DCT -> zigzag unpack -> quant -> etc. I guess you mean to merge zigzag with something else?
[20:51:25 CET] <kierank> encoder or decoder?
[20:51:36 CET] <kierank> if it's a decoder you can read your coefficients into the correct zigzag index
[20:51:49 CET] <Chloe> I'm doing the encoder first
[20:52:02 CET] <kierank> ah then probably you should zigzag in place
[20:54:13 CET] <Chloe> I was thinking if I could merge the DCT & zigzag, but other things than the DCT use the zigzag too
[21:35:19 CET] <BBB> Chloe: why do you want to unpack zigzag?
[21:35:30 CET] <BBB> Chloe: is it so you know the last significant coefficient?
[21:35:57 CET] <Chloe> so it's easier to quantize and then do rle on
[21:36:22 CET] <Chloe> otherwise I have to put the zigzag algo in the quantization and rle functions
[21:37:26 CET] <BBB> you mean because each quantizer is different and the ordering is in zigzag?
[21:39:54 CET] <atomnuker> Chloe: meh, its just a lookup table, do that during quantization unless you're man enough to hardcode it in the dct
[21:41:40 CET] <Chloe> My DCT is pretty trash (O(n^4) -- pls dont shoot me), I'd rather not put anything in it for now until I make it better. Is RLE not done in zigzag ordering?
[21:42:39 CET] <BBB> atomnuker: omg :D man enough to hardcode it in dct :D
[21:42:51 CET] <BBB> and trivial fdcts must exist already no?
[21:43:19 CET] <BBB> rle can do the lookup inside, so having the zigzag there shouldnt be an issue
[21:43:20 CET] <Chloe> Sure, but it's for a school project so I need to 'derive' everything myself. Can't use any library code
[21:43:26 CET] <BBB> ah
[21:43:42 CET] <Chloe> hence I'm implementing it directly from the spec pretty much
[21:44:25 CET] <BBB> I think most people just give the zigzag scantable to the coding and quant functions
[21:44:36 CET] <atomnuker> if you're still planning to write a faster dct then yeah, put the zigzag during RLE
[21:44:46 CET] <BBB> as for quant, if the quantizers need to be in scanorder, just palce them as such in the initial array
[21:44:51 CET] <BBB> so its just a matrix multiply again
[21:45:09 CET] <BBB> if you need it to derive last sig coeff, just provide an inverse zigzag (T^-1)
[21:45:28 CET] <BBB> so zigzag[izigzag[i]] == i
[21:50:45 CET] <Chloe> That sounds fine. My other issue was: how do I even know it works? I'll know when it's all implemented, but until then I'm pretty much blind.
[21:51:51 CET] <BBB> individual functions can be tested against the respective counterparts of the decoder
[21:51:59 CET] <BBB> the full thing, yes, when its done
[21:52:25 CET] <BBB> but component testing is pretty standard, e.g. idct(fdct(bla)) should minimize for error in bla[]
[21:53:08 CET] <BBB> for quant/dequant thats a little harder, but you can model the error with different quantizers and make sure it goes up as expected (towards quant*0.5)
[22:01:55 CET] <Chloe> BBB: I currently test if idct(fdct(bla)) == bla to 12d.p. and thanks for the pointer on how to test the quantizer. Anyway, from now on it's mostly implementing the format and then I'll finish rle/arithmetic coding
[22:46:19 CET] <atomnuker> you can't really get jpeg quantization wrong, its scalar
[22:46:47 CET] <atomnuker> and you can't get rle coding slightly wrong, if its wrong you'll desync by alot
[22:48:37 CET] <rcombs> challenge accepted
[22:49:17 CET] <JEEB> :D
[22:50:53 CET] <atomnuker> BTW Chloe, do you really think you can do arithmetic coding?
[22:51:13 CET] <atomnuker> I tried implementing it for the decoder and it was quite difficult
[22:52:02 CET] <atomnuker> the information from the spec was barely anything and the mozjpeg code was not easy at all to read
[22:52:40 CET] <atomnuker> you'll probably have to use code from an external library and you'll need a lot of effort to make it run
[22:55:17 CET] <BBB> jpeg has arithcoding?
[22:55:28 CET] <TD-Linux> yes but almost no one implements it
[22:55:50 CET] <TD-Linux> it was covered by patents for a long time, plus it was really slow
[22:56:19 CET] <TD-Linux> my system libjpeg has it enabled, but most software that bundles a jpeg decoder doesn't include it (like firefox)
[22:56:30 CET] <BBB> *mind blown*
[22:56:35 CET] <atomnuker> it doesn't save *that* much space as well
[22:57:01 CET] <atomnuker> it'll likely be easier to introduce a new format than to get them to start shipping libjpeg with arithmetic decoding enabled
[22:57:36 CET] <atomnuker> even debian doesn't compile anything with ac enabled
[22:58:33 CET] <rcombs> AV1P when
[22:58:55 CET] <TD-Linux> after video is solved
[22:59:40 CET] <jkqxz> Yeah, there's little point in doing the arithmetic coding unless you really enjoy that sort of thing.  Just do the normal huffman coding which ~all real images use.  (And if you feel like doing something marginally more interesting with that, make the optimal tables for it.)
[22:59:45 CET] <atomnuker> it doesn't have lapping and its either lapping or death now that daala proved what you can do with it
[23:00:12 CET] <TD-Linux> well, daala proved that it worked for still images. it never proved that it worked for video.
[23:00:43 CET] <atomnuker> yes, still images
[23:19:58 CET] <Chloe> atomnuker: I was under the impression it was needed, if I can avoid implementing it that'd be great
[23:20:14 CET] <Chloe> a DCT is enough to get full marks on algorithms/complexity
[23:20:23 CET] <Chloe> even a fuckslow one
[23:20:35 CET] <cone-337> ffmpeg 03Michael Niedermayer 07master:06c143e50577: avformat/mov: Fix integer truncation in mov_read_uuid()
[23:23:47 CET] <Chloe> atomnuker: what encoding does a standard jpeg have then? only rle?
[23:23:56 CET] <Chloe> standard meaning the most common one
[23:24:08 CET] <TD-Linux> huffman
[23:25:01 CET] <Chloe> ah yes ofc
[23:25:50 CET] <atomnuker> you don't even need to make optimal tables, just use the default ones
[23:26:39 CET] <Chloe> atomnuker: the spec have tables?
[23:28:32 CET] <atomnuker> yeah, for luma and chroma
[23:28:56 CET] <Chloe> oh for quantization?
[23:29:38 CET] <jkqxz> See annex K.  It's kindof presented as an example, but actually ~everyone just uses those.
[23:31:11 CET] <Chloe> yep, I have both those tables for quantization.
[23:31:16 CET] <Chloe> oh nice, it has huffman tables too
[23:31:42 CET] <JEEB> yup
[23:31:45 CET] <Chloe> I guess I can hardcode those
[00:00:00 CET] --- Tue Jan 31 2017