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

[burek]

[00:31:24 CET] <cone-909> ffmpeg 03Mats Peterson 07master:caeed0479fca: lavf/avidec: Skip xxpc entries in index; fixes trac #5311
[01:59:04 CET] <Timothy_Gu> So what's the reason why some hwaccels are AVHWAccel and some have decoders?
[01:59:19 CET] <Timothy_Gu> like VAAPI is an AVHWAccel but MediaCodec is a decoder
[02:19:13 CET] <rukhsana> hi
[03:36:51 CET] <cone-966> ffmpeg 03Michael Niedermayer 07master:689211d57272: avformat/concatdec: set safe mode to enabled instead of auto
[04:48:47 CET] <philipl_> Timothy_Gu: I think it depends on what level the underlying library works at. Some of them consume the entire bitstream and don't require any parsing. For those, it makes sense to just write a decoder. For the ones that require metadata parsing, then HWAccel makes sense with the hooks into the regular decoder.
[04:49:10 CET] <rcombs> (VideoToolbox would make more sense as a decoder but was implemented as a HWAccel because ?????)
[04:49:25 CET] <philipl_> MediaCodec is a full decode api so that's not a surprise. The one I did was CrystalHD where the library did full bitstream parsing
[04:49:29 CET] <philipl_> Can't speak to VTB
[05:11:59 CET] <rcombs> philipl: VTB does full bitstream parsing
[05:12:26 CET] <rcombs> there's awkward code in lavc to regenerate the bits of the bitstream that aren't provided to hwaccels for it
[05:12:33 CET] <rcombs> apparently it's& not especially stable
[05:53:44 CET] <philipl> rcombs: ugly
[05:58:24 CET] <Timothy_Gu> ok
[08:58:22 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20160310021753&slot=x86_64-archlinux-gcc-ubsan
[09:35:10 CET] <mateo`_> Timothy_Gu: for MediaCodec, you can't expect the API to get one output for one input; it does not fit to be an hwaccel of the h264 decoder, this is why it has its own decoder and it will gain "soon" its own hwaccel.
[09:37:28 CET] <wm4> Timothy_Gu: it's worth noting that a AVHwaccel struct is required to use a hw pixfmt
[09:37:38 CET] <wm4> because libavcodec/utils.c forces it so
[09:38:25 CET] <wm4> so that struct and the concept of slice hwaccels as the lavc native h264 decoder uses it are a bit distinct
[09:45:31 CET] <nevcairiel> mateo`_: what good is a hwaccel if it doesnt actually behave like a hwaccel, like you said yourself :D
[09:48:48 CET] <mateo`_> nevcairiel: it can't be an hwaccel of the h264 decoder
[09:52:05 CET] <mateo`_> because the h264 decoder expect to get a frame when you submitted all the frame slices
[09:54:00 CET] <mateo`_> so it makes perfect sense for mediacodec to have its own decoder with CODEC_CAP_DELAY (and have its own hwaccel to support surface output)
[09:54:06 CET] <cone-319> ffmpeg 03Carl Eugen Hoyos 07master:cb3f99e4d3f8: version.sh: Fix spurious rebuilds.
[10:01:37 CET] <cone-319> ffmpeg 03Carl Eugen Hoyos 07master:ac1974652b9c: lavf/mxfdec: Support Canopus codecs.
[10:55:51 CET] <wm4> wbs: why is 9a7dc618c50902e7a171f2deda6430d52c277a95 applied for decoding
[10:56:08 CET] <wm4> insanity
[11:24:42 CET] <wbs> wm4: I suppose it should only be done for encoding, sure
[11:51:53 CET] <BtbN> hm, I kind of feel like writing a generic GLSL filter/source, like shadertoy
[11:53:59 CET] <ubitux> iq didn't release it's weird live editor?
[11:54:05 CET] <ubitux> s/it's/his/
[11:54:28 CET] <BtbN> hm?
[11:55:37 CET] <ubitux> Inigo Quilez, the guy who won so many demo parties, and who actually made shadertoy (look for "iq" on it)
[11:55:50 CET] <ubitux> he wrote some kind of live editor, which you see using in some of his vids
[11:56:14 CET] <ubitux> https://www.youtube.com/watch?v=y8aL4Cnb9m4
[11:56:27 CET] <BtbN> Primarily thinking about GLSL based filtering though, the audio/video source would just be another possible use
[11:57:19 CET] <ubitux> well i guess he moved to shadertoy at some point
[12:11:11 CET] <wm4> would that read back to CPU memory?
[12:19:03 CET] <wbs> on the topic of intrinsics vs asm, the tricky thing about intrinsics is that the compiler can only use them if you build with enough -msse flags, and that means that the compiler is allowed to use such instructions anywhere, not just within the intrinsics part. so effectively, it's hard to sensibly do runtime detected features
[12:19:25 CET] <nevcairiel> gcc has some crazy attribute flags to enable them
[12:19:29 CET] <wbs> oh
[12:19:34 CET] <nevcairiel> although i dont know if that works on per-function or only per-file
[12:19:53 CET] <nevcairiel> i prefer the msvc way where they just work without weird flags
[12:19:55 CET] <JEEB> yeah, you basically would have to separate them per file if not per function
[12:20:16 CET] <ismail> gcc ifuncs?
[12:20:23 CET] <ismail> hmm no
[12:21:24 CET] <nevcairiel> apparently since gcc 4.8 you can specify it per-function
[12:21:33 CET] <ismail> target attribute I guess
[12:21:36 CET] <ismail> it works for clang too
[12:21:49 CET] <nevcairiel> although according to the docs, gcc is supposed to pick the appropriate variant by itself
[12:21:51 CET] <nevcairiel> which sounds weird
[12:22:31 CET] <ismail> https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html target section.
[12:24:46 CET] <nevcairiel> anyway, i still think using yasm code has more advantages that outweigh the "i cba to learn how to do it" argument
[12:33:25 CET] <BtbN> wm4, yeah, kind of like the OpenCL based filters already do
[12:33:46 CET] <BtbN> An OpenGL PIX_FMT would be possible though, but that's not something i planned to do
[12:34:06 CET] <wm4> passing GL textures would be nasty
[12:34:25 CET] <wm4> because it somehow needs a cooperating context
[12:34:46 CET] <wm4> in fact, just a filter creating a GL context would be nasty (what if the API user also uses GL)
[12:35:33 CET] <BtbN> could be put in a thread to prevent breakage in client applications
[12:36:12 CET] <wm4> just to isolate the state?
[12:36:54 CET] <BtbN> To isolate the active context, and not override a potential context that's active in the application using lavf
[12:39:33 CET] <BtbN> The biggest problem I see is the context creation itself. It works fundamentaly diffrent on every platform
[14:37:23 CET] <BBB> Timothy_Gu: decoders is old model, avhwaccel is new model
[14:37:31 CET] <BBB> Timothy_Gu: consider hw decoders deprecated in favour of avhwaccel
[14:37:36 CET] <wm4> BBB: not true
[14:37:41 CET] <wm4> at all
[14:37:44 CET] <BBB> :(
[14:37:54 CET] <wm4> you evne mix concepts
[14:38:13 CET] <wm4> the AVHWAccel struct is just a meaningless helper
[14:38:35 CET] <wm4> it's for listing hwaccel support, and somehow libavcodec/utils.c uses it to exclude hw pixfmts if they're not used
[14:39:09 CET] <BBB> well why dont you explain it then, not to me but to him
[14:39:12 CET] <wm4> the hwaccels like vdpau and vaapi are actual hwaccels which built upon a software decoder and accelerate it by grabbing certain entrypoints
[14:39:37 CET] <wm4> (they're called slice decoders, and you need to do significant bitstream parsing etc. to use them)
[14:40:09 CET] <wm4> and then there are full bitstream hw decoders - these have their own AVCodec (and also a AVHWAccel to make utils.c happy at least)
[14:40:17 CET] <wm4> like qsv and mmal
[14:41:07 CET] <wm4> and then we have a very old thing, the vdpau hw decoder, which is a slice decoder and actually uses the h264 decoder to do some work, and this thing has been deprecated for years
[14:55:32 CET] <durandal_1707> Isn't that Carl thing?
[14:58:21 CET] <BBB> I believe so, yes
[14:58:27 CET] <kierank> bloody carl
[14:58:34 CET] <BBB> my mplayer build from 1988 uses it"
[14:58:44 CET] <BBB> it works, why break it"
[14:59:00 CET] <BBB> and now someone wants intrinsics
[14:59:48 CET] <wm4> what a terrible world to live in
[15:00:52 CET] <BBB> at least this one I have voting rights in
[15:01:38 CET] <wm4> so can someone remove the old vdpau decoder
[15:02:04 CET] <BBB> carl has blocked that every single time, no?
[15:02:25 CET] <Daemon404> >carl
[15:02:32 CET] <Daemon404> vote, he can fuck himself
[15:02:36 CET] <Daemon404> sorry for the poor language
[15:02:39 CET] <Daemon404> my carl patience is long gone
[15:02:57 CET] <kierank> he is the cancer of this project
[15:03:10 CET] <kierank> but has too many neckbeard supporters
[15:03:24 CET] <ismail> wow slow down :) thats some really bad language there.
[15:03:37 CET] <Daemon404> ismail, try dealing with carl for years and come back
[15:03:38 CET] <ismail> <-- not a Carl fan
[15:03:47 CET] <wm4> I guess too many people have run out of patience
[15:03:49 CET] <Daemon404> or alternatively
[15:03:54 CET] <ismail> I remember having weird mails from him after libav fork
[15:03:58 CET] <Daemon404> recieve some hate male to your personal email fro mcarl
[15:04:01 CET] <Daemon404> like many of us have
[15:04:06 CET] <ismail> I did so too :)
[15:04:07 CET] <kierank> Hello!
[15:04:11 CET] <kierank> you are a liar and a thief
[15:04:15 CET] <ismail> lol
[15:04:17 CET] <ismail> indeed
[15:04:33 CET] <ismail> He thought libav guys were paying me to put libav in openSUSE
[15:04:37 CET] <ismail> weird guy
[15:04:40 CET] <Daemon404> lolwut
[15:05:07 CET] <ismail> kierank: at least he greets properly
[15:24:18 CET] <durandal_1707> ismail: who paid you then?
[15:36:20 CET] <BtbN> why does the mfx encoder have a huge bunch of binary arrays?
[15:36:43 CET] <Daemon404> because mxf is sadness
[15:36:46 CET] <Daemon404> theyre probably uuids
[15:37:17 CET] <BtbN> no, carl just send a patch that modified one of them
[15:38:07 CET] <rcombs> because nobody knows if it's spelled mfx or mxf off the top of their head
[15:38:15 CET] <rcombs> (might help if anyone knew what it stood for)
[15:38:36 CET] <Daemon404> BtbN, looks like he added it brokenly originally
[15:39:02 CET] <wm4> rcombs: they're different things
[15:39:15 CET] <rcombs> wm4: also doesn't help
[15:39:37 CET] <rcombs> (I don't remember which is which _and_ don't know which either stands for)
[15:39:39 CET] <Gramner> ugh intrinsics. let's not create a soup of various "languages" that does essentially the same thing but in completely different ways. I'm also no fan of intrinsics "functions" with super-long names that's often very different from the instructions they map to
[15:39:56 CET] Action: Daemon404 clobbers Gramner's registers
[15:40:06 CET] <mateo`_> rcombs: hahahaha, I had this confusion first time I saw the "mfx" decoder, I was like what the ...
[15:40:17 CET] <rcombs> one's a container used in cinema and the other's a weird intel hwaccel binary blob thing
[15:40:39 CET] <ubitux> 3 letters combinations are causing too much confusion, we should stick with 1-letter naming
[15:40:39 CET] <Gramner> e.g. _mm_cvtsi64x_si128 vs movq
[15:41:35 CET] <durandal_1707> what?
[15:43:13 CET] <rcombs> convert signed integer 64-bit (x?) to signed integer 128-bit?
[15:43:27 CET] <rcombs> I guess because movq to an SSE register clears the upper half?
[15:44:18 CET] <Gramner> "convert unsigned 64-bit int to unsigned 128-bit int" would be more accurate. but "convert" is a weird description for a move
[15:44:42 CET] <rcombs> what's the `si` stand for then
[15:44:44 CET] <Gramner> "si" means "unsigned integer" i guess
[15:44:47 CET] <rcombs> :|
[15:44:57 CET] <jkqxz> Not that I really disagree, but that's cherry-picking pretty much the worst possible example.  (Half the time you can't even generate the movq you want in intrinsics at all.)
[15:48:19 CET] <nevcairiel> _mm_cvtsi64x_si128 is for signed values, it takes an __int64 afterall, they use i and u for signed and unsigned
[15:48:55 CET] <nevcairiel> i forgot what the s specifically was for
[15:48:59 CET] <Gramner> there's also _mm_cvtsi64_si128 which "copies a 64-bit integer into a 128-bit parameter" unlike _mm_cvtsi64x_si128 that "copies a 64-bit value to a __m128i structure"
[15:49:37 CET] <nevcairiel> who defined those names anyway, Intel?
[15:49:42 CET] <Gramner> no idea
[15:49:42 CET] <J_Darnley> Perhaps someone would like to show how to use our existing *aligned* constants without loading them into a register
[15:49:58 CET] <J_Darnley> particularly pb_0
[15:51:20 CET] <J_Darnley> That is my second biggest gripe after the names.
[15:53:58 CET] <nevcairiel> if the instruction in question can read from memory, then just reference them?
[15:55:09 CET] <nevcairiel> its used in some functions like this, ie.  paddsb m2, [pb_4]
[15:56:11 CET] <jkqxz> (I remember banging my head against movq specifically when forced to write some stuff in intrinsics a few years ago.  As long as you never need to touch memory, intrinsics are basically fine.  Once you do, making the compiler do something more sensible than a load of single-word transfers is an immense pain.  And NEON is (was?) even worse.)
[15:57:05 CET] <J_Darnley> I have tried "just referencing them" in my own project and gcc bitched about types or incompatible something else
[15:57:22 CET] <J_Darnley> The assembler doesn't care about types.  If the linker can resolve the location of pb_4 then it will work.
[15:57:36 CET] <nevcairiel> so you are trying to use them outside of asm?
[15:57:46 CET] <jkqxz> -flax-vector-conversions
[15:57:55 CET] <J_Darnley> Yes.  Intrisics.  Like the guy here is trying to sell us on.
[15:58:19 CET] <nevcairiel> cast to __m128i* ? :d
[15:59:30 CET] <nevcairiel> no idea though, those constants were not designed for such use
[16:04:12 CET] <jkqxz> Explicit load intrinsics like _mm_load_si128((__m128i*)pb_0) will work.  Normal assignment may not.
[16:04:36 CET] <Daemon404> why are we even discussing this
[16:05:14 CET] <Gramner> intrinsics are nice if you have an existing c/c++ project with no asm and just need to add SIMD to one or a few functions because it's easy to get it going, with yasm you need to set up the build environment etc. but that's a moot point in ffmpeg's case since all of that is done and works
[16:07:26 CET] <rcombs> I've seen people argue it's better for NEON because you can easily share between armv7 and armv8
[16:07:54 CET] <rcombs> which reminds me that someone needs to put together a set of as macros for that
[16:09:36 CET] <wm4> why is there no pixdesc function that returns how many bytes per pixels there are on a plane
[16:10:19 CET] <Daemon404> you can derive it from the pixdesc itself
[16:10:23 CET] <Daemon404> i suppose.
[16:10:38 CET] <wm4> yes after destroying a wall with your head
[16:10:46 CET] <wm4> because it's that simple
[16:11:14 CET] <Daemon404> stuff liek android has the concept of "pixel stride" iirc
[16:11:20 CET] <Daemon404> i assume this is why you want t
[16:11:21 CET] <Daemon404> it
[16:11:35 CET] <wm4> not really
[16:11:48 CET] <wm4> but yes sounds equivalent
[16:15:38 CET] <rcombs> wm4: AVComponentDescriptor.step?
[16:16:18 CET] <rcombs> or, well, more complex if you're non- or semi-planar
[16:16:37 CET] <durandal_1707> there's function to get pixelstep and than you just multiply
[16:16:46 CET] <wm4> actually I've thought maybe it's av_image_fill_max_pixsteps, but I don't understand its doxygen
[16:16:48 CET] <rcombs> or if you're subsampling and want to count per pixel instead of per (sub)sample
[16:16:59 CET] <rcombs> wm4: what's the context for this?
[16:17:39 CET] <wm4> trying to layout microshit surfaces
[16:17:52 CET] <rcombs> oh lovely
[16:17:58 CET] <wm4> they only have pitch for plane 0 (if you're _really_ lucky, most time you don't have a pitch)
[16:18:15 CET] <wm4> so how the fuck do you calculate the pitch for the other planes
[16:19:13 CET] <rcombs> so what is this, NV12?
[16:19:22 CET] <wm4> there are many supported formats
[16:20:41 CET] <rcombs> pitch here meaning step between the start of 2 samples in a component?
[16:21:00 CET] <wm4> no, linesize (as ffmpeg calls it)
[16:21:11 CET] <Daemon404> so, strode.
[16:21:12 CET] <Daemon404> stride
[16:21:15 CET] Action: Daemon404 runs
[16:24:07 CET] <rcombs> wm4: so it's probably expecting either stride of the chroma planes to be <luma stride / 2> or <width/2, aligned to& something>
[16:24:14 CET] <jkqxz> Do any of the formats actually run into that problem?  YUV420P can be laid out line-interleaved so that the pitch is the same for all planes.
[16:24:28 CET] <wm4> rcombs: that's how it usually is, and that's not the problem
[16:24:44 CET] <wm4> I just didn't want to hardcode the shit
[16:26:41 CET] <rcombs> what's that got to do with bytes per pixel on a given plane
[16:27:43 CET] <wm4> I just thought that'd be a good idea to derive the plane pitch, or maybe not, I've given up on it anyway
[16:28:55 CET] <rcombs> are there formats available that have >1 byte per sample?
[16:29:20 CET] <wm4> packed yuv and p010
[16:29:34 CET] <rcombs> I mean per component
[16:30:00 CET] <wm4> p010 (but you can treat that exactly like nv12)
[16:30:16 CET] <rcombs> turns out I have no idea what p010 is
[16:30:32 CET] <wm4> 16 bit nv12
[16:30:41 CET] <wm4> or 10 bit padded
[16:31:18 CET] <nevcairiel> its what gpus like to use to output 10-bit content
[16:32:56 CET] <kierank> silly format
[17:45:08 CET] <j-b> mateo`_: wbs: "Android N includes namespace changes to prevent loading of non-public APIs."
[17:53:13 CET] <wm4> lol
[17:57:29 CET] <mateo`_> j-b: yeah i saw that
[17:57:56 CET] <mateo`_> I think I will remove the use of this JniInvocation stuff and only rely on av_jni_set_java_vm
[17:59:10 CET] <j-b> mateo`_: yes, I'd say so.
[17:59:11 CET] <mateo`_> Also i'm trying to compile FFmpeg for arm with their new ndk using clang3.8 as they said gcc 4.9 is deprecated
[17:59:23 CET] <mateo`_> and clang3.8 does not support .altmacro ...
[18:00:02 CET] <mateo`_> and we are using it everywhere in the arm code :(
[18:01:56 CET] <mateo`_> another note about this new ndk release, android-ndk-r11-linux-x86_64.zip unzip as android-ndk-r11-linux-x86_64.tar.bz2
[18:02:29 CET] <mateo`_> and it's not a bz2 tarball, it's a directory
[18:05:40 CET] <rcombs> j-b: are they adding a public way to start the IPC thread pool?
[18:07:08 CET] <rcombs> also advising everyone to statically link libcrypto.a
[18:07:17 CET] <rcombs> (kek)
[18:07:34 CET] <Daemon404> wut
[18:07:38 CET] <Gramner> yeah, that seems like such a good idea
[18:07:53 CET] <rcombs> "Use of SSL_ctrl symbol from libcrypto.so should be replaced with an app local version. For example, you should statically link libcyrpto.a in your .so file or include your own dynamically libcrypto.so from BoringSSL or OpenSSL in your app."
[18:07:58 CET] <Daemon404> but it's boringssl! google assures me it will never have a secuerity issue!
[18:08:01 CET] <Gramner> because everyone obviosuly keeps their statically linked crypto libs up to date
[18:08:19 CET] <rcombs> https://developer.android.com/preview/behavior-changes.html#ndk
[18:09:30 CET] <mateo`_> https://www.reddit.com/r/androiddev/comments/49qup4/ndk_r11_release_is_live/ (there are some useful comments about the situation of their new ndk release)
[18:09:39 CET] <Daemon404> rcombs, i also like how it's broken english
[18:09:59 CET] <rcombs> Daemon404: libcyrpto.a is my favorite static archive
[18:12:30 CET] <Daemon404> yes
[18:17:25 CET] <Daemon404> rcombs, also when you link your own libcrypto, its now gpl violating
[18:17:30 CET] <Daemon404> since it is no longer a system library
[18:17:44 CET] <rcombs> Daemon404: assuming your app is GPL, yeah
[18:17:53 CET] <Daemon404> see: vlc
[18:18:05 CET] <Daemon404> well, lgpl
[18:18:09 CET] <rcombs> GNUTLS to the rescue
[18:18:15 CET] <cone-066> ffmpeg 03Matthieu Bouron 07master:8d0a21805820: lavc/ffjni: fix uninitialized variable
[18:18:21 CET] <rcombs> ETA on that OpenSSL Apache 2.0 relicense?
[18:18:53 CET] <Daemon404> never
[18:19:07 CET] <Daemon404> for hysterical raisins
[18:19:09 CET] <Daemon404> (ssleay)
[18:19:10 CET] <rcombs> they said it was happening but yeah seems& difficult
[18:19:30 CET] <rcombs> what does eay actually have to say on the topic
[18:19:40 CET] <Daemon404> i dont know
[18:24:12 CET] <Zeranoe> Does anyone have experience debugging FFmpeg on Windows with GDB?
[18:30:32 CET] <JEEB> for me it worked like everywhere else
[18:30:37 CET] <JEEB> gdb ffmpeg.exe
[18:30:43 CET] <JEEB> > shows it loaded symbols
[18:30:48 CET] <JEEB> run muh params
[18:30:53 CET] <JEEB> > wait for crash
[18:30:56 CET] <JEEB> bt full
[18:30:57 CET] <Zeranoe> Just trying a simple "start" and I get "Cannot insert breakpoint 1." "Cannot access memory at address 0x140e0bd20". Everything works find on an old build (2.8.6) but git always does that error
[18:31:10 CET] <Zeranoe> fine*
[18:33:29 CET] <Zeranoe> Both versions built the same exact way with the same toolchain
[18:34:28 CET] <nevcairiel> i noticed that something seems to have caused this to break, but i didnt bother to research yet what
[18:39:31 CET] <Zeranoe> Would anyone be willing to try and reproduce if I provide the exe with the symbols? JEEB perhaps?
[18:41:36 CET] <JEEB> unfortunately I have still work to do :)
[18:43:21 CET] <cone-066> ffmpeg 03Carl Eugen Hoyos 07master:bd2cc3c42c0f: lavf/movenc: Fix help output.
[18:44:10 CET] <nevcairiel> my gdb crashes the app when i put a breakpoint in, thats fun
[18:44:54 CET] <Zeranoe> nevcairiel: Same error? What's your platform?
[18:45:20 CET] <nevcairiel> nah it inserts the breakpoint fine, it just crashes when trying to run ffmpeg when i did set a breakpoint
[18:46:05 CET] <Zeranoe> Mine wont even start...
[18:51:22 CET] <nevcairiel> i should probably fetch a gcc that matches my toolchain more closely
[18:53:05 CET] <Zeranoe> I just compiled my own gdb using the same toolchain that built FFmpeg and got the same error
[18:53:50 CET] <nevcairiel> maybe i should start doing that, include gdb in my toolchain build
[19:01:00 CET] <nevcairiel> with a fixed gdb version i can reproduce the issue though
[19:01:06 CET] <nevcairiel> with 2.8 it still worked, with 3.0 its broken
[19:01:09 CET] <nevcairiel> lets bisect!
[19:03:55 CET] <nevcairiel> way too many commits between 2.8 and 3.0
[19:05:02 CET] <Zeranoe> Yeah there's a ton
[19:12:26 CET] <Zeranoe> is there an env variable or something that will cause FFmpeg to break early?
[19:13:05 CET] <kierank> eh?
[19:13:17 CET] <kierank> break early how
[19:13:51 CET] <Zeranoe> Sometimes programs implement a debugger check that triggers a breakpoint if it finds it's being watched
[19:15:25 CET] <Zeranoe> I'd like to attach a debugger to a running instance of FFmpeg, but my command doesn't cause FFmpeg to prompt. I could probably do something with -y if there's no way to break otherwise 
[19:26:12 CET] <nevcairiel> Bisecting: 223 revisions left to test after this (roughly 8 steps) ... zzz
[19:26:35 CET] <Zeranoe> nevcairiel: I was just about to get started
[19:26:36 CET] <nevcairiel> if only configure wouldnt be that slow on windows
[19:26:49 CET] <Zeranoe> nevcairiel: Cross compiling?
[19:27:07 CET] <nevcairiel> that would even be slower since it needs far more manual steps =p
[19:27:19 CET] <Zeranoe> how?
[19:27:43 CET] <Zeranoe> I run Debian in a VM and just copy the compiled exe over
[19:27:55 CET] <nevcairiel> see, one extra step, copying
[19:28:00 CET] <Zeranoe> lol
[19:28:01 CET] <nevcairiel> now i just run a script that does all of it
[19:28:12 CET] <nevcairiel> it just takes a while, but i dont need to do anything
[19:29:13 CET] <nevcairiel> someone should come up with a special optimized bash version that implements a bunch of this stuff as built-ins so that it has to fork less
[19:29:31 CET] <drv> ffsh
[19:30:01 CET] <Daemon404> uh, like busybox?
[19:30:15 CET] <nevcairiel> something complete enough to run  ffmpeg configure =p
[19:37:22 CET] <Daemon404> it can
[19:37:24 CET] <nevcairiel> really curious what might have broken this
[19:37:33 CET] <jamrial> compiling on windows sucks. configure takes ages, gcc trashes my hdd really hard (especially during linking)
[19:37:45 CET] <jamrial> ccache doesn't perform as good as on linux
[19:37:47 CET] <nevcairiel> i have a ssd, i dont notice that, just configure being slow
[19:38:26 CET] <nevcairiel> maybe i should test if busybox is actually any better then
[19:38:35 CET] <nevcairiel> who knows if their windows port is as complete
[19:39:17 CET] <nevcairiel> (and i never bothered with ccache)
[19:44:53 CET] <Compn> jamrial : every time i use mingw on windows it corrupts one of my harddrives :D
[19:45:10 CET] <atomnuker> color me impressed, we have a tta encoder and asm for ttadec
[19:45:35 CET] <atomnuker> never knew the format had so much attention
[19:46:01 CET] <nevcairiel> it doesnt, some people like their pet projects though
[19:46:05 CET] <nevcairiel> sounds like something durandal_1707 would do
[19:46:15 CET] <jamrial> he did
[19:46:44 CET] <nevcairiel> the encoder appears pretty simple from code size
[19:46:58 CET] <jamrial> yeah, it's fairly simple compared to other lossless codecs
[19:47:32 CET] <nevcairiel> Bisecting: 13 revisions left to test after this (roughly 4 steps)
[19:47:38 CET] <nevcairiel> cant it just tell me which these 13 are
[19:47:47 CET] <nevcairiel> faster to read them than to make it recompile 4 times =P
[19:48:49 CET] <nevcairiel> hm git bisect view apparently
[19:49:42 CET] <jamrial> tta is open source and has an official library with a c api. tak is the real fringe lossless codec, being closed source and written in i think pascal
[19:50:53 CET] <nevcairiel> configure: Force mingw's ld to keep the reloc section
[19:50:56 CET] <nevcairiel> this one, apparently
[19:52:53 CET] <nevcairiel> 91b668acd6decec0a6f8d20bf56e2644f96adcb9
[19:53:39 CET] <Zeranoe> Interesting...
[19:54:31 CET] <Zeranoe> Makes sense
[20:22:06 CET] <J_Darnley> Zeranoe nevcairiel: dash in cygwin runs configure at about twice the speed
[20:22:28 CET] <J_Darnley> perhaps there's a msys version
[20:22:38 CET] <nevcairiel> i should time various alternatives
[20:22:43 CET] <J_Darnley> (or whatever toolchain you're using)
[20:26:08 CET] <Zeranoe> I started cross compiling in a VM and I'll never go back.
[20:49:53 CET] <Zeranoe> It looks like 4d8f536b535487063a08609636e712ad86d2ad54 breaks QSV for Haswell-DT 4th gen CPUs, or at least mine
[20:54:38 CET] <Zeranoe> nevcairiel: Do you need me to do anything to get that gdb issue resolved?
[21:10:03 CET] <durandal_1707> anyone saw nice pull request with splendid yasm optimizations?
[21:14:00 CET] <Daemon404> ... this one: https://github.com/FFmpeg/FFmpeg/pull/183 ?
[21:14:02 CET] <Daemon404> lmao
[21:14:40 CET] <wm4> I don't understand why there are dozens of PRs even after I added that "warning"
[21:15:05 CET] <wm4> and stupid comments that we should switch to github
[21:15:18 CET] <Daemon404> github effect
[21:15:27 CET] <Daemon404> the general level of discourse on github is... concerning.
[21:16:17 CET] <Daemon404> ... why did i read the comments on your thread
[21:16:19 CET] Action: Daemon404 barfs
[21:17:14 CET] Action: wm4 hands out barf bags
[21:24:59 CET] <cone-066> ffmpeg 03Martin Cracauer 07master:73d1398f0c4c: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing
[21:37:31 CET] <Compn> do you think people are using github repos as resume fodder?
[21:37:40 CET] <Compn> i have over 5 repos on github... :P
[21:40:48 CET] <Compn> maybe we need a dev to play github ?
[21:41:03 CET] <Daemon404> have you seen the quality of those PRs?
[21:41:10 CET] <Daemon404> we're missing nothing of value
[22:53:31 CET] <atomnuker> what happens when seeking to the audio samples?
[22:53:53 CET] <atomnuker> for example if a codec uses 1024 samples per frame
[22:54:14 CET] <atomnuker> and you want to seek to some point in the future which would land you on sample 623 of a frame
[22:54:39 CET] <wm4> decode the frame and skip 623 samples?
[22:55:07 CET] <atomnuker> ah, ok
[22:55:44 CET] <atomnuker> I'm experimenting with huge avctx->frame_size so I was wondering if that had implications on seeking
[22:57:07 CET] <cone-066> ffmpeg 03Michael Niedermayer 07master:2540d884f3fd: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool
[23:00:15 CET] <nevcairiel> seeking is never this accurate anyway,  you should consider yourself lucky if it finds the perfect packet to seek to
[23:00:41 CET] <Daemon404> depends on the format ;p
[23:02:35 CET] <wm4> Daemon404: and the demuxer
[23:04:10 CET] <nevcairiel> Daemon404: always fun when people uise idiotic pull requests as bug reports because you disabled the issue functionality, isnt it
[23:04:30 CET] <Daemon404> lulz
[23:11:32 CET] <Zeranoe> nevcairiel: Shall I submit a bug for the GDB issue?
[23:14:49 CET] <nevcairiel> no need
[23:20:10 CET] <Zeranoe> Ah, I see http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191195.html
[23:20:39 CET] <Zeranoe> Thank you
[00:00:00 CET] --- Fri Mar 11 2016