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

[burek]

[03:08:40 CET] <atomnuker> jamrial: sorry about that, I had a bad week
[03:13:40 CET] <TD-Linux> on a semi related note, if this picture is real then swr is well into potentially audible artifacts :/ http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170306/39906029/attachment.png
[03:14:38 CET] <TD-Linux> so bad as to be actually broken
[03:17:23 CET] <kode54> you may note that the bright orange in the picture is -80 dB
[03:17:58 CET] <kode54> probably fixable by doubling the window size of the resampler
[03:18:14 CET] <kode54> or rather, reducible
[03:18:45 CET] <kode54> my own extremely low latency resamplers have noticeable artifacts approaching -95 dB
[03:18:53 CET] <kode54> if you call that noticeable
[03:18:57 CET] <kode54> visible on a spectrogram
[03:19:16 CET] <TD-Linux> well 96db is 16bit so that should be fine
[03:19:52 CET] <kode54> sox resampler, while bordering on perfect, is not the lowest latency, but LGPL, so it may be possible to make use of it for general purpose
[03:19:57 CET] <TD-Linux> I'm all for removing resamplers, if libswr can be set to produce similar quality it's fine, but it's interesting that it's so broken
[03:20:08 CET] <kode54> my resampler isn't designed for general purpose signal, but rather multi-channel mixing
[03:20:08 CET] <TD-Linux> er not really broken but default settings so bad
[03:20:24 CET] <TD-Linux> speex/opus resampler is quite a bit better by default
[03:29:47 CET] <kode54> appears to use a filter size of 32 samples by default
[03:30:40 CET] <kode54> as does my resampler
[03:30:48 CET] <kode54> or one of them does
[03:31:10 CET] <kode54> it's designed for low latency software mixing in music reproduction
[03:31:28 CET] <kode54> soxr would be better, but also probably harder to make effective use of
[03:32:01 CET] <kode54> never mind that I also have linear interpolation, cubic interpolation, and two zero order hold algorithms to please people who want alternatives
[04:08:43 CET] <kode54> https://gist.github.com/kode54/d4220e418cd479b753c7 that's my most recent resampler, with makefile that runs tests with sox
[04:09:37 CET] <kode54> http://imgur.com/a/SsejT and this is what it generates
[04:10:48 CET] <kode54> you have to admit, it looks significantly better in the top image, which has a spectrum range of 0-96 dB
[11:09:19 CET] <BtbN> wm4, mpv is litterally the only player that does not lag my entire laptop.
[11:10:39 CET] <JEEB> :D
[11:12:10 CET] <kierank> wm4: regarding the thread
[11:12:12 CET] <kierank> safe patch
[11:12:20 CET] <kierank> isn't the idea all the codecs themselves should be threadd safe
[11:12:23 CET] <kierank> not the initialiser?
[11:12:33 CET] <JEEB> I thought that's how it began at least
[11:12:45 CET] <wm4> BtbN: interesting
[11:12:45 CET] <kierank> because that seems like a massive hack
[11:12:59 CET] <wm4> kierank: codec init safety != codec list safety
[11:13:17 CET] <kierank> ok
[11:13:27 CET] <wm4> codec inits are not really covered by this (although there's this silly init_static thing that only a few codecs use)
[11:14:04 CET] <wm4> 8 codecs
[11:14:11 CET] <wm4> nice headache
[11:14:27 CET] <kierank> derek send patches iirc
[11:14:28 CET] <kierank> sent*
[11:14:35 CET] <wm4> yeah
[11:14:44 CET] <wm4> e.g. X264_init_static mutates AVCodec.pix_fmts
[11:14:52 CET] <wm4> this can't be fixed
[11:15:23 CET] <wm4> would probably be best to add some sort of dynamic API to determine codec parameters
[11:15:31 CET] <JEEB> yea
[11:18:44 CET] <wm4> x264, x265, vpxenc, vpxdec set AVCodec.pix_fmts, openjpegdec sets an experimental flag depending on the library version (wtf), jpeg2000, wmavoice, qdmc init static tables
[11:25:16 CET] <nevcairiel> at  least static table init could be moved elsewhere
[11:25:29 CET] <nevcairiel> the first couple that set pixfmt based on external library version seems like it cant really be avoided
[11:25:38 CET] <nevcairiel> or needs re-design
[11:31:32 CET] <BtbN> wm4, like, the next best "player" is MS Edge, which still eats 30% CPU. Then MPC-HC with 30-40%, and VLC which can't even keep up, fully using the CPU
[11:31:42 CET] <BtbN> mpv is sitting at ~5% right now
[11:31:55 CET] <ismail> BtbN: which vo?
[11:32:05 CET] <BtbN> No idea, the default, didn't touch any settings
[11:32:09 CET] <ismail> oh ok
[11:32:24 CET] <ismail> on Windows I had similar good experience with dxva
[11:32:30 CET] <BtbN> Has to be something DXVA accelerated I assume
[11:32:34 CET] <ismail> yeah
[11:32:42 CET] <BtbN> No idea how else it would achive that
[11:32:52 CET] <BtbN> Makes you wonder what all the other players are doing
[11:32:53 CET] <wm4> BtbN: mpv doesn't enable dxva by default, though
[11:33:54 CET] <wm4> ismail: it uses opengl via angle by default (with custom swapchain code)
[11:34:08 CET] <nevcairiel> sounds to me like your laptop is having issues if playing some 720p with hwaccel lags it
[11:35:49 CET] <j-b> end of cinepack drama.
[11:36:04 CET] <JEEB> and good riddance
[11:36:31 CET] <ismail> wm4: yeah I manually switched to dxva and < %10 cpu for 2160p h264 decoding
[11:37:43 CET] <wm4> j-b: not sure why it's "APPLY MY PATCHES OR DIE", but ok
[11:38:01 CET] <j-b> wm4: BECAUSE DIE DIE DIE, YOU HERETIC
[11:38:08 CET] <wm4> ismail: try hwdec=auto (that would use d3d11va)
[11:38:19 CET] <ismail> wm4: will try, thanks!
[12:21:13 CET] <cone-310> ffmpeg 03Aman Gupta 07master:b6eaa3928e19: avcodec/h264, videotoolbox: fix crash after VT decoder fails
[12:34:19 CET] <nevcairiel> 3 people respond, and that guy only reads carls confused reply? way to go =p
[12:34:42 CET] <wm4> carl being "helpful" again
[13:22:30 CET] <kierank> durandal_1707: did you see libav patches to pixlet
[13:23:14 CET] <durandal_1707> yes i did
[13:38:38 CET] <iive> nevcairiel: what are you talking about?
[14:04:53 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:a6b1180e3909: avcodec/pixlet: fix architecture-dependent code and values
[14:26:04 CET] <durandal_1707> iive: he is talking about confused carl
[14:29:29 CET] <iive> durandal_1707:  your reply contained 0bit of useful information. it just repeated your rants from above.
[14:30:51 CET] <durandal_1707> iive: see ml and patch about h2645
[14:30:55 CET] <iive> ok, not your rants
[14:31:22 CET] <iive> ok, at least now i know where and what. thank you.
[14:47:37 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:e85e8408802d: avcodec/allcodecs: make avcodec_register_all thread safe
[14:47:38 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:49635f0a4636: avfilter/allformats: make av_register_all thread safe
[14:47:39 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:af7010ad0557: avfilter/allfilters: make avfilter_register_all thread safe
[14:47:40 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:776f289c0fe8: avdevice/alldevices: make avdevice_register_all thread safe
[15:12:42 CET] <adit> hi
[15:13:33 CET] <adit> I am bent on doing GSoC for this org. As for my vr proficiency is considered, I know quite a bit in that area, so any assistance would be helpful.
[15:13:51 CET] <adit> I also won the google powered hackathon two to three days ago where I made a virtual city.
[15:15:00 CET] <wm4> pick a topic on the ffmpeg gsoc wiki page, contact the mentor for the project you want
[15:15:37 CET] <adit> thank you sir. :D
[15:15:51 CET] <adit> can you give to me the link of the page?
[15:16:25 CET] <wm4> the general website is in the topic, just look for the wiki
[15:17:15 CET] <adit> Yes sir. Thank you so much. :D
[15:18:29 CET] <rcombs> (VR? in ffmpeg?)
[15:19:10 CET] <adit> :P It was having a tag of VR on GSoC's page
[15:19:32 CET] <durandal_1707> topic have only link to code of conduct
[15:20:22 CET] <adit> here https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017
[15:22:03 CET] <durandal_1707> VR stands for Virtual Reality?
[15:22:38 CET] <wm4> jamrial: to be specific, he wouldn't have needed to send a patch?
[15:23:10 CET] <jamrial> wm4: who?
[15:23:22 CET] <jamrial> Faiz?
[15:23:26 CET] <wm4> jamrial: yes
[15:23:39 CET] <jamrial> patch for what? he sent the updated set that you reviewed
[15:24:27 CET] <durandal_1707> reviewing patchset considered harmful
[15:24:30 CET] <wm4> I mean, he could have just pushed straight to master, without even sending the first version to the ML
[15:24:47 CET] <wm4> because it's an unmaintained file
[15:27:42 CET] <jamrial> no, ideally you wouldn't do that. the result would have been the first version without pthreads_once being pushed, which would then probably be replaced once you or someone else mentioned it
[15:28:17 CET] <wm4> well, I thought it's fine to just push changes to unmaintained files
[15:28:29 CET] <adit> durandal_1707: yes
[15:36:32 CET] <jamrial> wm4: it's fine for simple bug fixes, cosmetics and such, but behavior changes or bug fixes that may have more than one solution are IMO better posted to the ml to avoid poinlessly reverting code once people complain or replacing it once people suggest a better solution
[15:37:03 CET] <jamrial> i'm not saying that's what always happens, because i think it sometimes doesn't
[15:37:05 CET] <jamrial> just what i think is ideal
[16:58:44 CET] <BBB> j-b: dude, youre on wikileaks
[16:59:07 CET] <BBB> j-b: thats pretty impressive, congrats :D
[16:59:48 CET] <BBB> relevant quote of the day: To witnesses, the spy appears to be running a program showing videos (e.g VLC) [..]. But while the decoy application is on the screen, the underlaying system is automatically infected and ransacked.
[17:02:07 CET] <j-b> BBB: lolwut?
[17:02:26 CET] <BBB> really true :D
[17:03:09 CET] <BBB> now of course the relevant question is: what video codec do these decoy videos use?
[17:03:21 CET] <durandal_1707> vp13
[17:03:21 CET] <BBB> and if its h264, did they pay the relevant licensing fees?
[17:03:32 CET] <BBB> :D
[17:07:18 CET] <j-b> I'd say dll hijacking
[17:08:11 CET] <j-b> VLC Player Portable
[17:08:44 CET] <bencoh> :D
[17:30:08 CET] <ubitux> mmh, so we have "aspect" option in ffmpeg cli and lavc
[17:30:14 CET] Action: ubitux wonders which one gets set
[17:30:23 CET] <ubitux> also, option looks untested for some reason
[18:01:01 CET] <atana> michaelni, ping
[18:06:51 CET] <michaelni> atana, pong
[18:07:23 CET] <atana> I tried applying hamming window to the data by multiplying the data with window entries.
[18:07:53 CET] <atana> but I guess I did something wrong as now there is no match found
[18:08:36 CET] <michaelni> atana, can you push / or show the code so i can take a look ?
[18:08:50 CET] <atana> I will push the code
[18:09:40 CET] <atana> pushed
[18:18:47 CET] <michaelni> atana, the log2() is incorrect, the window needs to have as many points as the fft, that is if the fft has 1024 points the window needs 1024 points
[18:19:26 CET] <atana> so same as transform size. ok
[18:25:39 CET] <BBB> michaelni: I guess what Im confused about is what the code is doing that is taking so much time if we usually exit the loop (because input buffer = exhausted) after the first MB anyway
[18:27:47 CET] <BBB> michaelni: you have to realize how little information we have, so its hard to discuss this without having a sample. what codec are we talking about here? and why is 0 byte input being converted into (apparently) tons of bitstream inits during (apparently) header parsing time?
[18:29:05 CET] <michaelni> BBB, i think it was vp8 and theres a loop we check only per mb row 
[18:29:30 CET] <BBB> so Im imagining that the width of this sample is really big?
[18:29:53 CET] <BBB> I dont think this makes sense& what if the buffer is 1 byte? it will pass your check but still timeout
[18:29:54 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:1b7ffddb3a99: spherical: Add tiled equirectangular type and projection-specific properties
[18:29:55 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:022b4ea5837b: mov: Export bounds and padding from spherical metadata
[18:29:56 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:bde96422686f: mkv: Export bounds and padding from spherical metadata
[18:30:09 CET] <BBB> the timeout itself needs to be fixed if that is the issue
[18:30:24 CET] <BBB> if that means we need to do that per mb instead of per mb row (for vp8), then maybe thats ok
[18:30:35 CET] <BBB> Im assuming the overhead introduced by a per-mb bitstream-end check is minimal
[18:31:14 CET] <michaelni> i can try to add a per mb check if you prefer (need to check if that works) ?
[18:32:34 CET] <michaelni> are you against the init check or should that go in in addition ? it feels to me that its wrong to init on 0 size
[18:33:24 CET] <BBB> (Im thinking :) )
[18:33:34 CET] <atana> michaelni, 9 failures in this case
[18:34:00 CET] <BBB> I agree its wrong to init on 0-sized data
[18:34:13 CET] <BBB> so its probably ok in that sense
[18:34:31 CET] <michaelni> atana, try to overlap the ffts, that is instead of doing a fft with input from 0..1024 then 1024..2048, ... try 0..1024, 512..1536, ...
[18:34:31 CET] <BBB> but I dont have a very strong opinion on it, since like I said I dont really think it fixes the true issue youre after here
[18:35:24 CET] <BBB> so as long as the per-mb check is there to fix it for the more general case, I guess this patch is OK (unless others object)
[18:35:30 CET] <atana> michaelni, ok
[18:36:15 CET] <BBB> michaelni: please add return value check to vp9.c also
[18:36:25 CET] <BBB> (youre only adding it to vp8.c and vp6.c, not vp9.c)
[18:36:36 CET] <michaelni> ok
[18:43:23 CET] <nevcairiel> interesting fate failure i got, and curious it didnt fail before
[18:44:15 CET] <nevcairiel> fate-mov-spherical-mono dumps the side_data content through ffprobe, which includes the side_data_size field
[18:44:28 CET] <nevcairiel> that particular side data includes size_t fields, which vary in size on different platforms
[18:44:35 CET] <nevcairiel> ie. 32-bit on 32-bit, 64-bit on 64-bit
[18:44:43 CET] <nevcairiel> so logically one might conclude the struct size also varies
[18:45:01 CET] <nevcairiel> but it didnt fail before, and  it does now on vs2017
[18:45:38 CET] <JEEB> funky
[18:45:55 CET] <nevcairiel> maybe they changed default struct packing somewhere
[18:46:02 CET] <nevcairiel> still seems like an easy thing to fail
[18:46:21 CET] <wm4> uh that would change ABIs...
[18:46:29 CET] <nevcairiel> oh wait, that test is new in the patchset from 20 minutes ago, isnt it
[18:46:32 CET] <nevcairiel> fate just didnt catch it
[18:46:45 CET] <wm4> hm yes
[18:47:32 CET] <wm4> (still not sure why we'd use size_t for image dimensions???)
[18:48:17 CET] <nevcairiel> probably some diego arguments or so
[18:48:38 CET] <wm4> I think it was elenril who argued in favor
[18:49:34 CET] <BtbN> So, VC15 releases today?
[18:49:39 CET] <nevcairiel> it did already
[18:49:54 CET] <BtbN> nice, lets see if it updates itself
[18:50:17 CET] <BtbN> yes it does
[18:52:44 CET] <wm4> fate seems to fail on linux 64 bit too
[18:52:52 CET] <wm4> matroska-spherical-mono
[18:53:11 CET] <wm4> seems weird though (missing fields?)
[18:53:33 CET] <nevcairiel> failing on 64-bit sounds weird
[18:54:15 CET] <wm4> could it be that fate updated files have not been uploaded yet or something?
[18:54:28 CET] <nevcairiel> doesnt use external samples
[18:54:32 CET] <nevcairiel> no new ones anyway
[18:54:56 CET] <wm4> kode54: pls fix
[18:54:59 CET] <wm4> err
[18:55:01 CET] <nevcairiel> wrong kod* guy
[18:55:04 CET] <wm4> he isn't here
[18:55:23 CET] <wm4> who pushed those commits?
[18:55:29 CET] <nevcairiel> himself
[18:59:40 CET] <JEEB> i think koda recently posted some fixes for something although that could have been the pixlet thing
[19:01:12 CET] <durandal_1707> i did pixlet commit
[19:02:36 CET] <nevcairiel> it appears libav doesnt print side data size
[19:02:49 CET] <nevcairiel> maybe we should remove that, it seems fragile  with struct alignment and whatnot
[19:02:58 CET] <nevcairiel> (and largely irrelevant info)
[19:04:38 CET] <durandal_1707> yeah
[19:09:46 CET] <BtbN> Hm, after updating it, it now wants a product key. Should have thought about that.
[19:09:52 CET] <BtbN> At least the commandline tools still seem to work.
[19:09:56 CET] <nevcairiel> shouldve  used community
[19:09:59 CET] <nevcairiel> its free
[19:10:11 CET] <BtbN> I get a key via university, just have to wait until they update
[19:10:27 CET] <BtbN> They still list the RC there
[19:10:39 CET] <nevcairiel> the versions contain the same things anyway, so unless you use it professionally
[19:11:38 CET] <BtbN> I downloaded it via university mirrors, and that gives you Enterprise.
[19:12:44 CET] <BtbN> Got a 30 day grace period, and by then MS Imagine should be updated.
[19:13:44 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:5098a6f6275a: avcodec/vp8: remove redundant check
[19:16:28 CET] <adeel1> durandal_1707: I've changed this:         *(p->data[1] + i * 4    ) = rgba[2]; to this:         *(*(x->frame->data[1] + i * 4    )) = rgba[2];
[19:16:55 CET] <adeel1> durandal_1707: but there's still a seg fault
[19:18:04 CET] <durandal_1707> frame is null
[19:18:15 CET] <BtbN> Is using sscanf fine? Or is there an av_* function for it?
[19:20:55 CET] <durandal_1707> adeel1: use p->data[1][i * 4]....
[19:21:15 CET] <adeel1> okay
[19:25:15 CET] <adeel1> durandal_1707: I'm using this now: (p->data[1][i * 4    ]) = rgba[0]; but still same issue
[19:27:17 CET] <durandal_1707> adeel1: give full diff
[19:29:10 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/30b9693822aa18dc627384d19a3b1986
[19:34:07 CET] <durandal_1707> adeel1: remove commented out code,  will you
[19:34:18 CET] <adeel1> oaky
[19:34:22 CET] <adeel1> okay*
[19:34:32 CET] <durandal_1707> you use x->frame bellow, use p instead
[19:34:40 CET] <durandal_1707> remove printf
[19:35:24 CET] <durandal_1707> remove frame from XPMDecContext struct
[19:39:09 CET] <adeel1> durandal_1707: yea, it worked :D but only for 1 example. still seg faults on the other one
[19:40:22 CET] <durandal_1707> adeel1: give link to that xpm sample
[19:41:14 CET] <adeel1> durandal_1707: It fails on this one: https://github.com/ifwe/wx/blob/master/samples/sample.xpm
[19:42:42 CET] <durandal_1707> adeel1: what error you get?
[19:43:16 CET] <adeel1>  17167 segmentation fault (core dumped)
[19:45:10 CET] <durandal_1707> adeel1: give full diff of your current work
[19:46:18 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/b952004d435f5f1a991a9c1e8f839c7a
[19:56:07 CET] <durandal_1707> adeel1: the code looks wrong, p->data[0] should be filled with indexes directly, not with pixels stuff
[20:04:22 CET] <adeel1> durandal_1707: I'm not sure if I follow. I've changed p->data[0] + i * p->linesize[0]; to p->data[0] + i; but this only changed the dispaly location for working examples
[20:04:26 CET] <adeel1> example*
[20:08:05 CET] <durandal_1707> adeel1: that was good code
[20:08:56 CET] <durandal_1707> adeel1: you need to change to use ascii2index directly
[20:11:10 CET] <adeel1> durandal_1707: so I should remove the ascii2index function and use it inline where required?
[20:12:37 CET] <durandal_1707> adeel1: nope, you should remove pixels array usage just before it
[20:16:02 CET] <llogan> JEEB: would you be willing to add a message saying something like, "x264ops has been deprecated. Use x264-params instead"? I think that should address the "deprecated" concern.
[20:17:47 CET] <JEEB> I can do such a patch, sure
[20:17:57 CET] <adeel1> durandal_1707: okay, I've change x->pixels[ascii2index(ptr, cpp)] to ascii2index(ptr, cpp), the seg fault is gone now but I get:  nan M-V:    nan fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0    and there's not output
[20:18:02 CET] <llogan> thanks
[20:19:18 CET] <BBB> michaelni: patches are OK I think (do you want a reply on ML?)
[20:19:30 CET] <durandal_1707> adeel1: show your code
[20:21:03 CET] <michaelni> BBB, no need, ill apply
[20:24:45 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/9c3e87596d3460ac4f68719e45c25e6b
[20:51:55 CET] <durandal_1707> adeel1: so it shows black?
[21:45:29 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:55d7371fe0c4: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
[21:45:30 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:1afd24696020: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter()
[21:52:09 CET] <JEEB> nevcairiel: did VS2017 work for FFmpeg?
[21:58:21 CET] <nevcairiel> yes
[22:06:46 CET] <BtbN> Seems like a really good update
[22:06:53 CET] <BtbN> the new installer is also nice
[22:08:30 CET] <JEEB> man, I should really reinstall this machine at some point
[22:08:37 CET] <JEEB> > MSVS 2010, 2013, 2015
[22:09:08 CET] <BtbN> Just uninstall the old ones?
[22:09:45 CET] <JEEB> I have really bad recollection of old MSVS uninstallers
[22:55:28 CET] <jamrial> koda addressed my reviews for the version he pushed on libav but not for the one he pushed here :p
[22:56:17 CET] <jamrial> not like it would have changed the fate failures anyway. but he did push broken cubemap parsing code for mov
[23:43:34 CET] <knight___> where is AVFrame defined?
[23:44:33 CET] <nevcairiel> libavutil/frame.h
[23:45:24 CET] <knight___> can you explain me how sound data is stored in frames?
[23:48:12 CET] <durandal_1707> its stored as array
[23:49:34 CET] <knight___> is there any place I can read about it?
[23:49:38 CET] <durandal_1707> looking at any code in lavc and lavfi could show you how it is manipulated
[23:51:48 CET] <knight___> what is lavc?
[23:53:23 CET] <llogan> libavcodec
[23:56:03 CET] <llogan> damn...made the mistake of clicking "rebuild folder tree" in claws-mail. now it will be 14 years before i can use it again.
[00:00:00 CET] --- Wed Mar  8 2017