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

[burek]

[00:30:16 CEST] <iive> atomnuker: not only who would report them, but mostly to whom would you report them. copyright is not /was not crimie, so somebody must own the rights and enforce them.
[00:30:32 CEST] <iive> and they did, but a lot later...
[00:50:16 CEST] <iive> imho, the boom of ISP was possible, becasue it was free to just nail ethernet cables wherever you like. The last mile access is still the biggest bottleneck everywhere in the world.
[00:51:51 CEST] <nevcairiel> BtbN: i'm on telekom and i can smtp fine
[00:53:50 CEST] <nevcairiel> a quick google suggests its just their router, not actually their network
[00:53:57 CEST] <nevcairiel> who uses speedports anyway
[00:54:15 CEST] <nevcairiel> (and apparently an option you can turn off)
[00:54:32 CEST] <rcombs> in the US everybody uses HFC (DOCSIS)
[00:55:39 CEST] <nevcairiel> its not like I have numbers, but i feel like DSL is more wide spread here
[00:56:40 CEST] <nevcairiel> if anything it has more ISPs offering service, while cable is limited to one national ISP and a few local ones
[00:57:23 CEST] <rcombs> we don't quite have any national ISPs, unless you count dial-up
[00:57:40 CEST] <nevcairiel> US is too  huge, i guess
[00:57:51 CEST] <rcombs> nah, we've got cartels instead
[00:58:20 CEST] <rcombs> they all mark out their territory and nobody steps on each other's toes
[00:58:28 CEST] <rcombs> Comcast, Charter, Time Warner, few others
[00:58:53 CEST] <rcombs> everybody's got some territory and no two of them serve the same area
[00:58:53 CEST] <nevcairiel> not being in competition helps everyone, except the customers
[00:59:25 CEST] <nevcairiel> god beware they would actually have to compete with quality service
[00:59:53 CEST] <rcombs> the only competition is between the cable-TV incumbents (^that group) and the phone incumbents (AT&T, Verizon, and the few other remnants of the AT&T antitrust breakup of yore that they haven't bought back up yet)
[01:00:38 CEST] <rcombs> cable providers use DOCSIS, phone incumbents are a mix of various types of DSL, or& also DOCSIS
[01:01:19 CEST] <nevcairiel> being in a smaller country definitely helps with such things, we have 3 huge mobile carriers that have more or less full coverage, you get a choice in phone and internet service, etc
[01:01:52 CEST] <rcombs> these days e.g. AT&T is moving towards a coax network instead of actual individual phone lines, since whaddayaknow, it's cheaper to have a single line with taps than a huge-ass bundle of individual twisted pairs for individual houses all the way to the node
[01:02:38 CEST] <nevcairiel> (used to be 4 carriers, but the two smaller ones merged)
[01:58:00 CEST] <iive> btw, you can have monopoly with more than 1 copany controlling the market. i've heard that 30% of the market are enough for that.
[01:58:55 CEST] <iive> company...
[01:59:23 CEST] <iive> remember google fiber?
[03:04:33 CEST] <iive> google fiber never made
[03:04:53 CEST] <iive> it
[03:07:02 CEST] <iive> i mean, cartel is more when players on same market "reach an agreement" to play together. But when clients are physically separated and one cannot get service from anybody else, then we have a monopoly
[03:11:14 CEST] <jamrial> michaelni: your arm7 fate clients are running out of disk space and it's making the reports useless
[04:05:58 CEST] <michaelni> jamrial, managed to login after waiting for minutes for a prompt, i think ill make a backup of the fate configs and try to reboot it
[04:07:20 CEST] <jamrial> michaelni: cool
[04:30:12 CEST] <michaelni> seems rebooting ... really slow
[04:39:31 CEST] <michaelni> it rebooted, really funny, the shutdown took like 30min and the startup seems to have been so quick i missed it
[04:40:45 CEST] <michaelni> 14gb disk is 97% full
[04:42:01 CEST] <cone-889> ffmpeg 03Michael Niedermayer 07master:f1baafac7129: avcodec/interplayvideo: Clean up frames on parameter change
[04:50:05 CEST] <michaelni> wonderfull over 5gb of useless kernel images
[07:42:51 CEST] <ubitux> 01:07:08,360 --> 01:07:11,920
[07:42:52 CEST] <ubitux> And that was all <? br /> - I do not remember
[07:42:56 CEST] <ubitux> hello wm4 :D
[07:43:06 CEST] <ubitux> (yeah that one makes no sense)
[07:47:16 CEST] <ubitux> 00:07:35,022 --> 00:07:38,557
[07:47:18 CEST] <ubitux> - Ja sam tvoj seminar natrag <br / > u New Yorku u '91.
[07:48:06 CEST] <ubitux> 00:38:07,760 --> 00:38:09,890
[07:48:08 CEST] <ubitux> Sei tu il medico che...?< br /> Non si ottiene il bambino?
[07:48:10 CEST] <ubitux> yeah anyway
[07:48:13 CEST] <ubitux> wm4: there are some.
[09:25:01 CEST] <wm4> ubitux: so, "<br" whitespace "/" whitespace ">" ?
[09:38:55 CEST] <ubitux> wm4: <
[09:39:15 CEST] <ubitux> wm4: <\s*[Bb][Rr]\s*/\s*>
[09:39:30 CEST] <ubitux> with \s = whitespaces
[09:45:55 CEST] <wm4> so uh why don't you just rewrite it to do generic tag parsing, instead of this special-cased mess intermixed with sscanfs?
[09:53:44 CEST] <ubitux> wm4: just push your br patch
[09:53:57 CEST] <ubitux> if you can add the trailing / support easily, please do
[09:54:01 CEST] <ubitux> otherwise, whatever.
[09:54:53 CEST] <ubitux> i didn't write that decoder in the first place (i wrote one in mplayer though)
[10:00:44 CEST] <wm4> rewriting it might still be worth it though
[10:03:00 CEST] <wm4> the current parser seems to eat that though
[10:03:38 CEST] <wm4> weirdly fails on upperspace characters in the tag
[10:05:33 CEST] <cone-025> ffmpeg 03wm4 07master:f605b56ad9c5: htmlsubtitles: support <br> tag
[10:14:17 CEST] <jkqxz> wm4:  I've no idea; Diego complained about it in some previous code and I just copied it forward.
[10:14:23 CEST] <jkqxz> So, cargo-culting, I guess...
[10:18:10 CEST] <jkqxz> Some previous code = <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_vaapi.c;h=3970726d300600c28c676580cd997f1fc44d8397;hb=HEAD#l29>.
[10:19:51 CEST] <wm4> seems just as unjustified
[12:27:41 CEST] <durandal_1707> peloverde: have you had time to check it out?
[12:51:12 CEST] <J_Darnley> Good god!  I knew passing around these "opaque" structs was bad.  Look at that!  It is altering it!
[12:52:48 CEST] <J_Darnley> Why can't these people just use a normal block based transform?
[12:55:42 CEST] <nevcairiel> normal is another word for boring
[12:57:54 CEST] <J_Darnley> It is another word for understandable
[12:58:01 CEST] <J_Darnley> Even if I have no idea how multiplies, adds, and subs do a frequency transform I can understand what the code is doing
[13:51:46 CEST] <funman> does git bisect need something special to work with the merges?
[13:53:44 CEST] <nevcairiel> There is a script in the tools folder to help with that. But basically just skip commits that are on the wrong side
[14:01:28 CEST] <RiCON> ubitux: hehe https://i.fsbn.eu/YtW8.png (my rss parser removed the <br>)
[14:03:54 CEST] <RiCON> hm, no, seems specific to the atom feed
[14:09:03 CEST] <ubitux> seems to appear fine :p
[14:09:24 CEST] <ubitux> try commiting <script ...> now
[14:10:40 CEST] <RiCON> difference is probably here: http://git.videolan.org/?p=ffmpeg.git;a=rss http://git.videolan.org/?p=ffmpeg.git;a=atom
[14:11:03 CEST] <RiCON> one seems to sanitize the tag, the other doesn't
[14:11:26 CEST] <RiCON> but the one that does sanitize it actually doesn't show it(?)
[14:48:29 CEST] <ubitux> wm4: you may want to poke mateo` about the frame pool; he reintroduced it in lavfi for a & v, i think he wants to work on unifying it with lavc
[14:49:29 CEST] <wm4> sounds like a good idea
[16:15:33 CEST] <wm4> nice, AV_OPT_TYPE_BINARY relies on undefined behavior
[16:29:09 CEST] <J_Darnley> Oh good.
[17:09:26 CEST] <rcombs> wm4: fun, how's that?
[17:13:54 CEST] <wm4> rcombs: the binary option consists of a void*/int pair (the latter to store the length of the allocation), and it simply gets the pointer to the int field via pointer arithmetics
[17:14:01 CEST] <wm4> pretty sure that's Not Allowed
[17:14:48 CEST] <rcombs> afaik that's implementation-defined, not UB
[17:15:07 CEST] <rcombs> the resolution type works the same way (with 2 ints)
[17:15:40 CEST] <wm4> at least with the same type it's slightly safer due to no alignment fun
[17:15:49 CEST] <rcombs> no relevant implementation pads between a pointer and an int (or between 2 ints), so it should be fine
[17:16:22 CEST] <wm4> that sounds too much like "2222not UB by coincidence
[17:16:32 CEST] <wm4> stupid keyboard
[17:17:47 CEST] <rcombs> pretty sure it wouldn't be UB regardless
[17:17:58 CEST] <rcombs> since writing to struct padding isn't UB
[17:18:35 CEST] <rcombs> just, the C standard doesn't provide a guarantee that that code will end up writing to the field it intends to (it could instead write to padding)
[17:18:54 CEST] <rcombs> so, implementation-defined and fine in all supported implementations, but not UB
[17:20:28 CEST] <J_Darnley> I give up.  I've just reimplemented the same shit.  Clearly the coeffs are not going where I thought they were.
[17:28:51 CEST] <wm4> rcombs: I find that surprising
[17:29:17 CEST] <rcombs> well what part of that are you expecting to be UB?
[17:30:18 CEST] <wm4> making assumptions about the struct layout, and even writing to the padding
[17:32:43 CEST] <rcombs> writing to padding has to be legal; else you wouldn't be able to memset() a struct
[17:35:54 CEST] <wm4> memset might be a special case just like memcpy
[17:36:07 CEST] <wm4> and I think in theory memset could be different from default initialization
[17:38:58 CEST] <rcombs> pointer arithmetic can be UB in certain circumstances (going more than 1 past the end of an array)
[17:39:25 CEST] <rcombs> a pointer to a non-array is treated like a pointer to a 1-element array for the purposes of overflow and UB requirements
[17:39:33 CEST] <wm4> and you don't think going from struct member to member is UB?
[17:39:45 CEST] <rcombs> and incrementing to 1 past the end of an array is guaranteed not to overflow and is not UB
[17:40:31 CEST] <rcombs> so incrementing a valid pointer is not UB
[17:44:47 CEST] <rcombs> https://www.securecoding.cert.org/confluence/display/c/ARR37-C.+Do+not+add+or+subtract+an+integer+to+a+pointer+to+a+non-array+object see ARR37-C-EX1
[17:48:18 CEST] <wm4> yeah, but that doesn't mean anything for the next field in a struct
[18:03:58 CEST] <rcombs> it doesn't guarantee that the resulting pointer will be to the next field (that's struct layout, which is implementation-defined), but the arithmetic itself is not UB
[18:14:52 CEST] <wm4> well, dereferencing the pointer to past-the-last-array-element is still UB, even if the pointer is valid
[18:33:39 CEST] <jamrial> ubitux: ping
[19:09:52 CEST] <ubitux> jamrial: pong
[19:12:16 CEST] <jamrial> ubitux: whenever you have time, can you test https://pastebin.com/jwC5Tcd2 ?
[19:12:54 CEST] <jamrial> wrote that blindly, so it may not work at all and need a simple change here and there
[19:13:23 CEST] <ubitux> what is it for? speed attempt?
[19:13:30 CEST] <jamrial> it allows that neon function to work for any value of i between 0 and 63 instead of only a bunch (which are the ones the aac decoder actually needs)
[19:13:59 CEST] <jamrial> it's not really necessary, but would make the checkasm test be more thorough
[19:15:03 CEST] <jamrial> the c version and x86 version i wrote work for all values of i, but that arm one was microoptimized for the specific values the aac decoder currently uses
[19:15:57 CEST] <jamrial> at least with the x86 version, when i tried to implement the same optimization i didn't see any speed improvements, so i suppose the same may happen with this neon one
[19:16:28 CEST] <jamrial> better check in any case, since after all in aarch64 the stereo_interpolate functions didn't perform as expected
[19:20:15 CEST] <ubitux> jamrial: we don't have a test for checkasm for this function
[19:20:33 CEST] <ubitux> didn't you had a patch for this?
[19:21:18 CEST] <ubitux> (it will be easier for me to test)
[19:23:00 CEST] <jamrial> ubitux: https://pastebin.com/hT5dZiKg this tests every value of i, and https://pastebin.com/5iyDhRS7 tests only 3 and 5 (what the aac decoder uses)
[19:23:39 CEST] <jamrial> wrote that back when you first submitted the checkasm test, not sure if they apply cleanly with what you committed
[19:24:40 CEST] <ubitux>    ps_hybrid_synthesis_deint_neon (aacpsdsp.c:166)
[19:24:42 CEST] <ubitux>  - aacpsdsp.hybrid_synthesis_deint [FAILED]
[19:25:31 CEST] <ubitux> (or bus error without your asm modification but that's expected)
[19:25:53 CEST] <jamrial> figures, getting it right blindly the first time is rare :p
[19:26:07 CEST] <ubitux> :)
[19:26:33 CEST] <ubitux> i confirm the "safe" test currently works (without your changes)
[19:26:43 CEST] <jamrial> ok, if you feel like finding what else needs to be done to get it working then i can apply the full range test, otherwise i'll just apply the test for values 3 and 5
[19:27:11 CEST] <ubitux> sorry i don't have time for this currently
[19:27:20 CEST] <jamrial> alright
[19:27:38 CEST] <jamrial> thanks for testing the above anyway
[20:06:44 CEST] <atomnuker> the total amount of threads cannot change during runtime, right?
[20:08:36 CEST] <atomnuker> (more specifically avctx->thread_count)
[20:12:47 CEST] <atomnuker> BBB: supposing you run avctx->execute2 and you'd like to prevent thread contention on a single variable
[20:12:56 CEST] <atomnuker> is there a mutex or something I can use?
[20:13:44 CEST] <BBB> contention?
[20:13:53 CEST] <BBB> you mean multiple access without lock?
[20:14:04 CEST] <BBB> most people would use atomics, but it sounds like you want something else?
[20:15:28 CEST] <nicolas17> what does codec_time_base (as reported by ffprobe -show_streams) aka tbc (as reported by av_dump_format) mean?
[20:15:47 CEST] <nicolas17> it seems to be read from AVStream.codec.time_base, but that's deprecated
[20:15:58 CEST] <atomnuker> BBB: can't, need a mutex or something similar
[20:16:07 CEST] <atomnuker> I have a bufqueue which I can't touch
[20:16:22 CEST] <atomnuker> I could move it outside the avctx->execute and get away without it though
[20:16:36 CEST] <BBB> if possible, move it outside, yes
[20:16:47 CEST] <BBB> Im not sure what you want to do precisely so its hard to suggest something specific
[20:17:20 CEST] <atomnuker> opus can output multiple frames in a single packet
[20:17:29 CEST] <atomnuker> up to 6
[20:18:11 CEST] <atomnuker> I do most of my time dependent analysis before but the majority of the search can be run in separate threads
[20:18:25 CEST] <atomnuker> and quantization and encoding
[20:18:40 CEST] <BBB> right
[20:18:47 CEST] <atomnuker> (actually up to 48 frames per single packet if you go down to 2.5 msec frames)
[20:18:50 CEST] <BBB> I would encourage doing the bufqueue access outside the execute
[20:19:06 CEST] <BBB> execute is primarily designed for having no concurrent access at all within it
[20:19:21 CEST] <BBB> so whatever you do that needs protection needs to be done manually with mutexes and will have significant overhead
[20:21:46 CEST] <durandal_1707> this aac 960/120 mdct is really obnoxious
[20:21:55 CEST] <atomnuker> tell me about it
[20:22:33 CEST] <atomnuker> there's a horrid condition right in the busiest path of the forward mdct
[20:23:05 CEST] <atomnuker> and I'm pretty sure branch prediction gets it 100% wrong 100% of the times and that's why its not that fast
[20:23:24 CEST] <atomnuker> since the prediction depends on a randomly distributed variable from a randomly chosen point in a lookup table
[20:23:53 CEST] <atomnuker> (actually its kinda linear, there's a stride)
[21:36:44 CEST] <cone-353> ffmpeg 03Derek Buitenhuis 07master:99c68861f9c7: concatdec: Do not pass NULL to memcmp
[21:39:55 CEST] <cone-353> ffmpeg 03Ricardo Constantino 07master:3b3501f75cb2: configure: require pkg-config for libvorbis
[22:49:21 CEST] <durandal_1707> atomnuker: you sure mdct15 of 3 aka mdct120 works without artefacts?
[22:49:47 CEST] <atomnuker> yes, absolutely, the opus decoders and encoders use it
[23:02:21 CEST] <BBB> J_Darnley: what happened to the blog post?
[23:16:41 CEST] <peloverde> durandal_1707: where's your sample?
[23:18:31 CEST] <durandal_1707> peloverde: aac samples are on trac.ffmpeg.org/ticket/1407
[23:20:18 CEST] <durandal_1707> another one is linked on wiki.multimedia.cx/index.php/Advanced_Audio_Coding in table of features
[23:22:01 CEST] <durandal_1707> dont use streams they are not properly marked as 960/120
[23:52:06 CEST] <peloverde> durandal_1707: Which of those in the ticket uses only long windows, none of the conformance vectors are lc960 without sbr
[23:55:00 CEST] <durandal_1707> latm from ticket sample have very minimal artifacts mostly long windows
[23:55:38 CEST] <J_Darnley> Gah
[23:56:09 CEST] <J_Darnley> BBB: it was published here http://obe.tv/about-us/obe-blog/item/46
[23:56:49 CEST] <J_Darnley> I swear mirc doesn't flash in the taskbar anymore when I have a highlight
[23:58:26 CEST] <peloverde> durandal_1707: for the latm one i'm just getting errors from demux about codec parameters
[00:00:00 CEST] --- Fri Jul  7 2017