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

[burek]

[00:34:42 CEST] <akravchenko188> Guys, I have question.
[00:37:42 CEST] <akravchenko188> Probably I missed something. I have tried to upload amf support patches like amf context and scale mid of July. Thread in forum became dead, but I tried to ping to continue discussion.
[00:39:41 CEST] <iive> what forum?
[00:39:43 CEST] <akravchenko188> Could you please help how to drive hw support and not wait for months without feedback?
[00:40:13 CEST] <iive> i think all development is done on the maillist, if you have patches send them to the -dev maillist.
[00:40:38 CEST] <akravchenko188> I did
[00:40:54 CEST] <akravchenko188> I am talking about mail list
[00:41:05 CEST] <iive> oh
[00:41:43 CEST] <iive> what is amf?
[00:42:19 CEST] <akravchenko188> Media Framework from AMD
[00:43:03 CEST] <jamrial> jkqxz said he would look at it, afaik, but guess he hasn't had the time to
[00:44:33 CEST] <akravchenko188> Yep, he did. But it was more than three month ago
[00:45:50 CEST] <akravchenko188> Is it possible to speedup this somehow?
[00:46:58 CEST] <akravchenko188> There are lots of new stuff blocked by that patches
[00:49:35 CEST] <akravchenko188> So the main problem is the no feedback and huge latency :(
[00:50:37 CEST] <Compn> akravchenko188 : what kind of amd card do we need to test ?
[00:50:56 CEST] <Compn> akravchenko188 : the way is to give devels more amd cards :D
[00:51:41 CEST] <Compn> and for what os ?
[00:52:13 CEST] <akravchenko188> Most of not very old cards are supported
[00:52:29 CEST] <akravchenko188> Now windows
[00:53:26 CEST] <jamrial> Compn: it's not only testing, but also reviewing the implementation, since it adds a new public hwcontext module
[00:53:39 CEST] <akravchenko188> Amd added vulkan support for linux, and I am intended to implement support of it in ffmpeg
[00:54:17 CEST] <BtbN> Vulkan hwaccel/filter patches are already on their way
[00:56:41 CEST] <akravchenko188> I had discussion of hw context amf module. It is very simple. Just to share code between filters and codecs.
[00:57:13 CEST] <akravchenko188> It is following hwcontext machinery
[01:00:10 CEST] <akravchenko188> It would be really great to have feedback about hwcontextamf
[01:02:04 CEST] <BtbN> I think the primary issue is that nobody has an AMD card to test with
[01:02:15 CEST] <BtbN> Nobody that also reviews those patches
[01:04:09 CEST] <akravchenko188> Is there way to solve this? Is it possible to share pc with amd cards as node for ffmpeg testings?
[01:05:31 CEST] <akravchenko188> As part of continuous integration testing?
[01:06:06 CEST] <BtbN> An AMD-GPU enabled fate box would definitely be interesting
[01:06:24 CEST] <BtbN> There really aren't any tests for all the hwaccels right now
[01:13:22 CEST] <akravchenko188> No tests for any hw vendors?
[01:14:31 CEST] <akravchenko188> Only cpu codecs/filters are tested automatically?
[01:14:32 CEST] <jamrial> no, fate is not testing any hardware stuff
[01:15:06 CEST] <jamrial> also no external libraries, only internal modules
[01:15:33 CEST] <akravchenko188> Is this issue of fate architecture? Or just policy?
[01:16:22 CEST] <jamrial> policy. we have no control over what the external libraries do
[01:17:03 CEST] <jamrial> no saying it can't change to add some hwaccel tests eventually, as BtbN said
[01:20:58 CEST] <akravchenko188> Is it possible to add extension to fate just to run subset of tests with appropriate hw?
[01:24:40 CEST] <akravchenko188> It is very important to test hwaccel stuff on continuous integration basis for all vendors. Imho.
[01:27:42 CEST] <akravchenko188> So I see a few of issues with hwaccel: reviewing and testing and supporting
[01:28:57 CEST] <akravchenko188> Probably we need some strategy to solve all to have everything stable?
[01:34:36 CEST] <akravchenko188> Does anybody drive this?
[02:33:39 CEST] <Compn> akravchenko188 : we should ask j-b for some amd devs to test patches
[02:33:46 CEST] <Compn> devs w/ amd cards
[02:34:08 CEST] <Compn> j-b : we need amd cards apparently
[11:39:35 CEST] <durandal_1707> does mpeg2video bitstream can output Y plane values which are exactly 0 when decoded?
[13:09:56 CEST] <cone-296> ffmpeg 03Carl Eugen Hoyos 07master:b4e29e6225a8: lavf/mxfenc: Remove two unused variables.
[14:13:39 CEST] <cone-296> ffmpeg 03Martin Vignali 07master:04afdbb56052: swscale/x86/rgb2rgb : remove mmx version for shuffle2103
[14:13:40 CEST] <cone-296> ffmpeg 03Martin Vignali 07master:296609f859a5: swscale/x86/rgb2rgb : port shuffle 2103 mmxext to external asm and remove inline asm version
[15:02:47 CEST] <durandal_1707> iive: mplayer needs your help!
[15:05:39 CEST] <iive> durandal_1707, what's with the passive-aggressive messages?
[15:06:13 CEST] <durandal_1707> iive: which ones?
[15:06:49 CEST] <kierank> durandal_1707: theoretically yes mpeg2 can
[15:07:42 CEST] <durandal_1707> kierank: well, x262 intra have issues with some blocks which have 0, but not if all blocks are 0
[15:09:51 CEST] <atomnuker> durandal_1707: what's with the mplayer interest? no one uses mplayer unless they're forced to, and even then its probably on a 15 year old centos system
[15:10:09 CEST] <JEEB> centos and fedora don't distribute FFmpeg et al
[15:20:44 CEST] <atomnuker> yeah, what's up with that, I know they do it for patent reasons yet they keep other obviously patented stuff in
[15:21:16 CEST] <atomnuker> like the kernel, that's surely a minefield
[15:21:25 CEST] <kierank> atomnuker: yeah
[15:21:27 CEST] <kierank> it's such BS
[15:23:46 CEST] <durandal_1707> should i wait for pushing SER demuxer or should i push immediately?
[15:43:20 CEST] <cone-296> ffmpeg 03Paul B Mahol 07master:0709b0561f10: avformat: add SER demuxer
[15:44:18 CEST] <durandal_1707> i mix AVI and AV1 all the time
[16:32:23 CEST] <durandal_1707> michaelni: do you have comments about agm 3 ?
[16:36:23 CEST] <michaelni> durandal_1707, just posted a reply
[18:08:43 CEST] <BtbN> wow, SuperMicro released a BIOS Update for my X9 mainboard that's EOS since 2014
[18:12:29 CEST] <atomnuker> they were probably waiting for it to boot up all this time to test it before they uploaded it
[18:26:25 CEST] <BtbN> They're not HP
[18:53:19 CEST] <durandal_1707> does lavc have any way to crop height from start?
[19:01:29 CEST] <BtbN> crop
[19:02:11 CEST] <nevcairiel> simply cropping off lines should be easy, no alignment concerns there
[19:02:34 CEST] <nevcairiel> should check how the cropping in h264 or hevc works, they can do that
[19:32:13 CEST] <durandal_1707> i juse set frame->crop_top
[19:51:22 CEST] <durandal_1707> j-b: you got any samples for other codecs, like verint one?
[19:53:57 CEST] <durandal_1707> iive: nice work on mplayer
[20:10:28 CEST] <j-b> durandal_1707: ask koda
[20:10:45 CEST] <j-b> durandal_1707: also, AGM3 is listed now
[20:12:14 CEST] <durandal_1707> j-b: difference is very small
[20:13:55 CEST] <durandal_1707> to warrant another bounty..
[20:14:59 CEST] <j-b> then find new codecs :)
[20:15:32 CEST] <atomnuker> can't find one? no problem, make one yourself!
[20:15:36 CEST] <j-b> :D
[20:15:42 CEST] <j-b> FFv42
[20:17:48 CEST] <durandal_1707> VVC | XVC | ProRes RAW | Blackmagic RAW | ...
[20:18:01 CEST] <j-b> VVC will require a huge decoder time
[21:26:21 CEST] <qwefytuoityty> add nero aac?
[21:26:36 CEST] <JEEB> no
[21:26:46 CEST] <qwefytuoityty> yes?
[21:26:50 CEST] <JEEB> fdk-aac is good enough in open source for he-AAC use cases
[21:27:18 CEST] <JEEB> and already supported for encoding in FFmpeg
[21:27:22 CEST] <qwefytuoityty> vlc use for encoder ffmpeg?
[21:27:29 CEST] <JEEB> you can use it as well
[21:27:37 CEST] <JEEB> vlc also has its own fdk-aac module
[21:27:38 CEST] <JEEB> :P
[21:28:09 CEST] <JEEB> it's not included in any of the distributed versions though, since fdk-aac's license is technically incompatible with (L)GPL
[21:28:15 CEST] <JEEB> so you have to build that module yourself
[21:30:52 CEST] <qwefytuoityty> vlc windows
[21:33:01 CEST] <JEEB> if you want to test 24kbps he-AAC or whatever, you will have to build latest fdk-aac yourself (or probably someone on the internet distributes it - I have no idea), and then you have to build FFmpeg or VLC against it to have a module :P
[21:33:56 CEST] <JEEB> with fdk-aac in theory they could fix the license, and then you could mix it with (L)GPL stuff so it can be distributed in binary form, but closed source things such as nero's thing are not going to happen
[21:50:06 CEST] <durandal_1707> libavcodec/libaomenc.c:545:9: warning: unused variable 'pict_type' [-Wunused-variable]
[21:52:30 CEST] <cone-078> ffmpeg 03Paul B Mahol 07master:3ab88a751ebd: doc/filters: do not mention removed option from afir filter
[21:56:16 CEST] <BtbN> I think an LGPL build is just fine with fdk-aac
[21:56:24 CEST] <BtbN> Just an actual GPL build isn't
[21:59:08 CEST] <JEEB> could be, I might be misremembering that other case of closed source in LGPL etc
[21:59:15 CEST] <qwefytuoityty> VLC vorbis ogg is not bad, but only minimum 48 klbit. And one more problem compression through vlc in aac and vorbis takes ~ 5 minutes of wav of 78 MB and load of the processor of 100% the computer freezes for 5 min. until the encoding is over. And Nero and Opus console encoder encode the same file for ~ 30 seconds and the computer does not freeze up.
[21:59:22 CEST] <jamrial> BtbN: fdk-aac needs nonfree
[22:00:32 CEST] <BtbN> libfdk_aac is in EXTERNAL_LIBRARY_NONFREE_LIST, and configure says enabled gpl && map "die_license_disabled_gpl nonfree" $EXTERNAL_LIBRARY_NONFREE_LIST
[22:00:42 CEST] <BtbN> So in an lgpl build it does not need non-free
[22:01:05 CEST] <JEEB> yes
[22:02:47 CEST] <nevcairiel> from a legal standpoint t hat sounds weird to me
[22:03:04 CEST] <BtbN> That's how LGPL works
[22:03:05 CEST] <nevcairiel> if a library is classified proprietary and non-distributable, that shouldnt change
[22:03:31 CEST] <nevcairiel> LGPL only changes the requirements for the application using it, not the things we directly interact with
[22:06:44 CEST] <qwefytuoityty> i in vlc cnanel too
[22:07:39 CEST] <qwefytuoityty> AMD qad core x4 840 FM2+ Windows 32 1400MZ. Opus console and nero, load opus exe 25% 1400Mz
[22:28:50 CEST] <philipl> LGPL is satisfied if consumer can replace the LGPL bit with something they compiled themselves.
[23:26:51 CEST] <BtbN> philipl, nevcairiel: Is it just me, or shouldn't this be a >= check? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cuviddec.c;h=4d3caf924ed3aea1951c810a15ca22d36d510421;hb=HEAD#l381
[23:29:16 CEST] <BtbN> Also, I think the 2 should really be ulMaxDisplayDelay * ((!drop_second_field && deint != weave) ? 2 : 1)
[23:53:08 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/861531d29834b7a2940e426e5a761aa8e5eb37bc.patch seems more correct
[00:00:00 CEST] --- Sun Oct 14 2018