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

[burek]

[06:03:45 CET] <SortaCore> why does QSV "selected ratecontrol method not available" error not outptu the selected ratecontrol method?
[06:04:53 CET] <SortaCore> if you passed ratecontrol in one command it'd be understandable, but it gathers the rc from a bunch of params
[06:26:28 CET] <amit2020cs> Hi everyone , I am Amit and want to contibute to the community 
[10:46:50 CET] <nakul> Hi, kierank
[10:50:34 CET] <mateo`> Is it ok to use the bool type in the codebase ? (I'm looking at Aman's MediaCodec patch)
[10:51:13 CET] <mateo`> The only other use of this type is in the videotoolbox decoder
[10:56:03 CET] <wm4> mateo`: as long as you include stdbool, it should work at least (though I guess the public API shouldn't use it)
[10:56:52 CET] <wm4> regarding we "want" it, no idea, there are other C99 features which we pretend do not exist (although we definitely require C99)
[11:03:05 CET] <mateo`> doesn't we also require c11 ?
[11:05:50 CET] <wm4> yeah I guess for atomics we require c11, although we emulate them when C11 is not available
[11:06:13 CET] <jdarnley> So not exactly *required* then.
[11:07:12 CET] <jdarnley> But since we require the c99 standard integers I don't see why bool can't be used
[11:07:22 CET] Action: jdarnley has no comment about API
[11:11:10 CET] <Chloe> mateo`: I think we use c99 so probably
[11:38:20 CET] <nevcairiel> public API should remain free of those for compatibility, but in the code its probably fine
[11:40:00 CET] <mateo`> ok, everyone seems to agree so far, so i guess it's ok
[11:41:31 CET] <jkqxz> I would be kindof dubious about using it in general, but in android code it is surely fine because the set of usable compilers there is very restricted.
[11:51:30 CET] <wm4> actually the only incompatibility is with actual C89 users
[11:51:51 CET] <wm4> (for the API)
[11:52:00 CET] <wm4> jkqxz: even on android everything is going to support C99
[11:55:55 CET] <sfan5> the only supported compilers on Android are gcc 4.9 and clang 5.0
[11:56:13 CET] <sfan5> even older versions of the NDK have recent enough compilers that support C99 (e.g. gcc 4.8)
[11:59:08 CET] <JEEB> and those versions of gcc/clang have been around for quite a while
[12:10:39 CET] <wm4> whatever happened to the patch that makes the filter list in libavfilter static
[12:11:20 CET] <nevcairiel> that guy did it somehow entirely different to what avcodec etc did, and when he was told to unify it, he vanished
[12:48:44 CET] <atomnuker> Chloe?
[12:52:19 CET] <wm4> no, someone else
[12:52:37 CET] <nevcairiel> thats why it turned into something entirely different - different people doing the same hting and not talking =p
[13:22:42 CET] <CounterPillow> Hello, I wish to inquire whose dick I have to suck for a new release to be made. I have excellent tongue skills.
[13:23:08 CET] <thardin> wew
[13:26:13 CET] <thardin> lewd & rude
[13:26:29 CET] <thardin> stew
[13:27:02 CET] <kierank> CounterPillow: your own
[13:27:07 CET] <kierank> it's all you can get
[13:27:13 CET] <CounterPillow> :C
[13:43:29 CET] <JEEB> does anyone btw have any idea of what is the set of items to be done so we can start making a release branch?
[13:43:51 CET] <JEEB> (and then we can get the left things fixed so a release can be made)
[13:50:02 CET] <durandal_1707> nothing is set yet imho
[13:50:50 CET] <durandal_1707> lavfi filters into extern table?
[13:53:41 CET] <gagandeep> kierank: i have been interested in the cineform project because i will be learning more about codecs, videos and audio as i have been interested in that stuff
[13:53:56 CET] <kierank> ok
[13:54:35 CET] <gagandeep> but i still don't understand the relevance of doing cineform implementation in ffmpeg libraries
[13:55:37 CET] <gagandeep> what is ffmpeg actually doing by implementing their own version for various codecs
[13:56:34 CET] <gagandeep> i just don't understand the reason for doing this, and i know that i am perhaps sounding a bit offensive so i appologize for that
[13:57:57 CET] <noob> Hello. I just wanted to suggest allowing cryptocurrencies donations, like Bitcoin Cash or Monero.
[13:58:05 CET] <durandal_1707> look at vp8,  and others, they are faster, also cineform was opened long after it was reverse engineered
[14:00:04 CET] <durandal_1707> gagandeep: also bunch of codecs are not open source at all, so there is ffmpeg
[14:00:07 CET] <gagandeep> durandal_1707:so we don't just have to reverse engineer but actually to improve
[14:01:01 CET] <durandal_1707> something like that
[14:01:20 CET] <gagandeep> durandal_1707:thanks, i have been solely interested in this project because of what i will get out of doing this but now i am asking what the org will get from me doing this
[14:01:34 CET] <gagandeep> thanks for the answer
[14:02:51 CET] <durandal_1707> gagandeep: it will get better decoder
[14:03:39 CET] <gagandeep> i see now why interacting with the community is important for open source
[14:03:53 CET] <kierank> gagandeep: the gopro code is very hard to understand
[14:03:57 CET] <kierank> even when open source
[14:05:12 CET] <gagandeep> kierank: my exams are from 18th so i will not be actively participating till 23rd feb, so that is the reason i haven't been able to see much code yet
[14:05:21 CET] <kierank> ok
[14:05:38 CET] <kierank> deadline is march 27
[14:05:40 CET] <kierank> so you have time
[14:06:36 CET] <gagandeep> yeah, i haven't had the time for examining the codes yet properly so i felt lost and came here to discuss, but ya you guys have cleared the doubt
[14:06:48 CET] <gagandeep> a'right i am logging off now, thanks again
[15:12:00 CET] <doomedary> hey
[15:12:30 CET] <doomedary> db9e87dd8c1ce11d37edc16f9380ee8dee68891b breaks AVIO_FLAG_DIRECT use for me completely. I put in a check to exclude the change of packet size in that case which makes everything work again
[15:14:38 CET] <doomedary> Could someone tell me if I'm stupid and everything is intended like that (or verify that this commit breaks AVIO_FLAG_DIRECT) and that this simple fix would be ok?
[15:33:56 CET] <JEEB> so whatever protocol you're using is !h->is_streamed ? (whatever that flag means)
[15:34:11 CET] <JEEB> but in general yes, it seems to add additional buffering into the process so if that's your issue
[15:34:18 CET] <JEEB> then that sounds correct'ish
[15:34:43 CET] <doomedary> h->is_streamed is defined right above, which is kind of a silly check
[15:35:00 CET] <doomedary> so, whenever it's a file, h->is_streamed is false
[15:35:20 CET] <JEEB> right
[15:35:39 CET] <JEEB> anyways, feel free to post the patch on the ML and CC marton
[15:35:57 CET] <JEEB> if it's incorrect for some reason, we'll find out
[15:36:03 CET] <JEEB> if not, it will get applied
[15:36:14 CET] <doomedary> The problem is that the error is really confusing and this took me quite some time to locate. All of a sudden, av_write_frame and av_interleaved_write_frame would give EIO if my packets get too big (so depending on the content of my frames, it would fail with EIO)
[15:36:43 CET] <JEEB> I bet :P
[15:36:55 CET] <JEEB> bisecting probably would have been the simplest way to get to a known working state
[15:37:04 CET] <JEEB> and thus find the breaking commit
[15:37:08 CET] <doomedary> yeah i did a bisect
[15:37:39 CET] <doomedary> I just have this big software involving quite some hardware as well so each iteration took a bit
[15:38:09 CET] <doomedary> ok, i'll see if I can submit a patch, I believe ffmpeg does not require any signed forms
[15:39:30 CET] <JEEB> yea, it doesn't
[15:40:46 CET] <JEEB> if it's a corporate thing generally "-s" / "--sign-off" during `git commit` will mark it as something that someone signed off (although not required, pretty sure I've seen people post corporate patches without it, too)
[15:41:18 CET] <JEEB> we just generally think that if someone posted a patch on the ML, it was OK
[15:42:20 CET] <doomedary> ok, but should be fine for me/us it's only 20 chars :D
[15:42:44 CET] <doomedary> but i guess I should test agains master/HEAD first etc etc
[15:42:55 CET] <doomedary> and check if not anyone else noticed :| tedious
[15:49:19 CET] <durandal_1707> jamrial: load of money mostly
[15:49:49 CET] <jamrial> cool
[17:12:44 CET] <Chloe> atomnuker: I guess I can do lavfi. I also have a fully working cmdutils patch here
[17:16:12 CET] <Chloe> I just didnt want to do lavfi with the other libs cause lavfi is just so different and difficult
[17:16:53 CET] <JEEB> it makes sense to do things one by one :P
[17:16:56 CET] <JEEB> even if not difficult
[17:35:35 CET] <kepstin> alright, so I rewrote the fps filter using the activate callback.
[17:35:46 CET] <kepstin> I'm doing some more testing atm, but if anyone wants a look: https://gist.githubusercontent.com/kepstin/8f964bf6d336d9ef185af39445714ac2/raw/0001-libavfilter-vf_fps-Rewrite-using-activate-callback.patch
[17:43:59 CET] <durandal_1707> kepstin: send it to ml for review by nicolas
[17:44:18 CET] <kepstin> yeah, I plan to. I'm just finishing up some of my own tests first.
[17:46:37 CET] <kepstin> I think I'll probably have to write some fate tests too; there aren't any for the fps filter yet (i think?) so I'm not sure if I've introduced any regressions.
[17:49:07 CET] <durandal_1707> atomnuker: are you alive?
[17:51:04 CET] <atomnuker> yes
[17:51:46 CET] <durandal_1707> so why it takes so long to finish vulkan stuff?
[17:53:59 CET] <kepstin> oh, hah, that patch I linked doesn't even compile thanks to a typo.
[17:54:03 CET] Action: kepstin gets back at it.
[17:55:08 CET] <atomnuker> durandal_1707: I wanted to get drm buffer importing working as well as host mapping for async uploading done to do things as properly take advantage of whatever's supported
[17:57:07 CET] <atomnuker> s/as// s/properly/properly and/
[18:44:42 CET] <Nakul> Hi,kieran
[19:01:50 CET] <kierank> :(
[19:02:10 CET] <kierank> that guy has added me on facebook, tried and failed to tweet me and left irc too quickly :(
[19:02:36 CET] <durandal_1707> you have facebook?
[19:19:05 CET] <kierank> durandal_1707: yes
[19:19:21 CET] <kierank> durandal_1707: you not on facebook
[19:19:24 CET] <kierank> i tried adding you
[19:32:55 CET] <durandal_1707> kierank: one need to be very special for me to add to facebook
[19:33:08 CET] <kierank> but you can join facebook ffmpeg crew
[19:33:16 CET] <kierank> daemon404, av500 and others
[19:33:36 CET] <durandal_1707> what? thats awfull
[20:48:48 CET] <tmm1> i wish MAINTAINERS had irc handles
[21:03:55 CET] <thardin> that's not a bad idea
[21:04:08 CET] <thardin> I had just the same thought when writing myself into it a few days ago
[21:19:43 CET] <nevcairiel> well so the GCC produced import libraries on windows definitely don't work right with MSVC, guess i'll  send a patch to revert that change
[21:22:23 CET] <jamrial> nevcairiel: oh?
[21:22:31 CET] <nevcairiel> i told you this would happen :p
[21:23:42 CET] <JEEB> wasn't there just a discussion about that? and that def files could be used iwth link to create them?
[21:23:46 CET] <JEEB> (if available)
[21:23:58 CET] <jamrial> but we're not using dlltool, and msvc doesn't accept dll.a afaik
[21:24:01 CET] <nevcairiel> we used to do that, i have no clue why it was removed
[21:24:11 CET] <nevcairiel> dll.a is just a name, MS takes whatever you feed it
[21:24:14 CET] <JEEB> yea
[21:24:21 CET] <JEEB> with dll.a you just need to specify teh full name
[21:24:32 CET] <JEEB> since it only links against ".lib" by default without extensions
[21:30:29 CET] <nevcairiel> i'm not sure if dlltool generates on that works, I should test that
[21:30:46 CET] <nevcairiel> but we used to use lib.exe, libav for some reaosn removed that years ago, despite shit not working in all cases
[21:36:04 CET] <jamrial> i see lib.exe is being used in compat/windows/makedef
[21:36:15 CET] <jamrial> but only if binutil's ar is not present
[21:36:40 CET] <nevcairiel> it creates a lib file to dump the symbols from it, but deletes it again
[21:37:05 CET] <jamrial> right
[21:39:21 CET] <nevcairiel> ok the one-and-a-half revert works, lets see if dlltool behaves differently then gcc-made lib files
[21:43:26 CET] <nevcairiel> dlltool also seems to work, just gcc producing shit
[22:25:43 CET] <RiCON> nevcairiel: i remember mstorjo's change was because ffmpeg's linking kept getting broken by external libs setting declspec(dllimport)
[22:25:56 CET] <RiCON> i never actually tried it since, though
[22:26:07 CET] <JEEB> that's wbs here on IRC
[22:26:29 CET] <nevcairiel> all I know is that master doesnt work, and this does =p
[22:27:23 CET] <RiCON> this was specifically for shared ffmpeg + external static libs
[22:27:40 CET] <wbs> nevcairiel: what part in particular doesn't work with the binutils produced import library?
[22:28:21 CET] <nevcairiel> heck if i knew, it just doesnt load the library and the depends tool reports rather odd things that dont make sense
[22:28:35 CET] <nevcairiel> regenerate the lib with lib.exe, re-link my library, stuff works
[22:29:01 CET] <wbs> hmm, ok, I definitely should recheck that then
[22:29:10 CET] <wbs> or perhaps it's some difference between ffmpeg and libav?
[22:29:46 CET] <nevcairiel> dlltool works as well, its just gcc that produces something that doesnt work
[22:30:19 CET] <wbs> oh, ok
[22:30:36 CET] <wbs> that I really don't know why gcc itself produces something different than what dlltool does
[22:30:49 CET] <jamrial> we're adding a bunch of SHFLAGS to the gcc --out-implib call that libav doesn't
[22:33:15 CET] <nevcairiel> when using the gcc libs, for some reason the linker looks for the avresample symbols in avcodec, avformat and avutil, and doesnt find them,  and loading fails. despite also loading them from avresample itself. well at least thats what depends22 reports, who knows if it got confused by some other weirdness going on
[22:33:39 CET] <nevcairiel> curious that the .lib format is still such a piece of black magic :D
[22:34:47 CET] <wbs> oh, it's worse than that actually
[22:35:13 CET] <wbs> msvc and gcc uses two completely different styles of libraries for import libraries
[22:35:44 CET] <wbs> msvc uses a special kind of "object file" for functions to export/import from a dll
[22:36:03 CET] <nevcairiel> thats why msvc .lib files can also be magic hybrid files with some static functions and some linked
[22:36:21 CET] <wbs> that's also doable with gcc
[22:36:35 CET] <wbs> the .a/.lib files are just static libraries with no magic in itself on that level
[22:37:02 CET] <wbs> however, gcc on the other hand doesn't use the same kind of magic object files as msvc, but uses a bunch of pretty regular object files
[22:37:28 CET] <wbs> if you link those object files, you more or less will end up with the exact layout that you need in the dll import segment of a binary
[22:37:58 CET] <wbs> so instead of having a magic thing which says "this is a function to be imported", it's handled and linked as any other data
[22:38:10 CET] <wbs> which is kinda neat in one way
[22:38:42 CET] <wbs> but I tried adding support for that in lld, but haven't succeeded yet; there's some unknown piece of the logic on how to do it that we're missing there in lld
[22:39:04 CET] <wbs> (msvc link.exe mostly can do it, and all one ever would want to know is available to read in the binutils sources, but...)
[22:40:15 CET] <nevcairiel> seems to me like its moving the responsibility to the wrong side
[22:40:48 CET] <nevcairiel> telling the linker "import this symbol" seems more straightforward then producing an object that just happens to fall into the right place
[22:42:20 CET] <wbs> in one way yes. although the other one also gives some sort of more freedom to express other things I guess
[23:12:18 CET] <wbs> nevcairiel: ok, I can reproduce that. will send a revert for that commit to libav after some more testing with my llvm-mingw setup
[23:14:41 CET] <nevcairiel> with a plain revert, similar to the patch i send to ffmpeg-devel, you still get both, the .dll.a from gcc (for gcc, i guess), and the .lib for msvc, suppose that works well enough
[23:15:32 CET] <wbs> I think the .lib that is produced by dlltool also should work for gcc/ld, but perhaps there's some fancy incomaptibility there as well (but I doubt it)
[23:16:00 CET] <wbs> just curious, if dlltool (which is in the same gnu binutils project as ld) can do it properly, why can't ld?
[23:16:21 CET] <nevcairiel> the binutils people d ont care that much for win32
[23:16:41 CET] <nevcairiel> 2.30 cant even make any working windows binaries
[23:16:44 CET] <nevcairiel> so much for testing :)
[23:20:44 CET] <SortaCore> *slowly stares at videolan cross compiler team*
[23:21:11 CET] <SortaCore> I need more tea
[23:21:31 CET] <SortaCore> can someone explain how to make a patch, they'll be like two-liners to make error messages more useful
[23:21:59 CET] <SortaCore> but me git noob and apparently have the memory of a sieve with git as well
[23:24:36 CET] <jamrial> nevcairiel: msys2 pushed binutils 2.30 and i've been using it
[23:24:47 CET] <jamrial> admitedly, they might have added some patch on top of it
[23:24:48 CET] <nevcairiel> yeah they picked the fix
[23:24:51 CET] <jamrial> right
[23:25:01 CET] <nevcairiel> but its still hilarious that they managed to make a release with such a huge flaw
[23:25:01 CET] <JEEB> they probably broke everything at first and then picked the fix in ;)
[23:25:07 CET] <JEEB> yes
[23:25:15 CET] <JEEB> binutils should have at least tested the binary they made once
[23:25:39 CET] <jamrial> JEEB: yep, msys2 pushed 2.30, reverted to 2.29, pushed it back with the fix it seems
[23:25:45 CET] <JEEB> :D
[23:26:16 CET] <RiCON> i remember at least x265 being broken by the initial release of 2.30
[23:26:24 CET] <jamrial> they also pushed an update for perl that broke a lot of modules, including the ones needed by git send-email
[23:26:29 CET] <RiCON> binary ran but had no version
[23:26:30 CET] <jamrial> but it was fixed fairly quikc
[23:33:09 CET] <cone-879> ffmpeg 03Gyan Doshi 07master:f0809bc0fa63: avformat/mpegenc - accept PCM_DVD streams
[23:33:09 CET] <cone-879> ffmpeg 03Gyan Doshi 07master:310d56e86f49: fate/mpegps: add tests for PCM_DVD stream remux
[00:00:00 CET] --- Sat Feb 17 2018