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

[burek]

[00:00:44 CEST] <michaelni> JEEB, is it known why it segfaults ?
[00:00:56 CEST] <JEEB> yes, the post I did links to a fix to the segfault
[00:01:04 CEST] <JEEB> but apparently those output files don't work in browsers either
[00:01:13 CEST] <JEEB> according to that akamai person in his first attempt at getting that patch through
[00:03:38 CEST] <jamrial> who wrote support for webm in dashenc to begin with?
[00:04:50 CEST] <JEEB> Peter Grosse and it seems to have gotten merged from Libav.
[00:05:02 CEST] <JEEB> 7295b7373862ee54903b33d6ef3335531dfa93ad
[00:05:20 CEST] <JEEB> 1b8ef01f04ab2210a26b59d3a1a62daed52ce88a being the merge commit by rcombs 
[00:05:43 CEST] <JEEB> granted, the segfault fix is also by rodger, so he did indeed fix it and send the patch to the ML
[00:06:24 CEST] <JEEB> although let me check git blame specifically on that part of code
[00:09:09 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:6a955750d670: avfilter/vf_maskedclamp: add slice threading
[00:09:19 CEST] <JEEB> the reason for the segfault I've also explained in my first comment to the first attempt of the akamai person to have that patch go upstream https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228433.html
[00:09:32 CEST] <JEEB> (when I still didn't know he had commented on rodger's initial fix)
[00:34:49 CEST] <Chloe> JEEB: they should be waiting at least 3 days
[00:35:10 CEST] <JEEB> Chloe: I think the biggest thing is that I commented on his first attempt
[00:35:23 CEST] <JEEB> thus he knew that I had shown interest towards the patch
[00:35:32 CEST] <michaelni> JEEB, i see the crash now
[00:35:55 CEST] <Chloe> JEEB: oh then he pushed before you reviewed the second part. 
[00:35:55 CEST] <michaelni> also happens with vp8
[00:36:03 CEST] <JEEB> yes, it happens with everything
[00:36:07 CEST] <JEEB> I linked the explanation for it
[00:36:15 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228433.html
[00:36:38 CEST] <JEEB> basically because it was calling write_header before init() was called
[00:36:54 CEST] <JEEB> the rcombs patch I linked in https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/229058.html
[00:36:57 CEST] <JEEB> would fix the crash
[00:37:27 CEST] <JEEB> but according to the akamai person even fixing the crash didn't make that webm file work in browsers so I have no idea if the output is valid or not after that
[00:37:44 CEST] <michaelni> I think we should give Jeyapal a chance to comment, as he activly works on dashenc and i didnt activly follow it.
[00:38:16 CEST] <michaelni> but the segfault needs to be fixed
[00:38:30 CEST] <JEEB> sure, I'm just saying that we might as well remove the broken thing if we're OK with rugging these things under the rug
[00:38:56 CEST] <JEEB> because that way the segfault doesn't exist any more instead of currently still being there
[00:39:43 CEST] <JEEB> because if a feature possibly never worked then removing it technically doesn't constitute a removal, I think?
[00:39:52 CEST] <wm4> I'd rather have ffmpeg crash than people distributing broken encodes
[00:40:16 CEST] <JEEB> I agree
[00:40:31 CEST] <JEEB> but if the feature probably never worked and could be removed
[00:41:16 CEST] <JEEB> that way you get rid of the crash and the end result is cleaner
[00:41:53 CEST] <JEEB> just for the record, I'm just really pissed that this got committed - esp. with the commit message it has
[00:42:08 CEST] <JEEB> when you note that you set the "default" for something it means you have alternatives
[00:42:27 CEST] <JEEB> in this case it's not about alternatives, the thing's just moved away from a crashing thing
[00:44:46 CEST] <JEEB> and since I'm the only one seemingly having a problem with this, I will be probably seen as the bad guy who doesn't even post any patches
[00:46:16 CEST] <michaelni> JEEB, its not just you, i also see the apparent bad commit message but i did not closely follow the dashenc changes so i dont want to jump to quick conclusion as theres too much i dont know about this
[00:47:31 CEST] <JEEB> I only happened to know about the problem because I helped a facebook person to locally fixup the thing, and most likely that person then contacted this person to "fix" the issue
[00:47:58 CEST] <Chloe> JEEB: doesn't really matter if you dont submit tons of patches, you are knowledge and your opinion is useful
[00:48:16 CEST] <JEEB> but anyways, I will just shut up and go to sleep. not the best of evenings. not because I care about dashenc. but because this seems like against how this thing should work
[00:48:47 CEST] <JEEB> (to be honest if it was just about dashenc and not about commit/pushing etiquette I would just be non-caring)
[00:49:09 CEST] <JEEB> (unless someone wanted help around me and I happened to poke into it while helping someone)
[00:49:21 CEST] <JEEB> anyways, ‰|
[01:06:06 CEST] <cone-026> ffmpeg 03James Almer 07master:dff1fb27aaf0: avcodec/cbs: create reference counted fragments in ff_cbs_read_extradata()
[01:06:07 CEST] <cone-026> ffmpeg 03James Almer 07master:05c0f620bf14: avcodec/cbs_mpeg2: use existing buffer reference when splitting fragments
[01:13:01 CEST] <Chloe> so what else can we deprecate/remove?
[01:16:31 CEST] <cone-026> ffmpeg 03Aukasz Krzciuk 07master:48330500efd6: avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases
[01:16:57 CEST] <jkqxz> Chloe:  FF_QP2LAMBDA.
[01:17:03 CEST] <Chloe> jamrial: what does postproc give over normal filters?
[01:17:21 CEST] <jamrial> i don't know, why do you ask me?
[01:18:35 CEST] <Chloe> jamrial: you seemed to be supporting merging over just removing it entirely, was just wondering why
[01:21:01 CEST] <jamrial> because keeping the filter in a simpler form is better than just removing it
[01:22:33 CEST] <wm4> libpostproc was simply an ancient filter framework
[01:23:29 CEST] <Chloe> Why shouldn't the libpostproc filters just be moved to lavfi? (and I think there are a few equivalents already)
[01:24:19 CEST] <iive> that's actually good idea
[01:25:01 CEST] <wm4> lol all this effort for something that barely matters and at most is used by some old mplayer fans
[01:26:26 CEST] <jamrial> i'm fine moving the postproc code inside the pp filter and killing the library, or just moving the library out of the main repository
[01:26:37 CEST] <jamrial> but you're not going to have much luck removing both altogether
[01:26:38 CEST] <wm4> all while ffmpeg still can't correctly convert hdr video etc., unless you know the magic switches
[01:26:51 CEST] <wm4> Libav moved it to a separate repo
[01:26:55 CEST] <wm4> ffmpeg didn't care
[01:27:28 CEST] <jamrial> no, the other way around. libav didn't care about the library, since the maintainer wasn't in that project
[01:27:41 CEST] <nevcairiel> libpostproc was moved to a separate repo, but for some reason it was never removed from the main tree
[01:27:55 CEST] <nevcairiel> so more like "copied"
[01:28:04 CEST] <jamrial> is it even kept up to date?
[01:28:18 CEST] <nevcairiel> no, because people forgot that it even exists
[01:28:25 CEST] <wm4> does libpostproc change?
[01:28:42 CEST] <jamrial> if it is, then just send a patch to use said out of tree version. if it isn't, then also make it up to date
[01:28:44 CEST] <wm4> nevcairiel: what do you mean
[01:29:40 CEST] <wm4> I don't see it here https://git.libav.org/?p=libav.git;a=tree
[01:30:08 CEST] <nevcairiel> libav dropped it  entirely
[01:30:16 CEST] <nevcairiel> http://git.videolan.org/?p=libpostproc.git;a=summary
[01:30:25 CEST] <nevcairiel> hasnt really been updated much since the initial copy
[01:30:34 CEST] <jamrial> 2012, wtf
[01:31:15 CEST] <jamrial> so just tidy that repo up, make ffmpeg configure look for it, and remove it from the main repo
[01:31:32 CEST] <wm4> basically yes
[01:31:47 CEST] <wm4> I think D404 actually intended that ffmpeg uses it too
[01:31:57 CEST] <nevcairiel> probably bikesheeding ensued
[01:38:58 CEST] <atomnuker> better start from scratch rather than that repo
[01:39:36 CEST] <atomnuker> the filter's probably going to bitrot to hell so might as well deprecate that one too
[01:39:59 CEST] <iive> then go and start from scratch.
[01:40:34 CEST] <iive> i see this bitrot used a lot as excuse for removing things, that doesn't seem to rot.
[01:41:10 CEST] <iive> i just want to have good postprocessing filter, that can make old crappy videos less ugly
[01:41:22 CEST] <iive> and not consume a whole core.
[01:41:54 CEST] <wm4> what we need is a new libswscale
[01:42:46 CEST] <wm4> what kind of core gets maxed out by 320p video
[01:43:12 CEST] <nevcairiel> if i'm processing a video with ffmpeg, i would hope it always maxes my core, the more the merrier =p
[01:44:16 CEST] <wm4> I'm assuming realtime playback
[01:44:50 CEST] <iive> well, spp does excellent work of making blocky videos nice and smooth. it only does fdct and idct once for each pixel.
[01:45:25 CEST] <wm4> you mean nice and blurry
[01:46:53 CEST] <jamrial> spp doesn't seem to use libpostproc, though
[01:46:54 CEST] <iive> well, if you like it extra smooth :P
[01:47:18 CEST] <iive> jamrial, that's the point. if there is no pp, then i should use spp.
[02:00:37 CEST] <Chloe> klaxa: do you have a list of the features you would like to implement for ffserver?
[02:00:49 CEST] <klaxa> ah right, i was making that list
[02:01:18 CEST] <klaxa> https://gist.github.com/klaxa/a170a1c963463141a392cf53da20ae89
[02:01:27 CEST] <klaxa> what i have right now
[02:02:12 CEST] <klaxa> i've looked a bit at hlsenc.c and it looks like it can only work on files on disk?
[02:02:37 CEST] <klaxa> i've been trying to keep everything in memory for now
[02:07:04 CEST] <klaxa> hmm maybe i should read the code instead of doxygen :D
[02:07:53 CEST] <Chloe> klaxa: since you're not doing nginx, I'm sort-of interested in doing RTSP for that module I linked you. (or at least looking at it since you said you had no idea)
[02:09:21 CEST] <klaxa> okay, well i started to read about how to write nginx modules and stuff, also i think if i make it properly implementation independent it should also be possible to put all that in nginx modules
[02:09:39 CEST] <klaxa> that sentence didn't end the way i thought it would when i started to write it
[02:10:07 CEST] <klaxa> anyway, sounds good i guess?
[02:13:03 CEST] <klaxa> well i wasn't sure because nginx does http and rt(s)p uses udp so...
[02:13:19 CEST] <Chloe> klaxa: I'm unsure of how your ffserver will actually look, but I'm excited to see :) Also will you use a standardised config format like YAML or something?
[02:13:21 CEST] <klaxa> or i am under some misconceptions here
[02:13:40 CEST] <klaxa> i've actually been pondering that as well
[02:13:48 CEST] <klaxa> i like yaml
[02:14:23 CEST] <wm4> yaml sucks
[02:14:25 CEST] <Chloe> klaxa: I'm not sure either if nginx only supports http, I meant that I wanted to look into it but yeah
[02:14:28 CEST] <klaxa> i'm not sure how other peop--
[02:14:40 CEST] <klaxa> yea didn't think that would just fly with no problems :P
[02:14:40 CEST] <wm4> it's too complicated
[02:14:55 CEST] <wm4> it's like they thought of all syntaxes you could possibly want
[02:14:58 CEST] <Chloe> wm4: well I didnt necessarily mean YAML, just was suggesting not inventing yet-another config format
[02:15:06 CEST] <wm4> heh
[02:15:20 CEST] <klaxa> well the few times i touch yaml files it's usually simple ones
[02:15:27 CEST] <klaxa> although now i remember some others
[02:15:29 CEST] <klaxa> hmmm...
[02:16:12 CEST] <klaxa> the old ffserver was xml right? i don't really feel like going down that road
[02:16:22 CEST] <wm4> plain .ini is probably fine for 99% of all things
[02:16:26 CEST] <Chloe> I was just about to suggest xml for a joke
[02:16:38 CEST] <wm4> not sure what ffserver did
[02:16:49 CEST] <Chloe> wm4: it probably had an internal xml lib
[02:16:53 CEST] <klaxa> yeah a flat ini config should be fine
[02:17:01 CEST] <wm4> I'd probably go with json, with some extensions to make it less painful
[02:17:12 CEST] <wm4> (in practice probably a subset of yaml...)
[02:17:26 CEST] <Chloe> there are some really nice json libs too
[02:17:29 CEST] <wm4> but then I tend to overengineer such things
[02:17:42 CEST] <wm4> Chloe: a json parser is maybe 300 LOC in C
[02:17:55 CEST] <wm4> well, mpv's is, though it cheats a bit
[02:18:14 CEST] <wm4> but in conclusion json is really easy to process compared to xml
[02:18:15 CEST] <nevcairiel> as a human, i find reading/writing yaml easier then json
[02:18:15 CEST] <Chloe> wm4: less than a mailto uri parser apparently
[02:18:29 CEST] <wm4> nevcairiel: opposite for me
[02:18:37 CEST] <Chloe> wm4 isn't human.
[02:18:46 CEST] <nevcairiel> yaml has no braces everywhere, just some indentation
[02:18:50 CEST] <wm4> with yml I alwaas have to wonder wtf something really does.. in json it's just clear
[02:19:03 CEST] <klaxa> i agree that braces make it clearer :/
[02:19:11 CEST] <Chloe> honestly, my only experience of yaml is like
[02:19:14 CEST] <Chloe> travis configs
[02:19:17 CEST] <klaxa> i like python indentation, but in yaml i mostly don't get it
[02:19:20 CEST] <Chloe> and damn, they're pretty bad
[02:20:05 CEST] <wm4> the main things I hate about json as config formats are: 1. outer { } (around the whole thing), 2. having the quote keys in ""
[02:20:28 CEST] <wm4> but you could drop the outer {}, and make "" for keys optional
[02:20:35 CEST] <klaxa> well the config should really be just defining a few parameters per stream
[02:20:38 CEST] <wm4> then it's almost ini
[02:20:48 CEST] <klaxa> input, output format(s) and maybe max clients
[02:20:57 CEST] <klaxa> maybe some other options, but should all be global per stream
[02:21:01 CEST] <wm4> .ini without sections, then
[02:21:39 CEST] <atomnuker> klaxa: use lua. eof.
[02:21:39 CEST] <nevcairiel> thats why I hate json
[02:21:49 CEST] <nevcairiel> it just looks terrible with quoted keys and the outer {}
[02:21:54 CEST] <klaxa> i switched FROM awesome because of lua
[02:22:02 CEST] <atomnuker> lua is awesome
[02:22:08 CEST] <atomnuker> for config files
[02:22:14 CEST] <Chloe> mmh. I really like that json quotes its keys
[02:22:20 CEST] <atomnuker> want a standard human readable config file? gotcha
[02:22:28 CEST] <atomnuker> want to do some scripting in there? yep, you can
[02:22:34 CEST] <nevcairiel> using a Lua interpreter just to get config files seems extremely overkill =p
[02:22:51 CEST] <atomnuker> want to define some misc functions to override some edge cases? yep
[02:23:11 CEST] <Chloe> nevcairiel: if we have fflua then we can also make lavfi's filtergraphs lua
[02:23:35 CEST] <nevcairiel> if you have Lua already anyway and the stuff can interact with some things of your project, fine, but if you introduce it just for the config format then all your added benefits do not actually work
[02:24:28 CEST] <wm4> mpv uses a lot of lua scripting, but even it doesn't use lua for config files
[02:24:42 CEST] <atomnuker> because of historical reasons
[02:25:02 CEST] <Chloe> Honestly though
[02:25:03 CEST] <atomnuker> lua is infinitely more readible than both json or yaml or anything
[02:25:15 CEST] <wm4> not sure I agree
[02:25:18 CEST] <Chloe> How else can filtergraphs be easier to use
[02:25:54 CEST] <atomnuker> ":" as a set operator is a blunder of a choice and json shouldn't have gone for it
[02:26:48 CEST] <wm4> lavfi filter graphs would benefit from lua or json or whatever
[02:27:25 CEST] <Chloe> wm4: I really think filtergraphs should be scriptable
[02:27:39 CEST] <wm4> yeah
[02:27:42 CEST] <Chloe> They sortof are now but not really
[02:27:45 CEST] <Chloe> They try to be
[02:27:56 CEST] <Chloe> Which is an indication that they should be
[02:28:02 CEST] <wm4> well some options use this gross eval thing
[02:28:09 CEST] <wm4> or actually all
[02:28:17 CEST] <wm4> but some take a string argument and eval it
[02:28:26 CEST] <wm4> or, uh, not sure
[02:29:05 CEST] <wm4> hm right
[02:29:06 CEST] <atomnuker> having scriptable filtergraphs would solve like 99% of the issues lavfi users have requested
[02:29:19 CEST] <wm4> the filter parser doesn't use eval expressions
[02:29:25 CEST] <nevcairiel> the eval thing is kinda useful for things like scaling percentages and whatnot
[02:29:31 CEST] <wm4> but many filters use string options for number arguments, and eval those
[02:29:49 CEST] <wm4> e.g. vf_scale uses strings for w/h, so that it can eval them to allow filter users to do clever things
[02:29:50 CEST] <atomnuker> "I wanna have a logo! Which like moves! Like every 4 frames, but not on the 5th! Oh and I want it only in between frames 5 and 39!"
[02:29:51 CEST] <nevcairiel> i wouldnt really call that "scripting"
[02:30:15 CEST] <nevcairiel> atomnuker: you can probably even do that already =p
[02:30:38 CEST] <atomnuker> yes, using the API, but try telling that to people who don't believe such exists
[02:30:49 CEST] <nevcairiel> nah even from CLI
[02:31:01 CEST] <nevcairiel> the syntax is crazy but you can do all sorts of weird things with it
[02:31:18 CEST] <Chloe> nevcairiel: yes thats the issue lol
[02:31:32 CEST] <Chloe> You can do a lot of things but the syntax gets batshit insane
[02:31:55 CEST] <wm4> nevcairiel: it usually ends with really really long filter graph strings for achieving rather simple things
[02:32:04 CEST] <Chloe> Scripting would simplify it massively
[02:32:16 CEST] <wm4> with scripting you could use functions
[02:32:21 CEST] <rcombs> atomnuker: I mean, JSON got it from JS, but what would you suggest?
[02:32:38 CEST] <wm4> e.g. make a letterbox() function instead of direct vf_scale invocation with dozens of characters as arguments
[02:32:50 CEST] <Chloe> As for what scripting is viable, only lua or JavaScript probably?
[02:32:56 CEST] <wm4> json syntax could be extended to allow = for :
[02:33:03 CEST] <wm4> it's unambiguous
[02:33:05 CEST] <nevcairiel> never javascript
[02:33:15 CEST] <nevcairiel> its interpreters are huge and  clunky
[02:33:24 CEST] <nevcairiel> also the language itself is terrible
[02:33:24 CEST] <rcombs> are we inventing vapoursynth but in lavfi
[02:33:24 CEST] <wm4> mujs is tiny
[02:33:36 CEST] <Chloe> Mujs is pretty alright
[02:33:36 CEST] <atomnuker> nobody ships it, also js sucks as a language
[02:33:58 CEST] <wm4> fun fact: BrainStorming, BikeShedding, and BullShit all have the same initials
[02:34:14 CEST] <Chloe> Most people know js
[02:34:21 CEST] <nevcairiel> BS only ever means one thing tho :p
[02:34:21 CEST] <atomnuker> its only popular because someone went "OH A MOVING MENU! IN A BROWSER" 25 years ago
[02:34:22 CEST] <klaxa> so?
[02:35:36 CEST] <rcombs> JS is much less bad than it used to be
[02:35:41 CEST] <Chloe> rcombs: thats the dream (not really, just to make filtergraphs usable)
[02:35:53 CEST] <rcombs> these days the problem with JS is everything written in it
[02:36:03 CEST] <nevcairiel> the language itself is still terrible
[02:36:09 CEST] <rcombs> it's like PHP except better-documented
[02:36:11 CEST] <wm4> nevcairiel: +1
[02:36:16 CEST] <nevcairiel> its auto-type conversion rules still give me headaches
[02:36:22 CEST] <rcombs> I did say "less bad" and not "good"
[02:36:25 CEST] <wm4> also fuck this
[02:36:34 CEST] <wm4> as in, the special keyword "this" and its semantics
[02:36:50 CEST] <rcombs> oh yeah JS this is nonsense
[02:36:53 CEST] <Chloe> What other options are there?
[02:36:58 CEST] <atomnuker> lua.
[02:37:00 CEST] <Chloe> Other than lua and js
[02:37:07 CEST] <atomnuker> lua 5.3
[02:37:14 CEST] <atomnuker> its a different language
[02:37:23 CEST] <rcombs> on one hand, JS has loose-typing nonsense
[02:37:29 CEST] <nevcairiel> can go classic and use python like vsynth =p
[02:37:30 CEST] <rcombs> on the other hand, lua has 1-indexed arrays
[02:37:53 CEST] <Chloe> If people dont like js then theres pretty much only lua
[02:37:58 CEST] <wm4> mruby
[02:38:14 CEST] <rcombs> I mean there's moonscript but that's a lua dialect basically
[02:38:15 CEST] <wm4> python (not really)
[02:38:18 CEST] <rcombs> embedded perl
[02:38:26 CEST] <wm4> tcl
[02:38:35 CEST] <rcombs> in case you want to be no more readable than current filtergraphs
[02:38:36 CEST] <Chloe> nevcairiel: You complained about js being big then suggested python...
[02:38:50 CEST] <rcombs> I believe that was in jest
[02:38:54 CEST] <atomnuker> rcombs: you can still do array[0] in lua, its 1 indexed in some situations if you want it to be
[02:38:59 CEST] <nevcairiel> python is probably present on every system already anyway!
[02:39:06 CEST] <atomnuker> you can't embed python
[02:39:14 CEST] <rcombs> oh yes you can
[02:39:21 CEST] <rcombs> hi I maintain a product that does it
[02:39:23 CEST] <atomnuker> you can only have "from ffmpeg import libavcodec"
[02:39:24 CEST] <rcombs> (we're trying to stop)
[02:39:26 CEST] <Chloe> nevcairiel: coinflip which version though
[02:39:31 CEST] <nevcairiel> arrays are basically 1 indexed, if you access array[0] you go into the hash
[02:39:36 CEST] <rcombs> we call into python code from C++
[02:39:38 CEST] <wm4> in lua [0] would use a hash entry instead of the array optimization
[02:39:39 CEST] <rcombs> we regret it
[02:39:43 CEST] <wm4> Lua actually sucks too
[02:39:54 CEST] <atomnuker> not as much as python or js
[02:39:55 CEST] <wm4> but it has small footprint and relatively ok embedding
[02:40:11 CEST] <Chloe> atomnuker: js sucks less than python
[02:40:22 CEST] <rcombs> how about just expose an API to modify filtergraphs and let people write clients for it in whatever language they like
[02:40:32 CEST] <nevcairiel> you mean, lavfi?
[02:40:33 CEST] <atomnuker> you still need bindings
[02:40:36 CEST] <rcombs> run on unix sockets or whatever
[02:40:41 CEST] <klaxa> does that help cli users though?
[02:40:44 CEST] <atomnuker> Chloe: yeah, it does
[02:40:47 CEST] <wm4> mpv actually parses filter graphs itself, just uzsing the same syntax lol
[02:41:08 CEST] <Chloe> rcombs: xml rpc
[02:41:10 CEST] <atomnuker> python is godawful and is run by a bunch of paganic cultists
[02:41:32 CEST] <atomnuker> *intradimensional paganic cultists
[02:41:48 CEST] <rcombs> plus they maintain two similar languages at once so they must be super-masochistic
[02:42:04 CEST] <nevcairiel> 2.x still kicking eh?
[02:42:12 CEST] <atomnuker> read that as "masonic" at first though I guess they're masons too probably
[02:42:43 CEST] <wm4> what I dislike most about lavfi is how static it is and its format negotiation
[02:43:08 CEST] <Chloe> Could be dynamic with scripting
[02:43:18 CEST] <wm4> not really
[02:43:18 CEST] <rcombs> like how ffmpeg.c can't into new streams
[02:43:25 CEST] <atomnuker> well not to the extent that you can change essential frame properties like size
[02:43:28 CEST] <wm4> Chloe: as an API user
[02:43:39 CEST] <wm4> Chloe: even when not using its graph parser
[02:43:46 CEST] <atomnuker> you can use process_command to send filters arbitrary commands but afaik you can't really change the format nor the frame size
[02:43:55 CEST] <Chloe> wm4: ssshh im trying to argue for scripting here
[02:44:00 CEST] <wm4> Chloe: e.g. mpv's fiilter/f_lavfi.c shoulöd be almost empty, but it's not
[02:44:20 CEST] <atomnuker> not without reiniting the graph
[02:44:26 CEST] <Chloe> Anyway, I mean it seems like people arent strongly against changes to filtergraphs
[02:44:48 CEST] <Chloe> Maybe something for on-the-fly changes could be implemented alongside
[02:44:56 CEST] <rcombs> did I mention my evil plan to turn ffmpeg.c into a library and expose a bunch of hooks
[02:45:16 CEST] <wm4> atomnuker: and commands don't even have a convention that'd effectively mean you can implement changing certain options in a generic way (from the view of an API user)
[02:45:19 CEST] <nevcairiel> did we yell at you the last time you did?
[02:45:50 CEST] <rcombs> well I brought it up in darkhold and nobody yelled
[02:45:58 CEST] <rcombs> somebody went "oh yeah google does that for youtube apparently"
[02:46:12 CEST] <Chloe> rcombs: just make it hook into random shared objects
[02:46:18 CEST] <rcombs> wm4 went "how about write something new that's not bad" and I'm like "that sounds like a lot of work"
[02:46:34 CEST] <wm4> that was me yelling
[02:46:49 CEST] <wm4> ffmpeg.c is some sort of caricature at this point
[02:46:52 CEST] <rcombs> well it was lowercase so
[02:47:11 CEST] <wm4> and not really appropriate as a library anyway
[02:47:13 CEST] <Chloe> Should have put rewrite ffmpeg*.c on gsoc tbh
[02:47:27 CEST] <Chloe> Maybe thats what we truly need instead
[02:47:40 CEST] <rcombs> basically I need ffmpeg.c's functionality on iOS but I can't fork() there
[02:48:11 CEST] <rcombs> and I can't justify rewriting the whole thing for work and also I don't want to
[02:48:15 CEST] <Chloe> Instead of generic incremental library refractors, I should just rewrite ffmpeg*.c
[02:48:19 CEST] <wm4> complain to apple (trollol)
[02:48:54 CEST] <wm4> well then make patches to move all the shit to structs, and do your evil ffmpeg.c library thing as a small private patch after that is done
[02:49:48 CEST] <Chloe> rcombs: hire me to do it. Am very experienced with more than 2 weeks of irc experience
[02:50:24 CEST] <Chloe> Damn. I should have said more than 2 weeks of bikeshedding experience
[02:56:20 CEST] <Chloe> michaelni: removal/moval of postproc was discussed on irc a while ago and i only recently got round to doing a patch (it was also then discussed again today)
[03:01:03 CEST] <klaxa> man that really bugged JEEB, eh
[03:01:31 CEST] <klaxa> i totally get it though
[08:53:55 CEST] <JEEB> klaxa: yup, it really bugged me.
[10:39:33 CEST] <ldts> I have extended doc/examples/decode_video.c to add some trivial DRM/KMS display support in order to validate the current work in progress for ffmpeg v4l2 DRM (lrusak)...I have pushed this to my github because I dont know if there is any interest in having it in the ffmpeg tree....still I'll ask: does anyone think there might be any value in preparing it to be merged?  code it is here:
[10:39:33 CEST] <ldts> https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c
[10:41:17 CEST] <ldts> LongChair: ^^
[10:48:31 CEST] <LongChair> ldts: good to see we're progressing there :)
[10:49:26 CEST] <ldts> yeah, sorry about the lag 
[11:34:02 CEST] <LongChair> ldts: i guess what lrusak wants is to get it adjusted for the jobs API right ? 
[11:34:23 CEST] <LongChair> seems a lot of SoC vendors are going that route nowadays
[11:34:48 CEST] <ldts> sorry what do you mean?
[11:37:38 CEST] <wm4> can someone explain what the stateless v4l decoding api is
[11:44:45 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:9faec78b1429: avfilter/vf_mix: add slice threading
[11:44:46 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:e0e75f93b97a: avfilter/vf_maskedclamp: silence warning
[12:08:17 CEST] <ldts> wm4: I'll try to find out...I dont know
[12:09:18 CEST] <wm4> it sort of sounds like desktop hwaccel APIs (which are very nice and don't call all these random problems), but hard to find real information
[12:10:18 CEST] <ldts> yes I found a RFC for linux-rockchip that call them "Frame API" based decoders (ie non-stream API)
[12:10:54 CEST] <wm4> s/call/cause/
[12:11:20 CEST] <ldts> I guess you have seem it as well https://www.mail-archive.com/linux-media@vger.kernel.org/msg104163.html
[12:14:12 CEST] <wm4> possibly
[12:14:39 CEST] <wm4> I wonder if this went anywhere
[12:31:38 CEST] <cone-055> ffmpeg 03Paul B Mahol 07master:2d7ba3a96f50: avfilter/vf_premultiply: add slice threading
[13:00:48 CEST] <durandal_1707> who needs threading to overlay filter?
[13:01:31 CEST] <kierank> durandal_1707: did you fix prores
[13:03:22 CEST] <durandal_1707> kierank: locally, but only pure C version
[13:04:13 CEST] <durandal_1707> asm one needs asm of 12 bit idct, nobody have written
[13:04:47 CEST] <durandal_1707> asm needed because asm path needs transposed permutations
[13:04:55 CEST] <durandal_1707> and pure C doesnt
[13:07:25 CEST] <wm4> <durandal_1707> who needs threading to overlay filter? <- sounds pretty useful at least
[14:21:50 CEST] <ubitux> can't we just move libpostproc in a pp directory in lavfi with ff_ functions the pp filter would use?
[14:22:38 CEST] <ubitux> actually, it's like 3 .c, we may not even need a directory for it
[14:23:28 CEST] <ubitux> (that is, assuming the problem with libpostproc is its exposition)
[14:29:04 CEST] <durandal_1707> ubitux: problem of libpostproc is: it is dead code
[14:29:22 CEST] <ubitux> well, there is a pp filter
[14:30:00 CEST] <durandal_1707> yes, but that is irrelevant, better move libpp code into pp filter
[14:30:07 CEST] <durandal_1707> it is several lines
[14:30:19 CEST] <ubitux> yeah ok, well i'm fine with that
[14:30:49 CEST] <BtbN> Why is libpostproc its own lib?
[14:30:57 CEST] <nevcairiel> historical reasons
[14:31:01 CEST] <durandal_1707> old glorious days
[14:35:09 CEST] <wm4> rather the question is why is libpostproc in the main repo?
[14:35:13 CEST] <wm4> it's an embarrassment
[14:37:30 CEST] <wm4> it's a whole different lib for some filters that were written decades ago
[14:38:06 CEST] <wm4> try to explain it to someone uninitiated, "it's here for historical reasons, you should prefer the more powerful and advanced filters in libavfilter" is your best bet
[14:38:35 CEST] <wm4> it would be a bit different if they were just another set of filters in lavfi
[14:39:25 CEST] <wm4> also I wonder why libpostproc is supposedly "required" for some things (I've seen that claim from at least 2 people, but it was never explained)
[14:44:31 CEST] <wm4> wow vlc uses libpostproc
[14:44:33 CEST] Action: wm4 dies
[14:44:46 CEST] <j-b> The module is still there
[14:44:48 CEST] <j-b> and available
[14:44:56 CEST] <j-b> Some people use it.
[14:45:01 CEST] <wm4> the only time I've seen mpv users use vf_pp was out of ignorance, or in one case because they wanted a fast bob deint filter
[14:45:19 CEST] <nevcairiel> does vlc also still uses liba52? in some areas it always seemed quite a bit slow on the uptick
[14:45:49 CEST] <j-b> vlc did use liba52 for a very good reason, that was explained many times over, and it's no longer the case
[14:46:00 CEST] <j-b> wm4: our users are not always smart
[14:46:02 CEST] <wm4> what reason
[14:46:20 CEST] <wm4> neither are mine
[14:46:42 CEST] <j-b> an architecture issue with a52/dts being not "decoders" in VLC, but "filters" for SPDIF reasons.
[14:46:54 CEST] <j-b> and noone cared enough to fix.
[14:47:00 CEST] <j-b> until 2 years ago, IIRC
[14:47:14 CEST] <wm4> ah
[14:47:18 CEST] <j-b> However, moving from libdca was more problematic, in terms of regression.
[14:48:09 CEST] <j-b> wm4: I hate postproc with a force too, but I remember some arguments of it being more advancedly integrated with the mpeg4 decoder than usual filters
[14:48:15 CEST] <j-b> (or something like that)
[14:48:34 CEST] <j-b> How much of that is BS, I don't remember
[14:48:50 CEST] <wm4> it's the only filter that uses the exported QP table
[14:48:58 CEST] <j-b> yeah
[14:50:02 CEST] <nevcairiel> the need for processing 320x240px blocky videos also reduces every day
[14:50:24 CEST] <wm4> in any case still not a reason why it'd be a separate lib
[14:51:06 CEST] <j-b> true.
[14:51:15 CEST] <nevcairiel> i dont really care, i just dont build it and its so entirely separate that it not once impacted anything i wanted to change
[14:51:23 CEST] <j-b> and maybe there are more clever algo/filters to remove blocks that don't need a QP table
[14:51:36 CEST] <j-b> durandal_1707: ^^ that's what I meant.
[14:52:28 CEST] <nevcairiel> knowing the MB layout and possibly the compression factors of those MBs can be beneficial, on the other hand its also nice to be able to do that without this information, as someone may recompress the blocky video and the info is lost
[14:54:27 CEST] <durandal_1707> j-b: see recently added deblock filter, it is very simple and competes with h264 deblock filter from avs/vs
[14:54:27 CEST] <Chloe> j-b: I wonder how the new deblock filter stacks up against all the pp deblock filters
[14:54:39 CEST] <j-b> Chloe: exactly my point, I believe
[14:54:53 CEST] <j-b> I hate postproc, because some users are stooopid
[14:55:15 CEST] <j-b> durandal_1707: really cool then.
[14:55:34 CEST] <Chloe> j-b: well if we can just say 'use vf_deblock instead', but for all the filters in pp then I dont see why we cant just remove them
[14:55:46 CEST] <Chloe> then they'd essentially just be duplicate (and worse) filters
[14:56:02 CEST] <j-b> Chloe: I'm totally fine with saying to my users to change the filter.
[15:01:38 CEST] <Chloe> auto-levels could be added to eq somehow maybe, we have hqdn3d instead of the temporal noise filter
[15:02:04 CEST] <Chloe> Though I dont do much with filtering so idk about the quality of these filters
[15:02:38 CEST] <durandal_1707> atadenoise is temporal only denoiser
[15:03:02 CEST] <durandal_1707> nlmeans is now spatial only, need SIMD to be faster
[15:03:39 CEST] <Chloe> durandal_1707: are there any filters in pp which do not have 'equivalents'?
[15:03:56 CEST] <wm4> alternative filters will always behave slightly difference and thus will not be accepted as "replacements"
[15:04:24 CEST] <j-b> Chloe: durandal_1707: tbh, I need a filter to remove some blocking for all codecs. And if vf_deblock does 80% of the job, it's good enough for me.
[15:04:39 CEST] <j-b> Chloe: durandal_1707: and I can sponsor more work around that, if someone can do the work.
[15:05:07 CEST] <Chloe> around removing postproc or vf_deblock? cause i'm fairly sure that deblock does what you want already
[15:05:14 CEST] <Chloe> ngl it looks pretty good
[15:05:52 CEST] <durandal_1707> there is deringing filter
[15:06:10 CEST] <durandal_1707> in pp
[15:06:19 CEST] <durandal_1707>  /libpostproc
[15:06:57 CEST] <Chloe> durandal_1707: is that the only one then?
[15:07:43 CEST] <durandal_1707> there are various strange deinit filters
[15:09:07 CEST] <Chloe> wm4: mmh. Maybe, but even so, having equivalents would be good (or at least stating which lavfi filters are equivalents).
[15:09:30 CEST] <Chloe> wm4: 'cause they're sure not getting removed if there is no alternative whatsoever
[15:10:09 CEST] <durandal_1707> the temporal filter options looks to not be used at all, need to test...
[15:12:37 CEST] <durandal_1707> -vf pp=tn give silly artifacts
[17:00:33 CEST] <durandal_1707> which else filters needs slice threading?
[17:26:30 CEST] <cone-441> ffmpeg 03Paul B Mahol 07master:309fce63d8c8: avfilter/vf_shuffleplanes: add support for timeline
[18:25:38 CEST] <kierank> jdarnley: maybe worth looking at that hpeldsp patch
[18:27:10 CEST] <atomnuker> Gramner too, if he's there
[18:27:27 CEST] <atomnuker> *if he can
[18:28:56 CEST] <wm4> how do I make configure to check for two .pc files
[18:29:00 CEST] <wm4> fucking shell shit
[18:30:13 CEST] <wm4> and configure lying about shit
[18:30:35 CEST] <wm4> (incorrect error messages)
[18:33:33 CEST] <jamrial> you mean check_pkg_config() ?
[18:34:23 CEST] <jamrial> or require_pkg_config() if you need configure to die on failure
[18:36:47 CEST] <wm4> second
[18:37:03 CEST] <wm4> I guess it probably works now
[19:18:53 CEST] <cone-441> ffmpeg 03Paul B Mahol 07master:b473e76876d9: avfilter/vf_mix: use correct linesizes
[22:25:13 CEST] <RiCON> wm4: group within ""?
[22:25:32 CEST] <wm4> somehow that didn't work
[22:55:59 CEST] <durandal_1707> so only way to unpack packed binary is to run it?
[22:56:43 CEST] <atomnuker> packed binary?
[22:56:58 CEST] <atomnuker> usually there's a bunch of unpacked code to unpack it
[22:58:37 CEST] <durandal_1707> they appears to run it inside some kind of controlled environment
[23:12:25 CEST] Action: durandal_1707 attempts to run avisyth under linux to RE filter
[23:13:57 CEST] <atomnuker> madman
[23:14:22 CEST] <atomnuker> avisynth supports binary filters? lol
[23:15:35 CEST] <BtbN> A lot of modern games come not as native code, but to some weird VM code and ship a VM that jit-compiles it on the fly
[23:15:53 CEST] <BtbN> with a lot of randomization in that VM, and all that kind of bullshit, just for the sake of copy protection
[23:16:02 CEST] <BtbN> It still gets cracked within a week
[23:16:31 CEST] <nevcairiel> there have been some of those VMs that went uncracked for months
[23:16:52 CEST] <BtbN> That was before they even introduced the VMs, just Anti-Tamper
[23:17:03 CEST] <BtbN> The added VM layer was done in an attempt to slow them back down. Didn't work.
[23:17:38 CEST] <nevcairiel> and everyone knows none are infinitely safe, they are just trying to delay it long enough to get the launch weeks over without cracked versions turning up
[23:18:00 CEST] <BtbN> Yeah, but now it's usually just a matter of days again.
[23:19:03 CEST] <kierank> durandal_1707: run program in vm, dump memory
[23:19:12 CEST] <BtbN> I don't get the appeal of cracked games. You are behind on patches, no online features, massive risk of malware. The only reason a lot of people get it is to play test the game(and then "forget" to buy it).
[23:19:32 CEST] <BtbN> I guess the most effective thing game publishers could do is offer good old demos again
[23:36:04 CEST] <klaxa> and release it without drm like gog
[00:00:00 CEST] --- Sat Apr 28 2018