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

[burek]

[00:06:37 CEST] <BBB> TD-Linux: but that only makes sense if you scale references on resize
[00:06:53 CEST] <BBB> TD-Linux: here, you scale ref data pixels in the block decoding loop as part of mc
[00:06:55 CEST] <TD-Linux> BBB, right, versus scaling in MC
[00:07:04 CEST] <BBB> TD-Linux: so it doesnt matter how many refs you keep, there is no overhead
[00:07:19 CEST] <BBB> its just that the mc itself is super slow
[00:07:25 CEST] <BBB> (if the ref is scaled)
[00:08:27 CEST] <nevcairiel> wouldnt it potentially be faster to just upscale the refs once
[00:08:32 CEST] <TD-Linux> yeah that seems a lot worse than doing a scale ahead of time imo
[00:09:47 CEST] <J_Darnley> kierank: did you start on that drawutils function you asked about?
[00:10:07 CEST] <TD-Linux> the memory bandwidth penalty of doing the one scale ahead of time seems better than the rather ridiculous upper bound of mc complexity
[00:13:49 CEST] <BBB> the bound issue is solved by limiting scale factors
[00:13:50 CEST] <nevcairiel> maybe they considered changing the size may happen often and refs stay long
[00:13:56 CEST] <BBB> I believe it can go only up by 2 and down by 4
[00:14:00 CEST] <BBB> or the other way around
[00:14:23 CEST] <BBB> anyway, its this way, sorry :(
[00:14:28 CEST] <BBB> vp9 is finished, its not changing
[00:44:00 CEST] <TD-Linux> well I'm probably going to add this sort of feature in Daala at some point, so there's room to do it correctly there :)
[00:48:20 CEST] <atomnuker> TD-Linux: do you know if daala will use profiles
[01:00:00 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:62144b225d07: avfilter/internal: Doxygen for ff_fmt_is_in
[01:55:30 CEST] <TD-Linux> atomnuker, not sure yet, ideally there wouldn't be any profiles. the big sticking point is 8-bit references
[02:02:37 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:002b0499b62e: avfilter/af_ladspa: check functions return value in query_formats
[03:49:02 CEST] <kierank> J_Darnley: not yet
[03:52:14 CEST] <kierank> I don't see how the report is rude if I can't get gdb to backtrace
[04:45:22 CEST] <J_Darnley> kierank: I was going to say I would start some work on it next time my game crashed but that never happened.
[04:45:34 CEST] <J_Darnley> It is now 04.45 so I'm going to bed.
[04:46:01 CEST] <J_Darnley> I might start poking at it "tomorrow"
[11:42:00 CEST] <highgod> Hi, I want to ask a question, does ffserver support rtsp serfor for hevc stream? Thanks
[12:12:58 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:b379e1d6dfe2: avcodec/mpegvideo_enc: Factor new_picture unref out
[12:12:58 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:fd46d6deac9b: avcodec/mpegvideo_enc: Merge ifs with identical conditions
[12:12:58 CEST] <cone-384> ffmpeg 03Alexis Ballier 07master:6e8d856ad6d3: libavcodec/mpegvideo_enc.c: Fix encoding videos with less frames than the delay of the encoder.
[13:00:55 CEST] <ubitux> durandal_1707: http://yuzhikov.com/articles/BlurredImagesRestoration1.htm if you're bored
[13:06:40 CEST] <Compn> enhance...
[13:12:53 CEST] <durandal_1707> ubitux: writing nlmeans?
[13:26:21 CEST] <wm4> can we have an uncrop filter
[13:34:34 CEST] <durandal_1707> wm4: are you serious?
[13:34:59 CEST] <J_Darnley> It exists!  It's called pad!
[14:17:27 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:bb1d3f1078e0: avformat/rsd: add VAG support
[14:17:28 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:7bbd060324f0: avcodec/adpcm: increase max channels for ADPCM PSX to 8
[14:29:22 CEST] <cone-384> ffmpeg 03Carl Eugen Hoyos 07master:9496f565dcc7: configure: Simplify using --disable-all.
[15:09:45 CEST] <ubitux> durandal_1707: yes i'm writing nlmeans
[15:24:26 CEST] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:e11e32686fdb: avcodec/bitstream: replace qsort with AV_QSORT
[17:21:27 CEST] <JEEB> durandal_1707: seems like z's v2 rc is out
[17:21:31 CEST] <JEEB> so it shouldn't get major changes
[17:28:20 CEST] <durandal_1707> JEEB: simd have bug producing corrupt output
[17:28:43 CEST] <JEEB> ok
[17:30:32 CEST] <JEEB> is it easily repro'able?
[17:33:04 CEST] <durandal_1707> maybe it got fixed, dunno
[17:34:12 CEST] <JEEB> so what failed for you so I can test if I build it :P
[17:43:56 CEST] <durandal_1707> corrupted pixels on right side when resizing
[17:44:12 CEST] <JEEB> oh, I'm pretty sure that got fixed
[17:44:22 CEST] <JEEB> also he's got unit tests now
[17:44:48 CEST] <Daemon404> i recall that being an issue 1-2 weeks ago, no?
[17:48:50 CEST] <JEEB> durandal_1707: what was your last patch?
[17:50:22 CEST] <JEEB> is it the oct 2nd one?
[17:51:21 CEST] <durandal_1707> I havent send it yet, mostly api changes, looking at alpha issue right now and than gonna push it
[17:51:56 CEST] <JEEB> you have a wip repo?
[17:56:04 CEST] <durandal_1707> locally
[17:56:40 CEST] <durandal_1707> wm4: mpv thinks that gbrap is rgb555
[18:04:18 CEST] <wm4> durandal_1707: sample file?
[18:05:17 CEST] <durandal_1707> -vf format-gbrap
[18:06:58 CEST] <kierank> J_Darnley: I wasn't sure how to handle the constants in that function
[18:07:03 CEST] <wm4> can't see anything with rgb555, although it converts to argb instead of outputting it directly
[18:07:10 CEST] <durandal_1707> sorry its not mpv bug
[18:08:56 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:416e35e5aafc: avfilter: add zscale filter
[18:09:25 CEST] <JEEB> wow
[18:09:31 CEST] <wm4> wow
[18:09:52 CEST] <wm4> durandal_1707: when was grap introduced? maybe I have to ifdef it
[18:15:57 CEST] <durandal_1707> No, nut muxer picks wrong tag
[18:16:07 CEST] <JEEB> durandal_1707: first comment would be that -lstdc++ in extra-ldflags is required, at least for me
[18:16:51 CEST] <durandal_1707> than zimg pkgconfig is broken
[18:17:06 CEST] <JEEB> possibly
[18:34:47 CEST] <Compn> >pkgconfig is broken
[18:34:51 CEST] Action: Compn runs
[18:38:13 CEST] <wm4> durandal_1707: I added support for these formats
[18:38:20 CEST] <wm4> Compn: fuck your disgusting anti-developer attitude
[18:51:18 CEST] <JEEB> well, simple YCbCr->YCbCr scaling seems to work at least
[19:17:30 CEST] <durandal_1707> ycgco should also work
[19:38:00 CEST] <durandal_1707> tell this MIT guy to other stuff
[19:38:26 CEST] <durandal_1707> *to do
[20:11:13 CEST] <J_Darnley> kierank: if they are really constant then use some RODATA like most other cases.
[20:11:23 CEST] <kierank> they are not
[20:11:26 CEST] <kierank> they are calculated constants
[20:11:27 CEST] <J_Darnley> If you need to calculate them then use stack space
[20:12:44 CEST] <J_Darnley> You can always try simplifying and only supporting 1 particualar config
[20:12:51 CEST] <J_Darnley> like 420 and 8 bit mask
[20:45:46 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:94f7c97e0573: avformat/vag: Remove unused variable pos
[21:02:34 CEST] <kierank> J_Darnley: I should probably learn how to use stack space...
[21:22:08 CEST] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:07d4fe3a871f: avutil: use EINVAL instead of -1 for the return code of crypto related init functions
[21:34:48 CEST] <nicolas_> hi, i've found a bug on ffmpeg, i manage to fix it in 2 lines, but, i won't break something else, so i would like the opinion of dev of ffmpeg :
[21:35:17 CEST] <nicolas_> in the protocol rtsp, at the disconnection, the client has to send a packet ; this is implemented in ffmpeg, but
[21:35:41 CEST] <nicolas_> in the lowest network function, there is a test : "if (ff_check_interrupt(int_cb))" which make things not working
[21:36:09 CEST] <nicolas_> i can : or remove this check, but i think that it could be usefull for something else, or
[21:36:47 CEST] <nicolas_> add a parameter "force" to low network functions, but it touches the network.c of ffmpeg, so i guess you would not accept it easily
[21:37:50 CEST] <nicolas_> the thing is that testing if the user requesting to quit in this function it not valid with the fact that rtsp protocol require network packet sending at the disconnection.
[21:38:26 CEST] <BtbN> Mentioning what bug you are even trying to fix would be a good start.
[21:39:25 CEST] <nicolas_> let me find the number in the tracker, but in one word : ffmpeg is currently not sending the tearing down packet at the disconnection.
[21:39:55 CEST] <nicolas_> https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
[21:40:53 CEST] <nicolas_> [FFmpeg-trac] #4929
[21:46:36 CEST] <ubitux> nicolas_: fastest way to get feedback: see "contribute" on ffmpeg.org on how to suggest changes
[21:46:47 CEST] <ubitux> (in case you don't get any feedback here)
[21:48:04 CEST] <ubitux> atomnuker: it's really braindead; like, i'm able to trigger the crash only with http://pastie.org/10491407 now (or basically by just shuffling the code around)
[21:51:41 CEST] <kierank> How do you deal with functions with > 8 arguments?
[21:52:47 CEST] <J_Darnley> They're on the stack
[21:53:09 CEST] <kierank> Are there any docs about how to use the stack (or good examples of stack use)
[21:54:47 CEST] <nicolas_> ubitux, ok, prefered way is the mailing list ?
[21:55:01 CEST] <ubitux> nicolas_: for sending patch, yes
[21:55:17 CEST] <J_Darnley> Yadif uses it as does removegrain.
[21:55:30 CEST] <J_Darnley> Whether they're clear or not I'm not sure
[21:55:59 CEST] <J_Darnley> Basically: you ask for some as the 5th argument to cglobal
[21:56:13 CEST] <J_Darnley> then you have it available starting at [rsp]
[21:56:28 CEST] <kierank> I am going to just try and implement blend_pixel to begin with
[21:59:29 CEST] <cone-384> ffmpeg 03Kyle Swanson 07master:32403d1fabb6: avfilter/af_flanger: free frame on ENOMEM
[22:02:15 CEST] <atomnuker> ubitux: weird
[22:08:03 CEST] <ubitux> atomnuker: btw, you can most likely remove the div in the corr and max_ratio calc and take it out of the 2 loops 
[22:08:52 CEST] <ubitux> the corr div might be tricky
[22:09:34 CEST] <ubitux> maybe you can just drop the sqrt (and do it once outside the loop)
[23:11:16 CEST] <kierank> J_Darnley: In "cglobal yadif_filter_line, 4, 7, 8, 80," what does the 80 mean?
[23:11:49 CEST] <J_Darnley> 80 bytes of stack space will be reserved.
[23:12:42 CEST] <kierank> ah ok in bytes
[23:12:51 CEST] <kierank> just checking
[23:13:56 CEST] Action: J_Darnley opens the code
[23:16:46 CEST] <J_Darnley> The mmsize define can be used there to vary the space based on the SIMD register width
[23:19:10 CEST] <kierank> And so you use [rsp+offset] to signal the args which haven't been loaded into registers?
[23:19:32 CEST] <J_Darnley> Yes
[23:20:11 CEST] <J_Darnley> but it is probably better to use rXm or rXmp to access where they should be
[23:20:11 CEST] <kierank> Is it possible to control which args go into registers apart from the first n
[23:20:15 CEST] <kierank> ok
[23:20:28 CEST] <J_Darnley> and no
[23:20:36 CEST] <jamrial> you don't need to reserve stack space for function arguments
[23:20:58 CEST] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/drawutils.c;h=91fffd5e065749459a6fdf7ee0bcbb3059ec2dd7;hb=HEAD#l410
[23:21:06 CEST] <kierank> I don't need dst in a register for example
[23:21:56 CEST] <J_Darnley> If it helps you then I suggest you make the argument order fit your needs
[23:22:05 CEST] <kierank> ah I see
[23:23:01 CEST] <J_Darnley> I also suggest you pass strides/linesizes as ptrdiff_t
[23:34:11 CEST] <kierank> where does my allocated stack space start?
[23:34:15 CEST] <kierank> do I have to work it out?
[23:34:27 CEST] <nevcairiel> i think you can deduct from the stack pointer or something
[23:34:53 CEST] <Gramner> [rsp] to [rsp+<whatever amount you allocated>]
[23:35:08 CEST] <kierank> I see
[23:37:16 CEST] <kierank> what does rXmp mean?
[23:37:35 CEST] <nevcairiel> argument X's native position in native size
[23:37:54 CEST] <kierank> and without the p?
[23:38:06 CEST] <nevcairiel> not native size
[23:38:28 CEST] <nevcairiel> (ie dword)
[23:38:34 CEST] <Gramner> without size specified actually
[23:39:04 CEST] <Gramner> it's just a memory reference, e.g. [rsp+<some value>]
[23:39:14 CEST] <kierank> but yasm doesn't know the size of the elements in between either?
[23:40:13 CEST] <J_Darnley> I don't understand the question.
[23:40:43 CEST] <Gramner> stack arguments smaller than the native size are aligned to the native size, and the padding bytes are undefined if that's what you're asking
[23:40:50 CEST] <kierank> oh i see
[23:41:55 CEST] <Gramner> that's also why you should use ptrdiff_t instead of int for strides, otherwise the upper 32 bits are undefined and you need to manually clear them to use them safely
[23:43:03 CEST] <kierank> so can I do "dec rXmpd"?
[23:43:06 CEST] <kierank> is that allowed?
[23:43:43 CEST] <J_Darnley> Probably
[23:43:54 CEST] <nevcairiel> doesnt sound like something you can do
[23:44:00 CEST] <J_Darnley> Many arithmetic instructions can work with memory
[23:44:10 CEST] <kierank> but the height is an int
[23:45:17 CEST] <nevcairiel> rXm should be  dword, or so the docs in x86inc.asm claim
[23:45:29 CEST] <nevcairiel> ; rNm is the original location of arg N (a register or on the stack), dword
[23:46:32 CEST] <J_Darnley> The intel ref manual says dec can operate on memory
[23:46:36 CEST] <Gramner> oh yeah, that comment is wrong then
[23:47:11 CEST] <Gramner> note the code below where they are defined and you'll see that they have no specific size
[23:47:31 CEST] <nevcairiel> interestingly if rNm points to a register, it does reference to rNd
[23:47:53 CEST] <Gramner> yes, you need to specify a size for registers
[23:48:04 CEST] <Gramner> that comment could be clarified a bit I guess
[23:49:21 CEST] <nevcairiel> so how would he create a dword ref to rNm? use "dword r1m" as the operand?
[23:49:57 CEST] <Gramner> yes, if you need to specify a size, but that's fairly rare
[23:50:24 CEST] <Gramner> usually the size is implied by the instruction or a register that's part of the instruction
[23:50:47 CEST] <nevcairiel> makes sense
[23:52:08 CEST] <nevcairiel> kierank: sounds like you want to keep your loop counter on the stack, that seems somewhat inefficient to me tbh .. but if you're that low on regs..
[23:53:01 CEST] <kierank> Dunno, just trying to do what I'd usually do. dec rN jg .loop
[23:53:28 CEST] <nevcairiel> and you're out of regs to store it in one?
[23:53:42 CEST] <kierank> I am anticipating I will be
[23:55:07 CEST] <nevcairiel> it should be possible to do that with "dec dword rXm" from what i understand (now), but still seems unusual
[23:56:16 CEST] <jamrial> not really. it's done quite a bit on x86_32 functions when 7 gprs are not enough
[23:56:50 CEST] <Gramner> yes, it's possible. but it requires a load-modify-store, so it's significantly slower than having it in a register. OOE might hide the latency though
[23:57:21 CEST] <kierank> maybe I should just write x64 first
[23:57:40 CEST] <Gramner> that's usually easier, yes
[23:57:57 CEST] <kierank> I think I'll still need stack though
[23:58:02 CEST] <kierank> lots of random values
[23:58:35 CEST] <Gramner> 16 vector regs and 15 gprs not enough?
[23:58:39 CEST] <Gramner> (for x64)
[23:59:07 CEST] <kierank> got 10 arguments
[00:00:00 CEST] --- Mon Oct 19 2015