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

[burek]

[00:45:38 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:80721cc1ff1f: diracdsp: add dequantization SIMD
[00:45:39 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:bd61f3c6bfb8: diracdsp: add SIMD for the 10 bit version of put_signed_rect_clamped
[00:45:40 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:17caae72025f: diracdec: simplify golomb parsing and dequantization
[00:45:41 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:b9c6c5f4539d: diracdec: decode HQ profile slices in rows
[00:45:42 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:09d89d940635: diractab: expose the maximum quantization index as a macro
[00:45:43 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:c43485f70765: diracdec: rewrite HQ slice decoding
[00:45:44 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:0eb0f93109aa: diracdec: implement a LUT-based Golomb code parser
[00:45:45 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:dcad4677d637: diracdec: do not allocate and free slice parameters every frame
[00:45:46 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:209456292309: diracdec: do not memset the entire coefficient buffer for HQ pictures
[00:55:07 CEST] <llogan> anyone going to VDD?
[00:56:31 CEST] <llogan> i've never been to VDD...or Deutschland
[01:04:21 CEST] <llogan> 4500mi/7300km away. $1300-1600 USD for the ticket...
[01:38:28 CEST] <Compn> llogan : you going this year ?
[01:38:52 CEST] <Compn> llogan : btw are you anywhere near fairbanks ?
[01:39:49 CEST] <Compn> llogan : pretty sure kierank is going. j-b is going. BBB i think is going...
[01:40:00 CEST] <BBB> Im going yes
[01:40:09 CEST] <Compn> i might be going
[01:40:11 CEST] <cone-706> ffmpeg 03Rostislav Pehlivanov 07master:df1dc52195a5: diracdsp_init: add missing ARCH_X86_64 check
[01:40:48 CEST] <Compn> carl went last year. 
[01:40:53 CEST] <Compn> dont think i've seen iive yet 
[01:43:00 CEST] <llogan> Compn: i'm considering it, but i'll be travelling already for a while before VDD. I'm in Juneau.
[01:44:51 CEST] <llogan> ...also i don't want to miss out on coho fishing this year
[01:44:58 CEST] <Compn> i was in alaska once
[01:45:03 CEST] <Compn> felt a lot like the midwest :D
[01:50:57 CEST] <llogan> but the midwest is so flat
[01:51:57 CEST] <rcombs> it's got huge& tracts of land!
[03:53:43 CEST] <Timothy_Gu> nevcairiel: yeah I'm gonna try but I'm in China right now and the Internet sucks here (no surprise)
[10:47:26 CEST] <mateo`_> michaelni: I can't reproduce the ffprobe segfault you got, 1918 does not fail (except the decoding errors near the end of file, which are already here with master)
[10:52:48 CEST] <mateo`_> anyway multiple_stsd.mp4 play better with the merge commit but the audio is out of sync 
[10:58:07 CEST] <michaelni> 1918 just gives here: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2f194e0] error reading header
[10:59:47 CEST] <michaelni> ffprobe doesnt segfault under valgrind here, but it shows some anomalies
[11:01:01 CEST] <michaelni> mateo`_, http://pastebin.com/cVhC14xR
[11:01:03 CEST] <mateo`_> I also have some issues with multiple_stsd.mp4 I didn't have on my other machine yesterday
[11:01:44 CEST] <mateo`_> I've run ffprobe under valgrind too, but no invalid read :(
[11:03:54 CEST] <michaelni> for ticket 1918 this fails ./ffmpeg_g -i http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1918/aark15sd_9A62E2FA.mp4 -f null -
[11:08:30 CEST] <michaelni> mateo, you are on 5d3f3a421d70890eff73434b93cb55c233731bd1 ?
[11:09:43 CEST] <mateo`_> michaelni: i've clean/reset my repo and i'm currently rebuilding
[11:11:53 CEST] <mateo`_> michaelni: sorry for the noise, got the sames issues you have reported
[11:12:23 CEST] <michaelni> if you want the exact same test2.mov i used: http://www.ffmpeg.org/~michael/test2.mov
[11:13:36 CEST] <mateo`_> and libav just segfaults the same way
[11:13:53 CEST] <mateo`_> i'll fix the crashes and let you know
[11:46:11 CEST] <cone-432> ffmpeg 03Rostislav Pehlivanov 07master:a337cb736142: diracdec: fix #coeffs -> byte conversion
[11:52:59 CEST] <robUx4> nevcairiel: do you know if HEVC Main10 hardware decoder in libavcodec is supposed to work ?
[11:53:18 CEST] <nevcairiel> of course it works
[11:53:40 CEST] <robUx4> I only get AV_PIX_FMT_YUV420P10LE as possible output for the sample I use
[11:54:13 CEST] <robUx4> do you have a working sample ?
[12:02:03 CEST] <nevcairiel> any hevc main10 sample works for me
[12:02:33 CEST] <robUx4> you get something else than AV_PIX_FMT_YUV420P10LE ?
[12:02:46 CEST] <robUx4> even for 10 bits H264 I only get that
[12:03:04 CEST] <robUx4> so I can't even try to use the hardware decoder
[12:03:05 CEST] <nevcairiel> 10-bit h264 is not hardware accelerated
[12:03:18 CEST] <nevcairiel> no consumer hardware supports that
[12:03:56 CEST] <nevcairiel> hevc main10 is also only supported with dxva2 at this time, nothing else
[12:04:03 CEST] <nevcairiel> (ie. windows only)
[12:06:17 CEST] <robUx4> yes I'm trying on windows
[12:06:36 CEST] <robUx4> (d3d11va but it doesn't propose dxva2_vld anyway)
[12:06:55 CEST] <robUx4> here's a Main10 sample where it only proposes software decoding https://drive.google.com/open?id=0ByOSGN3npCKxQkpzYXlibkRuNTA
[12:08:12 CEST] <nevcairiel> works for me
[12:14:34 CEST] <robUx4> ok, I'll dig in the code to find out why it doesn't for me
[12:17:13 CEST] <nevcairiel> ffmpeg -hwaccel dxva2 -threads 1 -i D:\video-x265-10bit-420.mp4 -f null -
[12:17:23 CEST] <nevcairiel> uses hwaccel just fine on your sample
[12:25:49 CEST] <robUx4> never mind, I was using the other libavcodec
[12:25:58 CEST] <robUx4> I see there's more stuff in ffmpeg
[13:33:48 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:9157ac2f9c86: avcodec/dirac_vlc: Fix mixed declaration and statements
[13:56:44 CEST] <Chloe> what would an appropriate AVERROR be for corrupted memory?
[14:01:10 CEST] <kierank> corrupted memory?
[14:01:13 CEST] <BtbN> Uhm, what? How do you know the memory is corrupted, and why don't prevent it in the first place?
[14:04:41 CEST] <Chloe> An external function which will fail if the file in memory is corrupted
[14:04:57 CEST] <BtbN> And how did it get corrupted?
[14:05:21 CEST] <kierank> AV_INVALIDDATA or whatever it's called
[14:11:13 CEST] <Chloe> BtbN: because of a corrupted file at the start
[14:13:00 CEST] <BtbN> So not memory corruption, just a broken file.
[14:13:22 CEST] <BtbN> Invalid Data seems appropiate
[14:13:34 CEST] <Chloe> ok, thanks
[16:26:14 CEST] <cone-432> ffmpeg 03James Almer 07master:4acdbb1c6c19: avformat/oggenc: always use the time base stored in the theora header
[18:08:09 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vKWLc
[18:08:09 CEST] <KGB> 13FFV1/06master 1441cc0f2 15Michael Niedermayer: FFV1: Add security considerations...
[18:48:53 CEST] <bp0> if asked to split a patch into two separate patches, can I resubmit them to ffmpeg-devel in a single email with two attachements, or should I use two emails with one attachment each?
[18:51:17 CEST] <JEEB> you should use send-email preferably and have each patch in its own message with [PATCH] => [PATCH v2]
[18:51:39 CEST] <JEEB> https://git-scm.com/docs/git-send-email
[18:53:34 CEST] <JEEB> after making the two patches the two "topmost" commits in your repo, you can do `mkdir -p patchset && git format-patch HEAD~2 -o patchset` and then edit the .patch files to have [PATCH v2] instead of [PATCH]. then you can use git send-email according to the documentation specifying the directory (you can test it with --dry-run)
[18:54:16 CEST] <bp0> If using send-email instead of format-patch, how do you comment to the list without it being in the commit message?
[18:54:44 CEST] <nevcairiel> you put your comments below the --- line
[18:55:21 CEST] <bp0> alright, thanks
[18:55:29 CEST] <JEEB> --compose can also be used to create an introductory/cover message
[18:55:43 CEST] <JEEB> which will be [PATCH 0/2]
[18:55:59 CEST] <JEEB> anyways, more than one way to skin a cat
[18:56:35 CEST] <JEEB> also one thing I notice is that with send-email you generally want to disable CC'ing
[18:57:24 CEST] <JEEB> --suppress-cc=all is what I generally use (and set in my gitconfig)
[19:32:54 CEST] <cone-476> ffmpeg 03Michael Niedermayer 07master:2408f92678f8: avcodec/dirac_vlc: Fix avutil.h include
[21:08:17 CEST] <llogan> yet another user help question sent to ffmpeg-user-admin. they never tell me why they do that when i ask.
[21:10:02 CEST] <llogan> i'm not exactly sure where they find it either since I don't know why they would click "ffmpeg-user list run by michael, babtiste, and lou"
[21:55:13 CEST] <BBB> jamrial: dont you think we should allow ext lib tests in fate?
[21:55:34 CEST] <nevcairiel> its not a terrible idea, but the majority of stations wont test them
[21:55:48 CEST] <jamrial> not for a library like vpx. there's no way to do version checks and such
[21:56:05 CEST] <jamrial> components that depend on zlib sure, since that's been the same since the dawn of time
[21:57:39 CEST] <jamrial> for that matter, that makes me wonder if the minimum version we support for libvpx can decode vp8a and vp9a, or if this patch will need some extra checks
[22:13:19 CEST] <BBB> jamrial: I think thats worth asking :)
[22:15:19 CEST] <jamrial> or could be a good excuse to bump the minimum required version and get rid of all the ifdeffery :p
[22:17:26 CEST] <BBB> or that
[22:17:29 CEST] <BBB> many options...
[22:17:48 CEST] <BBB> someone could also make the internal vp8/9 decoders support alpha
[22:17:51 CEST] <BBB> *hint* *hint*
[22:18:03 CEST] <BBB> I can mentor that if theres some outreachy student up for that
[22:52:00 CEST] <nevcairiel> doesnt that literally require firing up a second decoder with a one-plane bitstream? the vpx patch makes it look like that
[22:53:29 CEST] <BBB> yes
[22:53:42 CEST] <BBB> but the decoder can be fired up internally so its hidden from the outside
[22:53:52 CEST] <BBB> it looks fairly hacky but whatever Im not in charge of bitstream design over there
[22:54:01 CEST] <BBB> ( :-p )
[22:54:21 CEST] <nevcairiel> its not even a bitstream design thing, its like the webm guys solved it without the vp8/9 people wanting to cooperate =p
[22:54:45 CEST] <nevcairiel> you dont want to give us a true alpha mode? we'll encode two bitstreams, ha!
[22:54:56 CEST] <BBB> dunno, not involved in the discussions
[22:55:00 CEST] <BBB> I think they did this in vp6 also
[22:55:08 CEST] <BBB> (from what I remember)
[22:58:01 CEST] <rcombs> ProRes 4444 it is, then
[23:06:15 CEST] <kierank> nevcairiel: dct on alpha is pointless
[23:06:24 CEST] <kierank> the whole point of alpha is to have nice sharp edges
[23:27:34 CEST] <cone-476> ffmpeg 03Burt P 07master:0d8caeb41e50: af_hdcd: integrate() renamed hdcd_integrate() to be consistent with the other function names
[23:27:35 CEST] <cone-476> ffmpeg 03Burt P 07master:7af44ce2f7c2: af_hdcd: don't log full HDCD stats if HDCD was not detected
[23:39:37 CEST] <jamrial> speaking of vp8, just sent a patch to add vp8 muxing support for ogg
[23:39:41 CEST] <jamrial> for all you ogg lovers :p
[23:41:08 CEST] <TD-Linux> did we ever write a spec for that even
[23:41:43 CEST] <jamrial> there is one
[23:41:49 CEST] <BBB> omg ;(
[23:41:52 CEST] <BBB> really
[23:41:57 CEST] <jamrial> https://people.freedesktop.org/~slomo/ogg-vp8/ogg-vp8.pdf
[23:41:58 CEST] <BBB> can we all please agree that ogg should just die
[23:42:13 CEST] <BBB> ogg is one of these horrible ideas that will just not die
[23:42:16 CEST] <BBB> I dont understand why
[23:42:30 CEST] <BBB> they keep trying to patchwork around its brokenness even though there is matroska
[23:42:37 CEST] <BBB> just use matroska and let ogg die
[23:42:40 CEST] <BBB> pretty please?
[23:42:43 CEST] <jamrial> BBB: xiph keeps it alive with opus and now daala
[23:43:36 CEST] <BBB> so sad
[23:44:01 CEST] <atomnuker> btw, since no one's saying a thing about the ffserver news, maybe llogan can push it?
[23:44:53 CEST] <BBB> jamrial: I also realize something else thats rather painful about avx2 (although its not strictly avx2s fault)
[23:45:21 CEST] <jamrial> what?
[23:45:35 CEST] <BBB> jamrial: most butterfly idct implementations that I know of do the outermost interleave pass at the end, which means that you load pairs of n, and num-1-n coefficients into memory for a sumsub
[23:45:37 CEST] <BBB> e.g. 0 and 31
[23:45:41 CEST] <BBB> and then 1 and 30
[23:45:41 CEST] <BBB> etc.
[23:46:05 CEST] <BBB> but the subsequent transpose needs to have pairs of 16 and you have only 16 regs so you end up doing 16 full emmory loads and stores
[23:46:32 CEST] <BBB> for sse2 this is hidden because you have 16 regs but only need 8 for the transpose, so you can transpose the first and last 8 in the 16 regs without stores/loads
[23:46:40 CEST] <BBB> and then the middle 2 pairs of 8
[23:46:46 CEST] <BBB> for avx2 this is not possible
[23:46:47 CEST] <jamrial> BBB: avx512 would solve that with its 32 simd regs
[23:46:55 CEST] <BBB> yeah when is that coming out again?
[23:46:57 CEST] <jamrial> but yeah, avx2 not so much
[23:47:06 CEST] <jamrial> soon(tm)
[23:47:07 CEST] <BBB> I think releasing avx2 w/o 32 regs was kind of a mistake maybe
[23:47:17 CEST] <BBB> also doesnt avx512 introduct 64byte zmm regs?
[23:47:21 CEST] <BBB> or is that the one after?
[23:47:24 CEST] <jamrial> yeah
[23:47:30 CEST] <BBB> I want 64 zmm regs
[23:47:33 CEST] <BBB> 32 ymm regs
[23:47:34 CEST] <BBB> 16 xmm regs
[23:47:44 CEST] <BBB> [etc]
[23:48:24 CEST] <BBB> 16 ymm regs is slightly painful
[23:48:46 CEST] <jamrial> well, with avx512 you'll get 32 zmm, 32 ymm (mapping to low bits of zmm regs) and 32 xmm (same), just like avx does with ymm/xmm, so that's something
[23:48:52 CEST] <nevcairiel> it seems odd that the size and the count of regs would double, might as well quadruple the size of the step before it and use the same hardware :D
[23:49:11 CEST] <nevcairiel> ymm uses silly lane stuff anyway, so why not expose those as 32 xmm regs
[23:51:47 CEST] <BBB> 32 xmm is kind of much
[23:51:50 CEST] <BBB> I mean sure why not
[23:51:55 CEST] <BBB> but Im not sure anyone will ever need them
[23:51:56 CEST] <BBB> ?
[23:52:32 CEST] <nevcairiel> why do you need 32 ymm but not 32 xmm
[23:53:21 CEST] <nevcairiel> couldnt you implement the same things that need 32 ymm regs in sse?
[23:53:35 CEST] <nevcairiel> say, like a 32x32 idct
[23:54:13 CEST] <BBB> nevcairiel: well, sure
[23:54:28 CEST] <BBB> nevcairiel: but that would only work on machines that have zmm regs
[23:54:42 CEST] <BBB> nevcairiel: so then you wouldnt need the avx2 32reg or sse2 32reg version on that machine anyway
[23:54:56 CEST] <BBB> nevcairiel: do the deployment potential of a function like that seems fairly minor
[23:54:59 CEST] <nevcairiel> well yes, but maybe you dont need 512 bit registers
[23:55:07 CEST] <BBB> for 32x32? yes you do
[23:55:15 CEST] <BBB> 32 words = 64 byte = 512 bits
[23:55:39 CEST] <BBB> likewise, 16x16 = 16 words = 32 byte = 256 bits = ymm regs to do it stackless/loopless
[23:55:51 CEST] <BBB> so the 16x16 is in fact stack- and loopless on avx2
[23:56:01 CEST] <BBB> but the 32x32 avx2 will be stack/loop based
[23:56:56 CEST] <BBB> (i.e. you do a 16x32 idct_1d and transpose results to stack (2x) and then another 16x32 idct_1d 2x in the other direction, which you residual_add to the prediction
[23:57:11 CEST] <nevcairiel> i'm really more disappointed that 32-bit only has 8 xmm regs, did they just plan badly or did the instruction coding not allow for more
[23:57:29 CEST] <BBB> who cares about 32bit :-p
[23:57:33 CEST] <jamrial> seriously, avx512 with 8 zmm regs will be hilarious
[23:58:08 CEST] <BBB> does anyone here write avx2 that works on 32bit?
[23:58:12 CEST] <BBB> all my avx2 is 64bit only
[23:58:18 CEST] <jamrial> i did
[23:58:20 CEST] <BBB> Im too lazy to care about 32bit at this point
[23:58:21 CEST] <nevcairiel> i also wonder why they didnt fix it in vex coding or somethng
[23:58:27 CEST] <nevcairiel> must be some deep technical reason why it just doesnt work
[23:58:31 CEST] <jamrial> but because it was relatively easy
[23:59:01 CEST] <jamrial> i had to work around the fact i had 7 gprs more often than the fact i had 8 simd regs
[23:59:35 CEST] <BBB> oh right theres that also
[23:59:38 CEST] <nevcairiel> BBB: unfortunately many of my users still use 32-bit, mostly for reasons of the host app that uses avcodec is bound by legacy reasons, like a plugin landscape and shit like that
[23:59:54 CEST] <BBB> nevcairiel: so what kind of work do you do? :-p
[00:00:00 CEST] --- Wed Jul 13 2016