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

[burek]

[00:02:55 CET] <cone-139> ffmpeg 03James Almer 07master:73a4589d4b0d: x86: add some more helper macros to check for slow cpuflags
[00:02:56 CET] <cone-139> ffmpeg 03James Almer 07master:70d685a77f28: x86: use the new helper macros where useful
[00:04:58 CET] <cone-139> ffmpeg 03James Almer 07release/3.0:1e8a75fae479: x86: add some more helper macros to check for slow cpuflags
[00:04:59 CET] <cone-139> ffmpeg 03James Almer 07release/3.0:4d9520793825: x86: use the new helper macros where useful
[00:12:10 CET] <cone-139> ffmpeg 03Metaksakis Georgios 07master:00c73c475e3d: lavd/gdigrab: mouse dpi awareness
[00:20:12 CET] <J_Darnley> What kind of C library API do people here like?  Public option struct?  Option get/set functions?  1 get/1 set function with key-value pairs?  Is there a specific one you find neat?
[00:22:46 CET] <Timothy_Gu> i guess the current norm is option get/set func
[00:22:49 CET] <Timothy_Gu> like AVOption
[00:34:11 CET] <nevcairiel> J_Darnley: i like structs, but they require a rather fixed ABI so its always a balancing act
[00:35:01 CET] <nevcairiel> other than that specific get/set functions probably, generic get/set like AVOption I would only use if there is really a million options to control like in ffmpeg
[00:48:49 CET] <J_Darnley> I might go with a struct for now.
[00:49:06 CET] <J_Darnley> My 1 user thought my original public struct was neat.
[01:28:56 CET] <kierank> Timothy_Gu: added multilib
[01:32:38 CET] <michaelni> Timothy_Gu, btw, looking at fatebeta, i wonder if in addition to the "Last Good Rev" the "First Bad Rev" could be shown too, this could be useful if someone wants to bisect a bug
[01:36:23 CET] <Timothy_Gu> michaelni: indeed it could be added
[01:36:48 CET] <Timothy_Gu> michaelni: but I really want to first migrate to a "proper" database system before such features are added
[01:37:10 CET] <michaelni> sure ... was thinking about it as i wondered what broke: http://fatebeta.ffmpeg.org/report/ppc64be-RHEL7.0-gcc-4.8.2-ibmcrl/20160214060754#failed_tests
[01:37:15 CET] <Timothy_Gu> fate.f.o doesn't use SSD, and parsing CSV is fairly slow
[01:40:27 CET] <Timothy_Gu> kierank: cool, thanks
[01:40:47 CET] <michaelni> Timothy_Gu, btw, do we have backups of fate.f.o ? if not you should probably make backups
[01:41:29 CET] <michaelni> also if we need a box with SSDs we could ask if someone would donate one
[01:41:35 CET] <Timothy_Gu> michaelni: no
[01:41:45 CET] <Timothy_Gu> I don't have 200 GB of free space...
[01:42:11 CET] <Timothy_Gu> which again leads to my wanting to migrate this to a proper database
[01:42:21 CET] <Timothy_Gu> MongoDB has autobackup ("sharding")
[01:42:31 CET] <Timothy_Gu> and is a lot faster
[01:46:37 CET] <michaelni> do we have backups of fate.f.o minus the actual "database/csv" ? that should be alot smaller and is more important too
[01:46:52 CET] <Timothy_Gu> michaelni: no
[01:47:14 CET] <Timothy_Gu> can you do exclusion in rsync?
[01:47:39 CET] <michaelni> i think so
[01:47:41 CET] <jamrial> anothing thing in fate but not fatebeta is a diff of the previous and latest compilation log when there are new warnings
[01:48:03 CET] <michaelni> tar also supports excludes
[01:48:12 CET] <jamrial> the ± link next to the number of warnings
[01:49:57 CET] <Timothy_Gu> I can probably pipe grep warning | diff to this
[02:50:28 CET] <Guest28> Hello I have a question about the use of the private API method "SecIdentityCreate" in http://ffmpeg.org/doxygen/trunk/tls__securetransport_8c_source.html. Is there a reason to keep that and/or an easy way to remove that usage? It prevents ffmpeg from being used in any mac app store app, fwiw.
[03:15:20 CET] <Timothy_Gu> ubitux: is there a good reason to keep the tsan and helgrind FATE station even though it's emitting nothing but useless stuff?
[03:28:14 CET] <cone-059> ffmpeg 03Michael Niedermayer 07release/3.0:bd0497b28bc2: avcodec/cfhd: Temporary disable frame threading until related bugs have been fixed
[03:47:27 CET] <Timothy_Gu> michaelni: does this make sense or no: https://github.com/FFmpeg/FFmpeg/pull/172/files
[03:49:28 CET] <michaelni> maybe, but a testcase would be nice
[03:51:25 CET] <cone-059> ffmpeg 03Michael Niedermayer 07master:295de3efc53e: fate/source-check.sh: Use "git show" instead of git --version to test for git
[03:56:13 CET] <Compn> hmm ydl made a bad mkv file with audio codec "supo" (using old ffmpeg) ... weird.
[03:56:46 CET] <Compn> o thats opus lol
[03:56:50 CET] Action: Compn stupid.
[04:01:59 CET] <cone-059> ffmpeg 03Michael Niedermayer 07release/3.0:c40983a6f631: fate/source-check.sh: Use "git show" instead of git --version to test for git
[04:18:46 CET] <cone-059> ffmpeg 03Michael Niedermayer 07n3.0:HEAD: fate/source-check.sh: Use "git show" instead of git --version to test for git
[05:03:29 CET] <Timothy_Gu> valgrind drd + helgrind + tsan = 1/4 of all FATE data
[05:10:29 CET] <andrewrk> congrats on 3.0
[05:22:56 CET] <rcombs> michaelni: re: dts fix; I'm not sure it's correct, just that it fixes this case
[05:23:28 CET] <rcombs> do library users still need to lock around avcodec_close()?
[08:15:59 CET] <someonesomewhere> i am having issues with ffmpeg-2.8.6.. I am trying to use it for android developement, and my app requires that ffmpeg should not exit.  However, if i make changes to exit_program function in cmdutils.c to not exit,  I see that the stack is getting corrupted (as a result, of which, I get a SIGSEGV later on because the return from that function is n
[08:15:59 CET] <someonesomewhere> ot proper).. This seems like a bug to me (I've been able to reproduce it on standalone ffmpeg running on mac osx 10.10  also)
[08:16:47 CET] <someonesomewhere> and i know things worked ok with 2.2.15 .. so somewhere things have changed which cause this behavior
[08:18:00 CET] <someonesomewhere> to reproduce it, just ensure that you don't exit in exit_program, and then rename main in ffmpeg.c to main2 or something like that, and then call that function twice.. and you'll see what I am talking about
[08:44:56 CET] <wm4> it wasn't designed for this, so you'll have to go through a lot to change this behavior (and there's no bug)
[08:48:07 CET] <JEEB> for requirements like that using the api sounds like a much better proposition
[09:50:32 CET] <nevcairiel> Timothy_Gu: the dca decoder requires the parser to be used to split frames appropriately, therefor the patch is not correct and the user should use the parser isntead
[09:52:24 CET] <nevcairiel> (its also against the old decoder)
[12:02:05 CET] <someonesomewhere> can someone elaborate on wm4's answer earlier:  why can't i use ffmpeg as a reentrant library -   I am trying to use it for android developement, and my app requires that ffmpeg should not exit.  However, if i make changes to exit_program function in cmdutils.c to not exit,  I see that the stack is getting corrupted (as a result, of which, I get a 
[12:02:05 CET] <someonesomewhere> SIGSEGV later on because the return from that function is not proper).. This seems like a bug to me (I've been able to reproduce it on standalone ffmpeg running on mac osx 10.10  also)
[12:03:52 CET] <BtbN> Well, it's a bug you made by modifiying some function
[12:04:05 CET] <BtbN> ffmpeg.c is not a librariey either
[12:06:20 CET] <nevcairiel> indeed, its not designed to function as a library, and if you modify it to  be one, any bugs caused by that are also caused by you
[12:07:37 CET] <wm4> <BtbN> ffmpeg.c is not a librariey either
[12:07:38 CET] <wm4> this
[12:08:26 CET] <wm4> and as far as I'm aware, even the broken POS known as android can start processes?
[12:08:43 CET] <wm4> or is that some nonsense security BS (that doesn't actually make anything secure)?
[12:09:12 CET] <nevcairiel> probably, just like breaking x86 asm on android for no good reason
[12:09:16 CET] <someonesomewhere> i shouldn't have used the word library..
[12:09:25 CET] <someonesomewhere> and lets also take android out of the picture
[12:09:30 CET] <someonesomewhere> to reproduce it, just ensure that you don't exit in exit_program, and then rename main in ffmpeg.c to main2 or something like that, and then call that function twice.. and you'll see what I am talking about
[12:09:42 CET] <wm4> it's not supposed to be called twice?
[12:09:42 CET] <someonesomewhere> on any platform.. on mac os x or linux
[12:09:45 CET] <nevcairiel> if you modify ffmpeg.c, and it bugs out afterwards, then you caused the bug
[12:09:51 CET] <BtbN> "change something in an entirely unsupported way, and it breaks" what a surprise
[12:10:04 CET] <BtbN> of course main is not re-entrant
[12:10:11 CET] <BtbN> it's only called exactly once
[12:10:27 CET] <someonesomewhere> well.. the only change i've made is that i don't exit from the program in exit_program.. and instead return from it
[12:10:36 CET] <BtbN> exactly, so?
[12:10:39 CET] <wm4> uh
[12:10:40 CET] <wm4> read what we wrote
[12:10:42 CET] <nevcairiel> our libraries are thread safe and reentrant, the ffmpeg.c application is not
[12:10:54 CET] <nevcairiel> you cannot use it in such a way
[12:12:03 CET] <nevcairiel> I know that other people have tried before to make ffmpeg.c or ffplay.c into a re-usable library of sorts, but its just not going to be easy, and definitely not supported by us
[12:12:36 CET] <BtbN> It's probably easier to write a library that runs the ffmpeg application as an external process
[12:12:44 CET] <someonesomewhere> but doesn't it mean that parts of ffmpeg.c (or cmdutils.c) is overwriting over parts of memory it shouldn't
[12:12:50 CET] <BtbN> no
[12:12:52 CET] <wm4> it would be great to have such a library, but just modifying ffmpeg.c slightly isn't going to do this
[12:13:12 CET] <nevcairiel> if you call main twice, who knows what happens
[12:13:16 CET] <BtbN> it just means that some code isn't meant to be run more than once
[12:13:18 CET] <nevcairiel> since its not designed to be called twice
[12:13:42 CET] <someonesomewhere> i haven't even got to the point where it is being called twice..
[12:14:00 CET] <nevcairiel> its also not meant to continue executing after the point where it usually exits
[12:14:17 CET] <someonesomewhere> if you don't exit the program in exit_program, and just return.. the program just returns to some random address.. (even before calling main function again)
[12:14:17 CET] <nevcairiel> in any case: you are on your own
[12:14:37 CET] <someonesomewhere> it doesn't return from exit_program in a secure manner.. it returns to some random address
[12:14:45 CET] <wm4> someonesomewhere: exit never returns
[12:14:52 CET] <BtbN> it doesn't return from exit_program at all, you made it do that
[12:14:52 CET] <nevcairiel> its not meant to ever return from that function
[12:15:01 CET] <nevcairiel> its supposed to quit
[12:15:17 CET] <someonesomewhere> and it can never be made to return from that function instead of quitting the program
[12:15:18 CET] <someonesomewhere> ?
[12:15:29 CET] <wm4> sure you can make it, good luck have fun
[12:15:34 CET] <wm4> it wasn't written or intended to do so
[12:15:35 CET] <nevcairiel> maybe it can, but it will be complicated
[12:15:40 CET] <BtbN> do what you want, but don't complain here about bugs you introduced
[12:15:43 CET] <wm4> so you're on your own introducing bugs and fixing them
[12:16:33 CET] <nevcairiel> the control flow assumes that it will stop executing entirely when those functions are called
[12:16:56 CET] <nevcairiel> to make it gracefully return from that function, you would need to write entirely new cleanup routines
[12:18:16 CET] <someonesomewhere> cleanup is one thing (which will involve resetting values of some variables, setting some objects to null, freeing up memory etc).. but the usual expectation is that it should return to the callee  ... and it doesn't.. and i don't know which cleanup routine can make its return "normal"
[12:18:36 CET] <jkqxz> exit_program() is marked with the noreturn attribute.
[12:18:51 CET] <jkqxz> So the compiler is free to assume it doesn't return, hence it just crashes if you ever try to do that.
[12:19:18 CET] <jkqxz> If you remove that attribute, it will return to the callee (and then die in some other horrible way instead).
[12:22:03 CET] <someonesomewhere> thanks  jkqxz  - that ifnormation helps - so if i just remove av_noreturn from cmdutils.h, it will at least start returning to the callee ?
[12:22:25 CET] <BtbN> and then explode because that code doesn't expect that function to ever return
[12:22:38 CET] <jkqxz> If you really want to persist in this likely-fruitless endeavour, you will be much better off jumping out of exit_program() with longjmp() to somewhere in your code.  That doesn't solve resetting memory back to the initial state, so it will likely still crash when you call main() a second time.
[12:23:19 CET] <jkqxz> s/much better off/very slightly less disastrously off/
[12:24:04 CET] <someonesomewhere> allrite, thanks everyone for the warnings, and inputs !!
[12:42:41 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:ccb94789e296: hevc: support Main10 decoding through dxva2
[12:42:42 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:1ec14612a5bd: ffmpeg_dxva2: support hevc main10 decoding
[12:42:43 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:a655bc834479: ffmpeg_dxva2: add a profile check for hevc
[12:44:45 CET] <wm4> nice
[12:46:45 CET] <nevcairiel> now it wont break any distros for another half year or so =p
[12:47:07 CET] <nevcairiel> i even bumped and changelog'ed it!
[12:48:02 CET] <atomnuker> anyone read the latest coverity dump?
[12:48:18 CET] <atomnuker> the dirac decoder has a bunch of avpriv_mirror() calls using negative parameters
[12:48:20 CET] <nevcairiel> i had a brief look but not indepth
[12:48:38 CET] <atomnuker> but coverity seems to think the function should not be able to take negative arguments
[12:48:47 CET] <atomnuker> I think it's a false warning though
[12:48:58 CET] <wm4> the code casts a negative int to unsigned
[12:49:00 CET] <nevcairiel> those are common enough with static analysis
[12:49:02 CET] <wm4> make of that what you want
[12:50:31 CET] <nevcairiel> i can never remember, was signed -> unsigned cast strictly specified in the spec?
[12:52:43 CET] <wm4> isn't it implementation dependent?
[12:52:51 CET] <nevcairiel> probably should be since using -1 to init an unsigned to max is used all over the place
[12:53:24 CET] <wm4> that's different
[12:53:44 CET] <wm4> (unsigned)-1 is fully defined
[12:54:03 CET] <nevcairiel> but (unsigned)-2 isnt?
[12:54:30 CET] <wm4> *shrug*
[12:54:53 CET] <nevcairiel> speaking of such weird things, did ganesh vanish
[12:54:54 CET] <jkqxz> Signed to unsigned is completely defined to do the Right Thing.  Too-large unsigned to signed is nasal demons.
[12:55:32 CET] <wm4> this is signed to unsigned anyway
[12:57:46 CET] <durandal_1707> nevcairiel: is missing ganesh patches
[13:14:08 CET] <cone-435> ffmpeg 03Rostislav Pehlivanov 07master:7cdea450c67d: vc2enc: fix use of uninitialized variables in the rate control system
[13:22:47 CET] <cone-435> ffmpeg 03KO Myung-Hun 07master:346ec917646c: MAINTAINERS: add myself as an OS/2 maintainer
[13:23:42 CET] <atomnuker> whoa, OS/2
[13:23:56 CET] <durandal_1707> what the shit
[13:26:17 CET] <durandal_1707> the bounty for vf_pad seems no longer active :(
[13:30:08 CET] <J_Darnley> what the heck is this "build failed" message?
[13:30:13 CET] <J_Darnley> and why do I care?
[13:30:44 CET] <J_Darnley> nice reply kierank
[13:30:55 CET] <atomnuker> someone's internal CI system went haywire?
[13:34:56 CET] <nevcairiel> probably mailed everyone with a commit in the history
[13:35:00 CET] <nevcairiel> nice job, random guy =p
[13:35:52 CET] <J_Darnley> Perhaps the software is a little better and only emailed everyone with a commit since the last good build.
[13:36:14 CET] <nevcairiel> judging from the list, thats still a lot of people
[13:36:46 CET] <J_Darnley> Maybe it should learn what a mailing list is (so it can be rejected for being too large)
[13:38:36 CET] <BtbN> That's some jenkins plugin that shouts at people who broke the build.
[13:38:41 CET] <wm4> it sent the mail to each committer, not a ML
[13:39:01 CET] <durandal_1707> I think getting rid of drawutils for vf_pad is best approach
[13:39:12 CET] <wm4> so if you argue it should use (private) MLs, that jenkings plugin is broken by design
[13:40:25 CET] <nevcairiel> we used that plugin back at my old job, it can be useful if it builds often enough so the number of p eople is limited
[13:40:42 CET] <nevcairiel> but of course one shouldnt make it run over some huge repository that you have no control over =p
[13:44:19 CET] <durandal_1707> michaelni: is it ok to increase AV_OPT_TYPE_COLOR to 8?
[13:45:21 CET] <durandal_1707> currenttly its only useful for 8bit per component colors
[13:45:49 CET] <nevcairiel> sounds like a breaking change
[13:46:59 CET] <durandal_1707> yes it is
[13:47:29 CET] <michaelni> sounds like it would need AV_OPT_TYPE_COLOR64 
[13:59:00 CET] <ubitux> https://news.ycombinator.com/item?id=11103016
[13:59:03 CET] <ubitux> first comment ^
[13:59:16 CET] <ubitux> btw, we didn't even mention the abi/api bump?
[14:00:22 CET] <ubitux> about the new aac enc, was it in 2.9?
[14:00:35 CET] <ubitux> i mean, that's some quite important changes
[14:00:45 CET] <nevcairiel> 2.8, and no
[14:01:07 CET] <ubitux> would be nice to spend a few minutes to 1 hour to write a proper release note before releasing :/
[14:01:34 CET] <ubitux> we're releasing a major version like it's nothing
[14:02:10 CET] <nevcairiel> because it isnt, its an arbitrary commit from master, its not like we did a feature freeze or anything
[14:02:25 CET] <J_Darnley> Did michael actually make the release?  Last I saw it was just a branch
[14:02:35 CET] <ubitux> http://phoronix.com/scan.php?page=news_item&px=FFmpeg-3.0-Released
[14:02:37 CET] <nevcairiel> was tagged as well by now
[14:02:43 CET] <ubitux> "Supports VP9 VA-API Acceleration"
[14:02:48 CET] <ubitux> as if it was the most important thing
[14:03:01 CET] <wm4> <ubitux> "Supports VP9 VA-API Acceleration" <- that's in already?
[14:03:04 CET] <ubitux> i mean, api/abi break is a major thing, a good native aac encoder too, ...
[14:03:08 CET] <nevcairiel> wm4: yes
[14:03:28 CET] <nevcairiel> ubitux: i would find abi/api changes implied by a new major =p
[14:03:49 CET] <ubitux> it's probably worth mentioning anyway
[14:03:57 CET] <ubitux> it's kind of important
[14:04:11 CET] <ubitux> anyway...
[14:07:20 CET] <michaelni> anyone wants to write a news entry for the 3.0 release for ffmpeg.org ?
[14:19:37 CET] <thardin> is it possible to make it so I only get coverity mail about things I maintain?
[14:29:23 CET] <BBB> is there a reason AVFMT_VARIABLE_FPS is not set for movenc.c?
[14:31:35 CET] <durandal_1707> it doesn't supports it?
[14:32:06 CET] <durandal_1707> is it ok to add uint64 to AVOption union?
[14:32:07 CET] <BBB> mov has per-packet timestamps, no?
[14:34:02 CET] <rcombs> do library users still need to lock around avcodec_close()?
[14:34:37 CET] <rcombs> also avcodec_open2()
[14:35:19 CET] <BBB> I thought it did that for you
[14:36:06 CET] <nevcairiel> rcombs: yes
[14:36:16 CET] <nevcairiel> well or specifically, you need to provide a lock manager
[14:36:30 CET] <nevcairiel> i think ffmpeg has a default implementation built-in these days though
[14:36:40 CET] <nevcairiel> so just verify its actually active in your environment
[14:36:51 CET] <rcombs> that sounds like "no" then
[14:36:57 CET] <rcombs> is this documented
[14:41:34 CET] <nevcairiel> someone once started to think about making all init thread safe
[14:41:37 CET] <nevcairiel> but Daemon404 got lazy
[14:41:46 CET] <wm4> rcombs: no and no
[14:41:51 CET] <rcombs> that sounds like a good idea
[14:42:09 CET] <wm4> there are also various other bits with questionable thread-safety
[14:45:41 CET] <nevcairiel> i havent had reports of such issues for a while now, and some people use my stuff in parallel apparently
[14:46:11 CET] <atomnuker> michaelni: is it alright for avpriv_mirror() to be called with negative arguments
[14:46:25 CET] <atomnuker> I noticed the snow_dwt also uses it with negative args
[14:46:57 CET] <michaelni> i saw no problem with negative args for x, width must be >= 0 or something of course
[14:47:38 CET] <michaelni> but just because i saw no problem of course doesnt mean that there is "guranteed" to be no problem, i could miss something ...
[14:51:00 CET] <atomnuker> well, I'm asking because coverity seems to think x shouldn't accept negatives
[14:52:26 CET] <michaelni> 50% of what coverity thinks is wrong
[14:52:56 CET] <michaelni> which is actually quite good as that also means 50% is right and leads to bug fixes
[14:53:59 CET] <atomnuker> ok
[14:55:14 CET] <BBB> kierank: I see single-threaded issues in that file you sent me
[14:55:41 CET] <kierank> oh
[14:55:48 CET] <kierank> I could only get it to crash in multithread mode
[14:56:13 CET] <BBB> ==13378== Invalid write of size 2
[14:57:07 CET] <BBB> Im gonna guess this is in the chroma plane when it switches between gbrp12 and yuv422p10
[14:57:23 CET] <BBB> ==13378==  Address 0x10eab318e is 353,326 bytes inside a block of size 353,327 alloc'd
[14:57:44 CET] <BBB> linesize[1] = 736, height=480, so alloc size is correct
[14:58:17 CET] <kierank> oh I guess I need to store the old pixel format as well
[14:58:27 CET] <BBB> might relate to the crash with MT also
[14:58:47 CET] <nevcairiel> isnt this an intra format?
[14:58:54 CET] <BBB> nevcairiel: buffer realloc
[14:59:05 CET] <nevcairiel> shares buffers over threads?
[14:59:14 CET] <BBB> no, but buffers need realloc on pixfmt/size chage
[14:59:25 CET] <BBB> so you need to know the pixfmt/size of the previous frame _in this thread_
[14:59:32 CET] <nevcairiel> sure, but threading shouldnt be hard on intra formats
[14:59:32 CET] <atomnuker> michaelni: I'm marking CID1352548 CID1352547 CID1352546 CID1352545 CID1352544 CID1352543 as ignore in coverity then
[14:59:34 CET] <BBB> (as opposed to avctx->, which is of the previous thread)
[14:59:40 CET] <nevcairiel> ah y eah
[14:59:48 CET] <BBB> so you need to store all these variables locally
[14:59:48 CET] <nevcairiel> you need to know what format your buffers are allocated for
[14:59:49 CET] <michaelni> atomnuker, sure
[14:59:56 CET] <BBB> its not hard, just slightly illogical
[15:00:10 CET] <BBB> its easy to do it wrong, lets say it like that
[15:00:17 CET] <BBB> (I made the same mistake in ffvp9 also, FWIW)
[15:00:44 CET] <nevcairiel> vp9 is inter, so thats even worse =p
[15:02:05 CET] <BBB> & I guess thats one way to look at it :-p
[15:11:53 CET] <Daemon404> [13:41] <@nevcairiel> but Daemon404 got lazy
[15:11:57 CET] <Daemon404> i have a WIP branch
[15:12:03 CET] <Daemon404> its super tedious to mark all codecs properly
[15:12:05 CET] <Daemon404> and boring.
[15:12:09 CET] <Daemon404> i dunno how elenril does it
[15:12:43 CET] <BBB> he probably sits down and just does it
[15:12:44 CET] <Daemon404> https://github.com/dwbuiten/FFmpeg/commit/3d2fc03955348f49f2a6b67a66cc038d19ba62b1
[15:12:49 CET] <BBB> how else do you think people get boring stuff done
[15:13:52 CET] <nevcairiel> divide and conquer, just set yourself incremental goals and reach them =p
[15:14:48 CET] <Daemon404> nevcairiel, would be easier if i could push them
[15:14:49 CET] <michaelni> Timothy_Gu, theres no v3.0 on http://fatebeta.ffmpeg.org/ 
[15:14:54 CET] <Daemon404> instead of rebasing for X weeks
[15:14:57 CET] <Daemon404> until theyre all done
[15:15:14 CET] <nevcairiel> there is no reason you couldnt push the flag additions
[15:15:37 CET] <Daemon404> at libav there is
[15:15:42 CET] <BBB> procrastrination&
[15:15:47 CET] <nevcairiel> i th ought we stopped caring about them
[15:16:35 CET] <nevcairiel> in any case this kind of change shouldnt conflict often so its probably not that terrible
[15:22:01 CET] <wm4> Daemon404: what speaks against pushing that commit
[15:22:12 CET] <wm4> just add the word "some" to the message
[15:27:47 CET] <Daemon404> wm4, i feared the diego
[15:27:51 CET] <Daemon404> ill submit it today
[15:28:08 CET] <nevcairiel> was so nice and quiet while he was gone for months
[15:28:16 CET] <BBB> iive: I guess my question for that patch is: what would you use it for that you cannot do today"
[15:29:21 CET] <BBB> what does diego have to do with patches?
[15:29:27 CET] <Daemon404> ... lmao
[15:29:28 CET] <Daemon404> [libutvideo] Is FFMPeg the new home for libutvideo? (#10)
[15:29:29 CET] <BBB> hell tell you to add/remove/change spaces
[15:29:36 CET] <Daemon404> BBB, "while youre at it..."
[15:29:45 CET] <BBB> tell him to send a patch
[15:29:49 CET] <BBB> problem_solved
[15:31:15 CET] <iive> BBB: print hwaccel capability in the info screen.
[15:31:36 CET] <BBB> which info screen?
[15:32:55 CET] <nevcairiel> the way I see those flags, if they are not required for behavior, they are not required. info-only flags seem rather pointless
[15:33:41 CET] <Daemon404> lmao kierank 
[15:33:42 CET] <iive> cmdutils.c::print_codec()
[15:33:47 CET] <Daemon404> i thought you were a nigerian prince at first
[15:33:53 CET] <nevcairiel> haha
[15:34:02 CET] <kierank> he played on with the joke as well
[15:34:06 CET] <kierank> in his reply
[15:34:18 CET] <nevcairiel> should have send him in invoice
[15:34:19 CET] <Daemon404> i got no reply
[15:34:30 CET] <kierank> yeah he only replied to me
[15:34:30 CET] <nevcairiel> s/ in / an /
[15:34:46 CET] <kierank> PS. I am sorry to say, but for your request of payment to be accepted you must have an agreement signed with Cyfrowy Polsat. That is not something impossible, but you must be ready to withstand very long and carefully crafted recruitment process. If I might be of any assistance in that, just let me know.
[15:35:09 CET] <Daemon404> ... i dont think that is a joke
[15:35:12 CET] <Daemon404> sadly.
[15:36:52 CET] <wm4> what am I missing out?
[15:37:13 CET] <Daemon404> you got the email too.
[15:37:23 CET] <Daemon404> Build failed in Jenkins: live-build-ffmpeg #23
[15:37:24 CET] <Daemon404> Build failed in Jenkins: live-build-ffmpeg #31
[15:45:19 CET] <BBB> I
[15:45:23 CET] <BBB> Im not getting the follow-ups
[15:45:31 CET] <BBB> so clearly Ive been erased from a long CC list, thankfully
[15:45:35 CET] <BBB> or my spam filter is working
[15:46:53 CET] <kierank> ubitux: something is up with https on ffmpeg.org
[15:47:16 CET] <nevcairiel> i would say something is down instead
[15:47:18 CET] <kierank> Resolving ffmpeg.org (ffmpeg.org)... 178.63.43.86
[15:47:18 CET] <kierank> Connecting to ffmpeg.org (ffmpeg.org)|178.63.43.86|:443...
[15:47:56 CET] <ubitux> i'm not really doing any admin on this
[15:48:00 CET] <ubitux> just paying for the server :p
[15:48:39 CET] <J_Darnley> BBB: think the OP sensibly didn't hit reply all
[15:49:43 CET] Action: kierank did
[15:49:45 CET] <kierank> as a troll
[15:50:06 CET] <J_Darnley> Yes, I didn't object to that.
[15:58:52 CET] <BBB> it was a proper troll
[15:59:05 CET] <BBB> so kierank, do you have a patch for the format change issue?
[15:59:05 CET] <Timothy_Gu> nevcairiel: ok
[15:59:17 CET] <kierank> BBB: will have to look at that at home
[15:59:24 CET] <BBB> hm...
[15:59:33 CET] <BBB> I can just try backing up format, I guess?
[15:59:50 CET] <kierank> yes but bear in mind I set format at the beginning
[15:59:56 CET] <kierank> because there were some samples without a format tag
[16:00:02 CET] <kierank> but appeared to be yuv422p10
[16:04:44 CET] <BBB> ok
[16:05:23 CET] <Timothy_Gu> michaelni: now there is
[16:06:52 CET] <michaelni> thx
[16:07:40 CET] <BBB> any valid cfhd samples?
[16:07:43 CET] <BBB> maybe a fate test?
[16:07:46 CET] <BBB> to test I didnt break stuff
[16:08:06 CET] <BBB> I get no valgrind issues after I fix the format issue, w/ as well as w/o threading
[16:08:20 CET] <Timothy_Gu> michaelni: the fate-recv.sh script is still the old one, so stuff like autoadding branch isn't working
[16:09:20 CET] <BBB> iive: now, coming back to that info flag& its not that Im against it, Im just not sure what the point is
[16:10:05 CET] <BBB> iive: since the flag is just an ifo bit, were doomed to forget to update it everywhere and always, so if its app specific, it could just as well live in the app and lag in uptodateness also
[16:10:56 CET] <BBB> iive: e.g. we dont have flags for this codec could output rgb and/or yuv, even though thats a valid thing to wonder in the app&
[16:11:31 CET] <BBB> iive: we also dont signal whether codecs are HD optimized or not, or whether the implementation of the audio decoder is float or int
[16:11:38 CET] <BBB> all very valid things to signal as an info bit
[16:12:03 CET] <iive> then remove all cap flags
[16:12:31 CET] <BBB> maybe we should, yes
[16:12:44 CET] <BBB> I can only wonder about the amount of flames/trolls that will invoke
[16:14:26 CET] <iive> tbh, I didn't expect the amount of controversy this small issue has caused.
[16:15:21 CET] <nevcairiel> most of the flags actually are required for some kind of behavior, ie. threading causes the generic code to behave differently
[16:17:43 CET] <BBB> iive: I can help you implement a small piece of codec that decides for each AVCodec whether it has accompanying ACHWAccel implementations
[16:17:48 CET] <BBB> iive: would that be useful?
[16:17:51 CET] <BBB> (to replace this flag)
[16:18:53 CET] <iive> codec/code ...
[16:19:15 CET] <BBB> hehe :)
[16:19:16 CET] <BBB> oops
[16:19:21 CET] <iive> ;)
[16:20:23 CET] <iive> BBB:  how would that code work?
[16:21:29 CET] <BBB> similar to find_hwaccel() in libavcodec/utils.c
[16:22:17 CET] <nevcairiel> that would probably be more useful information as well, knowing that a codec could do hwaccel on some system doesnt really help you, while checking for an actual hwaccel tells you if it can do hwaccel right here and now
[16:22:45 CET] <BBB> and then for pix_fmt, you can add any pix_fmt that you like (AV_PIX_FMT_VAAPI, DXVA2_VLD, D3D11VA_VLD, etc.
[16:24:15 CET] <iive> this actually does make sense
[16:24:59 CET] <iive> just have one thing in mind... the code would be bigger than 1 bit :)
[16:33:22 CET] <BBB> iive: yeah, I know, its not 1 bit& but & its info screen code, not performance-sensitive in the innermost loop of block decoding
[16:33:23 CET] <BBB> so thats ok
[16:33:34 CET] <BBB> kierank: do you have a fate test or test sample or so?
[16:33:38 CET] <BBB> kierank: to confirm I didnt break it
[16:33:40 CET] <kierank> yes but at home
[16:33:45 CET] <kierank> If you post a patch I will test tonight
[16:35:12 CET] <jamrial> atomnuker: backport that vc2enc commit to 3.0, preferably using "git cherrypick -x"
[16:35:21 CET] <BBB> kierank: posted to ML
[16:35:29 CET] <kierank> thanks
[16:35:33 CET] <BBB> kierank: its completely untested with real samples, so be careful :-p
[16:37:04 CET] <Timothy_Gu> BBB: your printfs are still in there :)
[16:37:27 CET] <BBB> oops
[16:37:29 CET] <BBB> anyway
[16:37:42 CET] <cone-435> ffmpeg 03Rostislav Pehlivanov 07release/3.0:0aa2fbddb190: vc2enc: fix use of uninitialized variables in the rate control system
[16:37:51 CET] <atomnuker> jamrial: done
[16:38:08 CET] <jamrial> thanks
[16:39:30 CET] <BBB> Timothy_Gu: fixed
[16:40:39 CET] <Timothy_Gu> thx
[16:52:41 CET] <ubitux> http://b.pkh.me/testsrc2-nv12-bgra-aarch64.jpg ready for upstream!
[16:53:07 CET] <ubitux> Timothy_Gu: idk about drd/helgrind/tsan; i think there are issues to fix
[16:56:48 CET] <BBB> ubitux: what is that
[16:57:07 CET] <ubitux> testsrc2 :(
[16:57:31 CET] <ubitux> after a nv12 ’ bgra in aarch64 :p
[16:57:42 CET] <jamrial> aarch64 specific asm?
[16:57:45 CET] <ubitux> yeah
[16:58:00 CET] <ubitux> i'm porting arm/yuv2rgb_neon.S to aarch64
[16:58:32 CET] <jamrial> awesome, we're lacking in the aarch64 asm coders department :p
[16:59:01 CET] <ubitux> i just need a debugger now :(
[17:01:22 CET] <rcombs> isn't it extremely similar to regular arm
[17:01:57 CET] <ubitux> no, actually really different
[17:02:16 CET] <rcombs> lacks some conditional execution, register allocations are different&
[17:02:29 CET] <rcombs> no thumb?
[17:03:02 CET] <ubitux> the most annoying part is that you can't play anymore with high/low part of a simd reg
[17:03:12 CET] <ubitux> at least as easily as regular arm
[17:03:19 CET] <rcombs> oh :/
[17:03:35 CET] <Timothy_Gu> ubitux: unless the avg. 700 failed tests are all issues to fix I don't really see how you could find the importatn parts
[17:03:53 CET] <ubitux> Timothy_Gu: it's a remainder to fix the noise :)
[17:04:02 CET] <ubitux> reminder*
[17:04:04 CET] <Timothy_Gu> ah :)
[17:04:23 CET] <Timothy_Gu> how would you go about doing that though?
[17:04:55 CET] <ubitux> check every issue one by one
[17:05:10 CET] <BBB> aarch64
[17:05:13 CET] <BBB> what is that again?
[17:05:15 CET] <BBB> is that arm64?
[17:05:19 CET] <rcombs> yup
[17:05:26 CET] <BBB> aha, yes, thats important
[17:05:37 CET] <BBB> although Im not sure why anyone would care about testsrc2 on arm
[17:05:41 CET] <BBB> but that may just be me
[17:05:46 CET] <ubitux> it's just for testing :p
[17:05:51 CET] <BBB> ok
[17:05:59 CET] <ubitux> yuv/nvx ’ rgb flavor are kinda useful
[17:06:04 CET] <BBB> agreed
[17:06:17 CET] <ubitux> but damn i hate the arm doc so much
[17:06:19 CET] <BBB> I thought it was testsrc2-specific, but I misread, youre essentially doing arm64 at swscale
[17:06:26 CET] <BBB> so thats super-cool
[17:06:28 CET] <ubitux> these guys should read the intel doc one day
[17:06:30 CET] <jamrial> where is the tsan slot? i can't find it
[17:06:40 CET] <BBB> can you make ffvp9 run on arm/arm64?
[17:07:39 CET] <Timothy_Gu> jamrial: it's broken
[17:07:42 CET] <Timothy_Gu> http://fatebeta.ffmpeg.org/log/x86_64-archlinux-gcc-tsan/20160215060601/configure
[17:08:15 CET] <ubitux> yeah there is a bug on this one
[17:08:34 CET] <ubitux> i don't feel like looking much more into it
[17:09:13 CET] <ubitux> BBB: maybe one day, i think there are more important thing to actually port first
[17:09:25 CET] <ubitux> i'm also waiting for my arm64 board to come...
[17:09:38 CET] <ubitux> qemu-aarch64 is fine for testing, but not so much for benchmark
[17:10:23 CET] <Timothy_Gu> 15812 www-data  20   0 3649m 3.5g 2184 S    1 45.4   0:14.39 report.cgi
[17:10:37 CET] <Timothy_Gu> mem=45.1%
[17:11:04 CET] <Timothy_Gu> yeah somebody's looking at the drd/helgrind report
[17:11:46 CET] <Daemon404> ... cgi?
[17:11:51 CET] <Daemon404> is this old fate
[17:12:06 CET] <Timothy_Gu> yes
[17:12:52 CET] <Daemon404> yikes
[17:13:26 CET] <Timothy_Gu> damn i can't even kill that process
[17:32:35 CET] <BBB> ubitux: is it hard to learn? maybe i should aarch64...
[17:32:38 CET] <BBB> learn*
[17:33:07 CET] <ubitux> well the official doc is shit, so you'll probably have to wander on random slideshow and blogs
[17:33:35 CET] <BBB> hm...
[17:34:01 CET] <ubitux> the most annoying part to have hw and toolchain anyway :p
[17:34:32 CET] <ubitux> the pine64 and a 64b odroid are going out around march iirc
[17:35:03 CET] <mateo`> BBB: i'm wondering, are there optimisations to be done in ffvp9 on armv7 ?
[17:35:07 CET] <ubitux> if you can't wait, there is the hikey and the poop devices from apple
[17:35:18 CET] <ubitux> mateo`: all of them
[17:35:36 CET] <ubitux> mc, lpf, dct, ...
[17:35:39 CET] <andrey_utkin> Hi, I'm interested in subtleties with H.264 Annex B vs AVCC. Willing to pay for good consulting with explanations why things work. The question is related to joining video clips of different origin. Joining AnnexB (mpegts) files work and with AVCC (MP4 container) it doesn't which I assume is legit. But if you convert this joined file to MP4, it still works. I wonder why.
[17:35:47 CET] <mateo`> I should probably give it a try then
[18:00:22 CET] <BBB> mateo`: you mean the scalar non-neon type?
[18:00:26 CET] <BBB> mateo`: or you mean neon?
[18:00:31 CET] <BBB> I guess scalar is armv6
[18:00:43 CET] <BBB> mateo`: for neon, yes, tons. like, its non-existant right now
[18:01:40 CET] <mateo`> i mean neon
[18:02:19 CET] <BBB> mateo`: basically all simd needs implementing for neon (mc, itxfm/loopfilter, intra pred; in that order)
[18:05:47 CET] <jamrial> i found it pretty cool how imgtec wrote complete simd coverage for ffvp9 8bit on mips
[18:11:34 CET] <Timothy_Gu> michaelni: I started backing up fate (just the outcome, without the full report)
[18:12:07 CET] <michaelni> Timothy_Gu, ok, great, thx
[19:08:23 CET] <Daemon404> mediacodec is quite an insane amount of code...
[19:09:03 CET] <nevcairiel> its like 3000 LoC without the JNI utility code, that is insane indeed
[19:09:13 CET] <Daemon404> yes
[19:09:17 CET] <Daemon404> i wasnt including the jni wrapper
[19:09:52 CET] <nevcairiel> fucking android people, cant they just use java to access their media
[19:09:59 CET] <nevcairiel> why does it need to go through avcodec anyway
[19:10:17 CET] <Daemon404> im sure there's A Reason
[19:10:52 CET] <Daemon404> same could be said for iOS
[19:10:57 CET] <Daemon404> of really any hwaccel
[19:11:02 CET] <Daemon404> or*
[19:11:24 CET] <nevcairiel> well some APIs are at least simple and straight forward to use
[19:11:38 CET] <nevcairiel> but MediaCodec becomes 100x more complicated when using it through  JNI
[19:11:42 CET] <nevcairiel> or at least I hope so
[19:11:52 CET] <nevcairiel> a native java version wouldnt be this terrible, would it
[19:11:58 CET] <Daemon404> none of the hwaccel stuff i see in avcodec is "simple"
[19:12:34 CET] <nevcairiel> the "classic" hwaccels like dxva, vaapi and vdpau require a decoder to hook into, so using them without at least parts of an actual decoder would be insanely hard
[19:12:42 CET] <nevcairiel> because they are slice decoders
[19:12:46 CET] <nevcairiel> not bitstream parsers
[19:14:15 CET] <mateo`> nevcairiel: we use lavc/lavf as a cross platform backend for audio/video
[19:14:40 CET] <nevcairiel> maybe you shouldnt =p
[19:18:54 CET] <mateo`> i'm dealing with native code, i could have do the same "shit" outside ffmpeg but I decided otherwise so other can benefit this work.
[19:20:49 CET] <cone-435> ffmpeg 03Timothy Gu 07master:5d823709301b: RELEASE: Update to 3.0.git
[19:22:09 CET] <Daemon404> java calling c calling java :3
[19:22:17 CET] <Daemon404> i think i forgot an extra 'c' there
[19:23:56 CET] <mateo`> Daemon404: it's even better than that "java calling avcodec calling java calling libstagefright calling omx calling avcodec"
[19:24:42 CET] <mateo`> in case the implementation behind the codec is a software one.
[19:37:06 CET] <Daemon404> mateo`, sounds like quite a lot of overhead for a mobile platform
[19:40:44 CET] <rcombs> don't forget all the awkward IPC in there
[19:46:46 CET] <nevcairiel> speaking of awkward public API, those quicksync people also disappeared, didnt they
[19:47:03 CET] <nevcairiel> someone had the theory that they had a deadline to get it all done and would otherwise lose the contract from Intel
[19:49:48 CET] <durandal_1707> contract for what?
[19:50:04 CET] <rcombs> which quicksync people?
[19:56:14 CET] <nevcairiel> those trying to push a QS vpp filter and other various weird stuff
[19:56:26 CET] <nevcairiel> also those responsible for thorougly breaking our QS decoder
[20:16:42 CET] <durandal_1707> anyone want to comment on fieldhint filter?
[20:45:22 CET] <Timothy_Gu> durandal_1707: how do you use it?
[20:48:15 CET] <durandal_1707> write file with line numbers from which frame pick which field
[20:48:59 CET] <durandal_1707> inverse telecine pattern
[20:49:49 CET] <durandal_1707> similar to avs and vs plugins
[20:50:13 CET] <durandal_1707> very old one though
[20:50:44 CET] <durandal_1707> to be used where fieldmatch fails
[21:18:44 CET] <BBB> I think its totally fine to commit weird filters that nobody else udnerstands
[21:18:45 CET] <BBB> I mean
[21:18:50 CET] <BBB> I dont understan any of that
[21:53:57 CET] <jamrial> seeing how ubuntu has feature freeze three days from now i wondering how likely is 3.0 to get in
[21:54:03 CET] <jamrial> it's not even in debian yet
[21:54:49 CET] <nevcairiel> and probably wont be because vlcs latest release is nearly 2 years old and is apparently not quite compatible anymore
[21:56:32 CET] <jamrial> can't they use a git snapshot?
[21:57:02 CET] <jamrial> they do it with x264, and i'm fairly sure they used to do that back in the ffmpeg 0.5 era
[21:57:11 CET] <nevcairiel> they could, but probably wont like that very much
[21:57:32 CET] <nevcairiel> especially since current vlc doesnt like ffmpeg 3.0 either, sicne they didnt remove the silly configure check
[21:58:11 CET] <JEEB> vOv
[21:58:15 CET] <wm4> lol
[21:58:33 CET] <nevcairiel> also our debian maintainer hasnt been seen for weeks
[21:59:31 CET] <nevcairiel> (well. 1.5 qulifies as multiple, right?)
[21:59:35 CET] <nevcairiel> qualifies*
[22:00:09 CET] <BBB> why does vlc not work with git head?
[22:00:21 CET] <jamrial> Andreas? I see an email from him from a week ago
[22:00:25 CET] <wm4> hwaccel threading
[22:00:34 CET] <nevcairiel> because they added a configure check to blacklist it in response to us disabling hwaccels with threading
[22:00:44 CET] <BBB> but we fixed that
[22:00:48 CET] <BBB> why is it still disabled?
[22:01:05 CET] <nevcairiel> ask them
[22:01:07 CET] <jamrial> because we haven't poked j-b about it maybe
[22:02:06 CET] <BBB> j-b: whats going on here? you could just poke me if there was a critical issue that needed to be fixed right away...
[22:02:12 CET] <BBB> so much goodwill wasted :(
[22:02:44 CET] <nevcairiel> BBB: the main problem of course is that noone from vlc ever talked to us directly about this topic
[22:02:54 CET] <nevcairiel> they just blacklisted ffmpeg without a comment
[22:02:56 CET] <BBB> indeed
[22:03:00 CET] <wm4> so much fun
[22:03:08 CET] <wm4> and we gave in too
[22:13:24 CET] <kierank> BBB: patch breaks one (huge) sample
[22:13:32 CET] <BBB> :(
[22:13:36 CET] <BBB> can you fix it? :-p
[22:13:43 CET] <kierank> looking now
[22:21:14 CET] <kierank> BBB: s->coded_format = -1 for some reason?
[22:21:17 CET] <kierank> how is that possible
[22:21:23 CET] <BBB> AV_PIX_FMT_NONe = -1
[22:21:38 CET] <BBB> why? no idea :-p
[22:30:10 CET] <kierank> I don't understand
[22:30:13 CET] <kierank> how is it possible
[22:30:50 CET] <BBB> depends on where/when
[22:33:55 CET] <kierank>         if (tag == 4 && data == 0x1a4a && s->coded_width && s->coded_height &&
[22:33:55 CET] <kierank>             s->coded_format != AV_PIX_FMT_NONE) {
[22:33:57 CET] <kierank> that check
[22:34:03 CET] <kierank> but s->coded_format is set to yuv422p10
[22:34:09 CET] <kierank> and there's no way it can get changed
[22:35:32 CET] <kierank> BBB: http://storage.sesse.net/trailer.avi
[22:35:35 CET] <kierank> that's the sample
[22:35:58 CET] <BBB> so where did it get changed?
[22:36:04 CET] <BBB> gdb watchpoint or so?
[22:36:16 CET] <Timothy_Gu> michaelni: backup completed. total 5.3 GiB
[22:36:33 CET] <kierank> oh bleh
[22:36:36 CET] <kierank> init_frame_defaults straight after..
[22:36:37 CET] <kierank> lol
[22:41:43 CET] <kierank> BBB: sent updated patch
[22:41:53 CET] <BBB> ty
[22:42:09 CET] <BBB> does it still fix the crash with the sample in that trac report?
[22:45:51 CET] <kierank> nope
[22:45:54 CET] <kierank> double free
[22:47:21 CET] <BBB> hm& well thats not good
[22:47:49 CET] <BBB> need me to look further? or can you fix that yourself?
[22:47:54 CET] <BBB> and is that only with mt or with thr=1 also?
[22:48:51 CET] <kierank> mt only
[22:49:46 CET] <kierank> I guess we need a separate variable for coded pixel format and allocated pixel format
[22:49:55 CET] <BBB> I did that, right?
[22:49:59 CET] <BBB> I had a_format and coded_format
[22:50:15 CET] <kierank> oh you check that
[22:50:16 CET] <kierank> ignore me
[22:50:23 CET] <kierank> dunno then
[22:50:31 CET] <kierank> let me do some more printfs
[22:55:51 CET] <BBB> which variable is double free'ed?
[22:57:18 CET] <kierank> it all looks fine to me
[22:57:24 CET] <kierank> but valgrind and gdb disagree
[22:58:54 CET] <kierank> crash still happens because the pixel format changes
[22:58:56 CET] <BBB> valgrind should tell you which variable is double free'ed
[22:59:15 CET] <kierank> --6908-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
[22:59:15 CET] <kierank> --6908-- si_code=80;  Faulting address: 0x0;  sp: 0x807136d60
[22:59:20 CET] <kierank> sometimes segfault sometimes double free
[23:00:15 CET] <BBB> hm ...
[23:00:27 CET] <BBB> let me test your patch
[23:00:52 CET] <kierank> I changed one line
[23:00:57 CET] <kierank> basically making yuv422p10 the default
[23:00:59 CET] <kierank> instead of none
[23:01:06 CET] <BBB> yes
[23:01:43 CET] <kierank> going to sleep now
[23:01:45 CET] <kierank> bye
[23:11:49 CET] <BBB> gnite
[23:12:37 CET] <BBB> how many threads?
[23:12:45 CET] <BBB> I dont see any issues with your patch with 1 or 2 threads
[23:14:13 CET] <nevcairiel> moar threads!
[23:14:32 CET] <BBB> I dont get any output for that cfhd sample either btw
[23:14:35 CET] <BBB> its just a gray screen
[23:58:16 CET] <kierank> It's not a grey screen
[23:58:22 CET] <kierank> There's video
[23:58:37 CET] <kierank> I have 8 threads by default iirc
[00:00:00 CET] --- Tue Feb 16 2016