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

[burek]

[00:49:46 CEST] <rcombs> I just implemented ALPN support in curl's darwinssl
[00:49:53 CEST] <rcombs> the weird thing is that I have no idea why I did that
[00:50:05 CEST] <wm4> what is ALPN
[00:50:27 CEST] <rcombs> the TLS extension that lets you tell the server what application-layer protocol you're using in the handshake
[00:50:51 CEST] <wm4> what does it mean?
[00:50:54 CEST] <rcombs> mostly used for negotiating HTTP/2 in the TLS handshake instead of starting at HTTP/1.1 and upgrading
[00:51:21 CEST] <rcombs> Application Layer Protocol Negotiation
[00:51:40 CEST] <rcombs> Secure Transport supports it but it's private/undocumented API
[00:52:30 CEST] <wm4> http 2... how terrible
[00:54:26 CEST] <llogan> pcm_* in mpeg ps is not kosher, right?
[00:54:41 CEST] <rcombs> reverse-engineering it was fun though
[00:54:53 CEST] <rcombs> because apparently absolutely nobody has written public docs on it before
[00:56:54 CEST] <TD-Linux> rcombs, I was under the impression that chromium uses Secure Transport... did they also reverse it?
[00:58:29 CEST] <wm4> btw., didn't nevcairiel write a native windows thing too?
[00:58:48 CEST] <rcombs> they use NSS
[00:58:50 CEST] <rcombs> wm4: yup
[01:00:20 CEST] <spaceinvader> does anyone have an interest in the prores encoder? i've been doing some research as i have a hardware decoder that won't play files from ffmpeg and i'm working towards a patch, but I could do with some help / a mentor
[01:00:37 CEST] <rcombs> aren't there 2 of those
[01:00:40 CEST] <rcombs> have you tried the other one
[01:00:48 CEST] <spaceinvader> yes, neither produce a "valid" output
[01:01:07 CEST] <rcombs> make that 3, actually
[01:01:16 CEST] <spaceinvader> 3?
[01:01:47 CEST] <spaceinvader> at the moment I'm patching proresenc_anatoliy but I'll also look at proresenc_kostya. there's also a decoder, but AFAIK that works OK
[01:02:05 CEST] <wm4> we should drop 2 of these 3
[01:02:07 CEST] <wm4> but politics
[01:02:24 CEST] <kierank> spaceinvader: which hardware decoder
[01:02:34 CEST] <rcombs> oh wait
[01:02:38 CEST] <rcombs> only 2 but one of them has 2 names
[01:02:40 CEST] <spaceinvader> if you specify -vcodec prores then it uses the anatoliy one
[01:02:51 CEST] <spaceinvader> kierank: blackmagic hyperdeck studio thing
[01:03:03 CEST] <kierank> ah I have one of those
[01:03:13 CEST] <spaceinvader> having looked at all of the other prores files I have, it seems that actually there is an alignment issue
[01:03:42 CEST] <spaceinvader> the encoders we have right now seem to be based of the same reverse engineer
[01:04:02 CEST] <kierank> yes
[01:04:33 CEST] <kierank> I guess you made sure to produce mov files that were exactly like the ones the hyperdeck make
[01:04:58 CEST] <spaceinvader> yep. i can actually remux apple prores with ffmpeg and it still plays fine
[01:05:14 CEST] <spaceinvader> and i've been messing around with the apple "Atom Inspector"
[01:06:37 CEST] <kierank> what is aligned differently
[01:07:12 CEST] <spaceinvader> http://wiki.multimedia.cx/index.php?title=Apple_ProRes#Frame_header so these are kostya's notes
[01:08:09 CEST] <spaceinvader> i find if i pad the frame headers so they are divisible by 16 (with the padding counted in the hdrSize but not in any of the picture slices / pic_data_size)
[01:08:13 CEST] <spaceinvader> then it almost plays
[01:08:20 CEST] <spaceinvader> i'm still having trouble with a couple of frames
[01:08:41 CEST] <spaceinvader> but also my padding is currently random memory and not zeros, so that might be to do with it
[01:09:33 CEST] <kierank> you can PM kostya. his nick is "Keiler"
[01:09:50 CEST] <spaceinvader> thanks
[01:11:14 CEST] <kierank> the hyperdeck thing is quite interesting - it loads new firmware into the fpga depending on the codec you choose
[01:12:34 CEST] <spaceinvader> cool. i noticed it has it's own fourcc too. most of the "apple licensed prores" encoders have one beginning with "a" for apple, e.g. "atf0" for "apple - The Foundry" and "abm0" for "Apple - BlackMagic DaVinci Resolve"
[01:12:53 CEST] <spaceinvader> but the hyperdeck uses "bmd0", so it seems like they must have done their own implementation
[01:13:16 CEST] <kierank> yes I believe so
[01:13:24 CEST] <spaceinvader> in any case, app of my apple prores movs have frames that divide by 16, and all of the blackmagic hyperdeck created ones divide by 4
[01:13:51 CEST] <spaceinvader> but at the moment ffmpeg ones can be odd length
[01:14:45 CEST] <kierank> how does apple pad the frame
[01:15:13 CEST] <kierank> I guess I could find some SDI and record it and see
[01:15:21 CEST] <kierank> the only prores file I have is 300GB
[01:17:31 CEST] <rcombs> I can grab some
[01:17:40 CEST] <spaceinvader> apple just seems to pad with zeros after all the slice data
[01:17:42 CEST] <rcombs> got access to a couple Ki Pros
[01:17:54 CEST] <rcombs> (also software)
[01:18:25 CEST] <spaceinvader> i've been using records from the blackmagic, and output from apple compressor, the foundry nuke and davinci resolve
[01:18:33 CEST] <spaceinvader> can get some sample files uploaded once i'm back at work tomorrow
[01:20:42 CEST] <wm4> <kierank> the only prores file I have is 300GB <- is there a nice anecdote behind this?
[01:20:55 CEST] <kierank> it's a 6 hour recording
[01:21:33 CEST] <kierank> the anecode is I tried to download it at vdd13, assuming the speed would be fast at the ISP hosting the conf
[01:21:49 CEST] <kierank> I gave up and downloaded it on my 3g plan
[01:23:50 CEST] <kierank> https://scontent-lhr3-1.xx.fbcdn.net/hphotos-ash2/v/t1.0-0/p206x206/1011774_423253084446982_419667676_n.jpg?oh=7e0cf2a90e9190b82cb5a5576a1042d1&oe=56C6B847
[01:23:53 CEST] <kierank> there is my proof
[01:26:31 CEST] <llogan> 300gb. and here im still using an iphone 3gs....
[01:27:32 CEST] <spaceinvader> kierank: hey cool, you're OBE/OBS right?
[01:27:59 CEST] <kierank> depending on your definition of OBS, ye
[01:28:00 CEST] <kierank> s
[01:29:16 CEST] <spaceinvader> i'm after some h264/zixi encoders, recognised your logo from the zixi website
[01:29:55 CEST] <kierank> heh ok
[01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:cb6f1f8bf95e: x86: fpel: Move prototypes for 4-px block functions
[01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:607f820ec7c9: x86: fpel: Remove erroneous ff_put_pixels8_mmxext prototype
[01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:a079cbf458fc: x86: vc1dsp_mmx: Move yasm initiation steps to vc1dsp_init
[01:57:40 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:068e6cb73205: huffyuvencdsp: Use intptr_t for width
[02:04:25 CEST] <Timothy_Gu> kierank: can you install libc6-dev-i386 and preferably g++-multilib on avdev?
[02:04:41 CEST] <Timothy_Gu> those are necessary for testing -m32
[02:05:11 CEST] <kierank> done
[02:05:55 CEST] <Timothy_Gu> that was fast. Thanks! :)
[02:33:04 CEST] <cone-278> ffmpeg 03Michael Niedermayer 07master:e91cd8a9c46f: compat/solaris/make_sunver.pl: Use /usr/bin/env perl instead of /usr/bin/perl
[08:52:26 CEST] <thardin> I hear visual studio can compile ffmpeg nowadays. is this true?
[08:52:36 CEST] <thardin> without using c99toc89 that is
[08:52:46 CEST] <j-b> yes
[08:53:48 CEST] <thardin> neat
[09:02:38 CEST] <JEEB> 2013u2 or newer methinks
[09:19:51 CEST] <thardin> http://blogs.msdn.com/b/vcblog/archive/2015/10/19/do-you-prefer-fast-or-precise.aspx  survey whether msvc should default to /fp:precise of /fp:fast
[09:20:03 CEST] <thardin> is what got me thinking about it
[10:06:44 CEST] <cone-732> ffmpeg 03Paul B Mahol 07master:0e08d6ca140a: avformat: add msf demuxer
[10:06:44 CEST] <cone-732> ffmpeg 03Paul B Mahol 07master:35564318ad5a: avformat: add wve demuxer
[11:41:40 CEST] <ubitux> lol google
[11:41:45 CEST] <ubitux> MediaCodec, API C my ass
[11:41:54 CEST] <ubitux> they don't map to the java thing
[11:41:56 CEST] <ubitux> no async
[11:42:15 CEST] <ubitux> (and sync one doesn't fit in the ff model either)
[11:42:31 CEST] <ubitux> jni incoming
[11:44:46 CEST] <mateo`> I want to drink to forget this thing
[11:45:06 CEST] <wm4> lol
[11:45:13 CEST] <wm4> wat
[11:45:31 CEST] <wm4> ubitux: it might not matter if the C API can be as fast as the Java thing?
[11:45:43 CEST] <wm4> what do you mean the sync one doesn't fit ffmpeg?
[11:48:34 CEST] <mateo`> MediaCodec provides two main functions, dequeueInputBuffer, dequeueOutputBuffer that let you retreive the internal buffers
[11:49:32 CEST] <mateo`> dequeueInputBuffer can returns TRY_AGAIN_LATER (meaning you can't feed more data into the decoder)
[11:50:17 CEST] <mateo`> maybe i'm mistaken but the ffmpeg decode function feeds a packet into the decoder, and then call the decoder to output the frame
[11:51:18 CEST] <mateo`> its the same for dequeueOutputBuffer
[11:51:36 CEST] <rcombs> you generally call a single function that feeds a packet in and gets a frame out
[11:52:00 CEST] <mateo`> yes this is what i meant (sorry if i'm not clear)
[11:52:57 CEST] <mateo`> so here it means that when the decoder tell you to try again when you want to push a frame to it
[11:53:08 CEST] <rcombs> so a MediaCodec wrapper would need to have its own queueing
[11:53:18 CEST] <mateo`> you have to queue it locally, so you can queue it when in the next call of the decode function
[11:57:07 CEST] <mateo`> well, it should fit the current api by queueing its input when needed
[12:00:09 CEST] <iive> or allow the current api to take an empty packet and return frame and take a packet and don't return frame
[12:17:49 CEST] <cone-732> ffmpeg 03wm4 07master:de1b1a7da9e6: avformat/mp3dec: improve junk skipping heuristic
[12:18:04 CEST] <wm4> phew, no stale commits accidentally pushed this time
[12:18:55 CEST] <wm4> mateo`: we were discussing an alternative API for libavcodec, which can handle decoupled packet/frame I/O
[12:37:45 CEST] <mateo`> wm4: yes, i'm following the discussion
[12:50:52 CEST] <cone-732> ffmpeg 03wm4 07release/2.7:9362282fd17f: avformat/mp3dec: improve junk skipping heuristic
[12:50:54 CEST] <cone-732> ffmpeg 03wm4 07release/2.8:96b87d5cfaa5: avformat/mp3dec: improve junk skipping heuristic
[13:06:50 CEST] <cone-732> ffmpeg 03Hendrik Leppkes 07master:00ae5b401b24: dca_parser: don't overwrite the sample rate, it may not be correct
[18:26:51 CEST] <Alzathar> Hi everybody
[18:28:02 CEST] <Alzathar> I would like to add the mime_type field for each demuxer. Is there any reason why it was not done before?
[18:28:27 CEST] <wm4> there are mime types in some places
[18:28:33 CEST] <wm4> but often they're just not needed
[18:28:39 CEST] <wm4> for what do you want to use them?
[18:28:48 CEST] <Alzathar> Yes but mostly for muxer
[18:29:43 CEST] <Alzathar> I would like to integrate FFmpeg into Qt as QtMultimedia plugin.
[18:30:00 CEST] <Alzathar> However, this requires to know the mime types
[18:30:56 CEST] <wm4> what does it need to know them for?
[18:32:59 CEST] <Alzathar> To determine if the media service support a media format
[18:33:08 CEST] <Alzathar> http://doc.qt.io/qt-5/qmediaservicesupportedformatsinterface.html#supportedMimeTypes
[18:33:41 CEST] <wm4> mime types are a very bad way to identify media file formats and anything
[18:34:05 CEST] <wm4> it might make sense to return from that function whatever you can think of
[18:34:33 CEST] <wm4> instead of doing it "properly" (which would just lead to mediocre results anyway)
[18:35:12 CEST] <Alzathar> ok, thanks for the advice.
[18:35:50 CEST] <wm4> (and libavformat itself identifies media types by probing the actual data)
[18:37:25 CEST] <Alzathar> I will focus more on the second method which gives a list of codecs to know if they are supported.
[18:37:40 CEST] <Alzathar> Yes, I 
[18:38:08 CEST] <Alzathar> Regarding libavformat, I found the way to idently the media type.
[18:38:20 CEST] <TD-Linux> yeah sadly the documentation says very little. most qt apps probably use types from mime.types, so they aren't very useful
[18:38:59 CEST] <TD-Linux> mediasource's isTypeSupported uses extended types like this: video/mp4; codecs="avc1.42E01E, mp4a.40.2"
[18:39:23 CEST] <j-b> Qt multimedia is crap
[18:39:50 CEST] <TD-Linux> but that requires the app to know what it's passing to phonon, which it probably doesn't.
[18:40:05 CEST] <Alzathar> Phonon is no more used in Qt5
[18:40:12 CEST] <TD-Linux> err QtMultimedia
[18:40:22 CEST] <j-b> phonon works with Qt5
[18:41:05 CEST] <Alzathar> @j-b: Maybe, but this is no more the default engine to read media service.
[18:41:40 CEST] <Alzathar> *to read media
[18:42:39 CEST] <j-b> good luck
[18:45:58 CEST] <Alzathar> I am interested to extract video frame and overlay it with some information. The new QtMultimedia system seems well adapted for that: http://doc.qt.io/qt-5/qtmultimedia-video-qmlvideo-example.html
[18:47:26 CEST] <JEEB> holy fuck
[18:47:43 CEST] <JEEB> ARIB's standardization of MMT over UDP oover TLV
[18:48:30 CEST] <JEEB> no idea if they will ever use that in reality, but it seems overconvoluted like hell
[18:50:19 CEST] <wm4> fishing for consulting money?
[18:54:08 CEST] <wm4> ubitux: someone reported this: https://sr.ht/jJ0A.txt
[18:55:46 CEST] <kierank> JEEB: omg
[18:58:39 CEST] <JEEB> kierank: just reading the specs is fun when you have no idea what those parts are at first: STD-B60 -> STD-B32 -> STD-B10 -> R-REC BT.1869
[18:59:50 CEST] <JEEB> I'm still reading wtf they mean with MMT
[19:00:06 CEST] <JEEB> I get it that they're using MFU/MPU for  video and audio
[19:00:16 CEST] <TD-Linux> JEEB, oh no this? http://www.nhk.or.jp/strl/publica/bt/en/fe0061-6.pdf
[19:00:19 CEST] <JEEB> (which can mean anything)
[19:00:44 CEST] <JEEB> TD-Linux: sounds like it
[19:01:01 CEST] <JEEB> instead of trying to find a simple brochure I jumped straight at the specs tho
[19:01:14 CEST] <JEEB> when someone mentioned that someone was trying to spec MMT
[19:01:38 CEST] <JEEB> because when I last read about MMT it was just some kind of weird umbrella wrapper on top of ISOBMFF and HTML5 and whatever
[19:02:40 CEST] <TD-Linux> JEEB, well MMTP isn't standardized yet, I don't think they can standardize things using it :)
[19:02:41 CEST] <kierank> mmt is mental
[19:03:07 CEST] <JEEB> TD-Linux: well the ARIB specs are official and out :P
[19:03:19 CEST] <TD-Linux> ...
[19:03:35 CEST] <TD-Linux> it's still a -00 draft https://datatracker.ietf.org/doc/draft-bouazizi-tsvwg-mmtp/
[19:04:30 CEST] <JEEB> http://www.arib.or.jp/english/html/overview/doc/2-STD-B60v1_3.pdf , http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_3.pdf , http://www.arib.or.jp/english/html/overview/doc/2-STD-B10v5_5.pdf
[19:04:34 CEST] <JEEB> related specs
[19:04:43 CEST] <JEEB> (not in english albeit the url says something else)
[19:05:09 CEST] <JEEB> also fun, MMTP has a separate spec
[19:05:20 CEST] <JEEB> I was reading the MPEG-H MMT document
[19:05:22 CEST] <JEEB> and just going WTF
[19:06:51 CEST] <TD-Linux> JEEB, well I guess it's gotta be ready for the 2020 japan olympics no matter what
[19:07:04 CEST] <TD-Linux> and RTP is only enterprise grade, not entertainment grade
[19:10:34 CEST] <ubitux> wm4: you're kidding me, right?
[19:10:36 CEST] <ubitux> :D
[19:10:52 CEST] <wm4> ubitux: apparently not
[19:25:45 CEST] <TD-Linux> JEEB, my favorite part of the NHK paper is apparently "applets" and "html5" can go inside MMT
[19:25:52 CEST] <JEEB> yes
[19:25:55 CEST] <wm4> wat
[19:26:05 CEST] <JEEB> MMT has a shitload of stuff on HTML5
[19:26:28 CEST] <JEEB> it reeks like MPEG-4
[19:26:31 CEST] <JEEB> with the viewpoint stuff
[19:26:47 CEST] <TD-Linux> is there some other MMT spec besides the internet draft?
[19:26:55 CEST] <JEEB> http://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs/w13293.zip
[19:27:05 CEST] <JEEB> this is the actual MMT spec's draft
[19:27:17 CEST] <JEEB> it might be out as an actual spec but ENOTSURE if free
[19:27:23 CEST] <JEEB> it's part 1 of MPEG-H
[19:27:42 CEST] <JEEB> http://www.iso.org/iso/catalogue_detail.htm?csnumber=62835
[19:27:45 CEST] <JEEB> yeah, not free
[19:27:58 CEST] <TD-Linux> oh I see, so the IETF draft is no longer the real standard
[19:28:12 CEST] <JEEB> the IETF thing is MMTP
[19:28:15 CEST] <JEEB> this is MMT
[19:28:20 CEST] <JEEB> *enjoy*
[19:28:47 CEST] <JEEB> and the draft doc shows MMT protocol as being defined by MMT
[19:28:56 CEST] <wm4> so this is basically satan in form of a standard?
[19:29:04 CEST] <TD-Linux> wait MMT is more than just MMTP protocol?
[19:29:57 CEST] <kierank> MMT = MP4 + MPEGTS + MXF in one
[19:29:57 CEST] <JEEB> MMT Protocol seems to be part 7.3 of MMT
[19:29:58 CEST] <kierank> imagine that
[19:30:11 CEST] <TD-Linux> oh shit
[19:30:12 CEST] <JEEB> yes, that's the feeling I'm getting here
[19:30:29 CEST] <j-b> kierank: oh boy
[19:31:05 CEST] <TD-Linux> so MMTP implements a file sending feature like HTTP, now I know what it's for and I wish I didn't
[19:31:45 CEST] <JEEB> yes, Assets
[19:32:01 CEST] <TD-Linux> "RTCP has been used in wired network for long time but it has drawbacks when used in wireless networks."
[19:32:20 CEST] <j-b> MMT is a demuxer or a protocol?
[19:32:39 CEST] <JEEB> MMT contains a protocol
[19:32:46 CEST] <TD-Linux> j-b, "MMTP" is a protocol that is very similar to RTP
[19:33:24 CEST] <TD-Linux> RTP is basically a container for UDP or SCTP usage
[19:33:43 CEST] <TD-Linux> well, MMTP actually contains .mp4 files, so it's like a meta container
[19:34:58 CEST] <JEEB> MPUs, which are basically a sequence with at least one random access point
[19:35:11 CEST] <JEEB> and which have to be decode'able from the beginning
[19:35:19 CEST] <JEEB> so it's basically a GOP
[19:35:30 CEST] <TD-Linux> I wonder how this maps into audio?
[19:35:44 CEST] <JEEB> these can then be put into MFUs and thus multiple MMTP payloads
[19:36:19 CEST] <TD-Linux> yeah okay so in the end it's basically the same as DASH fragments, but with extra packetization
[19:36:36 CEST] <JEEB> seems quite similar, yes
[19:37:04 CEST] <JEEB> probably to enable less than one GOP of latency
[19:37:15 CEST] <JEEB> since you don't have to index the whole thing
[19:37:35 CEST] <JEEB> although to be honest I haven't gotten that good of a grasp of it to be sure it's usable like that
[19:38:50 CEST] <kierank> 6:32 PM <TD-Linux> "RTCP has been used in wired network for long time but it has drawbacks when used in wireless networks."
[19:38:51 CEST] <kierank> ?
[19:39:07 CEST] <kierank> really
[19:39:19 CEST] <TD-Linux> kierank, it's apparently justification for defining their own feedback format, CLI
[19:39:31 CEST] <TD-Linux> the advantage is that it's not encrypted and can be man in the middled
[19:39:55 CEST] <TD-Linux> according to the MMT spec
[19:43:41 CEST] <TD-Linux> CI is apparently not HTML5 but HTML "inspired", featuring such beautiful elements such as <divLocation>. They've also taken the liberty to reinvent all the layout rules from scratch
[19:48:20 CEST] Action: J_Darnley chuckles at these streaming people.
[19:48:39 CEST] <JEEB> not even streaming
[19:48:42 CEST] <JEEB> this is broadcast
[19:48:56 CEST] <JEEB> although at the point of using UDP/IP over broadcast I'm not really sure which it is
[19:49:55 CEST] <J_Darnley> Streaming to me implies a live broadcast
[19:52:33 CEST] <kierank> for me streaming usually means some kind of http/tcp thing
[19:52:44 CEST] <kierank> one to one
[19:52:49 CEST] <kierank> broadcast for me means one to many
[20:01:48 CEST] <Daemon404> amusing ticket name
[20:02:41 CEST] <TD-Linux> so the CLI thing stands for "Cross-Layer Interface" and actually has to be produced by the lower level hardware, aka the wifi access point or whatever. basically it includes what the lower level radio guesses the achievable bitrate to be, how many bit errors, etc.
[20:03:45 CEST] <TD-Linux> it seems that MMT, despite using UDP, isn't really designed to work over the Internet, only over special purpose broadcast links, which I guess I should have expected but the usage of "UDP" and "HTML5" distracted me
[20:04:00 CEST] <TD-Linux> also explains why they made their own version of HTTP
[20:04:38 CEST] <JEEB> yeah
[20:18:52 CEST] <durandal_1707> ubitux: what random?
[20:21:02 CEST] <ubitux> durandal_1707: shufflesframes=random=3 would cause a random order for every 3 frames  ([2 1 0] [0 2 1] [0 1 2] [1 2 0] ...)
[20:22:18 CEST] <ubitux> i thought the purpose of the filter was to create discontinuities in order to fuzz muxers/filters/codecs?
[20:22:32 CEST] <ubitux> so maybe make it as unpredictable as possible
[20:23:31 CEST] <durandal_1707> no, you have random filter for that
[20:24:59 CEST] <durandal_1707> this one is to provide selectEvery feature from avisynth
[20:27:04 CEST] <J_Darnley> Why would not not call it SelectEvery then?
[20:27:56 CEST] <ubitux> because we're smarter @_@
[20:28:22 CEST] <ubitux> durandal_1707: does it has a use select can not cover?
[20:31:46 CEST] <durandal_1707> you can not use select to shuffle/reorder frames
[20:33:36 CEST] <durandal_1707> is there expression that accepts list as argument?
[20:35:46 CEST] <durandal_1707> if one need to delete specific frames, using expr for this is pita
[20:38:05 CEST] <ubitux> it's actually pretty easy
[20:38:38 CEST] <ubitux> (to drop)
[20:38:41 CEST] <ubitux> but i'm curious about the use case of shuffling and reordering frames
[20:39:44 CEST] <J_Darnley> A broken video which was bob deinterlaced using the wrong order by a complete moron.
[21:03:40 CEST] <durandal_1707> ubitux: user from #mpv
[21:06:05 CEST] <durandal_1707> some Chinese from vs and avs are following me on twitter
[21:16:39 CEST] <llogan> Outreachy is now "additionally open to residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander."
[21:17:43 CEST] <llogan> that means i qualify for fraud...i mean participation.
[21:23:20 CEST] <Zeranoe> So what licenese does FFmpeg need to be compiled with for OpenSSL? Relivant configure line: enabled gpl && die_license_disabled_gpl nonfree openssl
[21:23:43 CEST] <rcombs> --enable-nonfree
[21:23:48 CEST] <rcombs> i.e. nonredistributable
[21:24:10 CEST] <Zeranoe> rcombs: How is that different than: die_license_disabled nonfree libfaac
[21:26:04 CEST] <rcombs> Zeranoe: just a different warning
[21:26:15 CEST] <llogan> Zeranoe: while you're here, can you delete these? https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1395#p6061 and https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=846#p5212
[21:26:36 CEST] <llogan> more Chinese GPL violating spammer shitsoft
[21:26:41 CEST] <Zeranoe> llogan: I'd be happy to, not sure how those slipped in
[21:26:49 CEST] <llogan> thanks
[21:28:39 CEST] <Zeranoe> llogan: All taken care of. Thank you
[21:29:08 CEST] <llogan> i put word censoring on the gusari forum. more for my amusement than anything (they get deleted quickly). so idealshare becomes iDealshit or similar.
[21:36:37 CEST] <cone-732> ffmpeg 03Timothy Gu 07master:bc22cd244e4c: dnxhdenc: Optimize get_pixels_8x4_sym for 10-bit
[21:43:08 CEST] <llogan> i love seeing console outputs from gentoo users
[23:10:00 CEST] <Gramner> sigh @ that android 6.0 decision
[23:13:18 CEST] <Gramner> i'd personally say it's working as intended and a workaround is to either use x86-64 or a less silly OS
[23:19:35 CEST] <J_Darnley> What does any of that even mean?
[23:23:35 CEST] <Gramner> doing PIC on 32-bit x86 is annoying because there's no rip-relative addressing unlike x86-64. it's simply easier to use relocations instead which also results in faster code. relocations does increase startup time by some milliseconds and requires duplicating some memory if you have multiple instances of the same .so though, but that's an ok tradeoff imo
[23:24:10 CEST] <nevcairiel> Seems like stupid idea to force ban them
[23:24:17 CEST] <Gramner> and for some unknown reason GOOG decided to start throwing an error in android 6.0. when loading a .so that contains textrels
[23:28:06 CEST] <J_Darnley> That was a wonderful explaination so I'm sorry for wasting your time writing it.  I don't know what PIC is either.
[23:28:32 CEST] <Gramner> position-independent code
[23:36:44 CEST] <Gramner> when you load a library you want to load it a a random starting address (due to ASLR for security issues but also to avoid address space conflicts with other libraries). you can either do this with PIC (where static memory accesses are relative to something, often the current instruction pointer) or with relocations (where static memory addresses are kept in a list and updated when you 
[23:36:45 CEST] <Gramner> load the library)
[23:41:28 CEST] <Gramner> PIC is fine and dandy on archs such as x86-64 that has an instruction pointer-relative addressing mode where you can simply define static addresses as an offset from the current instruction, but 32-bit x86 doesn't have that so you basically need to use annoying hacks to be able to get the instruction pointer in a register so you can do loads explicitly relative to that register
[23:42:59 CEST] <iive> you don't need to get the instruction pointer, you just have a pointer that holds the address of the heap data
[23:43:13 CEST] <Gramner> well that works too
[23:43:20 CEST] <iive> just data.
[23:43:40 CEST] <Gramner> data with a known offset to the data you want
[23:44:28 CEST] <J_Darnley> ah, security related stuff that I don't really care to understand
[23:44:34 CEST] <iive> but the point still stands, you need to use a general purpose register for that.
[23:44:39 CEST] <J_Darnley> "both a payroll program and an accounts receivable program built to run at address 32K could not both be run at the same time" - Wikipedia.
[23:44:50 CEST] <J_Darnley> I want to go back to those days.
[23:45:05 CEST] <Gramner> in C the compiler handles this of course, but in asm you need to do a bnuch of special casing for it. it's also slower (the additional register certainly doesn't help when x86 is register-starved as it is)
[23:45:07 CEST] <iive> i think we are already there
[23:45:23 CEST] <iive> you don't have segmentation in 64bit mode :)
[23:45:41 CEST] <Gramner> you can do limited segmentation in 64-bit mode
[23:46:09 CEST] <J_Darnley> When I say I want to go back to those days I mean that literally.
[23:46:15 CEST] <Gramner> iirc some stack protection mechanisms can use that to have safe and unsafe stacks and whatever
[23:46:20 CEST] <iive> yes, but the address space is global,
[23:46:22 CEST] <J_Darnley> I want an amber or green crt.
[23:46:44 CEST] <iive> so you can have only one program at address 32k
[23:46:48 CEST] <J_Darnley> I want transistors you can see
[23:47:11 CEST] <J_Darnley> I want things to be slow
[23:48:11 CEST] <Gramner> go build a basic cpu in minecraft then
[23:52:43 CEST] <iive> Gramner: indeed, i've heard people have done such things
[23:54:28 CEST] <Gramner> yeah, tons of youtube videos of stuff like that
[00:00:00 CEST] --- Wed Oct 21 2015