| 00:01.08 | file | entirely possible |
| 00:02.54 | seanbright | i remember when the internet was altruistic |
| 00:03.01 | seanbright | seems like so long ago |
| 00:08.51 | seanbright | now that's bizarre - see #asterisk |
| 00:08.55 | seanbright | re: EPERM |
| 00:49.12 | *** join/#asterisk-dev Gugge (gugge@92.246.2.105) |
| 01:34.31 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 01:45.12 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 02:19.25 | *** join/#asterisk-dev dandann00dle (~dandann00@12.150.125.37) |
| 02:19.30 | *** join/#asterisk-dev dcollins0 (~dandann00@12.150.125.37) |
| 02:22.20 | *** join/#asterisk-dev dandann00dle (~dandann00@12.150.125.37) |
| 03:19.05 | *** join/#asterisk-dev Gugge (gugge@92.246.2.105) |
| 03:46.14 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:56.50 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:06.12 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:20.19 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:10.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:19.51 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:45.34 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:28.24 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:30.39 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 08:41.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 08:41.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:53.48 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 08:53.48 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:27.43 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 09:27.43 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:48.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 09:48.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:54.22 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 09:54.22 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 10:21.10 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 10:21.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 10:34.41 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 10:34.41 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:06.51 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 11:16.08 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 11:16.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:16.33 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 11:23.55 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 11:23.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:32.22 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 11:32.22 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:41.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 11:41.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:11.27 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 12:11.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:23.32 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 12:23.32 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:36.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 12:36.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:43.36 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 12:43.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:59.47 | pchero_work | test |
| 13:10.34 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:10.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:39.45 | *** join/#asterisk-dev Corydon76 (~quassel@zett.abyt.es) |
| 13:39.45 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 13:43.33 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 13:43.33 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 13:53.17 | *** join/#asterisk-dev dandann00dle (~dandann00@174.47.51.123) |
| 13:56.04 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 13:56.04 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:11.29 | seanbright | gtjoseph: there is already a 0030-... patch in master |
| 14:11.32 | seanbright | should i move mine to 0040? |
| 14:11.40 | gtjoseph | hmmm |
| 14:11.49 | gtjoseph | that's weird |
| 14:11.56 | seanbright | 0030-allow-disabling-of-conne |
| 14:12.54 | seanbright | i mean, they don't touch the same code, so i don't see why having them both be 0030 would be a problem in practive |
| 14:12.58 | seanbright | practice* |
| 14:13.32 | gtjoseph | yeha i'm not concerned about conflict. i'm just wondering why we're not consistent across branches. |
| 14:13.46 | seanbright | because the ones in master are feature changes |
| 14:13.51 | seanbright | not bug fixes |
| 14:14.02 | gtjoseph | still it's a pjproject patch |
| 14:14.10 | seanbright | true |
| 14:14.51 | seanbright | well, your call. let me know what you want me to do. |
| 14:15.09 | gtjoseph | hmmm. so no issues with yours i think but we probably should backport nick french's patch at some point |
| 14:15.41 | seanbright | did his end up in pjproject? |
| 14:15.52 | seanbright | i think by the time it will matter we'll be on 2.9 |
| 14:16.18 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 14:16.18 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:16.30 | seanbright | may 1 is the scheduled release date of 2.9 |
| 14:16.40 | gtjoseph | yeah. we don't add things to bundled until they've been accepted upstream |
| 14:16.52 | seanbright | ok, then i think it's a non-issue |
| 14:16.54 | gtjoseph | yeah we're fine until then |
| 14:17.00 | seanbright | when do we branch 17? |
| 14:17.09 | gtjoseph | probably july sometime |
| 14:17.18 | seanbright | good deal. |
| 14:17.38 | seanbright | my girlfriend is 17. what a conincidence. |
| 14:17.45 | gtjoseph | heh |
| 14:17.49 | seanbright | don't tell my wife |
| 14:17.50 | seanbright | or the cops |
| 14:17.57 | gtjoseph | what state do you live in? |
| 14:18.05 | seanbright | one of them |
| 14:18.13 | seanbright | one of the original 13 colonies |
| 14:18.20 | seanbright | the old line state |
| 14:18.36 | seanbright | home to the 1983 world series winning baltimore orioles |
| 14:18.53 | seanbright | starts with an M and ends with a D |
| 14:18.58 | seanbright | rhymes with Schmaryland |
| 14:19.09 | gtjoseph | Delaware? |
| 14:19.17 | seanbright | yes! |
| 14:19.19 | seanbright | good pull |
| 14:28.05 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 14:36.47 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 14:36.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:42.17 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-vymlcaoaobvvsxoz) |
| 14:42.17 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:47.19 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-jjbralgtmydfdfpy) |
| 14:47.19 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:12.08 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:12.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:16.27 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-solikuiozixdjljd) |
| 15:16.27 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:23.10 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:23.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:29.50 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:29.51 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:42.11 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:42.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:07.07 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 16:07.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:16.08 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 16:16.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:20.22 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:24.54 | bford | if anyone has some time to give some feedback on https://gerrit.asterisk.org/c/repotools/+/10941 and https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt i'd appreciate it! |
| 16:41.59 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:51.51 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:57.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 16:58.17 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 16:58.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:11.38 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 17:11.38 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:25.02 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 17:32.34 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 17:32.34 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 17:52.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:53.09 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 18:04.23 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 18:04.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:11.47 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 18:11.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:12.54 | seanbright | kharwell: i'm asking because i honestly don't know - does that change present ABI issues? |
| 18:14.09 | kharwell | I wondered that too. I figured no since it was at the end of the struct. However it is changing the size of the already existing value. |
| 18:14.14 | kharwell | Hrm can't say 100% sure then |
| 18:14.23 | gtjoseph | yeah i was just going to ask that on the review |
| 18:14.37 | file | hrm |
| 18:14.38 | file | yeah |
| 18:14.56 | gtjoseph | whether it breaks or not will depend on the endianess |
| 18:15.05 | gtjoseph | of the builder |
| 18:15.16 | seanbright | the real question is this - how many third party out-of-tree modules are using that structure? |
| 18:15.29 | seanbright | (i know that isn't a GOOD question, but i think it is a reasonable one) |
| 18:15.52 | seanbright | i would be willing to put money on the answer being "zero" |
| 18:16.38 | gtjoseph | so if you win powerball tonight would you be willing to sign it all over to me? |
| 18:16.50 | seanbright | absolutely |
| 18:16.59 | seanbright | considering i don't play the powerball that is an easy decision |
| 18:17.17 | seanbright | isn't there a "new thing" that is not remb anyway? |
| 18:17.28 | gtjoseph | heh. don't go there |
| 18:17.47 | gtjoseph | file has 'splained to us... "no" |
| 18:18.00 | seanbright | "sender side bandwidth estimation based on RTCP Transport Feedback messages" |
| 18:18.02 | file | it's a mess |
| 18:18.21 | file | transport-cc can be used to provide better feedback to the browser so it can calculate better |
| 18:18.29 | file | you still need REMB in order to cap/limit |
| 18:19.09 | file | TMMBR/TMMBN was supposed to help with this stuff, but it seems as though the browsers just shrugged |
| 18:19.32 | file | (I did some investigation and talking this morning) |
| 18:19.38 | seanbright | gotcha |
| 18:19.46 | seanbright | when will the webcast be up? |
| 18:19.55 | file | seanbright: pfft |
| 18:19.58 | file | seanbright: come to my TED Talk! |
| 18:19.59 | file | :P |
| 18:20.08 | seanbright | ok, so this is what we do |
| 18:20.24 | seanbright | rather than using a uint64_t, we using 2 uint32_ts |
| 18:20.54 | seanbright | low order bits go in the first one, high order in the second one |
| 18:21.12 | seanbright | then in the consuming code we munge into a uint64_t |
| 18:21.23 | seanbright | it's almost too easy |
| 18:21.44 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 18:21.53 | gtjoseph | well, that's one way to skin the cat |
| 18:22.02 | seanbright | OR... OR... and hear me out |
| 18:22.03 | kharwell | how does one transfer a patch to someone else in gerrit? |
| 18:22.17 | seanbright | we just change it to a 64 bit number and ask for forgiveness later |
| 18:22.20 | kharwell | *ownership that is |
| 18:22.26 | seanbright | don't transfer it to me |
| 18:22.35 | seanbright | changes his name |
| 18:22.49 | kharwell | worth a try |
| 18:23.05 | gtjoseph | hmmm. can we do it with a union? |
| 18:23.11 | gtjoseph | maybe not. |
| 18:23.35 | seanbright | i'd have to see how it was used. do we return it from our API or consume it via our API? |
| 18:24.08 | kharwell | actually now looking at the code the "ast_rtp_rtcp_feedback" struct uses the ast_rtp_rtcp_feedback_remb struct in a union as it's last value, so ABI prob broken there too |
| 18:24.11 | file | kharwell: so refresh my memory on what the browser stores it as |
| 18:24.52 | kharwell | prob easiest to see the pic: https://tools.ietf.org/id/draft-alvestrand-rmcat-remb-03.html but it's an 18 bit value |
| 18:25.00 | kharwell | the mantissa that is |
| 18:25.09 | seanbright | 18 < 32 |
| 18:25.20 | seanbright | just so we're all caught up |
| 18:25.50 | kharwell | values over 18-bits (> 0x3fff) get shifted and the BR exp gets increased by one |
| 18:26.18 | kharwell | so the bitrate can be over the max 18 bit storage value |
| 18:26.35 | gtjoseph | so i'm confused |
| 18:26.47 | gtjoseph | by the need for the uint64 |
| 18:27.01 | seanbright | in that picture it uses 24 bits total |
| 18:27.09 | gtjoseph | yeah |
| 18:27.21 | seanbright | so are we unpacking it into an int? |
| 18:27.25 | seanbright | err, integer |
| 18:28.14 | seanbright | so if BR Exp is high, we overflow a 32 bit int |
| 18:28.23 | kharwell | hrm actually you know what I need to double check the code. maybe the value in that struct doesn't need to be increased. maybe just the packing/unpacking sections in softmix |
| 18:29.04 | seanbright | this is the time that i wished i understood FP |
| 18:29.09 | kharwell | yeah the "ones" get shifted off the "high" end of the integer |
| 18:29.14 | seanbright | mantissa... that's not even a word |
| 18:29.52 | file | mantissa lost any meaning it had when I was writing the code |
| 18:29.54 | seanbright | well we should just never store it as an integer |
| 18:30.16 | seanbright | actually, i have not looked at the code so i shouldn't really comment |
| 18:30.18 | seanbright | let me look |
| 18:31.55 | seanbright | yeah, i'm confused |
| 18:32.23 | seanbright | i don't see how we'd ever need more than 18 bits for br_mantissa, unless we are abusing it in some way |
| 18:32.26 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.107) |
| 18:32.57 | kharwell | yeah looking back I think you are right |
| 18:34.51 | kharwell | wait no. At one point in softmix it gets set to the stored bitrate, which could be greater than 18-bits |
| 18:35.17 | kharwell | in softmix in remb_send_report: sc->remb_collector->feedback.remb.br_mantissa = sc->remb_collector->bitrate; |
| 18:35.31 | gtjoseph | ew |
| 18:35.43 | file | fix it, fix it, fix it |
| 18:35.45 | kharwell | however could prob change that |
| 18:36.01 | kharwell | and avoid the change to the public api side of things |
| 18:36.20 | gtjoseph | so are we not using br_exp at all?? |
| 18:36.23 | file | that'd be preferred |
| 18:37.08 | kharwell | gtjoseph: we are using it. It's just in this case the br_mantissa is being used as a holder value for calculations and it potentially holds too large a value |
| 18:37.19 | gtjoseph | ew |
| 18:37.50 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 18:37.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:37.50 | file | that shouldn't be that difficult of a fix |
| 18:37.58 | kharwell | nah |
| 18:42.18 | gtjoseph | so considering fb_exp is 0 - 63 do we need to be using a long long (128 bits) to manipulate it?? |
| 18:42.37 | gtjoseph | :) |
| 18:43.08 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 18:43.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 18:44.38 | kharwell | heh probably? Do we already have the compiler checks for it or need them? |
| 18:44.50 | file | long long, so long |
| 18:45.23 | kharwell | prob would want to use uint128_t though? |
| 18:45.31 | seanbright | what type is sc->remb_collector->bitrate |
| 18:45.36 | gtjoseph | or maybe just a double |
| 18:45.38 | gtjoseph | heh |
| 18:45.46 | file | unsigned int |
| 18:46.27 | seanbright | ok, so that is the maximum value we support for bitrate |
| 18:46.32 | seanbright | unless i am not understanding |
| 18:47.24 | gtjoseph | but that's not the max the spec says. what if we get an exponent of 35? |
| 18:47.54 | seanbright | well then remb_collector->bitrate can't be an int |
| 18:48.17 | seanbright | can't we just steal chrome code? |
| 18:48.19 | seanbright | heh |
| 18:49.14 | seanbright | so: bitrate = pow(br_mantissa, br_exp) |
| 18:49.16 | seanbright | is that correct? |
| 18:49.35 | gtjoseph | uhm |
| 18:49.37 | kharwell | should be able to represent an 81 bit integer correct? 18 total bits for the base mantissa. Anything greater gets shifted and up to 63 times, so 18 + 63 = 81 |
| 18:49.56 | gtjoseph | but then you've lost all precision |
| 18:50.01 | seanbright | well that's how FP works |
| 18:50.10 | gtjoseph | it should be mantissa * 2 ** exp |
| 18:51.08 | gtjoseph | next year file will probably be able to overrun a uint32 :) |
| 18:51.16 | file | ha |
| 18:51.32 | seanbright | could we use a double and then extract the relevant bits? |
| 18:51.39 | file | Chrome at least settles a max of 1.7Mbps for encoding |
| 18:51.40 | file | so shrug |
| 18:51.51 | gtjoseph | i suggested the double earlier |
| 18:51.58 | seanbright | you did |
| 18:52.02 | seanbright | i'm circling back |
| 18:52.21 | gtjoseph | 1.7m ??? |
| 18:52.26 | gtjoseph | that seems very low |
| 18:52.48 | file | shrugs |
| 18:52.57 | file | that's what I've seen it max out at |
| 18:53.11 | gtjoseph | are we going down the "remove the '" path?? |
| 18:53.27 | seanbright | so a standard float (32 bit) has 8 bits of exponent and 23 bits of mantissa |
| 18:53.33 | seanbright | (and 1 for sign, but who cares) |
| 18:54.19 | csavinovich | 18 bits of mantissa and 6 bits of exponent |
| 18:55.58 | seanbright | ok |
| 18:56.12 | seanbright | not sure if that was directed at me or not |
| 18:56.23 | csavinovich | to the group |
| 18:56.26 | seanbright | gotcha |
| 18:57.15 | kharwell | seanbright: ah so a float should be able to hold it |
| 18:57.29 | seanbright | yes |
| 18:57.53 | seanbright | applying the exp and mantissa is not simple exponentiation |
| 18:57.58 | seanbright | https://fabiensanglard.net/floating_point_visually_explained/ |
| 18:58.01 | seanbright | good read |
| 18:58.07 | kharwell | should I make a double you know for the year 2000 |
| 18:58.57 | seanbright | so each time you bump the exp by 1 you are changing the range of values that the float can represent |
| 18:59.07 | seanbright | and the mantissa is a slot within that range |
| 19:00.03 | kharwell | looks like I gots me some reading to do |
| 19:00.20 | seanbright | just scroll down to the "A different way to explain..." section |
| 19:00.46 | seanbright | a 32 bit float has a shit ton more range than a 32 bit int at the expense of precision |
| 19:01.36 | kharwell | makes sense. |
| 19:01.50 | seanbright | pardon the technical jargon there |
| 19:01.55 | seanbright | "shit ton" |
| 19:02.21 | seanbright | so converting from actual bitrate to the 6/18 format will be lossy |
| 19:02.27 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:02.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:02.42 | seanbright | but that's the spec |
| 19:03.15 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 19:08.44 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:08.44 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:10.13 | *** join/#asterisk-dev libardi (~libardi@201.53.215.24) |
| 19:12.23 | seanbright | of course i have no idea how to convert an integer into an arbitrarily sized FP number |
| 19:16.35 | kharwell | yeah will have to look into how myself |
| 19:17.19 | seanbright | it's also possible i am making it too complicated |
| 19:17.28 | seanbright | file: where's the chrome code? |
| 19:19.15 | file | WHAT |
| 19:19.18 | file | somewhere in chromium? |
| 19:19.24 | file | if you search for REMB you'll find it :P |
| 19:19.24 | seanbright | thought you had looked at it |
| 19:19.28 | seanbright | fantastic |
| 19:20.52 | file | months, months, months ago briefly |
| 19:22.11 | seanbright | kharwell: https://webrtc.googlesource.com/src/+/refs/heads/master/modules/rtp_rtcp/source/rtcp_packet/remb.cc |
| 19:22.14 | seanbright | cheat a little |
| 19:22.15 | seanbright | i won't tell |
| 19:22.23 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:22.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:23.19 | seanbright | https://webrtc.googlesource.com/src/+/refs/heads/master/modules/rtp_rtcp/source/rtcp_packet/remb.cc#125 |
| 19:23.23 | seanbright | and there you go |
| 19:23.24 | seanbright | NEXT |
| 19:24.10 | seanbright | they store bitrate_bps_ as a uint64_t |
| 19:26.10 | kharwell | so what you are saying is we can potentially be more standard compliant than chrome |
| 19:26.30 | file | doesn't take much |
| 19:26.33 | file | did I say that out loud? |
| 19:26.49 | seanbright | well |
| 19:27.39 | seanbright | 2^62 = 18446744073709551616bps |
| 19:28.04 | seanbright | (64 i mean) |
| 19:28.32 | seanbright | which is 18446700 Tbps |
| 19:28.44 | cresl1n | I want that bandwidth |
| 19:28.45 | seanbright | so i _think_ 64 bits is plenty |
| 19:29.39 | kharwell | seanbright: what about 50 years from now when we have petabyte pipes |
| 19:29.42 | seanbright | they check for overflow too, which is kind of them |
| 19:29.53 | seanbright | kharwell: with any luck i'll be dead by then |
| 19:30.15 | cresl1n | relevant. |
| 19:30.17 | seanbright | i'm a pack-a-day smoker, no way i'm making 90 |
| 19:30.27 | gtjoseph | peta byte = being bitten by a member of PETA |
| 19:30.43 | kharwell | I bet you drive a gasoline powered car too |
| 19:31.00 | seanbright | i also question the necessity for anything remotely that high for this application |
| 19:31.05 | seanbright | like... ever |
| 19:31.44 | seanbright | like... what is the bandwidth of the highest quality video available today? |
| 19:32.10 | seanbright | hdmi is 48 Gbps |
| 19:32.22 | file | ha |
| 19:33.04 | seanbright | which can be represented with a 36 bit integer |
| 19:34.17 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:34.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:47.42 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:47.42 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:55.21 | seanbright | cresl1n: i found a security issue in the wiki - how much is it worth to you? |
| 19:55.49 | cresl1n | I don't want to talk abou tit |
| 19:55.53 | cresl1n | :-P |
| 19:57.06 | seanbright | pfft |
| 19:57.09 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:57.09 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:57.49 | file | cresl1n: how about in JIRA? |
| 19:57.51 | file | :P |
| 19:58.33 | cresl1n | meanie |
| 19:58.49 | seanbright | file: you're trolling abilities have come so far under my tutelage |
| 20:00.11 | file | I learn from the best of the worst? |
| 20:02.20 | seanbright | i'll take it |
| 20:03.53 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 20:03.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 20:11.11 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 20:11.11 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 20:20.53 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 20:20.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 20:28.49 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:05.32 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 21:05.32 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:13.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 21:13.03 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:13.42 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 21:26.47 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 21:26.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:40.46 | seanbright | kharwell: am i wasting my time refreshing your review waiting for the next patch set? |
| 21:42.32 | kharwell | you are not. I haven't even started really looking back into it |
| 21:43.22 | kharwell | oh sorry I misread. yeah prob so |
| 21:43.26 | seanbright | well then. i stayed late for no reason. |
| 21:43.32 | seanbright | i blame you. |
| 21:43.46 | kharwell | redirects blame to file |
| 21:44.02 | file | feel free |
| 21:44.07 | file | I'm done work, blame me for everything! |
| 21:45.10 | kharwell | seanbright: at the rate I am going it'll prob be tomorrow. Well one always hopes |
| 21:45.24 | seanbright | that's cool |
| 21:45.29 | seanbright | i'm considering jimmy john's |
| 21:45.48 | file | I opted for a Baconator, as it is Wendy's Wednesday |
| 21:46.08 | kharwell | firehouse > jimmy john's |
| 21:46.24 | seanbright | i don't think there is one local |
| 21:46.26 | file | plus after paying the foundation guy what's $13 more dollars |
| 21:46.29 | seanbright | let me check |
| 21:46.49 | *** join/#asterisk-dev dandann00dle (~dandann00@174.47.51.123) |
| 21:46.59 | file | I think I've only ever had Firehouse... once |
| 21:47.16 | seanbright | 13 miles |
| 21:47.19 | seanbright | gonna pass |
| 21:50.05 | kharwell | actually I can't even remember the last time I had JJ's. Heck if ever. I was thinking of Jersey Mike's |
| 21:50.39 | seanbright | i miss quizno's |
| 21:50.45 | seanbright | most of them around here closed |
| 21:51.12 | file | I wasn't that impressed by Quizno's |
| 21:51.19 | kharwell | seanbright: yeah same. they were pretty tasty |
| 21:51.33 | seanbright | they had the something-something-ranch which was nommy |
| 21:51.48 | file | I found the bread nice, but that was about it |
| 21:51.58 | seanbright | turkey ranch & swiss |
| 21:52.02 | seanbright | mmmm |
| 21:52.07 | seanbright | ok, i'm leaving now BYE |
| 21:52.12 | file | 200 OK |
| 22:00.54 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5196-243.w90-105.abo.wanadoo.fr) |
| 22:03.54 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 22:03.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:15.57 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jjbralgtmydfdfpy) |
| 23:24.08 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 23:34.47 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |