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

[burek]

[00:01:18 CEST] <kurosu> an example of what bitstream.h could look like (expiry 1H): https://pastebin.com/WfPyiLk1
[00:01:33 CEST] <Compn> durandal_1707 : what kind of food ?
[00:03:20 CEST] <kurosu> good night
[00:04:58 CEST] <wm4> iive: a bitstream reader call will access all the bitstream state through pointers, which could be aliased to other pointers, so the compiler has to reload them all the time
[00:05:03 CEST] <wm4> which is probably slower
[00:05:47 CEST] <wm4> which is why performance critical code either puts the reader state on the stack (so the compiler's optimizer can work better), or do explicit caching with those awful macros
[00:12:37 CEST] <atomnuker> kurosu: if you're being choked by contracts preventing you from sharing you can always become an elvis presley
[00:22:53 CEST] <iive> wm4: i see
[00:28:09 CEST] <iive> wm4: however making a local copy is not enough, because the API requires getting pointer to the struct. You need to duplicate the api in order to use struct.member instead of struct->member.
[00:29:06 CEST] <iive> unless the compiler is smart enough to figure it out on its own.
[00:29:20 CEST] <wm4> duplicate the api? wat
[00:30:45 CEST] <iive> nah, i still can't make sense of these aliasing rules.
[00:31:09 CEST] <iive> it doesn't make sense for the compiler to assume the aliasing is always broken
[00:31:32 CEST] <iive> simply because there is C primitive to signal when to assume that.
[00:31:44 CEST] <iive> to signal when that is the case.
[00:35:36 CEST] <iive> Let me say it this way. The compiler always assumes nothing else modifies the structure it is working with.
[00:37:15 CEST] <iive> this is why it complains when you access strcutures with different type, because it breaks its assumption.
[00:43:35 CEST] <iive> well, not always, but at -O2
[00:48:28 CEST] <wm4> well yes that's the reason why other high level languages can be much faster than C (Fortran is a popular example)
[00:49:09 CEST] <wm4> compilers started doing strict aliasing rules for different types to help optimization (which broke code which ignored that rule)
[00:49:23 CEST] <wm4> for for the same types, like int*, it's still a problem
[00:49:28 CEST] <wm4> *but
[01:32:12 CEST] <nevcairiel> atomnuker: sorry i was out, the new api defines two functions for the encoder, one to submit input and  one to generate output, and you can control with return values which should be called next (ie. if you return EAGAIN from send_frame, you  indicate that you are not accepting new input right now, and the user has to call receive_packet a bunch first to get encoded data out)
[01:41:25 CEST] <atomnuker> ah, I didn't think about the return value of encode_frame
[01:42:51 CEST] <atomnuker> wait, when does encode_frame get called, when the user submits frames, right? not when they request packets
[01:43:17 CEST] <nevcairiel> there is no such thing as encode_frame
[01:43:24 CEST] <atomnuker> I mean internally
[01:43:50 CEST] <nevcairiel> there is send_frame which gives your encoder new frames, and receive_packet which gets encoded data out of the encoder
[01:44:11 CEST] <atomnuker> yes, I know how the new api works
[01:44:13 CEST] <nevcairiel> (the public APIs are named similar to those f unctions, with prefixes and whatnot)
[03:04:07 CEST] <cone-838> ffmpeg 03Michael Niedermayer 07master:0b180d2066ed: fate: Add fate-copy-trac3074
[03:51:05 CEST] <cone-838> ffmpeg 03Michael Niedermayer 07master:60a45713e7bc: avcodec/interplayvideo: Check ff_get_buffer() for failure
[05:38:07 CEST] <rcombs> kierank: until about 11:00
[08:37:31 CEST] <kurosu> atomnuker, there are 2 sides to your comment
[08:38:44 CEST] <kurosu> legality-wise, it's one thing to hide from potential harassment a la foo86 (then maybe he signed an NDA to get specs), and to wilfully breach a contract
[08:41:06 CEST] <kurosu> as for the pro-bono side, I prefer not to expand too much on it (a lot of people are doing a lot against it already), but people/companies are way too used to getting stuff for free/chump change (not that a bitstream reader matters to most anyway)
[08:42:59 CEST] <kurosu> bye
[10:12:52 CEST] <durandal_1707> michaelni: i want to add >8 bpp support to geq only if you are willing to relicense it to lgpl
[12:39:35 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:ecc16d893dc0: avfilter/vf_geq: >8 bps support
[12:52:41 CEST] <durandal_1707> michaelni: why are you so against relicensing?
[13:50:26 CEST] <durandal_1707> michaelni: ok if you like to ignore me i gonna remove dupe prores stuff
[13:53:01 CEST] <ubitux> you waited 1h
[13:54:46 CEST] <durandal_1707> yes so i gonna push it in less than one hour
[13:58:24 CEST] <J_Darnley> Argh!  Why the hell isn't ffplay looping?
[14:09:14 CEST] <iive> durandal_1707: what do you want relicensed?
[14:29:45 CEST] <durandal_1707> iive: geq
[14:30:23 CEST] <iive> isn't it lgpl already?
[14:30:57 CEST] <wm4> 1 second of research shows "no"
[14:31:19 CEST] <wm4> not sure why anyone would want this filter though
[14:31:22 CEST] <wm4> using luajit is faster
[14:33:14 CEST] <J_Darnley> atomnuker are you around?
[14:33:16 CEST] <iive> it's from mplayer, i guess this is why.
[14:34:14 CEST] <iive> I also don't see any request for relicensing on the maillist.
[14:34:18 CEST] <atomnuker> J_Darnley: yep
[14:39:50 CEST] <J_Darnley> Good.
[14:40:53 CEST] <J_Darnley> In the decode_hq_slice function of diracdec.c I cannot tell where the dequant coeffs go.
[14:41:14 CEST] <J_Darnley> They go into a buf in the SubBand struct
[14:41:44 CEST] <J_Darnley> Does this move them around for te whole plane transform?
[14:50:27 CEST] <atomnuker> J_Darnley: look for "uint8_t *buf = b1->ibuf + c->top * b1->stride + (c->left << (s->pshift + 1));"
[14:50:39 CEST] <atomnuker> that's where coefficients go
[15:44:42 CEST] <tdjones> atomnuker: Did you possibly have a chance to read the email that I had sent yesterday? I am wondering if you can help me figure out the proper codebooks to include for short windows
[15:48:04 CEST] <atomnuker> tdjones: did you try the libvorbis ones?
[15:52:40 CEST] <tdjones> The problem is that there are several sets of floor books available for 128-sample windows. The documentation for the codebook generator is nonexistant for the difference between each
[15:54:18 CEST] <kierank> J_Darnley: possibly the coefficients are ordered wrong for slice based transform
[15:54:30 CEST] <atomnuker> tdjones: give one a try to see if it works fine
[15:55:12 CEST] <atomnuker> they've probably been optimized for a particular set of samples by a machine
[16:43:44 CEST] <cone-163> ffmpeg 03Max Weber 07master:9e392c6ece8d: libavformat/avformat.h: Move docs inside of #if
[16:43:44 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:de54a37c1dfa: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets
[16:47:13 CEST] <cone-163> ffmpeg 03James Almer 07master:ac8ad8d0981b: x86/sbrdsp: sign extend start and end gprs in ff_sbr_hf_gen_sse
[17:05:31 CEST] <durandal_1707> iive: why would it need to be on ml?
[17:07:17 CEST] <iive> all development is done on the maillist
[17:10:27 CEST] <durandal_1707> iive: like security commits
[17:12:03 CEST] <durandal_1707> michaelni: your security commit broke als decoder, do you have sample that caused 18f94df8af0?
[17:12:41 CEST] <durandal_1707> i run thing under valgrind and it didnt report anything
[17:13:57 CEST] <durandal_1707> so i will revert that incorrect commit if i do not get response soon
[17:18:49 CEST] <iive> durandal_1707: security is done in private to protect users while fix is been worked on. The case with licensing is quite the opposite
[17:20:25 CEST] <durandal_1707> iive: see, you said developement is done on ml
[17:21:48 CEST] <iive> every rule has its exceptions.
[17:22:09 CEST] <kierank> durandal_1707: just put iive on ignore, it's easier that way
[17:23:14 CEST] <durandal_1707> iive: and you have power to tell me when something should be done on ml and when not
[17:23:51 CEST] <iive> i'm not giving orders
[17:24:41 CEST] <iive> but you are behving unreasonable and I'm trying to understand why
[17:24:58 CEST] <durandal_1707> license issues can and should be first told on irc and later on ml
[17:25:12 CEST] <iive> why?
[17:25:31 CEST] <durandal_1707> exp for sole author of one file
[17:26:09 CEST] <iive> well, are you sure he is the sole author of the file? Since it's been in MPlayer, a number of people might have small fixes in there.
[17:26:55 CEST] <durandal_1707> thats why  ask him first and rest later
[17:54:30 CEST] <KGB> [13FFV1] 15dericed opened pull request #73: update to version 03 (06master...06update-to-version-03) 02https://git.io/vQBV4
[18:11:32 CEST] <iive> durandal_1707: well, michael has always preferred email communication. and if you want to ask him personally, maybe ask him in private.
[18:20:27 CEST] <durandal_1707> iive: whats so hard telling: no, no way, yes, never and so on?
[18:25:34 CEST] <RiCON> durandal_1707: could you check if changing to require_pkg_config "vorbisenc vorbis" fixes your config error?
[18:25:44 CEST] <RiCON> to see if ogg is also needed or not
[18:27:32 CEST] <atomnuker> durandal_1707: just ask thilo for samples privately, surely he'll give 'em
[18:29:33 CEST] <iive> durandal_1707: you didn't get answer? from the fragment I saw I kind of assumed you already got rejection....
[18:30:59 CEST] <durandal_1707> RiCON: still same, something is fishy here
[18:33:28 CEST] <RiCON> yeah, nevermind, check_pkg_config doesn't work with multiple .pc
[18:33:54 CEST] <RiCON> patch is probably dropped as vorbisenc.pc only requires vorbis and ogg for --static
[18:45:28 CEST] <durandal_1707> iive: no, its just you
[19:18:18 CEST] <cone-163> ffmpeg 03wm4 07master:ff2d21a58c9c: hevcdec: properly export some side data with frame threading
[19:51:03 CEST] <RiCON> durandal_1707: this should work, but it looks a bit uglier than before http://sprunge.us/gYiS
[20:13:31 CEST] <J_Darnley> This idwt DSP is insanely laid out
[20:14:28 CEST] <atomnuker> yup
[20:14:51 CEST] <atomnuker> the forward transforms are nice though
[20:15:33 CEST] <J_Darnley> This is nice?  I thought the encoder which I failed to write SIMD for was better.
[20:17:40 CEST] <atomnuker> well, yeah, the forward transforms are on the encoder side
[20:18:28 CEST] <atomnuker> and they're nice because they're not split like the decoder's transforms
[20:18:29 CEST] <J_Darnley> That's forwards?
[20:18:32 CEST] <atomnuker> yep
[20:20:12 CEST] Action: J_Darnley hates this
[20:21:02 CEST] <J_Darnley> Why do these contexts hold frame properties?  Why are they not function arguments?
[20:21:36 CEST] <atomnuker> what did they hold? bit depth?
[20:21:45 CEST] <J_Darnley> width, height
[20:30:37 CEST] <kierank> Just use haar, it's simppe
[20:43:44 CEST] <J_Darnley> Simple my arse.  Its all buried behind layers of abstraction.
[20:44:07 CEST] <J_Darnley> Not to mention "which haar?" there's two of them.  Then there's two functions for H and V
[20:47:12 CEST] <durandal_1707> decoder?
[20:47:26 CEST] <J_Darnley> dirac/vc2
[20:51:06 CEST] <durandal_1707> why encoder is not using frame threads?
[21:08:42 CEST] <atomnuker> durandal_1707: dunno, never bothered to make it
[21:08:53 CEST] <atomnuker> if you get it running and its a few lines just push it
[21:44:44 CEST] <durandal_1707> atomnuker: have you filled gsoc report?
[21:46:43 CEST] <atomnuker> yep
[21:46:43 CEST] <kierank> J_Darnley: it's a separable transform
[21:46:53 CEST] <kierank> And there is a variant with a shift and one withour
[21:47:29 CEST] <atomnuker> (the non-shifted one is practically useless)
[21:48:27 CEST] <durandal_1707> this is just arithmetic operations
[22:10:57 CEST] <atomnuker> durandal_1707: am I doing something wrong or is the apad filter not working
[22:11:25 CEST] <atomnuker> -af apad=pad_len=480000 doesn't pad 10 seconds, it does nothing
[22:36:17 CEST] <durandal_1707> atomnuker: give full command
[22:37:11 CEST] <wm4> michaelni: ok to push my hevc commit to release branches? (or do you plan on doing that)
[22:59:51 CEST] <atomnuker> durandal_1707: ffmpeg -i test.wav -t 00:00:02 -af apad=480000 -y t2.wav
[23:00:11 CEST] <atomnuker> test.wav is an hour btw
[23:05:03 CEST] <durandal_1707> atomnuker: i dont think you can mix -t and -af
[23:05:12 CEST] <durandal_1707> use atrim filter
[23:32:03 CEST] <michaelni> wm4, which commit ? i can backport it if you want and assuming it cleanly applies
[23:33:17 CEST] <wm4> ff2d21a58c9c4797ea2d1c4ded09c797abc5a39f
[23:33:41 CEST] <wm4> for older releases it'll require removing sei fields that were not supported yet at the time
[23:40:39 CEST] <michaelni> wm4, do you want to backport it ? iam ok if you just push them
[23:41:42 CEST] <wm4> ok I'll do that later
[23:41:50 CEST] <wm4> which releases are still active?
[23:42:00 CEST] <wm4> and are micro version bumps ok?
[23:53:59 CEST] <michaelni> wm4, the ones listed on the main download page are still active, micro bumps are only ok if the release branch has a seperate minor version from master, the most recent ones should older did not
[23:54:30 CEST] <wm4> ok
[00:00:00 CEST] --- Sat Jul  1 2017