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

[burek]

[01:31:33 CET] <cone-179> ffmpeg 03Mark Thompson 07master:a1e83a2f904b: vaapi_vp8: Use VP8_MAX_QUANT instead of magic number
[01:46:18 CET] <cone-179> ffmpeg 03Andreas Cadhalpun 07master:783b350b2e49: mpegaudiodec_template: fix leaking fdsp for mp3on4float
[01:46:19 CET] <cone-179> ffmpeg 03Andreas Cadhalpun 07master:9ccc6cecd2d0: wmaprodec: fix leaking fdsp on init failure
[02:48:09 CET] <kierank> atomnuker: do you have an xps13 or 15?
[02:48:20 CET] <kierank> and how much did you pay approx?
[02:59:30 CET] <atomnuker> 15, 1200ish
[02:59:43 CET] <kierank> atomnuker: what specs
[02:59:44 CET] <kierank> ?
[03:00:39 CET] <kierank> oh you bought pre-brexit...
[03:00:51 CET] <kierank> so i don't think pricing can be comparable
[03:00:53 CET] <atomnuker> also had an 32gb ssd and a 1tb hdd
[03:01:18 CET] <atomnuker> because it was cheaper and because I spend 100ish for a 256 samsung 950
[03:02:40 CET] <kierank> I'm thinking of just going max specs because I'll end up using it for 5 years like this one
[03:02:46 CET] <kierank> this one at the time was nearly max specs
[03:03:19 CET] <kierank> on a separate note https://s3-us-west-1.amazonaws.com/disneyresearch/wp-content/uploads/20170215220933/Quasistatic-Cavity-Resonance-for-Ubiquitous-Wireless-Power-Transfer-Paper.pdf
[04:01:50 CET] <llogan> wm4: he shared it https://github.com/ajdlinux/PRBot
[04:04:44 CET] <llogan> maybe i'll do something with it over the weekend unless someone else is interested
[04:05:23 CET] <llogan> to let BtbN retire from copy 'n paste duty
[06:24:25 CET] <debianuser> Hello. Trying to help xtina#ffmpeg: debugging 99% CPU usage of `ffmpeg -f alsa -acodec pcm_s32le -i michooks -f  null -` while `arecord -r48000 -c2 -fS32_LE --period-size=16384 --buffer-size=65536 -Dmic_sv -twav /dev/null` (same period/buffer size as ffmpeg) uses ~0% CPU. Trying to understand what consumes all the CPU...
[06:24:37 CET] <debianuser> Ffmpeg opens alsa in NONBLOCK mode, so .read_packet() eventually returns AVERROR(EAGAIN). What happens next? How does ffmpeg wait for next packet? It doesn't use snd_pcm_wait(), doesn't use file descriptors polling, then what does it do when it gets AVERROR(EAGAIN)? Can you point to the right source fragment?
[07:15:46 CET] <debianuser> Current guess: http://pastebin.com/FG60uzfU - this is the output of (for i in `seq -w 100`; do time sleep .$i; done) command. Sleep times look weird. Does ffmpeg sleeps while waiting for data? What sleeps does it use? Is there a way to test what time those sleeps actually sleep for?
[07:26:38 CET] <wm4> "demuxers" returning AVERROR(EAGAIN) is just broken
[07:27:02 CET] <wm4> ffmpeg.c actually calls av_usleep(10000); in this case
[07:27:10 CET] <wm4> (which is completely nonsense if you ask me)
[07:31:00 CET] <nevcairiel> they only do that when you set nonblock
[07:31:08 CET] <nevcairiel> which is probably expected
[08:11:44 CET] <nevcairiel> fun, somehow mingw-w64 managed to break sqrt() slightly, it fails in some tests
[08:13:32 CET] <nevcairiel> probably the commit that claims "sqrt: Fix NaN propagation for IEEE Std 754-2008"
[08:14:38 CET] <nevcairiel> j-b: does mingw-w64 have a bug tracker thats actually being monitored, or  where do i send such things?
[08:15:44 CET] <wm4> where does mingw development happen anyway
[08:15:46 CET] <nevcairiel> apparently its already on their bug tracker
[08:16:38 CET] <nevcairiel> since last year, not that this prompted any fixes =p
[08:19:35 CET] <nevcairiel> https://sourceforge.net/p/mingw-w64/bugs/567/
[08:32:49 CET] <j-b> nevcairiel: yes, more or less.
[08:32:53 CET] <j-b> nevcairiel: any specific issue?
[08:40:28 CET] <nevcairiel> see the one i linked
[08:40:37 CET] <nevcairiel> makes ffmpeg fate go yellow right now :)
[08:41:13 CET] <nevcairiel> i'll probably put it back to 4.x later so new issues dont get hidden by it
[10:38:10 CET] <cone-972> ffmpeg 03Carl Eugen Hoyos 07master:1d54be215309: lavc/avpacket: Initialize a variable in error path.
[10:47:17 CET] <cone-972> ffmpeg 03Carl Eugen Hoyos 07release/2.8:92d8106fa610: lavc/avpacket: Initialize a variable in error path.
[10:47:18 CET] <cone-972> ffmpeg 03Carl Eugen Hoyos 07release/3.0:9b6af4561b07: lavc/avpacket: Initialize a variable in error path.
[10:47:19 CET] <cone-972> ffmpeg 03Carl Eugen Hoyos 07release/3.1:401a3ae2cb33: lavc/avpacket: Initialize a variable in error path.
[10:47:20 CET] <cone-972> ffmpeg 03Carl Eugen Hoyos 07release/3.2:5c524e651f4c: lavc/avpacket: Initialize a variable in error path.
[10:48:22 CET] <cone-972> ffmpeg 03Paul B Mahol 07master:1a71df9bac4b: avcodec/fmvc: fix decoding of odd size videos
[11:31:48 CET] <cone-972> ffmpeg 03Felicia 07master:fcf3e06fe406: libopus: decode ambisonics with non-diegetic sources
[11:31:49 CET] <cone-972> ffmpeg 03Michael Niedermayer 07master:04e611474b9a: avcodec/opus: Check count of ambisonic channels
[11:53:09 CET] <j-b> come on, the name is in the email sent
[11:53:12 CET] <j-b> Felicia Lim
[12:11:06 CET] <trapp> Hi, currently uncompressed/loss-less audio encoders (e.g. PCM) set the output bitrate during codec init.
[12:11:06 CET] <trapp> For uncompressed/loss-less video encoders the output bitrate is not set.
[12:11:23 CET] <trapp> I have posted a patch series that tries to estimate the output bitrate for some encoders and welcome feedback:
[12:11:23 CET] <trapp> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/206742.html
[12:12:48 CET] <trapp> In some cases framerate is not available in codec init and thus is guessed from timebase. Are there better options?
[13:57:05 CET] <J_Darnley> does anyone else have any more comment on my h264 assembly patches?
[14:46:01 CET] <BBB> J_Darnley: I think its fine. some parts actually get prettier which is a good thing
[14:46:10 CET] <BBB> J_Darnley: also I cant believe youre working on mbaff
[14:55:52 CET] <kierank> BBB: why, we see it on the profiler
[14:57:11 CET] <BBB> because mbaff makes your head hurt
[14:57:38 CET] <BBB> its one of those jokes you always see in conferences about video codecs: advantages of h264: bla, bla, bla, <s>mbaff</s>, bla, bla
[14:57:48 CET] <BBB> (<s> being strikethrough)
[14:59:16 CET] <nevcairiel> if you accept the premise that you want interlacing, then mbaff sounds like a good idea to have
[15:07:37 CET] <J_Darnley> BBB: since I was only doing one of the dsp functions, I don't really need to see how bad mbaff is, all I saw was doing half the number of "inner iters"
[15:07:46 CET] <BBB> :)
[15:25:13 CET] <jamrial> J_Darnley: could you remove the macro wrapping the macro of the same name? no other transform macro does that
[15:25:33 CET] <jamrial> just write the arguments in your h264 asm
[15:35:29 CET] <J_Darnley> okay, fine
[15:57:12 CET] <cone-972> ffmpeg 03Thierry Foucu 07master:4bc7268f2b5f: lavf/riff: Support decoding files with broken mediasubtype base guid.
[17:29:25 CET] <wm4> philipl: so I rebooted now, and I'm on 375.39
[17:29:56 CET] <wm4> I have no way to confirm (without rolling back the driver, which I don't want to), but I get the feeling 10 bit hevc decoding is now broken or slow
[17:31:20 CET] <Chloe> What's the difference between av_dup_packet() and av_copy_packet()? (other than the former being deprecated)
[17:58:57 CET] <atana> michaelni, I have some problem adding mono layout. I have updated the repo. could you explain the setting of layouts
[18:14:02 CET] <philipl> wm4: Rolling back or rolling forward?
[18:14:15 CET] <philipl> 378.13 is the current stable release
[18:14:33 CET] <philipl> 10bit hevc has been fine for me with that driver.
[18:16:19 CET] <wm4> Chloe: one copies, the other makes a reference
[18:16:54 CET] <wm4> Chloe: you shouldn't use either of them
[18:17:38 CET] <wm4> and of course Libav has neither of them
[18:17:55 CET] <wm4> actually it has av_dup_packet
[18:18:15 CET] <nevcairiel> dup was kinda useful for a while, but with the new refcount apis its probably not so much anymore
[18:20:29 CET] <wm4> at least in ffmpeg it's still useful as "ensure it's refcounted" function
[18:22:41 CET] <nevcairiel> yeah thats whati used  it for
[18:23:04 CET] <nevcairiel> but i just use av_packet_ref or what its called now and free the original one after, fit the dataflow  better
[18:36:02 CET] <andrey_turkin> Hi everyone. I'm tracking down a crash inside avcodec and I've got a feeling that hwaccel->end_frame() is being called twice in a row without start_frame in between. That shouldn't happen, right?
[18:39:33 CET] <nevcairiel> is that on mpeg2 by any chance?
[18:39:50 CET] <andrey_turkin> h264
[18:42:59 CET] <andrey_turkin> I assume there is a convention that there is start_frame, one or more decode_slice and end_frame, in that sequence.
[18:43:23 CET] <nevcairiel> probably, but a hwaccel should probably verify it actually received valid data during end_frame
[18:43:27 CET] <nevcairiel> some seem to do that
[18:46:39 CET] <andrey_turkin> But I don't yet see any which would reset its state in end_frame
[18:48:11 CET] <nevcairiel> the data is stored in the picture, so for that to happen it not only has to call it twice without anything in between, but on the same picture as well
[18:49:45 CET] <michaelni> atana, ill take a look, was afk
[18:53:05 CET] <michaelni> atana, i dont see a update in your repo but the last code i see, you dont need ff_channel_layouts_ref(). the ff_add_channel_layout() and ff_set_common_channel_layouts() should be enough
[18:54:19 CET] <atana> ok
[18:57:29 CET] <michaelni> atana, "AVFilterChannelLayouts *layouts" should be AVFilterChannelLayouts *layouts = NULL;
[19:19:42 CET] <atana> michaelni, repo updated
[19:31:18 CET] <michaelni> atana, ok, lets implement the 2nd stage for the lookup/matching next. For that its probably easiest to use a array of a struct with a int matchtime and int songid. Each time the current code finds a match the time difference and songid is added to that array, it will be needed to realloc the array with  av_fast_realloc() as we do not know how many matches there will be. Once we added all matches we can find, the array is 
[19:31:18 CET] <michaelni> sorted with qsort(), timediff is considered more siginificant than songid for the sorting
[19:32:28 CET] <michaelni> last we do a single pass over the array and find the song id that occurs most often in a continous span
[19:36:22 CET] <atana> sounds good.  what does time difference refer to here? 
[19:39:12 CET] <atana> is it time difference between matches?
[19:39:47 CET] <michaelni> atana, i didnt mention, the difference between p->cpoints[i].time aka t1, aka the time of the current fft window minus the same from the database where theres a match
[19:40:51 CET] <atana> ok, got it
[19:41:52 CET] <michaelni> so if we store a sont starting from time 0 and lookup same song starting from 0 all matches should be about 0 "timediff", if we lookup a song starting from 12sec the timediff would be 12 for the whole song (or -12 depending on how its implemeted)
[19:41:59 CET] <atana> from database I need to pick only the start time for calculating diff?
[19:42:31 CET] <michaelni> only the first time value (t1) the other 7 are not usefull
[21:35:55 CET] <jamrial> nevcairiel: your mingw-w64 fate client started to fail the eval test for no apparent reason two days ago, and i can't reproduce it here (i'm using the msys2 package of gcc, though)
[21:36:01 CET] <jamrial> did you update your toolchain or something?
[21:37:46 CET] <jamrial> mmh, wait, it's x86_32. let me check with that one instead
[21:38:33 CET] <nevcairiel> jamrial: its a mingw-w64 5.0.x bug
[21:38:41 CET] <nevcairiel> jamrial: https://sourceforge.net/p/mingw-w64/bugs/567/
[21:38:49 CET] <nevcairiel> only on 32-bit
[21:39:21 CET] <jamrial> ah, i see. assuming it was fixed in trunk then no wonder the msys2 build works
[21:39:29 CET] <jamrial> nevermind then
[21:39:31 CET] <nevcairiel> it was not
[22:02:06 CET] <atomnuker> I'm close to calling that rfc4175 guy an idiot and he only sent 1 email so far
[22:06:30 CET] <RiCON> maybe the mail server ate his other emails
[22:56:33 CET] <llogan> michaelni: does anyone ever clear out the mod queue for ffmpeg-trac? i don't because i don't have the password.
[23:00:51 CET] <llogan> we should filter messages not from trac at avcodec for that ML
[23:03:21 CET] <michaelni> llogan, your gpg key is expired  2016-11-18 it seems
[23:09:15 CET] <michaelni> llogan, ping me when you have fixed the gpg key ill send you the pw then
[00:00:00 CET] --- Sat Feb 18 2017