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

[burek]

[02:17:16 CEST] <alevinsn> what's the word I'm looking for?  function A calls function B, and function B calls function C
[02:17:30 CEST] <alevinsn> instead, take the call to function C and call it from function A after calling function B
[02:17:46 CEST] <alevinsn> what's the word to describe extracting the function call to function C from function B and moving it to function A
[02:17:47 CEST] <alevinsn> ?
[02:18:02 CEST] <alevinsn> I know there's a word for that....
[02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:6b5d3fb26fb4: avcodec/webp: Always set pix_fmt
[02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:60765cc42e3e: avcodec/pixlet: Fix runtime error: signed integer overflow: 436207616 * -5160230545260541 cannot be represented in type 'long'
[02:40:03 CEST] <cone-983> ffmpeg 03Michael Niedermayer 07master:c0ece1f4addf: avcodec/mpeg12dec: Fixes runtime error: division by zero
[02:52:27 CEST] <jamrial_> alevinsn: refactoring? idk
[02:52:47 CEST] <alevinsn> I thought that might be it, but refactoring is a pretty broad term
[02:52:54 CEST] <alevinsn> and covers a number of different techniques
[04:16:40 CEST] <cone-983> ffmpeg 03Steven Liu 07master:7355c1dda2f8: avformat/hlsenc: move old_filename free operation earlier
[04:24:50 CEST] <philipl> BtbN: I might be an idiot, but I don't actually see you calling decodePicture.
[04:24:54 CEST] <philipl> That would explain the garbage :-)
[04:25:35 CEST] <philipl> You go straight from av_hwframe_get_buffer to cuvidMapVideoFrame
[08:52:38 CEST] <beandog> who do I have to bribe with cookies to help me figure out the new encoding api
[08:52:43 CEST] <beandog> :)
[08:53:17 CEST] <rcombs> it's reasonably simple
[08:53:41 CEST] <rcombs> you send a frame, then receive packets until you get EAGAIN (usually you get one, but this can vary)
[08:54:04 CEST] <beandog> it's my first stab at any program in C using libav*, so I'm tripping up in general somewhat.
[08:54:13 CEST] <beandog> I'm decoding the audio just fine. I think.
[08:54:41 CEST] <beandog> you can see where my limited intelligence poops out - https://gist.github.com/beandog/7f51cdd45cf7ca9c8e4fce33760dfc60#file-avbox-c-L202
[08:55:36 CEST] <rcombs> you need to loop on avcodec_receive_frame until it stops giving you frames (EAGAIN)
[08:56:12 CEST] <beandog> ok
[09:00:58 CEST] <beandog> just pulling out one at all throws an error, though - "error: Resource temporarily unavailable"
[09:06:24 CEST] <JEEB> beandog: might be that the encoder didn't get enough data to start returning data
[09:06:34 CEST] <JEEB> some encoders require larger amounts of stuff put in
[09:06:40 CEST] <JEEB> like libx264 with slower presets
[09:07:45 CEST] <beandog> hmm
[09:07:46 CEST] <beandog> ok
[09:09:31 CEST] <ubitux> beandog: av_err2str(ret) is useful
[09:10:05 CEST] <beandog> ok
[09:16:29 CEST] <wm4> ubitux: even then the error messages are cryptic as hell
[09:18:45 CEST] <atomnuker> am I reading this right? vmaskmov solves like 99% of all opus assembly issues
[09:19:33 CEST] <atomnuker> if you can conditionally store to a memory address without overwriting
[09:21:18 CEST] <beandog> alright, I gotta run off to bed, thanks guys :) cookies for all
[10:16:33 CEST] <BtbN> philipl, no, there's a dummy call to DecodeVideo in between
[10:16:41 CEST] <BtbN> but DecodeVideo has no parameters to pass in the input buffer
[10:17:25 CEST] <BtbN> calling DecodeVideo throws an error though
[10:17:34 CEST] <BtbN> and MapVideo has both the input and output buffer parameters
[11:19:35 CEST] <cone-514> ffmpeg 03Clément BSsch 07master:8ba1fc2a4ac2: ffprobe: discard non-selected streams
[12:57:35 CEST] <BtbN> I hate Makefiles and their syntax
[13:01:05 CEST] <wm4> I hate shell and its syntax
[13:03:39 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:ad2296ab3a13: avcodec/aacdec_fixed: Fix various integer overflows
[13:03:40 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:d712a5cddbfc: cmdutils_opencl: Fix read of uninitialized pointer
[13:03:41 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:36cf42252152: cmdutils_opencl: Fix read of uinitialized cl_mem
[13:07:08 CEST] <BtbN> I can't get it to generate the needed file... It just doesn't care it doesn't exist, and fails at link time
[13:07:33 CEST] <durandal_1707> michaelni: arent packets padded with 0?
[13:07:53 CEST] <wm4> durandal_1707: the answer is "maybe"
[13:08:02 CEST] <durandal_1707> how would unckecked bistream work otherwise?
[13:08:23 CEST] <wm4> it usually requires only padding, not 0 padding
[13:08:28 CEST] <BtbN> If I add this to the Makefile, shouldn't it trigger the whole chain when a .ptx.o is in the list of files? https://bpaste.net/show/b925a4a49011
[13:08:32 CEST] <durandal_1707> maybe unaligned and unpadded
[14:30:50 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:5d0b8b1ae307: lavc/aarch64/simple_idct: fix iOS build without gas-preprocessor
[14:30:51 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:2f43897f6579: lavc/ffjni: fix local reference leak
[14:30:52 CEST] <cone-514> ffmpeg 03Matthieu Bouron 07master:1795dccde0ad: lavc/mediacodec_wrapper: fix local reference leaks
[14:46:21 CEST] <Gramner> atomnuker: note that vmaskmov* has some caveats on some cpu:s that you should to be aware of before using it such as preventing load-store forwarding and messing with the memory address disambiguator causing unrelated loads to stall
[14:48:47 CEST] <iive> maskmov has latency of 3000 on Ryzen ... and this is not the first AMD cpu to have issues with it.
[14:49:06 CEST] <atomnuker> its not doing anything fancy, just 2 (normal, movu) loads -> stuff -> 2 vmaskmov stores
[15:38:27 CEST] <jamrial> ubitux: wanna give the h264 cropping thing a look? or do we just skip it for now?
[15:38:36 CEST] <jamrial> the calculated cropping offsets post merge are different, and probably wrong
[15:39:50 CEST] <J_Darnley> I have sucessfully moved simple_idct to external asm...
[15:40:15 CEST] <jamrial> congrats
[15:41:12 CEST] <J_Darnley> I want to use some other code to do add and clamped functions.
[15:41:44 CEST] <J_Darnley> Do people object adding ~800 lines to lavc/x86/idctdsp.asm?
[15:42:56 CEST] <J_Darnley> Or should I copy ~100 to where I have been working?
[15:52:23 CEST] <J_Darnley> I think I'll copy.  I would need to duplicate a little anyway.
[15:54:04 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:d9051f8f3e60: avcodec/mimic: Fix runtime error: index 96 out of bounds for type 'const int8_t [64]'
[15:54:05 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:3a0ff78168f8: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int'
[15:54:06 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:8a69f2602fea: avcodec/dvbsubdec: Check entry_id
[15:54:07 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:7ac506714661: avcodec/scpr: Check y in first line loop in decompress_i()
[16:24:37 CEST] Action: kierank looking forward to see J_Darnley patch
[16:30:40 CEST] Action: J_Darnley facepalms
[16:30:59 CEST] <J_Darnley> Well obviously that's going toscrew you up!
[16:32:38 CEST] <gnafu> Expectations ruin everything.
[16:34:42 CEST] <j-b> BBB: you should give me the right to attack in your name
[16:34:50 CEST] <BBB> ?
[16:34:53 CEST] <J_Darnley> I should perhaps add a check to x264asm to catch those obvious errors.  No CPU has 128 registers (yet).
[16:34:58 CEST] <BBB> what did I do?
[16:35:14 CEST] <j-b> BBB: gpl violations
[16:35:20 CEST] <BBB> uh
[16:35:22 CEST] <BBB> dunno
[16:35:37 CEST] <j-b> Synology violates since 2 years!
[16:35:44 CEST] <BBB> so many people violate
[16:35:46 CEST] <BBB> nobody cares
[16:35:46 CEST] <j-b> it's not like a small thing
[16:35:48 CEST] <RiCON> 100 whole apps 
[16:35:49 CEST] <BBB> I tried for a little while
[16:36:00 CEST] <BBB> and its just too hard and too slow
[16:36:09 CEST] <BBB> and most violators are not in appropriate jurisdictions
[16:36:17 CEST] <BBB> and if they are, all you get is $1000 or so
[16:36:19 CEST] <BBB> whats the point
[16:36:28 CEST] <j-b> or way more
[16:36:36 CEST] <j-b> and forbid them from distributing
[16:37:45 CEST] <BBB> we need a more sustainable system than what we have now
[16:37:53 CEST] <BBB> having one developer do it makes no sense
[16:38:04 CEST] <BBB> maybe set up a collab with a law school and have their students do it as a summer project
[16:38:05 CEST] <BBB> every year
[16:38:19 CEST] <BBB> summer of code style
[16:38:39 CEST] <Gramner> summer of lawsuits
[16:38:55 CEST] <jamrial> what exactly do they violate gpl for? what gpl code could mobile apps need? doubt it's external library encoders
[16:40:02 CEST] <Gramner> maybe we should pitch practicing handling gpl violations as course material for law school
[16:40:16 CEST] <BBB> jamrial: who knows
[16:40:31 CEST] <BBB> jamrial: dont forget ios doesnt allow shared libs
[16:40:37 CEST] <BBB> jamrial: so full lgpl compliance is hard
[16:42:08 CEST] <j-b> that's totally untrue
[16:42:15 CEST] <j-b> iOS support shared libs since iOS8
[16:42:23 CEST] <j-b> 3 major versions ago
[16:47:09 CEST] <atomnuker> what's the shortest way to convert decimal to 1's e.g. 1 -> 0x1, 2 -> 0x3, 3 - 0x7, 4 - 0xf, etc?
[16:47:32 CEST] <BtbN> Why the hell does make delete my intermediate build files, and then isn't smart enough to figure out the build is up to date when re-running it?
[16:48:15 CEST] <atomnuker> ugh, I'll just use a lookup table, I only need up to 4
[16:48:50 CEST] <BtbN> https://bpaste.net/show/f1d4c223a851 like, what? Why?
[16:49:16 CEST] <nevcairiel> atomnuker: (1 >> x) - 1?
[16:49:55 CEST] <jamrial> <<
[16:50:00 CEST] <nevcairiel> right
[16:50:01 CEST] <nevcairiel> my bad
[16:50:03 CEST] <wm4> j-b: there's still the question whether the tivo clause allows gpl/lgpl at all
[16:50:13 CEST] <wm4> or was that only v3
[16:50:29 CEST] <j-b> wm4: only GPLv3
[16:50:48 CEST] <j-b> GPLv2/LGPLv2.1 is ok with tivo
[16:50:51 CEST] <j-b> LGPLv3 is unclear
[16:51:01 CEST] <ubitux> jamrial: not much more to say than what i said last time&
[16:52:04 CEST] <wm4> in any case even without shared libs you can apparently comply to lgpl
[16:52:16 CEST] <wm4> by proving .o files
[16:52:33 CEST] <wm4> though I wonder why the FSF chose such clunky requirements
[16:52:59 CEST] <wm4> in practice this is not going to help a single user
[16:53:09 CEST] <j-b> because they are lawyers
[16:53:19 CEST] <j-b> wm4: a long time ago, I wrote a GPL-short license
[16:53:23 CEST] <j-b> same spirit as GPL
[16:53:27 CEST] <j-b> but in a few sentences
[16:53:43 CEST] <wm4> but?
[16:55:09 CEST] <wm4> I think plenty of people would like a LGPL-style smaller licemse
[16:55:12 CEST] <wm4> license even
[16:56:01 CEST] <j-b> wm4: but, I had 2 guys from FSF that broke my balls
[16:56:05 CEST] <j-b> and I dropped the project
[16:57:16 CEST] <wm4> lol did they threaten to sue you
[16:57:19 CEST] <j-b> no
[16:57:31 CEST] <j-b> they started to explain how it will make the life of everyone more complex
[16:57:42 CEST] <j-b> because of compatibilities between GPL-light and GPL
[16:58:10 CEST] <atomnuker> nevcairiel: tnx, that's the 1 way of shifting I didn't consider
[16:58:23 CEST] <wm4> oh yeah, that's a "nice" property of GPL
[16:58:29 CEST] <durandal_1707> name of project is?
[17:11:47 CEST] <jamrial> ubitux: the problem seems to be the left cropping value being reduced to keep alignment when -flags unaligned is not set
[17:11:50 CEST] <jamrial> h264/hevc/theora do it one way, the new decode.c code another way
[17:12:30 CEST] <jamrial> i guess i could try to make decode.c behave the same, but wonder why it was changed in the first place
[17:13:01 CEST] <wm4> does this affect actual cropping, or the exported AVFrame cropping values?
[17:15:51 CEST] <atomnuker> wait, so I cannot shift a grp using another grp to specify shift amount?
[17:16:16 CEST] <atomnuker> (yet that's doable in SIMD?)
[17:16:29 CEST] <BBB> of course you can
[17:16:33 CEST] <BBB> but you can only shift with ecx
[17:16:34 CEST] <BBB> (cl)
[17:17:46 CEST] <BBB> atomnuker: I dont know why that limitation exists, but only ecx can shift (though any reg can be shifted)
[17:20:41 CEST] <jamrial> wm4: actual cropping
[17:28:30 CEST] <BBB> are you guys getting all these privmsgs from a user called BotRoomNN"?
[17:28:34 CEST] <BBB> how do I ignore that?
[17:28:51 CEST] <J_Darnley> Not me and I don't know.
[17:30:15 CEST] <Gramner> atomnuker/BBB: with bmi2 there's sensible 3-arg variable shift instructions
[17:30:39 CEST] <Gramner> shrx/shlx/sarx
[17:31:07 CEST] <Gramner> which are also faster than using cl on intel cpus because reasons
[17:32:53 CEST] <Gramner> 1/0.5 vs 2/2 on skylake
[17:36:18 CEST] <BBB> intel has so many reasons for so much crap behaviour
[17:36:25 CEST] <BBB> I never quite know what to think of it
[17:36:30 CEST] <BBB> I guess it works so WhyCare
[17:37:33 CEST] <Gramner> most of the weird performance issues are due to legacy x86 crap. like partially affecting flags, or behavior being different when src==0 and things like that
[17:38:48 CEST] <wm4> why didn't Intel come up with a new instruction set mode yet?
[17:38:59 CEST] <Gramner> they did. it's called itanium
[17:39:10 CEST] <Gramner> we all know how well that worked out
[17:39:19 CEST] <wm4> itanium was "revolutionary"
[17:39:28 CEST] <wm4> I mean something more like ARM did with Thumb
[17:39:43 CEST] <Gramner> because customers care about backwards compatibility
[17:39:54 CEST] <Gramner> so they still need to have all legacy crap
[17:40:11 CEST] <wm4> it can be... they can do the same like they signal the bitness of code
[17:40:20 CEST] <wm4> 15 vs. 32 vs. 64 bit code
[17:40:27 CEST] <wm4> *16
[17:40:31 CEST] <J_Darnley> 15-bit code?  Nice
[17:41:00 CEST] <Gramner> modern microprocessors are insanely complex to validate as it is, not sure they want to go down that rabit hole
[17:41:07 CEST] <BBB> they couldve fixed it with x86-64
[17:41:11 CEST] <Gramner> I'm guessing they will drop 16-bit at some point though
[17:41:54 CEST] <Gramner> yes. they could've, and should've, fixed (read: dropped) a lot of stuff
[17:41:56 CEST] <atomnuker> I dislike how I have to use cmov to clamp an integer, a separate clamp instruction would've been nice
[17:42:05 CEST] <Gramner> hindsight is 20/20
[17:42:51 CEST] <kierank> atomnuker: do it in simd
[17:43:00 CEST] <wm4> 64 bit mode was AMD, which focused on max. compatibility to existing toolchains or something
[17:43:42 CEST] <wm4> Gramner: well the idea is that they would gradually switch to slower emulation for the "old" instruction set
[17:44:39 CEST] <Gramner> that's already happening with mmx and x87
[17:45:06 CEST] <atomnuker> kierank: pretty much what I do, I splat an integer and multiply each word to get the bit in the correct place
[17:45:16 CEST] <Gramner> you can gain performance by converting mmx simd to sse2 that only uses the lower half on skylake
[17:45:31 CEST] <Gramner> depends on which instructions are used
[17:45:32 CEST] <kierank> J_Darnley: ^
[17:45:41 CEST] Action: wm4 wish swscale would remove this funny self-modifying mmx code for a broken scaler
[17:45:53 CEST] <wm4> can't make that up
[17:46:42 CEST] <Gramner> self-modifying SIMD sounds scary
[17:47:03 CEST] <kierank> wm4: you know perfectly well that weird shit isn't going to go away
[17:47:04 CEST] <kierank> FAST
[17:47:05 CEST] <kierank> SPEED!
[17:48:16 CEST] <wm4> :(
[17:48:48 CEST] <kierank> at least with mpeg2 mmx I can ask J_Darnley to get rid of it
[17:48:54 CEST] <BBB> Gramner: its there
[17:48:57 CEST] <Gramner> self-modifying code tends to be slow though since it messes a lot with internal cpu behavior
[17:48:59 CEST] <BBB> Gramner: its crazy
[17:49:11 CEST] <BBB> Gramner: and its crazy fast for mmx code, yes
[17:52:23 CEST] <atomnuker> self-modifying code sounds so radical though
[17:53:14 CEST] <wm4> at least it seemed to stop upsetting selinux and actively bothering users
[17:57:08 CEST] <iive> wm4: itanium was slow. nowdays even gpu's move away from vliw 
[18:01:09 CEST] <iive> the "self modifying code" is modified once before execution and doesn't change itself after that. so it is more like dynamic compilation of code
[18:01:19 CEST] <Gramner> that swscale code isn't self-modifying though. it's runtime-generated and not very scary. I'm disappointed!
[18:02:07 CEST] <iive> :)
[18:02:54 CEST] <atomnuker> Gramner: if itanium processors weren't a failure would the instruction set be okay to work with?
[18:04:06 CEST] <Gramner> the itanium instruction set was designed around smart compilers. e.g. the compiler would figure out all the things that could be done in parallell so the cpu wouldn't have to
[18:04:49 CEST] <Gramner> turns out writing good compilers is hard, and out-of-order execution in hardware is actually really good
[18:07:25 CEST] <Gramner> writing vliw asm by hand seems kind of annoying
[18:08:59 CEST] <atomnuker> the arm camp still seems to believe in smart compilers
[18:11:21 CEST] <wm4> iive: well I didn't say it should be vliw
[18:11:40 CEST] <wm4> Itanium was essentially a failed experiment, but they didn't play it save in the first place
[18:12:21 CEST] <wm4> the arm thumn instruction set on the other hand is a "safe" optimization that brought obvious benefits
[18:12:32 CEST] <wm4> *thumb
[18:12:37 CEST] <wm4> no radical new concepts
[18:14:21 CEST] <Gramner> the current x86 approach is basically "SIMD ALL THE THINGS" due to dennard scaling failing on us
[18:16:56 CEST] <wm4> what's dennard scaling?
[18:17:09 CEST] <Gramner> gathers, scatters and conflict detection in avx-512 feels very much designed for compilers, because it's rare to need such things in handwritten SIMD and inferring inter-dependencies between data can be very hard or impossible for a compiler to do, so just let the hardware deal with it
[18:17:16 CEST] <Gramner> https://en.wikipedia.org/wiki/Dennard_scaling
[18:18:05 CEST] <Gramner> it's why we don't have 30GHz cpus
[18:21:16 CEST] <nevcairiel> i wonder if you could make single cpu cores somehow bigger for more performance, instead of just scaling up cores to use the space
[18:21:24 CEST] <nevcairiel> (other then introducing new simd)
[18:21:49 CEST] <thardin> new paradigms may be needed. such as computing at optical frequencies
[18:22:55 CEST] <Gramner> you can add more cache and increase out-of-order execution windows, in-flight load/store buffers etc (which is what cpu designers tend do every new arch nowadays) but all of this has diminishing returns
[18:23:13 CEST] <Gramner> this is a physics issue, not a design issue really
[18:23:42 CEST] <nevcairiel> so essentially, x86 isnt going to get much faster
[18:24:28 CEST] <J_Darnley> Finally!  People will stop writing slower software
[18:26:06 CEST] <atomnuker> not even gallium arsenide would help nowadays, it would actually make things worse
[18:26:28 CEST] <Gramner> we'll get more cores, wider simd, more execution engines and slightly better IPC due to general arch improvements, but probably nothing major until a completely new material with better physical properties that is viable to create transistors out of shows up
[18:26:47 CEST] <J_Darnley> GRAPHENE!
[18:26:55 CEST] <Gramner> yes, graphene is one contender
[18:49:17 CEST] <jamrial> ubitux, michaelni: libav is also affected by this change in cropping behavior, so i'll just skip these commits for now
[18:59:52 CEST] <BtbN> I think I won against the Makefiles
[18:59:57 CEST] <BtbN> I hate Makefiles
[19:04:28 CEST] <J_Darnley> Dinner then patch squashing time.
[19:05:23 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:a02ae1c6837a: hevcdec: export cropping information instead of handling it internally
[19:05:24 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:4fded0480f20: h264dec: be more explicit in handling container cropping
[19:05:25 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:c3e84820d67c: h264dec: export cropping information instead of handling it internally
[19:05:26 CEST] <cone-514> ffmpeg 03Anton Khirnov 07master:1202b712690c: theora: export cropping information instead of handling it internally
[19:05:27 CEST] <cone-514> ffmpeg 03James Almer 07master:fc63d5ceb357: Merge commit '1202b712690c14f0efb06e4ad8b06c5b3df6822a'
[19:05:28 CEST] <cone-514> ffmpeg 03James Almer 07master:602ac487205e: doc/libav-merge: mention the skipped AVFrame crop fields usage commits
[19:27:17 CEST] <atomnuker> I like how in newer nasm versions you don't have to use that obscure debug option to resolve errors in macros
[19:27:28 CEST] <atomnuker> who thought that was a good idea
[19:27:50 CEST] <iive> what is the obscure debug option?
[19:28:19 CEST] <atomnuker> I can't remember, something you appended on make, its in the docs
[19:28:41 CEST] <atomnuker> DBG=1
[19:39:30 CEST] <ubitux> jamrial: even git/master ?
[19:39:59 CEST] <jamrial> ubitux: libav? yes
[19:40:42 CEST] <jamrial> i checked to see if it was fixed/changed in a following commit so i'd just cherry pick it as part of the merge, but no
[19:44:23 CEST] <ubitux> ok ok
[19:54:23 CEST] <jamrial> and here i was happy i got rid of an item from the libav-merge list, only to end up adding another :p
[20:08:42 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:e717fa1f0a66: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers
[20:08:43 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:2bfd0a97587d: avcodec/cllc: Check num_bits
[20:08:44 CEST] <cone-514> ffmpeg 03Michael Niedermayer 07master:15e892aad12b: avcodec/msmpeg4dec: Check for cbpy VLC errors
[20:21:21 CEST] <ubitux> jamrial: yeah :(
[20:22:11 CEST] <ubitux> jamrial: but it's better to have to deal with this list on a daily basis than the overall merge count we currently fight
[20:22:21 CEST] <ubitux> so its time will come
[20:27:44 CEST] <ubitux> seems our qsvenc is still quite a bit different
[22:37:12 CEST] <SviMik> can anybody say why ffmpeg sometimes puts chromaticities and gamma info into png file? what is it intended for? http://svimik.com/ffmpegpngformats1.png
[22:37:18 CEST] <SviMik> I have noticed that colors in png are screwed when in does so. Is there a way to disable it?
[22:39:16 CEST] <nevcairiel> it writes those if the color information is set on the encoder
[22:39:22 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/pngenc.c#L293
[22:39:56 CEST] <BtbN> If it has the information, it will write them
[22:52:03 CEST] <iive> atomnuker: found it, it compiles the .asm with -e option that basically only does preprocessor and saves the result in *.dbg.asm file, that is compiled/assembled on a second run.
[00:00:00 CEST] --- Fri May 12 2017