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

[burek]

[00:04:01 CEST] <Chloe> durandal_1707: figure it out?
[00:04:37 CEST] <Chloe> Rip
[00:14:33 CEST] <klaxa> jdarnley: do you think this is okay or should i really move everything ping-pong between C lua and C? https://gist.github.com/klaxa/6d3aa0127b311dcc79d88f89cc15accf
[00:16:17 CEST] <klaxa> configs_read() now loads the lua file, the parser function and then calls it with pcall, the parser function fills a file-scope variable with the config and returns the number of configs and raises luaL_error() on errors
[00:16:18 CEST] <klaxa> number of configs is kind of misleading, it's the number of configured servers
[00:16:53 CEST] <klaxa> hmm good thing i see *now* that my editor is messing up tabs and spaces
[00:17:00 CEST] <jdarnley> :)
[00:17:28 CEST] <jdarnley> change the second "Unable to read config file" to "parse"
[00:17:52 CEST] <jdarnley> I don't object to the global var but it should be static
[00:18:01 CEST] <klaxa> right
[00:18:02 CEST] <klaxa> ok
[00:19:27 CEST] <jdarnley> Oh, I guess if it isn't a library it doesn't matter whether it is static or not.
[00:19:58 CEST] <klaxa> why would it be different if it was a library?
[00:20:33 CEST] <jdarnley> Things that aren't static are "public"
[00:20:53 CEST] <klaxa> ah, didn't realize static made things "private"
[00:21:34 CEST] <jdarnley> In this case it limits it to just the scope of the file.
[00:22:09 CEST] <jdarnley> I think static is a bit overloaded in meaning in C
[00:22:30 CEST] <jdarnley> But that might just be because I've never read the technical definition of it.
[00:22:53 CEST] <klaxa> and being taught mostly java in uni doesn't help
[00:23:20 CEST] <jdarnley> I definitely don't mean it in the object oriented sense
[00:23:34 CEST] <jdarnley> ... of public/private
[00:23:43 CEST] <klaxa> yeah, it's just differently used in different contexts
[00:25:30 CEST] <klaxa> well, thanks for that explanation, that made it a bit clearer :=
[00:25:33 CEST] <klaxa> :)
[01:29:29 CEST] <klaxa> can av_realloc() fail on shrinking?
[01:37:52 CEST] <nevcairiel> all calls to it should be considered possible to fail
[01:38:06 CEST] <nevcairiel> you dont know what an allocator might try to do
[01:39:16 CEST] <klaxa> hmm yeah that's what i thought...
[01:45:35 CEST] <klaxa> oh god i have so many unchecked allocations....
[02:02:16 CEST] <atomnuker> jkqxz: so I'm trying to map DRM to VAAPI and I'm hitting the "av_assert0(i < FF_ARRAY_ELEMS(vaapi_format_map));" assert
[02:02:40 CEST] <atomnuker> do you happen to know why with VA_FOURCC_BGRX it fails to find a va_rt_format?
[02:03:05 CEST] <atomnuker> earlier today a few people in #mpv hit the same issue (on amd and i915)
[02:03:20 CEST] <atomnuker> though they used ffmpeg.c and I'm using the api
[02:04:02 CEST] <atomnuker> it makes no sense since there's a BGRX entry in vaapi_format_map
[02:13:39 CEST] <jkqxz> Blech, it always fails.  Clearly wasn't tested at all.
[02:14:35 CEST] <jkqxz> Will fix.
[02:20:53 CEST] <cone-014> ffmpeg 03Mark Thompson 07master:8ef51a4092a5: hwcontext_vaapi: Fix mapping from DRM
[02:20:58 CEST] <jkqxz> atomnuker:  ^
[02:38:21 CEST] <atomnuker> thanks, awesome
[02:38:32 CEST] <atomnuker> can you backport to whatever release branch it applies to?
[02:42:37 CEST] <jkqxz> It's not on any release branch.
[02:58:03 CEST] <atomnuker> that code's been there for about a year now, hasn't it? should at least apply to 4.0
[02:59:09 CEST] <nevcairiel> it was only broken recently by the added assertion
[05:49:24 CEST] <cone-969> ffmpeg 03Colin NG 07master:9aee574dd092: avformat/dashdec: Fix for ticket 7149 (Segfault when decoding dash streams)
[05:49:24 CEST] <cone-969> ffmpeg 03Colin NG 07master:93fc96e1997d: avformat/dashdec: Fix for ticket 7149 (Segfault when decoding dash streams)
[05:49:24 CEST] <cone-969> ffmpeg 03Steven Liu 07master:04b6060616b0: avformat/dashdec: replace user-agent to user_agent for deprecate warning message
[05:56:32 CEST] <cone-969> ffmpeg 03Steven Liu 07master:50df4c958b64: avformat/hlsenc: support http method for hls fmp4
[13:50:29 CEST] <kierank> gagandeep: what are you working on now
[13:55:58 CEST] <gagandeep> kierank: i think i just figured out for group decoding
[13:56:25 CEST] <kierank> you mean the 3d transform?
[13:56:27 CEST] <gagandeep> its spatial inverse for the num_spatial times, then inverse temporal
[13:56:30 CEST] <gagandeep> yeah
[13:56:46 CEST] <gagandeep> after that we get two fields even and odd from inverse spatial
[13:56:47 CEST] <kierank> ok, well I guess try and get the mountain clip to work
[13:56:51 CEST] <kierank> fields?
[13:56:54 CEST] <kierank> ok
[13:57:30 CEST] <gagandeep> then inverse spatial is performed on both fields along with the necessary subbands
[13:57:37 CEST] <gagandeep> and we get two frames back
[13:58:08 CEST] <gagandeep> this is the basic, and again i am seeing optimizations
[13:58:34 CEST] <gagandeep> so those will take time to work out properly but i think by sunday, i should have a non threaded version running
[13:59:27 CEST] <gagandeep> kierank: i meant to say two fields from inverse temporal
[13:59:45 CEST] <kierank> forget about threading for now, yes
[13:59:51 CEST] <kierank> just valid pictures
[14:00:26 CEST] <gagandeep> yeah, and later will need to get an interlaced ip version working as well, cause this was for progressive
[14:01:05 CEST] <kierank> dunno if we have interlaced temporal samples
[14:01:26 CEST] <gagandeep> i have from david newman, he gave me that when i asked for interlaced
[14:01:56 CEST] <gagandeep> really a nice person :)
[14:02:14 CEST] <kierank> ah ok
[14:03:29 CEST] <gagandeep> ok, anything else you want to ask right now
[14:05:03 CEST] <gagandeep> i think like in interlaced, ip frame will cause problems with hand optimizations as well
[14:05:03 CEST] <kierank> nop
[14:05:31 CEST] <gagandeep> now i see they are also using a lossless encoding for one subband in ip
[14:05:58 CEST] <gagandeep> will report later on this lossless
[14:19:53 CEST] <jdarnley> I've got a bit of a brain freeze.
[14:19:59 CEST] <jdarnley> The result of uint64_t * int32_t is uint64_t but what if the int32_t is negative?
[14:20:04 CEST] <jdarnley> For example: -1, does that become 0xFFFFFFFF before the multiply?
[14:21:38 CEST] <nevcairiel> your int32_t is converted to an unsigned type with allt he rules that go with it
[14:25:00 CEST] <nevcairiel> ie it probably turns into 64-bit FF's, not just 32-bit, i think?
[14:28:14 CEST] <jdarnley> ah, yes, hm
[14:40:19 CEST] <jdarnley> Yep, a quick test of 1 * -1 gives UINT64_MAX
[14:42:55 CEST] Action: jdarnley facepalms
[14:43:01 CEST] <jdarnley> that was all pointless
[14:43:26 CEST] <jdarnley> There's an FFABS on the int32_t
[14:43:49 CEST] <nevcairiel> lol
[14:43:59 CEST] <jdarnley> Thank you anyway
[14:44:09 CEST] <nevcairiel> the more you know
[14:44:31 CEST] <jdarnley> ... and knowing is half the battle!
[15:01:08 CEST] <jdarnley> oh, shit!  I forgot that you need avx512 for a 64-bit multiply
[15:01:59 CEST] <jdarnley> no pmullq
[15:03:47 CEST] <jdarnley> oh, I might not need to
[15:04:34 CEST] <jdarnley> move a left shift of 2 after the multiply and I can get away with pmuludq
[15:19:58 CEST] <durandal_1707> jdarnley: writting simd for what?
[15:20:16 CEST] <jdarnley> vc2 coeff quant
[15:20:27 CEST] <jdarnley> well, part of the quant
[15:20:47 CEST] <jdarnley> no, the whole quant, which is onyl part of the coeff coding
[15:21:22 CEST] <jdarnley> If you want to see, look for the QUANT macro in vc2enc.c
[15:28:41 CEST] <kierank> I would imagine transforms would be more interesting 
[15:28:44 CEST] <kierank> but up to you
[15:29:09 CEST] <jdarnley> Maybe, but they don't take much time compared to the coeff quant
[15:35:03 CEST] <kierank> are you thinking of unpacking to a buffer then dequanting in one go?
[15:35:06 CEST] <kierank> in two goes
[15:35:10 CEST] <kierank> might not be fast
[15:35:14 CEST] <kierank> after unpack data is in cache
[17:08:35 CEST] <jdarnley> Gah!  Its been so long since I did any assembly I've forgotten half the instructions available.
[17:35:05 CEST] <jdarnley> Is there a simple instruction to pack quadwords from to 2 regs into 1 reg?
[17:43:05 CEST] <jamrial> jdarnley: i think nothing before avx512
[17:43:41 CEST] <jdarnley> Right, shifts and shuffles
[17:53:37 CEST] <iive> quadword is 64 bit, isn't it?
[17:53:58 CEST] <iive> it would be movhps or movlps on sse then.
[18:24:17 CEST] <cone-596> ffmpeg 03Carl Eugen Hoyos 07master:7c333dc6a7fe: doc/codecs: Remove option sc_factor.
[21:44:06 CEST] <Gramner> jdarnley: punpck(l|h)qdq?
[21:45:49 CEST] <Gramner> or do you mean convert qwords to dwords?
[21:46:24 CEST] <Gramner> for the latter you can use shufps if truncation is fine
[00:00:00 CEST] --- Fri May 25 2018