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

[burek]

[00:18:33 CEST] <loudmax> Hi, may I ask some questions about big endian mips?
[00:21:35 CEST] <iive> go ahead and ask. getting answer is whole another thing :D
[00:22:51 CEST] <loudmax> I´m working at the high bit depth support for interlace filters
[00:23:19 CEST] <loudmax> fate test failed for be
[00:24:11 CEST] <loudmax> I need to test on be mips, but I´m not able to make the compiler work
[00:24:47 CEST] <loudmax> I tried on windows, which was a pain in the ass
[00:25:02 CEST] <loudmax> now I set up linux and it is the same
[00:25:28 CEST] <loudmax> ffmpeg compilation mips help doesn´t work
[00:29:22 CEST] <loudmax> Can anybody explain, how to compile ffmpeg on linux mint for mips and making fate tests with big endian?
[00:32:00 CEST] <durandal_170> loudmax: filter nirmally work in native endianes
[00:33:27 CEST] <loudmax> That´s what I hoped, but see this: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216392.html
[00:41:50 CEST] <wm4> anything with mips will be a PITA
[00:42:04 CEST] <wm4> I'm not sure why we try to support anything big endian
[00:42:11 CEST] <wm4> it's just a lot of work for practically no gain
[00:46:03 CEST] <loudmax> wm4: Is there a way to disable functionality for big endian inside a filter?
[00:46:23 CEST] <jamrial> wm4: the same will happen with ppcbe
[00:46:53 CEST] <jamrial> loudmax: what you did in your second patch was in the right direction (enabling only the LE variants of the pixfmts)
[00:47:30 CEST] <jamrial> you were probably missing adding a bunch of av_le2ne16() to some load and store lines somewhere
[00:48:04 CEST] <jamrial> see how other video filters do it
[00:48:57 CEST] <loudmax> jamrial: I found your new lut filter patch. Something like that?
[00:49:55 CEST] <jamrial> that one removes the ifdeffery. but yes, av_le2ne16() simply expands into av_bswap16() on big endian targets, and does nothing on little endian targets
[00:58:31 CEST] <loudmax> jamrial: That would be many av_le2ne16():
[00:58:47 CEST] <loudmax> jamrial: https://thepasteb.in/p/nZhlNkV668GFY
[01:01:27 CEST] <jamrial> loudmax: you may not need that many, but in any case i'm not the person to ask about this. durandal_170 and ubitux have actually written filters, unlike me
[01:03:50 CEST] <loudmax> durandal_170, ubitux: What do you think?
[02:38:27 CEST] <jamrial> loudmax: try this. read pixels with AV_RL16() from both dst and src buffers. use local variables if necessary (when used in more than one calculation or comparison)
[02:38:57 CEST] <jamrial> then use AV_WL16() to write to the dst buffer at the end if needed
[02:39:14 CEST] <jamrial> look at interpolate_bilinear16() in vf_rotate
[02:39:23 CEST] <jamrial> I can't say that will be enough, but it's worth a try
[02:43:07 CEST] <jamrial> include libavutil/intreadwrite.h for the above functions
[02:47:09 CEST] <loudmax> Okay, I will have a look. Just finished the patches v2 with av_le2ne16(). But I check AV_WL16()...
[02:55:31 CEST] <loudmax> jamrial: av_le2ne16() seems to make more sense to me. It leaves the little endian totaly untouched.
[02:56:17 CEST] <loudmax> Having said that, I actually don´t see the big difference
[02:57:11 CEST] <loudmax> Both are swapping a single pixel?
[03:17:51 CEST] <loudmax> jamrial: Now I´m again having the problem of not having a big endian system for testing
[03:18:49 CEST] <loudmax> I will send my patches with av_le2ne16() to the ML. Maybe Michael can check mips qemu
[03:19:39 CEST] <loudmax> Thank you for the hints
[03:19:58 CEST] <loudmax> Need to go to bed now.
[04:27:54 CEST] <cone-108> ffmpeg 03Henrik Gramner 07master:18821e3ba1ba: x86/exrdsp: optimize ff_reorder_pixels_avx2()
[05:29:49 CEST] <kevinn__> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec?
[05:30:07 CEST] <kevinn__> I can't seem to find any nice and simple sample
[07:10:00 CEST] <FishPencil> After doing some quick testing it looks like FFmpeg's nlmeans filter is ~5.6x slower than this one: https://github.com/farindk/ffmpeg I know there was talk of having this filter use SIMD, but I don't see any of that in farindk's fork
[07:23:18 CEST] <FishPencil> ah looks like there is some SSE2
[13:58:20 CEST] <JEEB> > estimating packet duration for subtitle packets from formats without an end timestamp
[13:58:29 CEST] <JEEB> sounds like I will need something heavy...
[14:01:40 CEST] <JEEB> rcombs: sounds like the TTML folk just figured all the subtitles for a fragment would be in a single sample :D
[14:01:51 CEST] <JEEB> where's my whiskey
[14:54:03 CEST] <cone-214> ffmpeg 03Hendrik Leppkes 07master:b4ecf2b582f3: vp9: move VP9SharedContext back to the top of VP9Context
[16:54:33 CEST] <durandal_1707> why we have own implementation of strdup?
[17:10:02 CEST] <BBB> durandal_1707: because av_strdup is a memory allocator so it needs to use the same allocater as av_malloc
[17:10:14 CEST] <BBB> durandal_1707: its stupid but unfortunately necessary
[17:10:52 CEST] <BBB> durandal_1707: the alternative is to keep very careful track of using free for strdup and av_free for av_malloc, but thats complicated and sometimes nearly impossible when mixing things
[17:13:35 CEST] <wm4> strdup is also not available on every shitty shit we appear to be supporting
[21:19:24 CEST] <JEEB> someone either please disagree or take in :) https://patchwork.ffmpeg.org/patch/5148/
[21:19:32 CEST] <JEEB> we've got two people for this now
[21:19:41 CEST] <BtbN> Privacy Error!
[21:19:50 CEST] <JEEB> youtube spams a lot of that
[21:19:51 CEST] <BtbN> You cannot visit patchwork.ffmpeg.org right now because its certificate has been revoked. 
[21:19:55 CEST] <BtbN> well
[21:20:01 CEST] <JEEB> oh
[21:20:02 CEST] <JEEB> startcom
[21:20:11 CEST] <BtbN> There is also no override option
[21:20:14 CEST] <JEEB> my latest beta firefox still trusts startcom o_O
[21:20:19 CEST] <JEEB> someone... uhh
[21:20:21 CEST] <BtbN> I just plain cannot visit it, at all.
[21:20:23 CEST] <JEEB> should switch the CA
[21:20:24 CEST] <BtbN> This is stable chrome.
[21:20:34 CEST] <JEEB> "GnuTLS: eat PREMATURE_TERMINATION error"
[21:20:40 CEST] <JEEB> is the topic
[21:20:53 CEST] <nevcairiel> they announced enforcing the revocation with chrome 61 a long time ago
[21:20:59 CEST] <JEEB> yea
[21:21:06 CEST] <JEEB> I was just surprised mozilla hadn't revoked it yet
[21:21:09 CEST] <JEEB> since I'm on the beta
[21:21:52 CEST] <BtbN> I stopped caring about Firefox when they announced to turn it into a chrome-clone
[21:22:18 CEST] <JEEB> they've done good job lately IMHO
[21:22:30 CEST] <BtbN> They are about to kill off pretty much all useful AddOns
[21:22:41 CEST] <BtbN> And only allow Chrome-Like Extensions
[21:22:59 CEST] <JEEB> well, even with that you can do cool stuff https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/
[21:23:35 CEST] <JEEB> and out of my daily extensions I'm only going to miss tab groups
[21:23:58 CEST] <JEEB> since the developer console's cookie management has gotten good enough I think I don't need Advanced Cookie Manager any more
[21:24:00 CEST] <BtbN> LastPass is going to be gimped like it is in Chrome, cliget will be dead, Mouse Geatures will be dead.
[21:24:04 CEST] <JEEB> but yes, it'll be painful as hell
[21:24:14 CEST] <JEEB> since people are making extensions on their free time
[21:24:30 CEST] <BtbN> The new API just does not give that kind of power that those kind of addons need
[21:24:32 CEST] <JEEB> and thus when you tell them "pls rewrite" not many will go for it
[21:25:02 CEST] <JEEB> BtbN: as far as I have seen new APIs have been added to the WE side when requirements are clearly seen
[21:25:04 CEST] <BtbN> You just can't modify the download dialog with an extension that only lives inside of the websites that are displayed
[21:25:25 CEST] <BtbN> Same for global mouse gestures
[21:25:28 CEST] <JEEB> BtbN: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/user_interface
[21:25:33 CEST] <JEEB> well... that is available
[21:25:38 CEST] <JEEB> so it's not only the site
[21:26:39 CEST] <JEEB> I'm not saying everything is there and even if it would be there it still doesn't make people rewrite their things that they did out of pure interest and don't want to do all that new work for
[21:26:49 CEST] <JEEB> I will see how badly I get bitten when 57 hits beta
[21:27:19 CEST] <BtbN> The cliget author also said that he didn't feel like to bash his head against the wall that is mozilla support to maybe in a few years give him the interfaces he needs for the addon
[21:28:27 CEST] <JEEB> also while limited, it seems like some gestures are already implemented as WE https://addons.mozilla.org/en-US/firefox/addon/foxy-gestures/
[21:28:38 CEST] <JEEB> but yea, I do agree that it will be a big pain point
[21:28:43 CEST] <BtbN> It will be limited the same way it is in Chrome
[21:28:50 CEST] <BtbN> Only works on websites
[21:28:56 CEST] <BtbN> not in the settings, not on "special pages"
[21:29:23 CEST] <JEEB> also it seems like the quickest way to get your APIs around is to make an experiment out of them a la https://github.com/autonome/webext-experiment-showOnlyTheseTabs/tree/master/experiment
[21:29:39 CEST] <JEEB> which is basically a way to create the interfaces
[21:31:10 CEST] <BtbN> I just Switched to Chrome. It's faster anyway, and as Firefox will soon have the same limitations to its Extensions...
[21:31:33 CEST] <JEEB> I just don't want to be on the chromium train
[21:31:48 CEST] <JEEB> which is a personal thing more than anything tbqh
[21:31:58 CEST] <JEEB> although I really like the new multithreaded stuff etc
[21:32:17 CEST] <JEEB> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
[21:32:20 CEST] <JEEB> etc
[21:32:58 CEST] <BtbN> There soon will be only Blink and Firefox left anyway
[21:33:11 CEST] <BtbN> Except for whatever MS and Apple decide to use
[21:33:25 CEST] <atomnuker> I quite like the synced tab stuff, I started using it a few days ago after I learned it does encryption properly
[21:33:43 CEST] <JEEB> the "containers" concept is nice, too
[21:33:58 CEST] <JEEB> completely separate sets of local storage
[21:37:42 CEST] <wm4> funny how the "convergence" to browsers kills browser people as well (Firefox)
[21:37:50 CEST] <wm4> you only need chrome
[21:58:30 CEST] <iive> BtbN: I can't get used to Chrome... it's so... second guessing...
[21:58:50 CEST] <BtbN> Well, Firefox is getting there as well
[21:59:00 CEST] <iive> I'm probably going to try some firefox fork
[21:59:14 CEST] <BtbN> All the Firefox forks so far have been a security nightmare
[21:59:19 CEST] <iive> something that would keep my extensions working.
[21:59:30 CEST] <JEEB> just use the LTS version then
[21:59:34 CEST] <BtbN> You just can't maintain a Browser without some grade of large professional backup
[21:59:42 CEST] <JEEB> the forks are all something I would not trust
[21:59:54 CEST] <iive> i've heard they are not going to make another long term support version before the break
[22:00:02 CEST] <iive> so 52 or die
[22:00:31 CEST] <nevcairiel> security is probably the prime reason the extensions are getting gutted anyway, so those are never coming back
[22:00:42 CEST] <iive> imho, 57 deadline is way too soon. most popular extensions are not yet ported.
[22:00:43 CEST] <jamrial> the xul extensions are both what made firefox stand out from chrome and what made it infamous among the average user
[22:00:55 CEST] <jamrial> many would break with every browser update
[22:01:10 CEST] <jamrial> many would not play well with others, makign firefox seem unstable or broken
[22:01:20 CEST] <jamrial> same with all the plugins like flash, java and shit like office, antivirus, skype and such installed without your authorization
[22:02:02 CEST] <jamrial> firefox in the eyes of too many people became the slow, bloated browser whereas Chrome was the fast, clean, it just werks browser
[22:02:25 CEST] <BtbN> I only ever see people memeing about Chrome eating was too much RAM
[22:02:27 CEST] <BtbN> not about Firefox
[22:02:27 CEST] <iive> well, is there noscript for chrome?
[22:02:30 CEST] <jamrial> so by killing xul that's dealt with
[22:02:38 CEST] <jamrial> but the one thing that made it unique also gone
[22:02:44 CEST] <jamrial> xul extensions, i mean
[22:03:10 CEST] <iive> i do agree, by killing xul, firefox commits suicide
[22:03:23 CEST] <jamrial> so now the adblockers like ublock actually load the ads, then hide them
[22:03:30 CEST] <jamrial> whereas before they would not be loaded at all
[22:03:37 CEST] <BtbN> I don't think they do that in Chrome
[22:03:41 CEST] <BtbN> and I doubt they will in Firefox
[22:04:03 CEST] <wm4> slack in firefox is slow on Linux, and the slack people gave up on that
[22:04:14 CEST] <wm4> and it's not because of any extensions
[22:04:15 CEST] <nevcairiel> chrome improved that, you can have ads not loading at all, yeah
[22:04:35 CEST] <BtbN> uBlock in Chrome seems pretty perfect to me
[22:04:43 CEST] <jamrial> iive: if the firefox devs actually implement all the interfaces needed so the most popular extensions work as intended, then things will be ok
[22:04:59 CEST] <wm4> firefox would just need to offer an alternative to xul
[22:05:00 CEST] <iive> jamrial: no, there is not enough time
[22:05:06 CEST] <BtbN> They got one more release for that
[22:05:07 CEST] <wm4> I don't believe they don't do this?
[22:05:14 CEST] <BtbN> once the current beta hits live, the Interface will be frozen
[22:05:15 CEST] <jamrial> BtbN: try to open a page with a slow computer and/or slow connection. You'll probably get to see an ad before it's hidden
[22:05:26 CEST] <wm4> because not doing it would be a big fat fuck you to users
[22:05:39 CEST] <wm4> (but we all know browsers and their users are in an abusive relationship)
[22:05:43 CEST] <JEEB> jamrial: that seems to only happen to me right after boot
[22:06:01 CEST] <iive> wm4: this is exactly what they do
[22:07:42 CEST] <iive> wireshark could probably tell you if they do load other websites
[22:07:57 CEST] <iive> there must be an firefox internal method for that too...
[22:07:58 CEST] <wm4> or the browser js debugger
[22:08:14 CEST] <wm4> (web dev tools or what they call it)
[22:08:44 CEST] <JEEB> jamrial: also I had that issue with adblock plus too, which AFAIK was a XUL extension
[22:08:56 CEST] <iive> yeh, but you should know how to use it and it may still lie to you .
[22:09:20 CEST] <iive> JEEB: that was an option of adblock
[22:10:52 CEST] <jamrial> so yeah, i bet there were many heated discussions among firefox devs before making this drastic decision. they put stability and idiot proof approach to extensions in one scale and the versatility and power of xul extensions in another
[22:10:57 CEST] <jamrial> and the former won
[22:11:50 CEST] <iive> the problem is, they cannot be better chrome than chrome
[22:15:40 CEST] <jamin> I've already posted this in the user's channel and seemingly stumped the folks there... I'm trying, without success, to get ffmpeg to open a multicast stream... https://pastebin.com/6nS0FXdt
[23:42:36 CEST] <kevinn__> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec?
[23:42:43 CEST] <kevinn__> I can't seem to find any nice and simple sample
[00:00:00 CEST] --- Wed Sep 20 2017