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

[burek]

[01:11:51 CET] <cone-544> ffmpeg 03Carl Eugen Hoyos 07master:dbecf03f692a: lavc/qtrle: Do not use aligned writes for 24bit frames.
[01:17:25 CET] <uau> cehoyos's patch doesn't look complete
[01:18:07 CET] <uau> in the 64-bit case, while the loop itself advances by 8, it doesn't look like the pointer would be kept 8-aligned overall
[01:18:15 CET] <nevcairiel> that code is old
[01:18:24 CET] <nevcairiel> only the 24bpp case was changed recently
[01:19:59 CET] <nevcairiel> unless i missed a commit
[01:20:01 CET] <uau> nevcairiel: nope, AV_WN64A was introduced by 3278ea67c8f2a7c1aea8fd3114b35983791e6732 (part of recent changes)
[01:41:49 CET] <cone-544> ffmpeg 03Carl Eugen Hoyos 07master:def18ac43bb9: tests/fate/ffmpeg: Check for apng codec for fate-copy-apng.
[04:16:42 CET] <vel0city> Is anyone working on the DNG GSoC project idea?
[04:18:07 CET] <vel0city> Noone has expressed interest for it?
[07:17:48 CET] <vel0city> DNG is an extension of the TIFF 6.0 format
[07:17:55 CET] <vel0city> should its implementation reside in tiff.c?
[08:27:20 CET] <JEEB> vel0city: if it makes sense. if it is sharing most of the structure etc then it mighr make sense as a separate input format like mp4/mov/etc are in mov(enc)
[08:27:47 CET] <JEEB> if it's only some basic structures then sharing some parsing functions only makes sense
[08:32:35 CET] <vel0city> JEEB: Right, just looked at mov(enc) and that's pretty much what I was thinking would be best. Because they do share most of the structure.
[08:32:57 CET] <JEEB> alright
[08:35:52 CET] <vel0city> JEEB: Could it be a combination of the two approaches? Use tiff.c but implement DNG specific stuff in dng.c
[08:37:03 CET] <vel0city> Assuming that it's worth it (ie. there would be a lot of DNG code)
[08:37:08 CET] <JEEB> yea
[12:04:45 CET] <vel0city> I'm looking at an image file format that has 5 8-bit components per pixel
[12:05:06 CET] <vel0city> it's CMYK + A which I'm assuming is not even used
[12:05:30 CET] <vel0city> how would I map that to an pixfmt?
[12:05:40 CET] <vel0city> the only 40bpp formats I can find are planar, which this isn't
[12:06:20 CET] <vel0city> CC durandal_1707
[12:08:03 CET] <vel0city> would I have to process it myself?
[12:09:50 CET] <thardin> something tells me you need color information to go along with it
[12:10:01 CET] <nevcairiel> we don't have any CMYK formats at all, so the easier option would be to convert it to RGBA, or the more complex alternative would be adding CMYK formats as needed
[12:10:40 CET] <thardin> conversion to RGB is lossy tho
[12:10:51 CET] <nevcairiel> i believe some tiff decoding already does cmyk to rgb
[12:12:01 CET] <vel0city> nevcairial: Not TIFF, but PSD does
[12:12:26 CET] <vel0city> *nevcairiel
[12:12:45 CET] <nevcairiel> tiff as well as  far as i can tell
[12:12:51 CET] <vel0city> where?
[12:12:57 CET] <nevcairiel> look for the TIFF_PHOTOMETRIC_SEPARATED case
[12:13:28 CET] <vel0city> ah right
[12:13:58 CET] <vel0city> that wasn't really my problem though
[12:14:12 CET] <vel0city> first I gotta map it to a pixfmt 
[12:14:23 CET] <vel0city> or figure out how to do it without pixfmt
[12:16:22 CET] <vel0city> oh, I just read the code around the SEPARATED case
[12:18:08 CET] <vel0city> yeah that doesn't look too hard, thanks
[14:44:56 CET] <lemourin> why can't anyone comment on my one line patch: https://patchwork.ffmpeg.org/patch/12153/ ? i've been waiting for 3 weeks and pinged it twice already..
[14:48:35 CET] <durandal_1707> lemourin: just ping it more, every day
[14:49:32 CET] <lemourin> ehh, i didn't want to be called out on being too annoying
[14:51:17 CET] <durandal_1707> lemourin: you are ok until Nicolas complain
[15:05:32 CET] <thardin> that m264 guy is still trying to do dlopen()
[15:05:46 CET] <BBB> that m264 guy still trying to link to closed source software
[15:05:52 CET] <thardin> yes
[15:06:06 CET] <BBB> why did we reject realvideo wrappers but are we intending to accept matrox264 wrappers
[15:06:18 CET] <BBB> should I submit a request for a foundation vote?
[15:06:23 CET] <thardin> did the realvideo wrappers also use dlopen()
[15:06:40 CET] <thardin> ?
[15:06:52 CET] <BBB> ctx->lib_handle = dlopen(LIBRV11DEC_FILE, RTLD_LAZY);
[15:06:55 CET] <BBB> https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer
[15:06:58 CET] <BBB> looks like it, yes
[15:07:23 CET] <BBB> I think it's so that people can download binaries with rv support
[15:07:27 CET] <BBB> but without rv binaries
[15:07:35 CET] <BBB> and then they can add rv support by simply installing the dll
[15:07:40 CET] <durandal_1707> ladspa and frei0r use dlopen
[15:07:40 CET] <BBB> without needing a new build of ffmpeg
[15:07:56 CET] <nevcairiel> those are plugin frameworks, isnt that used to load plugins?
[15:08:00 CET] <durandal_1707> yes
[15:08:05 CET] <nevcairiel> well different thing =p
[15:08:18 CET] <thardin> those also aren't for circumventing the (l)gpl
[15:08:32 CET] <thardin> though they may have that effect indirectly
[15:08:33 CET] <BBB> I don't think it's circumventing, it's just ignoring entirely
[15:08:48 CET] <BBB> "we don't care about your license, we just want to make money"
[15:09:17 CET] <thardin> "donate $100¬ to fffoundation and me might consider it"
[15:09:25 CET] <thardin> err 100k¬
[15:09:39 CET] <BBB> lol
[15:10:01 CET] <nevcairiel> i'm sure some companies might even consider that
[15:10:14 CET] <BBB> anyway, I'm thinking we should set a project policy on linking to closed-source software
[15:10:15 CET] <durandal_1707> yes, then we can make FFDD
[15:10:26 CET] <BBB> and this "it's hardware GPU drivers!" thing should also be tightened if you ask me
[15:10:32 CET] <thardin> BBB: aren't there lots of hardware encoders already?
[15:10:32 CET] <BBB> not everything is a "system library"
[15:10:42 CET] <thardin> or do those go via some kernel thing maybe?
[15:10:53 CET] <BBB> I honestly think we're starting to have too many
[15:10:58 CET] <BBB> qsvmpeg
[15:11:03 CET] <BBB> instead of ffmpeg
[15:11:11 CET] <BBB> can you still use ffmpeg without intel qsv hardware?
[15:11:19 CET] <BBB> or is that similar to using ffmpeg without simd optimizations?
[15:11:21 CET] <BBB> ;)
[15:11:33 CET] <thardin> I mean, they could just push yuv4mpeg or whatever it's called instead of hooking crap into libav*
[15:11:56 CET] <BBB> the part where certain filters require qsv or cnn annoys me a bit
[15:12:11 CET] <BBB> maybe I'm just old-fashioned
[15:12:16 CET] <BBB> or just old
[15:12:19 CET] <thardin> piping raw video streams around is a perfectly workable solution and incurs no maintainer effort for ffmpeg's part
[15:12:45 CET] <BBB> right, so why don't they do that? why all this effort to integrate into ffmpeg? I don't get it, other than us now carrying the maintenance burden
[15:12:58 CET] <nevcairiel> qsv decoding and the qsv filters should really just be canned, since platform-driven decoding like dxva or vaapi is generally better and more maintained, and the qsv encoder can afaik accept surface data from vaapi or dxva
[15:13:06 CET] <nevcairiel> but some people hang on to those for reasons
[15:13:48 CET] <thardin> BBB: probably the latter part. also network effect
[15:14:12 CET] <nevcairiel> it makes it sound nice to be able to say that ffmpeg supports it
[15:14:17 CET] <thardin> it effectively turns ffmpeg into an advertising vehicle for a set of vendors
[15:17:08 CET] <durandal_1707> for free?
[15:18:44 CET] <iive> what is matrox264 doing? decoding or encoding?
[15:19:23 CET] <iive> last time i heard of matrox, they were rebranding radeon cards... so are they really using their own hardware?
[15:24:16 CET] <nevcairiel> its apparently some enterprise-y stuff
[15:25:40 CET] <nevcairiel> 422 encoding only, presumably 10-bit
[15:26:05 CET] <nevcairiel> https://www.matrox.com/video/en/products/developer/hardware/m264/
[15:32:47 CET] <BBB> I believe it's primarily encoding, but it appears there was a decoder wrapper in the patch also
[15:35:29 CET] <JEEB> anyways, we'd need clear-cut rules for what's kosher and what's not and unfortunately that's going to be hard :/
[15:35:55 CET] <BBB> not doing anything is worse
[15:35:59 CET] <JEEB> yes
[15:36:07 CET] <BBB> I understand if people are fine with closed-source, and then I'll take the result and shut up
[15:36:08 CET] <JEEB> since we already got nonfree-and-not-open-source things in there
[15:36:17 CET] <JEEB> which is IMHO bad
[15:36:20 CET] <BBB> the reason I keep bringing this up is because it is my impression many of us *don't* like this
[15:36:22 CET] <BBB> yes
[15:36:32 CET] <JEEB> I think nonfree originally was for just incompatible *OSS* licenses
[15:36:45 CET] <JEEB> not "get yer free proprietary module in here!"
[15:37:43 CET] <JEEB> but I'd have to check the history of the repo for that a bit more
[15:37:43 CET] <JEEB> :P
[15:42:42 CET] <BBB> I think you're right
[15:42:52 CET] <BBB> "nonfree" was for things like the weird licensed aac encoders
[15:42:54 CET] <BBB> but they were opensource
[15:42:57 CET] <JEEB> yup
[15:43:04 CET] <BBB> and then it became for non-compatible but free licenses
[15:43:20 CET] <BBB> there were some opensource licenses incompatible with gpl
[15:43:32 CET] <BBB> so --enable-gpl + these encoders became nonfree = nondistributable
[15:43:40 CET] <BBB> but it was never intended for closed source software
[15:43:50 CET] <BBB> nowadays we don't even bother with nonfree anymore
[15:43:54 CET] <BBB> we just dlopen it and it's ok???
[15:43:59 CET] <BBB> crazy
[15:44:45 CET] <nevcairiel> we dont even have that many things in the nonfree list, there is 2 openssl things, 1 of those aac decoders, and only 2 actual proprietary things, one of those is a hardware interface,  and one is pure s oftware afaik
[15:45:08 CET] <nevcairiel> and that software thing was being discussed recently anyway (ndi  shit)
[15:45:58 CET] <JEEB> but yea, there's the question of what we're considering OK. for actual OS provided interfaces the answer is simple (f.ex. dxva2/d3d11va), but then you get the stuff where the interfaces are provided by the driver, not the OS
[15:46:15 CET] <JEEB> to which point is that OK and to which point is it not?
[15:46:19 CET] <JEEB> (´4@)
[15:46:21 CET] <nevcairiel> if you to to linux, what is "the OS" anyway?
[15:46:25 CET] <nevcairiel> go to*
[15:46:45 CET] <JEEB> yea, that was what I limited my sentence first, but then remembered that nvidia provides interfaces on windows as well P
[15:46:48 CET] <JEEB> :P
[15:49:07 CET] <JEEB> and if we're OK with driver provided interfaces then how do we decide what to go with and what to not go with? is it enough if we stick against interfaces that will dload stuff in the background or?
[15:49:11 CET] <JEEB> :psyduck:
[15:51:55 CET] <nevcairiel> the problem is that there is technically no difference between an nvidia encoder and a matrox encoder, both use some .so to talk to a driver to facilitate some hardware encoder doing things, except one is actually useful to thousands if not millions of people, and one is a "pro" device for corporate use
[15:52:13 CET] <JEEB> yes
[15:52:44 CET] <JEEB> the nvidia layer just IIRC puts the dload stuff behind an nvidia interface, and here they put it in the patch
[15:52:50 CET] <JEEB> > nvenc_dload_funcs
[15:53:47 CET] <nevcairiel> thats even a header-only implementation that it pulls in, not a library it links to
[15:56:46 CET] <iive> the matrox thing is not even video card. it's just pcie card.
[15:56:56 CET] <nevcairiel> well, hardware is hardware
[15:57:20 CET] <iive> is that a problem for vaapi or vdpau?
[15:57:32 CET] <iive> how hard is to write a wrapper for them?
[15:57:44 CET] <iive> same for the nvidia encoder?
[15:58:01 CET] <nevcairiel> vdpau doesnt have any encoding, and vaapi encoding is .... very low level
[15:58:28 CET] <atomnuker> yeah, they wouldn't expose such low level stuff
[15:58:56 CET] <nevcairiel> i'm really not sure what someone thought when they designed the vaapi encoding api
[15:59:10 CET] <nevcairiel> it seems like a direct driver interface with the high-level api library missing
[15:59:10 CET] <durandal_1707> does anybody know how to RE codec using only entropy data from video frames?
[15:59:31 CET] <iive> then it is up to us to create a new api for hardware encoding
[15:59:36 CET] <atomnuker> its pro hardware, so the people who use it would still need to force the decoder and presumably won't use anything else, so I don't see the problem with not including m264 and letting users implement it themselves
[15:59:47 CET] <iive> and to movie the vendor stuff into it.
[16:00:56 CET] <iive> the library implementing it should probably be some mit/bsd/llvm style license
[16:01:03 CET] <iive> and it will by a system library.
[16:01:26 CET] <atomnuker> libyami :)
[16:01:34 CET] <JEEB> :D
[16:01:37 CET] <JEEB> libdarkness
[16:02:49 CET] <iive> btw, does v4l2 also get into the codec business?
[16:02:55 CET] <nevcairiel> the problem is that such a project would be a swamp of annoyance, because all the hardware interfaces are so different
[16:03:41 CET] <nevcairiel> v4l2 has some decoding interfaces
[16:03:54 CET] <nevcairiel> but i dont think its very widely supported
[16:03:58 CET] <nevcairiel> on some ARM systems iirc
[16:04:17 CET] <nevcairiel> we even support that
[16:04:23 CET] <iive> nevcairiel, the question is if the swamp would be in a separate library or inside ffmpeg.
[16:04:32 CET] <atomnuker> yeah, but very few boards support that horrible interface anyway
[16:04:43 CET] <iive> it's already getting quite muddy around here.
[16:05:12 CET] <nevcairiel> now ARM, thats a real swamp of hardware nonsense
[16:05:25 CET] <nevcairiel> no unified interfaces whatsoever
[16:05:43 CET] <nevcairiel> only OpenMAX, which is horrible
[16:05:57 CET] <atomnuker> no one uses that now these days though, right?
[16:06:21 CET] <iive> it was replaced by something even more obscure, afaik
[16:06:23 CET] <nevcairiel> i have no clue what one uses to achieve hardware access on arm in a broader scale
[16:06:30 CET] <nevcairiel> on android you  probably hook into mediacodec
[16:07:28 CET] <atomnuker> I think wm4 was telling me about some /sys or debugfs horrors, not sure if that was on the odroid or rpi
[16:07:45 CET] <nevcairiel> rpi is the worst non-standard thing when it comes to graphics anyway
[16:07:56 CET] <iive> agree
[16:08:02 CET] <nevcairiel> the broadcom proprietary drivers are so bad
[16:08:15 CET] <nevcairiel> and the opensource version is slow :)
[16:09:29 CET] <sourabhboss> What is codec_tags in mov muxer
[17:22:32 CET] <J_Darnley> sourabhboss: a mapping of ffmpeg api to codec specific values, maybe
[17:48:47 CET] <sourabhboss> J_Darnley: Thanks :) 
[17:52:02 CET] <durandal_1707> JEEB: open bug report about v3.80 APE not decoding properly
[17:52:07 CET] <JEEB> ok
[17:52:14 CET] <JEEB> I was planning on but not during $dayjob
[18:12:18 CET] <faLUCE> Hello. Please have a look at ffmpeg.c,  the line with: av_log(NULL, AV_LOG_INFO, "encoder -> type:audio "  .   The previous line  "av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase);     "  should be  put AFTER the log line
[18:15:12 CET] <JEEB> I guess what he is trying to say is that the logging would be more consistent if the time base for the send and receive log would be the same
[18:15:31 CET] <JEEB> you can grasp the time base from the _time logging but those are not exact values
[19:54:31 CET] <atomnuker> if anyone's bored and still hasn't played it - play dead cells
[19:58:40 CET] <durandal_1707> atomnuker: stop playing games, make something useful
[19:59:10 CET] <gnafu> Like FFV2.
[19:59:32 CET] <durandal_1707> nope
[20:00:22 CET] <gnafu> Well, I'd like to see more FFV2 development.
[20:02:04 CET] <atomnuker> nah, don't wanna work on that, I wanna work on vulkan
[20:08:37 CET] <gnafu> atomnuker: Aah.
[20:12:49 CET] <jamrial> nevcairiel: do you have any idea why fate-copy-png is failing on msvc even after carl's fix?
[21:42:10 CET] <JEEB> oh, so we're OK with bools now?
[21:42:34 CET] <JEEB> as much as C bools are such :D
[21:43:52 CET] <JEEB> mediacodec and msbc at least seem to use bool
[21:44:36 CET] <atomnuker> we should not be okay with it unless some external api requires it
[21:59:07 CET] <J_Darnley> yeah, cant do a 3 state boolean with bool
[22:17:04 CET] <philipl_> true, false, file_not_found
[22:18:39 CET] <atomnuker> true, false, *((uint8_t *)&var) = 0xff;
[22:28:32 CET] <iive> true, false, NULL :P
[23:07:22 CET] <vel0city> apparently I _have_ to assign a pixfmt even if I want to process it myself? why?
[23:07:39 CET] <vel0city> what is it even used for?
[23:08:38 CET] <vel0city> ahh I see it's used to check the image size
[23:08:45 CET] <vel0city> still, that's hacky :/
[23:08:58 CET] <vel0city> image support seems hacky in general
[23:09:11 CET] <durandal_1707> vel0city: how it is hacky?
[23:09:51 CET] <vel0city> durandal_1707: because now I have to find any 40bpp format and assign it to that
[23:09:57 CET] <vel0city> so that the size check will work
[23:10:02 CET] <vel0city> even if that format has nothing to do with mine
[23:10:07 CET] <vel0city> or, make a new pixfmt...
[23:11:03 CET] <durandal_1707> if you need 10bit per 4 components, make new format
[23:11:26 CET] <vel0city> it's 8-bit 5 components actually
[23:11:48 CET] <vel0city> and the thing is, TIFF can support arbitrary components per each photometric
[23:12:07 CET] <vel0city> though now I'm just limiting it to just 4+1, probably not much point to be generic in this case
[23:12:27 CET] <vel0city> aribitrary extra components*
[23:12:51 CET] <vel0city> er, sorry, I haven't provided much context. here's the issue I'm solving: https://trac.ffmpeg.org/ticket/7675
[23:14:42 CET] <durandal_1707> vel0city: wasnt patch about that made by Carl already?
[23:15:18 CET] <vel0city> which patch? master from yesterday still doesn't read that image properly
[23:15:28 CET] <durandal_1707> on mailing list
[23:15:34 CET] <durandal_1707> not yet committed
[23:17:16 CET] <vel0city> oh. crap.
[23:19:06 CET] <vel0city> shouldn't there be a indication on Trac when someone solves an issue? ...
[23:19:36 CET] <JEEB> links to patches, possibly? although generally active tickets might only get updated after the improvement gets in
[23:20:13 CET] <vel0city> so the only option is to always search the mailing lists for relevant patches?
[23:20:23 CET] <JEEB> pretty much
[23:23:53 CET] <vel0city> alright
[23:24:29 CET] <vel0city> at least I didn't waste my time, getting familiar with that code is useful for DNG
[23:25:08 CET] <vel0city> someone should review that patch though... it's from two months ago
[23:25:16 CET] <vel0city> er, one
[23:26:30 CET] <JEEB> I remember there was some discussion regarding it, but I don't remember the details
[23:27:27 CET] <vel0city> I'm looking at his code too atm. hm, he doesn't read the ExtraSamples tag which seems wrong
[23:29:25 CET] <vel0city> it's less generic the way he does it, but I guess it doesn't matter if you're not gonna implement ExtraSamples support for other color spaces/formats anyway
[23:30:32 CET] <vel0city> JEEB: I assume the discussion was on here? Can't find any emails.
[23:30:53 CET] <JEEB> it was on the ML
[00:00:00 CET] --- Sat Mar 16 2019