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

[burek]

[00:00:02 CEST] <atomnuker> Gramner: ah, forgot the offset was barely one byte
[00:00:03 CEST] <exastiken_> instead it comes from 2 sources
[00:00:50 CEST] <Gramner> there's two offset types: 1 byte and 4 bytes. obviously you want the majority to use 1 byte
[00:01:20 CEST] <exastiken_> can someone explain how do_encode's function run is so small but motion_estimate ends up so big?
[00:01:30 CEST] <Gramner> which works really well in evex compressed displacements since almost all offsets are a multiple of the load/store size
[00:03:10 CEST] <jamrial> TD-Linux: the most used display resolution being 1366x768 and the massive intel lead on gpu kinda hints this survey was done mostly on net/notebook :p
[00:03:21 CEST] <nevcairiel> TD-Linux: i think a browser survey is probably far more impacted by laptops then a gaming centric survey, but yeah
[00:04:04 CEST] <atomnuker> Gramner: so above 256 you need to have your offset aligned to nearest multiple of 4?
[00:04:10 CEST] <nevcairiel> (the Browsers by Architecture graph looks funny)
[00:04:13 CEST] <jamrial> and the gpu model graph tells you what instruction sets are available, because most of those gpus are intel igp
[00:04:36 CEST] <Gramner> atomnuker: no, the 4-byte offset uses bytes. so anything within +-2GiB
[00:05:11 CEST] <Gramner> onkly the one-bte offset has to be a multiple (which is true in the majority of cases, so saves space on average)
[00:06:48 CEST] <Gramner> e.g. mova zmm0, [src+256] would be encoded as imm8 0x04
[00:08:58 CEST] <Gramner> so for 64-byte memory args you can have +-8 KiB offsets encoded in one byte as long as it's a multiple of 64
[00:09:31 CEST] <atomnuker> how is the type signalled?
[00:10:24 CEST] <nevcairiel> its the size of the register, zmm is 64 byte
[00:11:15 CEST] <Gramner> not strictly register size. e.g. vpbroadcastd will use multiples of 4
[00:11:28 CEST] <Gramner> it's basically the "memory access size"
[00:43:10 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:d7786b66bdd4: cbs: Fragment/unit data is always reference counted
[00:43:10 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:315cc8c0988d: cbs_h2645: Simplify representation of fixed values
[00:57:15 CEST] <exastiken_> How do I compile ffmpeg with debugging options visible to callgrind?
[00:58:33 CEST] <BtbN> Use the _g executable.
[01:00:36 CEST] <jamrial> by default it compiles with -g, but if you need a specific debug level (-g3 or -ggdb) use --enable-debug=$level
[01:12:07 CEST] <exastiken_> BtbN: I tried it with _g but it's telling me that No debug information is present, recompile source and redo the profile run. The function is located is located in this ELF object: 'ffmpeg_g'
[01:13:15 CEST] <exastiken_> jamrial: I'm already using   --enable-debug=3
[01:13:48 CEST] <exastiken_> my full configure is
[01:13:50 CEST] <exastiken_> ./configure \   --prefix="$HOME/ffmpeg_build" \   --pkg-config-flags="--static" \   --extra-cflags="-I$HOME/ffmpeg_build/include -g" \   --extra-ldflags="-L$HOME/ffmpeg_build/lib" \   --extra-libs="-lpthread -lm" \   --bindir="$HOME/bin" \   --enable-debug=3 \   --extra-cflags="-gstabs+ -g" \   --enable-gpl \   --valgrind=valgrind \   --disable-optimizations \   --disable-stripping \   --enable-extra-warnings \   --enable-li
[01:14:18 CEST] <exastiken_> --enable-libfreetype \   --enable-libmp3lame \   --enable-libopus \   --enable-libtheora \   --enable-libvorbis \   --enable-libvpx \   --enable-libx264 \   --enable-libx265 \   --enable-nonfree
[01:22:27 CEST] <iive> don't paste huge things in irc, use pastebin site
[01:22:55 CEST] <iive> and compilation related question are more on topic in #ffmpeg.
[01:23:24 CEST] <nevcairiel> you seemed to be itnerested in analyzing x265 earlier anyway, you should probably analyze x265 directly and n ot through ffmpeg then
[01:59:22 CEST] <Gramner> apparently github were storing passwords in plaintext in log files that got exposed, nice
[02:07:21 CEST] <jamrial> user account passwords?
[02:07:43 CEST] <Gramner> yes
[02:07:52 CEST] <Gramner> they sent me an email about it
[02:08:48 CEST] <klaxa> why would they have them in the first place?
[02:08:57 CEST] <Gramner> "[...] a recently introduced bug exposed a small number of users passwords [...]"
[02:09:04 CEST] <nevcairiel> only affects those that changed them recently, otherwise they wouldnt have gone into logs
[02:09:50 CEST] <klaxa> ah hmm i guess when you enter them in the site, they hash them when they receive it
[02:10:22 CEST] <nevcairiel> and the logs only possibly got "exposed" to their own employees, and even there are  probably strict limits who can view them
[02:10:26 CEST] <atomnuker> btw here's the latest isobmff av1 spec if anyone's interested or has any comments
[02:10:27 CEST] <atomnuker> https://aomediacodec.github.io/av1-isobmff/
[02:10:32 CEST] <nevcairiel> still not nice, but better then other things that  happened
[02:10:40 CEST] <klaxa> yeah
[02:11:43 CEST] <atomnuker> jamrial / jkqxz ^^
[02:32:53 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:300ef253141f: cbs: Add support for array subscripts in trace output
[02:32:54 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:b5df289eb771: lavc: Add coded bitstream read/write support for VP9
[02:32:55 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:308b989e0cf1: lavc: Add VP9 metadata bitstream filter
[02:32:56 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:ddd3a209dc5a: lavc/cbs: Add tests for VP9
[02:32:57 CEST] <cone-597> ffmpeg 03Mark Thompson 07master:e07b1913fc67: fate/cbs: Always overwrite output in cbs fate tests
[02:40:16 CEST] <wm4> wow the internal mpeg encoder could use libxvid's rate control?
[02:42:30 CEST] <atomnuker> yeah
[02:44:47 CEST] <wm4> that's so fucked up
[02:54:07 CEST] <atomnuker> indeed, it was only working for 2pass
[05:11:59 CEST] <wm4> jamrial: aprtopos vp9, seems like there might be a problem with BSF dataflow in avcodec: https://github.com/FFMS/ffms2/pull/323#discussion_r185303842
[05:12:05 CEST] <wm4> *apropos
[05:13:26 CEST] <wm4> haven't looked closer at it, so I'm not sure if it's really a bug
[05:14:51 CEST] <jamrial> i don't see bsf usage in that repro program
[05:15:21 CEST] <jamrial> unless this is related to the superframe split bsf autoinserted by the decoder?
[05:16:43 CEST] <wm4> it is
[05:16:47 CEST] <wm4> because this uses vp9
[05:17:02 CEST] <wm4> I wonder if it's just a file with broken muxing
[05:17:20 CEST] <wm4> but if enabling frame threading changes it...
[05:19:57 CEST] <jamrial> this bsf was written by elenril, but he's kinda awol...
[05:21:28 CEST] <jamrial> maybe ask BBB to look at it. he understands the vp9 bitstream better
[05:37:25 CEST] <TD-Linux> I think the API requires you to loop until you get no more frames out
[05:37:59 CEST] <wm4> if the file is correctly muxed that shouldn't happen
[05:38:34 CEST] <wm4> the thing with ffms2 is that it tries to create a perfect packet->frame index
[05:40:55 CEST] <TD-Linux> yeah I guess the ffmpeg docs say you don't have to pull all frames out
[05:40:56 CEST] <TD-Linux> >For example, you can call avcodec_send_packet() repeatedly without calling avcodec_receive_frame().
[05:41:08 CEST] <TD-Linux> so it's a bug (unless he's getting EAGAIN from avcodec_send_packet)
[05:42:45 CEST] <wm4> yeah if there's still a frame to output, and avcodec_send_packet is called, it should return EAGAIN
[08:17:24 CEST] <ubitux> i have 2 4x32-bit regs such that v0=ABCD and v1=BCDE, and i want v2={A+B A+B+C A+B+C+D A+B+C+D+E}
[08:17:34 CEST] <ubitux> is there an usual pattern to deal with this?
[09:10:33 CEST] <cone-762> ffmpeg 03Tobias Rapp 07master:a150b2e3a099: fftools/ffmpeg: properly initialize output stream field order
[09:47:22 CEST] <durandal_1707> if we would add support for all color properties negotiation, how it should be done?
[12:03:46 CEST] <Chloe> lol. I thought I was bad for replying to a thread which was from 2017 then durandal_1707 replies to one from 2016 :d
[12:05:00 CEST] <Chloe> durandal_1707: will you push '[PATCH] avcodec: remove duplicate prores decoder'?
[12:08:06 CEST] <durandal_1707> Chloe: i pushed that ages ago
[12:09:00 CEST] <Chloe> durandal_1707: ah, missed it. I'm not currently tracking master and you didnt say it was pushed on the ML
[12:25:38 CEST] <jdarnley> Oh wow.  ffmpeg did get rtp-vc2 added by someone.
[12:26:10 CEST] <jdarnley> How do I make ffplay play an rtp stream?
[12:35:56 CEST] <durandal_1707> can i get review for overlay simd patch?
[12:36:14 CEST] <funman> jdarnley: i think you need an sdp
[12:36:48 CEST] <funman> then should be ffplay foo.sdp iirc
[12:38:35 CEST] <jdarnley> lol it guessed it as some sort of ausio
[12:38:38 CEST] <jdarnley> *audio
[12:47:28 CEST] <jdarnley> Oh whoops.  That is only for encoding.
[12:47:29 CEST] <jdarnley> FUCK!
[12:48:03 CEST] <jdarnley> wait, I see a "dec" file
[12:48:43 CEST] <jdarnley> Oh yes, that was the encoder commit.
[13:10:50 CEST] <jdarnley> This sdp thing is garbage.  Do I really have to read a couple of RFCs to create one?
[13:11:31 CEST] <nevcairiel> if you dont know how, then you need to read something that tells you how to do it, does that seem so unusual? :p
[13:12:34 CEST] <jdarnley> Reading 1 sure but this one references several others including a "changes from" section.
[13:13:11 CEST] <jdarnley> Why can't I just use ffmpeg's or ffplay
[13:13:18 CEST] <jdarnley> 's usual options for this?
[13:13:34 CEST] <nevcairiel> you can also just specify a rtp url for opening
[13:13:44 CEST] <nevcairiel> but without sdp its usually a bit unreliable, in my experience
[13:19:22 CEST] <jdarnley> Now I would need to understand what "nettype" and "addrtype" are if basic ipv4 wasn't shown.
[13:24:26 CEST] <jdarnley> Fucking whitelist shit!
[13:24:55 CEST] <JEEB> oh right, ffplay has a weird list of "live" protocols :D
[13:25:00 CEST] <JEEB> I felt that was weird as heck
[13:27:41 CEST] <jdarnley> "Invalid return value 0 for stream protocol"
[13:27:50 CEST] <jdarnley> such a useful message
[13:28:46 CEST] <JEEB> ah yes, the EOF != zero
[13:28:46 CEST] <JEEB> thing
[13:28:55 CEST] Action: JEEB pats jdarnley 
[13:42:09 CEST] <jdarnley> > "seascape" (upside-down landscape)
[13:42:10 CEST] <jdarnley> heh
[13:45:09 CEST] <atomnuker> durandal_1707: probably a structure instead of a single array of color ranges
[13:45:23 CEST] <atomnuker> actually an array of structs
[13:45:47 CEST] <atomnuker> each defining a single acceptable input
[13:46:18 CEST] <atomnuker> so it would contain pixfmt, colorspace, color range, transfer functions
[13:46:55 CEST] <atomnuker> and each of those would need to get negotiated separately
[13:47:24 CEST] <atomnuker> I'm not sure if that's really the correct solution though
[13:47:54 CEST] <atomnuker> because most codecs don't care at all about anything but pixfmt
[13:49:04 CEST] <atomnuker> it'll be the most correct solution for filters though
[13:51:42 CEST] <durandal_1707> current state is just broken
[13:52:19 CEST] <JEEB> it's so broken that most likely when we fix it it will just break some use cases that people *thought* were working :D
[13:52:28 CEST] <JEEB> (but weren't in reality)
[13:53:10 CEST] <nevcairiel> the current state isnt quite broken, just ignorant of such things
[13:53:26 CEST] <JEEB> yes, you could put it like that :)
[13:53:42 CEST] <nevcairiel> and personally, i would say thats how its best, because all the combinations go into infinite complexity
[13:54:05 CEST] <nevcairiel> but of course users are generally morons and would never bother to make sure colors are correct on their own, and instead yell at us :p
[13:54:20 CEST] <durandal_1707> so you want to keep J?
[13:56:44 CEST] <nevcairiel> no, i would just remove them without replacement and let users figure it out themselves
[13:58:35 CEST] <nevcairiel> for range negotiation might be straight forward, sure, but if you go to the other properties like colorspace, then negotiation and conversion becomes a nightmare, and personalyl I would never want my colorspace to be auto-converted
[14:00:35 CEST] <nevcairiel> because speifically compressing colorspace is a lossy operation
[14:00:40 CEST] <nevcairiel> specifically*
[14:04:19 CEST] <JEEB> yup
[14:04:33 CEST] <JEEB> requiring user to be more explicit is good the more correctly you start doing stuff
[14:07:24 CEST] <durandal_1707> that's what i'm trying to do, remove J
[14:07:54 CEST] <durandal_1707> if there are no more comments for overlay simd i gonna apply it!
[14:35:09 CEST] <durandal_1707> wm4: have you tried that y4m thing?
[15:25:39 CEST] <BBB> atomnuker: the problem of that approach might be that we get chain-conversions with each filter
[15:26:18 CEST] <BBB> atomnuker: imagine that your in/out is bt2020 10bit (full-range), and the first filter supports 8bit rgb and the second only bt709 limited-range yuv 8bit
[15:26:34 CEST] <BBB> atomnuker: and I havent talked about transfer functions or primaries yet
[15:27:12 CEST] <BBB> I think the most important thing (since thats how most filters will work) is to make it default and VERY easy for filters to say I dont care and just proxy my input frame fields to the output)
[15:27:23 CEST] <BBB> e.g. if input is bt709, then output is bt709 etc.
[15:27:48 CEST] <BBB> I think if we do that for all fields, well fix 90% of the use cases already
[15:28:05 CEST] <BBB> second thing is to make sure all filters support 10bit, which is admittedly orthogonal to this, but still
[15:28:28 CEST] <atomnuker> yeah, that'd be alright, most filters don't care about primaries or color ranges
[15:28:37 CEST] <atomnuker> just about pixfmts
[15:28:41 CEST] <BBB> for the few cases where the filter does care about what type of stuff is in the frame, or where in/out is different (e.g. converting bt2020 av1 to vp8), auto-insertion of converion would be nice, yes
[15:29:00 CEST] <atomnuker> btw there seems to be a bug with the vp9 bsf
[15:29:02 CEST] <atomnuker> https://github.com/FFMS/ffms2/pull/323#discussion_r185303842
[15:29:09 CEST] <BBB> and then we need to think of how that auto-inserted conversion filter is implemented, because vittorio is right that swscale is a piece of crap
[15:30:10 CEST] <Chloe> imagine that your in/out is bt2020 10bit (full-range), and the first filter supports 8bit rgb and the second only bt709 limited-range yuv 8bit this sounds fun, i can imagine people would also want to know if they were losing quality by not all filters supporting their  input
[15:30:11 CEST] <BBB> I believe jamrial wrote the vp9 bsf
[15:30:14 CEST] <BBB> I just wrote the decoder
[15:30:23 CEST] <BBB> Chloe: right
[15:30:33 CEST] <nevcairiel> atomnuker: there is no issue, someone just didnt read the api docs on how to handle the api
[15:30:35 CEST] <BBB> Chloe: at the very least auto-inserted filters should be very clearly logged
[15:31:16 CEST] <BBB> Chloe: the worst thing that could happpen is that stuff like that silently works and people start saying crap like ffmpeg quality is actually kind of shitty lately :("
[15:34:41 CEST] <atomnuker> well it would be easy to make the filters not care currently, because that's what they do, except for yuvj
[15:37:34 CEST] <durandal_1707> f* i will committ all my patches!
[15:38:05 CEST] <JEEB> you are clearly frustrated. sit down and let's talk about what is disturbing your peace of mind?
[16:04:25 CEST] <durandal_1707> jamrial: have new comments for overlay patch?
[16:08:32 CEST] <jamrial> durandal_1707: the "da" parameter seems pointless as you either don't use it or overwrite it
[16:12:08 CEST] <durandal_1707> jamrial: it is for future functions
[16:12:27 CEST] <durandal_1707> when main have alpha
[16:12:43 CEST] <jamrial> ok
[16:14:52 CEST] <jamrial> i don't see anything obviously wrong, so make sure there's a fate test for this and it should be good
[16:16:19 CEST] <durandal_1707> jamrial: there are already tests for overlay filter
[16:17:02 CEST] <JEEB> and it passes? zer gut
[16:19:04 CEST] <durandal_1707> as reviewer you must apply, build, install and test it too
[16:20:06 CEST] <BBB> durandal_1707: do you appreciate vittorios comment? I think its good to not just reject it but at least think about what he says a little
[16:24:11 CEST] <durandal_1707> BBB: i appreciate everyones comments, i write all such comments in my diary
[16:25:15 CEST] <Chloe> Doesnt this patchset highlight the bigger issue here: the state of swscale
[16:32:00 CEST] <atomnuker> no, it doesn't
[16:32:12 CEST] <atomnuker> this is just negotiation
[16:32:19 CEST] <atomnuker> and removal of YUVJ formats
[16:37:29 CEST] <atomnuker> but feel free to think it underlines the shortcomings of big bad swscale because someone told you so and because of your misconceptions
[16:44:44 CEST] <BBB> swscale demonstrates that video format conversion has gotten a lot more complex over the years
[16:44:50 CEST] <BBB> it used to just be pixel layout and scaling
[16:44:54 CEST] <BBB> then full vs. limited range
[16:44:56 CEST] <JEEB> yup
[16:45:07 CEST] <BBB> and now its also primaries, colorspace (bt709/2020/etc.), transfer function
[16:45:07 CEST] <JEEB> then colorspaces within the same colorspace families
[16:45:15 CEST] <BBB> in the future well adjust it dynamically for viewing conditions
[16:45:37 CEST] <BBB> I guess swscale handles bitdepth somewhat, although I find the dithering deplorable
[16:45:41 CEST] <BBB> but thats just me
[16:45:52 CEST] <BBB> and people dont like when I say deplorable so maybe I shouldn't
[16:50:52 CEST] <atomnuker> would you rather it shifts without dithering?
[16:51:03 CEST] <atomnuker> there are more than one dithering methods available too
[16:54:06 CEST] <BBB> I would not rather have it shift without dithering
[16:54:16 CEST] <BBB> I would, however, like to have an option to use floyd-steinberg dithering
[16:54:49 CEST] <JEEB> for various stuff I would just point one towards zimg
[16:54:52 CEST] <JEEB> and the zscale filter
[16:55:06 CEST] <BBB> yes, I believe vittorio is a fan of that also
[16:55:19 CEST] <nevcairiel> I just wish zscale had some ARM assembly
[16:55:22 CEST] <JEEB> it's one of those cases "holy crap the eternal IRC troll actually made something quite useful"
[16:55:24 CEST] <nevcairiel> but i'm too dumb to write that
[16:55:25 CEST] <JEEB> *cases of
[16:55:33 CEST] <BBB> Im kind of sad, I was hoping that the colorspace filter would be a good stop-gap fix for that, but unfortunately it just didnt do enough quickly enough
[16:56:21 CEST] <BBB> but Ill admit that zimg does more than colorspace, and it doesnt do it poorly, so thats kind of great
[16:56:51 CEST] <BBB> (my sarcasm there is just me being northern-dutch, not me being negative about zimg or anything)
[16:57:43 CEST] <atomnuker> JEEB: would you not?
[16:57:56 CEST] <atomnuker> _stop_ flogging that thing here or on #ffmpeg
[16:58:01 CEST] <JEEB> eh?
[16:58:15 CEST] <JEEB> it seems to be doing a better job than swscale
[16:58:15 CEST] <atomnuker> you always mention it whenever someone asks about conversions
[16:58:25 CEST] <JEEB> if I'm incorrect then sure
[16:58:38 CEST] <nevcairiel> its definitely much better then anything we have
[16:58:40 CEST] <atomnuker> define better
[16:58:51 CEST] <BBB> atomnuker: what do you want us to do? recommend swscale?
[16:58:53 CEST] <atomnuker> I understand if its for some complicated niche conversion
[16:58:55 CEST] <BBB> or fix swscale?
[16:59:05 CEST] <BBB> or something else?
[16:59:15 CEST] <JEEB> yes, for just plain scaling it might be OK, not sure if swscale does linear gamma
[16:59:23 CEST] <nevcairiel> it does not
[16:59:35 CEST] <atomnuker> stop flogging it unless its necessary, like a conversion which swscale isn't fast at or is plain wrong at
[16:59:41 CEST] <JEEB> sure
[16:59:55 CEST] <JEEB> but we were specifically talking about colormatrix/transfer function/resolution
[17:00:03 CEST] <JEEB> and while you could have 2 filters do some of that
[17:00:09 CEST] <JEEB> BBB's and swscale
[17:00:13 CEST] <JEEB> (when used together)
[17:00:24 CEST] <JEEB> w/34
[17:00:46 CEST] <JEEB> also isn't "flogging" basically hitting someone in the back with a whip or something?
[17:01:27 CEST] <JEEB> anyways, colorspaces|transfer matrices etc. were *specifically* mentioned
[17:01:40 CEST] <JEEB> so I don't get it why you're so mad
[17:02:01 CEST] <JEEB> and yes, I use swscale myself at times because nobody cares if some things are 100% correct with gamma-correct scaling and shit
[17:02:37 CEST] <JEEB> but as soon as we start caring about that as being 'the baseline' then we only have zimg and libplacebo (whenever that gets ready)
[17:02:43 CEST] <JEEB> that do these things correctly
[17:13:07 CEST] <atomnuker> you offer zimg to people who don't have a need for it and won't solve their problem
[17:13:16 CEST] <atomnuker> and whenever the topic arises you can't help but mention it
[17:15:12 CEST] <JEEB> when was it in cases where it will not do what they need?
[17:20:44 CEST] <atomnuker> a time or two on #ffmpeg
[17:21:07 CEST] <JEEB> right. in a case where they didn't need scaling or colorspace conversion?
[17:21:34 CEST] <atomnuker> yes
[17:21:40 CEST] <JEEB> ok
[17:21:46 CEST] <JEEB> then that was incorrect of course
[17:21:54 CEST] <JEEB> but it's quite surprising I would recommend it in that case
[17:22:02 CEST] <JEEB> but sure, I'm not perfect and probably an asshole too
[17:23:54 CEST] <JEEB> but I find this thing pretty derpy that you start herping a derp at me when specifically these technicalities of how colorimetry has become more complex was the goddamn theme
[17:24:13 CEST] <wm4> durandal_1707: you never sent me a sample file, and the one I made seemed ok
[17:50:17 CEST] <durandal_1707> wm4: you sure it is hd1080 and long enough?
[17:50:20 CEST] <BBB> JEEB: colorspace; colormatrix is the older (8bit only) filter from baptiste
[17:50:48 CEST] <JEEB> yea, I remember there were two but always get them wrong :P
[17:51:02 CEST] <wm4> durandal_1707: I can't do anything with this statement and I won't try to guess what the heck you mean either
[17:54:31 CEST] <durandal_1707> wm4: this one: https://media.xiph.org/video/derf/y4m/sunflower_1080p25.y4m , with 500 frames, backstepping from end show hourglass
[17:54:53 CEST] <durandal_1707> just any hd1080 y4m with 500 frames will do
[17:55:18 CEST] <durandal_1707> you need to have , pressed all the time
[17:55:34 CEST] <wm4> are you sure you got the right player, mpv doesn't render hourglass cursors
[17:55:45 CEST] <wm4>             To reduce wasted bandwidth from poorly-behaved scrapers and web
[17:55:45 CEST] <wm4>             crawlers, please verify below that you intend to download a very
[17:55:45 CEST] <wm4>             large file.
[17:55:50 CEST] <wm4> is what I get with wget
[17:56:36 CEST] <durandal_1707> wm4: ffmpeg -f lavfi -i testsrc2=size=hd1080 -vframes=500 out.y4m 
[17:56:59 CEST] <wm4> Unrecognized option 'vframes=500'.
[17:57:00 CEST] <wm4> Error splitting the argument list: Option not found
[17:57:40 CEST] <BBB> JEEB: its ok, close enough
[17:57:51 CEST] <BBB> wm4: -vframes <space> 500
[17:58:16 CEST] <BBB> remember, ffmpeg has its own NIH getopt_long implementation that has many more features and is much more consistent
[17:58:17 CEST] <durandal_1707> see, i mixed mpv synthax with ffmpeg one
[17:58:43 CEST] <JEEB> mpv doesn't do singular dashes
[17:58:48 CEST] <JEEB> as far as I know :P
[18:21:59 CEST] <wm4> durandal_1707: seemingly, seeking will sporadically not work (from mpv's perspective the demuxer seek is broken)
[18:22:47 CEST] <wm4> durandal_1707: so libavformat will somehow seek to the start instead, and the backstepping will decode _all_ frames until the target
[18:29:15 CEST] <durandal_1707> wm4: and with my patch it is instant
[18:34:47 CEST] <wm4> that just means the current code is even more broken
[18:35:04 CEST] <wm4> but your new code is not entirely correct
[18:38:00 CEST] <durandal_1707> wm4: i just need to add FFMAX(pts, 0)
[18:59:43 CEST] <atomnuker> why are there 2 sets of arnr options for libvpx...
[19:00:07 CEST] <atomnuker> -arnr-maxframes, -arnr-strength, -arnr-type
[19:00:18 CEST] <atomnuker> -arnr_max_frames, -arnr_strength, -arnr_type
[19:02:27 CEST] <jamrial> "legacy" and "common" options. same reason quality and deadline are the same option, or cpu-used and speed
[19:03:03 CEST] <jamrial> things just piled up around the time vp9 encoding was added
[19:08:08 CEST] <atomnuker> has it been long enough to remove them?
[19:11:08 CEST] <jamrial> they are not deprecated, though
[19:11:59 CEST] <atomnuker> the common ones were added 5 years ago
[19:12:33 CEST] <atomnuker> well why weren't they deprecated? could people not decide which ones they wanted?
[19:12:59 CEST] <atomnuker> even weirder is that the common ones have the "-" sign but the older ones as well as most vpx options have an underscore
[19:13:50 CEST] <atomnuker> actually the opposite, the common ones blend in better
[19:30:35 CEST] <JEEB> https://lwn.net/Articles/753284/
[19:30:37 CEST] <JEEB> gcc 8.1 out
[19:31:29 CEST] <wm4> old
[19:31:40 CEST] <JEEB> sure :) just noticed it on LWN
[19:32:11 CEST] <wm4> gawd there's already c++-2a
[19:32:14 CEST] <wm4> (why "a")
[19:33:18 CEST] <nevcairiel> it was 1z and the overflow from z is a
[19:33:44 CEST] <nevcairiel> 0x, 1z, 2a
[19:33:55 CEST] <nevcairiel> hm wonder what happened to y
[19:34:30 CEST] <nevcairiel> oh it existed
[19:34:42 CEST] <nevcairiel> 0x became 11, 1y became 14, 1z is becoming 17
[19:34:45 CEST] <nevcairiel> 2a probably 21?
[19:35:02 CEST] <nevcairiel> maybe 20
[19:35:06 CEST] <nevcairiel> who knows when they finish it
[19:37:02 CEST] <jamrial> 1z is 17, not becoming
[19:37:21 CEST] <nevcairiel> is that fully and finally ratified yet
[19:37:26 CEST] <jamrial> it's finished, but the supposed juicy parts were postponed for 2x
[19:37:52 CEST] <nevcairiel> since 11 they havent really messed with the core much anymore anyway, just piling features on
[19:39:05 CEST] <nevcairiel> gcc 8.1 only claims experimental support for c++17, must be a mess to get it in fully, they are usually faster then that
[19:39:53 CEST] <jamrial> yeah
[19:40:41 CEST] <wm4> does 2a finally add concepts?
[19:40:43 CEST] Action: wm4 lols
[19:41:02 CEST] <nevcairiel> its in the draft for it yes
[19:42:00 CEST] <jamrial> gcc 5 came out in 2014 and was already c++14 feature complete, for example
[19:42:38 CEST] <jamrial> actually no, early 2015, but still
[19:42:55 CEST] <wm4> I wonder if they'll fix the completely broken C99 designated initializers
[19:46:01 CEST] <BBB> whats broken about it?
[19:47:00 CEST] <wm4> compiler enforces the same order as declaration, and array syntax doesn't work
[20:04:13 CEST] <rcombs> string literals as template parameters are interesting, and there's a proposal to add std::fmt
[20:04:34 CEST] <rcombs> which would be based on fmtlib, and do type-safe (sn)printf
[20:05:10 CEST] <rcombs> possibly including compile-time format-string parsing
[20:05:34 CEST] <nevcairiel> some C compilers already do that to throw warnings at you
[20:07:31 CEST] <rcombs> nevcairiel: yeah but then the libc parses it again at runtime
[20:07:53 CEST] <nevcairiel> i guess if it can store it to kenized during compilation or so that might be neat
[20:07:54 CEST] <rcombs> (twice for asprintf)
[20:07:58 CEST] <nevcairiel> tokenized*
[20:08:09 CEST] <rcombs> yeah
[20:08:18 CEST] <rcombs> there's a proposal for compile-time code that emits runtime code
[20:08:42 CEST] <rcombs> with the compile-time code having really extensive introspection/reflection capability
[20:08:51 CEST] <rcombs> like, "iterate class members" and such
[20:09:02 CEST] <wm4> D did that years ago and it was a shitball
[20:10:13 CEST] <rcombs> so compile-time format strings would move the parser loop to compile-time and emit e.g. "print N characters, then format an int, then print N more characters, then format a float", etc, as C++ code
[20:12:09 CEST] <rcombs> the nice thing about fmtlib over printf as-is is that it supports arbitrary C++ types; you can define a formatter function or any given type (and if you don't it'll use the ostream<< one)
[20:12:16 CEST] <rcombs> so you can spit out string, path, etc
[20:13:26 CEST] <rcombs> I still hate std::filesystem::path for trying to force MS's bullshit on me
[20:13:40 CEST] <wm4> could be sort of done with C if anyone cared
[20:14:07 CEST] <rcombs> path::path(string) converts from [process codepage] to UTF-16; path::string() converts from UTF-16 to [process codepage]
[20:14:36 CEST] <rcombs> at least with boost::filesystem::path I can set an override to make it use UTF-8 instead of [process codepage]
[20:14:56 CEST] <rcombs> "but rcombs, that adds global state" yeah fuckwit what do you think the process codepage is
[20:15:06 CEST] <wm4> also I don't get why paths would need special formatting
[20:15:22 CEST] <rcombs> wm4: they don't, it's just another type that isn't char*
[20:15:37 CEST] <rcombs> the formatter for it just takes the string
[20:15:52 CEST] <rcombs> (the path class is just a wrapper around std::string [or std::wstring if your platform sucks])
[20:16:49 CEST] <wm4> oh, so C++ solving C++ made problems
[20:17:25 CEST] <rcombs> eh, it's a useful wrapper
[20:17:40 CEST] <wm4> totally
[20:17:55 CEST] <wm4> I mean I know what code you're talking about, so I don't have to believe you
[20:17:56 CEST] <rcombs> stuff like operator/ to join adding a separator, functions to extract the filename, stem, etc
[20:26:26 CEST] <wm4> you could just use, you know, functions for that
[20:37:21 CEST] <atomnuker> wm4: read what I write next time
[20:37:39 CEST] <TD-Linux> rcombs, most c compilers can special case printf and emit calls to special minimize versions that don't do full parsing
[20:37:59 CEST] <rcombs> huh, really?
[20:38:12 CEST] <rcombs> like, for non-trivial cases?
[20:38:48 CEST] <wm4> atomnuker: how did I offend you now
[20:39:13 CEST] <nevcairiel> nevermind him, he is just extra obnoxious today
[20:39:26 CEST] <TD-Linux> I'm not sure exactly, I know printf("%s", x) gets reduced and I've seen more specific ones show up in disassembly
[20:40:13 CEST] <rcombs> yeah I know about that one
[20:40:28 CEST] <wm4> oh, so me mentioning HDMI was offensive because it's already covered by "broadcasting junk"
[20:40:30 CEST] <wm4> well whatever
[20:40:34 CEST] <TD-Linux> it's a builtin function so in theory it can do anything
[20:40:58 CEST] <rcombs> yeah, though usually it ends up just being a bog-standard variadic function call
[20:43:50 CEST] <TD-Linux> rcombs, huh it looks like latest gcc actually has a full "printf compiler" and emits custom code for each printf call https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-ssa-sprintf.c
[20:43:58 CEST] <rcombs> oh huh
[20:45:04 CEST] <rcombs> that looks like it's just used for warnings and constants, though?
[20:45:39 CEST] <atomnuker> nevcairiel: I'm frustrated such an idea could even be proposed by someone in our circles
[20:53:13 CEST] <TD-Linux> rcombs, yeah you're right. the actual folding happens here. I assumed it being in gimple would mean a full compiler, but it's just a bunch of special cases. https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-fold.c#L3108
[20:55:09 CEST] <rcombs> yeah, that's still just the "no %" and "just %s" special cases
[20:55:26 CEST] <rcombs> which is nice but not especially broad
[23:17:13 CEST] <atomnuker> michaelni: could you please okay that libxvid_rc patch?
[23:17:20 CEST] <atomnuker> you're listed as maintainer
[23:19:30 CEST] <durandal_1707> he is busy finding case where that code is useful
[23:20:19 CEST] <atomnuker> or maybe he's formulating a new branch of psychology to try to understand carl's objection to the commit message
[23:20:43 CEST] <atomnuker> like myself, because I don't understand what he's complaining about
[23:20:54 CEST] <atomnuker> sentence by sentence, each statement is the truth
[23:22:23 CEST] <jamrial> he probably doesn't like the commit message is too agressive, saying only misled people used that feature and such
[23:26:20 CEST] <j-b> I kind of agree on the commit message. However, the commit in itself is fine.
[23:26:49 CEST] <BBB> I find the commit message aggressive, but so is his opposition to it
[23:27:03 CEST] <BBB> both could display some more manners and common sense :-/
[23:27:29 CEST] <j-b> well, it's also very easy to say "Commit OK, please reformulate commit message" and end the discussion
[23:27:52 CEST] <BBB> +1
[23:36:19 CEST] <durandal_1707> Gramner: i will add you to copyright as you did it too
[23:36:48 CEST] <Gramner> ok, sure
[23:51:34 CEST] <jkqxz> I feel like I must have missed something here.  How is one meant to distinguish between the H.265 profiles with the same profile_idc and constraint flags?  E.g. "Screen-Extended High Throughput 4:4:4 10" and "Screen-Extended 4:4:4 10".
[23:52:13 CEST] <JEEB> wasn't there also a tier flag?
[23:52:16 CEST] <JEEB> or something
[23:53:11 CEST] <jkqxz> I don't think the tier flag makes a difference?
[23:53:36 CEST] <jamrial> wasn't there a huge compat table or some such?
[23:53:38 CEST] <jkqxz> It looks like it only modifies the level constraints (after you know the profile).
[23:53:59 CEST] <JEEB> ah
[23:58:24 CEST] <jkqxz> There are a few other differences like the high throughput profiles allowing 4:2:2 and combining of tiles with entropy-coding-sync, but those are optional so can't be used to distinguish them.
[23:59:52 CEST] <jkqxz> jamrial:  The relevant rows of the huge table (table A.5 is the relevant part of it) are identical for the two profiles.
[23:59:59 CEST] <jamrial> i see
[00:00:00 CEST] --- Thu May  3 2018