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

[burek]

[00:49:26 CEST] <llogan> michaelni: what's the reason we can't use PayPal for donations? IIRC, you mentioned the reasoning before. This is regarding the "Not a mail listing category suitable" email to devel-owner.
[00:54:38 CEST] <michaelni> llogan, i am not sure what you refer to. There may have been some issue with SPI and paypal but i dont remember exactly. But checking i see paypal on https://www.spi-inc.org/projects/ffmpeg/, maybe we need to update our donation page
[00:58:59 CEST] <llogan> michaelni: looks like donations page does need an update then. sorry, i meant the email asking about this was sent to ffmpeg-user-owner. i'll reply to it and CC.
[01:46:41 CEST] <cone-457> ffmpeg 03James Almer 07master:bf324359be8d: avcodec/vp9_parser: set profile in AVCodecContext
[09:27:46 CEST] <akravchenko188> Hello, guys. back to topic about testing and applying patches for amf support (hwcontext_amf, scaler_amf), were sent July
[09:28:27 CEST] <akravchenko188> is there anybody who can review it and give some feedback?
[09:30:05 CEST] <akravchenko188> is there still issue with missing AMD cards? How such issue solved here?
[10:13:35 CEST] <cone-083> ffmpeg 03kjeyapal at akamai.com 07master:de43c227fd7d: avformat/dashenc: Support HTTP persistent for init segments as well
[12:47:27 CEST] <cone-083> ffmpeg 03Paul B Mahol 07master:4fcfb9c4ebf3: avfilter: add xstack filter
[12:49:23 CEST] <kierank> Jaex: 
[12:49:24 CEST] <kierank> January: 
[12:49:25 CEST] <kierank> Writing objects: 100% (15/15), 11.71 KiB | 0 bytes/s, done.
[12:49:25 CEST] <kierank> Total 15 (delta 11), reused 4 (delta 2)
[12:49:25 CEST] <kierank> remote: -Info-          Update is fast-forward
[12:49:25 CEST] <kierank> remote: -Deny-          In e0727068bc6392625a015e47b3399d0c5be4f567:
[12:49:25 CEST] <kierank> remote: -Deny-          Trailing whitespace found in tests/api/api-h264-slice-test.c.
[12:49:25 CEST] <kierank> remote: -Deny-          Commit aborted, fix the issue and try again.
[12:49:26 CEST] <kierank> remote: error: hook declined to update refs/heads/master
[12:49:26 CEST] <kierank> To git at source.ffmpeg.org:ffmpeg
[12:49:27 CEST] <kierank>  ! [remote rejected] master -> master (hook declined)
[12:49:27 CEST] <kierank> error: failed to push some refs to 'git at source.ffmpeg.org:ffmpeg'
[12:50:07 CEST] <January> you didn't need to spam with the entire log
[12:52:17 CEST] <cone-083> ffmpeg 03Josh de Kock 07master:0a055f463a60: lavc/h264dec: don't error out when receiving multiple IDR slices
[12:52:18 CEST] <cone-083> ffmpeg 03Josh de Kock 07master:fb7925ba2fa1: fate: add api-h264-slice test
[12:54:58 CEST] <kierank> and now we wait
[13:41:57 CEST] <cone-083> ffmpeg 03Cameron Cawley 07master:22238d0b9440: avcodec: Implement Archimedes VIDC encoder/decoder
[13:41:58 CEST] <cone-083> ffmpeg 03Cameron Cawley 07master:0e9c01fd87ae: avformat/rpl: Support files containing 8 bit PCM or VIDC audio
[14:47:13 CEST] <kierank> January: bah 0a055f463a60af764c083fd0ba3112037557de4b commit message is wrong
[14:47:23 CEST] <kierank> you keep conflating "slice threading" with chunks
[14:48:43 CEST] <January> it was on the mailing list for a long time, and you pushed it, so not really sure what to say
[14:49:53 CEST] <kierank> I'm telling you to be more precise in your wording in the future
[14:55:33 CEST] <durandal_1707> oh, some popcorn time finally
[14:56:05 CEST] <durandal_1707> rm -rf mediafoundation*
[15:00:18 CEST] <January> durandal_1707: you dont want meadiafoundation?
[15:02:25 CEST] <durandal_1707> i do not want mediafoundation,video/audio/toolbox, and other corporate crap
[15:03:22 CEST] <atomnuker> the mf wrapper doesn't even output hardware frames
[15:03:51 CEST] <atomnuker> you can't get good performance with it or good battery life, for that you need the built in decoders we have
[15:04:21 CEST] <JEEB> for decoding you don't really need MF unless you need swdec
[15:04:29 CEST] <JEEB> for hwdec we have dxva2 and d3d11va for windows
[15:05:06 CEST] <atomnuker> the guy states one of the goals is to have a non-gpl h264 encoder and doesn't even mention evading patent fees
[15:05:29 CEST] <January> atomnuker: m$ doesnt pay them?
[15:07:14 CEST] <nevcairiel> Windows doesnt come with a h264 encoder
[15:07:54 CEST] <JEEB> atomnuker: for non-GPL we have openh264 and in theory you can utilize binaries from cisco for that (although I think that requires dload or so since the install has to download it from cisco)
[15:07:55 CEST] <nevcairiel> unless that changed recently
[15:08:09 CEST] <JEEB> (latter to even evade the MPEG-LA stuff)
[15:08:18 CEST] <JEEB> but yea (´4@)”
[15:08:31 CEST] <atomnuker> nevcairiel: the patch says there is: encoders:   * video: h264_mf, hevc_mf
[15:09:13 CEST] <atomnuker> January: I think they're included in the license for windows but you have to use them and not some other implementation if you don't want to pay patent fees
[15:09:57 CEST] <JEEB> the distributor to end users pays so yea, if you distribute another thing that's your problem
[15:10:34 CEST] <JEEB> which is why people have loved DShow and MF, you can kind of externalize the problem since you're just generally asking for some format in the framework and "I didn't distribute the thing that gives me this stuff"
[15:10:38 CEST] Action: JEEB sighs
[15:11:05 CEST] <atomnuker> will there be a CCCP release for mf :)
[15:11:26 CEST] <JEEB> MF doesn't have real players etc
[15:11:28 CEST] <nevcairiel> noone but  MS themselfes really uses MF
[15:11:41 CEST] <JEEB> yea, nevcairiel tried to make a player but it was a chick n' egg problem
[15:11:50 CEST] <JEEB> nevcairiel: I've seen some people distribute MF filters but yea - it's rare as hell
[15:14:05 CEST] <atomnuker> there's already a player, isn't there? windows media player
[15:14:25 CEST] <JEEB> that is heavily hard-coded towards MS filters
[15:14:28 CEST] <JEEB> even for DShow
[15:14:50 CEST] <nevcairiel> not sure how it works with MF, but in DShow you can make it use any system filters
[15:14:51 CEST] <JEEB> it seems to be like: hard-coded for MF if MS MF filters support something => fall back to DShow MS filters => fall back on 3rd party DShow filters
[15:15:01 CEST] <JEEB> nevcairiel: yea unofficially you can tweak it
[15:15:02 CEST] <nevcairiel> the MS filters just often have very high priorities
[15:15:24 CEST] <JEEB> I thought there was something in addition to priorities
[15:15:29 CEST] <JEEB> actual UUID things
[15:15:40 CEST] <JEEB> don't remember, was long enough ago when I last loked into details of that tweak :P
[16:21:34 CEST] <philipl> nevcairiel: FYI, I looked at fps cost of my cuda yadif when not doing frame doubling and it's negligible. Looking back I realise that I saw a 50% slowdown with frame doubling because the encoder was working twice as much. Need to test without encoding... silly me
[16:37:36 CEST] <J_Darnley> can I generate a strobe video with lavfi easily?  A video which alternates between black and white every frame?
[16:42:24 CEST] <J_Darnley> maybe just two color sources and an interleave
[16:42:32 CEST] <durandal_1707> J_Darnley: ffmpeg -f lavfi -i color=black -f lavfi -i color=white -lavfi hstack,stereo3d=sbsl:al,trim=duration=1 1.y4m
[16:43:03 CEST] <JEEB> that's an interesting way... can't you just interleave two inputs?
[16:43:09 CEST] <JEEB> frame-wise
[16:43:25 CEST] <JEEB> without going through horizontal stacking and then stereo3d doing the interleaving :D
[16:46:22 CEST] <J_Darnley> does interlave double the framerate?  Two 30fps becomes 60 fps?
[16:49:14 CEST] <durandal_1707> J_Darnley: ffmpeg -f lavfi -i color=black -f lavfi -i color=white -lavfi "interleave,settb=1/25,setpts=N,showinfo,trim=end_frame=100" 1.y4m
[16:49:55 CEST] <J_Darnley> Thanks for the suggestions but I went with ffplay -f lavfi -i 'color=black:r=30 [a]; color=white:r=30 [b]; [a][b] interleav
[16:49:59 CEST] <durandal_1707> without settb and setpts it is memory bomb for some reason
[16:51:08 CEST] <durandal_1707> J_Darnley: did you just bombed your machine?
[16:51:19 CEST] <J_Darnley> No
[16:51:25 CEST] <durandal_1707> good :)
[16:52:20 CEST] <J_Darnley> htop says ~7% cpu and 0.7% memory
[16:53:39 CEST] <J_Darnley> Well, that didn't help anyway
[16:56:10 CEST] <durandal_1707> what are you doing?
[16:58:26 CEST] <atomnuker> throwing a rave?
[16:58:48 CEST] <J_Darnley> Trying to work out what the heck kind of packing this dumb professional video format is doing
[16:58:59 CEST] <philipl> nevcairiel: so I'd say it's ~12% slower to do yadif without rate doubling and then another ~12% to do doubling so ~25% overall
[16:59:46 CEST] <durandal_1707> philipl: and comparing to CPU yadif?
[17:01:35 CEST] <JEEB> durandal_1707: he only did bobbing in it IIRC, not actual internals of yadif
[17:01:38 CEST] <JEEB> also > CUDA
[17:02:11 CEST] <nevcairiel> he added the actual yadifing
[17:02:18 CEST] <JEEB> ok
[17:04:22 CEST] <philipl> I have real yadif.
[17:04:51 CEST] <philipl> durandal_1707: it's a bit hard to do apples to apples. Doing CPU decoding + CPU yadif, the yadif makes it 50% slower
[17:06:18 CEST] <philipl> Obviously, doing GPU decoding and copying back to do cpu yadif is way way slower.
[17:44:47 CEST] <atomnuker> BBB: are packets in dav1d padded?
[17:45:26 CEST] <BBB> no
[17:45:51 CEST] <atomnuker> turns out AV_INPUT_BUFFER_PADDING_SIZE can be quite useful for entropy coders too :/
[17:46:39 CEST] <atomnuker> also OD_EC_LOTS_OF_BITS is an atrocious badly put out hack with a completely random value
[17:47:12 CEST] <atomnuker> basically its normal to overread after the packet ends by calling ec functions, they're guaranteed to return 0
[17:47:28 CEST] <atomnuker> but every time you do that you call the refill function since the count is 0
[17:47:34 CEST] <atomnuker> the refill function will be a noop
[17:48:10 CEST] <atomnuker> so if the refill function detects that it has reached the end of the buffer it'll put 0x4000 into the amount of bits and fool the ec into not calling refill
[17:48:43 CEST] <atomnuker> why 0x4000? there's a whole chapter of war and peace in the libaom website which tells you "dunno, it was a nice number"
[17:49:14 CEST] <atomnuker> it would have been more optimal to pick (1 << (sizeof(bits_counter) << 3)) - 1
[17:49:58 CEST] <BBB> happy to add padding if it helps
[17:50:03 CEST] <BBB> you can set the rules if you rewrite it
[17:50:05 CEST] <BBB> right?
[17:50:07 CEST] <atomnuker> but still what an utterly pointless thing
[17:50:31 CEST] <atomnuker> it avoids a 100% predicted branch by adding cryptic code
[17:51:03 CEST] <atomnuker> rewrite it? already done, there's no original code left and its around 130 lines shorter than the original file
[17:51:41 CEST] <atomnuker> just polishing it, if the buffer was padded it would remove a end of buffer check in the refill function
[17:52:02 CEST] <atomnuker> since you never refill more than a few bytes at a time
[18:05:14 CEST] <atomnuker> hmm, padding wouldn't work, you'd shift in non-zero bits at the end of each tile
[21:50:31 CEST] <atomnuker> BBB: reopened PR, discussion area's a mess but gitlab sucks as much as anything else does except MLs
[21:50:53 CEST] <atomnuker> speedup seems to be around 5% overall for the 1080p video I use for testing on my machine
[21:51:24 CEST] <BBB> oh sweet
[21:51:29 CEST] <BBB> I didnt expect a speedup
[21:51:30 CEST] <BBB> but nice
[21:52:05 CEST] <atomnuker> me neither, I'm even surprised I managed to get the 64 bit window working with a speedup, but I'm guessing it has to do with the refill function
[21:52:30 CEST] <atomnuker> I could have saved on the buf_pos < buf_end check there because I couldn't make it overread ever but better safe than sorry
[21:52:49 CEST] <atomnuker> then I believed it would have fit in ryzen's 5 instructions for 1 cycle loop thing
[23:10:09 CEST] <BBB> sweet
[23:10:37 CEST] <BBB> do you have any interest in experimenting with sse2 versions of update_cdf or read_symbol?
[23:10:43 CEST] <BBB> (i.e. do 4 symbol checks at a time)
[23:17:30 CEST] <BBB> atomnuker: any preferred reviewer for your patch?
[23:17:40 CEST] <BBB> I can review it but maybe someone else knows this stuff better than me
[23:18:07 CEST] <atomnuker> pinged unlord, he knows best
[23:18:25 CEST] <atomnuker> absolutely, I'll do some simd for the update part first
[23:18:52 CEST] <atomnuker> read_symbol is also simdable
[23:18:52 CEST] <BBB> inline assembly ftw
[23:18:59 CEST] <atomnuker> no need to
[23:19:09 CEST] <BBB> oh you think the call overhead is minor?
[23:19:21 CEST] <BBB> (I always assumed it was like cabac and itd be suitable for inline asm)
[23:19:46 CEST] <atomnuker> nah, update_cdf doesn't use any internal msac stuff, its fully doable in asm
[23:20:24 CEST] <atomnuker> as for msac_decode_symbol simd, I'll make it inline along with ctx_norm+ctx_refill
[23:21:05 CEST] <atomnuker> then the core cdf part of it can be simd'd whilst still keeping the function calls down to 1
[23:26:29 CEST] <BBB> ok
[23:26:32 CEST] <BBB> overall looks very nice
[23:26:36 CEST] <BBB> I added 2 minor style comments
[23:26:42 CEST] <BBB> but overall I feel it looks good
[23:26:53 CEST] <BBB> how etensively has it been tested? do we need to spend some time testing it?
[23:28:28 CEST] <BBB> I suppose if its a non-inline, you could also make it avx2
[23:28:39 CEST] <BBB> which allows updating 8 symbols at once
[23:28:47 CEST] <BBB> or 16?
[23:29:06 CEST] <JEEB> &34
[23:29:21 CEST] <BBB> they are only 2 bytes...
[23:30:34 CEST] <atomnuker> BBB: I've tested it with some broken files and I haven't been able to trigger any of the asserts left nor trigger an overrun
[23:30:47 CEST] <atomnuker> I think if it passes ubsan it should be fine
[23:30:59 CEST] <BBB> and md5 of nonbroken files are identical right?
[23:32:18 CEST] <atomnuker> yep
[23:33:41 CEST] <BBB> cool
[23:33:44 CEST] <BBB> very cool
[23:50:40 CEST] <j-b> atomnuker: WoW!
[23:52:25 CEST] <atomnuker> BBB: mate...?
[23:52:34 CEST] <atomnuker> is _everything_ in x86 templated automatically
[23:52:44 CEST] <BBB> no
[23:52:47 CEST] <BBB> someone went overboard
[23:53:03 CEST] <BBB> theyre just init functions
[23:53:27 CEST] <BBB> I think someone hopes well do #if BITDEPTH == 8 & lots of code & # else & lots of code #endif
[23:53:55 CEST] <BBB> I was planning to do if (), not #if, but I guess I missed something
[23:53:59 CEST] <BBB> ohwell
[23:54:01 CEST] <BBB> not so important
[23:54:01 CEST] <atomnuker> I'm getting complaints that my init function is defined multiple times because I don't ifdef it for 8 and 10 bits
[23:54:04 CEST] <BBB> its just init code
[23:54:30 CEST] <BBB> void bitfn(bla_dsp_init_x86)(BlaDSPContext *const c) { .. }
[23:54:35 CEST] <atomnuker> msac_init.c:(.text+0x0): multiple definition of `dav1d_msac_init_x86'; src/src@@dav1d_bitdepth_8 at sta/x86_msac_init.c.o:msac_init.c:(.text+0x0): first defined here
[23:54:37 CEST] <BBB> bitfn() will take care of suffic
[23:54:44 CEST] <BBB> oh
[23:54:45 CEST] <atomnuker> eh, ok
[23:54:46 CEST] <BBB> uh
[23:54:47 CEST] <BBB> hm
[23:54:50 CEST] <BBB> oh right
[23:54:51 CEST] <BBB> for msac
[23:54:52 CEST] <BBB> hm...
[23:54:57 CEST] <BBB> sorry I misunderstood you
[23:55:04 CEST] <BBB> yes you want that non-templated
[23:55:07 CEST] <BBB> sorry about that
[23:55:18 CEST] <BBB> can you ask epirat?
[23:55:21 CEST] <BBB> he knows how to do that
[23:56:10 CEST] <atomnuker> no such nick
[23:56:17 CEST] <atomnuker> (ePirat too)
[23:56:59 CEST] <atomnuker> nvm, I'll do it myself, I see how in meson.build or whatever
[23:57:32 CEST] <BBB> in #dav1d
[23:57:39 CEST] <BBB> oh, hes asleep
[23:57:40 CEST] <BBB> ohwell
[23:57:58 CEST] <atomnuker> yep, works now
[00:00:00 CEST] --- Sat Oct 27 2018