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

[burek]

[00:27:55 CEST] <Chloe> Does ffmpeg support mpeg 4 structured audio?
[00:28:13 CEST] <Chloe> I just found out about it, looks pretty crazy
[00:28:38 CEST] <nevcairiel> probably not
[00:29:06 CEST] <nevcairiel> sounds like one of those pipe-dream formats that never saw any use
[00:29:08 CEST] <Chloe> Does anything even use it
[01:36:33 CEST] <cone-616> ffmpeg 03Martin Storsjö 07master:847190ebd99f: configure: Don't assume an aligned stack on clang on windows
[01:36:34 CEST] <cone-616> ffmpeg 03Zhong Li 07master:3d6e76b953af: qsvenc: Fix a typo of FrameRateExtD/FrameRateExtN
[01:36:35 CEST] <cone-616> ffmpeg 03Zhong Li 07master:deefca02c275: qsvenc: add the Access Unit Delimiter NAL Unit support
[01:36:36 CEST] <cone-616> ffmpeg 03James Almer 07master:7e3c4d029b8e: Merge commit '847190ebd99ffd57dc89bd568a33bf2d5c424129'
[01:36:37 CEST] <cone-616> ffmpeg 03James Almer 07master:20608261f781: Merge commit '3d6e76b953afd36e23ef8532b81aea58a6338931'
[01:36:38 CEST] <cone-616> ffmpeg 03James Almer 07master:b065c71e9d2a: Merge commit 'deefca02c275ce4bc5ccbee690463ffef81a18b8'
[01:42:50 CEST] <cone-616> ffmpeg 03Martin Storsjö 07master:ea2f72a2c14c: configure: Don't assume a 16 byte aligned stack on BSDs on i386
[01:42:51 CEST] <cone-616> ffmpeg 03James Almer 07master:23f447294487: Merge commit 'ea2f72a2c14c67a3b35dac6426d1e3c0fae33fd5'
[02:02:50 CEST] <cone-616> ffmpeg 03Ruiling Song 07master:86499771d122: qsv: align surface width/height to 16.
[02:02:51 CEST] <cone-616> ffmpeg 03James Almer 07master:be6749c7190e: Merge commit '86499771d1228d8303c8eb6509e20c0caaa02da5'
[02:04:17 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:5292e97c42b0: configure: Document available options for the --toolchain parameter
[02:04:18 CEST] <cone-616> ffmpeg 03James Almer 07master:44df2e858889: Merge commit '5292e97c42b05db7ad4e51c1ea756b12fdf721ff'
[02:13:16 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:b9ea301e0247: configure: Use a more sensible suffix for x86 assembly tempfiles
[02:13:17 CEST] <cone-616> ffmpeg 03James Almer 07master:3bbec8e7c20b: Merge commit 'b9ea301e02472d0982b0fa0f80294bd95885bde8'
[02:17:38 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:17ee5b0c13bc: configure: Use indirection for the -o assembler flag also for x86asm
[02:17:39 CEST] <cone-616> ffmpeg 03James Almer 07master:91bcf0b8cdb3: Merge commit '17ee5b0c13bc17465b71bc9ca1cde9f0eed8b3ff'
[02:29:12 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:8c7554e6a9b1: configure: Add check_x86asm() helper function to simplify some expressions
[02:29:13 CEST] <cone-616> ffmpeg 03James Almer 07master:e46fab0f3cfb: Merge commit '8c7554e6a9b126bd6ee5bf80dae9e11e056db2f1'
[02:31:13 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:434b44cd6fb4: configure: Simplify vararg check
[02:31:14 CEST] <cone-616> ffmpeg 03James Almer 07master:75bf51ef87f4: Merge commit '434b44cd6fb4bb9a2bf2bb29ef55ce1a315314b8'
[02:59:45 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:2124a97a4998: configure: Drop unused helper function test_cflags_cpp()
[02:59:46 CEST] <cone-616> ffmpeg 03Sven Dueking 07master:a2fc8dbae853: Add Haivision SRT protocol
[02:59:47 CEST] <cone-616> ffmpeg 03James Almer 07master:a959e38f7a71: Merge commit '2124a97a4998413c7e81539b16b01ef6ac570ea9'
[02:59:48 CEST] <cone-616> ffmpeg 03James Almer 07master:a123e576a485: Merge commit 'a2fc8dbae85339d1b418d296f2982b6c04c53c57'
[03:08:44 CEST] <atomnuker> jamrial: dude, libsrt wasn't approved for merging by anyone
[03:08:49 CEST] <atomnuker> can you revert it?
[03:09:47 CEST] <jamrial> atomnuker: neither was every other module merged during the past seven years. i'm not sure what's special about this one
[03:10:55 CEST] <atomnuker> well its one company trying to push their NIH protocol and I'm not sure that's what we should be promoting
[03:11:29 CEST] <atomnuker> and I'm not the only one who finds the whole srt thing silly
[03:12:55 CEST] <jamrial> ok, if others agree we don't want it i'll revert it
[03:13:56 CEST] <atomnuker> kierank and tmatth had some opinions about it
[03:14:56 CEST] <atomnuker> in fact just revert it now and lets have this discussion on the ML
[03:19:19 CEST] <wm4> lol atomnuker learning what merges from libav are
[03:19:36 CEST] <wm4> atomnuker: you can send a patch to remove it
[03:19:38 CEST] <atomnuker> fine, I guess it can stay until someone responds as well
[03:20:21 CEST] <atomnuker> wm4: that's what they might have been but you don't get a carte blanche to do whatever you want because they merged something
[03:20:30 CEST] <jamrial> i mean, if it's really disliked by most devs then i'll revert it
[03:21:08 CEST] <atomnuker> jamrial: its a proprietary protocol which hadn't had a proper discussion on the ML and against which I expressed disagreement
[03:21:14 CEST] <jamrial> i have zero interest about this thing, i just merged it because it was in the queue and it looked like a pretty standard external wrapper
[03:21:54 CEST] <atomnuker> well its a bit more than that, now these companies are going to go around NAB yelling "HEY THEY MERGED OUR CRAPPY NIH TCP OVER UDP ITS REAL NOW, GIVE US MONEY"
[03:22:30 CEST] <atomnuker> I mean sure its likely it'll become a widely used standard for some kinda wrong reasons
[03:23:14 CEST] <atomnuker> ah well, its kinda like some other protocols we support so its alright
[03:23:54 CEST] <wm4> jamrial: so far we have 1 devs
[03:24:11 CEST] <atomnuker> who has mixed feelings about it
[03:26:46 CEST] <jkqxz> It might be an NIHed package of awfulness with the most unhelpful name ever but that doesn't change the fact that a load of people do use it.
[03:27:22 CEST] <jkqxz> (It's already in VLC too.)
[03:27:59 CEST] <wm4> lol really
[03:28:17 CEST] <wm4> does any site use it? or is it outside of that use case
[03:28:38 CEST] <jkqxz> So while it's pretty nasty I don't really think there are grounds for not having it unless there are actual technical objections to the wrapper.
[03:28:38 CEST] <atomnuker> vlc will literaly take any wrapper you send patches for
[03:28:39 CEST] <atomnuker> they still have a daala one
[03:31:56 CEST] <atomnuker> wm4: its not that type of protocol, maybe some websites would use it if it becomes an IETF standard but until then its point to point for programs that support it
[03:33:28 CEST] <atomnuker> and its probably not going to become an IETF standard because the IETF still has a few sane people who'll see that the companies who are part of the alliance still hold rights over the patents
[03:35:35 CEST] <atomnuker> so as far as I can tell its not really royalty free unlike aom
[03:36:00 CEST] <JEEB> I think the two "pro" protocols that popped up recently were NDI (?) and SRT
[03:36:49 CEST] <JEEB> and don't we actually have NDI merged already? since I learned of it on #ffmpeg when someone was asking why nobody distributes it in binaries
[03:37:02 CEST] <JEEB> (because people want GPL components and Newtek NDI is closed source)
[03:37:09 CEST] <JEEB> -> nonfree
[03:37:19 CEST] <JEEB> it even has the balls to call it a "standard"
[03:37:22 CEST] <JEEB> https://www.newtek.com/ndi/
[03:37:22 CEST] <cone-890> ffmpeg 03James Almer 07master:c42c99c3e5ac: avcodec/libaomenc: use av_assert0()
[03:54:02 CEST] <atomnuker> JEEB: we have ndi but isn't that for actual devices?
[03:54:10 CEST] <atomnuker> like capture cards
[04:20:05 CEST] <philipl> wm4: You happy with the updated movtextenc diff I posted?
[04:21:34 CEST] <wm4> philipl: yeah
[04:21:45 CEST] <wm4> at least it looks right
[05:19:36 CEST] <atomnuker> sent a +3000 line patchset for Vulkan support if anyone's interested
[05:38:35 CEST] <jamrial> atomnuker: if it needs the latest Vulkan api, shouldn't the configure check make sure of that?
[05:40:02 CEST] <jamrial> either VK_API_VERSION_1_0 or VK_HEADER_VERSION >= $version, whichever works best
[05:44:05 CEST] <philipl> wm4: Thanks. I tested it.
[05:47:39 CEST] <atomnuker> jamrial: yeah, I was wondering how to do that using check_lib, thanks
[05:49:43 CEST] <jamrial> atomnuker: you can use check_cpp_condition() for it
[05:51:55 CEST] <jamrial> like, check_lib ... && check_cpp_condition vulkan vulkan/vulkan.h "VK_HEADER_VERSION >= 65"
[05:52:24 CEST] <jamrial> also, move it to the correct section, same as opencl and most external deps
[05:54:39 CEST] <jamrial> actually, test_cpp_condition ... || die "custom error message"
[05:54:40 CEST] <jamrial> much like opencl
[05:55:36 CEST] <cone-890> ffmpeg 03Philip Langdale 07master:af043b839c38: movtextenc: fix handling of utf-8 subtitles
[10:01:04 CEST] <liyou> what is the mean of 'last_vis_time'?
[10:02:47 CEST] <liyou> anyone there?
[10:16:51 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:91bb87137673: avcodec/mpc8: check for overread first
[10:16:52 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:0b86ea03d841: avcodec/ac3: fix out of array access introduced previously
[10:20:03 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:9b22417de680: fate: add eac3_core bitstream filter test
[12:02:36 CEST] <cone-586> ffmpeg 03Carl Eugen Hoyos 07master:11f8f9547dbf: fftools/ffmpeg: Remove an unused variable.
[13:01:45 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:cc402282551d: avcodec/mpc8: check for overread earlier and abort decoding frame
[13:01:46 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:e30a37e95e43: avcodec/mpc8: get frame output buffer right before it is actually needed
[15:00:28 CEST] <jya> anyhow with access to a h264 analysing tool? wondering what's with the encoding of this file: https://raw.githubusercontent.com/jyavenard/htmltests/master/mediatest/fragmented/1426818/1426818.mp4 
[15:00:40 CEST] <jya> plays fine with ffmpeg, but not Apple Video Toolbox
[15:06:09 CEST] <klaxa> atomnuker: carl sent me an email last night stating i definitely need a qualification task, do you know of something that would make sense for me to do?
[15:09:49 CEST] <durandal_1707> klaxa: fix mpegts demuxer
[15:18:38 CEST] <durandal_1707> or pcm/mlp in mpegps
[15:19:41 CEST] <BodecsB> <durandal_1707> I have sent the live switch app into devel mailing list we talked about some days ago
[15:19:55 CEST] <durandal_1707> BodecsB: yes, i noticed
[15:20:06 CEST] <BodecsB> I revised the code
[15:20:22 CEST] <BodecsB> that i originally showed you
[15:25:17 CEST] <jya> in that video, the AUD NAL make up for the entire content... never seen that.. why is ffmpeg playing that crap?
[15:25:42 CEST] <nevcairiel> AUD NALs have no content, are you sure you're not reading it wrong
[15:26:01 CEST] <jya> nevcairiel: I'm fairly sure.
[15:27:12 CEST] <jya> the first packet demuxed is a NAL type 9 (AUD) and has a size of 22382 bytes
[15:39:39 CEST] <jya> BBB: that looks like a typo in that code: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9block.c#L450
[15:40:13 CEST] <BBB> what is the typo?
[15:40:21 CEST] <jya> https://bugzilla.mozilla.org/show_bug.cgi?id=1432857
[15:40:34 CEST] <jya> "(warning) Opposite inner 'if' condition leads to a dead code block."
[15:41:04 CEST] <jya> oh sorry, wrong line: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9block.c#L471
[15:41:52 CEST] <BBB> oh, and 464 also
[15:41:53 CEST] <BBB> yes
[15:42:01 CEST] <BBB> these two leading if statements can probably be removed
[15:42:14 CEST] <jya> line 490 and 502 are also there
[15:42:26 CEST] <jya> if 490 is true, then you can never get to 502
[15:42:55 CEST] <BBB> you will need some testing to verify results are the same
[15:42:57 CEST] <BBB> but yes, possibly
[15:43:11 CEST] <jya> well, if "if (td->left_intra_ctx[row7]) {" is true
[15:43:25 CEST] <jya> you can never end up in a else where you would need to test if (td->left_intra_ctx[row7]) { again
[15:43:46 CEST] <jya> that's just me glancing at the code, with no clue what it's doing :)
[15:44:37 CEST] <BBB> 502 is duplicate, yes
[15:44:54 CEST] <BBB> I was thinking more of structuring 491 like the block earlier on, as part of the have_l/a condition
[15:44:56 CEST] <BBB> and then remove both
[15:44:59 CEST] <BBB> but I dont think you can do that
[15:45:39 CEST] <BBB> all this stuff is really weird
[15:45:44 CEST] <BBB> please submit patch :)
[15:45:54 CEST] <BBB> I think youre right, yes, and a simple patch is probably best
[15:46:01 CEST] <BBB> to just remove the dead code blocks
[15:46:03 CEST] <BBB> 3x2lines
[16:44:27 CEST] <atomnuker> durandal_1707: fine, if you want something more interesting you get something more interesting
[16:44:33 CEST] <atomnuker> here's a chromatic aberration filter as promised
[16:54:28 CEST] <durandal_1707> atomnuker: nice
[17:10:03 CEST] <atomnuker> jya: that's messed up
[17:10:16 CEST] <atomnuker> you want accessors for every single avctx member?
[17:10:33 CEST] <jya> atomnuker: well yes :) 
[17:10:46 CEST] <nevcairiel> jya: looks like its one of those crazy files where someone muxed h264 annexb into mp4 but blindly assumed that every packet  contains only one NAL, find the muxer tht did this and yell at them
[17:11:58 CEST] <jya> atomnuker: right now, to support different version of libavcodec (all the way from 53!!) we have a bit of a hacking method using multiple includes for each version, and different class of the loader, so that the ABI mostly work with an independent code.
[17:12:05 CEST] <atomnuker> jya: well you can't have 'em, we keep a stable ABI for your convenience and our pain
[17:12:34 CEST] <BBB> jya: I think weve tried accessors in the past and they were largely disliked
[17:12:34 CEST] <atomnuker> more than 2 years in between breaking is sufficient
[17:12:43 CEST] <jya> I'd like to stop doing so in 58... So we can have a single code, the will support multiple future version of libavcodec
[17:13:39 CEST] <jya> the current 58, width/height have moved for example... that's okay, there's an accessor
[17:13:55 CEST] <nevcairiel> between different major versions, fields arent the only thing that can change, so can constants
[17:13:57 CEST] <jya> but some don't.. I didn't make a long list :)
[17:14:03 CEST] <nevcairiel> its not something we will invest in our codebase to support
[17:14:21 CEST] <nevcairiel> thats the entire point of changing the major version, its inherently incompatible
[17:14:47 CEST] <jya> nevcairiel: it's very messed up that video, but ffmpeg plays it, which makes chrome play it... And now I have people whining that chrome can play their video when firefox can't
[17:15:22 CEST] <nevcairiel> we try to play files if its not too huge of a hack to do so, and this wasnt
[17:15:53 CEST] <jya> nevcairiel: but the issue isn't just a matter of major version, depending on define, the structure can change... so you can't guarantee what the ABI will be
[17:16:25 CEST] <nevcairiel> so build against the header file that comes w ith the  library
[17:16:28 CEST] <nevcairiel> its not rocket science
[17:16:48 CEST] <nevcairiel> (also, anyone that publicly ships a library with any of those defines set is probably out for a world of pain)
[17:17:11 CEST] <nevcairiel> they are a development tool, not flags for users to change, really
[17:17:33 CEST] <jya> nevcairiel: it is unfortunately not possible to ship multiple version of our code, for all version of ffmpeg lib out there.
[17:17:45 CEST] <jya> and we can't ship our own copy of ffmpeg
[17:17:59 CEST] <nevcairiel> and its not possible for us to accomodate such requirements
[17:18:02 CEST] <jya> obviously that would have been my preferred solution
[17:18:02 CEST] <nevcairiel> so guess we're stuck
[17:18:49 CEST] <jya> you find that the 4 fields I mentioned are unreasonable to provide?
[17:18:58 CEST] <jya> (I can do without opaque)
[17:19:14 CEST] <jya> I'm happy to submit a patch for those 4
[17:19:29 CEST] <nevcairiel> basically, yes, since we're actively working in the opposite direction
[17:19:53 CEST] <jya> and what direction is that?
[17:20:12 CEST] <nevcairiel> less accessors, cleaner structs without half-private fields and the like
[17:20:31 CEST] <jya> whenever in the past I had mentioned about ABI , the answer as always : use AVOptions, and now you're telling me , don't use AVOptions... can't win
[17:21:02 CEST] <nevcairiel> you're free to use avoptions, but those fields there probably dont work through the option api
[17:21:09 CEST] <nevcairiel> because its complex data
[17:21:12 CEST] <jya> if you guys can't even make your mind about what direction to use or if that fluctuate from one month to the next
[17:23:08 CEST] <jya> when is 58 version going to be stable? I'd like to add support for this version and not having to rush because suddenly libavcodec.58 is out.
[17:31:41 CEST] <jya> nevcairiel: for the record, this was our bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1435212 
[17:55:59 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commits/vc2enc_new_transforms2
[17:56:45 CEST] <jdarnley> kierank: do you know anyone else who might be able to find the issue at the top of the planes?
[17:57:10 CEST] <kierank> nope, i can look maybe at the weekend
[18:00:09 CEST] <jdarnley> okay, here is an easy way to see the problem
[18:01:45 CEST] <jdarnley> ./ffmpeg -f lavfi -i 'testsrc2=hd720, format=yuv422p10' -vframes 1 -vcodec vc2 -wavelet_type 5_3 -y temp.mov
[18:03:11 CEST] <jdarnley> ./ffplay -f lavfi 'movie=temp.mov [a]; testsrc2=hd720, format=yuv422p10 [b]; [a][b] blend=all_mode=differencemax:shortest=1'
[18:25:30 CEST] <JEEB> was there anyone here versed in how sub2video is designed to work?
[18:26:54 CEST] <JEEB> as O
[18:27:42 CEST] <JEEB> as I'm not sure which way something should be improved in it to fix overlaying of subtitles after a filter chain re-init/config
[18:29:58 CEST] <JEEB> I have one fix, which seems to break the weirdly VFR FATE test (although I do not change the fact that the nullptr packets get pushed forward). then I have two alternative places to stop unwated PTS=INT64_MAX packets from going into the overlay input at all, which doesn't seem to break the FATE test, but on the other hand not sure at which level I should be stopping them
[18:49:37 CEST] <jamrial> durandal_1707: want me to add a test for the new eac3 file? similar to the other four existing tests
[18:49:52 CEST] <durandal_1707> JEEB: i just fixed 3years old mpeg-ps bug report, so you can do it too
[18:50:07 CEST] <durandal_1707> jamrial: that needs pcm file?
[18:50:09 CEST] <jamrial> assuming the decoded output is ok and will (hopefully) not change, to avoid having to upload a new .pcm file in the future
[18:50:10 CEST] <jamrial> yeah
[18:50:52 CEST] <jamrial> durandal_1707: https://pastebin.com/RcPRxkaH
[18:51:03 CEST] <durandal_1707> jamrial: go ahead, i have not planned to do it, just because I have no other hw to test
[18:51:32 CEST] <JEEB> durandal_1707: I mean I already fixed my sample ages ago :D
[18:51:45 CEST] <JEEB> and it works just fine in a 24/7 stream seemingly
[18:51:49 CEST] <jamrial> i created the .pcm file on an x86_32 build using no asm functions, so it's all x87 floats
[18:52:09 CEST] <JEEB> durandal_1707: basically http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227598.html
[18:52:31 CEST] <JEEB> my initial fix didn't change the fact that the subtitle update thing gets pushed to the end
[18:52:55 CEST] <JEEB> just that it no longer can push nullptr AVSubtitles which would end up being INT64_MAX
[18:53:07 CEST] <JEEB> because that would EOF the filter input
[18:53:23 CEST] <JEEB> then there's of course just not pushing those packets out, and there's two possible places to do that at
[18:58:32 CEST] <durandal_1707> JEEB: if output of subtitle overlaying is same before and after your patch i see nothing wrong
[18:59:14 CEST] <JEEB> with normal stuff it doesn't seem to do anything wrong, although I've only visually verified it with the sample I have
[18:59:18 CEST] <JEEB> the test is weirdly VFR and low frame rate
[18:59:30 CEST] <JEEB> like, I would expect CFR from a rawvideo source at a set frame rate
[19:00:16 CEST] <JEEB> and yes, the test drops one overlayed subtitle at the 5fps mark, but I don't know where the issue is. is it my patch, or is it some underlying issue that my patch is bringing up while fixing something else
[19:02:54 CEST] <durandal_1707> JEEB: have you checked is it because pts is now something else?
[19:03:39 CEST] <JEEB> I could add some logging at the timestamps of AVFrames pushed into / received from the filter chain, but the primary input is not changed at all with this
[19:04:28 CEST] <atomnuker> jkqxz: could you make vaapi drm exporting swap U and V planes for yuv420p?
[19:08:54 CEST] <cone-586> ffmpeg 03James Almer 07master:53937c437105: fate: add test for eac3 dependant stream
[20:33:56 CEST] <kierank> jamrial: ?
[20:34:07 CEST] <kierank> why do I get things I don't have on my system autodetected
[20:34:20 CEST] <nevcairiel> you dont anymore anyway
[20:34:28 CEST] <nevcairiel> the headers are now required to be installed
[20:34:37 CEST] <jamrial> yeah, with nvidia stuff it should be disabled now unless you have the external headers
[20:34:47 CEST] <kierank> for cuivid and the other one?
[20:34:49 CEST] <kierank> there were two iirc
[20:34:58 CEST] <jamrial> yes
[20:35:03 CEST] <kierank> ok great
[20:45:17 CEST] <cone-586> ffmpeg 03James Almer 07master:f6171471e6cf: avcodec: rename the AV1 profiles
[20:45:18 CEST] <cone-586> ffmpeg 03James Almer 07master:ea3320bb8285: libaomenc: fix profile setting
[20:45:19 CEST] <cone-586> ffmpeg 03James Almer 07master:0ac379863231: Merge commit 'ea3320bb828553182fb34e164826f95df5743522'
[20:47:04 CEST] <cone-586> ffmpeg 03Diego Biurrun 07master:e744281c4949: configure: Revert some incorrect uses of check_cc()
[20:47:05 CEST] <cone-586> ffmpeg 03James Almer 07master:05a1ec3374c6: Merge commit 'e744281c49496b0e0a357e9f84c37fbf99215e20'
[20:48:55 CEST] <cone-586> ffmpeg 03Martin Storsjö 07master:ab05d3934de8: arm: vc1dsp: Add commas between macro arguments
[20:48:56 CEST] <cone-586> ffmpeg 03Martin Storsjö 07master:3a7b4ae62c79: arm: Produce .const_data instead of .section .rodata for Mach-O
[20:48:57 CEST] <cone-586> ffmpeg 03James Almer 07master:a7109b82c4ab: Merge commit 'ab05d3934de8e932dbd77979a687e6598e67535c'
[20:48:58 CEST] <cone-586> ffmpeg 03James Almer 07master:33bd2b99a1c2: Merge commit '3a7b4ae62c798edbd82bcd8fef863c74ed2acd4a'
[20:58:33 CEST] <JEEB> has anyone her tested compilation with NDK r17 yet?
[20:58:46 CEST] <JEEB> it seems like some ARM SIMD stuff starts failing to compile
[21:09:19 CEST] <wbs> JEEB: I have patches for exactly that coming up
[21:09:24 CEST] <JEEB> ah
[21:09:49 CEST] <wbs> JEEB: that change has been in upstream llvm since may last year
[21:10:04 CEST] <JEEB> oh, so it's not a toolchain bug but rather we're using something incorrectly?
[21:10:16 CEST] <JEEB> was about to go derp at NDK devs
[21:10:23 CEST] <wbs> it's much more subtle
[21:10:59 CEST] <wbs> previously the clang built-in assembler was pretty limited, and the arm assembly requires support for the "altmacro" feature (which only the arm assembly requires, not the aarch64 assembly)
[21:11:28 CEST] <wbs> in may last year, it grew support for altmacro, so now configure concludes that it can run clang's assembler directly without needing gas-preprocessor
[21:11:35 CEST] <JEEB> aaah
[21:11:46 CEST] <JEEB> didn't notice it disabling gas-preproc :)
[21:11:51 CEST] <wbs> but then it fails over due to a few other fringe features that clang doesn't support and probably won't
[21:12:43 CEST] <JEEB> right
[21:12:47 CEST] <wbs> see 59cee42d7d22530e66a155305389e29679b11f78 and d7320ca3ed10f0d35b3740fa03341161e74275ea for related changes in libav
[21:14:47 CEST] <wbs> JEEB: out of the 3 changes sent, 1/3 probably is the one you need. the other two are needed for ios targets only
[21:15:21 CEST] <wbs> (when targeting apple platforms, clang disables a few more fringe features in the assembler, probably since they conflict with the legacy apple gas macro system)
[21:19:19 CEST] <JEEB> sounds nice enough
[21:19:28 CEST] <JEEB> cheers for the heads-up
[21:23:44 CEST] <wbs> (now the patches made it through the ML)
[21:24:17 CEST] <durandal_1707> lol, the aic decoder gave incorrect output all the time, even fate ref files are wrong
[21:26:49 CEST] <jamrial> well, fate tests make sure the output is the intended, not that the intended output is correct :p
[21:27:17 CEST] <njtze> .-.            .-.
[21:27:21 CEST] Last message repeated 2 time(s).
[21:27:21 CEST] <njtze> /   \          /   \
[21:28:00 CEST] Last message repeated 2 time(s).
[21:50:50 CEST] <wm4> bunny got cut off
[21:51:16 CEST] <wm4> (in at least 1 other channel it was successful and in addition annoyingly highlighted some nicks)
[21:54:28 CEST] <thardin>  /mode +p helps immensely with the spammers
[21:55:17 CEST] <iive> what is +p about ?
[21:55:34 CEST] <thardin> hides channel from /whois
[21:56:00 CEST] <thardin> assuming this server runs inspircd with that module installed
[21:56:15 CEST] <iive> how would this help?
[21:56:16 CEST] <sfan5> pretty useless without setting +s too
[21:58:57 CEST] <thardin> not what we've found on the local network
[23:18:33 CEST] <atomnuker> klaxa: not really having any ideas
[23:39:39 CEST] <jamrial> TD-Linux: aom commit 2eee346308dd2e26bce206ed233a5523f7d6ce55 did not remove the enums and related aom_image_t fields in aom_image.h
[23:41:20 CEST] <TD-Linux> jamrial, ah whoops I missed that
[23:41:30 CEST] <TD-Linux> jamrial, related: https://aomedia-review.googlesource.com/c/aom/+/53703
[23:41:47 CEST] <jamrial> oh nice
[23:42:02 CEST] <TD-Linux> I'll do a separate one for the RGB formats
[00:00:00 CEST] --- Sat Mar 31 2018