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

[burek]

[00:02:09 CEST] <BBB> durandal_1707: it makes sense to do whatever you like doing
[00:02:30 CEST] <BBB> durandal_1707: if you dont care for what you write, then youre gonna give up pretty soon - look at all unoptimized code paths in swscale
[00:03:00 CEST] <BBB> (in the end, everyone uses opengl shaders to view video, and only some big datacenter bigcorps care about sw conversion, and they really only care about yuv420p10le to yuv420p)
[00:03:09 CEST] <BBB> hence swscale most paths are unoptimized
[00:03:42 CEST] <iive> I thought swscale uses runtime code generation
[00:03:57 CEST] <nevcairiel> only in the fastmmx path
[00:05:47 CEST] <BBB> and only for the fast_bilinear scaling type (which is not default)
[00:05:50 CEST] <BBB> and only for horizontal scaling
[00:07:56 CEST] <kierank> yuv420p10le to yuv420p --> they do?
[00:08:01 CEST] <kierank> iirc that conversion is in c
[00:08:06 CEST] <kierank> or it might be vice versa
[00:08:36 CEST] <kierank> in some future universe we can get rid of fast_bilinear and other junk from the early 2000s
[00:08:40 CEST] <JEEB> durandal_1707: have you made any tests with the latter revisions of zscale btw?
[00:08:51 CEST] <JEEB> s/zscale/zimg/
[00:09:10 CEST] <nevcairiel> a fresh universal scaling lib would be nice, but most things that coem to be hardly support enough formats to be able to replace swscale
[00:09:32 CEST] <JEEB> yeah
[00:09:40 CEST] <durandal_1707> guy is removing/readding code
[00:09:58 CEST] <JEEB> yeah, he seems pretty active
[00:11:03 CEST] <kierank> JEEB: https://github.com/buaazp/zimg?
[00:11:38 CEST] <wm4> removing useless features? what heresy
[00:11:42 CEST] <wm4> wrong url
[00:12:04 CEST] <wm4> https://github.com/sekrit-twc/zimg/
[00:15:04 CEST] <kierank> interesting
[00:17:37 CEST] <JEEB> yeah. funny enough I kind of dislike the guy due to him being an obnoxious troll for most of the internet history I've known him, but this stuff is actually being useful.
[00:18:04 CEST] <BBB> nevcairiel: https://xkcd.com/927/
[00:20:24 CEST] <jamrial> ^FLIF
[00:21:05 CEST] <nevcairiel> if their claims for FLIF hold true, it might actually not be that bad
[00:21:54 CEST] <nevcairiel> current implementation not withstanding
[00:24:41 CEST] <atomnuker> at least it's currently doing the right thing instead what every other new image format does
[00:25:27 CEST] <atomnuker> "encode an image as <insert video codec> keyframe and you have a new format"
[00:26:54 CEST] <wm4> atomnuker: don't forget the part where you slightly modify the original codec, so you can't share any code
[00:27:15 CEST] <wm4> ...and then add animations on top of the new image format
[00:28:25 CEST] <BBB> and alpha
[00:28:26 CEST] <BBB> and rgb
[00:28:31 CEST] <BBB> in a completely incompatible and incoherent way
[00:29:07 CEST] <atomnuker> that reminds me of APNG and MNG
[00:35:50 CEST] <nevcairiel> BBB: and preferably in 3 different ways
[00:42:48 CEST] <cone-754> ffmpeg 03Marton Balint 07master:80b6cc4214a8: concatdec: fix metadata memleak on error
[00:42:49 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:7c6dd90eed48: ffplay: more robust mutex creation
[01:00:29 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:1175bbd14fe3: ffserver: fix line wrapping on function decls
[01:00:30 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:3388bcced450: ffserver: unify exit path in _write_index()
[01:00:31 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:8a9089948f02: ffserver: wrap around too-busy message text
[01:00:32 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:d8c714cb241b: ffserver: wrap around bandwidth exceeded msg text
[01:00:33 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:84b4998dbdbd: ffserver: fix up rate units in server messages
[01:02:09 CEST] <BBB> nevcairiel: and a fourth, which is only function on april 1st!
[01:03:16 CEST] <JEEB> :D
[02:06:28 CEST] <J_Darnley> I've been tinkering around with assembly from that stereo filter patch for so long I've forgotten what I set out to test.
[06:54:22 CEST] <kurosu> durandal_1707, so you can follow BBB's advices, even for the coeff storing
[06:54:29 CEST] <kurosu> ah
[06:55:00 CEST] <kurosu> durandal_1707, so you can follow BBB's advices, even for the coeff storing
[06:55:40 CEST] <kurosu> I don't know how often the call is made (once per frame? line?)
[06:56:02 CEST] <kurosu> so maybe reloading them everytime isn't a big penalty
[06:57:00 CEST] <kurosu> but what you store on the stack, could be an array in the asm file (like the ex_*)
[06:57:27 CEST] <durandal_1707> func is called once per slice
[06:58:13 CEST] <kurosu> which approximately image height / threads I guess
[06:58:19 CEST] <kurosu> is
[06:58:29 CEST] <kurosu> probably fine
[06:59:21 CEST] <kurosu> my solution was 96B * number of anaglyphs (didn't count, looks close to 20)
[06:59:30 CEST] <kurosu> not huge, but still
[07:01:07 CEST] <kurosu> on the other hand, your coeffs are 17 bits (16 magnitude and sign)
[07:01:29 CEST] <kurosu> do they have to be like that? or could they be 16bits?
[07:02:06 CEST] <kurosu> because really, pmulld instead of pmaddwd sounds like a waste
[07:41:30 CEST] <cone-444> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:fe95b0eb8fdf: ffserver: avoid leaking pathname at exit
[10:44:47 CEST] <durandal_170> can I use avx2?
[10:58:05 CEST] <rcombs> is someone stopping you?
[11:08:48 CEST] <cone-617> ffmpeg 03Henrik Gramner 07master:8bb376cf6b4a: checkasm: Fix the function name sorting algorithm
[11:08:48 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:f83ead7691ad: Merge commit '8bb376cf6b4ab8645daedb8becaa7163656436a4'
[11:16:50 CEST] <cone-617> ffmpeg 03John Stebbins 07master:f56a08559334: matroskaenc: Don't write a track language tag
[11:16:51 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:4064d688e7f2: Merge commit 'f56a08559334b7eb6b3fedbc0cc741887f6067ae'
[11:17:32 CEST] <cone-617> ffmpeg 03Henrik Gramner 07master:2c3dbff1d89b: avutil/avstring: Inline some tiny functions
[11:17:33 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:a7322bd97f2e: Merge commit '2c3dbff1d89bbf8300c121c06524c014cb6e0915'
[11:19:21 CEST] <cone-617> ffmpeg 03Anton Khirnov 07master:f3202871598f: d3d11va: check for malloc failure
[11:19:22 CEST] <cone-617> ffmpeg 03Anton Khirnov 07master:bb198c4997d5: d3d11va: make av_d3d11va_alloc_context() available at all times
[11:19:23 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:ac830e9b489b: Merge commit 'f3202871598f59b570b31b01cfeb64b8fedbd700'
[11:19:24 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:0cd8170dd2b5: Merge commit 'bb198c4997d5036f3bf91de51e44f807115677d0'
[11:19:59 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:4c160fa23996: dcadec: Always initialize return variable
[11:20:00 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:fecf775624c0: Merge commit '4c160fa23996c05efcd952ccfac2359311d8a1bc'
[11:23:53 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:cab63a8b594c: dv: Mark internal frame reference as const
[11:23:54 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:d0186a4ec4c4: Merge commit 'cab63a8b594cdc365bb2581a12b3ac8e6dd480b2'
[11:26:07 CEST] <kierank> JEEB: professional edition?
[11:26:10 CEST] <kierank> of that zimg
[11:26:21 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:1da2a20763ae: dvbsubdec: Fix function return type
[11:26:22 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:fbd71bba8583: Merge commit '1da2a20763ae9ca579d5fd20763065871ddf6311'
[11:27:27 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:4628443ca353: h263: Drop uninitialized variable use from log message
[11:27:28 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:78d9658a4d04: Merge commit '4628443ca3534060888dd0015b229337eac13fd2'
[11:28:40 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:10aa6f9db44e: h264: Use the correct argument context in debug log
[11:28:41 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:f85e460078d8: Merge commit '10aa6f9db44e96977e7155fdc3e62619e0e00a15'
[11:29:28 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:b8b13acd70a1: hevc: Simplify logical check
[11:29:29 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:c9b35246191f: Merge commit 'b8b13acd70a1c1b6c044f967d78cb82f1a53887b'
[11:33:08 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:abe9adfb3156: rangecoder: Use AV_RB16 instead of bytestream_get_be16
[11:33:09 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:cae02106b706: Merge commit 'abe9adfb31566c415fd830a8d4977c79512d4385'
[11:33:55 CEST] <cone-617> ffmpeg 03Derek Buitenhuis 07master:eae58428bd19: avcodec: Do not lock during open for codecs marked as having threadsafe init
[11:33:56 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:45ab078e35a4: Merge commit 'eae58428bd199f7d4670bf471f56ed204430878e'
[11:34:21 CEST] <cone-617> ffmpeg 03wm4 07master:65db4899fa87: mmaldec: refactor to have more context per MMAL input buffer
[11:34:22 CEST] <cone-617> ffmpeg 03wm4 07master:39f01e346cab: mmaldec: be more tolerant against MMAL not returning decoded output
[11:34:23 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:827d4b794282: Merge commit '65db4899fa8790049bec3af16ecdb75dd81051fd'
[11:34:24 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:329a0e419e6e: Merge commit '39f01e346cab464ef6c0d4ec58cc13b7123e60d8'
[11:53:48 CEST] <TimNich> Daemon404: Looks like your libav thread lock commit got merged&
[11:54:14 CEST] <JEEB> kierank: I don't know if there's one, but that could explain his activity around it
[11:54:53 CEST] <wm4> TimNich: he also posted a ffmeg patch for this, which was applied before
[11:55:42 CEST] <nevcairiel> ever commit gets merged, the real question is if its contents get applied
[11:55:44 CEST] <ubitux> durandal_170: do you test your simd with odd width and unaligned frames? (like padded by one pixel on the left)
[11:55:46 CEST] <nevcairiel> every*
[11:55:52 CEST] <TimNich> wm4: and said the libav shouldnt be merged&
[11:56:07 CEST] <nevcairiel> please dont assume that I dont know what I'm doing =p
[11:56:48 CEST] <wm4> nevcairiel: what do you think about switching to cherry-picking?
[11:56:55 CEST] <nevcairiel> nothing
[11:57:07 CEST] <nevcairiel> it doesnt allow a script to identify which commits are still missing
[11:57:24 CEST] <TimNich> nevcairiel:  well I wasnt assuming its contents got merged, but I was wondering and havent looked to see yet...
[11:57:45 CEST] <nevcairiel> maybe you should before starting to rant on irc :)
[11:59:12 CEST] <nevcairiel> merging cannot "skip" commits, they have to be merged - the only option is to simply empty them and not merge any content
[11:59:37 CEST] <TimNich> hardley a rant, simply an observation since Daemon404 had said not to merge, o a heads up to him to make sure it was still OK
[12:00:10 CEST] <TimNich> Ahh&
[12:01:31 CEST] <nevcairiel> there is plenty empty merges, usually because the  change is already applied in ffmpeg (usually the same way, but sometimes differently)
[12:04:39 CEST] <TimNich> I always found that seeing what had gone into the merge was cumpersome, but Ive just found out that Sourcetree shows you, unlike gitk ;(
[12:05:04 CEST] <nevcairiel> the web thing can also show it somewhat ok'ish
[12:05:44 CEST] <TimNich> Oh. useful to know, thanks.
[12:05:57 CEST] <wm4> what does sourcetree show gitk doesn't?
[12:06:53 CEST] <nevcairiel> an interface that doesnt make you barf?
[12:06:54 CEST] <nevcairiel> :D
[12:07:25 CEST] <TimNich> In gitk if I click on a merge it just says Merge branch 'master' of
[12:08:19 CEST] <nevcairiel> yeah gitk seems to fail at showing the actual local diff of a merge
[12:08:40 CEST] <TimNich> but sourcetree cannot diff random commits..
[12:08:49 CEST] <wm4> gitk shows a 3-wqy diff
[12:08:51 CEST] <wm4> *way
[12:09:33 CEST] <nevcairiel> when i'm in the master branch, and i click on a merge commit, it would be nice to be able to see the actual changes this merge brought in
[12:09:42 CEST] <nevcairiel> you know, like "git diff" can do
[12:09:56 CEST] <TimNich> So Ive often wondered at the contents of a merge becasue of gitks limitation
[12:09:58 CEST] <nevcairiel> unless there is a hidden button in gitk, it seems to not be able to
[12:10:22 CEST] <TimNich> Im glad its not just me then...
[12:12:14 CEST] <TimNich> wm4:  3-way diff?
[12:12:28 CEST] <nevcairiel> 3-way diffs are stupid to read
[12:13:00 CEST] <TimNich> I only have 2 eyes, so cannot cope with 3-wy
[12:13:04 CEST] <TimNich> *way
[12:13:49 CEST] <nevcairiel> 3-way diff is what it shows on the web thing by default as well, ie. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d0186a4ec4c4391906bf7dcd83d3ea3e3b858d82
[12:13:54 CEST] <nevcairiel> the diff shown is the 3-way
[12:14:11 CEST] <nevcairiel> but you can get the actual interesting diff by clicking "diff 1" in the file list above it
[12:15:08 CEST] <wm4> btw., is there a way to make git merge insert the difference between the 2 branches on a conflict?
[12:15:33 CEST] <nevcairiel> difference? I always get the content from both branches in these <<<<< blocks
[12:15:59 CEST] <wm4> like a diff
[12:16:00 CEST] <nevcairiel> often I consult the libav git web thing to see what the actual change was, so if you mean that somehow.
[12:17:40 CEST] <nevcairiel> https://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented
[12:17:43 CEST] <nevcairiel> thats all there is
[12:17:54 CEST] <nevcairiel> an extra line with the original from the other side
[12:25:30 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:c0152ebb9e05: avcodec/mmaldec: Use av_assert0() instead of assert()
[12:43:59 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:9139a7e84f75: dnxhddec: cleanup frame header parsing
[12:44:00 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:4e7cba1d8a9c: dnxhd: profile flags
[12:44:01 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:52256860d6e3: dnxhdenc: do not select 4:4:4 profiles
[12:58:31 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:1f4ff53aea7c: dnxhddec: Introduce DNXHD_VARIABLE
[12:58:32 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:3a6a432b58fa: isom: add support for DNxHR codec family
[12:58:33 CEST] <cone-617> ffmpeg 03Jeremy James 07master:118a3cd2c5e2: dnxhd: add decoder support for DNxHR
[13:19:14 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:66db504f038a: dnxhd: add CID 1270
[13:19:15 CEST] <cone-617> ffmpeg 03Jeremy James 07master:6f1ccca4ae3b: dnxhd: add better support for CIDs 1270 to 1274
[13:30:54 CEST] <jermy> michaelni: I've got some longer samples for DNxHR, but not sure what might be required to get something suitable for FATE
[14:05:38 CEST] <michaelni> fate samples should be short ideally
[14:06:02 CEST] <kierank> BBB, atomnuker: hdd problems on avdev
[14:06:06 CEST] <kierank> can you backup your stuff
[14:06:09 CEST] <kierank> I will replace the hdd
[14:06:53 CEST] <michaelni> jermy, maybe they can be shortened? but i wasnt just asking for fate but more generally
[14:10:34 CEST] <jermy> Do you want a couple of frames of each - otherwise I've got a tarball if you are more in a position to extract a little. Content was shot by a colleague so isn't a problem licence-wise
[14:11:52 CEST] <michaelni> for fate ideally would be very few frames + patch, more generally if not for fate then anything is fine
[14:28:16 CEST] <BBB> kierank: I have no issues with you just deleting it
[15:01:39 CEST] <BBB> Gramner: ah there you go, that patch on libav-devel is what I meant (except I dont understand configure at all)
[15:02:06 CEST] Action: Daemon404 waves from NY
[15:18:31 CEST] <BBB> Daemon404: isnt it much nicer here than in britland?
[15:18:48 CEST] <Daemon404> it's all relative
[15:18:58 CEST] <BBB> so einsteinian
[15:19:23 CEST] <Daemon404> harr harr
[15:19:54 CEST] Action: durandal_170 writting simd for tak decorrelation
[15:20:40 CEST] <BBB> durandal_170: youre really getting into it - cool!
[15:21:08 CEST] <durandal_170> what have 32 byte mmsize?
[15:21:26 CEST] <kierank> Daemon404: it is raining here
[15:22:13 CEST] <BBB> durandal_170: avx2
[15:22:30 CEST] <BBB> durandal_170: for your stereo3d patch, its mostly ok now, try to not use three-operand instructions if you dont have to
[15:22:32 CEST] <durandal_170> and how to use it?
[15:22:35 CEST] <BBB> durandal_170: its slower on pre-avx hardware
[15:22:40 CEST] <BBB> since it requires an extra movdqa
[15:22:49 CEST] <BBB> so if you movu m0, [data]
[15:22:54 CEST] <BBB> dont pshufb m10, m0, [bla]
[15:23:03 CEST] <BBB> (well you can, for the first N-1)
[15:23:09 CEST] <BBB> but for the last one, just use pshufb m0, [bla]
[15:23:14 CEST] <BBB> that saves a movdqa on pre-avx
[15:23:31 CEST] <BBB> and saves a vex instruction (longer opcode) on >=avx
[15:24:04 CEST] <BBB> durandal_170: and interleave your adds so you decrease dependencies
[15:24:12 CEST] <BBB> durandal_170: so instead of padd m10, m[1-5]
[15:24:28 CEST] <BBB> do paddw m0, m1 - paddw m2, m3, paddw m4, m5
[15:24:30 CEST] <BBB> and so on
[15:24:44 CEST] <BBB> so each instruction is independent of the previous one, which increases parallel pairing on modern cpus
[15:24:55 CEST] <BBB> and the psrldq should be done in the end for all 3 together so they can pair also
[15:25:03 CEST] <BBB> psrld, I mean
[15:25:10 CEST] <BBB> rest is good!
[15:25:22 CEST] <BBB> very nice work
[15:25:50 CEST] <durandal_170> BBB: so how to do 8 pixels at once with avx2?
[15:25:52 CEST] <BBB> has anyone told you you use a lot of registers and can probably tune that down?
[15:26:18 CEST] <BBB> (its ok for now, but as you understand this stuff more intimately, youll want to learn to use less registers, possibly even try to make it work on 32bit :D)
[15:27:11 CEST] <BBB> durandal_170: I dont have avx2 hardware so its not something Ive played with a lot, its basically the same instructions, just m%d holds twice as much data and you have lane separation which is a bloody pain
[15:30:46 CEST] <durandal_170> so basically what should it look like? Line separation?
[15:34:41 CEST] <BBB> lane separation
[15:35:13 CEST] <BBB> imagine I load 8 bytes of data (movh) into a xmm register m0, and do punpcklbw m0, m1 where I just did pxor m1, m1 so m1 is zero
[15:35:30 CEST] <BBB> I now get m0[0],0,m0[1],0,m0[2],0, etc.
[15:35:31 CEST] <BBB> right?
[15:35:45 CEST] <BBB> now do the same with a ymm register on avx2
[15:36:15 CEST] <BBB> I actually dont get (m0[x],0) over x=0-15, whereas I do get that for x=0-7 for xmm
[15:36:43 CEST] <BBB> instead, I get (m0[x],0) over x=0-7 for the low half of the ymm register (just like xmm), and then the same over x=16-23 over the high half of the ymm register
[15:36:57 CEST] <BBB> so its like as if the ymm register is actually two xmm registers, and I ran punpcklbw over both of them
[15:37:02 CEST] <BBB> this complicates a lot of things
[15:37:07 CEST] <BBB> some things still work, others don't
[15:37:10 CEST] <BBB> shuffling is a pain, basically
[15:37:29 CEST] <durandal_170> but there are v instructions
[15:37:44 CEST] <BBB> x86inc.asm wraps all of that for you
[15:37:50 CEST] <BBB> vpunpcklbw == punpcklbw
[15:37:52 CEST] <BBB> its the same thing
[15:40:05 CEST] <durandal_170> so doing stereo3d in avx2 would give any speedup?
[16:01:39 CEST] <J_Darnley> durandal_170: it should give a speedup if you don't spend too much on dealing with the split-lanes complication.
[16:02:13 CEST] <J_Darnley> But I'm in the same boat as BBB, I don't have an avx2 cpu, so I haven't played with it that much
[16:03:20 CEST] <BBB> durandal_170: avx2 should speed up the simd about 2x, since you do twice as much data
[16:03:28 CEST] <BBB> durandal_170: but not all simd works out of the boat
[16:03:40 CEST] <Daemon404> avx2 is really useful for big companies, and noone else
[16:03:41 CEST] Action: Daemon404 runs
[16:03:55 CEST] <BBB> so pessimistic
[16:04:02 CEST] <BBB> Daemon404: why do you work for a big company again?
[16:04:30 CEST] <Daemon404> i dont think i'd call us properly big ;p
[16:04:42 CEST] <Daemon404> anyway im just syaing not many consumers have avx2 yet
[16:04:52 CEST] <Daemon404> not even a lot of companies
[16:05:10 CEST] <Daemon404> my gripe is people who write tons of avx2 code
[16:05:12 CEST] <Daemon404> and nothing lower
[16:05:19 CEST] <Daemon404> so asm is practically useless for most
[16:05:21 CEST] <J_Darnley> :)
[16:05:22 CEST] <Daemon404> (whats up x265)
[16:06:11 CEST] <J_Darnley> I'm waiting for money and a CPU that combines AVX2 and XOP's integer FMA
[16:07:02 CEST] <kierank> Daemon404: i can see their point
[16:07:14 CEST] <kierank> focus on the now and forget the past
[16:07:22 CEST] <Daemon404> kierank, then why do they write for xp support
[16:07:26 CEST] <Daemon404> and 32bit xp at that
[16:07:32 CEST] <kierank> iono
[16:07:51 CEST] <J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista
[16:08:21 CEST] <J_Darnley> (maybe that was someone else)
[16:08:29 CEST] <Daemon404> doubtful for x265
[16:11:31 CEST] <kierank> can swresample (or avresample) do exact resampling so n samples in and m samples out
[16:37:24 CEST] <Daemon404> ...wut... the cabac states had a tablegen added last year?
[16:37:34 CEST] <Daemon404> is it going to be "controversial" if i move those to the codec context
[16:37:37 CEST] <Daemon404> theyre not very large
[16:38:47 CEST] <wm4> lol
[16:39:21 CEST] <wm4> what did the commit adding these say?
[16:39:35 CEST] <Daemon404> let's see
[16:39:41 CEST] <nevcairiel> screw tablegen
[16:39:50 CEST] <Daemon404>     cabac: Allow hardcoding CABAC table.
[16:39:54 CEST] <Daemon404> entirety of teh commit message
[16:40:28 CEST] <nevcairiel> no reasoning, no reason for keeping
[16:40:33 CEST] <Daemon404> ;)
[16:40:57 CEST] <wm4> lol
[16:41:10 CEST] <wm4> who needs commit messages
[16:41:48 CEST] <iive> you may ask the author. 
[16:42:19 CEST] <Daemon404> that's not a reasonable way of mamanging a codebase
[16:42:29 CEST] <Daemon404> the author may not even be around anymore, necessarily
[16:43:12 CEST] <RiCON> <+J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista <- they do require numa, but it's configurable at build
[16:44:27 CEST] <iive> it is basic politeness to ask. if you don't get answer, then you can say that the author is not around anymore.
[16:44:52 CEST] <Daemon404> iive, i think youve completely missed the point: the reason should be in the commit message
[16:45:34 CEST] <TheRyuu> ^ x1000
[16:47:44 CEST] <JEEB> that indeed
[16:47:56 CEST] <JEEB> if there is a reason, it should be noted for posterity
[16:51:49 CEST] <iive> have you looked what the patch does?
[16:52:08 CEST] <wm4> maybe we should have a policy for commit messages
[16:52:24 CEST] <BBB> lets vote on the policy
[16:52:32 CEST] <wm4> you know, just some formal requirements
[16:52:55 CEST] <J_Darnley> You need to write a policy before you can vote on it.
[16:52:56 CEST] <BBB> (guys, weve tried this for ages, some people just write really poor commit messages. point it out when it happens, but we cant fix the past - lets not dwell on it)
[16:53:03 CEST] <JEEB> true that
[16:53:10 CEST] <iive> no really, this patch just moves code around.
[16:53:11 CEST] <Daemon404> BBB, i tried that
[16:53:19 CEST] <wm4> I tend to feel silly for pointing out commit message issues
[16:53:25 CEST] <Daemon404> i literally got accused of being a "bullshit libav reviewer"
[16:53:33 CEST] <wm4> (feels similar to putting too much weight on cosmetic issues)
[16:53:54 CEST] <iive> it seems that the old code generates the table at runtime. I assume that the code allows the table to be generated at compile time?
[16:54:04 CEST] <Daemon404> iive, we know what it does
[16:54:08 CEST] <Daemon404> thats not what we want
[16:54:12 CEST] <Daemon404> we want to know WHY it does this
[16:54:15 CEST] <Daemon404> and why it was added in 2014
[16:54:19 CEST] <Daemon404> for no gain 
[16:54:36 CEST] <Daemon404> this is not a hard concept to grasp
[16:55:02 CEST] <iive> i think that the hardcoded vs dyngen of tables have been bashed to dead...
[16:55:58 CEST] <wm4> right now we just want to fix the awful locking
[16:56:03 CEST] <wm4> which causes real world problems
[16:56:54 CEST] <TheRyuu> <+J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista <---btw you can drop xp support very easily with the subsystem linker option (which I think exists in binutils/ld as well)
[16:59:46 CEST] <RiCON> it is easy, just forget to pass "-DWINXP_SUPPORT=ON"
[17:08:51 CEST] <Gramner> (@BBB) and saves a vex instruction (longer opcode) on >=avx
[17:08:58 CEST] <Gramner> all instructions are vex-encoded in avx
[17:09:11 CEST] <Gramner> ant rhey all use 3-operande, even if src1 and dst are identical
[17:09:14 CEST] <iive> wm4: what locking do you have in mind? is it one that avoids concurent table generation?
[17:09:54 CEST] <wm4> iive: there is a global, non-recursive lock in lavc and/or lavf
[17:10:03 CEST] <Gramner> and vex-encoded instructions are only one byte longer than legacy instructions in very few cases, not worth caring about
[17:10:38 CEST] <BBB> Gramner: hes writing xmm code
[17:10:48 CEST] <BBB> Gramner: so three-operand vs. two-operand costs a vex isntr
[17:12:24 CEST] <Gramner> yes of course, in legacy code 3-operand results in an extra mov
[17:13:19 CEST] <Gramner> on modern hardware the extra moves doesn't cost anything other than increased cache usage though, since they're eliminated in the register renaming stage
[17:13:23 CEST] <BBB> and in avx it costs a vex instr
[17:13:31 CEST] <Gramner> every instruction in avx code is vex
[17:13:48 CEST] <BBB> right, so doing paddw m0, m1 is better than paddw m0, m1, m2
[17:13:51 CEST] <BBB> in avx
[17:14:27 CEST] <Gramner> no, becasue the first gets assembled as vpaddw m0, m0, m1
[17:14:47 CEST] <BBB> in xmm/avx?
[17:14:50 CEST] <Gramner> yes. and it's the same length as legacy paddw m0, m1
[17:15:00 CEST] <BBB> rly?
[17:15:04 CEST] <BBB> I didnt know that
[17:15:05 CEST] <BBB> how crazy
[17:15:06 CEST] <Gramner> very few instructions are longer when vec envoded
[17:15:07 CEST] <BBB> why?
[17:15:19 CEST] <BBB> ok nevermind that then
[17:15:22 CEST] <BBB> I stand corrected
[17:15:25 CEST] <nevcairiel> because it doesnt like mixing vex and legacy, clearly
[17:15:36 CEST] <BBB> but but but but but but but
[17:15:38 CEST] <BBB> mind blown
[17:15:50 CEST] <Gramner> if you want to jmp between avx and avx2 or whatever it's easier to just use vex encoding everywhere
[17:16:33 CEST] <Gramner> x86inc does that automagically since every instruction that has both legacy and vex encoding is a macro in x86inc
[17:16:44 CEST] <J_Darnley> And that is what x264asm does for you when you INIT_* for avx or newer
[17:16:49 CEST] <Gramner> (and yes, thats a _lot_ of macros)
[17:17:46 CEST] <Gramner> which is why yasm was slow as hell in earlier version. it used a hash table to store macros but we essentialy turned that hash table into a linked list
[17:18:08 CEST] <Gramner> so i made a lone line patch to yasm that incresed the hash table size and made it run 20x faster
[17:18:17 CEST] <Gramner> one line*
[17:19:48 CEST] <BBB> I remember that
[17:20:04 CEST] <bofh__> oh, so *that's* why that change made x86inc fast again
[17:20:16 CEST] <bofh__> always wondered.
[17:20:47 CEST] <Gramner> yes, pengvado also made a change to x86inc that reused variables instead of creating new local variables (variables used the same hash table)
[17:21:14 CEST] <Gramner> that change isn't needed with newer yasm versions, but it doesn't hurt either so we'll keep it for now
[17:21:22 CEST] <wm4> I hope yasm uses a dynamic hash table size now
[17:21:48 CEST] <bofh__> also iirc in vex-mode using a v* instruction with 2-operand form results in at least one assembler throwing an error instead of doing the logical thing and encoding it as a 3-op 1 with op2==op3.
[17:22:07 CEST] <Gramner> it doesn't, but it's kind of irrelevant. setting it to a "large" value results in what, a few 100 kB of extra memory usage?
[17:22:24 CEST] <bofh__> what matters is does it stay in L1, mostly
[17:22:56 CEST] <bofh__> or at least does the hot subpart stay in L1
[17:23:59 CEST] <atomnuker> kierank: I'm fine too, just delete my stuff
[17:24:06 CEST] <Gramner> the difference between L1 and L2 is tiny compared to parsing through a size 500 linked list or whatever like it used to is probably not even a noticable difference
[17:25:08 CEST] <BBB> linear search
[17:25:09 CEST] <BBB> hm....
[17:25:18 CEST] <BBB> do you remember these goog interview questions?
[17:25:24 CEST] <BBB> actually every company has them nowadays
[17:34:09 CEST] <Gramner> goog questions is like, algorithms and data structures. (and writing string manipulation functions in c, which is what I failed on when I applied there a few years ago. doing anything with strings in c is horrible compared to high level languages)
[17:40:04 CEST] <durandal_170> is there any good avx2 example?
[18:06:58 CEST] <BBB> durandal_170: what do you mean with good? x264 has some avx2 code, theres some code in hevc/vp9 decoders in ffmpeg
[18:15:57 CEST] <kierank> you can write some v210 avx2 if you need to start somewhere =p
[18:33:39 CEST] <durandal_170> BBB: for start simple pxor like in blend
[18:34:01 CEST] <BBB> ?
[18:34:09 CEST] <BBB> I dont understand
[18:34:16 CEST] <BBB> your avx2 code will be identical to your ssse3 code
[18:34:31 CEST] <BBB> x86inc.asm does a lot of magic so the disassembly will look entirely different
[18:34:34 CEST] <BBB> but the source code is identical
[18:34:41 CEST] <BBB> just INIT_YMM avx2 instead of INIT_XMM ssse3
[19:18:34 CEST] <bofh__> things I was hoping to never see in the wild but just did: ADTS in RIFF WAV
[20:05:13 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:1d4af04adf99: avutil/attributes: add av_warn_unused_result
[20:28:00 CEST] <jamrial> why are so many fate clients failing the screenpresso test with a "file not found" error?
[20:28:04 CEST] <jamrial> the sample has been in the fate suit for days, they should have synced it by now
[20:28:50 CEST] <nevcairiel> maybe syncing is broken on them
[20:29:04 CEST] <nevcairiel> they all seem to be michaels, fwiw
[20:29:13 CEST] <nevcairiel> weell, most of them
[20:43:23 CEST] <michaelni> seems some of my boxes rsync from the wrong server, they should be good on the next commit/run
[20:44:07 CEST] <nevcairiel> do we have two that provide the fate suite?
[20:44:16 CEST] <michaelni> yes
[20:44:54 CEST] <michaelni> its on fate.ffmpeg.org too
[20:45:01 CEST] <nevcairiel> i always just do make fate-rsync, wherever that gets it from
[20:45:18 CEST] <nevcairiel> and whereever i uploaded samples to is apparently the same box :D
[20:46:04 CEST] <michaelni> i have a explicit rsync command in my script and that used fate. i dont remember that i choose that intentionally so i probably didnt 
[20:46:40 CEST] <michaelni> maybe was a typo that i copied to all boxes :)
[20:52:48 CEST] <jamrial> it was not just your machines, though. also ubitux's and someone called jeremy
[20:59:26 CEST] <nevcairiel> maybe the second box should get a cronjob to sync its own repository over from the main one
[22:31:00 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:4802b8368a70: ffplay: log SDL error messages
[22:31:01 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:b67c1ab58cb1: ffplay: more robust condition variable creation
[22:31:02 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:4c2bfabc3a82: ffplay: use correct context for av_log
[22:42:43 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:8deb1fdac84e: avformat/omadec: Fix { typo
[22:51:29 CEST] <cone-617> ffmpeg 03Ronald S. Bultje 07master:cb912b452192: vp9: fix msvc build by using 6 GPRs on 32bit if stack!=aligned.
[00:00:00 CEST] --- Tue Oct  6 2015