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

[burek]

[00:00:18 CET] <atomnuker> I haven't figured out how to do the part afterwards, where for i >= val you go the other way
[00:04:52 CET] <BBB> ty!
[00:05:15 CET] <j-b> atomnuker: \o/
[00:05:19 CET] <BBB> well I think you do both right?
[00:05:32 CET] <BBB> and then you mask them based on val
[00:05:34 CET] <BBB> and then you or them
[00:05:40 CET] <BBB> thats how I would do it at least
[00:06:26 CET] <BBB> but gramner is better at this than me
[00:09:13 CET] <atomnuker> yeah, I suppose I could splat the val across a reg, then run a compare, and convert the output of that into a mask
[00:10:07 CET] <atomnuker> then using that I could combine the 2 paths
[00:10:16 CET] <BBB> you can also do what I did in cdef/lr
[00:10:33 CET] <BBB> have a 64 byte constant times 32 db 0xff times 32 db 0x0
[00:10:37 CET] <BBB> and then index into that using val
[00:10:44 CET] <BBB> its almost the same
[00:11:08 CET] <cone-547> ffmpeg 03Mark Thompson 07master:edcdf3512376: cbs_vp9: Ensure that reserved zero bits are actually zero
[00:11:28 CET] <BBB> but what yousaid works also, yes
[00:21:28 CET] <atomnuker> https://0x0.st/sIHr.jpg
[00:21:36 CET] <atomnuker> yep, gimp still works even though I've never used it
[00:43:22 CET] <kierank> durandal_1707: sucks
[00:43:25 CET] <kierank> adding bayer to swscale
[00:43:27 CET] <kierank> mess on top of mess
[01:11:14 CET] <cone-547> ffmpeg 03James Almer 07master:ec440339b2cd: avcodec/cbs_vp9: keep track of reference frames
[01:11:15 CET] <cone-547> ffmpeg 03James Almer 07master:7aaf092f8ce8: avcodec/cbs_vp9: store profile in the private context
[01:13:04 CET] <jamrial> jkqxz: only thing that remains would be to add frame_type to VP9ReferenceFrameState
[01:14:03 CET] <jamrial> it's not contemplated in the spec, but without it, an avparser can't feasibly set pict_type for frames with show_existing_frame = 1
[01:14:54 CET] <BBB> show_existing_frame is by definition an inter frame, right?
[01:14:55 CET] <jamrial> the decoder for example keeps avframe references instead of a custom struct like VP9ReferenceFrameState, which has that and more
[01:15:00 CET] <BBB> its what vc1 calls a pskip frame
[01:15:11 CET] <BBB> it copies the whole reference with no motion or residual
[01:15:13 CET] <jamrial> it can point to invisible frames, which can be intra_only
[01:15:14 CET] <BBB> thats still inter:)
[01:15:23 CET] <BBB> the reference of the frame is intra
[01:15:27 CET] <BBB> but the frame itself is inter
[01:15:35 CET] <BBB> its just specially coded
[01:15:56 CET] <BBB> or you want to point out keyframe search poiints using this?
[01:16:09 CET] <BBB> I would say the keyframe search point is the invisible frame, not the show-existing-frame making it visible
[01:16:10 CET] <jamrial> show_existing_frame is literally a 1 byte frame that says "present this old frame"
[01:16:56 CET] <jamrial> in av1 it certainly can be intra, as it's the case with delayed RAPs
[01:26:38 CET] <BBB> right, I know
[01:26:46 CET] <BBB> I just wonder why you want to annotate them as such
[01:26:51 CET] <BBB> you cant actually seek to the show-existing-frame
[01:27:03 CET] <BBB> you can seek to the invisible frame, skip the next few frames that reference frames beforeit
[01:27:06 CET] <BBB> and then show it
[01:27:12 CET] <BBB> and then go from there
[01:27:18 CET] <BBB> but the seek is not to the show-existing-frame then
[01:27:21 CET] <BBB> so ...
[01:27:26 CET] <BBB> its complicated ;)
[01:28:35 CET] <jamrial> BBB: i'm trying to port the parser to cbs, to export more fields than just profile
[01:29:03 CET] <BBB> oh so its just metadata, not for seeking or anything input to the muxer?
[01:29:04 CET] <jamrial> since reimplementing parsing code to handle super frames, keeping track of references and such is annyoning
[01:29:08 CET] <jamrial> yeah
[01:29:34 CET] <jamrial> so i want to set AVCodecParserContext.pict_type correctly for all frames
[01:51:20 CET] <jkqxz> It seems like it depends on what you are going to use it for.
[01:51:28 CET] <jkqxz> If you are looking at packets then the superframe containing an invisible key frame is obviously itself key - making the displayed actually-non-key frame the one that gets marked as key, while the later-displayed actually-key frame doesn't.
[01:51:45 CET] <jkqxz> Whereas if you are looking at frames only then it's more logical for it to be the other way around.
[01:52:02 CET] <jkqxz> It seems like the first interpretation is more useful, though, since that's what you actually want for seeking purposes?
[01:53:46 CET] <jkqxz> (At least we don't have the wrangle with the wtf confusing thing in AV1 where the IDRalike frame only flushes the DPB when it's shown, not when it's decoded.)
[02:48:22 CET] <jamrial> BBB, jkqxz: like this https://github.com/jamrial/FFmpeg/commit/c4dc8cffcdcaae3d489ed991fa7b267fbaad4f90
[02:49:00 CET] <jamrial> pretty much the same as the av1 parser
[02:55:38 CET] <BBB> yeah I guess
[02:55:46 CET] <BBB> (still a cbs n00b)
[02:55:49 CET] <BBB> (me)
[03:01:36 CET] <jamrial> BBB: it's really neat and powerful. it parses everything for you
[03:01:45 CET] <jamrial> you just then read some values and export metadata, or you change them then output it all as a new frame where the new value is neatly written without fucking up the bitstream
[03:02:04 CET] <jamrial> props to jkqxz for writing it :p
[03:04:59 CET] <jamrial> it's ideal for bitstream filters and parsers for obvious reasons, but also can be used in decoders to handle the header bitstream parsing. each frame's tile/slice data is also handed to you as an avbufferref
[03:08:46 CET] <BBB> Ill play with it at some point
[03:08:53 CET] <BBB> might be useful for the stream analyzer going forward
[03:09:09 CET] <BBB> the amount of code in there right now related to header parsing is just awful
[03:44:53 CET] <cone-547> ffmpeg 03ManojGuptaBonda 07master:4a6d5f3cadaa: avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
[11:52:42 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:323c2cfd384a: avfilter: add (a)graphmonitor filter(s)
[14:54:25 CET] <pasouza> hi, I'd like to know the right procedure for reimbursement request (GSoC mentor summit)
[14:58:21 CET] <durandal_1707> write it to ML
[15:00:26 CET] <Compn> include invoice
[15:00:38 CET] <Compn> who you mentored, project worked on, etc
[15:00:43 CET] <Compn> committed status
[16:02:23 CET] <pasouza> ok, thanks!
[16:04:00 CET] <pasouza> can I email the invoice privately? as it may contain personal info
[16:40:01 CET] <durandal_1707> pasouza: do not include invoice, there are already siimilar mails available in archive
[17:34:19 CET] <akravchenko188> jkqxz: hi, could you please answer on my comments in forum?. Probably I can remove amf logging on this stage, and decide later how to integrate it
[17:36:16 CET] <akravchenko188> jkqxz: there are some customers, who need hw pipeline in FFMpeg (hwdecode -> scaler -> encode) and we have hwcontext_amf blocker for this
[17:38:21 CET] <akravchenko188> jkqxz: it would be very nice if we try to speed up the integration process
[19:08:24 CET] <durandal_1707> why is everything is so silent?
[19:24:03 CET] <jamrial> it's spooky day
[19:25:41 CET] <atomnuker> its cold
[19:58:26 CET] <atomnuker> how do I right shift a gpr with a value from another gpr? shr only accepts constants
[20:00:09 CET] <nevcairiel> they accept register CL
[20:00:18 CET] <nevcairiel> and only that
[20:01:01 CET] <atomnuker> register cl?
[20:01:22 CET] <nevcairiel> its an 8-bit slice o f RCX
[20:03:16 CET] <atomnuker> wow, that's bad design
[20:07:04 CET] <jamrial> atomnuker: if you're targeting avx2, use shrx
[20:08:19 CET] <nevcairiel> not sure using a super vex instruction is really worht it =p
[20:08:24 CET] <nevcairiel> super long*
[20:10:04 CET] <jamrial> it's like five bytes instead of three or four from shr. it's not that bad
[20:10:31 CET] <jamrial> and you can use any gpr with it
[20:12:49 CET] <atomnuker> no, I choose maximum efficiency and least readibility, I'll make it so cl (r3b) ends up as my final shift amount
[20:34:04 CET] <jamrial> maximum efficiency and least readibility <-- the ffmpeg way :p
[20:36:25 CET] <atomnuker> didn't need to do it in the first place, I remembered I didn't need variable right shifts after all
[20:36:41 CET] <atomnuker> I'll just use psrlw
[20:37:08 CET] <atomnuker> ...which I can't because it takes either a constant or a memory address
[20:37:48 CET] <atomnuker> what were intel smoking, vectors are nice but then gprs are inflexible crap
[20:38:08 CET] <atomnuker> shenzhen io's assembler had more flexible gprs than this
[20:46:21 CET] <atomnuker> wait, psrlw m3, xm3 works?
[20:50:27 CET] <BBB> atomnuker: yes!
[20:50:30 CET] <BBB> atomnuker: but its slow
[20:50:49 CET] <BBB> atomnuker: because its crosslane, it takes the first qword (!?!?!?!?!?) from xm3 to shift all words (in both lanes) in m3
[20:51:14 CET] <BBB> and if the qword >= 16, itll set everything to 0
[20:51:24 CET] <BBB> which, given that theyre words (possibly non-zero), is quite likely
[20:52:38 CET] <atomnuker> I think it'll be faster than giving it a memory argument, plus I'd have to either bloat my grps to 7 (since r6m exists) or reserve some stack
[20:57:54 CET] <BBB> for me, stack mem wa sfaster
[20:57:59 CET] <BBB> probably because no cross-lane
[21:00:54 CET] <atomnuker> can't do a dumb 1 to 1 look up table either, it requests fpic
[21:01:18 CET] <atomnuker> honestly what the fuck intel, why did they not make it accept gprs
[21:12:30 CET] <BBB> lea r6, [table]
[21:12:45 CET] <BBB> mov r5d, dword [r6+idx*2]
[21:12:46 CET] <BBB> or whatever
[21:12:53 CET] <BBB> its annoying yes
[22:22:16 CET] <kurosu_> shr design is older than you, respect your elders :p
[22:28:58 CET] <atomnuker> I wonder if the 68000 had the same level of flag abuse and opaqueness
[22:34:26 CET] <cone-330> ffmpeg 03Michael Niedermayer 07master:793a3e7bc909: doc/fate.texi: Mention that samples should be uploaded before pushing dependent commits
[22:39:25 CET] <cone-330> ffmpeg 03Mark Thompson 07master:30fcc1093796: cbs_h264: Include SEI type names in trace output
[22:39:26 CET] <cone-330> ffmpeg 03Mark Thompson 07master:2dee0679e9a8: cbs_h265: Add PTL parsing for Main 10 Still Picture profile
[23:46:20 CET] <nevcairiel> atomnuker: for the record, which actual register actually backs r0-r14 in x86inc.asm code varies between platforms, because it prefers those it doesnt have to save, so r3b is only CL on unix64, on 32-bit its  r1b and on windows64 its r0b, but i see you're not using it anymore anyway
[23:50:38 CET] <nevcairiel> some code in avcodec even uses SHR with a CL argument, it has 3 different register assignments in there for the 3 cases
[23:56:34 CET] <atomnuker> yeah, I thought so too
[00:00:00 CET] --- Thu Nov  1 2018