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

[burek]

[08:44:16 CET] <fritsch> wm4: when implementing a hw decoder and this one is then used by the send / receive API and let's consider both send and receive return EAGAIN - cause everything is filled up but we don't receive data yet. How would you handle that, so that we don't run into an endless high cpu intensive loop?
[10:25:32 CET] <nevcairiel> fritsch: decode APIs are not allowed to return EAGAIN
[10:25:55 CET] <nevcairiel> (unless noblock flag is set, in which case its up to the c aller to figure out what to do)
[10:32:25 CET] <fritsch> nevcairiel: but what to do if it cannot take any pakets anymore, but is not yet read to output something?
[10:32:35 CET] <nevcairiel> wai
[10:32:37 CET] <nevcairiel> t
[10:32:42 CET] <nevcairiel> or buy hardware that behaves properly
[10:32:46 CET] <fritsch> haha
[10:33:07 CET] <fritsch> not sure what that has to do with the hardware
[10:33:19 CET] <fritsch> think of 120 fps hevc10 bit content with unbelievably high bitrate
[10:33:38 CET] <fritsch> in the sense of decoding takes long, but all buffers are already in
[10:33:42 CET] <fritsch> do I overlook something?
[10:34:14 CET] <nevcairiel> the decoder would then need to wait and block internally
[10:34:48 CET] <nevcairiel> the API does not allow for returning EAGAIN
[10:36:21 CET] <fritsch> mmh, then the docu is wrong
[10:36:35 CET] <fritsch> ah no it's not - but it's not 100% clear
[10:36:49 CET] <nevcairiel> it has specific cases where it returns EAGAIN, ie. it wants more inpuit
[10:36:55 CET] <fritsch> jep, figured
[10:37:10 CET] <fritsch> so if there is no error, no input needed, it needs to block
[10:37:11 CET] <fritsch> okay
[10:37:51 CET] <fritsch> thx very much
[12:10:10 CET] <wm4> nevcairiel: what noblock flag
[12:10:44 CET] <wm4> fritsch: it can't return eagain for both... it must implement waiting to prevent that
[12:10:56 CET] <nevcairiel> probably there isnt even such a flag on avcodeccontext
[12:11:03 CET] <nevcairiel> formatcontext has it, i guess
[12:11:56 CET] <wm4> fritsch: we could implement an optional async mode, but even then you'd need a callback or whatever to notify the api user of progress
[12:12:32 CET] <wm4> fritsch: what I definitely want to avoid is that the api user has to poll/sleep - that would be crap
[13:21:28 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:fab13bbbcdf9: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'
[13:21:29 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:d03d38616278: avcodec/wavpack: Check bitrate_acc for overflow
[13:21:30 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:29638d4db90d: avcodec/dcadsp: Fix 2 runtime error: signed integer overflow: -1958094138 - 1078906344 cannot be represented in type 'int'
[13:21:31 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:ba150051322c: avcodec/wavpack: Fix runtime error: left shift of negative value -2
[14:41:19 CET] <cone-200> ffmpeg 03Carl Eugen Hoyos 07master:1638d956a35c: lavf/matroska: Support QDMC.
[15:49:50 CET] <BtbN> philipl, could you have a look at https://github.com/BtbN/FFmpeg/commit/master ? I have mostly rewritten the crop/resize patch, and in my tests it works as expected. Would just like a second pair of eyes for logic errors.
[16:04:45 CET] <BtbN> oh hey, VS2017 has a language setting, that even the commandline tools follow
[16:06:08 CET] <JEEB> nice
[16:20:26 CET] <BtbN> great, while compiling, Windows Defender uses more CPU than all compiler processes combined
[16:20:34 CET] <BtbN> Lets turn that shit off
[16:25:31 CET] <BtbN> "built with Microsoft (R) C/C++ Optimizing Compiler Version 19.10.24930 for x64" hey, that just worked
[16:26:33 CET] <JEEB> yayifications
[16:28:16 CET] <jamrial> BtbN: just add a your msys or cygwin environment folder to the exception list
[16:28:28 CET] <BtbN> hm?
[16:28:36 CET] <BtbN> Oh
[16:28:38 CET] <BtbN> nah
[16:28:51 CET] <durandal_1707> BBB: have you looked at vmaf patch?
[16:35:26 CET] <jamrial> that mail has probably the longest subject ever
[16:36:56 CET] <Compn> does mail rfc have a limit on subject length ?
[16:37:45 CET] <durandal_1707> yes, to loong and devs ignore it
[16:38:07 CET] <kierank> vmaf is weird metric, ask BBB 
[16:40:33 CET] <cone-200> ffmpeg 03Paul B Mahol 07master:035e932d7c03: avformat/vivo: fix logic error in checking version in probe
[17:07:45 CET] <nevcairiel> BtbN: you should've waited 2 days when 2017 final comes out :d
[17:08:55 CET] <JEEB> oh, it's that close? nice
[17:09:03 CET] <JEEB> I should really move to VMs with VS...
[17:09:12 CET] <JEEB> I've got 2010,2013,2015 installed on this host OS now
[17:09:27 CET] <nevcairiel> 2017 finally provides a modern no-frills installer
[17:09:35 CET] <nevcairiel> it should install much quicker and actually uninstall without troubles
[17:09:38 CET] <BtbN> nevcairiel, I'm pretty sure it just updates
[17:12:44 CET] <nevcairiel> and yeah official release day is march 7th
[17:13:10 CET] <BtbN> It didn't install into any special RC directory. So I'm pretty sure it will just self-update to the release version
[17:14:53 CET] <nevcairiel> i guess i'll finally kill the 2012 fate system then and replace it with a 2017
[17:15:12 CET] <JEEB> sounds like a good idea, only game devs seem to have stayed with 2012
[17:17:38 CET] <kierank> BtbN: the problem is if you do scaling in your decoder that crazy guy has justification for doing it
[17:17:49 CET] <kierank> irrespective of the fact yours is a black box
[17:18:03 CET] <BtbN> the 9 dude?
[17:18:25 CET] <nevcairiel> there is still a huge difference in adding hundreds of lines of unoptimized code and setting 2 flags for the hardware
[17:18:35 CET] <kierank> i agree
[17:18:38 CET] <kierank> but that guy won't
[17:18:48 CET] <BtbN> That guy won't agree with anything sensible
[17:18:49 CET] <nevcairiel> what do we care, its not like his code is getting in
[17:19:08 CET] <kierank> you know as well as i do that because of the crazy decision making processes, that code will get in
[17:19:26 CET] <BtbN> wm4, shouldn't the cuvid deinterlacing shenanigans work, now that the lazy filter init is in?
[17:19:39 CET] <BtbN> I still need a "-r 50" input option for the output to double in framerate
[17:20:13 CET] <BtbN> I doubt that his code will get in. I haven't seen anyone in favor for it.
[17:31:52 CET] <wm4> BtbN: this never affected deint
[17:31:56 CET] <wm4> but maybe scaling
[17:32:12 CET] <BtbN> scaling/cropping works fine out of the box
[17:32:23 CET] <BtbN> But it doubling the framerate is completely lost
[17:32:42 CET] <BtbN> Maybe I should move that in front of the get_format callback as well?
[17:32:56 CET] <wm4> I don't know if the decoder can even signal this (usually it wouldn't make sense)
[17:35:00 CET] <nevcairiel> changing the time base from a decoder is just not something that any other thing does, so user-code probably doesnt check for a change there
[17:36:33 CET] <nevcairiel> not to mention that the primary timebase is not even a f ield a decoder can access
[17:37:34 CET] <nevcairiel> timestamps are supposed to be largely opaque for decoders
[17:50:21 CET] <BBB> the vmaf patch subject needs some work, yes
[17:50:35 CET] <BBB> as for the patch itself, the problem is it uses pipe/fork, so Im not 100% sure its appropriate
[17:50:46 CET] <BBB> but theres no other way to interact with vmaf ATM, since it has no API that Im aware of
[17:51:10 CET] <JEEB> yeah, it's just a tool with python implementation I think?
[17:51:14 CET] <JEEB> it's not really meant to be used as a lib
[17:51:53 CET] <BBB> ATM, yes
[17:52:06 CET] <BBB> still cool to have it integrated even if the patch needs to be applied manually
[17:52:12 CET] <JEEB> sure
[17:52:20 CET] <BBB> I can see this being useful to e.g. youtube or so :)
[17:52:29 CET] <BBB> anyway, the gsoc project is to integrate it for real
[17:52:30 CET] <BBB> so
[17:52:36 CET] <BBB> stuff2do
[17:52:46 CET] <JEEB> yup
[18:55:22 CET] <kierank> atomnuker: is referencing a frame of a different resolution in av-1 well defined?
[18:57:22 CET] <kierank> ok found it in the spec, seems to be
[18:57:42 CET] <nevcairiel> probably inherited that from vp9
[19:03:39 CET] <kierank> ah didn't know vp9 allowed tht
[19:36:57 CET] <BBB> kierank: theres a spec?
[19:41:03 CET] <adeel2> durandal_1707: I'm still getting these 3 errors: [xpm @ 0x7f7494007960] [IMGUTILS @ 0x7f749d4f7b80] Picture size 0x0 is invalid [xpm @ 0x7f7494007960] video_get_buffer: image parameters invalid [xpm @ 0x7f7494007960] get_buffer() failed how would I go on about fixing these?
[19:42:00 CET] <durandal_1707> adeel2: by moving get buffer to right place
[19:42:38 CET] <durandal_1707> get buffer needs width and height to be non zero
[19:50:01 CET] <adeel2> durandal_1707: okay, got those errors fixed, now I'm getting  Picture size 2147483648x2147483648 is invalid
[19:50:17 CET] <JEEB> that is a cool picture size :P
[19:50:37 CET] <durandal_1707> adeel2: you did something wrong
[19:51:20 CET] <adeel2> I think it's an overflow issue
[19:51:41 CET] <durandal_1707> adeel2: where you put this get buffer?
[19:52:23 CET] <adeel2> durandal_1707: right after "ff_set_dimensions" in the beginning
[19:52:51 CET] <durandal_1707> adeel2: before sscanf?
[19:53:03 CET] <durandal_1707> use common sense
[19:54:22 CET] <adeel2> lol. my bad.
[20:11:59 CET] <adeel2> durandal_1707: I've tried skipping the dimension checking function. still get error in get buffer. have now called it afte sscanf
[20:13:23 CET] <durandal_1707> adeel2: dunno, i need to see code
[20:15:11 CET] <adeel2> https://github.com/adl1995/FFmpeg/commit/97465bd80da4eb20304eed90c61f589b7c336f6a
[20:17:04 CET] <unholy_me> @durandal_1707 is there any good audio filter in the avfilter, which has multiple channels?
[20:17:23 CET] <unholy_me> as input*
[20:18:29 CET] <durandal_1707> unholy_me: pan, sofalizer, stereotools
[20:20:06 CET] <durandal_1707> adeel2: why you blindly copied xbm code without any unnderstanding?
[20:20:45 CET] <durandal_1707> adeel2: there is already code in xpm which handles width and height
[20:22:02 CET] <durandal_1707> unholy_me: for start just try to get compilation of filter and simple pass that returns unchanged frames
[20:24:53 CET] <unholy_me> @durandal_1707 : I tried and compiled a simple image filter given in doc/writing_filters and understood how it works
[20:25:22 CET] <unholy_me> If I ignore the math, i can write a very simple filter
[20:26:00 CET] <durandal_1707> now modify it and do audio one
[20:27:58 CET] <durandal_1707> the square decoder is very simple one
[20:28:54 CET] <unholy_me> Thanks @durandal_1707 On it
[20:34:01 CET] <unholy_me> @durandal_1707 I was thinking, the skip_spaces, parse_channel_name functions all remain the same right?
[20:35:24 CET] <durandal_1707> no, you dont neeed any of pan code just structure
[20:38:37 CET] <unholy_me> If I may, what exactly is the difference between a decoder and filter?
[20:39:23 CET] <durandal_1707> unholy_me: decoder actually decompress something from compressed stream
[20:39:52 CET] <unholy_me> and filter?
[20:40:03 CET] <durandal_1707> ambisonic decoder doesnt have to decompress anything its just called that way
[20:40:33 CET] <durandal_1707> filter just process input in any way it wants
[20:41:22 CET] <durandal_1707> it doesnt do any compression and bitsttream format stuff
[20:41:43 CET] <unholy_me> So, in the qualification task we are supposed to design a square decoder or a filter?
[20:42:23 CET] <durandal_1707> unholy_me: square decoder as filter. its just naming
[20:46:50 CET] <unholy_me> @durandal_1707 Also, what options would be there in the square filter?
[20:47:04 CET] <unholy_me> Like to fill the option array
[20:48:23 CET] <durandal_1707> unholy_me: name it ambisonic filter. square would be just output option
[20:50:07 CET] <durandal_1707> it would accept numerous input formats in which ambisonic can be found in wild
[20:50:34 CET] <durandal_1707> for now just concentrate on B format
[20:51:29 CET] <unholy_me> B-format : W,X,Y,Z channels only?
[20:52:11 CET] <durandal_1707> yes, thats most common ambisonic format
[21:40:59 CET] <unholy_me> @durandal_1707 I don't understand what to write in query_format() ?
[21:41:57 CET] <durandal_1707> unholy_me: requst 4 channels in input and 4 in output
[21:43:26 CET] <durandal_1707> set channel layout
[21:43:48 CET] <unholy_me> AVFilterLink *inlink <--- what is this set to?
[21:44:23 CET] <durandal_1707> thats your input link
[21:45:06 CET] <durandal_1707> you set to it channel layouts, samplerates and sampleformats
[21:46:17 CET] <unholy_me> Then how do I request "4 channels" specifically?
[21:46:31 CET] <unholy_me> I understand for 1 channel
[21:46:41 CET] <durandal_1707> unholy_me: have you read doc/filters_design.txt?
[21:47:15 CET] <durandal_1707> unholy_me: by signaling only 4 channel layout
[21:48:46 CET] <unholy_me> okay okay... sorry 
[21:48:56 CET] <unholy_me> reading it now
[22:09:45 CET] <unholy_me> @durandal1707 is it true that every channel has a series of frames?
[22:10:13 CET] <unholy_me> how are frames designated for audio channels?
[22:14:16 CET] <durandal_1707> unholy_me: every frame have channels
[22:15:25 CET] <durandal_1707> depending on sample format how it is interleaved in frame array
[22:50:13 CET] <unholy_me> AV_CH_LAYOUT_4POINT0 ---> is this the correct layout for the square filter?
[22:51:51 CET] <durandal_1707> unholy_me: not important, just that it have 4 channels
[22:52:25 CET] <unholy_me> aye, sir!
[22:58:01 CET] <unholy_me> another thing, do we have to preset the channel layout or detect which channel layout is incoming?
[22:59:29 CET] <durandal_1707> unholy_me: you receive ch layout which you signal in query formats
[23:00:15 CET] <durandal_1707> one can accept multiple at once. but not in your case
[23:01:33 CET] <unholy_me> There is a function to set channel layout right? Which directory can I find it?
[23:03:04 CET] <durandal_1707> unholy_me: look at other filters and their query formats
[23:09:34 CET] <unholy_me> \durandal_1707 the w,x,y,z would have a float value in every frame, right?
[23:11:05 CET] <durandal_1707> unholy_me: no,they are sugned 16bit integers in wav, but you can request float as processing format for simplicity
[23:14:42 CET] <unholy_me> also the angle theta, that would be a float?
[23:16:01 CET] <durandal_1707> unholy_me: yes, but for square thats fixed
[23:19:45 CET] <unholy_me> ohkay at 1.57 rad
[23:24:55 CET] <unholy_me> would it be okay to take buffer in this? 
[23:28:46 CET] <durandal_1707> unholy_me: what?
[23:29:25 CET] <unholy_me> Just buffer is ued when the frames are big, right?
[23:30:43 CET] <durandal_1707> unholy_me: just process full frames. no need for extra buffers
[00:00:00 CET] --- Mon Mar  6 2017