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

[burek]

[02:19:36 CEST] <michaelni> jamrial, make disctclean ; ./configure && make -j12  doc/examples/transcode_aac_g fails with "gcc: error: doc/examples/transcode_aac.o: No such file or directory"
[02:20:10 CEST] <jamrial> michaelni: does that happen before the merge as well? this is not supposed to touch examples
[02:25:05 CEST] <jamrial> mmh, looks like not
[03:09:37 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07master:64e034da9541: avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
[03:09:37 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07master:4bb80133356b: avcodec/v4l2_buffers: More clear return code documentation
[03:09:37 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07master:b81b8a76b54c: avcodec/v4l2_context: Reduce spelling variations
[03:09:37 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07master:d679f3d02178: avfilter/vf_thumbnail_cuda: Avoid mixing declaration and statements
[04:39:30 CEST] <jamrial> michaelni: pushed a new version where it should be fixed
[04:41:01 CEST] <jamrial> we might want to fully decouple the examples recipes from the fftools ones. there's no point in compiling _g versions for those IMO
[04:44:38 CEST] <atomnuker> yep, stripping/copying can still take a second or two even on an ssd
[05:03:33 CEST] <jamrial> personally i'd also remove it from the fftools as well. they can be stripped during install, much like the libraries
[05:04:03 CEST] <jamrial> i might cook a patch for that and send it to the ml
[06:03:55 CEST] <ldts> jkqxz: what does the Hardware Output/Input column in https://trac.ffmpeg.org/wiki/HWAccelIntro#FFmpegAPIImplementationStatus means?
[06:06:39 CEST] <ldts> trying to understand how is different from HW Context (doesnt hw context provide this support?)
[11:31:52 CEST] <jkqxz> ldts:  Um, does raspberry pi really have any v4l2m2m support?  Where is it?  I'm really quite sure that the desktop platforms do not.  (And it seems unlikely anyone will ever accept pushing all of that complexity into the kernel for a nonembedded platform.)
[11:33:13 CEST] <nevcairiel> I was wondering about that, while it would be nice to have a single interface for all desktop platforms, I didn't really believe it to be real
[11:33:26 CEST] <nevcairiel> especially for nvidia with their closed driver
[11:33:48 CEST] <jkqxz> ldts:  There are some ad-hoc implementations of hardware surface input/output which don't use the common infrastructure (e.g. mediacodec), so they aren't the same thing.
[18:16:03 CEST] <cone-949> ffmpeg 03James Almer 07master:54ce880a4646: Partially revert "Merge commit '71a49fe25f2e4468fbbadbebef8d073b1b3cc1a5'"
[18:27:53 CEST] <cone-949> ffmpeg 03Karthick J 07master:9e271e3fa3f9: avdevice/decklink_dec: Used av_parity instead of duplicated function
[20:54:36 CEST] <cone-949> ffmpeg 03Carl Eugen Hoyos 07master:59924d5eb116: lavfi/vmafmotion: Allow more pix_fmts.
[21:59:04 CEST] <jamrial> michaelni: did you look at the latest version of the merge?
[22:19:05 CEST] <jkqxz> ldts:  There are some ad-hoc implementations of hardware surface input/output which don't use the common infrastructure (e.g. mediacodec), so they aren't the same thing.
[22:19:31 CEST] <jkqxz> ldts:  Do raspberry pi and desktop Linux really have V4L2M2M support?  Where can I find it?
[22:27:03 CEST] <ldts> jkqxz: every linux system since 2.635 has v4l2 m2m support (I think that a different matter is whether the specific platform running the OS has the hardware capabilities _and_ the driver support for it)...let me check the raspberrypi hardware now (I thought someone mentioned that it had hardware capabilities...maybe not. checking now)
[22:30:24 CEST] <jkqxz> Well, yeah, you can build it.  I can build NVENC anywhere too, but it's not going to work on something which isn't Nvidia.
[22:31:05 CEST] <jkqxz> So I don't think that table should be suggesting that people can use V4L2M2M on all desktop Linux, because they can't.
[22:32:34 CEST] <ldts> jkqxz: yes that is correct, but you can't say no either because they might...so it is kind of confusing in my opinion
[22:32:47 CEST] <jkqxz> And probably never will be able to - the whole point of V4L2M2M is to push all of the complexity into binary firmware and the kernel so that userspace can be uniform on Android, and that isn't really a useful thing on desktop.
[22:33:57 CEST] <jkqxz> Is there a Raspberry Pi driver?  I couldn't find one from a bit of Googling, but I admit that isn't conclusive.
[22:34:53 CEST] <ldts> jkqxz: ok..but ChromeOS for instance has decided to only support v4l2 m2m IIRC (hence the importance of supporting it)
[22:35:25 CEST] <jkqxz> It also supports VAAPI for all the Intel chips.
[22:35:51 CEST] <cone-949> ffmpeg 03Martin Vignali 07master:ac5908b13f16: libavcodec/exr : add x86 SIMD for predictor
[22:37:03 CEST] <ldts> jkqxz: ah I was thinking of arm ok
[22:39:09 CEST] <ldts> so no I can't find the driver either..maybe raspberry pi h264 support is through some other interface on linux then (I would have thought that its hardware acceleration on Linux should have gone via v4l2)
[22:40:00 CEST] <jkqxz> Raspberry Pi works via OpenMAX or MMAL.  A V4L2M2M driver is a plausible thing to exist there, though.
[22:42:37 CEST] <FishPencil> I'm getting undefined references to av_* components. I'm pretty sure one of the external libraries is dll*porting something and it's causing this. Is there a way to find which one without one by one disabling them to see what works?
[22:43:10 CEST] <ldts> jkqxz: yes I Can see the MMAL driver in the raspberry kernel tree...so no v4l2_m2m
[22:43:55 CEST] <jkqxz> There can be multiple.
[22:43:56 CEST] <jkqxz> Ok, table edited.
[22:44:53 CEST] <jkqxz> It would be nice to have some more ARM stuff in that table.  Just adding more columns quickly becomes silly, though, so I'm not sure how it would want to work.
[22:45:12 CEST] <jkqxz> Maybe a new table for ARM platforms, or just a list for the APIs?
[22:46:00 CEST] <ldts> yes I am not sure because the table says API Availability and the API is indeed aviable in all Linux systems...no ARM specific
[22:46:44 CEST] <ldts> maybe a table with all known working v4l2_m2m hardware?
[22:47:11 CEST] <jkqxz> IMO all ioctl()s returning ENOSYS does not constitute API availability.
[22:47:36 CEST] <jkqxz> That would be useful, yes.
[22:48:02 CEST] <ldts> yes it makes more sense, so Samsung Exynos, Qualcomm Dragonboards and so on
[22:48:58 CEST] <ldts> so the Platform Availability for v4l2_m2m should say P instead of Y 0r (Y with a * to indicate depends on hardware?)
[22:49:27 CEST] <jkqxz> There should probably be an "Linux on other ARM" column there.
[22:49:55 CEST] <ldts> but raspberry pi is linux on ARM...
[22:50:36 CEST] <ldts> ok I 'll think about this and will post a proposal on the ML
[22:50:37 CEST] <jkqxz> Hence "other".  Raspberry Pi shouldn't be special, but it is a very common platform with weird properties which are useful to distinguish.
[23:02:50 CEST] <michaelni> jamrial, i cant seem to find a failure in the latest version
[23:03:06 CEST] <jamrial> michaelni: ok, thanks a lot for testing
[23:28:27 CEST] <cone-949> ffmpeg 03Diego Biurrun 07master:c95169f0ec68: build: Move cli tool sources to a separate subdirectory
[23:28:28 CEST] <cone-949> ffmpeg 03James Almer 07master:2f7ca0b94e49: tools/ismindex: remove unused header
[23:28:29 CEST] <cone-949> ffmpeg 03James Almer 07master:fd5f4ac0813c: Merge commit 'c95169f0ec68bdeeabc5fde8aa4076f406242524'
[00:00:00 CEST] --- Mon Oct  2 2017