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

[burek]

[00:02:30 CEST] <kierank> atomnuker: what a surprise
[01:14:30 CEST] <Chloe> klaxa: didnt get around to emailing about ffserver today but expect one tomorrow or the day after. (Also who is your mentor?)
[01:14:47 CEST] <klaxa> atomnuker
[01:15:24 CEST] <klaxa> alright thanks for taking the time, i'm currently reading through old mailing list archives to find out how debated this project really was :/
[01:15:46 CEST] <klaxa> and it must even go back further than 2015, it was already a qualification task for outreachy 2014
[01:17:47 CEST] <klaxa> and gsoc 2014
[01:17:53 CEST] <klaxa> even though ffmpeg was not accepted that year
[01:31:51 CEST] <klaxa> gaaaah
[01:32:10 CEST] <klaxa> in 2014 the gsoc page was on wiki.multimedia.cx for some time
[01:32:27 CEST] <klaxa> apparently during that the project was added and later merged back into trac
[01:32:34 CEST] <klaxa> with the history of who added it gone
[01:32:54 CEST] <klaxa> aaah no there is history on the wiki, duh
[01:34:00 CEST] <klaxa> it was nicolas
[01:39:35 CEST] <klaxa> but i can't find any discussion of it in the archives at least not at the time it was relevant (early 2014, early 2015)
[01:41:13 CEST] <klaxa> maybe i didn't look hard enough
[01:49:51 CEST] <klaxa> i just had the idea of maybe using an optional external http library? like, if available and desired use libwhatever and otherwise use the built-in http server?
[01:53:39 CEST] <atomnuker> meh, that'd be worse
[01:54:01 CEST] <klaxa> how so?
[01:56:12 CEST] <atomnuker> ifdeffery, hacks, hidden incompatibilities, no tnx
[01:57:05 CEST] <klaxa> hmmm ok
[07:12:47 CEST] <cone-026> ffmpeg 03guikunzhi 07master:8ea8be595166: fix memory leak of parsing dash MPD
[10:19:52 CEST] <cone-026> ffmpeg 03Steven Liu 07master:798ae8794e84: avformat/dashdec: fix compling warning "filename is deprecated"
[10:22:02 CEST] <JEEB> has anyone seen perf impact post-framesync2 for overlay filter?
[10:22:52 CEST] <JEEB> I will probably try to do some profiling one of these days to verify that's it
[10:27:47 CEST] <durandal_1707> JEEB: what? for vf_overlay.c ?
[10:54:05 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:5b6cc3a73acb: avformat/vpcc: Calculate VP9 level from Luma's Sample rate and Picture size
[10:54:06 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:060e74e2a970: avformat/dashenc: Set VP9 codec string with profile, level and bitdepth
[10:54:07 CEST] <cone-026> ffmpeg 03Karthick Jeyapal 07master:4c27a6fbfde1: avformat/dashenc: Set mp4 as the default format for VP9
[10:55:30 CEST] <Chloe> tmm1: you asked about zvbii think it is needlessly complex
[11:36:59 CEST] <nevcairiel> kierank: durandal_1707: re prores, apparently the 4444 profile is just always 12-bit, while the 422 profiles are 10-bit, if that helps at all
[11:39:38 CEST] <Compn> i wonder how many prores people are using ffmpeg now
[11:39:56 CEST] <Compn> i didnt realize it was such a big codec
[11:40:46 CEST] <BtbN> I used prores once because it was the only codec that supports an alpha channel that fits into mp4
[11:41:16 CEST] <BtbN> It created a ridiculously big 200MB file for a few seconds long clip, but it worked
[11:41:36 CEST] <Compn> https://support.apple.com/en-us/HT200321
[11:41:46 CEST] <Compn> Unauthorized codec implementations
[11:41:46 CEST] <Compn> In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability. If you're using or considering the purchase of a product that encodes or decodes ProRes but isn't on the list below, please contact us at ProRes at apple.com.
[11:41:47 CEST] <Compn> ehehe
[11:42:02 CEST] <Compn> apple nailed us
[11:42:16 CEST] <BtbN> ffmpeg has like 10 different prores encoders as well
[11:42:18 CEST] <nevcairiel> they are just annoyed that they cant charge license fees
[11:42:29 CEST] <BtbN> it's rather confusing. Only some of them support alpha
[11:43:05 CEST] <nevcairiel> there is only two, and one of them supports 4444, one doesnt
[11:43:08 CEST] <Compn> BtbN : good point, do any of the various encoders have docs that explain which one supports alpha? if not we should improve the docs
[11:43:26 CEST] <BtbN> No idea, I just looked at the source right away
[11:43:36 CEST] <Compn> ehe
[11:43:53 CEST] <nevcairiel> one of them hasnt been touched since 2015 more or less
[11:43:57 CEST] <nevcairiel> it should probably just be dropped
[11:44:11 CEST] <Chloe> Why has it not been dropped
[11:44:25 CEST] <nevcairiel> usual reasons
[11:44:26 CEST] <BtbN> Because nobody cared enough to send a patch
[11:45:06 CEST] <Compn> send patch and then we get complaints after its removed :D
[11:45:10 CEST] <nevcairiel> paul send a patch, but the usual bike-sheeding ensued
[11:46:31 CEST] <Compn> also, at the time, it was difficult to see which one would succeed
[11:46:35 CEST] <Compn> and which one would be abandoned
[11:46:50 CEST] <Chloe> I will rebase his patch and enact anti-bikeshedding order #3732, if durandal_1707 doesnt want to it himself
[11:46:54 CEST] <Compn> and also no one cared to compare them, and they had different features (although that was sync'd long ago iirc)
[11:47:12 CEST] <nevcairiel> the _ks variant has more features these days
[11:47:19 CEST] <Compn> Chloe : that would be useful, as you are new to bikeshedding and may handle it differently
[11:48:38 CEST] <Compn> Chloe : also it maybe good idea to alias the prores name you remove to the other one. e.g. for old scripts that use -prores_anatoly or whatever , have it automatically use the encoder still in
[11:49:07 CEST] <nevcairiel> anatoly was the old default, its unlikely anyone accessed it directly
[11:49:24 CEST] <Compn> those apple users are weird :P
[11:49:34 CEST] <Compn> also the archivists
[11:49:46 CEST] <Compn> but they will already be angry we removed it :P
[11:49:46 CEST] <Chloe> Compn: Id hardly say Im new to bikeshedding... but yes, compatibility should be kept as much as required
[11:50:10 CEST] <Chloe> Clearly they should just use ffv1
[11:50:11 CEST] <Compn> Chloe : you are experienced with ffmpeg bikeshedding already? :)
[11:50:36 CEST] <Chloe> Compn: I did sdl2 and the new iter api
[11:50:52 CEST] <Compn> oh what fun :)
[11:51:34 CEST] <Chloe> I didnt manage to get the opengl output device to be dropped though
[11:51:44 CEST] <Chloe> Maybe Ill also resend a patch for that
[11:53:45 CEST] <durandal_1707> no, please no
[11:53:49 CEST] <durandal_1707> lavd needs new api
[11:54:39 CEST] <Compn> i like idea of opengl output
[11:54:52 CEST] <Compn> ffmpeg can finally absorb mplayer :)
[11:55:15 CEST] <Compn> now just need binary codec loader....
[11:55:54 CEST] <Chloe> Compn: why does it need to be in the libraries
[11:56:06 CEST] <Compn> why what need to be where ?
[11:56:13 CEST] <Chloe> Why does libavdevice need a renderer
[11:56:23 CEST] <Chloe> (Hint: it doesnt)
[11:56:42 CEST] <Compn> i didnt say it had to be in libraries
[11:57:04 CEST] <Chloe> Compn: well it is currently in the library
[11:57:16 CEST] <Chloe> And thats the issue
[11:57:25 CEST] <Compn> i dont mind if you change it :)
[11:57:58 CEST] <Chloe> durandal_1707: yes. I really want to do it, but I dont have hardware to test the major devices in lavd
[12:01:41 CEST] <Chloe> durandal_1707: also why you against removing lavd components if you want a new api? The less components there are the easier it is
[12:08:34 CEST] <Compn> interesting looks like a lot of articles of people using ffmpeg to convert 4k stuff to 1080 :D
[12:10:25 CEST] <Chloe> Compn: which filter they suggesting?
[12:12:06 CEST] <Compn> averaging area in one article
[12:12:09 CEST] <Compn> lets see the other
[12:12:36 CEST] <Compn> oh im not getting proper google results these pages might be outdated
[12:13:37 CEST] <Compn> other article uses a frontend with different names for filters
[13:23:00 CEST] <Chloe> 'I was wondering if there is any chance to move development to github?'
[13:32:43 CEST] <durandal_1707> Chloe: how would you move fate tests?
[13:35:00 CEST] <durandal_1707> gonna remove another prores decoder NOW! you can not stop me!
[13:35:53 CEST] <durandal_1707> i wrote 12bit prores support, but than i found out that we have 2 decoders, so i need to add this support for both of them?
[13:36:47 CEST] <durandal_1707> also there is no asm for 12 bit simple idct, i wrote asm for 12bit prores, but it was not bitexact as it used 10 bit idct
[13:37:30 CEST] <durandal_1707> and i can not really do only C version as asm one have different idct permutation
[13:43:42 CEST] <wm4> durandal_1707: post some numbers and the decision is clear
[13:44:47 CEST] <wm4> klaxa: in the end I'd say do what you feel like doing
[13:45:16 CEST] <wm4> that'll probably lead to the best outcome anyway
[13:45:50 CEST] <wm4> or at least I think that's how it should go
[13:46:06 CEST] <cone-026> ffmpeg 03Carl Eugen Hoyos 07master:3914a76db687: lavf/rtmpcrypt: Add a cast to silence an unavoidable warning.
[13:46:10 CEST] <wm4> if you want to extend/improve the native http server, go ahead; if you found a nice external lib you'd like to use, go ahead
[13:48:44 CEST] <Chloe> klaxa: yeah, in the end wm4 is right but I would recommend at least looking at the nginx module i linked (maybe you could just extend that)
[13:49:01 CEST] <durandal_1707> wm4: this is about decoder - they give same results with same speed
[13:49:34 CEST] <wm4> wait so we have multiple prores encoders and decoders or what
[13:49:49 CEST] <nevcairiel> two of both
[13:49:52 CEST] <wm4>  DEVIL. prores               Apple ProRes (iCodec Pro) (decoders: prores prores_lgpl ) (encoders: prores prores_aw prores_ks )
[13:49:58 CEST] <wm4> 2 decoders 3 encoders
[13:50:04 CEST] <wm4> heh
[13:50:05 CEST] <nevcairiel> two of t hose encoders are the same one
[13:50:10 CEST] <wm4> ah
[13:50:16 CEST] <nevcairiel> prores is prores_aw
[13:50:57 CEST] <wm4> I guess decoders are easier to compare
[13:51:27 CEST] <wm4> durandal_1707: how is one of them better?
[13:53:30 CEST] <durandal_1707> decoders give same output, just one code is prettier than other
[13:53:55 CEST] <wm4> seems like a good reason
[13:54:10 CEST] <durandal_1707> and prores_lgpl had more features until carl copy pasted code to aw decoder
[13:54:23 CEST] <nevcairiel> are they the same license now? same speed?
[13:54:58 CEST] <durandal_1707> see git history, it is one huge mess of renaming and relicensing
[14:01:33 CEST] <durandal_1707> for speed i need to check again
[14:06:27 CEST] <Chloe> durandal_1707: youd just move the repo, the fate tests would still have to be somewhere else, but its not really practical anyway
[15:42:42 CEST] <jamrial> wow, the mailman version used for ffmpeg-devel not only fucks up pgp signed email by Thunderbird+enigmail, but also by Apple Mail
[15:43:03 CEST] <BtbN> Never had an issue with that
[15:43:16 CEST] <jamrial> the only mulitpart mails i see that don't get runied by mailman scrambling it are from mutt
[15:43:53 CEST] <jamrial> BtbN: look at the github thread, jdarnley's and Daniel Oberhoff's mails
[15:44:34 CEST] <jamrial> then look at Nicolas'
[15:44:37 CEST] <jamrial> or any email by michaelni
[15:45:22 CEST] <jdarnley> Time I finally went to mutt?
[15:46:12 CEST] <jamrial> mailman doesn't play nice with some specific kind of mulitpart emails at the time of adding the list signature attachment
[15:46:33 CEST] <jamrial> and it scrambles the original email contents, making the pgp signature invalid
[15:47:33 CEST] <jamrial> who manages the server running mailman? maybe this was addressed in a more recent version...
[15:47:42 CEST] <BtbN> jamrial, I don't see any issues?
[15:47:54 CEST] <BtbN> Or difference between their mails
[15:48:11 CEST] <jamrial> BtbN: do the pgp signatures in those emails show up as valid for you?
[15:48:20 CEST] <BtbN> They all tell me "Parts of this message are signed"
[15:48:24 CEST] <BtbN> and then highlights which parts
[15:48:41 CEST] <wm4> heh the mkvtoolnix gitlab link isn't loading for many people
[15:49:05 CEST] <j-b> gitlab is mostly down today or very very slow
[15:49:13 CEST] <jamrial> BtbN: using thunderbird? is that message in a yellowish bar?
[15:49:31 CEST] <BtbN> jamrial, Blueish-Bar now, since I imported the keys
[15:49:37 CEST] <BtbN> but yes, Thunderbird with Enigmail
[15:50:57 CEST] <jamrial> BtbN: for jdarnley and Daniel's email, i get a yellowish bar saying "Parts of this message are signed", then when i click on security info, i see "BAD signature from [...]"
[15:50:58 CEST] <BtbN> there is only one mail of them that has an invalid signature, the 14:41 CEST one
[15:51:13 CEST] <BtbN> (last one from Danial in the github thread)
[15:51:17 CEST] <BtbN> the other ones verify successfully
[15:51:26 CEST] <jamrial> Nicolas and michaelni emails are blueish, and it says "Good signature"
[15:51:37 CEST] <wm4> j-b: apparently it's really hard to setup gitlab, and it will be slow as shit
[15:51:55 CEST] <wm4> I wonder how videolan is coping
[15:52:38 CEST] <BtbN> jamrial, it only seems to break some mails
[15:52:45 CEST] <BtbN> and I'm tempted to blame thunderbird?
[15:53:28 CEST] <BtbN> Like, the original mail from Danial is fine
[15:53:29 CEST] <jamrial> as in, enigmail parsing them wrong rather than mailman ruining them before delivery?
[15:53:35 CEST] <BtbN> yes
[15:54:00 CEST] <BtbN> Or something, somewhere, strips whitespaces or converts charset
[15:54:06 CEST] <jamrial> so far, every email created by enigmail and passed through mailman doesn't validate for me, and now this one from Apple Mail
[15:54:14 CEST] <jamrial> mutt email is always ok
[15:54:23 CEST] <BtbN> then most of his mails are unsiged, the original from him in github is fine
[15:54:26 CEST] <BtbN> his last in github is broken
[15:55:04 CEST] <cone-026> ffmpeg 03Derek Buitenhuis 07master:28503c5aea5f: mov: Properly abide by the track's media duration
[15:57:18 CEST] <jamrial> BtbN: guess the only way to confirm this is someone using mutt or some other client confirming they also get bad signature on those mails
[15:57:50 CEST] <BtbN> It also broke my reply to the C++ nvcodec
[15:57:53 CEST] <BtbN> which was just one word
[15:58:11 CEST] <BtbN> unsurprisingly, the one I sent is fine
[15:58:19 CEST] <BtbN> so lets compare the two raw mails
[16:02:29 CEST] <BtbN> jamrial, this is confusing. I saves the raw mail that's broken, and the "ffmpeg-devel mailing list" footer isn't even in there
[16:03:16 CEST] <jamrial> BtbN: it should be at the end, in base64
[16:03:31 CEST] <BtbN> oh, indeed
[16:03:34 CEST] <BtbN> why is it base64
[16:09:05 CEST] <ubitux> i'll apply the AV_OPT_FLAG_DEPRECATED and its associated http patch tonight
[16:09:20 CEST] <ubitux> along with thread message queue function
[16:09:43 CEST] <ubitux> tonight = ETA ~ h-4
[16:10:55 CEST] <BtbN> jamrial, it's definitely mailman breaking it. Intact signed part: https://bpaste.net/show/1d477460f7cc  What mailman makes of it: https://bpaste.net/show/69df0894253b
[16:11:09 CEST] <BtbN> I'm not 100% sure which parts are signed, but all of them are changed
[16:12:08 CEST] <BtbN> There's also a suspicious line in the headers: X-Content-Filtered-By: Mailman/MimeDel 2.1.20
[16:14:00 CEST] <jamrial> yeah, it doesn't play nice with too many parts, and seems to remove one of the boundaries when it rebuilds the mail to add its own attachment
[16:14:59 CEST] <jamrial> enigmail could admitedly create simpler signed emails, much like mutt, but mailman definitely shouldn't break anything like this
[16:47:50 CEST] <wm4> we should have an avcodec_set_parameters_from_avframe() function
[16:48:05 CEST] <durandal_1707> patch welcome
[16:50:04 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:161e006cc02e: avfilter: add tmix filter
[16:50:05 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:a5172dcab67f: avfilter/vf_mix: add scale option
[16:50:06 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:330215830ef9: avfilter/vf_mix: clip output pixel values
[17:18:13 CEST] <cone-026> ffmpeg 03Jerome Borsboom 07master:02e4970bc9d3: avcodec/vc1: fix out of bounds access of overlap filter
[17:35:58 CEST] <BtbN> hm, I'm not sure about adding more and more stuff to the ffnvcodec headers which are not needed by ffmpeg
[17:36:28 CEST] <atomnuker> its fine if they're optional
[17:36:36 CEST] <BtbN> I'm more concerned license-wise
[17:36:52 CEST] <atomnuker> why?
[17:37:00 CEST] <atomnuker> its lgpl, isn't it?
[17:37:11 CEST] <BtbN> Yes, ours is, because it's a re-implementation
[17:37:25 CEST] <BtbN> If the patch author just straight up copied that from the nvidia headers, which have a restrictive proprietary license, that's a problem.
[17:38:13 CEST] <wm4> mpv uses those headers too
[19:45:52 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:71fa82bed62f: lavu/threadmessage: add av_thread_message_queue_nb_elems()
[19:53:20 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:5be0410cb31c: lavu/opt: add AV_OPT_FLAG_DEPRECATED
[19:53:21 CEST] <cone-026> ffmpeg 03Clément BSsch 07master:2e341eb15bf8: lavf/http: use AV_OPT_FLAG_DEPRECATED for user-agent option
[20:08:24 CEST] <peloverde> Is new avcC side data supposed to make it to the h264 parser? It seems to be getting lost on me. 
[20:08:57 CEST] <JEEB> avcC side data?! o_O
[20:09:09 CEST] <peloverde> yes like in flv
[20:09:09 CEST] <JEEB> I thought that was in extradata, not side data
[20:09:31 CEST] <JEEB> funky
[20:09:33 CEST] <peloverde> You are right
[20:09:35 CEST] <peloverde> it is AV_PKT_DATA_NEW_EXTRADATA
[20:09:51 CEST] <JEEB> that is funky
[20:10:03 CEST] <jamrial> that depends
[20:10:03 CEST] <JEEB> so we do extradata updates with side data now?
[20:10:10 CEST] <jamrial> of course
[20:11:52 CEST] <peloverde> from what I can tell it makes it to the decoder, but not the parser, so the parser screams and screams and screams
[20:12:00 CEST] <jamrial> parsers don't handle packets, just raw data, so new extradata sent through packet side data will not be seen by it
[20:12:42 CEST] <wm4> just replace parsers by BSFs already
[20:59:08 CEST] <atomnuker> so now I understand why kmsgrab mapping to vulkan works on one of my machines with an nvidia proprietary drivers and optimus
[20:59:31 CEST] <atomnuker> the nvidia card draws into the intel card since the intel card is connected to the display
[20:59:42 CEST] <atomnuker> so the intel card has access to the screen
[21:00:10 CEST] <atomnuker> and the reason why I don't see tiling is because the buffer on the intel is linear
[21:00:49 CEST] <atomnuker> and if I run something with wayland I see tiling because I presume the compositor picks an optimal texture format which is tiled
[21:02:12 CEST] <atomnuker> makes sense because both gpus have their own tiling so the only way to interop them is by transferring the buffer linearly
[21:41:55 CEST] <klaxa> mmhh i'm really favoring being http server/implementation independent
[22:31:20 CEST] <durandal_1707> static const int elem_offset[sizeof(num_bins_in_se)] <---- this one should be uint8_t
[22:34:54 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:356a33b20aec: avfilter/vf_atadenoise: do not abort if user specified invalid size
[22:37:06 CEST] <JEEB> oh, so akamai dudes had push rights?
[22:37:20 CEST] <JEEB> I was going to comment on one of their patches and the guy pushed it after ~2 days
[22:37:37 CEST] <JEEB> the darn commit message doesn't even tell you the asdf truth
[22:37:42 CEST] <durandal_1707> JEEB: which patch?
[22:37:49 CEST] <JEEB> [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9
[22:37:59 CEST] <JEEB> I mean, I'm not sure what 1,2 did
[22:38:19 CEST] <JEEB> but unless they did some magic it's not the default format but they just quietly moved it out of the webm list
[22:38:29 CEST] <JEEB> (because webm is broken)
[22:38:48 CEST] <JEEB> do note that I agree with the idea of making the default VP9
[22:38:55 CEST] <JEEB> since browsers seem to be able to play that
[22:40:13 CEST] <durandal_1707> this all shady, for commit rights, it is enough to request to be maintainer for some part of ffmpeg code
[22:40:32 CEST] <atomnuker> JEEB: just revert it and ask
[22:41:04 CEST] <JEEB> I don't use dashenc.c and I'm most definitely not going to start a revert war. I will possibly write a response on the ML
[22:41:25 CEST] <JEEB> I only knew webm mode was broken because I heard it from a facebook person
[22:41:31 CEST] <atomnuker> there's no such thing as revert wars nowadays, especially with these people
[22:41:32 CEST] <JEEB> and I debugged it one lonely night
[22:41:48 CEST] <JEEB> but yea, I will take a look at it in context
[22:41:57 CEST] <JEEB> if the 1,2 out of 3 did something nice
[22:55:35 CEST] <BtbN> VP9 in browsers is horrible though, no hwaccel
[22:56:50 CEST] <kierank> durandal_1707: of course, you just ask and get commit
[22:57:04 CEST] <kierank> you also ask and get to host ffmpeg.org and trac
[23:06:00 CEST] <j-b>  /lastlog durandal_1707 
[23:06:03 CEST] <j-b> :)
[23:06:07 CEST] <j-b> hello guys
[23:06:22 CEST] <j-b> BtbN: why don't they accelerate it? Do you know?
[23:06:53 CEST] <BtbN> Lack of wide spread HW support I guess
[23:07:05 CEST] <j-b> I thought recent nvidia/Intel chips had it.
[23:07:08 CEST] <BtbN> iirc hwaccel in Browsers on Linux is also disabled entirely
[23:07:14 CEST] <BtbN> because of the API chaos
[23:07:25 CEST] <BtbN> And questionable stability
[23:07:35 CEST] <j-b> yeah
[23:07:42 CEST] <j-b> annoying for webgl
[23:08:17 CEST] <BtbN> WebGL works fine
[23:08:20 CEST] <BtbN> it's just video hwaccel
[23:08:46 CEST] <BtbN> Seems like Chrome in Windows does accelerate VP8 and 9 now
[23:08:51 CEST] <BtbN> Firefox just hasn't implemented it it seems
[23:09:16 CEST] <atomnuker> I don't think firefox really cares about the API chaos aspect of it
[23:09:37 CEST] <atomnuker> because afaik they only care about windows mainly
[23:09:48 CEST] <atomnuker> so they just need dxva there and that's it
[23:11:18 CEST] <atomnuker> as for linux, if it somewhat works, its good enough (opengl compositing accerelation is still disabled unless you force it)
[23:12:37 CEST] <atomnuker> and even if there was decoding accerelation it still has to go back to system ram and through a few copies before finally being composited and displayed
[23:13:20 CEST] <atomnuker> *at least* they stopped damaging the entire window a few versions ago on every frame and just damage what they need to
[23:13:35 CEST] <BtbN> Yeah, Firefox on Linux is in a very sorry state, I switched to Chrome because of that. And even there it's pretty bad.
[23:13:53 CEST] <atomnuker> not chromium?
[23:14:05 CEST] <BtbN> I'm not going to build that on every update, takes hours.
[23:14:06 CEST] <wm4> firefefox is in a sorry state anywhere
[23:14:15 CEST] <BtbN> It's fine on Windows
[23:14:15 CEST] <wm4> *firefox
[23:14:19 CEST] <wm4> nope
[23:14:34 CEST] <wm4> also some of the sorry is portable
[23:15:00 CEST] <wm4> btw. does anyone know how to add custom search prefixes?
[23:15:11 CEST] <wm4> without running 3rd party code
[23:15:14 CEST] <atomnuker> BtbN: are you on gentoo?
[23:15:17 CEST] <BtbN> yes.
[23:15:24 CEST] <BtbN> Edit your search engine, and write the Prefix there?
[23:15:31 CEST] <BtbN> I'm 99% sure that's a core feature and just there.
[23:15:31 CEST] <atomnuker> wasn't there a sort of a binary repo for gentoo
[23:15:39 CEST] <BtbN> Chrome is binary
[23:15:42 CEST] <BtbN> Chromium you build yourself.
[23:15:50 CEST] <wm4> BtbN: where
[23:15:52 CEST] <BtbN> And since it's practically the same code
[23:15:58 CEST] <BtbN> wm4, in the search engine editor
[23:16:15 CEST] <wm4> where, I only see a list where I can delete entries, nothing else
[23:16:26 CEST] <atomnuker> I'd rather take a day to build it if I had no other option than install literal google spyware
[23:16:28 CEST] <BtbN> about:preferences#search
[23:17:16 CEST] <BtbN> Yeah, the Keyword field is just right there, and you can freely edit it.
[23:18:32 CEST] <wm4> BtbN: yeah, I can only delete things there
[23:18:45 CEST] <BtbN> works fine for me
[23:18:55 CEST] <wm4> there's also a link "Add more search engines..." that leads to some WTF garbage that probably makes people accidentally install spyware
[23:18:57 CEST] <BtbN> double click the Keyword, edit it
[23:19:21 CEST] <wm4> yeah, changing the keyword works, but adding a new entry?
[23:19:30 CEST] <wm4> this makes me wonder wtf mozilla is fucking doing
[23:19:53 CEST] <BtbN> you are aware that you can right click basically any input field on any website, and click "Add keyword for this Search", and it will appear there?
[23:19:54 CEST] <wm4> it's just a bad chrome clone now anyway
[23:20:05 CEST] <wm4> BtbN: doesn't work for wikipedia
[23:20:32 CEST] <BtbN> Just tested it. Works
[23:21:45 CEST] <wm4> it just adds a bookmark
[23:21:50 CEST] <wm4> I don't want a fucking bookmark
[23:22:07 CEST] <BtbN> And the bookmark has a keyword, and when you prefix something in the URL bar with that keyword, it will use that bookmark for the search
[23:22:12 CEST] <BtbN> which seems to be exactly what you want?
[23:22:30 CEST] <wm4> I'd probably edit the config files directly, but it's all either hundreds of KBs XML gibberish, or sqlite
[23:22:44 CEST] <BtbN> No idea what you're on about, it works just fine for me.
[23:22:45 CEST] <wm4> well that didn't work either
[23:22:50 CEST] <wm4> I only had a bookmark
[23:23:00 CEST] <BtbN> Yes, it _is_ a bookmark. With a keyword for the searchbar
[23:23:29 CEST] <wm4> actually now it worked
[23:23:35 CEST] <wm4> but after removing the bookmark it's gone again
[23:23:49 CEST] <BtbN> well, that's not overly surprising, since the keyword is set on the bookmark
[23:23:59 CEST] <wm4> it also doesn't show up in the preferences (even while the bookmark is added)
[23:24:08 CEST] <wm4> and the other searches don't have any bookmarks anywhere
[23:24:20 CEST] <BtbN> The other searches that show up there are Browser-Extensions
[23:24:25 CEST] <BtbN> the default one are hidden default ones
[23:24:42 CEST] <wm4> that seems fucking stupid
[23:24:42 CEST] <BtbN> custom stuff is only done via bookmark
[23:25:37 CEST] <wm4> also I wonder when firefox will stop leaking memory
[23:26:01 CEST] <j-b> never
[23:26:06 CEST] <atomnuker> hasn't leaked for me in a while?
[23:36:32 CEST] <JEEB> there, herped a derp at akamai
[23:51:24 CEST] <JEEB> michaelni: shall we just remove the webm mode from dashenc.c in the branches where it segfaults (it might just segfault in all branches where the feature lies currently)
[23:51:38 CEST] <JEEB> since we didn't get any reports about it seemingly, and people are not interested in fixing it
[23:52:19 CEST] <JEEB> it can be quickly tested with any VP9 input, `ffmpeg -i INPUT -c copy -b:v 2M out.mpd` (since it doesn't read maxrate)
[23:55:19 CEST] <JEEB> related thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/229058.html
[23:56:37 CEST] <JEEB> and while I do not care about dashenc.c too much, it's still infuriating when people don't just seem to do the Right Thing
[23:58:48 CEST] <JEEB> also jamrial ^
[00:00:00 CEST] --- Fri Apr 27 2018