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

[burek]

[00:06:09 CEST] <cone-134> ffmpeg 03Ruiling Song 07release/4.0:58569162c280: lavf: make overlay_qsv work based on framesync
[00:06:10 CEST] <cone-134> ffmpeg 03Ruiling Song 07release/4.0:a768c0a3e1fa: lavf/qsv: clone the frame which may be managed by framework
[00:09:09 CEST] <jkqxz> jamrial:  Not really.  It mostly came from looking at AV1, and I've not come back to that yet.
[00:09:21 CEST] <jamrial> jkqxz: ah, cool
[00:09:44 CEST] <jamrial> it's been a week without normative changes, so guess it's safe to write av1 cbs now :p
[00:09:46 CEST] <jkqxz> Should I just add doc as Moritz suggested and apply?  I don't have any real use for it so I'm fine with sitting on it until I've got AV1 as well.
[00:14:23 CEST] <jamrial> however you prefer, really
[00:14:52 CEST] <jamrial> you also have the jpeg one in the queue so maybe it's better to have everything in the main repo instead of having to keep it in sync locally with your current work
[00:17:45 CEST] <cone-134> ffmpeg 03Jerome Borsboom 07master:8132d362facd: avcodec/vaapi: do not parse MVMODE for VC-1 interlaced frame pictures
[00:58:12 CEST] <nevcairiel> i wonder how many people actually got paid for that rv11 thing
[00:58:23 CEST] <nevcairiel> at least one, i'm sure
[00:59:21 CEST] <nevcairiel> its easy to argue "for the users" if your own personal interest is fullfilling your contract work
[01:03:41 CEST] <JEEB> it's funny how I've already seen cases on #ffmpeg where people try to build some wrapper for closed source thing XYZ in FFmpeg... just that they happen to be on ARM or something
[01:03:57 CEST] <JEEB> and then it ends up being "well, go ask $VENDOR if they are nice enough to give you an ARM SDK"
[01:04:21 CEST] <JEEB> stuff like the funky "broadcast" protocols (NDI etc)
[01:04:53 CEST] <JEEB> and then of course they reply with "but FFmpeg listed this as a newly supported feature? But don't you support it?!"
[01:05:05 CEST] <JEEB> and you try to get it into their heads that all that FFmpeg has is a wrapper
[01:09:34 CEST] <TD-Linux> it would be best to actually have a policy so you can point to it
[01:09:40 CEST] <TD-Linux> and maybe prevent people from doing the work in the first place
[01:10:13 CEST] <rcombs> isn't NDI mostly just MPEG2 over UDP or HTTP
[01:10:25 CEST] <rcombs> with, what, a second sub-stream for alpha
[01:11:06 CEST] <JEEB> some control thing and they call it a "standard protocol" even though it's all closed source and proprietary
[01:11:16 CEST] <JEEB> they have stuff like message sending to cameras and back
[01:12:06 CEST] <JEEB> but yea, it's probably MPEG-2 or something over UDP
[01:12:07 CEST] <nevcairiel> there is so many crazy commercial codecs, and everytime i read someone asking "hey is this in ffmpeg?", and i go look up what the codec is, i find out that they even charge you for their decoder software, and I'm just like "nope, i'm out of here"
[01:12:55 CEST] <TD-Linux> I'm not sure how to write the rule exactly if you want to make fdk_aac OK but rv11 not
[01:13:03 CEST] <rcombs> prores raw is a thing now
[01:13:12 CEST] <JEEB> """raw"""
[01:13:15 CEST] <JEEB> lossy bayer coding
[01:13:36 CEST] <TD-Linux> well I guess the FSF consideres the fdk_aac license free so that makes it easy
[01:13:41 CEST] <rcombs> also I chatted with fraunhofer people the other day and apparently they're not the ones who defined the non-GPL-compatible android fdk_aac license
[01:14:23 CEST] <rcombs> so, uh& blame google I guess?
[01:14:35 CEST] <TD-Linux> doubtful considering the non-GPL-compatible part involves buying licenses from fraunhofer
[01:14:43 CEST] <JEEB> TD-Linux: the source being distributable and open source already makes it uber 9000 times better than closed source SDKs
[01:14:44 CEST] <atomnuker> if it was up to them it would be closed source with a license making you sell illegal weapons probably
[01:15:04 CEST] <nevcairiel> wasnt that a patent clause, but i guess frauenhofer may hold some of those
[01:15:41 CEST] <TD-Linux> the iffy part is it says you must have all patent licenses (unspecified) or you violate the copyright too
[01:15:50 CEST] <rcombs> well, from Via
[01:15:57 CEST] <TD-Linux> JEEB, right, but you need that in a well-formed rule and not feelings :)
[01:16:07 CEST] <TD-Linux> rcombs, true. I wonder who's in that pool :)
[01:16:11 CEST] <rcombs> which is actually Dolby but yeah a fair number of the patents in the pool are Fraunhofer's
[01:16:57 CEST] <rcombs> the relevant clause is this one, right? "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses."
[01:17:10 CEST] <rcombs> have lawyers actually told people that makes it GPL-incompatible
[01:17:29 CEST] <rcombs> I read that as basically "you must use this in compliance with relevant local law"
[01:18:00 CEST] <TD-Linux> yeah it's sufficiently iffy that different people interpret it differently
[01:19:44 CEST] <JEEB> yup
[01:19:52 CEST] <JEEB> what fedora did is they ripped all of the HE-AAC parts out of it
[01:19:58 CEST] <JEEB> s/fedora/red hat/
[01:20:01 CEST] <JEEB> and then called it libre
[01:30:42 CEST] <cone-134> ffmpeg 03Michael Niedermayer 07master:d9706f79c17a: avcodec/ffv1enc: Check that the crc + version combination is supported
[11:20:46 CEST] <durandal_1707> ./libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406 [-Wconstant-conversion]
[11:20:49 CEST] <durandal_1707> static const int16_t FIX_2_613125930   = FIX(-2.613125930, 13);
[17:27:59 CEST] <cone-533> ffmpeg 03Paul B Mahol 07master:e34751cb8a1d: avcodec/clearvideo: do not try to return frame when it is same as previous one
[17:27:59 CEST] <cone-533> ffmpeg 03Paul B Mahol 07master:f09fdf2d9c0f: avcodec/clearvideo: display warning if decoder overreads input
[18:55:24 CEST] <durandal_1707> ubitux: are you against changing min/max for nlmeans filter options?
[19:21:21 CEST] <klaxa> atomnuker: so i'm kind of conflicted of where to go with the project right now regarding the networking stuff, apparently using the lavf http server does have more disadvantages than advantages so i would definitely not be against using something different
[19:22:03 CEST] <klaxa> the idea of writing it as an nginx plugin came up and seems appealing, but would require more time to learn that interface probably
[19:22:17 CEST] <klaxa> also how would i do rtp with nginx? :S
[19:23:07 CEST] <klaxa> "just" using a library would be okay with me too, but i don't want to go grab the first-best one, rather some suggestions of well performing libraries i should look at?
[19:25:40 CEST] <BtbN> doesn't vlc use microhttpd or something?
[19:28:17 CEST] <klaxa> searching httpd on their github indicates they wrote their own
[19:33:03 CEST] <BtbN> https://www.gnu.org/software/libmicrohttpd/ doesn't sound bad though
[19:34:14 CEST] <klaxa> alright, actually i already took a superficial look at it (it was the first one i found) i'll read it some more
[19:34:15 CEST] <BtbN> https://gnunet.org/git/libmicrohttpd.git/commit/?id=65a322cfe842d6028a0b27bc114b34ea178903eb hmm
[19:36:43 CEST] <klaxa> >MHD is currently used in a wide range of implementations. Examples based on reports weve received from developers include:
[19:36:44 CEST] <klaxa> >Large-scale multimedia server (reportedly serving at the simulator limit of 7.5 GB/s) 
[19:37:01 CEST] <klaxa> sounds like if i don't abuse their api too badly it's fast
[19:37:30 CEST] <BtbN> no idea if it'd be worth investigating replacing the existing httpd stuff with it?
[19:37:54 CEST] <BtbN> Might be quite an undertaking though
[19:41:36 CEST] <klaxa> shouldn't it just require the network stuff to be handled by the microhttpd lib and have a custom AVIOContext that writes to the client?
[19:42:58 CEST] <klaxa> well i need to know how the api works first before i can draw conclusions, back to reading...
[19:43:00 CEST] <JEEB> klaxa: as ingest or otherwise? of course if you plan on supporting stuff that's not HTTP and friends as ingest/output then other requirements pop up.
[19:43:01 CEST] <BtbN> you wish. Specially stuff like hls is badly entangled into it
[19:43:15 CEST] <nevcairiel> hls doesnt use http serving
[19:43:22 CEST] <nevcairiel> only client
[19:43:29 CEST] <BtbN> oh right, it has this weird http push feature
[19:43:49 CEST] <nevcairiel> not sure if any internal component uses the http server
[19:43:51 CEST] <nevcairiel> probably not
[19:43:56 CEST] <JEEB> well you could write the segments in some virtual AVIO context that emulates file writes
[19:44:07 CEST] <JEEB> and then the httpd side can give access to those generated assets
[19:44:14 CEST] <JEEB> be that nginx or otherwise
[19:44:36 CEST] <nevcairiel> temporarily writing to files is always going to be easier
[19:45:05 CEST] <BtbN> can always make that a tmpfs if you don't want the io
[19:45:07 CEST] <JEEB> but yea, generally what seems to be popular is to keep a buffer of GOPs around
[19:45:11 CEST] <atomnuker> klaxa: I think it would be interesting to implement it as an nginx plugin
[19:45:26 CEST] <JEEB> and then serve clients timelines from it
[19:45:27 CEST] <atomnuker> I know nginx-rtmp is the workhorse of streaming websites
[19:45:58 CEST] <atomnuker> would be nice to be able to send it some stream (rtmp, whatever) and let it generate dash or rtmp
[19:46:18 CEST] <BtbN> that's exactly what it does?
[19:46:32 CEST] <JEEB> so that f.ex. if you have a live stream you could start="2018-04-12T00:00:00.000" end="2018-04-12T00:00:05.000"
[19:46:46 CEST] <JEEB> and that would give you a VOD playlist if it's already past that
[19:46:52 CEST] <JEEB> or a live playlist if it's still ongoing
[19:47:25 CEST] <JEEB> basically having a buffer and a data structure of timestamp => parts of buffer mappings
[19:48:09 CEST] <JEEB> but yea, basically something like nginx-rtmp but without the RTMP would already be cool :)
[19:48:19 CEST] <JEEB> since you could decide on having some better ingest
[19:48:34 CEST] <klaxa> what does nginx-rtmp take as ingest?
[19:48:38 CEST] <BtbN> rtmp
[19:48:42 CEST] <klaxa> huh
[19:48:51 CEST] <JEEB> RTMP in, HLS and DASH (and RTMP) out
[19:49:05 CEST] <BtbN> pretty much anything out, as you can just make it call ffmpeg
[19:49:24 CEST] <JEEB> also regarding nginx modules, I think I tried scrolling through this before http://www.evanmiller.org/nginx-modules-guide.html
[19:49:39 CEST] <JEEB> which has dumb references but seemed to get some basics around
[19:50:04 CEST] <klaxa> yeah i've been through that up to handlers, had to digest that before going on
[19:50:20 CEST] <klaxa> probably have to re-read the first parts again now that things start to make sense
[19:53:02 CEST] <BtbN> ngingx modules are rather annoying though, as they are not truely dynamic modules, but need to be built together with nginx
[19:54:15 CEST] <tmm1> you might also consider using https://github.com/nodejs/http-parser
[20:00:18 CEST] <cone-533> ffmpeg 03Michael Niedermayer 07master:d06b01fc2d4f: avcodec/vc1_block: simplify ac_val computation
[20:01:18 CEST] <klaxa> as far as i can see that does only http parsing, no tcp networking?
[20:01:41 CEST] <nevcairiel> dont get involved with node stuff, its a huge trap
[20:02:43 CEST] <klaxa> while i'm also not a fan of most things javascript, if it's suggested in here it must have some value :V
[20:03:21 CEST] <BtbN> libmicrohttpd seems like the more complete solution
[20:07:58 CEST] <klaxa> regardless of what i end up using i think i'll have to make the stuff i did more flexlible
[20:34:15 CEST] <tmm1> http_parser is a standalone c parser, has nothing to do with javascript. widely used by nodejs and other platforms so it is very robust and well tested
[20:34:39 CEST] <tmm1> i only suggested it as a middle ground between the existing lavf http parsing soup and a full fledged existing webserver like nginx or microhttpd
[21:03:27 CEST] <klaxa> well the parsing is not so much of a problem i think
[21:04:01 CEST] <klaxa> (for now, who knows what i run into)
[00:00:00 CEST] --- Wed Apr 25 2018