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

[burek]

[02:32:59 CET] <cone-867> ffmpeg 03Michael Niedermayer 07master:232b8a5a438a: avformat/img2enc: re enable atomic writes with split planes
[02:32:59 CET] <cone-867> ffmpeg 03Muhammad Faiz 07master:f8d429e0c569: avfilter/avf_showcqt: rewrite showcqt and add features
[03:54:04 CET] <cone-867> ffmpeg 03Michael Niedermayer 07master:492dead9ac85: avfilter/avf_showcqt: Fix ;;
[04:00:38 CET] <Timothy_Gu> nevcairiel: that makes sense. thanks
[04:17:09 CET] <cone-867> ffmpeg 03Ganesh Ajjanagadde 07master:a0e390e8ff33: avutil/avstring: add av_warn_unused_result
[10:05:38 CET] <__gb__> nevcairiel, vlc git commit b72986e8 mentions that hwaccel decode with frame multithreading works since libavc >= 55.01.0 -- does this mean we have a regression in ffmpeg or an un-merged "feature" ?
[10:05:57 CET] <nevcairiel> thats for some definition of "works"
[10:06:23 CET] <nevcairiel> it was allowed, and sometimes worked, but the issues I outlined were always present and you were rather misguided if you tried to use it
[10:06:28 CET] <__gb__> nevermind, very old commit :)
[10:10:38 CET] <nevcairiel> its about the same time some minor fixes were introduced to somehow make frame threading not break in obvious ways when used with hwaccel
[10:10:46 CET] <nevcairiel> but the fundamental problems remain
[10:12:41 CET] <JEEB> yeah
[10:13:40 CET] <nevcairiel> the amount of breakage depends on your hardware, too. intel seems to have far more problems than nvidia
[10:18:15 CET] <ubitux> wbs: there is a generic "skip_frame" option (vs this "skip_frames"); you might want to use something less confusing
[10:19:23 CET] <wbs> ubitux: that seems to be a wholly different thing, for speeding up decoding by skipping decoding of some (e.g. non-reference) frames
[10:19:34 CET] <wbs> ubitux: while this is "allow the encoder to skip frames if it thinks it needs to"
[10:19:43 CET] <ubitux> yes i know it's totally different
[10:19:54 CET] <ubitux> that's why i suggest to use a more distinct naming :p
[10:20:06 CET] <wbs> ah, sorry, I misunderstood
[10:20:15 CET] <ubitux> like "allow_skip_frames" or sth, or really whatever you want
[10:20:20 CET] <wbs> yeah, that sounds better
[10:22:47 CET] <cone-530> ffmpeg 03Michael Niedermayer 07master:057ce755b937: ffprobe: Remove abort()
[10:23:10 CET] <wm4> (this must be the proof nobody uses this way to mark 3D files)
[10:23:25 CET] <nevcairiel> or noone uses ffprobe
[10:23:28 CET] <nevcairiel> which is probably both true
[10:23:41 CET] <wm4> I use ffprobe all the time
[10:23:49 CET] <ubitux> many platforms use ffprobe
[10:23:51 CET] <wm4> it's nice for dumping all what ffmpeg knows about a file
[10:24:15 CET] <wm4> (I just wish it had a better cmdline help or docs)
[10:25:17 CET] <__gb__> wm4, since you use it all the time, you are then the most knowledgeable person to resolve the latter :)
[10:28:23 CET] <nevcairiel> wm4: actually thats rotation code, not 3d?
[10:28:39 CET] <JEEB> I use ffprobe heavily, too
[10:28:43 CET] <JEEB> the json output is <3
[10:30:14 CET] <wm4> nevcairiel: oh, ok
[10:30:26 CET] <nevcairiel> that might make it more likely to be used
[10:30:31 CET] <nevcairiel> but who knows
[10:30:32 CET] <wm4> true
[10:30:51 CET] <wm4> and ever since Linus derped a lot about video rotation, everyone tries to support it out of the box
[10:31:11 CET] <wm4> rotation is what users really want!
[10:32:17 CET] <wm4> the abort() was added 5 months ago
[11:07:25 CET] <rcombs> I use ffprobe now and then
[11:09:40 CET] <cone-530> ffmpeg 03Rodger Combs 07master:1e477a970fd5: lavu: add AESNI CPU flag
[11:09:41 CET] <cone-530> ffmpeg 03Rodger Combs 07master:ec588db56fdc: lavu/aes: move AVAES to separate internal header
[11:09:42 CET] <cone-530> ffmpeg 03Rodger Combs 07master:15ff5c7215de: lavu/aes: add runtime dispatch for crypt function
[11:09:43 CET] <cone-530> ffmpeg 03Rodger Combs 07master:54cd1ab55513: lavu/aes: align AVAES struct members
[13:51:05 CET] <cone-530> ffmpeg 03Kirill Gavrilov 07master:bea931c2eb77: avcodec/png: read and write stereo3d frame side data information
[14:29:33 CET] <mateo`> michaelni__: implementing the logic to skip the relevant markers using a switch would make something like this http://pastie.org/10513535#4,30 (and would take the same amount of lines in this case)
[14:30:39 CET] <mateo`> i don't really mind which version to use so if you feel the switch/case is more simpler, i'll go with it
[14:35:38 CET] <michaelni__> mateo`, to me when looking at it, the switch needs less msec  to understand
[14:36:25 CET] <kierank> Timothy_Gu: note that I'm using pretty much all the cpu on avdev right now
[15:38:58 CET] <cone-530> ffmpeg 03Rodger Combs 07master:cceed8389d61: lavu/aes: test CBC functionality
[16:43:28 CET] <BBB> am I being too difficult on ganesh in my comments on that patch of his?
[16:43:39 CET] <BBB> (a second opinion might be helpful here)
[16:44:12 CET] <nevcairiel> i find his entire endeavours pointless and might have possibly expressed that to him before
[16:44:47 CET] <Daemon404> i dont mind their point
[16:44:50 CET] <Daemon404> i mind that theyre sloppy
[16:47:30 CET] <BBB> ok but more specifically the specific patch in question
[16:47:40 CET] <Daemon404> which
[16:47:53 CET] <Daemon404> "that patch of his" doesnt tell me much when he is 50% of the ML volume
[16:47:59 CET] <BBB> all: fix enum definition for large values
[16:48:09 CET] <Daemon404> i didnt see you being an ass
[16:48:19 CET] <BBB> specifically the second third and second chunks (I approved the first chunk)
[16:48:38 CET] <Daemon404> no, youre points are valid
[16:48:41 CET] <Daemon404> your*
[16:50:43 CET] <BBB> ok ty
[16:56:07 CET] <BBB> nevcairiel: so, do people actually use msvc nowadays?
[16:56:15 CET] <BBB> like, in the wild, in realworld ffmpeg deployments/usages
[16:56:29 CET] <Daemon404> like chrome?
[16:56:34 CET] <nevcairiel> dunno, i use it for debugging only since builds are like 20% slower
[16:56:59 CET] <BBB> :(
[16:57:04 CET] <BBB> do we know why its 20% slower?
[16:57:11 CET] <Daemon404> CABAC
[16:57:12 CET] <BBB> is it missing inline asm, compiler being shit?
[16:57:13 CET] <nevcairiel> half of that is inline asm
[16:57:22 CET] <BBB> hmk
[16:57:23 CET] <nevcairiel> not sure where the other half goes
[16:57:38 CET] <Daemon404> also pretty much all the mpeg2/4 asm
[16:57:38 CET] <Daemon404> iirc
[16:57:40 CET] <BBB> does msvc support any form of custom asm in 64bit builds?
[16:57:44 CET] <Daemon404> no.
[16:57:48 CET] <BBB> I remember that the quirky asm was 32bit only
[16:57:48 CET] <nevcairiel> Microsoft has been working on enabling Clang to compile native windows code
[16:58:02 CET] <nevcairiel> its supposed to be ready next month
[16:58:02 CET] <Daemon404> nevcairiel, except clang devs did most of the work
[16:58:03 CET] <BBB> oh rly
[16:58:07 CET] <nevcairiel> going to give it a whirl
[16:58:10 CET] <Daemon404> reverse engineering the C++ ABI
[16:58:10 CET] <BBB> so theyre ditching msvc?
[16:58:11 CET] <nevcairiel> Daemon404: who cares
[16:58:12 CET] <Daemon404> or lack thereof
[16:58:17 CET] <nevcairiel> BBB: nah
[16:58:24 CET] <nevcairiel> well not yet anyway
[16:58:39 CET] <Daemon404> they just did a major compiler and crt overhaul
[16:58:42 CET] <Daemon404> i doubt theyre ditching it
[16:58:52 CET] <BBB> overhaul!
[16:58:59 CET] <BBB> instead of being 30 years behind, theyre now only 15 years behind
[16:59:00 CET] <BBB> whoa
[16:59:01 CET] <BBB> impressive
[16:59:05 CET] <nevcairiel> Daemon404: in any case, Microsoft supplied the required missing information like for structured exception handling, dont think it would've been done anytime soon without MS taking an interest
[16:59:09 CET] <BBB> forefront of technoological innovation
[16:59:16 CET] <BBB> I wish I could work there
[16:59:33 CET] <Daemon404> the compiler is not actually that bad
[16:59:34 CET] <nevcairiel> they are also only using the Clang frontend and still their own compiler backend
[16:59:44 CET] <Daemon404> it's only slower for us due to inline asm, really.
[17:00:11 CET] <nevcairiel> And when it comes to C++, their compiler is really not bad and usually pretty far feature wise
[17:00:19 CET] <nevcairiel> they just dont care about C much
[17:01:16 CET] <nevcairiel> but yeah they wanted to get rid of inline asm for a long time, so they just never offered any kind in x64 builds
[17:01:59 CET] <nevcairiel> will see how well clang works, if I can make builds that are debuggable, don't require mingw, and perform comparable to gcc-mingw builds, then I won't hesitate to do so
[17:02:22 CET] <Daemon404> youll have to build clang HEAD
[17:02:23 CET] <Daemon404> to test
[17:03:03 CET] <Daemon404> i dont think it currently supports PDB generation.
[17:03:03 CET] <nevcairiel> Microsoft didn't backport all their changes yet to mainline, but they want to get that all sorted in the next couple months
[17:03:14 CET] <nevcairiel> and in the meantime, they'll distribute their own binary
[17:03:21 CET] <nevcairiel> there is a talk from cppcon if you care
[17:03:28 CET] <Daemon404> ill google it
[17:03:49 CET] <nevcairiel> https://www.youtube.com/watch?v=TRgWJuQhkQo
[17:04:08 CET] <nevcairiel> apparently they can build windows and some other major products with it already
[17:05:02 CET] <nevcairiel> in any case, this is supposed to come out in november some time with the vs2015 update
[17:07:13 CET] <Daemon404> one day theyll learn that you can update in intervals shorter than N months
[17:07:36 CET] <nevcairiel> it already gotten much faster with the couple months updates
[17:08:14 CET] <nevcairiel> vs2015 was only officially released in july i think
[17:08:23 CET] <Daemon404> i have yet to install it
[17:08:38 CET] <Daemon404> because its effort to dl iso / installer
[17:08:43 CET] <Daemon404> and do the BIg Uninstall / Install
[17:09:03 CET] <nevcairiel> i re-did my fate vm because it even still had 2010 on it
[17:09:23 CET] <nevcairiel> but they carried the community edition forward, so thats a huge gain
[17:48:02 CET] <Daemon404> InitializeSecurityContext(NULL, NULL, NULL, 0, 0, 0, NULL, 0, NULL, NULL, NULL, NULL);
[17:48:05 CET] <Daemon404> <3
[17:58:55 CET] <Timothy_Gu> kierank: ok
[18:09:46 CET] <Gramner> google logic: "text relocations cause unnecessary dirty pages" so let's prevent such software from running at all! being unable to use software is clearly a significant improvement in user experience compared to using some extra kilobytes of memory
[18:10:10 CET] <JEEB> lol
[18:10:47 CET] <Daemon404> context?
[18:11:20 CET] <Gramner> context is that you cannot link to libavcodec on android 6 because it contains textrels
[18:11:28 CET] <Gramner> on x86
[18:11:31 CET] <Gramner> 32-bit x86
[18:11:39 CET] <Daemon404> and nothing of value was lost
[18:12:35 CET] <Daemon404> wbs, you should look at nevcairiel's schannel patch, since you 'own' the tls code
[18:12:42 CET] <Daemon404> my review is weak at best.
[18:49:13 CET] <iive> Gramner: it more like "We must do any hacks known and unknown to save some memory. OK, we'll run Java".
[18:51:12 CET] <Gramner> indeed
[18:52:52 CET] <wm4> isn't it for "security" reasons
[18:55:11 CET] <Gramner> what security reasons?
[18:57:51 CET] <BBB> I thought the issue was that text relocations added up to startup latency?
[18:58:40 CET] <wm4> Gramner: you have to make the code pages writable, but actually I don't remember the cited reason
[18:58:41 CET] <wm4> s
[18:59:05 CET] <Gramner> wm4: the VM needs the execmem SELinux capability anyway
[19:01:04 CET] <Gramner> also shouldn't it be possible to just make pages non-writable after relocations are done if you think that's an issue?
[19:02:06 CET] <wbs> Daemon404: I can try to have a look
[19:02:38 CET] <Gramner> in any way, you can just use ROP to wreck stuff if you can't write to executable sections
[19:03:40 CET] <Daemon404> wm4, http://www.element14.com/community/servlet/JiveServlet/showImage/38-19876-221957/its-dangerous-to-go-alone-take-this.jpg
[19:03:43 CET] <Daemon404> er
[19:03:45 CET] <Daemon404> wbs
[19:05:46 CET] <Gramner> BBB: it does affect startup latency of course, but that's hardly anything the OS devs should care about. also getting rid of textrels on 32-bit x86 results in significantly slower code instead which is just moving the problem around
[19:06:29 CET] <BBB> Gramner: this was an issue brought up to me at some point
[19:06:34 CET] <BBB> Gramner: they didnt care about slower software
[19:06:44 CET] <BBB> Gramner: the startup latency was considered more user noticeable"
[19:07:12 CET] <BBB> a user doesnt notice the difference between 150 and 160 fps, but a user does notice the difference between 500 and 750ms startup time
[19:07:12 CET] <wm4> nevcairiel: av_dup_packet is not marked as deprecated in ffmpeg?
[19:07:24 CET] <BBB> (I made these numbers up)
[19:07:36 CET] <Gramner> and not being abel to use an application at all is not user noticable then I guess?
[19:07:38 CET] <BBB> chrome startup time is terrible, and on android this would obviously be a bigger issue
[19:07:48 CET] <BBB> I think theyre trying to force their hand :)
[19:07:52 CET] <BBB> maybe not working
[19:08:00 CET] <BBB> people can just keep building for android 5 right?
[19:08:04 CET] <BBB> so Im not sure its an issue
[19:08:07 CET] <Daemon404> this sounds like google internal warring to me
[19:08:17 CET] <BBB> I dunno, I dont work there
[19:08:19 CET] <BBB> Im just speculating
[19:08:34 CET] <Daemon404> i can count the number of 32-bit x86 android devices ive used on 0 hands
[19:08:34 CET] <Daemon404> so.
[19:08:42 CET] <wm4> michaelni: are you ok with me applying this libswscale channel layout avoption patch?
[19:08:52 CET] <Daemon404> you mean swr
[19:09:07 CET] <wm4> uh
[19:09:08 CET] <wm4> yes
[19:09:35 CET] <Gramner> supporting PIC on 32-but x86 in ffmpeg for example would require going through ~60k lines of asm and rewrite a lot of it, while making it ugly and harder to maintain in the process. that's not going to happen anytime soon
[19:12:54 CET] <michaelni> wm4, the max/min extension, yes sure
[19:14:29 CET] <wm4> michaelni: only min is changed
[19:15:15 CET] <BBB> wm4: you misudnerstand my comment
[19:15:22 CET] <BBB> wm4: I dont mind that - I mind the hardcoded codec list
[19:15:33 CET] <BBB> basically what nevcairiel said
[19:15:38 CET] <wm4> BBB: well I'm just saying that it's codec specific
[19:15:52 CET] <BBB> sure, but that specific identifier should not live outside the context of the codec
[19:16:17 CET] <wm4> I think I'd rather have such a hack, than exposing this capability via API
[19:16:31 CET] <BBB> I dont want the hack at all
[19:16:36 CET] <wm4> the correct solution is probably setting it in the parser
[19:16:37 CET] <BBB> imagine how hard it will be to get rid of
[19:17:11 CET] <Mavrik> Daemon404, there's tons of x86 Androids out there lately actually.
[19:17:21 CET] <Mavrik> And the textrels is a rather nasty problem.
[19:17:41 CET] <Mavrik> (Might also be connected to the dumbess of Android's ld loader).
[19:20:31 CET] <nevcairiel> textrels are not going away though, like Gramner said, its a huge and annoying task that noone is going to do
[19:20:36 CET] <nevcairiel> you can build withtout yasm = p
[19:20:51 CET] <Gramner> and make it too slow to be usable instead
[19:21:18 CET] <Mavrik> On the other hand, people should be using MediaCodec anyway.
[19:21:35 CET] <Mavrik> And ffmpeg muxers don't rely on yasm all that much.
[19:21:46 CET] <Mavrik> (Even though MediaCodec is fun in its own way.)
[19:26:10 CET] <cone-530> ffmpeg 03wm4 07master:80580bb24014: swr: do not reject channel layouts that use channel 63
[19:39:06 CET] <Plorkyeran> <@nevcairiel> in any case, this is supposed to come out in november some time with the vs2015 update <-- the preview is in november, but not as part of the update
[19:39:18 CET] <Plorkyeran> and the "real" release is targetting feb
[19:39:48 CET] <nevcairiel> thats not what they said
[19:39:56 CET] <Plorkyeran> they clarified on reddit afterwards
[19:40:05 CET] <Plorkyeran> because they said misleading things in the talk
[19:41:04 CET] <nevcairiel> people need to stop using reddit and use more approachable communication platforms
[19:42:45 CET] <Plorkyeran> it is pretty weird to have /r/cpp be the canonical source of news for vc++ and ISO standardization meetings...
[19:43:35 CET] <JEEB> fun... vs2015 skips having VS130COMNTOOLS, instead having VS140COMNTOOLS
[19:44:47 CET] <nevcairiel> of course, its vs14 afterall
[19:45:02 CET] <JEEB> well it makes sense for them to finally normalize the numbers
[19:45:16 CET] <nevcairiel> normalize what
[19:45:35 CET] <JEEB> well vs2013 was 120
[19:45:48 CET] <nevcairiel> and 2015 is 140
[19:45:58 CET] <JEEB> yes
[19:46:13 CET] <JEEB> I mean, it makes sense to pull the two numbers together :P
[19:46:18 CET] <JEEB> 14.0/140
[19:46:34 CET] <JEEB> or wait, ffuu. 120 was 140 too
[19:46:46 CET] <JEEB> so the mismatch was between the actual product name and the version only
[19:46:48 CET] <JEEB> welp
[19:49:45 CET] <nevcairiel> yes
[20:30:29 CET] <cone-530> ffmpeg 03Michael Niedermayer 07master:3f5029181307: doc/filters: Remove article redundancy
[21:22:22 CET] <meh`> has anyone been working on encoders/decoders using OpenMAX to run on the rbpi?
[21:24:02 CET] <wm4> why would you want to use omx on the rpi
[21:25:39 CET] <meh`> wm4, because I need hardware acceleration for encoding, and I'm either doing something wrong or it's not there
[21:26:05 CET] <BtbN> I don't think there is any omx support in ffmpeg at all?
[21:26:28 CET] <wm4> meh`: there's rpi decoding via mmal, and the same could be done for encoding
[21:29:53 CET] <meh`> wm4, I'll give that a shot
[22:09:44 CET] <atomnuker> managed to get enough of daala's entropy decoder up and running to start decoding spectral coefficients now
[22:10:00 CET] <atomnuker> fits in under 150 lines with a few asserts thrown in
[22:25:52 CET] <cone-530> ffmpeg 03Lou Logan 07master:2193f537ed35: doc/encoders: fix "the their" typo
[23:50:47 CET] <kylophone> Is there a preferred way of generating random numbers in FFmpeg?
[23:50:55 CET] <kylophone> is rand() ok?
[23:52:18 CET] <kierank> there is av_rand iirc
[23:53:04 CET] <kierank> oh you're kyle swanson
[23:53:07 CET] <kierank> ...
[23:53:26 CET] <kylophone> yep. that's me.
[23:53:49 CET] <kylophone> I figured there was something like that, but I haven't found it in the docs yet.
[23:54:55 CET] <nevcairiel> we have av_lfg
[23:55:36 CET] <nevcairiel> avutil/lfg.h
[23:57:42 CET] <kylophone> cool. avutil/lfg.h looks good.
[23:57:46 CET] <kylophone> thanks!
[23:57:51 CET] <kierank> durandal_1707: 22 million runs on h264 and no crashes which is looking good
[00:00:00 CET] --- Thu Oct 29 2015