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

[burek]

[00:21:37 CEST] <prelude2004c> can you guys believe this %#$$ .. i am stuck on " Xlib:  extension "NV-GLX" missing on display ":0". " 
[00:21:42 CEST] <prelude2004c> can't run vdpau info on that
[00:26:28 CEST] <cone-885> ffmpeg 03Michael Niedermayer 07master:0b9b3163f2a9: avcodec/libxvid: Fix use of uninitialized AVPacket fields
[00:34:33 CEST] <DHE> prelude2004c: fyi, I'm taking another crack at a fix...
[00:35:24 CEST] <prelude2004c> much appreciated... and i am trying to get vdpau going .. this is why i hate that damn things.. pain in the ass to get going .. error like " Xlib:  extension "NV-GLX" missing on display ":0". " which right now i can't get past
[00:35:25 CEST] <prelude2004c> :(
[00:35:57 CEST] <prelude2004c> i am trying to do a side by side comparison of quality so we can see if we need to tune anything on nvenc.. if not, then we just have to figure out the decoding which vdpau should take care of
[00:38:02 CEST] <DHE> strange, I have that extension working just fine without needing to configure it. are you using the nVidia driver in your X11 system
[00:42:43 CEST] <DHE> if I want to post a patch to the mailing list, is attaching it as MIME considered acceptable? (I don't know exactly what thunderbird will do to it, so I'm assuming the worst)
[00:49:59 CEST] <jkqxz> DHE:  Yes, the file output by git format-patch as an attachment to an email is acceptable.  (A raw diff is not.)
[00:51:53 CEST] <DHE> k thx
[00:53:19 CEST] <DHE> I might be doing that in a few hours, maybe tomorrow. gotta make sure this patch actually works, and that takes 20 minutes per run
[00:53:56 CEST] <cone-885> ffmpeg 03Marton Balint 07master:37d201aad9f7: ffplay: simplify display code
[00:53:57 CEST] <cone-885> ffmpeg 03Marton Balint 07master:15005701b590: avformat/movenc: propagate shift_data errors properly
[00:53:58 CEST] <cone-885> ffmpeg 03Marton Balint 07master:0d0b9397d63a: avformat/movenc: remove useless if and reindent
[00:54:32 CEST] <michaelni> atomnuker, coverity found 2 issues in aacpsy.c 1361962 (uninit use of 2 cases of clippings) didnt investigate so dunno if false positive or real
[00:57:35 CEST] <atomnuker> ah, thanks for reminding me
[01:42:08 CEST] <DHE> guess it'll have to wait until tomorrow...
[01:42:14 CEST] <DHE> prelude2004c: willing to try v2?
[01:42:21 CEST] <prelude2004c> of course
[01:42:28 CEST] <prelude2004c> still trying this damn nvidia driver thing :( 
[01:42:44 CEST] <prelude2004c> loosing my mind over here
[01:44:12 CEST] <DHE> https://github.com/DeHackEd/FFmpeg/commit/48167d81dc8a89.patch it seems to pass my 28 hour test video, and I'm running it on live content now. waiting for results, which will proably come in tomorrow
[01:44:14 CEST] <prelude2004c> i want to get this going so i can trully compare the differences between nvtranscoder and nvenc
[01:44:28 CEST] <prelude2004c> cool... did the old v1 fail ?
[01:44:32 CEST] <DHE> any reason you can't just save a sample to disk then test that? (we're getting off topic)
[01:44:37 CEST] <DHE> prelude2004c: you tell me. you ran it
[01:44:50 CEST] <prelude2004c> oh i though you found a bug and now corrected it :) 
[01:45:22 CEST] <DHE> no, I'm taking a different approach. as someone here suggested, I put the fix right into the mpegts demuxer rather than having libavformat's wrappers handle it
[01:49:21 CEST] <prelude2004c> cool
[01:56:31 CEST] <DHE> if it passes, I'll propose it to the mailing list
[02:01:20 CEST] <prelude2004c> ok i am going to run it .. still trying to get vdpau going here.... hopefully i will get it soon
[02:09:20 CEST] <cone-885> ffmpeg 03Rostislav Pehlivanov 07master:a1953d4cec16: aacpsy: remove dead code
[02:22:14 CEST] <atomnuker> michaelni: fixed, also set CID1361963 to false positive, ignore (the vc2enc.c one)
[02:22:38 CEST] <michaelni> atomnuker, thx
[02:32:05 CEST] <CoJaBo> What........ exactly is this file doing?
[02:32:07 CEST] <CoJaBo> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/bmp_parser.c
[02:38:33 CEST] <atomnuker> it's a parser, it looks for a valid frame and sends it off to the decoder
[02:39:23 CEST] <atomnuker> durandal_1707 wrote it, but I think it might have been implemented to support some random stream of concatenated bmps images
[03:00:15 CEST] <CoJaBo> atomnuker:  well, the problem I'm having is that it's horrifically broken..
[03:00:38 CEST] <CoJaBo> I can't even figure it what is trying to do :/
[03:01:36 CEST] <atomnuker> what are you trying to do?
[03:05:03 CEST] <CoJaBo> atomnuker:  figure out why it crashes..
[03:07:12 CEST] <atomnuker> ok, now that's serious
[03:07:21 CEST] <atomnuker> which line is the crash?
[03:07:32 CEST] <CoJaBo> Dunno, i can't find it
[03:07:41 CEST] <atomnuker> gdb?
[03:07:44 CEST] <CoJaBo> where is that function even called?
[03:07:55 CEST] <CoJaBo> It's an oom crash
[03:08:09 CEST] <atomnuker> not a segfault?
[03:08:23 CEST] <CoJaBo> no such luck :/
[03:09:16 CEST] <CoJaBo> If the input file contains the letters "BM" anywhere in it, ffmpeg tries to read the entire input file into memory
[03:09:34 CEST] <atomnuker> try commenting out the ff_combine_frame() call there
[03:13:40 CEST] <DHE> so it's reading otherwise random bytes as the image size and loading it?
[03:17:21 CEST] <CoJaBo> DHE:  Quite possibly
[03:18:10 CEST] <atomnuker> ff_combine_frame is the only thing allocating memory there
[03:18:11 CEST] <CoJaBo> Here's the bug and testicle https://trac.ffmpeg.org/ticket/5598
[03:26:44 CEST] <DHE> you can use a ulimit to deny the memory allocation
[03:32:27 CEST] <CoJaBo> doesn't really get me that far tho :/
[03:52:10 CEST] <prelude2004c> DHE, i have loaded the patch so now we wait... that said, i am still trying to do a side by side comparison with nvenc vs nvtranscoder.. if i can get this damn vdpau working :( 
[06:17:14 CEST] <prelude2004c> can you guys believe that nobody in ubuntu & nobody at nvidia has been to help me so far ? . you guy shave to get me off this whole vdpau dependancy of using the X ... its an annoying requirement
[06:17:31 CEST] <prelude2004c> especially when we are encoding on remote servers not a local game machine
[12:22:21 CEST] <durandal_1707> michaelni: is it possible to do #5521?
[12:23:25 CEST] <nevcairiel> doesnt seem something that our current logging framework is well suited for
[12:50:07 CEST] <BtbN> What does the SKIPHEADERS variable in the Makefiles do?
[12:50:29 CEST] <nevcairiel> it skips testing headers that have external dependencies
[12:50:51 CEST] <BtbN> What kind of tests?
[12:51:01 CEST] <nevcairiel> make checkheaders
[12:51:15 CEST] <nevcairiel> it builds the header to test if all requiured deps are included etc
[12:51:38 CEST] <BtbN> ah, so conditionaly adding nvenc.h seems correct
[12:51:55 CEST] <nevcairiel> just like every other thing that requires external libraries, yes
[12:56:24 CEST] <ubitux> annoying this merge, heh.
[13:21:20 CEST] <dcr_uab> hi
[13:21:50 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:7aa16d59bfc5: avcodec/nvenc: split H264/HEVC encoder definitions into separate files
[13:22:22 CEST] <dcr_uab> I'm trying to generate some video from a custom hardware
[13:22:35 CEST] <dcr_uab> and use it as input to ffmpeg
[13:23:01 CEST] <dcr_uab> I do not want to implement a v4l driver, to avoid kernel development
[13:23:59 CEST] <dcr_uab> is there any "simple" video source sample device that I could use as a base to extend currently available devices 
[13:24:01 CEST] <dcr_uab> ?
[14:30:12 CEST] <BtbN> Building on 36 cores is something I could get used to.
[14:30:25 CEST] <JEEB> yeah, I need to get my home server xeon
[14:30:35 CEST] <BtbN> well, 2
[14:30:39 CEST] <BtbN> There is no 36 core xeon
[14:30:49 CEST] <BtbN> so 2 18 core it is
[14:31:18 CEST] <BtbN> only problem is, just those two CPUs are more expensive than some cars.
[14:31:20 CEST] <JEEB> I am really pondering on getting a refurbished E5-2670... I think that's what it was?
[14:31:43 CEST] <JEEB> since you can get two of those with a mobo and 128GiB of RAM for ~$500
[14:33:02 CEST] <BtbN> Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz
[14:33:07 CEST] <BtbN> that's what this AWS instance has.
[14:33:38 CEST] <nevcairiel> those are still super expensive :)
[14:33:45 CEST] <JEEB> yeah
[14:33:57 CEST] <DHE> I have some 2690 v1 chips. 8 cores @ 2.9GHz
[14:34:17 CEST] <DHE> where you getting them for that cheap?
[14:34:18 CEST] <JEEB> I am wondering if I should vulture a 2012 E5 or wait for the next gen of xeons to become cheap on the refurb market
[14:34:29 CEST] <BtbN> nevcairiel, those are non-public, not even listed on ark
[14:35:15 CEST] <nevcairiel> if you buy a million chips, intel will build you a special one
[14:35:55 CEST] <BtbN> I like how this beast builds ffmpeg in 11 seconds
[14:36:30 CEST] <durandal_1707> give me it!
[14:36:46 CEST] <BtbN> The largest c4 instance on AWS ;)
[14:39:13 CEST] <michaelni> BtbN, "Commit:     Ubuntu <ubuntu at ip-172-31-24-241.eu-west-1.compute.internal>" from 7aa16d59bfc537db69ffb08b9d5ec5f868cff56a
[14:39:44 CEST] <BtbN> huh?
[14:39:58 CEST] <michaelni> "Signed-off-by: Timo Rothenpieler <timo at rothenpieler.org>"
[14:40:00 CEST] <BtbN> why the hell did it do that. It correctly signed it off
[14:40:20 CEST] <michaelni> i dont know
[14:41:05 CEST] <michaelni> btw, noticed by carl not me
[14:41:23 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commits/master only did it for the first once, didn't do anything differently oO
[14:47:20 CEST] <BtbN> Does it determine that at push or commit time?
[14:47:28 CEST] <JEEB> commit
[14:47:37 CEST] <JEEB> push is just moving history from one place to another
[14:48:28 CEST] <BtbN> Then I'm clueless why it didn't work that one time.
[14:48:37 CEST] <BtbN> Configured the author globally before even cloning.
[14:50:16 CEST] <BtbN> I moved it arround with a pull --rebase, so I guess that's when it happend?
[14:50:40 CEST] <JEEB> shouldn't affect the author...
[14:50:48 CEST] <JEEB> oh wait, commit
[14:50:50 CEST] <JEEB> not author
[14:50:53 CEST] <JEEB> that could be it
[14:50:58 CEST] <nevcairiel> it would refresh the commiter  then, so if you did that on an env where no author was set
[14:51:08 CEST] <JEEB> yeah, but only committer, not author
[14:51:18 CEST] <BtbN> the author is fine
[14:51:25 CEST] <BtbN> as is the signoff
[14:51:27 CEST] <JEEB> k
[14:51:37 CEST] <JEEB> yeah, sign-off is part of commit message
[14:51:47 CEST] <nevcairiel> author and signoff dont change after the commit was made, unless you manually go and change it
[14:51:55 CEST] <nevcairiel> commiter changes when you change the commit in any way
[14:52:09 CEST] <JEEB> yeah
[14:52:13 CEST] <BtbN> I guess something in git barfed on itself there...
[14:52:29 CEST] <BtbN> Some strange condition where it ignored the globally set user
[14:54:15 CEST] <BtbN> Something I just wondered. For qmin/qmax, does min mean "worst quality"?
[14:54:26 CEST] <BtbN> So, -qmin 20 -qmax 10, or -qmin 10 -qmax 20
[14:54:57 CEST] <michaelni> qmin is nummerically minimum
[14:55:01 CEST] <nevcairiel> it maps to the qp range as you would understand qp,  so min is the highest quality
[15:15:12 CEST] <BtbN> https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows <- I guess this might be the source for a lot of people building with the memalign-hack for windows?
[15:17:27 CEST] <JEEB> it could be one of the sources of derp
[15:18:20 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:e1de62c5be1f: doc: Add color_trc values
[15:18:57 CEST] <BtbN> Not so sure about that pkg-config option either.
[15:20:09 CEST] <JEEB> if it's the static one, it's because many toolchains would otherwise link against the shared stdlib etc
[15:20:32 CEST] <JEEB> and people on windows usually expect their binaries to work as-is
[15:20:39 CEST] <BtbN> No, it's forcing the cross-build to use native pkg-config, instead of a potentily non-existent prefixed one.
[15:20:46 CEST] <JEEB> oh
[15:21:10 CEST] <BtbN> well, host pkg-config
[15:21:43 CEST] <BtbN> Not sure what problem that solves
[15:22:18 CEST] <RiCON> because using cross-prefix would prefix pkg-config too
[15:22:36 CEST] <BtbN> yes, which is the right thing to do.
[15:22:37 CEST] <nevcairiel> yeah i use that command as well
[15:22:40 CEST] <RiCON> and it doesn't really matter, just change PKG_CONFIG_PATH to the appropriate
[15:22:46 CEST] <nevcairiel> except mingw doesnt come with a prefixed pkg-config
[15:23:10 CEST] <RiCON> pkg-config doesn't need to be native
[15:23:10 CEST] <BtbN> But won't that break stuff, when that pkg-config finds stuff that's installed on the host, and wants to use it for the crosscompile?
[15:23:28 CEST] <RiCON> not if you change the path
[15:23:39 CEST] <BtbN> Well, the wiki article doesn't mention the pkg-config path at all.
[15:52:48 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:faffff88c21c: avcodec/nvenc: use AVOptions to select presets
[15:52:49 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:9824321b3214: avcodec/nvenc: convert profile parsing to AVOptions
[15:52:50 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:b0172873a89d: avcodec/nvenc: convert levels to AVOptions
[15:52:51 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:40df468ab174: avcodec/nvenc: convert tier to AVOptions
[15:52:52 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:f84dfbc74a4f: avcodec/nvenc: add rate control option
[15:52:53 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:b69335304d38: avcodec/nvenc: use INIT_CLEANUP to deal with init failures
[15:52:54 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:f052ef30ef65: avcodec/nvenc: allow configuring number of surfaces
[16:06:24 CEST] <BtbN> andrey_utkin, btw., the reason why I originally didn't use the caps stuff is because it used to lie.
[16:06:43 CEST] <BtbN> It reported a lot of features as unsupported, while they worked perfectly fine if you just used them.
[16:07:47 CEST] <BtbN> Seems like that got a lot better with recent drivers though.
[16:08:45 CEST] <BtbN> andrey_utkin, also, make sure to run tools/patcheck on your patches. There are a lot of hidden tabs instead of spaces and trailing spaces.
[16:09:14 CEST] <BtbN> Most of the stuff it reports about static vars can be safely ignored, but it spots a lot of actual mistakes.
[16:10:14 CEST] <BtbN> It also reports some issues of useless != 0 or == 0. But in some instances i preferred to keep them for improved readability.
[16:44:08 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:0d021cc8b30a: avcodec/nvenc: rework library load and GPU selection
[16:44:09 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:d3463912c196: avcodec/nvenc: extract timestamp calculations into separate function
[16:46:53 CEST] <cone-014> ffmpeg 03foo86 07master:d1f558b3628d: avcodec/dca: require checked bitstream reader
[16:46:54 CEST] <cone-014> ffmpeg 03foo86 07master:054a2c9fdf64: avcodec/dca: support EXSS marker in avpriv_dca_convert_bitstream()
[16:46:55 CEST] <cone-014> ffmpeg 03foo86 07master:1f7b67a1caef: avcodec/dca_parser: simplify state machine
[16:46:56 CEST] <cone-014> ffmpeg 03foo86 07master:214e63f85113: avcodec/dca_parser: skip initial padding
[17:04:54 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:2f53b5b74b65: avcodec/nvenc: refactor encode_frame a bit
[17:04:55 CEST] <cone-014> ffmpeg 03Andrey Turkin 07master:58c6dcb4b7e7: avcodec/nvenc: don't enqueue timestamps until a frame was accepted
[17:04:56 CEST] <cone-014> ffmpeg 03Timo Rothenpieler 07master:1330a0f31f37: avcodec/nvenc: Fix forcing constqp rc mode
[17:04:57 CEST] <cone-014> ffmpeg 03Timo Rothenpieler 07master:eae4eba9cbe1: avcodec/nvenc: twopass mode works in all modes
[17:04:58 CEST] <cone-014> ffmpeg 03Timo Rothenpieler 07master:971351b6642e: avcodec/nvenc: Handle minqp-only case in set_vbr
[17:20:26 CEST] <andrey_utkin> BtbN i guess you mentioned me by mistake?
[17:27:14 CEST] <CoJaBo> i wish any of the code was commented
[17:45:46 CEST] <andrey_turkin> BtbN: I was about to fix that commit with TEXT but I see you beat me to it
[17:46:19 CEST] <BtbN> andrey_utkin, indeed. Didn't even notice there were two of you.
[17:46:49 CEST] <andrey_turkin> yeah, that's the wrong one
[17:46:56 CEST] <andrey_turkin> Two different people actuall
[17:47:23 CEST] <andrey_turkin> same first name, different last names
[17:52:00 CEST] <andrey_utkin> wow
[17:52:06 CEST] <andrey_utkin> hi andrey_turkin :)
[17:52:21 CEST] <andrey_turkin> hi )
[17:53:29 CEST] <BtbN> andrey_turkin, so, no idea if you ever got these: https://bpaste.net/show/335ad92c5451
[17:56:03 CEST] <andrey_turkin> didn't get those. Sorry about not using patcheck; I tried to use it on a few commits but it just spammed about some errors which obviously were not errors so I gave up
[17:56:26 CEST] <andrey_turkin> should've kept using it
[17:56:38 CEST] <BtbN> yeah, it has a lot of false-positives. But it does reliably report tabs and trailing whitespaces
[17:56:53 CEST] <andrey_turkin> I can make that rename/reformat commit to make ffmpeg version resemble libav's, or the other way around. That would make remaining differences more obvious. Do you think this is a good idea?
[17:57:20 CEST] <BtbN> I'm quite happy with the current state of it.
[18:00:02 CEST] <andrey_turkin> ok then. On the related but different topic: did you heard anything about broken yuv420p coding on maxwells? It looks like chroma planes are in some different format than expected
[18:00:22 CEST] <BtbN> I only have Kepler-Hardware. And so far never heard of that.
[18:00:31 CEST] <andrey_turkin> it works fine on Keplers
[18:01:13 CEST] <andrey_turkin> also nv12 works fine
[18:01:30 CEST] <andrey_turkin> I'll try to reproduce this on Quadro when I've some free tie
[18:01:47 CEST] <andrey_turkin> *time
[18:01:54 CEST] <BtbN> There is one more thing in libav I'd like to merge over btw. They have a vastly diffrent timestamp logic, which appears to be slightly better in edge cases.
[18:01:59 CEST] <BtbN> https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/nvenc.c;h=1ff27a19327fafc445339e91d71471812a7f186d;hb=HEAD#l1259
[18:03:39 CEST] <andrey_turkin> doesn't it assumes CBR?
[18:03:46 CEST] <andrey_turkin> rather CFR
[18:05:55 CEST] <andrey_turkin> while ffmpeg''s version just basically reoders pts to get dts
[18:07:34 CEST] <BtbN> They both do that. The difference is ffmpeg does some rather strange offset calculations of which I'm not entirely sure why they are even neccesary.
[18:08:37 CEST] <BtbN> While the libav version only extrapolates the very first timestamp in case of b frames, and then uses the unmodified input timestamps.
[18:08:40 CEST] <andrey_turkin> oh right, I see now. First two are estimated then it is just reordering. I've no idea why ffmpeg does the rest
[18:08:57 CEST] <BtbN> Not even the first two, just the very first one, and only when there are b frames.
[18:08:58 CEST] <durandal_1707> michaelni: going to comment my mail about Sheer?
[18:09:45 CEST] <michaelni> durandal_1707, iam looking into ticket 5521
[18:10:14 CEST] <BtbN> like, ffmpeg substracts 1 from the dts, every time when there are b frames. And I have no idea why. That came in with a patch from nvidia, and it did fix stuff.
[18:12:02 CEST] <BtbN> I'm also not sure why "pic_params.inputDuration = 0;". The frame should contain a propper duration most of the time?
[18:13:20 CEST] <BtbN> libav does set the duration on the output frame, but never sets it on the input frame at all. Not even to 0.
[18:20:07 CEST] <durandal_1707> michaelni: also look at mail for unrelated problem
[18:25:39 CEST] <pfelt> is this the right place to ask questions on changes we made to the api between 2.8 and 3.0, or is that for #ffmpeg?
[18:33:24 CEST] <Compn> if you are working on a patch to fix something about the change, ask here
[18:33:37 CEST] <Compn> if you want to report a bug, in #ffmpeg (or please use the trac! )
[18:34:14 CEST] <Compn> hope that helps, pfelt
[18:40:36 CEST] <cone-014> ffmpeg 03Timo Rothenpieler 07master:69c25c0ad7e4: avcodec/nvenc: forward frame duration
[18:41:03 CEST] <pfelt> it's more a bug in a package that uses libav* but it was caused by a change in the api. i was just having a hard time finding where the data moved to
[18:41:08 CEST] <pfelt> i think i found it tho
[19:07:31 CEST] <BtbN> andrey_turkin, https://github.com/BtbN/FFmpeg/commit/e5babccfbcd83559247d28e215440a0e74060425
[19:07:50 CEST] <BtbN> that should be it. Or did I miss something?
[19:13:36 CEST] <andrey_turkin> looks good to me
[19:13:49 CEST] <BtbN> What I'm just wondering. Is it safe to assume av_fifo_generic_write/read never fail? They currently can't fail. But libav does check their return value. In some places...
[19:13:56 CEST] <BtbN> ffmpeg code seems to never check them.
[19:14:36 CEST] <andrey_turkin> I'm not even sure they work the same way
[19:14:52 CEST] <andrey_turkin> ffmpeg's version can and will return positive value iirc
[19:15:00 CEST] <andrey_turkin> some places in libav would consider that a failure
[19:15:51 CEST] <andrey_turkin> if I understood correctly they can't fail since their size is big enough to hold values for all the surfaces
[19:15:59 CEST] <BtbN> ah, generic_write returns total - size
[19:16:10 CEST] <BtbN> yes, they are safe in nvenc.
[19:16:23 CEST] <BtbN> But I'm just wondering, as a grep over the ffmpeg codebase shows that they are never checked
[19:16:38 CEST] <BtbN> And even in libav, they only check some of them
[19:16:40 CEST] <andrey_turkin> I don't think they can ever fail
[19:16:50 CEST] <andrey_turkin> if there isn't enough space they will stall
[19:18:02 CEST] <cone-014> ffmpeg 03Timo Rothenpieler 07master:e5babccfbcd8: avcodec/nvenc: Refactor timestamp generation logic
[19:39:34 CEST] <durandal_1707> kierank: who is employer?
[19:40:12 CEST] <kierank> See the thread
[19:40:33 CEST] <kierank> He removes his email thinking it will hide things 
[19:45:26 CEST] <durandal_1707> Oh
[19:54:34 CEST] <durandal_1707> argh
[20:00:13 CEST] <andrey_turkin> this is kinda weird. IMO it doesn't matter ho reported an issue as long as it is a valid issue. 
[20:05:34 CEST] <Illya> andrey_turkin: it's so you get the version info etc, but in this case they actually posted it above...
[20:37:50 CEST] <CoJaBo> How long does it generally take to get crash bugs fixed? Wondering if I should just wait, or try to implement a work-around...
[20:41:03 CEST] <durandal_1707> CoJaBo: does your bmp encoder writes file size in bitstream?
[20:41:20 CEST] <CoJaBo> durandal_1707: Yes
[20:42:13 CEST] <durandal_1707> michaelni: bmp parser again
[20:43:17 CEST] <CoJaBo> I was trying to figure out what the code is actually doing, but can't figure it out :/
[20:44:11 CEST] <michaelni> durandal_1707, iam not in MAINTAINERs for the bmp_parser
[20:45:01 CEST] <durandal_1707> but you added that fragile header check
[20:45:04 CEST] <michaelni> also iam still working on the ffprobe log feature you asked me about
[20:45:20 CEST] <CoJaBo> Passing size value from the BMP header to ffmpeg as the -frame_size argument actually fixes it, btw; not sure what, if anything, that means tho...
[20:45:22 CEST] <michaelni> i cant work on everything at once
[20:45:55 CEST] <durandal_1707> I asked if it was possible, not for you to work pro bono ;-)
[20:46:25 CEST] <CoJaBo> But how do you know for certain something is possible before doing it? :P
[20:47:23 CEST] <durandal_1707> CoJaBo: bmp header needs file size set, I will look at you bug report
[20:49:12 CEST] <CoJaBo> AFAIK, the size is a requirement of the BMP file format; I'd imagine there could be encoders that violate the spec, but ffmpeg should at least work with a compliant one...
[20:50:38 CEST] <durandal_1707> CoJaBo: that's how parser originally worked
[20:50:52 CEST] <CoJaBo> Why was it changed?
[20:56:25 CEST] <durandal_1707> to support noncompilant files
[20:57:54 CEST] <CoJaBo> Does it make sense to do that tho? Without the length, it's going to be rather difficult (if not flatly impossible) to determine the length without blind guesswork...
[20:59:30 CEST] <CoJaBo> It makes sense when reading from discrete files (as it could always fall back on the actual filesize and assume it wasn't truncated), but in a piped stream that doesn't seem like a reliably recoverable scenario.
[21:26:48 CEST] <michaelni> CoJaBo, how can i reproduce that bmp_parser bug ?
[21:27:23 CEST] <CoJaBo> michaelni: Instructions and sample files are in the bug https://trac.ffmpeg.org/ticket/5598
[21:28:06 CEST] <CoJaBo> michaelni: Basically, it's only looking for a 16-bit header, so almost any sequence of BMPs longer than "a couple" should trigger it :/
[22:32:33 CEST] <cone-767> ffmpeg 03Michael Niedermayer 07master:d0388bd32e1c: avcodec/bmp_parser: Fix state
[22:37:36 CEST] <cone-767> ffmpeg 03Paul B Mahol 07master:77f9c4b7aa9e: avocdec: add MagicYUV decoder
[23:13:46 CEST] <llogan> ubitux: i want the project to refund you for the server costs. and move the services to FFbulgaria or videolan or wherever is most appropriate (not that I'm volunteering/able to do so atm).
[23:14:54 CEST] <ubitux> no no, don't worry about the refund
[23:15:22 CEST] <ubitux> i'd just be happy if i can just stop paying for it :)
[23:15:37 CEST] <Compn> thought we agreed to use FFbulgaria long ago
[23:15:55 CEST] <Compn> except for kierank who objected to it
[23:16:02 CEST] <Compn> because reasons
[23:18:05 CEST] <llogan> i don't care where it goes. as long as it works and someone capable and trustworthy can admin it.
[23:19:40 CEST] <BBB> Compn: that is so mean
[23:19:57 CEST] <BBB> Compn: kierank has a right to express his opinions even if you disagree with him, without you stabbing him in the back every time it comes up
[23:28:21 CEST] <ubitux> note: i can obviously wait more if the bulgaria plan is not satisfaying enough
[23:28:41 CEST] <ubitux> as long as there is a plan to move somewhere else in progress
[23:28:57 CEST] <ubitux> i'm not giving deadlines, just a complain :)
[23:31:43 CEST] <llogan> it's a valid complaint.
[23:43:39 CEST] <CoJaBo> cool, someone fixed my bug alreAdy? =D
[23:47:58 CEST] <CoJaBo> michaelni: Massive thanks for that; when I can figure out how to get it to actually build, I'll test it on the full input file just to be sure...
[00:00:00 CEST] --- Wed Jun  1 2016