[Ffmpeg-devel-irc] ffmpeg-devel.log.20170309
burek
burek021 at gmail.com
Fri Mar 10 03:05:02 EET 2017
[00:00:08 CET] <BBB> (excuse my python)
[00:01:50 CET] <BBB> nevcairiel: as for fixing fate, why do we print the raw side data buffer? why not create a nice print_spherical_data utility function that checks if the data size is correct and else errors out? and then use that in ffprobe
[00:43:48 CET] <noobe1> Hello, anyone here knows of HEVC licensing and support by FFmpeg? I'm having very hard time finding whether HEVC would fall under LGPL or GPL when used with FFmpeg.
[00:47:28 CET] <TD-Linux> noobe1, ffmpeg does not provide any patent licenses
[00:47:33 CET] <jkqxz> There are quite a few different parts to consider. The ffmpeg decoder is LGPL. The x265 encoder is GPL, so ffmpeg built with support for it is GPL. The various hardware encoders (NVENC, VAAPI) are LGPL for the ffmpeg parts, but require external components which may have other licences.
[00:48:53 CET] <noobe1> That clears up things. Do we keep this info documented somewhere in readme or source code? Or is just "known"?
[00:50:40 CET] <llogan> LICENSE.md has some info. you can also just view the source code of the particular component you are interested in. the header will contain license info.
[00:50:42 CET] <jkqxz> Which part? (I'm not sure whether that was meant to be a patent or a copyright question.)
[00:51:18 CET] <noobe1> I'm intereted in decoding part (playback) for now. Which files woudl that be?
[00:53:08 CET] <jkqxz> Unless you use hardware, decoding is all part of libavcodec so the top-level LGPL licence applies (i.e. LICENSE.md).
[00:53:14 CET] <iive> noobe1: usually GPL portions require you to use --enable-gpl configure option.
[00:53:15 CET] <noobe1> BTW, I just downloaded HEVC demo file from http://demo-uhd3d.com/fiche.php?cat=uhd&id=101 and latest FFmpeg release doesn't play it. Is there any suggested test files?
[00:54:01 CET] <noobe1> hmm...maybe 3D is a problem...I'll try different files
[00:57:14 CET] <jkqxz> Works for me.
[00:59:28 CET] <noobe1> looking at license.md, it says "the following libraries are under GPL": - libx264
[00:59:28 CET] <noobe1> - libx265
[00:59:41 CET] <noobe1> are those used for decoding or encode?
[00:59:54 CET] <kierank> enode
[00:59:56 CET] <kierank> c
[01:00:41 CET] <noobe1> alright, how can I tell which H264/H265 *.c file is used for decoding then?
[01:02:04 CET] <jkqxz> Primarily libavcodec/hevc*.c, but it depends on a lot of code in other files as well (non-H.265 specific support stuff).
[01:02:09 CET] <unholy_me> while registering my filter, running make it says undefined reference to ff_(file name). Any idea why?
[01:02:25 CET] <Compn> in which file
[01:02:39 CET] <jkqxz> You added it to allfilters.c but didn't add it to the Makefile?
[01:02:48 CET] <unholy_me> no I added it to both
[01:03:05 CET] <unholy_me> makefile and allfilters.c
[01:03:39 CET] <jkqxz> Did you rerun configure so that the config option for it exists? (It is made by parsing allfilters.c.)
[01:04:15 CET] <unholy_me> yup when config runs, my new filter is shown on the list of available filters
[01:04:30 CET] <jkqxz> Does it get built by make?
[01:04:41 CET] <unholy_me> nope, thats the problem
[01:05:06 CET] <unholy_me> it says undefined refernce to ff_(my filter)
[01:05:35 CET] <jkqxz> You added a line like OBJS-$(CONFIG_BLAH_FILTER) in the makefile, is CONFIG_BLAH_FILTER set in your config.h?
[01:06:55 CET] <unholy_me> okay just ran a make -n
[01:07:01 CET] <unholy_me> problem solved
[01:07:21 CET] <unholy_me> CONFIG_BLAH_FILTER --- didnt write filter :P
[01:07:26 CET] <unholy_me> sorry
[03:18:15 CET] <RiCON> BtbN: npp doesn't support p010le or is it just scale_npp?
[03:37:34 CET] <c3r1c3-Win> BtbN: Are you the same BtbN that hangs (or used to hang out) in OBS chat?
[07:20:31 CET] <cone-345> ffmpeg 03Muhammad Faiz 07master:53a5cea47861: swresample/resample: do not allow odd filter_length
[07:23:53 CET] <philipl> BtbN: If it's a driver bug, then me on linux vs you on windows would be a big difference. I'll try and verify I can reproduce with the basic sample.
[07:28:18 CET] <philipl> BtbN: so, I got it to lock up immediately.
[07:28:26 CET] <philipl> ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -i burosch2.mpg -flags +ilme+ildct -c:v h264_nvenc -preset slow -rc vbr_2pass -rc-lookahead 10 -b:v 2M -refs 7 -bf 0 -c:a copy -c:s copy -map 0 bob.mkv
[07:28:44 CET] <philipl> If I do that with -bf 1, I get 'No free surfaces'.
[07:28:53 CET] <philipl> Linux, 378.13, GTX1080
[07:40:47 CET] <rcombs> ubitux: remind me what happened to subs-in-lavfi
[07:47:00 CET] <ubitux> i got busy with the merges, then i had more important stuff to do
[07:56:31 CET] <uu8> I have been able to debug ffmpeg with gdb but when the process become threaded at conversion my debug does not enter to the threads
[07:57:02 CET] <rcombs> anything you need from me?
[08:01:31 CET] <uu8> so, I can't audit the part of the code I am interested in
[08:47:08 CET] <flux> uu8, so have you looked into gdb and threaded debugging? although disabling threading at compile time might be a better alternative.
[08:49:41 CET] <wm4> you can just use -threads 1 if you really think that's the problem
[10:21:06 CET] <cone-345> ffmpeg 03wm4 07master:fcfc78cbabb6: aacdec: do not mutate input packet metadata
[10:53:35 CET] <wm4> is libfdk-aacenc still relevant for anything?
[10:55:08 CET] <kierank> He-aac encoding
[10:55:25 CET] <wm4> the native encoder doesn't support itß
[10:55:29 CET] <wm4> ?
[10:59:19 CET] <JEEB> wm4: yea
[10:59:37 CET] <JEEB> that said I've not really used HE-AAC for much
[10:59:45 CET] <JEEB> although that's probably due to not doing radio yet
[10:59:57 CET] <JEEB> (that said for radio I might just bite the bullet and do opus)
[11:00:01 CET] <wm4> yeah, who even wants HE
[11:00:11 CET] <kierank> Broadcast...
[11:00:28 CET] <wbs> isn't it kinda useful for low-bitrate things?
[11:00:31 CET] <JEEB> yes
[11:00:44 CET] <JEEB> it will rape the sound but you can get similar bit rates out of it as low rate opus
[11:01:12 CET] <JEEB> at which point just doing sw decoding of opus in my opinion is a better alternative unless none of the clients can support it
[11:01:48 CET] <kierank> JEEB: I have tried to ask your employer to support it
[11:02:11 CET] <kierank> A couple of years ago
[11:11:50 CET] <JEEB> :D
[11:13:02 CET] <rcombs> have there been listening tests of the current native encoder vs FDK at QuickTime?
[11:13:30 CET] <rcombs> my impression is that it's thought to be on-par with those, but I don't know if there's data to confirm that
[11:14:22 CET] <JEEB> hydrogenaudio kept doing those tests
[11:28:29 CET] <nevcairiel> last i heard some claimed fdk was still better, but not by much
[11:33:29 CET] <furqan> i want to concatenate multiple video with different format into one singe file format
[11:33:46 CET] <furqan> could anyone give me some directions?
[11:34:17 CET] <JEEB> this is a development channel, usage is on #ffmpeg
[11:35:26 CET] <furqan> no, i am using ffmpeg with c++
[11:38:08 CET] <JEEB> that is still usage
[11:38:20 CET] <JEEB> this is for development of the FFmpeg's libraries themselves
[11:38:52 CET] <furqan> ok
[11:38:59 CET] <furqan> i will go there than
[11:39:01 CET] <furqan> thanks
[13:28:48 CET] <adeel1> durandal_1707: so, apprently, the code was correct before. The reason that one picture was showing completely black was that it's color was Black. Yes the alphabet A written in black -__
[13:34:34 CET] <durandal_1707> you need to rush, because another student already did what you need to do
[13:51:25 CET] <adeel1> durandal_1707: I'm having a few issues moving the code to its previous state. Could you please take a look? https://gist.github.com/adl1995/b19bf5bd0d728abc4e1549ba3cd18fa8
[13:56:19 CET] <stevenliu> Hi ,Mark Thompson here?
[13:56:32 CET] <wm4> that's jkqxz
[13:57:38 CET] <stevenliu> [hevc_qsv @ 0x22fe140] Initialized an internal MFX session using hardware accelerated implementation [hevc_qsv @ 0x22fe140] Using the constant bitrate (CBR) ratecontrol method [hevc_qsv @ 0x22fe140] Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode.
[13:57:45 CET] <stevenliu> When i use hevc_qsv
[13:58:08 CET] <stevenliu> avbr and cbr all of them give me this message, is that mean my cpu cannot support hevc?
[13:58:23 CET] <stevenliu> Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz
[13:58:41 CET] <stevenliu> I'm using git clone last commit ffmpeg code
[14:01:07 CET] <jkqxz> Do you have the plugin?
[14:01:28 CET] <stevenliu> ffmpeg_g -v verbose -y -i /home/centos/ffmpeg/10M1080P.mp4 -an -c:v hevc_qsv -load_plugin hevc_hw -b 5M -maxrate 5M -look_ahead 0 out.mp4
[14:02:15 CET] <jkqxz> (I assume it works for you with H.264?)
[14:02:17 CET] <stevenliu> when use hevc_sw it cannot load plugin
[14:02:17 CET] <stevenliu> Could not load the requested plugin: 2fca99749fdb49aeb121a5b63ef568f7
[14:02:37 CET] <jkqxz> Yeah, you only get the software plugin on windows.
[14:02:43 CET] <stevenliu> maybe h264 is soft codec? default
[14:03:03 CET] <wm4> wait what, so it uses hw by default, but the plugin provides a sw encoder?
[14:03:17 CET] <stevenliu> My system is Linux localhost 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[14:04:54 CET] <stevenliu> 30208 root 20 0 1599508 241328 6336 S 669.0 3.1 2:14.26 ffmpeg_g frame= 682 fps= 27 q=-0.0 size= 16154kB time=00:00:26.88 bitrate=4923.1kbits/s speed=1.06x
[14:05:17 CET] <stevenliu> When i run h264_qsv to transcode , the cpu usage is 669%
[14:05:18 CET] <jkqxz> It provides software implementations for some of the codecs, yeah. You have to actively pick hardware.
[14:06:31 CET] <jkqxz> (The choice is at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_qsv.c;h=03244a62f953db14cc85f56b95b2f985de097e7a;hb=HEAD#l674>, you can pick one explicitly by passing the device argument to av_hwdevice_ctx_create().)
[14:07:13 CET] <jkqxz> stevenliu: That sounds like it's always picking software. Does your VAAPI setup work?
[14:08:54 CET] <stevenliu> I don't know how to check if vaapi have been setup work :(
[14:10:11 CET] <jkqxz> Does running ffmpeg like that give you the stderr output from libva saying it loaded iHD_drv_video.so?
[14:10:50 CET] <stevenliu> No,
[14:11:02 CET] <stevenliu> configuration: --enable-libmfx
[14:11:18 CET] <stevenliu> this is my ffmpeg build configure
[14:14:06 CET] <jkqxz> Hmm. Does "./ffmpeg_g -y -c:v h264_qsv -hwaccel qsv -i any_h264_file.mp4 -an -c:v hevc_qsv -load_plugin hevc_hw -b 5M -maxrate 5M out.mp4" do the same thing?
[14:15:19 CET] <stevenliu> rebuilding ffmpeg with configure --enable-libmfx --enable-vaapi
[14:16:08 CET] <stevenliu> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/facebook.mp4': Metadata: major_brand : isom minor_version : 1 compatible_brands: isomavc1 creation_time : 2015-02-02T18:19:19.000000Z Duration: 00:45:02.06, start: 0.000000, bitrate: 2708 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x714 [SAR 1:1 DAR 640:357], 2576 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
[14:16:32 CET] <stevenliu> wait
[14:16:37 CET] <stevenliu> let me try it
[14:17:44 CET] <stevenliu> Press [q] to stop, [?] for help [AVHWDeviceContext @ 0x31a79a0] Cannot open X11 display . [AVHWDeviceContext @ 0x31a79a0] Opened VA display via DRM device /dev/dri/renderD128. libva info: VA-API version 0.99.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'iHD' libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so libva info: Found init function __vaDriverInit_0_32 libva info: va
[14:17:49 CET] <jkqxz> Standalone software encode or decode relies on the library to do the hardware setup. The hwaccel setup does it explicitly with the VAAPI or DXVA2 child device via hwcontext, so it might be better. (I think other people have had this problem in #ffmpeg, though I never go to the bottom of why.)
[14:18:00 CET] <stevenliu> [AVHWDeviceContext @ 0x31a79a0] Initialised VAAPI connection: version 0.99 [AVHWDeviceContext @ 0x31a79a0] Matched "16.5.55964-ubit" as known driver "Intel iHD". [AVHWDeviceContext @ 0x2f35ec0] Matched "16.5.55964-ubit" as known driver "Intel iHD".
[14:20:03 CET] <jkqxz> (<https://lists.libav.org/pipermail/libav-devel/2017-March/082788.html> (and the following two patches) are trying to fix that by allowing you to set the device explicitly for the non-hwaccel case.)
[14:22:36 CET] <stevenliu> ok, let me try it, thank you Mark
[14:34:45 CET] <wm4> BBB, ubitux, nevcairiel: would you say disabling merging side data by default needs a major API/ABI bump?
[14:34:50 CET] <wm4> because michaelni argues so
[14:35:25 CET] <BBB> I would say that adding side data merging should require a major bump
[14:35:38 CET] <BBB> if it did, then removing it also needed a major bump
[14:35:45 CET] <BBB> if it didnt, then neither does this
[14:35:56 CET] <adeel1> BBB: are you also mentoring the XPM decoder/encoder project for GSoC?
[14:36:00 CET] <BBB> adeel1: no
[14:36:02 CET] <wm4> BBB: there wasn't even a minor bump, but it was in 2011
[14:36:13 CET] <BBB> wm4: 2011 is not an excuse
[14:36:29 CET] <wm4> BBB: well, apparently the excuse works for michaelni?
[14:36:36 CET] <BBB> lets vote
[14:36:59 CET] <ubitux> wm4: i believe that whatever bad decision happened in the past should not encourage any new one in the present: any api/abi break should be protected
[14:37:13 CET] <wm4> ubitux: ok, but is it an API/ABI break?
[14:37:24 CET] <wm4> especially the claim that it's an ABI break is ridiculous AFAIK
[14:37:30 CET] <wm4> also, API users had 6 years to adapt
[14:37:41 CET] <wm4> (why do I have to wade through this bullshit...)
[14:38:27 CET] <ubitux> i don't know the details of the issue, but figuring out if you're breaking the API or ABI shouldn't be that hard; or is it?
[14:38:52 CET] <ubitux> if it changes the behaviour for the apps, yes it's an API break, if some apps needs recompilation, yes that's an ABI break
[14:39:01 CET] <stevenliu> Thanks @jkqxz, It's work now
[14:39:05 CET] <BBB> its not an abi break by that
[14:39:06 CET] <ubitux> i don't think it's rocket science
[14:39:21 CET] <BBB> as for api, yes, behaviour changes
[14:39:36 CET] <ubitux> well then you have my answer
[14:39:55 CET] <ubitux> which is pretty simple API change = protect it
[14:40:03 CET] <durandal_1707> adeel1: whats so hard? the task is rather trivial
[14:40:13 CET] <wm4> it breaks API users which don't use the API correctly, but only in some minor cases
[14:40:26 CET] <wm4> (side data isn't that common, that's part of the concept)
[14:40:28 CET] <adeel1> durandal_1707: I was getting confused. Let me give it a try again.
[14:41:12 CET] <wm4> ubitux: currently packets from libavformat have AVPacket.side_data unset, even if there's side data... is thia what you expect?
[14:41:15 CET] <wm4> *this
[14:41:49 CET] <ubitux> it doesn't matter what a developer expect: what matters is what current applications do
[14:41:59 CET] <ubitux> is the change going to break some or not?
[14:42:14 CET] <ubitux> did we ever warrant such change?
[14:42:49 CET] <ubitux> am i being unreasonable? i don't understand why there is a debate
[14:43:01 CET] <ubitux> every api change we did was motivated by misdesign from the past
[14:43:04 CET] <wm4> I don't understand why there's a debate either
[14:43:07 CET] <ubitux> why is this an exception now?
[14:43:21 CET] <wm4> the API is that AVPacket.side_data is set if there's side data
[14:43:27 CET] <wm4> this was broken with this merge side data hack
[14:43:29 CET] <wm4> I'm fixing it
[14:43:30 CET] <wm4> that's all
[14:44:31 CET] <adeel1> durandal_1707: does changing data[1] to data[0] make any sense? I ask this because we are accessing 0th index in the height width loop and 1st index in when storing rgba.
[14:45:38 CET] <durandal_1707> adeel1: 1 holds indexes for pal8 and 0 hold palette colors
[14:46:04 CET] <adeel1> durandal_1707: oh, right.
[14:46:06 CET] <durandal_1707> other way around actually
[14:46:28 CET] <wm4> ubitux: also, API users which wanted to work with Libav had to respect side data anyway
[14:46:38 CET] <durandal_1707> this is specific to only pal8 though
[14:48:18 CET] <ubitux> wm4: i don't think libav users are a majority, and i think a fix that change API likely to break apps needs special care for the user
[14:48:30 CET] <ubitux> because we shit on the users 6 years ago means that we should do it again
[14:48:37 CET] <ubitux> doesn't* mean
[14:49:03 CET] <wm4> I'm not talking about shitting on users, but _stopping_ shitting on users
[14:50:34 CET] <RiCON> it's still different behavior so isn't that still an API break?
[14:50:55 CET] <wm4> different behavior is not necessarily an API break
[14:51:42 CET] <wm4> also I wonder what's the purpose of this discussion... if you argue that it will break some API users, then that's going to happen at the next major bump anyway
[14:51:46 CET] <wm4> and without warning
[14:51:48 CET] <wm4> so why delay it
[14:52:00 CET] <wm4> just don't backport it to a stable release
[15:04:34 CET] <iive> imho, the merge functions should be deprecated first
[15:04:46 CET] <iive> and removed/disabled on next major bump
[15:05:03 CET] <iive> just like any API change that could break api users.
[15:07:28 CET] <wm4> they don't need to be removed
[15:15:10 CET] <iive> there is flag to disable them, if the program wants it
[15:26:02 CET] <wm4> iive: I know that
[16:10:05 CET] <BBB> michaelni: why are you arguing with a real, valid, easily addressable review point?
[16:11:22 CET] <BBB> michaelni: just address the review comment as I suggested in my review. this is trivial, quick and makes the code better. why not just do it? why argue
[16:14:49 CET] <durandal_1707> but there must be always oposition for every single ugly thing
[16:15:10 CET] <microchip_> guys, latest git ffmpeg has the stream mapping placed above. Known bug? http://pastebin.com/g4LnwAiH
[16:16:08 CET] <wm4> where's the bug? the first line?
[16:16:46 CET] <microchip_> wm4: stream mapping info used to be just above the encode status info. Now it's before init of libx264 and the other info
[16:17:53 CET] <BtbN> yes, the init order changed, so the output did as well
[16:18:06 CET] <BtbN> Not a bug, the ffmpeg output is in no way standardized
[16:18:12 CET] <microchip_> ic
[16:18:48 CET] <microchip_> looks strange now, tho
[16:28:30 CET] <cone-123> ffmpeg 03wm4 07master:f5da453b068f: concatdec: pass AVFormatContext flags to sub demuxer
[16:28:31 CET] <cone-123> ffmpeg 03wm4 07master:597c6b789efb: hls: pass AVFormatContext flags to sub demuxer
[16:28:51 CET] <ubitux> wm4: yes, having it an next major bump is fine, as long as it's documented (doc/APIChanges, Changelog, self-doc etc)
[16:29:43 CET] <BtbN> microchip_, the input is listed first now. Seems the way more natural order to me?
[16:30:57 CET] <microchip_> BtbN: well, now I have to scroll up to see the stream mapping info and the text "Press [q] to stop, [?] for help". Doesn't feel "right"
[16:31:15 CET] <BtbN> That message has always been there
[16:32:47 CET] <microchip_> i guess i'm used to the old way :)
[16:47:12 CET] <philipl> BtbN: I forget - were you still looking for an opinion from me on the resize/crop patch?
[16:47:15 CET] <philipl> I'm ok with it
[16:47:26 CET] <BtbN> Yeah, specially if I messed up the logic somewhere
[16:47:38 CET] <BtbN> It seems to work fine in my tests
[16:47:38 CET] <philipl> where's the current version?
[16:51:13 CET] <philipl> I can only see Miroslav's original on the list.
[16:51:21 CET] <philipl> Yours is on a github branch I assume?
[16:58:59 CET] <BtbN> philipl, yes, HEAD on my github
[17:00:34 CET] <michaelni> BBB, because your assumtation is wrong, iam not a clown
[17:01:34 CET] <BBB> michaelni: assume for a second that there is no assumption...
[17:01:53 CET] <BBB> michaelni: assume for a second that Im just trying to do a fair, honest review of a patch and I think theres an issue with it
[17:02:51 CET] <michaelni> BBB, iam happy to change it, i just disagree that theres a real issue in the patch
[17:03:07 CET] <BBB> I think youre trying to say that problem was there before the patch also , right?
[17:03:30 CET] <BBB> but hasnt the agreement always been that if we pick up on an issue in a patch review, and it is trivially addressed, that thats OK to address in the same patch cycle?
[17:03:46 CET] <BBB> for the benefit of making the code better overall at virtually no cost to anyone?
[17:06:18 CET] <michaelni> BBB you speak about a memory issue "You know very well that this makes the memory issue go away", there is no memory issue in this testcase, its a timeout, taing too much time
[17:06:47 CET] <BBB> fine, call it a MC issue then
[17:06:55 CET] <BBB> you understand the issue Im pointing out right?
[17:06:58 CET] <BBB> or, rather
[17:07:06 CET] <BBB> do you agree the issue Im pointing out exists?
[17:07:37 CET] <michaelni> BBB, i think i can guess what you mean but i do not know if such a issue exists or not
[17:08:20 CET] <michaelni> i assumed there was a "check "somewhere preventing reference frames to missmatch the current frames resolution
[17:09:16 CET] <BBB> I dont see such a check in vp56_render_mb()
[17:09:32 CET] <BBB> and vp56_conceal_mb() litrally just derives a MV and calls render()
[17:10:32 CET] <michaelni> I see checks for VP56_SIZE_CHANGE which run av_frame_unref()
[17:10:52 CET] <michaelni> i dumbly assume these kill reference frames on a resoltion change
[17:10:54 CET] <BBB> Im also frowning @ if (s->mb_width > 1000 || s->mb_height > 1000) { error }
[17:12:06 CET] <michaelni> that seems there since 2006 and the initial implementation it seems
[17:14:49 CET] <BBB> why is have_undamaged_frame never unset?
[17:16:04 CET] <BBB> if you unset have_undamaged_frame in size_change, doesnt that fix the issue then?
[17:16:17 CET] <michaelni> it should
[17:16:32 CET] <BBB> sounds nicer?
[17:16:35 CET] <michaelni> i l try that, that would be simpler
[17:16:50 CET] <michaelni> and nicer, yes
[17:18:51 CET] <BBB> ok, I think that addresses my issue also, so no other comments
[17:18:57 CET] <BBB> (from me at least)
[17:19:13 CET] <michaelni> great, ill post a patch once i tested it
[17:34:26 CET] <cone-123> ffmpeg 03wm4 07master:f940492bb241: avcodec: clarify some decoding/encoding API details
[17:37:37 CET] <wm4> fritsch: I hope this commit makes it clearer ^
[18:09:50 CET] <cone-123> ffmpeg 03James Almer 07master:58eb0f57f670: avformat/matroskaenc: add support for Spherical Video elements
[18:28:55 CET] <BBB> atomnuker: do you want to guide rajesh through the qualification task also? then Ill take care of the other guy (mirage)
[18:30:43 CET] <BBB> Gramner: so how do you deal with avx laning in palignr for directional intra prediction?
[18:30:50 CET] <BBB> (or pshufb)
[18:31:11 CET] <BBB> it seems to me that laning totally destroys the use of palignr :-/
[18:38:34 CET] <philipl> BtbN: looks alrighy.
[18:38:54 CET] <BtbN> good, thanks. I'll just go ahead and push.
[18:39:36 CET] <BtbN> hm, if configure would be fast on cygwin, this would be so nice for building
[18:39:50 CET] <BtbN> make is down to less than one minute, but configure...
[18:45:47 CET] <AreaScout> Hi all, if i use FFmpeg > then 2.8 FF_THREAD_FRAME doesn't look to use all my cores on decoding, with <= 2.8 everything is ok, did i miss some API changes in the new versions, is it different to handle ?
[18:46:12 CET] <AreaScout> code is here: https://github.com/AreaScout/moonlight-embedded/blob/master/src/video/ffmpeg.c
[18:47:04 CET] <AreaScout> and codec is h264
[18:48:15 CET] <wm4> if nobody knows/replies, it'd be good if you could bisect it
[18:48:32 CET] <BtbN> AreaScout, did the speed decrease, or just the CPU usage?
[18:49:48 CET] <AreaScout> speed decrease and the cause was less core balance i think
[18:51:46 CET] <BtbN> have you tested master?
[18:53:36 CET] <AreaScout> yes i am much faster then master because they doesn't use opengles2 on SDL2 like my hardware does and they use slices, and slices are in the case of my hardware much slower
[18:54:07 CET] <BtbN> what?
[18:55:42 CET] <AreaScout> master uses slice threading and this is slower on my single board computer, well it was now everything higher then 2.8 is also slow
[18:56:10 CET] <AreaScout> i use frame threading
[18:57:09 CET] <AreaScout> sorry you mean ffmpeg master and i thought you mean moonlight-embedded master ^^ :D
[18:57:26 CET] <AreaScout> well yes i tried FFmpeg master also
[18:57:53 CET] <wm4> is there slice rendering involved?
[18:58:08 CET] <wm4> (via the draw_horiz_band or whatever callback)
[18:58:16 CET] <AreaScout> yes but on a lower level
[18:58:26 CET] <wm4> huh, meaning?
[18:58:31 CET] <AreaScout> the GPU driver does
[18:58:44 CET] <AreaScout> but i can feat the driver only with full frames
[18:59:05 CET] <AreaScout> thats the reason i do frame threading
[19:00:47 CET] <AreaScout> frame threading looks like this with 2.8 http://www.areascout.at/IMG_1364.PNG and everything higher then 2.8 looks like this https://www.areascout.at/IMG_1365.PNG
[19:00:55 CET] <adeel1> durandal_1707: I've tried manipulating the data array, but the decoded image still displays distotred. Could you please take a look?
[19:02:30 CET] <AreaScout> i have to explain that core 5-8 is a separate CPU A15 and core 1-4 is CPU A7
[19:02:49 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/b19bf5bd0d728abc4e1549ba3cd18fa8
[19:03:58 CET] <AreaScout> on the first picture FFmpeg runs on the second CPU (A15) well balanced
[19:04:21 CET] <AreaScout> on the second also but badly balanced
[19:08:43 CET] <cone-123> ffmpeg 03Timo Rothenpieler 07master:5cd3cd5b6872: avcodec/cuvid: add support for cropping/resizing
[19:09:26 CET] <durandal_1707> adeel1: how distorted?
[19:09:46 CET] <adeel1> durandal_1707: I get purple boundries.
[19:10:01 CET] <adeel1> durandal_1707: at one point I got the full image, but I changed some code and it broke.
[19:10:07 CET] <durandal_1707> change order of rgba entries in first for loop
[19:10:49 CET] <adeel1> durandal_1707: yes, already tried that. It only changes the colour of the distored image.
[19:13:22 CET] <atomnuker> BBB: sure, but neither of those have CC'd me in any emails
[19:13:42 CET] <BBB> rajesh has
[19:14:03 CET] <BBB> emails is from 6 days ago
[19:14:03 CET] <atomnuker> since you ran out of qualification tasks what do you plan to give mirage?
[19:14:20 CET] <BBB> maybe something avx2 in vp8?
[19:14:37 CET] <atomnuker> that'd be cool
[19:14:50 CET] <BBB> also mildly useless
[19:14:55 CET] <BBB> but I guess its the idea that counts at this point
[19:15:36 CET] <durandal_1707> adeel1: it happens with all images?
[19:15:40 CET] <BBB> if you want to search your inbox, the name of the student is Rajesh kumar Sahu
[19:15:43 CET] <atomnuker> VP8 is massively used still and doesn't have any hwaccel
[19:15:44 CET] <BBB> he CCed you
[19:15:49 CET] <atomnuker> (yep, I found it)
[19:15:51 CET] <BBB> cool
[19:15:57 CET] <BBB> what will you give him as a qual task?
[19:16:21 CET] <atomnuker> I think a forward haar transform for the vc2 encoder
[19:16:49 CET] <adeel1> durandal_1707: for one I get completely black (this might be because the actual image is black), and for the other I get purple boundaries as I mentioned above.
[19:17:14 CET] <durandal_1707> and others?
[19:17:37 CET] <BBB> atomnuker: cool
[19:17:48 CET] <durandal_1707> give link to them
[19:22:18 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/793ee47bdfd6bf4307e63e20ba65c78d (distorted), https://github.com/ifwe/wx/blob/master/samples/sample.xpm (black)
[19:31:43 CET] <durandal_1707> adeel1: make colors name first character uppercase
[19:31:50 CET] <durandal_1707> and try again
[19:34:54 CET] <adeel1> durandal_1707: I have changed "h c #ffffff" to "H c #ffffff", (and remaining), but still same issue
[19:36:51 CET] <durandal_1707> not that
[19:37:08 CET] <durandal_1707> thats not color name
[19:44:22 CET] <adeel1> durandal_1707: Is this it #8c94bd? <- that's the value, I think.
[19:44:49 CET] <durandal_1707> not that
[19:45:05 CET] <durandal_1707> name like red green....
[19:47:16 CET] <adeel1> durandal_1707: but that is only in parseutils.c file and first char is already uppercase
[19:49:53 CET] <durandal_1707> no
[19:50:04 CET] <durandal_1707> in xpm files
[19:50:24 CET] <wm4> michaelni: so is that ffmpeg.c/ffprobe.c patch agreeable?
[19:50:53 CET] <adeel1> durandal_1707: cant find color name in xpm file
[19:51:24 CET] <adeel1> wait
[19:51:48 CET] <adeel1> color names are only define in one xpm file (the github link)
[19:51:52 CET] <adeel1> defined*
[19:55:02 CET] <adeel1> durandal_1707: not getting any output: console shows this nan M-V: -0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
[19:55:29 CET] <durandal_1707> with window?
[20:00:49 CET] <adeel1> durandal_1707: no, not getting any window either
[20:01:24 CET] <durandal_1707> then debug where it hangs
[20:02:15 CET] <adeel1> durandal_1707: not sure how that's done.
[20:02:33 CET] <durandal_1707> learn
[20:05:23 CET] <adeel1> durandal_1707: would I have to make a debug version explicitly?
[20:05:57 CET] <durandal_1707> code is simple add printfs
[20:21:04 CET] <michaelni> wm4, please give me and others some time to look at and test it, you just posted it a few hours ago
[20:30:46 CET] <adeel1> durandal_1707: I have added a TEST(i) output at the beggining of each func call and they all seem to get called.
[20:31:12 CET] <durandal_1707> and loops?
[20:35:39 CET] <adeel1> durandal_1707: just added printf to them. it seems the inner for loop breaks gets stuck at j = 5
[20:52:37 CET] <durandal_1707> adeel1: inspect why
[21:07:14 CET] <BBB> Im starting to get the hang of avx2, the magic of ignoring lanes is in using vperm2i128 sparsely and correctly
[21:07:25 CET] <BBB> if only they documented this better
[21:07:44 CET] <BtbN> You happen to know some tool to bench avx and avx2 stuff?
[21:07:55 CET] <BtbN> Want to know what this 1800X is actually capable of with them
[21:08:20 CET] <jamrial> BtbN: use ffmpeg's checkasm
[21:08:45 CET] <jamrial> see if the avx/avx2 functions are faster or not than the <=sse4 ones
[21:09:19 CET] <BtbN> Is it built by default?
[21:09:24 CET] <jamrial> yes
[21:09:36 CET] <JEEB> too bad ryzen didn't have ECC
[21:09:37 CET] <jamrial> bah, as part of fate
[21:09:41 CET] <BtbN> JEEB, it does.
[21:09:46 CET] <BtbN> And some boards even support it
[21:09:58 CET] <BtbN> Or don't you mean ECC RAM?
[21:09:58 CET] <jamrial> use make checkasm to build it
[21:10:03 CET] <jamrial> then run it with --bench
[21:10:06 CET] <JEEB> BtbN: I hear the board manuf that listed ECC support meant the physical hardware, not ECC RAM in that mode
[21:10:11 CET] <jamrial> and afaik, Gramner was right. Ryzen has 128bit simd, so avx/avx2 ymm instructions will be slower than on intel
[21:10:15 CET] <TD-Linux> JEEB, apparently the asrock ones support real ECC
[21:10:28 CET] <BtbN> JEEB, the ASUS X370-Pro one claims to support it as well
[21:10:45 CET] <JEEB> TD-Linux: apparently someone actually asked and told that he got a reply from asrock saying it doesn't actually use the ECC functionality
[21:11:03 CET] <TD-Linux> JEEB, that was from a different vendor
[21:11:03 CET] <BtbN> So they all just support plugging them in there, but don't use the ECC features...?
[21:11:40 CET] <TD-Linux> yeah it's the asus one that ignores ECC https://www.asus.com/us/Motherboards/PRIME-X370-PRO/specifications/
[21:12:54 CET] <JEEB> right, https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/def6vs2/
[21:12:57 CET] <JEEB> AMD answer
[21:13:19 CET] <JEEB> so yes, technically the boards could support full ECC
[21:14:18 CET] <wm4> what kind of bullshit is this
[21:14:45 CET] <BtbN> It's a consumer CPU. But AMD was kind enough to not disable ECC.
[21:14:58 CET] <BtbN> So it's up to BIOS/Software support from the Mainboard manufacturers.
[21:15:04 CET] <BtbN> And from the looks of it, most opted to not support it
[21:16:24 CET] <jamrial> BBB: avx512 will fortunately add instructions to properly shuffle across lanes. things like vpermb and vpermi2b (essentially pshufb on all 64 bytes), the latter allowing you to emulate palignr since it takes two regs as input
[21:16:37 CET] <BBB> oh nice
[21:16:39 CET] <jamrial> but who knows when cannonlake will show up, and if it will have avx512 on desktop
[21:16:55 CET] <BBB> but so actually for things like directional intra pred, it seems palignr actually works just fine in avx2
[21:17:19 CET] <BBB> youre a little more restricted but once you get how braindead it is, you can hack your way around it and it works without any slowdown or extra shuffling
[21:17:30 CET] <BBB> so you dont have 5 ways to write it, just 2
[21:17:33 CET] <BBB> but thats still >0
[21:31:02 CET] <BtbN> I should probably use gcc 6.3 for ryzen
[21:34:59 CET] <BtbN> jamrial, https://bpaste.net/show/e043f90216f5
[21:35:10 CET] <BtbN> I can't find a test where it compares sse4 vs. avx(2)
[21:35:52 CET] <BtbN> Oh
[21:36:03 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_c: 3035.4
[21:36:03 CET] <BtbN> vp9_avg_8tap_smooth_16h_10bpp_avx2 is like twice as fast on sse2 than avx2
[21:36:04 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_sse2: 667.0
[21:36:05 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_ssse3: 489.3
[21:36:06 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_avx: 511.2
[21:36:07 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_avx2: 461.8
[21:36:07 CET] <BBB> that seems logical
[21:36:29 CET] <BBB> you probably need a higher number of iterations?
[21:37:28 CET] <BBB> the numbers seem fairly random, yes
[21:37:35 CET] <BtbN> How do I increase them?
[21:37:47 CET] <BtbN> And should I pin it to a single CPU?
[21:37:56 CET] <BBB> BENCH_RUNS
[21:37:59 CET] <BBB> in checkasm.h
[21:38:21 CET] <BtbN> so go to like a million instead off 1k?
[21:39:23 CET] <BtbN> the Windows scheduler has some issues with Ryzen atm.
[21:39:30 CET] <BtbN> so some randomness might come from that
[21:40:06 CET] <BBB> if I change it to 5000:
[21:40:07 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_c: 20441.9
[21:40:07 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_sse2: 2635.6
[21:40:08 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_avx2: 1405.7
[21:40:23 CET] <BBB> or:
[21:40:25 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_c: 13050.1
[21:40:26 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_sse2: 1062.1
[21:40:27 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_ssse3: 570.1
[21:40:28 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_avx2: 280.4
[21:41:07 CET] <BBB> I dont think a million will ever finish TBH
[21:41:18 CET] <BBB> but maybe you have a massively awesome super-computer
[21:41:22 CET] <BtbN> yeah, I noticed, went for 10k now
[21:51:10 CET] <BtbN> https://bpaste.net/show/4f662b54f022 that's with 10k
[21:51:31 CET] <BtbN> yeah, that seems more reasonable
[22:03:25 CET] <TD-Linux> at least it looks like it's not slower, so you won't have to detect ryzen specially
[22:05:46 CET] <BtbN> Windows still has massive issues with the NUMA like architecture of Ryzen
[22:05:56 CET] <BtbN> And with the asymetric SMT
[22:06:53 CET] <jamrial> many of the ymm functions are slower than their xmm/sse counterparts, but apparently not nearly as bad as it was with bulldozer
[22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_8bpp_ssse3: 821.0
[22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_8bpp_avx2: 856.4
[22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_10bpp_sse2: 1620.3
[22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_10bpp_avx2: 1536.8
[22:10:22 CET] <jamrial> weird
[22:12:26 CET] <BtbN> I blame the scheduler
[22:18:30 CET] <JEEB> oh, cool
[22:18:36 CET] <JEEB> someone had already started work on bink2
[22:18:38 CET] <JEEB> https://wiki.multimedia.cx/index.php/Bink_Video_2
[22:30:59 CET] <durandal_170> JEEB: thats old
[22:33:40 CET] <JEEB> durandal_170: true, only noticed now tho
[22:45:50 CET] <michaelni> atana, did you implement the window overlap ?
[23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:58dd25f8adb1: avcodec/mpegaudiodec_template: Check for negative e
[23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:800d02abe041: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127
[23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:222c9f031de3: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1
[23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:e2a4f1a9eb2c: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'
[23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:bac9c03ed932: avcodec/movtextdec: run mov_text_cleanup() before overwriting pointers
[23:44:31 CET] <durandal_170> how to copy avframe contents to another frame?
[23:47:51 CET] <DHE> av_frame_ref() if you're doing it without modifying the frame(s)
[23:58:12 CET] <durandal_170> i need one frame to be untouched from previous state
[23:58:42 CET] <durandal_170> but another frame is going to change
[00:00:00 CET] --- Fri Mar 10 2017
More information about the Ffmpeg-devel-irc
mailing list