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

[burek]

[08:55:26 CEST] <JEEB> .2
[10:21:52 CEST] <`md> 03:04:13 <bxbxb> Hello there! I was wondering if there was an email that I could reach the ffmpeg team at? Thanks! It's regarding a large donation and I didn't want to spam the user list!
[10:21:56 CEST] <`md> lolwat?
[10:30:04 CEST] <durandal_1707> whats wrong with that?
[12:44:59 CEST] <Chloe> yo working on an decoder thing durandal_1707 gave me  slowly but looking to do something else alongside, anything needs doing?
[12:46:09 CEST] <Chloe> Or rather anything not particularly time sensitive which someone wants
[12:53:06 CEST] <Compn> Chloe : atomnuker wants some old game format reverse engineered :D
[12:53:08 CEST] <Compn> ehe
[12:53:09 CEST] Action: Compn afk
[12:53:20 CEST] <Compn> [22:09] <atomnuker> https://pars.ee/temp/mm2_dmusic.zip
[12:53:20 CEST] <Compn> [22:10] <atomnuker> there's a simple client in there too which uses directmusic to decode them (windows only ofc)
[12:53:55 CEST] <Chloe> Nice. Ill check it out
[12:54:58 CEST] <nevcairiel> its a midi-like format, i would recommend to stay away =p
[12:55:13 CEST] <nevcairiel> synthesizer formats are hell on earth
[12:56:19 CEST] <Chloe> nevcairiel: oh. Ill leave it to the libopenmpd guys then, they do the tracker format stuff
[13:00:45 CEST] <ramiro> michaelni: hi michael, I'm working on the intra macroblocks for p frames patch I sent a couple of weeks ago. using a continuous variable like intra_penalty is more interesting than my yes/no approach, but now I have some questions for mpegvideo_enc.c's encode_picture().
[13:01:40 CEST] <ramiro> michaelni: 1) for both ff_fix_long_p_mvs() and ff_fix_long_mvs(), wouldn't it be better to re-run motion estimation with a limited range instead of truncating/using intra mbs?
[13:03:31 CEST] <ramiro> michaelni: 2) for ff_fix_long_p_mvs(), would it be ok to set CANDIDATE_MB_TYPE_INTER instead of CANDIDATE_MB_TYPE_INTRA when the mvs are out of range (with a function parameter to select which one)?
[13:09:28 CEST] <Chloe> nevcairiel: you got anything interesting then?
[13:10:41 CEST] <durandal_1707> Chloe: can you read math papers about non-local means ?
[13:11:25 CEST] <Chloe> I dont have big brain for hard maths but Ill give it a shot why not
[13:15:48 CEST] <durandal_1707> Chloe: can you read this https://arxiv.org/abs/1407.2343 and look at my anl branch on github and tell my why code does not work for denoising audio?
[13:24:43 CEST] <kierank> Qiiiik
[13:25:28 CEST] <Chloe> durandal_1707: why would nlmeans work for audio?
[13:27:17 CEST] <durandal_1707> Chloe: there is another paper which claims it works, also  i can get reasonable ouput under some conditions
[13:29:57 CEST] <Chloe> From what i understand, nlmeans takes the mean of the relative difference per pixel for the entire frame. So in audio this means youre taking the relative difference per sample for a frame?
[13:30:13 CEST] <Chloe> But its essentially a one dimensional nlmeans i think
[13:30:41 CEST] <durandal_1707> yes it works in 1 dimenstion only
[13:31:49 CEST] <nevcairiel> in frequency domain?
[13:32:11 CEST] <Chloe> Ah i see thats what youre doing. Sorry Im a bit slow, on my phone
[13:32:18 CEST] <nevcairiel> nlmeans over sample data doesnt seem very logical
[13:32:28 CEST] <durandal_1707> nevcairiel: nope
[13:33:19 CEST] <Chloe> nevcairiel: yes thats what durandal_1707 is doing
[13:33:46 CEST] <Chloe> durandal_1707: so whats it doing when it doesnt give reasonable output?
[13:35:26 CEST] <durandal_1707> Chloe: it gives samples that doesnt make sense nans/infs etc
[13:36:20 CEST] <Chloe> Oh right mmh. durandal_1707 what did the paper which was about audio say?
[13:36:27 CEST] <durandal_1707> if i modify algo i get too much quit audio
[13:36:34 CEST] <Chloe> Were there any major differences between image and audio nlmeans?
[13:37:19 CEST] <durandal_1707> Chloe: this paper does nlmeans very fast, so i thought i could use its 1d nlmeans algorithm for denoising
[13:38:06 CEST] <Chloe> durandal_1707: i mean you want it working first right?
[13:38:48 CEST] <Chloe> Id get *any* audio nlmeans working and then look at this 1d nlmeans algo again
[13:40:17 CEST] <Chloe> durandal_1707: sorry not able to help much with it, not at a pc for a few hours
[13:40:49 CEST] <durandal_1707> anoher paper algo is not of much use, it is not described very good
[13:47:53 CEST] <michaelni> ramiro, for 1) it would seem logic but in practice subjective quality may prefer intra over limited (and incorrect thus) MVs. at least for some content. for 2) yes, seems to make sense to have more options
[16:25:08 CEST] <ramiro> michaelni: I don't see why a second limited search would result in incorrect MVs. I haven't tested yet, but I would assume a second limited search could possibly provide better results than truncating (by the way this is in the context of eliminating intra mbs for p frames, even though I see your point that intra is better and preferred in this case)
[17:00:46 CEST] <michaelni> ramiro, an object in classical physics can only be at one position at a time so theres only one correct motion vector. Now if that is beyond some limit every other motion vector must be wrong and that could lead to more artifacts than the correct motion vector
[17:01:38 CEST] <michaelni> it doesnt have to lead to artifacts but it could
[17:04:11 CEST] <michaelni> of course if the intra/inter decission and all that is perfect than it doesnt matter as it would reject a MV causing more artifacts but its not prefect so the whole would need testing
[20:06:07 CEST] <rungcc> Hi people, is there someone here that could point me to where could I find someone to hire as a freelancer to create custom encodes profiles to ffmpeg?
[21:26:01 CEST] <atomnuker> wm4: why would you want a flat array?
[21:26:19 CEST] <atomnuker> this makes no sense if you're transmitting something very well defined and universal
[21:26:39 CEST] <atomnuker> making it opaque and codec specific would make it completely useless
[21:27:03 CEST] <atomnuker> what would api users need to put in there if they want to correctly decode a packet?
[21:28:20 CEST] <atomnuker> I understand if it was some data that's not fitting in something we do, like for example a container providing containerization for some data without any explicit type, like magnetometer measurements
[21:32:18 CEST] <wm4> atomnuker: but it's not universal
[21:32:57 CEST] <atomnuker> field parity is universal, its just that most codecs signal that in headers, but we treat packed pixel formats as codecs which don't have such
[21:33:03 CEST] <wm4> it's just some codec specific data that happens not to fit into extra or packet data
[21:33:46 CEST] <wm4> sort of like extradata
[21:33:58 CEST] <wm4> most extradata also transports parameters that are general concepts
[21:34:04 CEST] <wm4> just in a codec specific form
[21:35:05 CEST] <atomnuker> you have a point there, but most extradata we use is in the context of a specified codec-specific header
[21:36:35 CEST] <atomnuker> also extradata isn't something api users have to touch or write themselves
[21:37:13 CEST] <wm4> field parity isn't either
[21:37:25 CEST] <wm4> unless you plan to add this to other raw codecs
[21:37:45 CEST] <wm4> also the field parity thing he wants to add seems to be very basic
[21:37:57 CEST] <wm4> (I don't know interlacing shit much, I just know it's usually more complex)
[21:38:55 CEST] <atomnuker> not really, just need to know the per-packet parity
[21:39:15 CEST] <atomnuker> I don't mind doing packing inside lavf but that would need simd code there
[21:39:49 CEST] <wm4> anyway, I don't want to block it
[21:39:58 CEST] <wm4> being side data is good enough
[23:23:56 CEST] <klaxa> mmrrr, rewriting the parsing as luaC_functions is giving me some trouble...
[23:26:20 CEST] <klaxa> i have started to split the parsing into parts that use lua and those that... don't, but in the end everything interfaces with the stack
[23:26:51 CEST] <klaxa> and i can't pass anything opaque to a lua_Cfunction
[23:27:15 CEST] <klaxa> only "easy" solution i see is using a global variable
[23:40:50 CEST] <jdarnley> Oh, are you the person writing the Lua config for ffserver?
[23:41:18 CEST] <jdarnley> Passing data over the C -> Lua -> C barrirer can be a challenge
[23:42:16 CEST] <jdarnley> push a (light)userdata and you can get a pointer to whatever memory you need.
[23:43:51 CEST] <jdarnley> Lua has a helpful channel on #lua
[23:44:43 CEST] <jdarnley> Also, if the config is only for use in the ffserver binary you are probably fine to use static variables in the C.
[23:49:33 CEST] <klaxa> hmm... well i just now put the whole parsing function in a luaC_function and allocate the configs in a file-scope variable
[23:50:05 CEST] <klaxa> calling it with invalid configurations prints the expected errors without crashing
[23:53:37 CEST] <klaxa> also i replaced all the if (lua_type(...)) stuff with luaL_checktype() which just raises an error, much simpler :)
[00:00:00 CEST] --- Thu May 24 2018