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

[burek]

[00:05:08 CEST] <jamrial> J_Darnley: depends. if the one patch would end up having a list of different changes that comprise said improvements, then that means it shouldn't be all in one patch but rather one per change
[00:06:21 CEST] <J_Darnley> That's how they are right now but I want to rebase, change the order, change whitespace, edit, drop one, ...
[00:07:45 CEST] <J_Darnley> Overall it would be additions to 1 function and a new function.
[00:07:57 CEST] <J_Darnley> Not to mention I should test the speed again after a bugfix between now and when I originally wote the thing.
[00:11:10 CEST] <atomnuker> J_Darnley: lpc encoder? you mean libavcodec/lpc.c improvements?
[00:11:15 CEST] <atomnuker> or is it flac specific
[00:11:28 CEST] <J_Darnley> Flac specific, I think.
[00:11:48 CEST] <J_Darnley> Well, it was 3 years ago
[00:13:32 CEST] <J_Darnley> Oh, my patches aren't about calculating the coeffs but doing the actual encoding(?)
[00:25:15 CEST] <atomnuker> cool
[00:50:48 CEST] <KGB> [13FFV1] 15kieranjol opened pull request #58: pdf_backmatter.md - updates dead links (06master...06patch-1) 02https://git.io/vS5sn
[01:40:40 CEST] <atomnuker> michaelni: sent a new patch without <p></p>, feel free to push whenever you get the change
[01:40:48 CEST] <atomnuker> (llogan doesn't seem to be here)
[01:41:28 CEST] <atomnuker> can whoever handle social networks (Timothy_Gu?) also post about the release and like to the news post when it gets pushed
[17:18:19 CEST] Action: Compn finally learns how to use -map
[17:18:21 CEST] <Compn> huzzah!
[17:18:36 CEST] <Compn> thanks to whoever writes the tutorials on ffmpeg trac wiki
[17:19:22 CEST] <iive> Compn: link?
[17:19:27 CEST] <iive> :P
[17:22:09 CEST] <Compn> https://trac.ffmpeg.org/wiki/Map
[17:22:29 CEST] <Compn> rogerdpack and burek 
[17:22:43 CEST] <Compn> the authors deserve some thanks :)
[18:38:24 CEST] <durandal_1707> Compn: found yet another screen codec that use zlib, it uses same rle encoding as mscc
[19:27:51 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vS5Q2
[19:27:51 CEST] <KGB> 13FFV1/06master 14d22129e 15Kieran O'Leary: pdf_backmatter.md - updates dead links
[20:00:00 CEST] <BtbN> That decklink patch broke the coverity builds: https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/222597943#L1103
[20:13:04 CEST] <kierank> durandal_1707: where do you even get these codecs from
[20:13:46 CEST] <durandal_1707> kierank: internet of all the things
[20:17:38 CEST] <jamrial> BtbN: that seems to complain about ubitux's "strict" pthread implementation (for assert levels above 0)
[20:17:46 CEST] <jamrial> maybe it needs to be disabled for c++ sources
[20:41:25 CEST] <atomnuker> TimothyGu: do you have acces to the social media accounts?
[20:53:50 CEST] <kierank> atomnuker: it's a holiday weekend you know
[20:53:53 CEST] <kierank> people have other things to do
[21:11:43 CEST] <wm4> like what
[21:12:57 CEST] <jamrial> dinner with family
[21:13:53 CEST] <jamrial> or overdosing with chocolate
[21:24:12 CEST] <kierank> going outdoors
[21:26:47 CEST] <wm4> now why would you do that
[21:28:22 CEST] <durandal_1707> its weekend
[21:30:02 CEST] <kierank> wm4: vitamin a
[21:30:37 CEST] <durandal_1707> isnt that d or e
[21:30:57 CEST] <Compn> durandal_1707 : what fourcc is it ?
[21:31:35 CEST] <durandal_1707> Compn: SRGC
[21:32:04 CEST] <Compn> durandal_1707 : so many screen codecs heh
[21:32:39 CEST] <kierank> durandal_1707: probably, i hated biology
[21:33:09 CEST] <alevinsn> Vitamin D
[21:34:43 CEST] <alevinsn> jamrial:  I'll likely add sem_ functions to w32threads.h in 1.5-2 weeks, lots to do for me in the week preceding NAB show
[21:35:05 CEST] <alevinsn> jamrial:  Although, I suspect that the use-case for semaphores is very limited in ffmpeg
[21:35:10 CEST] <alevinsn> unlike other pthread functionality
[21:51:52 CEST] <nevcairiel> What exactly would use the sem API specifically?
[21:54:09 CEST] <alevinsn> well, the decklink use case is a good reason for using semaphores
[21:54:20 CEST] <alevinsn> in this case, you have decklink playing frames at a fixed rate
[21:54:25 CEST] <alevinsn> for decklink output
[21:54:42 CEST] <alevinsn> while frames may be arriving at a faster than real-time rate
[21:54:48 CEST] <alevinsn> frames that are ready to be played back
[21:54:59 CEST] <nevcairiel> Well it doesn't use it anymore apparently :p
[21:55:03 CEST] <alevinsn> you don't want to schedule too many frames into Blackmagic
[21:55:10 CEST] <alevinsn> it uses a semaphore-like concept
[21:55:19 CEST] <alevinsn> or you run into problems
[21:56:43 CEST] <alevinsn> I don't know how semaphores are used in jack--haven't looked into it
[21:56:58 CEST] <alevinsn> so, it is possible that something similar might come up with other output devices
[21:57:00 CEST] <Chloe> Whay about jack? 
[21:57:08 CEST] <alevinsn> there are almost no output devices in ffmpeg
[21:57:16 CEST] <alevinsn> a number of input devices, but very few output devices
[21:57:19 CEST] <alevinsn> hah
[21:57:27 CEST] <Chloe> Output devices are bad
[21:57:27 CEST] <alevinsn> jackaudio
[21:57:44 CEST] <Chloe> Yes i know what it is, I've worked on it
[21:57:52 CEST] <Chloe> Libavdevice needs a rework
[21:58:06 CEST] <Chloe> Its pretty much a libavfromat clone
[21:58:21 CEST] <alevinsn> there are two instances of semaphores used in the code, one (formerly) in decklink output, and one in jackaudio
[21:58:33 CEST] <alevinsn> I was saying I haven't looked into how jackaudio uses semaphores
[21:59:13 CEST] <Chloe> Why do you need semaphores? 
[21:59:26 CEST] <alevinsn> why in general or why in decklink and jack?
[21:59:38 CEST] <Chloe> Err. 
[21:59:46 CEST] <alevinsn> its a broad question :-)
[22:00:01 CEST] <Chloe> What are you doing? Why do you want to do it? How does it involve semaphores? 
[22:00:21 CEST] <alevinsn> um, a patch was submitted that replaced the use of semaphores in decklink with one that uses a combination of
[22:00:29 CEST] <alevinsn> a mutex, conditional variable, and a counter
[22:00:38 CEST] <alevinsn> so that it would be possible to build it without pthread on Windows
[22:01:03 CEST] <alevinsn> no one is wanting to use semaphores currently for anything else in ffmpeg--but there was a discussion for adding a sem_ portability layer
[22:01:06 CEST] <alevinsn> to ffmpeg
[22:01:32 CEST] <alevinsn> and then, presumably, going back to using the sem_ functions in the decklink code
[22:01:59 CEST] <Chloe> I wouldn't be against it. FFmpeg already has a mini compat layer for osx semaphores 
[22:02:08 CEST] <alevinsn> right, but used almost nowhere
[22:02:16 CEST] <alevinsn> a search for sem_ in the code finds almost no instances
[22:03:58 CEST] <Chloe> The rework for lavd i had in mind would make use of semaphores more, though i haven't been able to do anything with ffmpeg due to school work.
[22:04:38 CEST] <Chloe> Im actually on holiday right now, so i dont have a copy of the ffmpeg code on hand, but are you saying decklink uses semaphores at the moment or has in the past? 
[22:04:52 CEST] <alevinsn> has until very recently
[22:04:59 CEST] <alevinsn> still uses a semaphore in concept
[22:05:19 CEST] <alevinsn> but using an implementation that relies on a combination of a condition variable, mutex, and counter
[22:05:36 CEST] <alevinsn> to eliminate the dependency on pthread
[22:06:21 CEST] <alevinsn> you're on holiday but are choosing to spend your time on the ffmpeg-devel IRC channel? :-P
[22:07:00 CEST] <Chloe> Yes, I'm not enjoying my holiday 
[22:07:31 CEST] <alevinsn> I think I can empathize
[23:11:16 CEST] <atomnuker> jamrial: how did the hack to use more than 7 gprs on 32 bit machines work again?
[23:14:55 CEST] <iive> omit frame pointer and no-pic ?
[23:17:55 CEST] <Chloe> alevinsn: take a look at the osx semaphore compat thing, see if you could do something like that for win 32. (note that i dont have access to email so can't check the ml) 
[23:18:18 CEST] <nevcairiel> atomnuker: you can specify a negative stack size to avoid using one of the regs for the stack pointer, although you cant use "m" addressing of any parameters anymore then
[23:18:37 CEST] <nevcairiel> (and of course thats only 8 then, more is not possible)
[23:21:59 CEST] <Gramner> uhm, you can't really use more than 7 regs on 32-bit x86 since there's only 8 and one of them is the stack pointer
[23:23:01 CEST] <nevcairiel> maybe that trick was to use the 7th then
[23:23:08 CEST] <nevcairiel> i ate too much to remember
[23:26:11 CEST] <rcombs> what determines the number of samples per audio frame in lavfi with ffmpeg.c?
[23:26:21 CEST] <rcombs> is it just whatever comes in from the decoder?
[23:26:31 CEST] <nevcairiel> the requested frame size from the encoder, iirc
[23:26:42 CEST] <nevcairiel> well, at least at the end of lavfi
[23:26:49 CEST] <nevcairiel> in the beginning it may be from the decoder
[23:26:53 CEST] <nevcairiel> it gets re-framed somewhere
[23:26:56 CEST] <nevcairiel> not sure if thats only in the sink
[23:27:08 CEST] <rcombs> looks to me like it buffers and re-frames for the encoder on output
[23:27:25 CEST] <rcombs> av_buffersink_set_frame_size, etc
[23:29:45 CEST] <atomnuker> Gramner, nevcairiel: this is what I'm trying to understand: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/diracdsp.asm#L141
[23:30:13 CEST] <rcombs> maybe the resampler does it
[23:30:24 CEST] <atomnuker> what did the "m" suffix do when used on regs?
[23:30:58 CEST] <Gramner> it refers to the original parameter location, e.g. the stack on 32-bit
[23:31:04 CEST] <nevcairiel> r4m is the location of the 5th argument, in the 32-bit case thats not a reg but stack space, so it basically uses stack instead of regs
[23:33:27 CEST] <atomnuker> ah, I get it
[23:34:47 CEST] <Gramner> on 64-bit it can be either a register or the stack depending on which number it is, the first 4 args are passed in regs on win64, the first 6 on sysV.
[23:36:10 CEST] <nevcairiel> you could reserve dedicated stack space for these things, but if the parameter stack is unused after initial loading, why not use that
[23:37:48 CEST] <Gramner> note that stack space used for passing arguments belong to the called function so you're allowed to use that portion of memory for whatever you want
[23:41:37 CEST] <rcombs> but if the ABI happens to put that particular arg in a register, then it points at that register, which you might be using for something else, right?
[23:42:02 CEST] <nevcairiel> yeah you need to know the ABI to use that function smart
[23:43:07 CEST] <nevcairiel> but x86 is the same everywhere, and you'll find some differences between UNIX64 and WIN64 in some functions
[23:44:31 CEST] <atomnuker> also where did the differences in float arguments come from? what makes floats special in this case?
[23:44:52 CEST] <atomnuker> I think it's because FPUs were optional back 30 years ago but I could be wrong
[23:46:27 CEST] <nevcairiel> x86 cdecl doesnt handle float any special, its just passed on the stack as well and has a dedicated fpu register for return values
[23:47:21 CEST] <nevcairiel> win64 and unix64 are just generally a bit different, but both can pass float in a xmm reg if the conditions are right
[23:48:15 CEST] <atomnuker> I though unix64 always passes them in xmm regs
[23:48:57 CEST] <nevcairiel> maybe the condition is  "true" then! :P
[23:50:55 CEST] <nevcairiel> it reads like it can always pass them on xmm regs, while win64 only passes 4 parametrs in regs, no matter if those are gprs or xmm regs
[23:51:04 CEST] <nevcairiel> but i dont have much e xperience with unix64
[23:58:37 CEST] <iive> ax,bx,cx,dx, si,di,bp that's 7 without sp, ip
[00:00:00 CEST] --- Mon Apr 17 2017