--- Log opened Wed Jun 12 22:05:22 2013
2013-06-12 22:05:30 < Skyler_> I guess we can re-acquire the channel ownership later or something
2013-06-12 22:05:33 < Gramner> freenode has policies regarding channel names though, it's not allowed to go around registering channels if you don't have a legitimate use case for them
2013-06-12 22:05:40 < Skyler_> Yeah, it's probably not a big deal
2013-06-12 22:05:54 < JEEBsv> yeah, it shouldn't
2013-06-12 22:05:54 < j-b> yes, and it's not that hard to get back.
2013-06-12 22:06:29 < DaKaZ_> so... I'm late to the party and missed whatever spurred this x265 movement... can someone catch me up quickly?
2013-06-12 22:07:00 < muggs> H.265/HEVC
2013-06-12 22:07:30 < JEEBsv> MWC started a project and it quite possibly will be licensed in a similar way to x264
2013-06-12 22:07:32 < DaKaZ_> yeah... I figured that part out.
2013-06-12 22:07:35 < JEEBsv> *MCW
2013-06-12 22:07:42 < JEEBsv> (damn you, MVC)
2013-06-12 22:07:58 < DaKaZ_> who's that?
2013-06-12 22:09:02 < kierank> multicoreware
2013-06-12 22:10:42 < DaKaZ_> interesting.... well, I am glad someone got the project going, I failed at that!
2013-06-12 22:11:34 < Skyler_> MCW had the advantage of "contributing 7 figures in startup resources" :P
2013-06-12 22:12:09 < JEEBsv> yeh... that kind of stuff helps get such projects up and running
2013-06-12 22:12:17 < muggs> well, we didn't contribute, but we certainly appreciated the contributions
2013-06-12 22:12:21 < DaKaZ_> wow, thats a serious investment
2013-06-12 22:27:38 < muggs> for those that joined late, I mentioned that currently we're working on 1) Lookahead/GOP parallelism  2) making RDO optional
2013-06-12 22:36:14 < muggs> does x264 assembly use MMX instructions when compiled for x86_64? so far it seems we haven't needed EMMS on 64bit builds.
2013-06-12 22:37:56 < muggs> we're only using sad/x3/x4, satd, and sse functions at this point.
2013-06-12 22:39:57 < Skyler_> x264 uses MMX on 64-bit for functions that are too small to get SSE versions
2013-06-12 22:39:59 < Skyler_> e.g. don't need the width
2013-06-12 22:40:12 < Skyler_> emms isn't really costly though, I mean, you're probably not using float in many places
2013-06-12 22:40:18 < Skyler_> so it can't really hurt to just leave it there
2013-06-12 22:40:27 < Skyler_> e.g. sad width 4 is mmx
2013-06-12 22:40:42 < Skyler_> or quant_2x2
2013-06-12 22:40:46 < muggs> the HM uses doubles everywhere for distortion and RDO
2013-06-12 22:40:59 < Skyler_> That should be immediately changes to int64_t
2013-06-12 22:41:09 < Skyler_> floating point should never be used on a macroblock-level, IMO
2013-06-12 22:41:18 < muggs> agreed, it's on the list
2013-06-12 22:41:58 < muggs> need to verify that these 64x64 blocks can't overflow a uint64 first
2013-06-12 22:43:05 < Skyler_> well, the max distortion is 255*255*64*64
2013-06-12 22:43:31 < Skyler_> for max bits, you can probably be really loose and say like 32 bits per pixel, so 32*64*64*(MAX LAMBDA2)
2013-06-12 22:43:59 < Skyler_> and since there's probably a fixed point factor in there, shift it all up some N bits (x264 uses 8)
2013-06-12 22:44:27 < muggs> fixed point factor in lambda2?
2013-06-12 22:45:57 < Skyler_> oh, okay, x264 does this:
2013-06-12 22:46:18 < Skyler_> RD = SSD + ((BITS * LAMBDA2 + 32768) >> 16)
2013-06-12 22:46:26 < Skyler_> BITS is measured in fix8, because CABAC uses fractional bits
2013-06-12 22:46:33 < Skyler_> LAMBDA2 is also fix8
2013-06-12 22:46:49 < Skyler_> But especially with the larger partitions of H.265 you probably don't need that level of precision, so you can do what x264 used to do:
2013-06-12 22:46:58 < Skyler_> RD = SSD + ((BITS * LAMBDA2 + 128) >> 8)
2013-06-12 22:47:05 < Skyler_> where bits is fix8
2013-06-12 22:47:29 < Skyler_> in x264, that actually fits in 32 bits, not 64
2013-06-12 22:47:52 < Skyler_> so fitting in 64 should be pretty easy.
2013-06-12 22:51:18 < muggs> yeah, seems so.  their functions currently do this:  RD = floor(SSD + (BITS * dLambda2 + .5));
2013-06-12 22:52:26 < Skyler_> That seems close enough to the same thing
2013-06-12 22:52:47 < muggs> yep
2013-06-12 22:54:13 < Skyler_> I'm guessing CABAC hasn't changed, so you can probably steal x264's optimized cabac
2013-06-12 22:54:15 < muggs> they have dLambdaMotionSAD, which is sqrt(dLambda2) * 32k, that they use for motion search
2013-06-12 22:54:20 < Skyler_> and the bit cost calculator
2013-06-12 22:54:33 < Skyler_> sqrt(dLambda2) is just dLambda, that's silly
2013-06-12 22:54:40 < Skyler_> x264 already has a set of lambdas that you can probably use
2013-06-12 22:54:48 < Skyler_> or you can just convert theirs to x264's format
2013-06-12 22:54:56 < muggs> we have borrowed the mv_cost() per-QP arrays
2013-06-12 22:54:57 < JEEBsv> yes, the CABAC code is something that should be rather easily portable
2013-06-12 22:55:20 < muggs> I haven't looked in detail, but the claim is that HEVC CABAC has been simplified
2013-06-12 22:55:36 < Skyler_> I think that's referring to the binarization, I think the actual arithcoding is the same?
2013-06-12 22:55:39 < Skyler_> I'm not 100% sure though
2013-06-12 22:55:53 < JEEBsv> That Other Encoder at least IIRC took it as-is
2013-06-12 22:56:05 < muggs> CABAC is well outside my comfort range
2013-06-12 22:56:45 < Skyler_> hopefully it's inside the comfort range of one of the other devs that will inevitably arrive here :p
2013-06-12 22:57:21 < muggs> heh
2013-06-12 22:57:56 < Skyler_> for optimizing RDO, you need to modify CABAC to be templated
2013-06-12 22:57:58 < Skyler_> like x264 does it
2013-06-12 22:58:03 < Skyler_> this will make it vastly faster
2013-06-12 22:58:10 < Skyler_> since RDO doesn't have to write the actual bitstream
2013-06-12 22:58:29 < muggs> they have something called TEncBitCounter, that they use when measuring RDO
2013-06-12 22:58:44 < Skyler_> well, you'd have to look at how they update it
2013-06-12 22:58:49 < Skyler_> bad way: actually run cabac
2013-06-12 22:58:56 < Skyler_> good way: use a transition table (see cabac.h in common/ in x264)
2013-06-12 22:59:07 < Skyler_> also see rdo.c lines 54-63
2013-06-12 22:59:27 < muggs> there's also an RDOQ function that looks suspiciously like trellis
2013-06-12 22:59:38 < muggs> 20% compression improvement
2013-06-12 23:01:07 < Skyler_> 20% is a little extreme for trellis
2013-06-12 23:01:21 < Skyler_> I recall JM's RDOQ being obnoxiously slow, to the point of insanity, I hope HM's is better
2013-06-12 23:01:34 < Skyler_> though I think it also picked quantizer in addition to doing quantization so it was like insanely slow
2013-06-12 23:01:36 < muggs> it's pretty slow
2013-06-12 23:02:00 < muggs> it's always at the top of VTune charts
2013-06-12 23:02:37 < Skyler_> trellis can be hard to understand but it's definitely a function that can benefit enormously from structural and algorithmic optimization
2013-06-12 23:02:40 < Skyler_> like, orders of magnitude
2013-06-12 23:03:36 < muggs> x264 has demonstrated this :)
2013-06-12 23:03:49 < Skyler_> I'm going to guess they're using the equivalent of trellis 2 right now
2013-06-12 23:03:54 < Skyler_> e.g. RDO implies RDOQ for each mode
2013-06-12 23:03:58 < Skyler_> rather than RDOQ after RDO selects a mode
2013-06-12 23:04:11 < Skyler_> implementing --trellis 0/1/2 will probably give huge speed gains
2013-06-12 23:04:22 < Skyler_> If they're /not/ doing that and it's still so slow, I have no idea
2013-06-12 23:05:05 < muggs> right it's making every mode decision based on a full encode of every option.. it's horrendous
2013-06-12 23:06:19 < muggs> we're about 2/3 done making it use SATD to cull most modes, then use RDO on the best
2013-06-12 23:06:45 < Skyler_> it looks like x264 uses about 13% of time in trellis on --preset slower (with trellis 2)
2013-06-12 23:07:08 < Skyler_> one thing you should probably test is how much different sizes of satd affect things, or if you can just get away with using 4x4 satd on everything
2013-06-12 23:07:11 < Skyler_> since 4x4 satd is absurdly fast
2013-06-12 23:07:35 < Skyler_> (well, 4x4 on everything except transform size decision of course)
2013-06-12 23:08:16 < Skyler_> a 16x16 satd4x4 is 63 cycles on a haswell for example
2013-06-12 23:08:27 < muggs> good lord
2013-06-12 23:09:03 < Skyler_> avx2 almost doubled its speed, it was wonderful
2013-06-12 23:10:04 < Skyler_> in x264 we found that using sa8d wasn't generally any better, but that could stop being the case since hevc has bigger transforms
2013-06-12 23:11:11 < muggs> the HM was using sa8d_8x8 everywhere that wasn't 4x4; but we haven't done any comparisons with satd
2013-06-12 23:12:26 < Skyler_> interesting
2013-06-12 23:12:49 < muggs> btw: AMP makes SIMD a bit of a pain.  your partitions are no longer necessarily aligned.
2013-06-12 23:12:59 < Skyler_> AMP?
2013-06-12 23:13:40 < muggs> asymmetrical motion prediction.  3/1 splits
2013-06-12 23:14:01 < Skyler_> oh; which simd does that affect?  I'd think that would just require new SAD functions (since the partitions are a different size anyways)
2013-06-12 23:14:05 < Skyler_> and I guess new motion compensation?
2013-06-12 23:14:30 < Skyler_> but it shouldn't affect the regular-size functions, right?
2013-06-12 23:14:37 < muggs> sad/satd/sse.. pretty much all the asm primitives we use
2013-06-12 23:14:50 < muggs> right.
2013-06-12 23:14:59 < Skyler_> but it shouldn't affect any of your normal primitives, just new sizes
2013-06-12 23:15:09 < muggs> intra is all square partitions
2013-06-12 23:15:27 < Skyler_> like 8x16 won't change, you'll just have to add a 12x16
2013-06-12 23:15:59 < muggs> uhm, yes.  that does seem like it should be true.
2013-06-12 23:16:40 < muggs> we had to change FENC_STRIDE to 64 for obvious reasons.
2013-06-12 23:16:55 < Skyler_> I thought superblock sizes went up to 64?
2013-06-12 23:17:14 < muggs> yes
2013-06-12 23:17:25 < Skyler_> so it'd have to be 64+1 -> 96, I guess
2013-06-12 23:17:30 < Skyler_> because you'd have to have the edges for intra pred
2013-06-12 23:17:36 < Skyler_> oh, that's FDEC_STRIDE.
2013-06-12 23:17:40 < Skyler_> I am the dumb
2013-06-12 23:17:49 < muggs> heh
2013-06-12 23:18:09 < Skyler_> I wonder if we'll have to end up writing separate intra pred asm functions for every single one
2013-06-12 23:18:25 < muggs> because FENC_STRIDE changed, we had to change the C decls to x265_ so linking x265 and x264 in the same app didn't break one another
2013-06-12 23:18:47 < Skyler_> c decls?
2013-06-12 23:19:08 < muggs> the asm funcdefs.. x265_sad_8x8(), etc
2013-06-12 23:19:17 < Skyler_> Oh... why were they called x264 to begin with?
2013-06-12 23:19:42 < muggs> that's what the macros generate
2013-06-12 23:19:51 < Skyler_> Oh, you need to set program_name to what your program's name is
2013-06-12 23:20:12 < Skyler_> oh, I see, it's now called private_prefix
2013-06-12 23:20:15 < Skyler_> %ifndef private_prefix %define private_prefix x264
2013-06-12 23:20:16 < Skyler_> %endif
2013-06-12 23:20:43 < muggs> right, we changed private_prefix to x265
2013-06-12 23:21:17 < muggs> I was hoping to avoid that, since we were using the asm unchanged, but the FENC_STRIDE change required it
2013-06-12 23:22:26 < Skyler_> I think you're going to change the asm, and I don't feel like there's value in not changing it
2013-06-12 23:23:47 < muggs> I'm hoping to keep the changes minimal, to make it easy to pull in improvements
2013-06-12 23:24:19 < Skyler_> good point, but you'll probably have to make some pretty significant additoins, at least, to add the larger block sizes
2013-06-12 23:24:34 < muggs> but yeah, intra is a tough nut.  33 modes for 4, 8, 16, and 32
2013-06-12 23:25:12 < muggs> the HM actually generates predictions for 64x64, even though you can't signal those
2013-06-12 23:27:01 < Skyler_> I'm guessing that's just old cruft?
2013-06-12 23:27:26 < muggs> I haven't looked myself, but was told it was for mode decisions
2013-06-12 23:27:54 < muggs> to decide whether to split to 32x32, I guess
2013-06-12 23:28:07 < muggs> doesn't sound like a good idea
2013-06-12 23:28:57 < Skyler_> Yeah... there's no intra 64x64 mode to begin with
2013-06-12 23:29:03 < Skyler_> and using intra to pick inter modes feels like a terrible idea
2013-06-12 23:29:45 < muggs> I assume it's a guesstimate of 4 32x32 intras, but that's just a guess
2013-06-12 23:29:56 < muggs> dinner time here, be back in an hour or so
2013-06-12 23:32:52 < muggs> oh, an interesting detail.  the HM mvd cost calculator gave a slight penalty to negative MVD digits, and this seems to give slightly better compression
2013-06-12 23:32:56 < kierank> i wonder if there is some sort of directional heuristic you can use for all the intra directions
2013-06-12 23:33:43 < muggs> kierank: probably.  most of the modes are packed around H and V
2013-06-12 23:34:51 < Skyler_> Yeah, x264 had one a long time ago, I think
2013-06-12 23:34:55 < Skyler_> but it was removed because it was waful
2013-06-12 23:34:57 < Skyler_> *awful
2013-06-12 23:35:01 < Skyler_> it worked okay, but it was slow
2013-06-12 23:35:07 < Skyler_> but on much larger blck sizes with far more directions, it could be better
2013-06-12 23:35:15 < Skyler_> x264 already has some shortcuts where it omits modes based on dominant directions too
2013-06-12 23:35:26 < Skyler_> a slight penalty to negative MVD digits....?
--- Day changed Thu Jun 13 2013
2013-06-13 00:44:14 < muggs> yeah, MVD(-1,1) would cost slightly more than MVD(1,1)
2013-06-13 01:02:20 < Skyler_> So it's not based on the direction of the MV, but the direction of the delta?  that seems really bizarre
2013-06-13 01:02:30 < Skyler_> I could understand "bias towards shorter MVs" or something but this isn't that either
2013-06-13 01:02:48 < Skyler_> is there any explanation anywhere?
2013-06-13 01:03:25 < muggs> none that I've found
2013-06-13 01:04:07 < Skyler_> is it explicit/intentional?
2013-06-13 01:04:14 < Skyler_> I mean, like you said that it did help
2013-06-13 01:04:31 < muggs> looked very intentional
2013-06-13 01:05:11 < Skyler_> what exactly was the formula?
2013-06-13 01:05:16 < muggs> I can point you to the HM function:
2013-06-13 01:05:52 < muggs> UInt TComRdCost::xGetComponentBits( Int iVal )
2013-06-13 01:06:00 < Skyler_> sorry, I don't have the code, where can I get it?
2013-06-13 01:06:13 < Skyler_> it's only in the x dimension, though?
2013-06-13 01:06:30 < muggs> it measures x and y with the same function
2013-06-13 01:06:45 < muggs> I'll pastebin it, just a sec
2013-06-13 01:06:51 < Skyler_> oh, what's the "x" then?
2013-06-13 01:07:43 < muggs> sometimes it means recursive, sometimes it means static.. not real sure.
2013-06-13 01:08:11 < Skyler_> I hope we can do away with hungarian notation
2013-06-13 01:08:14 < muggs> http://privatepaste.com/64d7445efd
2013-06-13 01:08:58 < Skyler_> How are MVs coded in CABAC?  is the sign bit still bypassed?
2013-06-13 01:09:04 < Skyler_> That looks like code simulating CAVLC MV costs
2013-06-13 01:09:13 < Skyler_> with SE golomb codes
2013-06-13 01:09:30 < Skyler_> in fact, that should be *exactly correct* for the case of an SE golomb
2013-06-13 01:09:36 < Skyler_> so I think they were just using SE golomb costs...
2013-06-13 01:10:16 < muggs> let me look, I think they use it for more than just MVD
2013-06-13 01:11:49 < muggs> nope, that function is only used for MVD
2013-06-13 01:15:27 < muggs> might have been sample bias.. I didn't check a lot of videos to see if it helped them globally
2013-06-13 01:16:38 < Skyler_> it might help as compared to removing the bias, but it might not help as compared to using a correct formula in the first place
2013-06-13 01:19:19 < muggs> HM's svn: https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/
2013-06-13 01:20:05 < muggs> that was one place where I added x264's bit cost and the HM's bit cost next to each other with a compile switch to toggle them, but have been too busy to revisit it
2013-06-13 01:20:15 < Skyler_> it's tricky though because x264's is fractional
2013-06-13 01:20:58 < muggs> uhm, yeah, and it's not storing floats there anymore, so would need some tweaks to make it match again
2013-06-13 01:21:57 < muggs> seemed funny to store bit costs as fractions
2013-06-13 01:25:35 < pengvado> why? things really do cost fractions of a bit
2013-06-13 01:27:01 < muggs> it makes more sense when you consider lambdas, but the reason we store ints there now is that the HM func only returned ints
2013-06-13 01:30:12 < Skyler_> well then I guess you haveto refactor it :p
2013-06-13 01:30:16 < Skyler_> you said you had convrted it to use the tables anyways
2013-06-13 01:30:20 < Skyler_> so why is this even an issue?
2013-06-13 01:30:24 < Skyler_> the tables store the bit cost in bits*lambda
2013-06-13 01:31:00 < Skyler_> if the code does something the wrong way, it's eventually going to need to be changed
2013-06-13 01:31:46 < muggs> no arguments, it was just a curious thing the way they did it
--- Log closed Thu Jun 13 01:37:09 2013
--- Log opened Thu Jun 13 04:40:01 2013
--- Log closed Thu Jun 13 16:45:03 2013
--- Log opened Thu Jun 13 20:04:26 2013
2013-06-13 21:36:54 < someday> Hi
2013-06-13 21:37:21 < someday> How can be part of x265 development?
2013-06-13 21:37:32 < someday> has it already started ?
2013-06-13 21:38:05 < JEEB> something that has high chances of becoming something called 'x265' has had its development started, yes
2013-06-13 21:38:52 < someday> how can I be part of it ?
2013-06-13 21:38:57 < JEEB> but the whole deal is being negotiated right now, as a company started the development. If it will be licensed in a similar way to x264, it will be able to get the x264 name and  be open source
2013-06-13 21:39:38 < someday> ok...that's good news!
2013-06-13 21:39:49 < JEEB> uhh, *x265 name
2013-06-13 21:40:55 < JEEB> if it all goes through then this channel and a mailing list hosted on videolan will be provided and all
2013-06-13 21:41:51 < someday> gr8! Exciting!
2013-06-13 21:43:32 < JEEB> I guess you have already read the spec?
2013-06-13 21:47:56 < someday> Not really, just have watched  video (related to spec) and read articles about it. Whatever I could find in internet.
2013-06-13 21:49:05 < JEEB> http://www.itu.int/rec/T-REC-H.265-201304-I
2013-06-13 21:49:25 < JEEB> ISO/IEC was slow at putting it through FDIS
2013-06-13 21:49:32 < JEEB> so they only ratify it in July
2013-06-13 21:52:33 < someday> yeah, now I can go through this.
2013-06-13 21:53:42 < JEEB> you can also take a look at HM's source code, but remember that specification > HM
2013-06-13 21:53:58 < JEEB> if there is a difference, specification generally takes the upper hand
2013-06-13 21:55:43 < someday> ok .. I did start that ,  going through it currently.
2013-06-13 21:56:45 < JEEB> now I wish HEVC FF was released already :V
2013-06-13 21:56:56 < JEEB> the last public draft is by now more than a year old
2013-06-13 22:00:14 < someday> What is FF ? ffmpeg ?
2013-06-13 22:00:30 < JEEB> File Format
2013-06-13 22:00:41 < JEEB> amendment 2 to MPEG-4 Part 15
2013-06-13 22:01:28 < someday> ah .. ok..
2013-06-13 22:03:41 < Paranoialmaniac> 待ってるんだぜ...
2013-06-13 22:11:36 < someday> Mpeg-4 part 15 is this available in public ?
2013-06-13 22:13:19 < someday> I am here http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=55980
2013-06-13 22:13:40 < someday> and here http://mpeg.chiariglione.org/standards/mpeg-4/avc-file-format/text-isoiec-14496-152010dam-2-carriage-hevc
2013-06-13 22:13:59 < someday> both are not free..
2013-06-13 22:16:06 < Paranoialmaniac> 14496-15 is not free.
2013-06-13 22:16:38 < JEEBsv> that draft noted is available, but as I said -- it is more than a year old by now
2013-06-13 22:17:13 < JEEBsv> and GPAC, a project that has one of its devs be an editor of that spec, is implementing it differently
2013-06-13 22:17:23 < JEEBsv> so I will just guess that the final draft will be different
2013-06-13 22:17:46 < JEEBsv> if they want it to be finalized in July they will have to release the final draft this month
2013-06-13 22:17:56 < JEEBsv> I hope they will soon
2013-06-13 22:18:06 < JEEBsv> Matroska wants to mimic their extradata
2013-06-13 22:18:52 < someday> I found that http://x264.fushizen.eu/random/29n13120t.pdf
2013-06-13 22:19:13 < JEEBsv> yes, that's the PDF I made of the old draft
2013-06-13 22:20:50 < someday> ah ..ok.
2013-06-13 22:23:57 < someday> x265 will be addition on x264 or will it be written from scratch ?
2013-06-13 22:25:16 < JEEBsv> what has come up so far is that it is based on HM, and then both completely new code as well as x264 code is modified to make a completely new encoder
2013-06-13 22:25:38 < JEEBsv> there are some things that are quite useful from x264, and some that just aren't :)
2013-06-13 22:27:46 < someday> Yeah... we can get best of all 3 :)
2013-06-13 22:41:42 < Mandarinka> is this channel going to be similar to #x264, or is this rather equivalent of #x264dev? I don't want to be a squatter in developers' place, but I'm curious about the project naturally :)
2013-06-13 22:42:53 < Skyler_> I think it's more #x264dev for now, since there won't be a user channel for a long, long time
2013-06-13 22:43:04 < Skyler_> it's not really meaningful to users until there's a working encoder, so
2013-06-13 22:43:44  * JEEBsv is going through 3GPP documents in the hopes of finding a newer version of HEVC FF there
--- Day changed Fri Jun 14 2013
--- Day changed Sat Jun 15 2013
--- Day changed Sun Jun 16 2013
--- Day changed Mon Jun 17 2013
2013-06-17 18:40:13 < muggs> I've had a couple of engineers looking at adding assembly routines for the newer block sizes.  We added SSE routines pretty easily, but satd has stumped them.
2013-06-17 18:42:21 < muggs> s/SSE/SSD... the HM uses 'sum of square errors' terminology
2013-06-17 18:43:13 < Skyler_> you mean increasing the size of existing SATD functions?
2013-06-17 18:43:40 < Skyler_> It should be very easy; the current SATD is based around a 16x4 basic block (there's a 16x4 satd that gets called repeatedly)
2013-06-17 18:43:45 < Skyler_> so just call it more basically
2013-06-17 18:44:23 < Skyler_> or, well, more precisely, in some cases we use 8x8 as the basic block, in some cases 16x4
2013-06-17 18:44:27 < Skyler_> e.g. avx2 wants the 16x4
2013-06-17 18:44:31 < muggs> that's what it looked like from a cursory reading, but apparently they weren't able to get a functional 32x32 out of it
2013-06-17 18:44:33 < Skyler_> but the concept should be the same.
2013-06-17 18:44:42 < Skyler_> Okay, you're going to need to watch out for overflow between stages
2013-06-17 18:44:51 < Skyler_> Larger than 16x16 might overflow, so you might have to sum multiple times
2013-06-17 18:45:03 < Skyler_> instead of just at the end
2013-06-17 18:45:13 < Skyler_> since we keep the satd score in a vector of 16-bit values until the end
2013-06-17 18:45:20 < Skyler_> so if it looks like it's overflowing, that could be it.
2013-06-17 18:45:31 < Skyler_> It'd help if they did their development here though, so we could see what they were doing and try to help
2013-06-17 18:46:21 < Skyler_> watch out though; the existing code increments the pointers, so you'll probably need to futz with things a little to do something wider than 16
2013-06-17 18:46:29 < muggs> agreed.  I'll talk to them about that this evening.  Most of the engineers are in Chennai, India or in a Beijing time zone
2013-06-17 18:46:32 < Skyler_> e.g. the function that does 16x4 will add 4 rows to the pointers
2013-06-17 18:49:01 < muggs> for optimal speed, we might need a 32x4 macro?
2013-06-17 18:49:23 < Skyler_> Hmm
2013-06-17 18:50:16 < Skyler_> that'd be pretty big, code-wise...
2013-06-17 18:50:25 < Skyler_> in terms of physical code, that is
2013-06-17 18:50:30 < Skyler_> here's my suggestion, I'm not sure if it's the best or pengvado likes it
2013-06-17 18:50:36 < Skyler_> 1)
2013-06-17 18:50:36 < Skyler_>     lea  r2, [r2+4*r3]
2013-06-17 18:50:37 < Skyler_>     lea  r0, [r0+4*r1]
2013-06-17 18:50:48 < Skyler_> pull these out of 16x4.  make them handled by the caller instead of the callee.
2013-06-17 18:50:50 < Skyler_> Then you can just do
2013-06-17 18:50:53 < Skyler_> call 16x4
2013-06-17 18:50:56 < Skyler_> add 16 to each pointer
2013-06-17 18:50:57 < Skyler_> call 16x4
2013-06-17 18:51:00 < Skyler_> add strides
2013-06-17 18:51:01 < Skyler_> etc
2013-06-17 18:51:07 < Skyler_> or, well add strides*4-16
2013-06-17 18:51:10 < Skyler_> and repeat the process
2013-06-17 18:51:36 < Skyler_> after 8 rows out of 32, you can do a horizontal sum in order to save the results and not overflow (or otherwise calculate how you'll have to do things to avoid overflow; I'm not sure what the rules are, pengavdo would know)
2013-06-17 18:51:57 < Skyler_> You could also base it on 8x8, which already doesn't do the pointer-incrementing internally, I think.
2013-06-17 18:51:57 < muggs> just realized it would be really handy if this channel were logged
2013-06-17 18:52:09 < Skyler_> Oh, it totally should be; feel free to log it just like we log #x264dev
2013-06-17 18:52:25 < Skyler_> oh, 8x8 does do it internally
2013-06-17 18:52:38 < muggs> do you need to setup a bot somewhere?
2013-06-17 18:52:55 < Skyler_> I don't know, I'm not really an expert at this
2013-06-17 18:55:59 < Skyler_> I guess you could do it with a bot
2013-06-17 18:56:06 < Skyler_> and like set it to autoupload somewhere public
2013-06-17 19:10:23 < pengvado> http://akuvian.org/src/x264/freenode-x265.log.bz2
2013-06-17 19:10:58 < kierank> btw, not that i care much but logging is against the freenode terms of use
2013-06-17 19:12:00 < pengvado> last I read the terms of use, they just said that if you're going to publish logs you have to say so in the channel topic
2013-06-17 19:13:19 < Gramner> doesn't most irc clients enable logging by default?
2013-06-17 19:13:57 < Skyler_> public logging, I think
2013-06-17 19:13:57 < kierank> public logs
2013-06-17 19:14:07 < kierank> oh freenode terms just say consider it carefully
2013-06-17 19:14:10 < kierank> never mind then
2013-06-17 19:16:57 < muggs> pengvado: thanks
2013-06-17 19:25:00 < muggs> I'm not channel op, so I'm unable to change the topic
2013-06-17 19:25:48 < JEEB> yeah, the channel is still registered to that unknown guy who snatched both #x265 and #x265dev
2013-06-17 19:26:22 < muggs> I thought those dropped when you signed off.  guess not
2013-06-17 19:26:42 < JEEB> nah, if you register a channel under a registered user name it will stay yours, for a while
2013-06-17 19:28:13 < JEEB> that user has last been seen a little over two weeks ago, so if he doesn't appear in a month or two all of his stuff gets flushed
2013-06-17 19:29:25 < muggs> failing that, I've just squatted on #x265-dev
2013-06-17 19:31:49 < Skyler_> you could ask the freenode ops?
--- Day changed Tue Jun 18 2013
2013-06-18 05:51:00 < muggs_> Hey guys
2013-06-18 05:51:50 < Gopu> hi all
2013-06-18 05:52:47 < muggs_> it's late, even in the pacific time zone, so there might not be many active devs at this time
2013-06-18 05:57:21 < pengvado> you want to discuss something, or was the timezone comment as out-of-the-blue as it looked?
2013-06-18 06:01:49 < muggs_> Mandar is the fellow trying to adapt the satd macros for HEVC partitions
2013-06-18 14:00:37 < Skyler_> people here have insane sleep schedules anyways; if you have a question, it's probably better to ask than to worry about time zones
--- Day changed Wed Jun 19 2013
2013-06-19 14:50:42 < JEEB> btw, the L-SMASH project wants to implement the 14496-15 AMD2 "HEVC-in-MP4" mappings, if anyone wants to help with that, feel free to poke me or  #L-SMASH
2013-06-19 14:51:06 < Paranoialmaniac> なんぞ！？
2013-06-19 14:52:29 < JEEB> and I laid it out like that because in some cases helping by providing the current text isn't good, so if anyone has access to the text and wants to help, they can do that too
2013-06-19 14:52:41 < JEEB> currently the only public draft is the one that finished ballot in april
--- Day changed Thu Jun 20 2013
2013-06-20 21:21:51 < muggs> Min Chen is writing functions that generate all 33 intra predictions at once, to nice effect
2013-06-20 21:22:02 < JEEB> nice
2013-06-20 21:22:25 < JEEB> can't wait to get chewing on that encoder after we finally get some container-wise specs for HEVC
2013-06-20 21:22:25 < muggs> but to take advantage of it, we need satd_4x4_x8 or something similar
2013-06-20 21:22:44 < Skyler_> Why do we need that?
2013-06-20 21:22:58 < Skyler_> Oh, I see, you mean, you want to stick all the 4x4 satds next to each other
2013-06-20 21:23:00 < Skyler_> and sum separate results
2013-06-20 21:23:12 < Skyler_> That shouldn't be too hard; you just don't do the final HADDW step at the end of the satd, I think
2013-06-20 21:23:18 < muggs> yeah, similar to sad_x4
2013-06-20 21:23:22 < Skyler_> so you can do a 32x4 SATD or similar
2013-06-20 21:23:36 < Skyler_> and just count each 4x4 separately by doing a limited HADDW (adding just each set of 4, instead of all 32)
2013-06-20 21:23:49 < Skyler_> intra_satd_x9 is probably a good example of something to look at for this
2013-06-20 21:23:57 < Skyler_> phminposuw is also a wonderful friend
2013-06-20 21:24:25 < Skyler_> intra_sad_4x4_x9 is probably the simplest
2013-06-20 21:24:50 < Skyler_> but yeah, that sounds like a very good idea; totally agree
2013-06-20 21:24:59 < Skyler_> with that many modes, the SIMD will be wonderful
2013-06-20 21:34:21 < muggs> sorry, had a phone call.  intra_sad_4x4_x9 does 9 predictions, then calculates 9 satds?
2013-06-20 21:34:33 < muggs> er.. 9 sads, I guess?
2013-06-20 22:30:57 < Skyler_> muggs: yeah, there's one of those for 4x4/8x8 sad/satd
--- Day changed Fri Jun 21 2013
2013-06-21 12:33:25 < JEEB> Galaxy S4 indeed seems to have a SW HEVC decoder
2013-06-21 12:33:26 < JEEB> http://pastebin.com/KnMZv6dw
2013-06-21 12:33:39 < JEEB> I had to check it by hand because "lol no-one wanted to help with a real device"
--- Day changed Sat Jun 22 2013
--- Day changed Sun Jun 23 2013
--- Day changed Mon Jun 24 2013
--- Day changed Tue Jun 25 2013
2013-06-25 19:30:25 < muggs> it looks like HEVC allows bipred pixels to be > 8bits
2013-06-25 19:39:15 < Skyler_> as in, the intermediates?
2013-06-25 19:41:48 < muggs> the pixels you compare with, I believe.
2013-06-25 19:42:45 < muggs> let me double check that
2013-06-25 19:49:00 < muggs> near as I can, it's in the final averaging, which uses 2 * A - B
2013-06-25 19:50:22 < muggs> TComYuv::removeHighFreq()
2013-06-25 19:50:41 < muggs> https://hevc.hhi.fraunhofer.de/trac/hevc/ticket/175
2013-06-25 19:51:43 < muggs> oh, my bad. it's smoothing one side
2013-06-25 19:52:15  * JEEB double-blinks
2013-06-25 19:52:18 < muggs> I need a vacation.  fortunately i have one coming up
2013-06-25 20:17:07 < muggs> this confuses me:  pred = (clip(2*O - R1) - R2 )/ 2
2013-06-25 20:17:38 < Skyler_> what are O, R1, and R2?
2013-06-25 20:18:05 < muggs> that's the confusing part. the but report says this: "This makes the prediction operation to be (O is the predicted signal, R1 and R2 are references):"
2013-06-25 20:18:42 < muggs> s/but/bug
2013-06-25 20:19:38 < muggs> was O just ave(R1, R2)?
2013-06-25 20:19:41 < Skyler_> But I thought pred was the predicted signal.
2013-06-25 20:19:45 < Skyler_> How do pred and O differ?
2013-06-25 20:19:58 < muggs> that's what I'm stuck on
2013-06-25 20:20:08 < Skyler_> what does the spec say?
2013-06-25 20:35:40 < muggs> predSamples[x][y] = Clip((predSamplesL0[x][y]*w0 + predSamplesL1[x][y]*w1 + ((o0 + o1 + 1) << log2WD)) >> (log2WD + 1))
2013-06-25 20:38:05 < muggs> o0 and o1 are weight offsets.  I don't see this 2A-B operation
2013-06-25 20:39:57 < muggs> non-weighted is even simpler.  I should eat lunch, maybe that will help
2013-06-25 20:44:18 < muggs> I suspect O = predSamples[x][y] and this smoothing is documented elsewhere
2013-06-25 21:06:14 < muggs> bah; the HM is filtering the fenc pixels used for bidir search
2013-06-25 21:15:15 < Skyler_> that seems a little weird
2013-06-25 21:15:32 < Skyler_> is it doing a lowpass filter /on the source/?
2013-06-25 21:24:10 < muggs> that's what it looks like
2013-06-25 21:25:01 < muggs> it does an merange=4 exhaustive search in both references to refine bidir
2013-06-25 21:48:26 < Skyler_> x264's approach is probably a little bit faster
2013-06-25 21:48:31 < Skyler_> (this is a huge understatement)
2013-06-25 22:06:30 < muggs> does H.264 have bidir MVs? I thought the prediction locations were implicit?
2013-06-25 22:47:46 < Skyler_> um... yes it has bidir mvs
2013-06-25 22:47:51 < Skyler_> mpeg-2 has bidir mvs
2013-06-25 22:47:59 < Skyler_> skip/direct is implicit
2013-06-25 23:13:23 < muggs> I see, so when we get around to adding bidr we'll rip out what's there and port the x264 code
2013-06-25 23:20:09 < Skyler_> x264's bidir should be extremely fast, it's optimized to minimize calls to MC
2013-06-25 23:20:15 < Skyler_> (refine_bidir)
--- Day changed Wed Jun 26 2013
--- Day changed Thu Jun 27 2013
2013-06-27 02:05:34 < muggs> fwiw: gop parallelism is now functional.  with all the perf settings enabled, we're at 15fps on a 16-core server for HD I+P
2013-06-27 02:09:36 < Skyler_> gop parallelism sounds like a memory nightmare though
2013-06-27 02:10:40 < muggs> oh, it is.. especially as it is at the moment.  every frame in the encoder has full motion reference planes.. 15 of them
2013-06-27 02:11:07 < muggs> I need to make a pool for them and recycle them as references are removed from the DPB
2013-06-27 02:12:14 < muggs> there's a meeting tomorrow to decide if this is good enough to go public with.  it looks promising
2013-06-27 02:13:59 < muggs> the only good thing about GOP parallelism is you mostly don't need it unless you have more than 8 cores.
2013-06-27 02:18:47 < Mandarinka> This must require quite a large lookahead if you do it with scenecut detection AND long gop (say, 10 seconds)?
2013-06-27 02:19:22 < muggs> we have no lookahead yet, this is a fixed keyframe interval
2013-06-27 02:19:35 < Mandarinka> (oh and 1-pass)
2013-06-27 02:19:55 < muggs> it's still at the "interesting toy" stage
2013-06-27 02:21:06 < muggs> relocating, be back in a bit
2013-06-27 02:30:37 < Skyler_> muggs: gop parallelism also breaks if you need VBV :/
2013-06-27 02:30:44 < Skyler_> IMO it's not that useful to have because you can do it outside the encoder
2013-06-27 02:31:08 < Skyler_> you only need it inside the encoder for realtime, and if you're realtime you probably need VBV, so...
2013-06-27 02:31:16 < Skyler_> but if it's already there it'd be cool to mix with other paralellism modes
2013-06-27 02:31:29 < muggs> just another tool..
2013-06-27 02:32:06 < muggs> if we weren't operating under a contract with a fixed perf goal, we definitely would have taken different paths
2013-06-27 02:33:47 < muggs> to add gop parallelism I had to work around a lot of potential frame parallelism issues.. it will be much easier to add that now
2013-06-27 02:34:28 < muggs> it's good to know 6 frames can saturate 16 xeon cores
2013-06-27 02:38:10 < Skyler_> Makes sense
2013-06-27 20:18:42 < muggs> ok, our client has signed off on a GPL release, now it's just a matter of when and how.
2013-06-27 20:19:46 < muggs> I'm on vacation next week, so it will probably happen the 2nd week of July, barring any blockers
2013-06-27 20:19:51 < Skyler_> awesome!
2013-06-27 20:20:45 < Mandarinka> that's great :)
2013-06-27 20:22:37 < JEEB> awesomeness
2013-06-27 20:22:52 < Paranoialmaniac> :)
2013-06-27 20:25:07 < irock> \o/
2013-06-27 20:33:13 < muggs> hopefully between now and then we can get a head-start on making the code base more palatable
2013-06-27 20:39:48 < muggs> I need to relocate, will be back on in an hour or so
--- Day changed Fri Jun 28 2013
2013-06-28 23:56:10 < muggs_> does x264 keep a public bug tracker?
2013-06-28 23:56:19 < Skyler_> the mailing list is about as close as there is to one
2013-06-28 23:56:27 < Skyler_> but if you want one for x265, that'd be fine; j-b could host I imagine
2013-06-28 23:57:04 < muggs_> yeah, I'm debating it with myself.  it would fast become filled with "I want a pony" requests
2013-06-28 23:57:18 < Skyler_> I'm not a huge fan, but I'm not against either
2013-06-28 23:58:27 < muggs_> I think we will start off without one, since once you do have one it looks quite odd to take it away :)
2013-06-28 23:59:13 < Skyler_> Yeah, I don't feel like it's necessary
2013-06-28 23:59:37 < Skyler_> IMO bugs should be resolved as soon as possible; if you need a tracker for it, you have too many bugs already
2013-06-28 23:59:51 < Skyler_> and for features and such, adding bureaucracy makes it get done slower, not faster
--- Day changed Sat Jun 29 2013
2013-06-29 00:00:04 < Skyler_> (this is more true for something x264-size than like, something ffmpeg-size)
2013-06-29 00:01:58 < muggs_> I think I agree; encoder bugs should be infrequent and short-lived.  at least for a mature encoder
2013-06-29 00:02:59 < Skyler_> even for a new one, bugs should be rare and resolved quickly, otherwise they accumulate
2013-06-29 00:05:13 < muggs_> this is what our team will be doing for the next week, ensuring all the various build options can generate identical and deterministic bitstreams
2013-06-29 00:05:37 < Skyler_> good idea; making it valgrind-clean should be a goal too
2013-06-29 00:05:54  * muggs_ adds that to the list
2013-06-29 00:06:47 < Skyler_> since it's extremely difficult to debug if valgrind is covered with all kinds of other warnings (plus, they usually imply real bugs
2013-06-29 00:08:19 < muggs> my ISP is about to get a short haircut
2013-06-29 01:31:40 < j-b> muggs_: a bugtracker can be blocked-to-assholes
2013-06-29 02:42:45 < muggs_> j-b: I've opened an internal one, so we can track things
2013-06-29 04:01:53 < Kovensky> <muggs_> yeah, I'm debating it with myself.  it would fast become filled with "I want a pony" requests <-- Go's bug tracker labels such bugs with "ponies:" :>
2013-06-29 04:27:04 < muggs__> lol
2013-06-29 10:19:02 < JEEB> <Skyler_> since it's extremely difficult to debug if valgrind is covered with all kinds of other warnings (plus, they usually imply real bugs <- how true
2013-06-29 10:32:16 < Mandarinka> < Skyler_> IMO bugs should be resolved as soon as possible; if you need a tracker for it, you have too many bugs already <--- if I may react, I think it would be good to still have a database of bugs, because it isn't realsitic to have everything fixed right away. There are long-standing bugs in x264 cli for example (mkv muxing) that don't get fixed because they are probably unimportant. But if people r
2013-06-29 10:32:16 < Mandarinka> epeatedly come/ask about them, it can save time to have an organised list somewhere. Else you might end up with something like "unnoficial bug thread" on doom9 :)
2013-06-29 10:34:51  * Mandarinka wanted to set one up for x264 due those mkv muxing issues and possibly other unexpected things people might want to know about :). But then didn't have enough free time.
--- Day changed Sun Jun 30 2013
--- Day changed Mon Jul 01 2013
--- Day changed Tue Jul 02 2013
2013-07-02 08:26:22 < j-b> good morning
--- Day changed Wed Jul 03 2013
--- Day changed Thu Jul 04 2013
--- Day changed Fri Jul 05 2013
--- Day changed Sat Jul 06 2013
--- Day changed Sun Jul 07 2013
--- Day changed Mon Jul 08 2013
2013-07-08 12:24:24 < j-b> Good morning
2013-07-08 15:55:39 < easyfab> bm
--- Day changed Tue Jul 09 2013
--- Day changed Wed Jul 10 2013
--- Day changed Thu Jul 11 2013
2013-07-11 01:29:15 < muggs_> would you guys prefer that I rip out the HM's broken rate control and adaptive AQ code? or would it be better to leave them in place until they are replaced?
2013-07-11 01:34:14 < Skyler_> IMO it'd be better to stick with constant QP unless you intend to use some of the code
2013-07-11 01:34:35 < Skyler_> how does the AQ work, out of curiosity?
2013-07-11 01:34:55 < muggs_> constant QP is currently the hard-coded default.  the AQ code paths are all dead
2013-07-11 01:35:35 < Skyler_> oh, okay, so it's just nonsense
2013-07-11 01:44:02 < muggs> I seriously need to switch ISPs
2013-07-11 01:44:28 < Skyler_> maybe use a remote IRC host?   that at least means you don't lose connection to the server
2013-07-11 01:44:35 < Skyler_> quassel or the like if you want a GUIish thing
2013-07-11 01:56:27 < muggs> giving quassel a try
2013-07-11 02:27:54 < muggs> btw: i"m leaning towards keeping a bug-tracker, but not making it generally public.  mostly for developers to keep track of TODOs
2013-07-11 02:33:17 < Skyler_> makes sense, I guess, but it should be at least publicly visible maybe?
2013-07-11 02:36:07 < muggs> yeah, perhaps
--- Log closed Thu Jul 11 09:39:18 2013
--- Log opened Thu Jul 11 14:01:24 2013
2013-07-11 22:40:17 < DaKaZ> is there a github for any work going around x265 other than the c++ prototype that ming built a while back?
2013-07-11 22:53:53 < Skyler_> DaKaZ: as soon as I sign the agreement, x265 will be public and GPL
2013-07-11 22:54:11 < Skyler_> since you're an x264 shareholder, I can send it to you for review if you want
2013-07-11 22:55:04 < DaKaZ> that would be great
2013-07-11 22:55:08 < DaKaZ> thanks
2013-07-11 22:57:12 < Skyler_> what's your current email?
2013-07-11 23:03:02  * Skyler_ pokes DaKaZ 
--- Day changed Fri Jul 12 2013
2013-07-12 14:26:42 < DaKaZ> Skyler_: sorry, missed that before I bailed last night, you got it right
2013-07-12 15:04:55 < Skyler_> okay
--- Day changed Sat Jul 13 2013
--- Day changed Sun Jul 14 2013
--- Day changed Mon Jul 15 2013
--- Day changed Tue Jul 16 2013
2013-07-16 15:34:20 < JEEB> new draft for editors' proposed edits to HEVC v1 http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7757 / http://x264.fushizen.eu/random/JCTVC-N0041_v1.pdf
--- Day changed Wed Jul 17 2013
2013-07-17 02:29:37 < muggs> public release is tentatively scheduled for next Monday, or at least early next week
2013-07-17 02:32:46 < Skyler_> sorry for all the hassle
2013-07-17 02:33:18 < muggs_> not a problem, it's actually less than I expected
2013-07-17 02:35:32 < muggs_> I could use some advice.  the HM does a whole lot of fudging with the lambda values, it doesn't have a fixed mapping from QP -> lambda as x264 does.
2013-07-17 02:36:25 < muggs_> do you think it would be appropriate to just take the x264 lambda and lambda2 tables and replace all that logic?
2013-07-17 02:41:50 < Skyler_> That's probably fine, but I'd suggest a tiny bit of RD-curve testing to make sure the constants should be the same
2013-07-17 02:41:59 < Skyler_> e.g. the fudgy 0.9 and so forth in the comments on the tables
2013-07-17 02:42:22 < Skyler_> those constants come entirely from testing and are probably format-specific
2013-07-17 02:42:38 < muggs_> Yeah, I was looking at that 0.9 somewhat cross-eyed, couldn't tell where it came from
2013-07-17 02:43:03 < Skyler_> It's totally chosen via "test to see which is optimal across a range of videos"
2013-07-17 02:43:11 < Skyler_> no logic behind it at all, AFAIK
2013-07-17 02:43:18 < Skyler_> But it predates me
2013-07-17 02:43:26 < Skyler_> that's Laurent code, I think
2013-07-17 02:43:33 < muggs_> "looks good from here, put a nail in it" :)
2013-07-17 02:44:19 < muggs_> so by RD curve you mean running at various QP and measuring PSNR per bitrate?
2013-07-17 02:45:51 < Skyler_> yes, and optimizing the lambda for best RD curve
2013-07-17 02:45:59 < Skyler_> you can literally just chart it in excel and binary search
2013-07-17 02:46:38 < muggs_> ok, probably best to build the tables programically at first then
2013-07-17 02:46:42 < Skyler_> it doesn't have to be very precise; any value near the optimal is fine
2013-07-17 02:49:04 < muggs_> now that our agreement is settled, I can be more lenient with advance copies of the code, if anyone would like a peek.
2013-07-17 18:06:24 < muggs> j-b: I have a mailing list reply stuck in moderation.  How do I un-stuck it?
2013-07-17 18:07:19 < j-b> fixed
2013-07-17 18:07:33 < muggs> danke
2013-07-17 18:07:58 < j-b> I guess too big message
2013-07-17 18:14:40 < muggs> yeah, long patch
2013-07-17 18:14:46 < muggs> TLDR
2013-07-17 19:27:14 < muggs> j-b: any chance video lan could host something like patchwork?  http://jk.ozlabs.org/projects/patchwork/
2013-07-17 19:29:03 < muggs> the Mercurial devs get 10-20 patches a day and they use this to manage tracking them.  see http://patchwork.serpentine.com/project/hg/list/
2013-07-17 19:41:40 < JEEBsv> I think they already host patchwork
2013-07-17 19:51:16 < kierank> who's tree are the patches on the mailing list relative to
2013-07-17 19:54:54 < muggs> the patches submitted to the list are supposed to apply to the main devel branch, unless they are flagged for the stable branch
2013-07-17 19:55:45 < muggs> JEEBsv: you're right: http://patches.videolan.org/project/vlc-devel/list/
2013-07-17 19:57:00 < JEEBsv> yup
2013-07-17 19:57:01 < muggs> we'd just need to add a page for our mailing list
2013-07-17 19:58:41 < kierank> can i download hm and apply all the patches and get a working encoder?
2013-07-17 19:58:50 < kierank> or something close to that
2013-07-17 20:45:41 < Kovensky> I think libav uses (or used?) patchwork
2013-07-17 21:40:23 < j-b> muggs___: something like http://patches.videolan.org/project/vlc-devel/list/ ?
2013-07-17 21:40:36 < j-b> muggs___: if so, yes :)
2013-07-17 21:42:39 < JEEBsv> :)
2013-07-17 21:42:53 < j-b> JEEBsv: oh, you fucking toasted me :)
2013-07-17 21:43:01 < j-b> but, yes for patches.v.o :)
2013-07-17 22:34:03 < muggs__> kierank: only maybe 1% of our patches have gone through the mailing list.
2013-07-17 22:34:20 < muggs__> it was a recent change of work-flow
2013-07-17 22:35:31 < j-b> muggs___: does patches.videolan.org look OK for your need?
2013-07-17 22:41:43 < muggs__> yeah, should be fine
--- Day changed Thu Jul 18 2013
2013-07-18 06:59:58 < j-b> muggs_: https://patches.videolan.org/project/x265-devel/list/
2013-07-18 16:41:15 < j-b> muggs: ping
2013-07-18 16:45:01 < muggs> j-b: pong
2013-07-18 20:02:23 < muggs> heh, it seems a few people are discovering the mailing list
2013-07-18 20:04:39 < Skyler_>  nice
2013-07-18 20:04:46 < Skyler_> gosh I really hope this all works out
2013-07-18 20:05:19 < j-b> muggs: I'm trying to cover the news coverage with VLC for iOS though :)
2013-07-18 20:06:58 < muggs> at this point, it doesn't hurt if everyone knows about it.  the Monday date is just to make a coordindate media event.
2013-07-18 20:09:13 < muggs> been beating on the source with a hammer for a couple of weeks now.
2013-07-18 20:09:24 < muggs> trying to improve it from "eye bleed" to "merely annoying"
2013-07-18 20:09:27 < Skyler_> awesome
2013-07-18 20:14:14 < j-b> Skyler_: btw, would you like a x264 patchwork?
2013-07-18 20:14:51 < kierank> we don't really do mailing list stuff
2013-07-18 20:15:07 < Skyler_> I don't think it'd be that useful at this point
2013-07-18 20:15:17 < Skyler_> I wouldn't object if others wanted it though
2013-07-18 20:24:42 < kierank> the mailing list has gone?
2013-07-18 20:25:41 < Skyler_> ?
2013-07-18 20:26:14 < kierank> http://mailman.videolan.org/pipermail/x265-devel/
2013-07-18 20:26:27 < Skyler_> o_O
2013-07-18 20:26:29 < Skyler_> weird
2013-07-18 20:26:49 < JEEB> try looking at the x264-devel's url on the index
2013-07-18 20:26:58 < JEEB> and adapt that, should still show the basic info
2013-07-18 20:27:45 < JEEB> I haven't registered onto the mailing list so I don't know if the history works if you're logged in:)
2013-07-18 20:28:46 < JEEB> but I would just guess it was made !public and limited to known individuals :)
2013-07-18 20:29:31 < muggs_> only j-b has admin rights to the list, AFAIK
2013-07-18 20:30:55 < j-b> kierank: no, the archives are private until the official announce
2013-07-18 20:31:13 < j-b> muggs_: you are now maintainer on the patchwork
2013-07-18 20:31:16 < kierank> ok
2013-07-18 20:31:31 < muggs_> j-b: thanks
2013-07-18 20:32:16 < muggs_> lord, by the end of september I'll have 98k flight miles this year.  crazy
2013-07-18 20:34:56 < j-b> muggs_: you should see the accepted/superseded/dropbox
2013-07-18 20:35:42 < muggs_> yep, I've marked two accepted and the rest rejecte
2013-07-18 20:35:44 < muggs_> d
2013-07-18 20:36:23 < j-b> muggs_: great, can I do something else for you?
2013-07-18 20:36:51 < muggs_> nothing I can think of right now
2013-07-18 20:36:54 < muggs_> thanks
2013-07-18 21:53:27 < muggs_> I see this phc fellow logged in the day his ops expired and renewed them
--- Day changed Fri Jul 19 2013
2013-07-19 16:39:20 < j-b> muggs: ping
2013-07-19 23:17:16 < j-b> muggs_: ping
--- Day changed Sat Jul 20 2013
--- Log closed Sat Jul 20 08:35:33 2013
--- Log opened Sat Jul 20 09:19:27 2013
--- Log closed Sat Jul 20 09:19:27 2013
--- Log opened Sat Jul 20 10:11:40 2013
--- Day changed Sun Jul 21 2013
--- Day changed Mon Jul 22 2013
2013-07-22 11:35:21 < JEEB> any schedule on the publication btw?
--- Day changed Tue Jul 23 2013
2013-07-23 14:54:41 < muggs> Hi all.  https://bitbucket.org/multicoreware/x265
2013-07-23 14:55:43 < Skyler_> good morning~
2013-07-23 15:00:26 < Paranoialmaniac> nice :)
2013-07-23 15:01:55 < muggs> my internet has been very iffy lately, apologies if I drop
2013-07-23 15:13:15 < JEEBsv> yay
2013-07-23 16:41:57 < kierank> http://www.tomshardware.com/reviews/x265-hevc-encoder,3565-3.html
2013-07-23 16:41:57 < kierank> lol
2013-07-23 16:42:13 < kierank> psnr graph but they decided not to use tune psnr
2013-07-23 17:11:15 < JEEBsv> :D
2013-07-23 17:11:21 < JEEBsv> standard derp
2013-07-23 19:33:29 < Skyler_> it would be nice if muggs could get them to correct these things, but we can't hope for too much~
2013-07-23 19:58:11 < Daiz> <kierank> psnr graph but they decided not to use tune psnr
2013-07-23 19:58:46 < Daiz> and they even said they didn't use it because it "affects subjective quality"... then post no subjective quality comparison
2013-07-23 19:59:27 < Skyler_> yeah, it's rather amazing
2013-07-23 19:59:36 < Skyler_> apparently, the mcw guy specifically instructed them not to do quality benchmarks
2013-07-23 19:59:39 < Skyler_> And then they did.
2013-07-23 19:59:41 < Skyler_> Because they're tom's hardware
2013-07-23 20:23:39 < Daiz> http://media.bestofmicro.com/Z/3/393951/original/x265.jpg << props to multicoreware for living up to their name!
2013-07-23 20:24:22 < JEEB> if they are using WPP then even threading within picture would get quite simpler :D
2013-07-23 20:27:46 < Skyler_> Daiz: they're intending to use wavefront threading, so it will definitely scale better than x264
2013-07-23 20:28:39 < Daiz> What needs to be improved?
2013-07-23 20:28:39 < Daiz> - Everything :)
2013-07-23 20:28:40 < Daiz> ( ´∀`)
2013-07-23 20:28:52 < Daiz> anyway, exciting stuff all in all
2013-07-23 20:30:34 < Skyler_> heehee
2013-07-23 20:30:45 < Skyler_> yeah, basically.  I don't know if it'll get anywhere, but I'd rather have something than nothing
2013-07-23 20:34:08 < JEEB> there actually was an intra coder by prunedtree around, but after that there wasn't really any commits :s
2013-07-23 20:34:10 < JEEB> from me included
2013-07-23 20:35:03 < JEEB> that wasn't based on HM
2013-07-23 20:35:19 < JEEB> so yeah... this is way in front of it :D
2013-07-23 20:36:27 < JEEB> now we need the goddamn container specs :s
2013-07-23 20:43:40 < Daiz> JEEB: I remember you doing builds of HM, where were they at?
2013-07-23 20:43:53 < Daiz> mostly since the page recommends using HM for decoding raw H.265 bitstreams
2013-07-23 20:45:04 < JEEBsv> x264.fushizen.eu/builds and then there's a hevc-hm dir
2013-07-23 20:45:10 < Daiz> thanks
2013-07-23 20:45:30 < JEEBsv> the libavcodec decoder is already pretty good tho
2013-07-23 20:45:45 < JEEBsv> too bad I don't have the url to mpv that I had lachs0r build with it
2013-07-23 20:45:56 < Daiz> that'd be even better
2013-07-23 20:46:29 < JEEBsv> also I made a very quick n' dirty hevc-in-matroska hack using libavformat's default matroska muxing mode
2013-07-23 20:47:11 < JEEBsv> (which surprisingly worked)
2013-07-23 20:49:29 < JEEBsv> Daiz: anyways grep #darkhold logs for me noting "tmp.*.biz"
2013-07-23 20:49:42 < JEEBsv> srsfkn was it?
2013-07-23 20:49:52 < JEEBsv> that should lead you to a build from early july
2013-07-23 20:50:32 < Daiz> http://tmp.srsfckn.biz/mpv-x86_64-20130704.7z got this
2013-07-23 20:50:38 < JEEBsv> yup
2013-07-23 20:50:44 < JEEBsv> that's it
2013-07-23 20:50:44 < Daiz> great
2013-07-23 20:50:52 < JEEBsv> that contains le HEVC decoder
2013-07-23 20:51:02 < JEEBsv> and the lulzy matroska hack if you use --demuxer=lavf
2013-07-23 20:51:05 < Daiz> and can handle raw H.265 bitstreams?
2013-07-23 20:51:14 < JEEBsv> Annex B, yes
2013-07-23 20:51:30 < JEEBsv> might have to rename to dot-hevc
2013-07-23 21:19:28 < Thor__> how will h265 utilize multicore CPU's vs multicore GPU's ?
2013-07-23 21:19:53 < Thor__> is it designed for gpu encoding from scratch?
2013-07-23 21:20:18 < kierank> wavefront processing
2013-07-23 21:21:35 < Daiz> aww, x265 can't take 16-bit input
2013-07-23 21:21:53 < Daiz> or maybe it's just this compile
2013-07-23 21:29:54 < Daiz> oh it finally started
2013-07-23 21:29:56 < Daiz> >0.16 fps
2013-07-23 21:30:12 < Daiz> yikes
2013-07-23 21:34:03 < Daiz> x265 sure seems to take it sweet time to start doing something
2013-07-23 21:34:35 < Daiz> it's been saying "0 frames: 0.00 fps, 0.00 kb/s" for the past couple minutes while CPU usage has been 100%
2013-07-23 21:34:46 < Daiz> so I guess it's doing... something?
2013-07-23 21:34:50 < Skyler_> If it buffers frames like x264 does, it could do That Thing where it counts fps based on output frames instead of input
2013-07-23 21:35:27 < Daiz> well hopefully it will actually start reporting something at some point
2013-07-23 21:36:28 < Daiz> I like how at this state x265 is already leagues ahead in usability compared to HM
2013-07-23 21:37:05 < Skyler_> I know, right?
2013-07-23 21:37:58 < Daiz> yuv [info]: 1280x720 24Hz, frames 0 - 1727 of -1378
2013-07-23 21:38:03 < Daiz> that -1378 looks a bit wonky
2013-07-23 21:38:15 < Daiz> maybe that's causing the progress report issues
2013-07-23 21:38:16 < Daiz> idk
2013-07-23 21:38:31 < Skyler_> maybe your video just happens to violate causality?
2013-07-23 21:38:38 < Daiz> who knows
2013-07-23 21:38:46 < JEEBsv> well the cmake script seemingly had a typo as well
2013-07-23 21:38:52 < Skyler_> and maybe when you play it back, it finishes before it starts
2013-07-23 21:38:56 < JEEBsv> so i'd guess there'll be plenty of bugs
2013-07-23 21:39:47 < Daiz> but well, once again, it certainly seems to be doing _something_ seeing the 100% CPU utilization
2013-07-23 21:39:52 < Daiz> just gotta wonder what that something actually is
2013-07-23 21:45:56 < Daiz> still 0 frames
2013-07-23 21:46:06 < Daiz> (;´д`)
2013-07-23 21:48:55 < Daiz> oh, now it just jumped to 192 frames
2013-07-23 21:49:27 < Daiz> maybe I should cut my frames to a quarter
2013-07-23 22:01:56 < Daiz> [44.4%] 192/432 frames, 1.08 fps, 1085.61 kb/s, eta 0:03:41
2013-07-23 22:02:00 < Daiz> now we're getting somewhere
2013-07-23 22:09:30 < Daiz> I guess H.265 is now officially faster than VP9 encoding, though!
2013-07-23 22:09:48 < Daiz> unless they've managed to speed it up tremendously since I last tried it
2013-07-23 22:19:22 < muggs> Hey guys, just got back.  I had 3 yards of dirt delivered on my driveway this morning that had to be dealt with
2013-07-23 22:20:18 < muggs> Skyler_: what things did you want addressed?  I don't have any of that in my back-log.
2013-07-23 22:20:43 < Skyler_> 02:41 < kierank> http://www.tomshardware.com/reviews/x265-hevc-encoder,3565-3.html
2013-07-23 22:20:43 < Skyler_> 02:41 < kierank> lol
2013-07-23 22:20:43 < Skyler_> 02:41 < kierank> psnr graph but they decided not to use tune psnr
2013-07-23 22:20:43 < Skyler_> 03:11 < JEEBsv> :D
2013-07-23 22:20:46 < Skyler_> 03:11 < JEEBsv> standard derp
2013-07-23 22:20:57 < Skyler_> that's what I mentioned, but besides that, there's making j-b happy :p
2013-07-23 22:21:01 < muggs> yeah, that annoyed me too
2013-07-23 22:21:01 < Skyler_> er, what I meant
2013-07-23 22:23:36 < muggs> yes, this situation with j-b is totally regretful.
2013-07-23 22:24:12 < muggs> to answer some earlier points.  When you use --gops > 1, the progress reporting is stupid slow.  only once per keyframe
2013-07-23 22:24:37 < muggs> normally progress reports happen once a mini-gop which is usually 4 frames.
2013-07-23 22:25:11 < muggs> by the time we integrate the lookahead, it should operate more closely like x264 and update once a frame or roughly once a second
2013-07-23 22:26:10 < muggs> the negative frame count is interesting.  it's trying to estimate the number of frames in the file.  perhaps there is an int overflow
2013-07-23 22:28:15 < BugMaster> muggs: yes, this situation with j-b is totally regretful. <- what with j-b? (I missed something?)
2013-07-23 22:28:36 < Skyler_> just bad communication between videolan and mcw related to x265
2013-07-23 22:34:49 < Daiz> well
2013-07-23 22:34:51 < Daiz> as it turns out
2013-07-23 22:35:08 < Daiz> x265 didn't like me feeding y4m file as test.yuv
2013-07-23 22:35:13 < Daiz> the output was garbled too
2013-07-23 22:35:31 < Daiz> as I realized my mistake I renamed it to test.y4m and removed --width height etc params and it worked out fine
2013-07-23 22:36:45 < Daiz> well this is... interesting
2013-07-23 22:37:03 < Daiz> x264 reports a slightly higher bitrate (file output to mkv) than x265
2013-07-23 22:37:12 < Daiz> but the raw hevc stream has a bigger filesize...
2013-07-23 22:48:04 < Daiz> detail-wise this x265 seems to fare quite nicely
2013-07-23 22:48:12 < Daiz> but gradients, man
2013-07-23 22:48:16 < Daiz> banding up the bum
2013-07-23 22:48:58 < Skyler_> probably a lack of AQ/psy/etc
2013-07-23 22:49:25 < muggs> WPP is intended to be the main threading component, with frame parallelism to be added a bit later
2013-07-23 22:50:02 < muggs> GOP parallelism was a short-term hack to figure out how many frame threads we needed to saturate a 16 core server, and to estimate performance
2013-07-23 22:50:20 < muggs> turns out we need 6 parallel frames + WPP
2013-07-23 22:50:48 < muggs> and yeah, we have no psy-opts or AQ
2013-07-23 22:52:42 < Daiz> anyway, I'm positively surprised all in all
2013-07-23 22:57:00 < Daiz> http://check2pic.ru/compare/30357/ a quick comparison
2013-07-23 22:57:57 < Daiz> x264-10bit --preset placebo --tune animation --aq-mode 3 --crf 18 -i 1 -I 48 --frames 432 --colormatrix bt709
2013-07-23 22:58:01 < Daiz> x265 --input test8.y4m --wpp --gops 4 --keyint 48 -q 15 --frames 432
2013-07-23 22:58:13 < Skyler_> oh, of course.  x265 is probably using 8-bit
2013-07-23 22:58:45 < Daiz> but 8bit H.265 was supposed to minimize banding issues!
2013-07-23 22:59:00 < Skyler_> it was?
2013-07-23 22:59:00 < Daiz> because of IBDI and such
2013-07-23 22:59:08 < Skyler_> did they actually end up using that?
2013-07-23 22:59:12 < Daiz> idk
2013-07-23 22:59:12 < Skyler_> I thought it was dropped >_<
2013-07-23 22:59:21 < Daiz> but at least that's what was talked about on doom9 quite extensively
2013-07-23 23:00:06 < Skyler_> a lot of things were dropped iirc
2013-07-23 23:11:46 < Daiz> well, if 8bit is going to be as banding-sensitive as with H.264, then I guess Main 10 Profile will be the way to go
2013-07-23 23:15:21 < BugMaster> #4 looks like to have blocking problems not sure to call this banding
2013-07-23 23:16:27 < Daiz> when talking about banding
2013-07-23 23:16:29 < Daiz> take a look at shot 5
2013-07-23 23:17:07 < BugMaster> eh. #2 and #5 have a lot of banding problems
--- Day changed Wed Jul 24 2013
2013-07-24 00:03:29 < muggs_> we're real close to landing a consortium member who wants 10/12bit 4:4:4 4k/8k; so we will probably have a team heading in that direction soon
2013-07-24 00:14:23 < Daiz> >4:4:4
2013-07-24 00:14:37 < Daiz> aren't the main profiles (sadly) limited to 4:2:0 though
2013-07-24 00:16:36 < kierank> yes 422 and 444 doesn't exist yet
2013-07-24 00:59:14 < foonix> oh nice, x264 folks are here.. somehow C++ mercurial CamelCase made me wonder.. (no flaming intended) :)
2013-07-24 00:59:56 < Skyler_> a lot of the ugliness is inherited from HM, which will take much work to exorcise, I imagine
2013-07-24 01:01:57 < foonix> yeah, that makes sense
2013-07-24 01:01:59 < Daiz> but it's really damn annoying how we're still going to be stuck with 4:2:0 in H.265
2013-07-24 01:10:24 < Mandarinka> Congratulations on the announcement/release, both to MCW and Videolan/x264! \o/
2013-07-24 02:01:26 < muggs> cheers
2013-07-24 02:14:34 < Kovensky> btw, how does the HM heritage affect the code license-wise?
2013-07-24 02:17:57 < Mandarinka> gnight & bye
2013-07-24 02:19:00 < Skyler_> Kovensky: I think HM is BSDish
2013-07-24 02:19:11 < Kovensky> <Daiz> anyway, I'm positively surprised all in all <-- so, when will we see HEVC Underwater releases? :)
2013-07-24 02:20:05 < Kovensky> Skyler_: so x265 is GPLv2 with parts BSD? or does the GPLv2 of the modifications infect everything else?
2013-07-24 02:25:25 < Skyler_> GPLv2 infects everything, yes
2013-07-24 02:25:25 < Skyler_> (for practical purposes)
2013-07-24 02:25:25 < Skyler_> the choice in this case was between proprietary and GPL though, we would not be able to have gotten BSD
2013-07-24 02:25:26 < Kovensky> yeah, I knew of the MCW constraints; just wondered what happened to the HM parts of the code
2013-07-24 02:25:54 < Kovensky> IIRC you're going with a x264LLC-like system? GPL for general purpose, proprietary with contracts?
2013-07-24 02:26:02 < Kovensky> (but not yet, I suppose)
2013-07-24 02:27:54 < Skyler_> Yeah, it'll be managed by MCW
2013-07-24 02:28:07 < Skyler_> under the same constraints as x264 LLC, which they pretty much had to agree with to get rights to x264
2013-07-24 07:47:40 < Daiz> encoding 10-bit video with x265 seems to be... pretty slow
2013-07-24 07:47:51 < Daiz> not that it would be particularly surprising
2013-07-24 07:51:42 < Daiz> ~6300MB memory usage for encoding 720p video with 16bit input
2013-07-24 08:07:55 < Daiz> over 20 minutes in and it still hasn't given even the first progress report
2013-07-24 08:09:40 < Skyler_> I'm guessing it has no asm for 10-bit yet
2013-07-24 08:09:54 < Skyler_> they copied in a lot of x264 asm and such for 8-bit
2013-07-24 08:10:11 < Skyler_> so 10x slower would tooootally leave me unsurprised
2013-07-24 08:11:46 < Daiz> yeah it's not exactly unexpected
2013-07-24 08:11:50 < Daiz> that this would be slow as hell
2013-07-24 08:12:53 < Daiz> I wonder if the libavcodec HEVC decoder will be able to decode this
2013-07-24 08:13:16 < Daiz> it seems to have no issues with any 8-bit tests I've encoded so far
2013-07-24 08:18:13 < Daiz> ooh first progress report!
2013-07-24 08:18:14 < Daiz> 0.09fps
2013-07-24 08:18:55 < Daiz> >[44.4%] 192/432 frames, 0.09 fps, 97658.20 kb/s, eta 0:44:36
2013-07-24 08:18:59 < Daiz> that bitrate doesn't look quite right...
2013-07-24 08:19:06 < Daiz> no wonder it's so damn slow
2013-07-24 08:20:35 < Daiz> well, it got fucked
2013-07-24 08:20:37 < Daiz> time to retry
2013-07-24 08:21:11 < Daiz> I guess y4m properties override width depth etc
2013-07-24 08:23:54 < Daiz> >x265-hbd.exe has stopped working
2013-07-24 08:23:57 < Daiz> and now it crashed
2013-07-24 08:24:02 < Daiz> I guess I'll just feed it 8bit input...
2013-07-24 08:28:42 < Daizz> I guess libavcodec can't really cope with 10-bit H.265 yet
2013-07-24 08:28:46 < Daizz> http://puu.sh/3KrmU.jpg
2013-07-24 08:29:18 < Skyler_> Daiz: oops
2013-07-24 08:30:05 < JEEB> :)
2013-07-24 08:30:07 < Daiz> on the plus, 10-bit encoding wasn't THAT slow, at least with this low of a bitrate
2013-07-24 08:30:08 < Daiz> encoded 432 frames in 184.78s (2.34 fps), 248.47 kb/s
2013-07-24 08:31:10 < JEEB> I didn't test 10bit decoding myself at all because lolHM
2013-07-24 08:31:27 < JEEB> encoding a single 2164 frame sample with HM in 8bit mode was fun enough for me :D
2013-07-24 08:32:38 < Skyler_> yeah, I love how I heard from various MCW people things like "well it's 100 times faster so far, and it goes at 0.1 fps"
2013-07-24 08:33:11 < JEEB> Total Time:    89242.850 sec.
2013-07-24 08:33:15 < JEEB> 720p, 2164 frames
2013-07-24 08:33:23 < Skyler_> impressive.
2013-07-24 08:35:56 < Daiz> then again I guess something might be wrong with the encode as well, trying to decode with HM to YUV (with -d 8) and reading with rawsource gives a nice green picture as well
2013-07-24 08:36:40 < JEEB> :D
2013-07-24 08:36:48 < JEEB> that's possible too, the code did look rather OK
2013-07-24 08:37:03 < JEEB> lemme see if the test files repo has any 10bit streams >_>
2013-07-24 08:37:37 < JEEB> yay, corp-specific naming
2013-07-24 08:37:44  * JEEB looks at the excel spreadsheet
2013-07-24 08:40:54 < Daiz> yeah seems like the issue is in the encode itself
2013-07-24 08:41:17 < JEEB> lal, the test suite is 100% limited to the 8bit files
2013-07-24 08:41:34 < JEEB> time to look at the itu-t ftp I guess
2013-07-24 08:43:35 < Daiz> <Kovensky> <Daiz> anyway, I'm positively surprised all in all <-- so, when will we see HEVC Underwater releases? :)
2013-07-24 08:43:41 < Daiz> not anytime soon, that's for sure
2013-07-24 08:43:51 < Daiz> while the results are promising they're still clearly overall worse than 10-bit x264
2013-07-24 08:43:55 < Daiz> not to mention many times slower to encode
2013-07-24 08:44:27 < JEEB> ericsson's 10bit sample seems to go green as well
2013-07-24 08:44:36 < Daiz> when decoded?
2013-07-24 08:44:38 < Daiz> with hm
2013-07-24 08:45:00 < JEEB> not with HM, didn't try that yet
2013-07-24 08:45:07 < JEEB> tried http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/under_test/WPP_F_ericsson_MAIN10_2.zip
2013-07-24 08:45:27 < Daiz> gonna see how that decodes with HM
2013-07-24 08:45:51 < Daiz> is that .bit file the hevc bitstream
2013-07-24 08:46:12 < JEEB> yes
2013-07-24 08:48:07 < Daiz> well, decoding it with HM to 10bit and encoding with x264 --input-depth 10 seems to result in working picture
2013-07-24 08:48:24 < Daiz> while doing the same to my test encode results in green
2013-07-24 08:48:28 < Daiz> so I guess the encode is ultimately fucked
2013-07-24 08:48:43 < JEEB> k
2013-07-24 10:47:36 < JEEB> wonder how hard it would be to bolt a proper frame decision thing into x265
2013-07-24 10:47:50 < JEEB> s/frame/picture/
2013-07-24 11:25:01 < Daemon404> so uh, is there any intention of cleaning up the vec/*.inc files to actually be maintainable?
2013-07-24 11:25:11 < Daemon404> they look like they were generated by a complex perl script
2013-07-24 11:26:06 < JEEB> I would guess so
2013-07-24 11:26:37  * Daemon404 is very wary of this corporate business and 'good enough'
2013-07-24 11:26:50 < Shiz> did I join in time to shit on x265
2013-07-24 11:26:53 < JEEB> lol
2013-07-24 11:27:28 < Shiz> wait, I haven't even tried to build it yet
2013-07-24 11:27:30 < Shiz> this will be fun
2013-07-24 11:27:36 < JEEB> it should build rather well
2013-07-24 11:27:54 < JEEB> cd build/linux && sh thatSingleShellScript
2013-07-24 11:27:56 < Shiz> I'm on OSX
2013-07-24 11:27:57 < JEEB> then wait for cmake to roll
2013-07-24 11:28:06 < Shiz> oh, welp
2013-07-24 11:28:11 < Shiz> no build scripts for OSX
2013-07-24 11:28:12 < JEEB> then you will get the makefile
2013-07-24 11:28:13 < Shiz> : D
2013-07-24 11:28:20 < JEEB> Shiz, they all base on the cmake stuff
2013-07-24 11:28:22 < Daemon404> multiple build systems?
2013-07-24 11:28:23 < JEEB> thus, grab cmake
2013-07-24 11:28:35 < JEEB> I bet you could even get an xcode project out of it
2013-07-24 11:28:38 < JEEB> if you'd really want
2013-07-24 11:28:41 < JEEB> IIRC
2013-07-24 11:28:49 < Shiz> haha oh fuck
2013-07-24 11:29:00 < Shiz> their linux build script is an interactive cmake session
2013-07-24 11:29:02 < Shiz> killl meeee
2013-07-24 11:29:07 < JEEB> wut
2013-07-24 11:29:11 < JEEB> it was quite uninteractive for me
2013-07-24 11:29:40 < Shiz> CMAKE_BUILD_TYPE: Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
2013-07-24 11:30:19 < Shiz> it allows you edit all the option
2013-07-24 11:30:21 < JEEB> Daemon404, anyways it's a /very/ legit concern, did they have an issue thingy yet?
2013-07-24 11:30:22 < Shiz> in a curses-like interface
2013-07-24 11:30:26 < Shiz> options*
2013-07-24 11:30:30 < JEEB> that probably was added after I built
2013-07-24 11:31:08 < Shiz> /Users/mark/Development/Sources/x265/source/Lib/TLibCommon/CommonDef.h:42:10: fatal error: 'malloc.h' file not found
2013-07-24 11:31:10 < Shiz> #include <malloc.h>
2013-07-24 11:31:12 < Shiz>          ^
2013-07-24 11:31:18 < Shiz> Shiz's adventures in compiling x265
2013-07-24 11:31:42 < JEEB> o_O
2013-07-24 11:31:47 < JEEB> also anyone here has good reading regarding picture type decisions
2013-07-24 11:31:48 < Daemon404> JEEB, i dont see one.
2013-07-24 11:31:50 < Shiz> who the fuck uses malloc.h
2013-07-24 11:31:52 < JEEB> Daemon404, k
2013-07-24 11:31:55 < Shiz> like what the fuck
2013-07-24 11:32:04 < Shiz> if I knew how to use hg i'd submit a patch
2013-07-24 11:32:06 < Shiz> :D
2013-07-24 11:32:19 < JEEB> just use it like svn
2013-07-24 11:32:23 < JEEB> hg help is also available
2013-07-24 11:32:34 < JEEB> it's kind of clunky but should work
2013-07-24 11:32:43 < Shiz> it's actually in Tk
2013-07-24 11:32:47 < Shiz> err
2013-07-24 11:32:49 < Shiz> TLib
2013-07-24 11:32:51 < Shiz> wtf tk
2013-07-24 11:33:11 < Shiz> oh man
2013-07-24 11:33:13 < Shiz> CommonDef.h
2013-07-24 11:33:17 < Shiz> I'm in for a wild ride aren't I
2013-07-24 11:33:39 < JEEB> it's called "basing yer code on lulzy company-written C++"
2013-07-24 11:33:41 < JEEB> aka HM
2013-07-24 11:33:44 < Shiz> m_qp     = (Char*)xMalloc(Char,   numPartition);
2013-07-24 11:33:47 < Shiz> heeelp
2013-07-24 11:34:09 < JEEB> anyways, it's one helluva cleanup we're left with :D
2013-07-24 11:34:12 < Shiz> I'll do some patches to make it work under OSX I guess
2013-07-24 11:34:15 < Shiz> the least I can do
2013-07-24 11:34:15 < JEEB> but at least it runs >1fps already
2013-07-24 11:34:20 < JEEB> on Daiz's machine
2013-07-24 11:34:25 < JEEB> which is faster than libvpx with VP9
2013-07-24 11:36:05 < Daiz> yeah for such an early state the speed is quite impressive
2013-07-24 11:36:11 < JEEB> naturally
2013-07-24 11:36:19 < JEEB> since it doesn't have any picture type analysis at this stage
2013-07-24 11:36:24 < JEEB> it's not really surprising
2013-07-24 11:36:40 < JEEB> but yeah, the asm/whatever files should be made more sane-looking and maintainable
2013-07-24 11:36:44 < Daiz> true, but it does manage to use 100% of my CPU all the time
2013-07-24 11:36:50 < JEEB> well, as I said
2013-07-24 11:36:56 < JEEB> WPP makes saturating shit rather easy
2013-07-24 11:37:03 < JEEB> since you can thread within picture a lot
2013-07-24 11:37:26 < JEEB> divx's decoder doesn't implement picture-based threading at all so far
2013-07-24 11:37:27 < JEEB> only WPP
2013-07-24 11:37:34 < JEEB> it seems to be the new hip thing
2013-07-24 11:37:52 < Shiz> Linking CXX executable x265
2013-07-24 11:37:54 < Shiz> ld: library not found for -lrt
2013-07-24 11:37:56 < Shiz> SO CLOOOSE
2013-07-24 11:38:24 < Daiz> I was personally positively surprised how simple it was to build on windows
2013-07-24 11:38:44 < Daiz> run .bat to run cmake, hit generate, run build .bat, get x265
2013-07-24 11:39:04 < JEEB> well, yeah -- cmake creates stuff nicely as long as you don't cross-compile
2013-07-24 11:39:14 < JEEB> auta armias if you try to cross-compile with it tho
2013-07-24 11:39:53 < Shiz> it impressively fails to link
2013-07-24 11:39:56 < JEEB> btw Daiz -- feel free to test out https://fushizen.eu/u/jeeb/derp/testing_lavf_hack_remux.mkv with --demuxer=lavf in that mpv build :)
2013-07-24 11:39:59 < Shiz> and I have reason why
2013-07-24 11:40:02 < Shiz> no*
2013-07-24 11:40:40 < Daiz> JEEB: sure
2013-07-24 11:40:48 < Shiz> http://bpaste.net/show/116931/
2013-07-24 11:40:59 < JEEB> it isn't encoded with WPP so it doesn't multithread when decoding of course
2013-07-24 11:41:00 < JEEB> but still
2013-07-24 11:41:01 < JEEB> lul
2013-07-24 11:41:22 < Shiz> int (anonymous namespace)::cmp<32, 32, 16, 16, &(x265_pixel_sa8d_16x16_avx)>(unsigned char*, long, unsigned char*, long)
2013-07-24 11:41:27 < Shiz> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2013-07-24 11:41:33 < JEEB> Shiz, "ld: symbol(s) not found for architecture x86_64"
2013-07-24 11:41:41 < JEEB> sounds like your linker and compiler are trying to do different things
2013-07-24 11:42:11 < Daiz> JEEB: seems to work just fine
2013-07-24 11:42:26 < Shiz> JEEB: sounds like misconfigured buildscripts then
2013-07-24 11:42:37 < Shiz> but it always adds 'for architecture'
2013-07-24 11:43:07 < Shiz> hey
2013-07-24 11:43:09 < Shiz> at least I got close?
2013-07-24 11:43:39 < Shiz> actually a question
2013-07-24 11:43:50 < Shiz> what purpose does aligning on 32-bit boundaries have
2013-07-24 11:43:52 < Shiz> for SSE data?
2013-07-24 11:44:20 < JEEB> it lets you do aligned access
2013-07-24 11:44:23 < JEEB> basically
2013-07-24 11:44:31 < JEEB> aligned access in general is good
2013-07-24 11:44:46 < Shiz> well
2013-07-24 11:44:50 < Shiz> "The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types."
2013-07-24 11:44:53 < Shiz> -- OSX malloc(3)
2013-07-24 11:45:04 < Shiz> and since OSX doesn't have memalign, I'll just #define xMalloc to malloc
2013-07-24 11:46:28 < JEEB> yeah, seems like OS X does 16 byte mem aligned o_O
2013-07-24 11:46:56 < Shiz> all the better
2013-07-24 11:48:04 < JEEB> http://stackoverflow.com/a/12055862/1620828
2013-07-24 11:50:33 < Shiz> basically all the .asm code isn't properly linked in
2013-07-24 11:58:30 < Shiz> http://bpaste.net/show/x2uVUHGpyVEyjkZ2NLOq/
2013-07-24 11:58:36 < Shiz> changed some code to this
2013-07-24 11:58:41 < Shiz> from CommonDef.h:161
2013-07-24 12:01:04 < JEEB> Shiz, on any sane mingw platform the MS aligned malloc stuff should be usable
2013-07-24 12:02:16 < Shiz> mingw part isn't mine :p
2013-07-24 12:02:19 < Shiz> I only added the OSX stuff
2013-07-24 12:02:26 < Shiz> and changed the #else to #elif __linux__
2013-07-24 12:04:07 < JEEB> but yeah, the mingw stuff surely isn't needed any more, I'll test later
2013-07-24 12:04:52 < Shiz> cool
2013-07-24 12:05:16 < Shiz> man
2013-07-24 12:05:23 < Shiz> where does cmake store the intermediate object files
2013-07-24 12:05:26 < Shiz> it's a clusterfuck
2013-07-24 12:07:31 < Daemon404> iirc it's like
2013-07-24 12:07:38 < Daemon404> .something/something/file.cpp.o
2013-07-24 12:07:52 < JEEB> in other words, ls -alh helps
2013-07-24 12:08:14 < Shiz> yeah I just used find(1)
2013-07-24 12:08:27 < Shiz> no idea why it cna't find the symbols
2013-07-24 12:11:25 < koda> isn't the x264.inc in place for writing east asm?
2013-07-24 12:14:56 < JEEB> I would guess it is since there's some yasm asm around
2013-07-24 12:16:41 < Shiz> find . -name '*.o' -exec gobjdump -T {} -b elf64-x86-64 \; 2>/dev/null | grep x265_pixel
2013-07-24 12:16:42 < Shiz> <3
2013-07-24 12:16:50 < Shiz> it shows me the symbols are properly exported
2013-07-24 12:23:16 < Shiz> you can't make this shit up
2013-07-24 12:23:25 < Shiz> some asm things are prefixed with _, some aren't
2013-07-24 12:28:54 < JEEB> can you see if some of those are asm and some intrinsics?
2013-07-24 12:29:00 < JEEB> or are they definitely all asm?
2013-07-24 12:31:19 < Shiz> the C++ primitives are prefixed with a _
2013-07-24 12:31:21 < Shiz> the rest isn't
2013-07-24 12:50:11 < JEEB> Shiz, funky -- I'll probably take a longer look after I (possibly) get 10.6 installed on this macbook >_>
2013-07-24 12:50:44 < JEEB> https://plus.google.com/104244485442810148916/posts/9VmAarTPDyy got it to this situation yesterday
2013-07-24 12:52:03 < JEEB> j-b, is there any issue reporting system in planning for this project?
2013-07-24 12:52:10 < JEEB> or what was going to be the idea for that :V
2013-07-24 12:52:12 < Skyler_> I think so, they mentioned a patchwork
2013-07-24 12:52:16 < Skyler_> or something?
2013-07-24 12:52:24 < JEEB> patchwork would handle patches at least
2013-07-24 12:52:28 < Skyler_> both j-b and muggs showed interest in a bug tracker or something like that
2013-07-24 12:52:33 < JEEB> k
2013-07-24 12:52:36 < Skyler_> which would probably be useful especially early on when there's five million bugs
2013-07-24 12:52:47 < JEEB> yeah
2013-07-24 12:53:09 < JEEB> btw, any recommended reading for me or fazias if we're interested in writing picture coding type selection code?
2013-07-24 12:53:30 < JEEB> other than of course x264's frame type selection stuff
2013-07-24 12:56:07 < Skyler_> I think their intent is to outright copy the lookahead code for now?
2013-07-24 12:57:05 < JEEB> doesn't sound like a too bad idea
2013-07-24 12:57:11 < Skyler_> do you mean something besides that ...?
2013-07-24 12:57:40 < Skyler_> picture coding type selection code in my experience is mostly a combination of two things
2013-07-24 12:57:48 < Skyler_> an Estimate The Cost Of This Frame function
2013-07-24 12:57:54 < Skyler_> and Some Algorithm That Calls It A Bunch
2013-07-24 12:58:04 < JEEB> and then select one that seems most optimal
2013-07-24 12:58:11 < JEEB> yeah
2013-07-24 12:58:17 < Skyler_> so like b-adapt 2 is a viterbi implementation of the latter
2013-07-24 12:58:36 < JEEB> gonna have to read some x265 code to see how the hell that stuff kind of works on that side
2013-07-24 12:58:39 < JEEB> and where to hack it up
2013-07-24 12:59:00 < Skyler_> yeah >_<
2013-07-24 13:00:31 < Skyler_> I'm glad there's suddenly so much interest in x265 now, I guess it's nice to have something new that actually has a ton of places that can be improved
2013-07-24 13:00:32 < JEEB> ok, time for me to get to the uni >_> don't have a charger for this macbook and the battery is either dead or has to be somehow poked
2013-07-24 13:02:33 < JEEB> and thankfully MSVS13 will add some extra C support
2013-07-24 13:02:44 < JEEB> so even if this project would be C'ified
2013-07-24 13:02:49 < JEEB> it should be buildable
2013-07-24 13:12:59 < Kovensky> <Daiz> not anytime soon, that's for sure <-- heh
2013-07-24 13:13:11 < Kovensky> even for troll releases, we still need a decoder in libavcodec
2013-07-24 13:13:41 < JEEB> which is mostly just a merge away to be honest
2013-07-24 13:13:45 < JEEB> the container related stuff is the problem
2013-07-24 13:14:17 < Kovensky> true
2013-07-24 13:14:22 < Kovensky> still no response at all from matroska?
2013-07-24 13:14:28 < Skyler_> yeah, I hope people will soon get over this "we'll b encoding in H.265 next week" expectation :P
2013-07-24 13:14:33 < Skyler_> *be
2013-07-24 13:14:49 < Daiz> I've been trying to tell people that since January
2013-07-24 13:15:03 < Daiz> yet it still persists
2013-07-24 13:15:03 < JEEB> Kovensky, matroska is tied to 14496-15 AMD2
2013-07-24 13:15:08 < JEEB> which is still nowhere to be seen
2013-07-24 13:15:09 < Skyler_> I just try to remind people that nobody used x264 in 2004
2013-07-24 13:15:12 < JEEB> yeah
2013-07-24 13:15:20 < JEEB> I think Nero's AVC encoder was the first thing
2013-07-24 13:15:25 < Skyler_> and it literally took, like, 5 years
2013-07-24 13:15:32 < Skyler_> and that 5 years is a really really long time
2013-07-24 13:15:37 < Daiz> it really is
2013-07-24 13:15:43 < JEEB> yup
2013-07-24 13:15:48 < Skyler_> personally I do feel like it might happen faster this time
2013-07-24 13:15:53 < Skyler_> but faster probably means "1 or 2 years" not "next month"
2013-07-24 13:15:57 < JEEB> indeed
2013-07-24 13:15:57 < Daiz> yeah
2013-07-24 13:16:08 < JEEB> anyways, getting the containers set would be very fabulous though
2013-07-24 13:16:25 < JEEB> I can do my hacks with libavformat but that's not pretty at all
2013-07-24 13:16:26 < Skyler_> if we can get 10-bit all set up, it might be able to replace x264 in anime encoding sooner, at least
2013-07-24 13:16:31 < Daiz> I've said to people that H.265 will be practical sometime in 2014 at the very earliest
2013-07-24 13:16:45 < Skyler_> but we'd want proper SIMD in the decoder and everything, and even that would be another 6-12 months minimum for everything on both ends
2013-07-24 13:17:02 < Kovensky> <Skyler_> yeah, I hope people will soon get over this "we'll b encoding in H.265 next week" expectation :P <-- heh
2013-07-24 13:17:09 < Kovensky> I'm not seriously expecting anyone to do that anytime soon
2013-07-24 13:17:18 < Skyler_> I didn't mean you !
2013-07-24 13:17:21 < Kovensky> only as possibly troll releases to get people to upgrade their decoders
2013-07-24 13:17:25 < Skyler_> :P
2013-07-24 13:17:36 < Daiz> well, people with no clue tend to take marketing at face value
2013-07-24 13:17:39 < Daiz> "H.265 standard approved"
2013-07-24 13:17:44 < Daiz> "IT'S OVER, H.264 IS FINISHED"
2013-07-24 13:17:52 < Daiz> "google says vp9, like, totally rocks your socks"
2013-07-24 13:18:02 < Daiz> "IT'S OVER, H.264/H.265 IS FINISHED"
2013-07-24 13:18:23 < JEEB> I thankfully have a good amount of signal muting for that
2013-07-24 13:18:59 < Skyler_> Daiz: I think that's in large part 4channish trolling
2013-07-24 13:19:09 < Skyler_> and when you read 4chan and its brethren, well
2013-07-24 13:19:14 < Skyler_> you do only have yourself t blame :p
2013-07-24 13:19:29 < Daiz> it's layered in that but there are people who seriously expect that H.265 would be ready for real-world use based on announcements like that
2013-07-24 13:19:30 < Daiz> or VP9
2013-07-24 13:19:53 < Skyler_> yeah
2013-07-24 13:20:21 < Daiz> well, luckily the message seems to have gone through to at least some people
2013-07-24 13:20:29 < Kovensky> at any rate, I was also positively surprised that something this young and completely unoptimized is still only slightly worse than the world's current best encoder
2013-07-24 13:20:54 < Daiz> well, "slightly" as long as we're not talking about gradients ( ´∀`)
2013-07-24 13:21:06 < Kovensky> well yeah :P
2013-07-24 13:21:09 < Daiz> though compared to 8bit H.264 it only fares somewhat worse in regard to gradients
2013-07-24 13:21:14 < Kovensky> you should see how it fares vs 8bit H.264
2013-07-24 13:21:18 < Kovensky> oh, there we go
2013-07-24 13:21:36 < Skyler_> H.265 is really a pretty good spec, it seems to get 30-50% compression just by being better, which is enough to (depending on source) compete pretty well with the full total of everything x264 has come up with
2013-07-24 13:21:53 < Skyler_> doubly so on anime where psy helps less
2013-07-24 13:21:59 < Daiz> yeah, it does seem very promising
2013-07-24 13:22:14 < Kovensky> I wonder how much of libx264 would be helpful
2013-07-24 13:22:19 < Skyler_> the entirety of lookahead
2013-07-24 13:22:22 < Daiz> https://0-media-cdn.foolz.us/ffuuka/board/a/image/1374/62/1374625256657.png << 8bit x264
2013-07-24 13:22:26 < Daiz> https://1-media-cdn.foolz.us/ffuuka/board/a/image/1374/62/1374625490239.png << 8bit x265
2013-07-24 13:22:26 < Kovensky> yeah, was about to mention lookahead
2013-07-24 13:22:30 < Skyler_> most of the not-h264-specific asm, and even h264 specific things can be adapted
2013-07-24 13:22:33 < Skyler_> e.g. changing quant slightly
2013-07-24 13:22:38 < Kovensky> CABAC?
2013-07-24 13:22:44 < Skyler_> they've already copied SATD, for example, which is really important
2013-07-24 13:22:47 < Skyler_> Yeah, CABAC
2013-07-24 13:22:52 < Daiz> x265 seems to fare very well when it comes to lineart in anime
2013-07-24 13:22:58 < Daiz> and I quite like that
2013-07-24 13:23:00 < Skyler_> Yeah, the intra prediction in h.265 should do phenomenally
2013-07-24 13:23:04 < JEEB> yup
2013-07-24 13:23:31 < JEEB> it's partially probably because of the PSNR optimization from HM, but the spec really gives you some extra tools to make lines look better
2013-07-24 13:23:36 < Kovensky> that makes it quite the head start
2013-07-24 13:23:51 < Kovensky> compared to x264's beginnings
2013-07-24 13:24:05 < Skyler_> anime was very good with early x264 too for the same reasons
2013-07-24 13:24:27 < Skyler_> PSNR optimized intra prediction will give extremely good results on line art
2013-07-24 13:24:34 < JEEB> yup
2013-07-24 13:24:45 < Skyler_> and spatial intra pred is enormously helpful on anime, especially with small transform sizes, even if your code is written by insane monkeys
2013-07-24 13:26:24 < Skyler_> so I guess h265 will probably be used for anime first assuming people actually get 10-bit working
2013-07-24 13:26:42 < Skyler_> and then everyone will get upset that there's a new format yet again... XD
2013-07-24 13:27:08 < Daiz> well, at least main 10 profile has a chance of getting hardware acceleration
2013-07-24 13:27:23 < Daiz> though last I heard hardware developers where throwing a bitch fit about it or something
2013-07-24 13:27:35 < JEEB> oh hw people will throw a bitch fit about it
2013-07-24 13:27:37 < Daiz> I guess we'll see how it goes
2013-07-24 13:27:39 < JEEB> and have already
2013-07-24 13:27:58 < JEEB> did you see RIM's proposals on "best effort" 10bit decoding with a 8bit decoder? :P
2013-07-24 13:28:06 < Daiz> no
2013-07-24 13:28:10 < Daiz> but that sounds like quite the thing
2013-07-24 13:28:34 < JEEB> basically "let's look for some post-processing to make the decoding error less notice'able"
2013-07-24 13:28:39 < Daiz> hahahahaha
2013-07-24 13:28:40 < JEEB> "let's put this as an annex!"
2013-07-24 13:28:58 < JEEB> the e-mail stuff was rather funny too
2013-07-24 13:29:19 < Daiz> yeah, you sure can do a lot about it, especially when the image breaks down almost completely
2013-07-24 13:29:26 < Daiz> I sure would love to see them try postprocess that
2013-07-24 13:29:48 < JEEB> "because of licensing constraints we cannot fully give users full 10bit support, but we want to be able to be 'compliant' and take in users' crap even when we won't be decoding it 100% right"
2013-07-24 13:30:06 < JEEB> aka "we want more money for 10bit decoders, but we still want to pretend we're capable of 10bit decoding"
2013-07-24 13:30:17 < Daiz> >have tons of licenses to have decoding for widely-patented format
2013-07-24 13:30:20 < JEEB> *for actual
2013-07-24 13:30:25 < Daiz> >can't support a part of it because of "licensing constraints"
2013-07-24 13:30:26 < Daiz> say what now
2013-07-24 13:31:01 < JEEB> basically their own licensing, as in if the customer bought a 8bit decoder or a 10bit decoder
2013-07-24 13:31:08 < Daiz> ...
2013-07-24 13:31:16 < Daiz> how very lame
2013-07-24 13:32:10 < Daiz> anyway, Main 10 Profile in H.265 is a really commendable effort
2013-07-24 13:32:18 < Skyler_> is Main 10 basically Main with 10-bit?
2013-07-24 13:32:22 < JEEB> yup
2013-07-24 13:32:22 < Daiz> yes
2013-07-24 13:33:00 < Daiz> The Main 10 profile was added at the October 2012 HEVC meeting based on proposal JCTVC-K0109 which proposed that a 10-bit profile be added to HEVC for consumer applications.
2013-07-24 13:33:00 < Daiz> The proposal stated that this was to allow for improved video quality and to support the Rec. 2020 color space that will be used by UHDTV.[132] A variety of companies supported the proposal which included ATEME, BBC, BSkyB, CISCO, DirecTV, Ericsson, Motorola Mobility, NGCodec, NHK, RAI, ST, SVT, Thomson Video Networks, Technicolor, and ViXS Systems.
2013-07-24 13:33:43 < Skyler_> awesome!
2013-07-24 13:33:48 < Daiz> it really is
2013-07-24 13:34:02 < hakoneko> |д・)...
2013-07-24 13:34:12 < Paranoialmaniac> hakoneko: にゃーん
2013-07-24 13:34:28 < hakoneko> |д・)mew...
2013-07-24 13:35:26 < Paranoialmaniac> silverfilain: you should also translate x265 commit log into japanese :P
2013-07-24 13:35:40 < Daiz> that quote is also a very nice thing for rubbing against the faces of people whining about how "10-bit is useless" (☞ﾟ∀ﾟ)☞
2013-07-24 13:35:43 < Skyler_> the x264 commit log can use an update too
2013-07-24 13:36:24 < silverfilain> ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼
2013-07-24 13:36:44 < JEEB> I'm not sure if the 10bit encoding is more useful in HEVC as much as it is with AVC
2013-07-24 13:37:06 < silverfilain> hakoneko is alias of silverfilain
2013-07-24 13:37:08 < Skyler_> if I had to guess, I'd say less useful, because HEVC has less rounding error than AVC
2013-07-24 13:37:11 < silverfilain> yoroshiku
2013-07-24 13:37:11 < JEEB> yeah
2013-07-24 13:37:22 < Daiz> quite hard to say how it's going to be in practice though
2013-07-24 13:37:23 < JEEB> the JCT-VC papers show ~5% gain
2013-07-24 13:37:27 < JEEB> with HM testing
2013-07-24 13:37:32 < Daiz> since x265 right now is a bandfest with 8bit
2013-07-24 13:37:34 < Daiz> and 10bit doesn't work
2013-07-24 13:38:04 < JEEB> well, you've got PSNR optimization, static GOP types and the other stuff there
2013-07-24 13:40:29 < JEEB> I kind of expect that kind of stuff to become better with time, although there will be some benefit from 10bit most probably
2013-07-24 13:40:41 < Skyler_> I doubt 8-bit will ever have banding solved really
2013-07-24 13:40:51 < Skyler_> HEVC doesn't really give us any better solutions, as far as I know?
2013-07-24 13:41:04 < Skyler_> I mean, it's probably not possible without postprocessing or IBDI
2013-07-24 13:41:24 < JEEB> trure
2013-07-24 13:41:27 < JEEB> *true
2013-07-24 13:46:04 < Daiz> btw Skyler_, do you still blog anywhere
2013-07-24 13:46:15 < Daiz> since http://x264dev.multimedia.cx/ is pretty much dead
2013-07-24 13:48:40 < Skyler_> nope, not really
2013-07-24 13:49:02 < Skyler_> well actually okay, I have a tumblr, but it's a Secret.
2013-07-24 13:54:33 < Skyler_> if anyone identified mine I would be preeettty surprised~
2013-07-24 13:56:12 < Daiz> so you're secretly blogging about touhou futa or something!
2013-07-24 13:56:21 < Skyler_> neither, really :p
2013-07-24 13:59:10 < Daiz> you're right, that'd probably be too obvious
2013-07-24 13:59:12 < Daiz> ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼
2013-07-24 14:00:05 < Skyler_> I thought that would be more your think
2013-07-24 14:00:08 < Skyler_> *your thing
2013-07-24 14:00:18 < Daiz> nah
2013-07-24 14:00:23 < Daiz> also I don't use tumblr at all
2013-07-24 14:00:31 < Daiz> and I honestly hate its model as a non-user
2013-07-24 14:00:42 < Daiz> trying to follow "discussion" or comments on it is an utterly confusing mess
2013-07-24 14:01:13 < Skyler_> oh, yeah, it's not very good for discussion in the same way, like, a forum is
2013-07-24 14:01:26 < Daiz> notes are covered in "likes" and "reblogs" and you can't filter it down to anything that replies or adds to it, and most of the time it doesn't seem to list half of the entries adding to it in any way
2013-07-24 14:02:06 < Skyler_> it's more a system for Posting Cool Stuff and Sharing That Stuff With Friends
2013-07-24 14:02:08 < Daiz> even twitter makes it easier to follow conversations
2013-07-24 14:02:13 < Daiz> yeah, I know
2013-07-24 14:02:13 < Skyler_> than, like, conversing with people
2013-07-24 14:02:17 < Daiz> it's just annoying
2013-07-24 14:04:22 < Daiz> frankly I don't like most of the big user sites when it comes to following discussion
2013-07-24 14:04:25 < Daiz> or discussing
2013-07-24 14:04:31 < Daiz> twitter is twitter
2013-07-24 14:04:35 < Daiz> tumblr makes discussion a pain
2013-07-24 14:05:02 < Daiz> trying to follow discussion on reddit after the first read is an exercise in painful at best due to the non-linear nature of discussion
2013-07-24 14:05:20 < Skyler_> I thought it was more painful due to the atrocious neckbeardism and sexism :/
2013-07-24 14:05:27 < Skyler_> and creeps
2013-07-24 14:05:30 < nevcairiel> i never understood how people can spend hours on reddit, i usually get a headache after trying to follow the first discussion there
2013-07-24 14:05:46 < Daiz> hacker news I can tolerate thanks to an extension that highlights new replies and you generally always see all replies on a single page unless there's tons of comments
2013-07-24 14:06:50 < Daiz> 4chan with 4chan X is what I find the most comfortable - you get a flat, linear stream of comments, automatically fetched new replies, a powerful quoting system and inline on-demand threading if you want
2013-07-24 14:06:54 < Daiz> it's like the best of all worlds
2013-07-24 14:07:15 < nevcairiel> except its full of creeps and trolls :D
2013-07-24 14:07:26 < Daiz> and participating in the discussion is very easy
2013-07-24 14:07:33 < Skyler_> daiz is okay with that, he's one of them
2013-07-24 14:07:38 < Skyler_> (the trolls, I mean.  not sure about the former)
2013-07-24 14:07:50 < Daiz> and I also do like anonymous discussion in general
2013-07-24 14:08:18 < Daiz> for subjects that's purely about subjective stuff and so, exact identity doesn't really matter at all
2013-07-24 14:08:26 < Daiz> and posts are judged solely by the content
2013-07-24 14:09:20 < Daiz> I do also use a name and tripcode for posting about video encoding and a couple other things I have expertise in, but rest of the time I'm anonymous
2013-07-24 14:09:45 < Daiz> and that works out quite well
2013-07-24 14:19:48 < Daiz> also, you can have a lot of nice discussion on 4chan, especially on the smaller boards
2013-07-24 14:20:20 < Daiz> on larger boards like /a/ and /v/ you have to have a pretty good mental filter (or actual filters), and /b/ is obviously just a cesspoll
2013-07-24 16:09:41 < muggs> g'morning.  hopefully my internet connection is better today
2013-07-24 16:12:15 < JEEBsv> g'morning
2013-07-24 16:12:25 < koda> o/
2013-07-24 16:12:34 < JEEBsv> Shiz seemed to be doing some stuff to fix compilation on OS X
2013-07-24 16:16:53 < muggs> cool
2013-07-24 16:17:37 < muggs> I neglected to mention we have a mailing list:  x265-devel@videolan.org
2013-07-24 16:17:48 < muggs> I'll add that to the wiki
2013-07-24 16:17:56 < JEEBsv> is that still limited to registered members to read it?
2013-07-24 16:17:58 < JEEBsv> (archives)
2013-07-24 16:18:49 < JEEBsv> also I noticed that you were using some mingw aligned malloc and stuff, I'll probably poke that as well since every sane mingw environment would have the windows XP SP2+ aligned malloc etc. stuff
2013-07-24 16:23:57 < muggs> I don't know if J-B has made it open yet
2013-07-24 16:24:10 < ps-auxw> I remember browsing it a few days ago.
2013-07-24 16:25:09 < JEEBsv> yes, it was public before it was made private :)
2013-07-24 16:27:25 < j-b> Until I got some explanations from Tom, the ml is closed.
2013-07-24 16:28:01 < j-b> Because I'm nice does not mean I am stupid.
2013-07-24 16:28:20 < j-b> American have still a lot of difficulties to understand that.
2013-07-24 16:28:46 < nevcairiel> its hardly private if all thats required is a anonymous sign up, but shrug =)
2013-07-24 16:35:25 < muggs> http://mailman.videolan.org/listinfo/x265-devel && http://patches.videolan.org/project/x265-devel/list/
2013-07-24 16:35:48 < muggs> apparently my crap net connection will persist for a few more days
2013-07-24 16:38:39 < kierank> 17:27:12 <j-b> Until I got some explanations from Tom, the ml is closed.
2013-07-24 16:38:39 < kierank> 17:27:48 <j-b> Because I'm nice does not mean I am stupid.
2013-07-24 16:38:39 < kierank> 17:28:06 <j-b> American have still a lot of difficulties to understand that.
2013-07-24 16:49:45 < muggs> peachy
2013-07-24 17:07:57 < muggs> we met with J-B some weeks ago and planned hosting our repo and web page on video lan's servers
2013-07-24 17:08:34 < muggs> and were working toward that goal until about a week and a half ago when we got knee-capped.
2013-07-24 17:09:15 < kierank> why
2013-07-24 17:09:55 < muggs> the people writing the checks decided it was better to do a GPL release but not under the video-lan banner
2013-07-24 17:10:06 < muggs> at least initially
2013-07-24 17:10:17 < Daiz> ah, corporate politics
2013-07-24 17:10:29 < muggs> we've been fighting against that, we really do want to use VL
2013-07-24 17:10:55 < muggs> but we went quiet for a while trying to figure out what to do.  J-B saw A+B and assumed we're pricks
2013-07-24 17:12:35 < muggs> the whole situation sucks, but there's not much I can do about it
2013-07-24 17:13:56 < kierank> what is the objection to videolan.org
2013-07-24 17:14:37 < nevcairiel> french leadership, obviously
2013-07-24 17:15:06 < Daiz> maybe they're not fans of VLC and prefer MPC-HC ;)
2013-07-24 17:15:08 < muggs> The details don't get down to me, but I've heard concerns about legal risk.
2013-07-24 17:15:28 < Shiz> who's muggs
2013-07-24 17:15:50 < muggs> I'm Steve Borho from MulticoreWare
2013-07-24 17:15:58 < Shiz> ic
2013-07-24 17:16:08 < Shiz> I got x265 to compile, but not link under OSX 10.8
2013-07-24 17:16:21 < Shiz> with some minor edits
2013-07-24 17:16:23 < kierank> 18:14:54 <muggs> The details don't get down to me, but I've heard concerns about legal risk. --> lol
2013-07-24 17:16:26 < kierank> that's beyond a joke
2013-07-24 17:16:31 < muggs> what symbols are missing?
2013-07-24 17:16:42 < Shiz> all intrinsics
2013-07-24 17:16:47 < Shiz> so it's probably a linker input error
2013-07-24 17:17:20 < Shiz> http://bpaste.net/show/116931/
2013-07-24 17:18:25 < Shiz> what's funny is that all of those symbols seem to be present
2013-07-24 17:18:28 < Shiz> so I'm not sure
2013-07-24 17:18:53 < muggs> this is still gcc, right?
2013-07-24 17:19:11 < Shiz> clang
2013-07-24 17:19:17 < Shiz> standard cmake cxx
2013-07-24 17:19:46 < Shiz> i only did cd build/linux && sh *.bash && make
2013-07-24 17:20:13 < muggs> it might be the order the common libs are linked together
2013-07-24 17:20:35 < Shiz> the error occurs in the final link of the x86/ to my knowledge
2013-07-24 17:20:37 < Shiz> sec
2013-07-24 17:25:59 < muggs> if the compiler isn't setting __GNUC__ or _MSC_VER, vec-primitives.cpp will not call any setup functions
2013-07-24 17:27:58 < muggs> source/common/vec/CMakeLists.txt probably won't try to build much, either
2013-07-24 17:28:35 < muggs> no idea why the assembly symbols are missing, though
2013-07-24 17:36:25 < Shiz> but I checked out the .a files
2013-07-24 17:36:28 < Shiz> they contain the symbols
2013-07-24 17:36:34 < Shiz> that are missing
2013-07-24 17:36:38 < Shiz> pretty sure clang defines GNUC
2013-07-24 17:37:26 < muggs> it built all the common/vec/*.cpp files?
2013-07-24 17:38:03 < muggs> all but the avx2 ones, hopefully
2013-07-24 17:40:43 < muggs> kierank: unfortunately, it's not my opinion that counts
2013-07-24 18:46:39 < easyfab> for information : I have some crash  with non-mod32 videos (for example 720*400 resolution) and --cpuid other than --cpuid 1,  can someone confirm ? or is it only my build ?
2013-07-24 18:49:37 < Shiz>   if given arguments:
2013-07-24 18:49:39 < Shiz>     "not" "Darwin" "matches" "Darwin"
2013-07-24 18:49:41 < Shiz>   Unknown arguments specified
2013-07-24 18:49:44 < Shiz> I wonder why this doesn't work
2013-07-24 18:50:53 < Shiz> fixed
2013-07-24 18:51:25 < muggs_> easyfab: sounds like a block copy bug, any chance you can get a stack trace?
2013-07-24 19:01:31 < Skyler_> kierank: videolan is known for giving big "screw you"s to MPEG-LA and such people
2013-07-24 19:01:42 < Skyler_> and they are quite awesome for it, and thanks to french law, they can
2013-07-24 19:01:51 < Skyler_> but it also makes many enemies in the corporate world
2013-07-24 19:02:05 < Skyler_> they also do things like include decss in VLC and so on
2013-07-24 19:02:15 < kierank> and hosting source code at x265 affects what
2013-07-24 19:02:26 < kierank> x264 also has enemies
2013-07-24 19:02:30 < kierank> it's a stupid argument
2013-07-24 19:02:43 < Skyler_> well, I think it's dumb too
2013-07-24 19:02:49 < kierank> i am called an IP thief quite regularly by said same individuals
2013-07-24 19:02:50 < Skyler_> but when the people asking for it are the ones paying for the project
2013-07-24 19:03:13 < Skyler_> personally I think it's stupid but if they want to do it that way they can, I suppose
2013-07-24 19:03:33 < Skyler_> (I already complained quite a bit)
2013-07-24 19:05:12 < Shiz> muggs_: Cmake seems to ignore any kind of way I throw a custom compiler at it
2013-07-24 19:05:20 < easyfab> muggs_: http://www.images-host.fr/view.php?img=2107240401.jpg   don't know if it help you
2013-07-24 19:05:36 < Shiz> cmake -D:CMAKE_C_COMPILER=/usr/bin/gcc -D:CMAKE_CXX_COMPILER=/usr/bin/g++ -G 'Unix Makefiles' ../../source
2013-07-24 19:05:45 < Shiz> CC=/usr/bin/gcc CXX=/usr/bin/g++ VERBOSE=1 make
2013-07-24 19:05:55 < Shiz> still uses /usr/bin/cc and /usr/bin/c++
2013-07-24 19:06:47 < muggs_> I've complained on my side, fwiw.  I think in the end we will join with VL, but it might take a while
2013-07-24 19:07:13 < muggs_> easyfab: if you build RelWithDebInfo, you'll get a proper stack trace
2013-07-24 19:07:32 < easyfab> Ok will try
2013-07-24 19:08:07 < muggs_> Shiz: try make -n
2013-07-24 19:08:33 < Shiz> doesn't really help since all cmake-generated makefiles do is invoke cmake
2013-07-24 19:08:51 < muggs_> there was another trick to make cmake dump info as it goes, let me see if I can find it
2013-07-24 19:08:57 < Shiz> VERBOSE=1 make
2013-07-24 19:08:59 < Shiz> it's what I did
2013-07-24 19:09:04 < Shiz> brb
2013-07-24 19:10:10 < muggs_> they suggest: make VERBOSE=1   - perhaps that is passed to sub-makes better
2013-07-24 19:12:45 < muggs_> to change compilers you have to set CC and CXX prior to running cmake
2013-07-24 19:23:27 < Shiz> it's the same thing
2013-07-24 19:23:33 < Shiz> X=Y is just environment varialbes in the shell
2013-07-24 19:23:35 < Shiz> order is irrelevant
2013-07-24 19:24:10 < muggs_> I think make treats cmdline args differently than env vars
2013-07-24 19:24:19 < Shiz> it's not a cmdline arg.
2013-07-24 19:24:28 < Shiz> X=Y anywhere in the cmdline will be an env var
2013-07-24 19:33:08 < muggs_> http://stackoverflow.com/questions/2826029/passing-additional-variables-from-command-line-to-make
2013-07-24 19:34:07 < nevcairiel> If you put it after the make command, its not going into an env var
2013-07-24 19:34:21 < muggs_> http://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands
2013-07-24 19:34:39 < muggs_> that was the other trick:   cmake -DCMAKE_VERBOSE_MAKEFILE=ON . && make
2013-07-24 19:41:03 < easyfab> muggs_: Is this better http://www.images-host.fr/view.php?img=2107244001.jpg ?
2013-07-24 19:41:22 < muggs_> perfect
2013-07-24 19:42:23 < muggs_> x264's AVX SSD function needs 32bit alignment.
2013-07-24 19:42:57 < muggs_> hrm.  the plane strides probably need to be a factor of 32
2013-07-24 19:47:00 < Shiz> muggs_: CMAKE_VERBOSE_MAKEFILE is deprecated and replaced by VERBOSE=1
2013-07-24 19:47:08 < Shiz> www.cmake.org/pipermail/cmake/2009-August/031296.html
2013-07-24 19:47:23 < muggs_> that's that then
2013-07-24 19:49:16 < Shiz> yeah but it doesn't tell me much, only the command line
2013-07-24 19:49:22 < Shiz> also I found out clang does define __GNUC__
2013-07-24 19:52:26 < Shiz> http://bpaste.net/show/117060/
2013-07-24 19:53:57 < Shiz> anyway I can contribute the erst of my patches if you want already
2013-07-24 19:55:43 < muggs_> yeah, go right ahead
2013-07-24 19:58:04 < muggs_> easyfab: working on a patch, but I need to test it.
2013-07-24 20:04:02 < Shiz> https://bitbucket.org/shiz/x265
2013-07-24 20:04:08 < Shiz> could anyone verify this still builds on Linux?
2013-07-24 20:04:11 < Shiz> I don't have a box to test it atm
2013-07-24 20:04:37 < muggs_> I can check, it'll take a few minutes
2013-07-24 20:04:49 < Shiz> thanks
2013-07-24 20:16:11 < muggs_> doing a baseline linux build now, then will pull your changes
2013-07-24 20:21:57 < Shiz> aight
2013-07-24 20:51:23 < muggs_> Shiz: builds fine on Linux
2013-07-24 20:51:30 < Shiz> nice
2013-07-24 20:52:26 < Shiz> https://bitbucket.org/multicoreware/x265/pull-request/1/darwin-compatibility-fixes/diff
2013-07-24 20:55:14 < Daiz> JEEB
2013-07-24 20:55:20 < Daiz> any ideas on demuxing HEVC... from flv
2013-07-24 20:55:35 < JEEB> completely made up by those blokes at xhevc.com :P
2013-07-24 20:55:38 < Shiz> wtf
2013-07-24 20:55:43 < Daiz> figures
2013-07-24 20:55:49 < JEEB> there's currently no official way of muxing HEVC into anything
2013-07-24 20:55:56 < JEEB> there's my hack for matroska
2013-07-24 20:55:56 < Daiz> yeah, that's what I recall
2013-07-24 20:56:03 < JEEB> there's 14496-15AMD2, no final draft
2013-07-24 20:56:04 < Daiz> so seeing .flv made me go "wtf"
2013-07-24 20:56:08 < JEEB> there's the MPEG-2 Systems thing
2013-07-24 20:56:15 < Daiz> and then seeing that it's actually HEVC inside it even more wtf
2013-07-24 20:56:16 < JEEB> no final draft either
2013-07-24 20:56:49 < Daiz> how the fuck would I even be able to preview this shit with anything
2013-07-24 20:57:02 < Daiz> how nice of them to provide "samples" in completely unusable form
2013-07-24 20:57:47 < Daiz> oh they have some dshow filters on their page
2013-07-24 20:57:58 < JEEB> basically only their hacked Gabest's FLV splitter and hacked monogram muxer work with them
2013-07-24 20:57:59 < JEEB> la
2013-07-24 20:58:11 < Daiz> still, why the fuck couldn't they just provide raw hevc bitstream
2013-07-24 20:58:18 < Daiz> nobody fucking needs audio for video evaluation
2013-07-24 21:13:20 < muggs_> Skyler_: does x264 require a contributor agreement for all patches, or just the substantial contributions?
2013-07-24 21:14:01 < Skyler_> all patches that aren't trivial
2013-07-24 21:14:10 < Skyler_> trivial being build system (it doesn't matter if the build system remains GPL)
2013-07-24 21:14:15 < Skyler_> one-line bugfixes, etc
2013-07-24 21:15:04 < Skyler_> how you judge this probably depends on how your lawyer(s) feel about this :P
2013-07-24 21:15:14 < Skyler_> I know GNU has a policy for example related to this
2013-07-24 21:15:17 < Skyler_> since they use copyright assignment
2013-07-24 21:16:18 < muggs_> googling.. I see. http://www.gnu.org/licenses/why-assign.html
2013-07-24 21:19:10 < Skyler_> I think a good guideline is that if the patch is anywhere close to substantial enough to be "create work", the person should be asked to sign a CLA
2013-07-24 21:19:14 < Skyler_> *creative work
2013-07-24 21:19:28 < Skyler_> your boss will probably want you erring on the side of caution
2013-07-24 21:19:40 < muggs_> that is my guess as well
2013-07-24 21:19:53 < muggs_> everyone is gun shy at the moment
2013-07-24 21:22:13 < Shiz> man
2013-07-24 21:22:16 < Shiz> things used to be simple
2013-07-24 21:22:27 < Shiz> I could just say 'here's my shit, do with it whatever you want' and it would be fine
2013-07-24 21:23:22 < Skyler_> that's probably okay too
2013-07-24 21:23:45 < Skyler_> it might make the lawyers upset but I suppose you could BSD-license your changes or something <.<
2013-07-24 21:23:54 < Skyler_> but yeah, license stuff is annoying
2013-07-24 21:24:05 < Shiz> wtfpl\/w 13
2013-07-24 21:24:08 < Shiz> whoops.
2013-07-24 21:24:12 < Shiz> wtfpl
2013-07-24 21:24:39 < muggs_> I think what makes our lawyer(s) testy is that we would be a much more inviting lawsuit target than video lan or the x264 consortium
2013-07-24 21:24:52 < muggs_> so we have to be even more careful
2013-07-24 21:25:00 < Skyler_> that's probably true, yeah
2013-07-24 21:25:13 < kierank> lawsuit about what
2013-07-24 21:25:36 < Shiz> adding osx compatibility is licensed by the MPEG-LA
2013-07-24 21:25:39 < Shiz> pls2payroyalties
2013-07-24 21:25:43 < muggs_> heh
2013-07-24 21:30:12 < kierank> usual lawyerbs
2013-07-24 21:30:31 < kierank> i have to wave them my letter from mpegla saying source code distribution doesn't need a licence all the time
2013-07-24 21:30:48 < JEEB> yeah, I bet many people don't believe that
2013-07-24 21:31:04 < JEEB> great that you got an actual letter on that :D
2013-07-24 21:31:20 < muggs_> Shiz: I think AVX needs 32byte alignment, not sure 16bytes is enough.
2013-07-24 21:31:59 < kierank> almost everyone thinks if you buy a proprietary encoder you get a transmission licence
2013-07-24 21:32:30 < Shiz> muggs_: "The alignment requirement of SIMD memory operands is relaxed."
2013-07-24 21:32:47 < Shiz> according to wikipedia at least
2013-07-24 21:32:52 < Skyler_> AVX does not require memory operand alignment
2013-07-24 21:32:56 < Skyler_> except for movdqa/friends
2013-07-24 21:33:05 < Shiz> I'm double-checking
2013-07-24 21:33:32 < muggs_> don't your AVX asm functions use aligned loads?
2013-07-24 21:33:56 < Shiz> I can always use posix_memalign() if it's an issue
2013-07-24 21:34:18 < muggs_> that's what we use for Linux, I think
2013-07-24 21:34:25 < Shiz> no, you use memalign()
2013-07-24 21:34:32 < Shiz> which is Linux's nonstandard variant
2013-07-24 21:34:34 < Shiz> :P
2013-07-24 21:35:12 < muggs_> oh yeah, we only use posix_memalign in the testbench
2013-07-24 21:35:23 < Shiz> well, you should use posix_memalign
2013-07-24 21:35:28 < Shiz> memalign() itself is obsolete
2013-07-24 21:35:48 < muggs_> agreed
2013-07-24 21:36:01 < Skyler_> copy x264_malloc if you need something (?)
2013-07-24 21:36:10 < Shiz> that means you also can remove the malloc.h header
2013-07-24 21:36:13 < Shiz> :P
2013-07-24 21:36:34 < muggs_> I've been meaning to clean that up; but it's never made it to the top of my todo list
2013-07-24 21:36:47 < JEEB> ugh, x264_malloc -- does that still not use _aligned_malloc() on windows?
2013-07-24 21:36:52 < Shiz> although
2013-07-24 21:36:58 < Shiz> x264_malloc() uses OSX's raw malloc
2013-07-24 21:37:10 < JEEB> yes, it's a hack on top of normal malloc
2013-07-24 21:37:21 < Shiz> does x264 support avx
2013-07-24 21:37:23 < Shiz> i thought it did
2013-07-24 21:37:24 < JEEB> yes
2013-07-24 21:37:29 < Shiz> then it should be no issue as-is
2013-07-24 21:39:19 < muggs_> x264_malloc has some shiny new HUGE_PAGE_SIZE stuff in it
2013-07-24 21:39:50 < muggs_> and calls memalign on linux, heh
2013-07-24 21:40:17 < JEEB> and I think on windows it still hacks up its own aligned malloc, right?
2013-07-24 21:40:23 < muggs_> yes
2013-07-24 21:40:28 < JEEB> instead of using XP SP2+ _aligned_malloc :<
2013-07-24 21:40:30 < muggs_> over-allocates and moves pointer
2013-07-24 21:40:55 < JEEB> granted, most probably when that code was written windows 2000 support was still a thing
2013-07-24 21:41:01 < Shiz> JEEB: gotta support that pre-SP2 xp
2013-07-24 21:41:15 < Shiz> (still could've made it a ./configure-time thing)
2013-07-24 21:41:36 < JEEB> and then xy-VSFilter copied that stuff :<
2013-07-24 21:42:04 < Shiz> you know what to do
2013-07-24 21:42:08 < Shiz> libalignedmalloc
2013-07-24 21:42:56 < Skyler_> what's _aligned_malloc?
2013-07-24 21:43:10 < JEEB> the windows native aligned malloc
2013-07-24 21:43:17 < JEEB> has been available since xp sp2
2013-07-24 21:43:33 < Skyler_> does it work like memalign?
2013-07-24 21:43:37 < Shiz> pretty much
2013-07-24 21:43:44 < JEEB> http://msdn.microsoft.com/en-us/library/8z34s9c6%28v=vs.80%29.aspx
2013-07-24 21:43:57 < Shiz> manually forcing the compiler to GCC brought me some
2013-07-24 21:43:59 < Shiz> interesting stuff
2013-07-24 21:44:01 < Shiz> /var/folders/p6/w5430zrn575g3w2g6q0gqfx00000gn/T//ccY4F4qK.s:85:no such instruction: `xgetbv'
2013-07-24 21:44:01 < JEEB> oh wait
2013-07-24 21:44:05 < JEEB> it's been there since win95 o_O
2013-07-24 21:44:38 < JEEB> although that might have been in visual studio clibs, I know the msvcrt got it at least with XP SP2
2013-07-24 21:44:40 < JEEB> if not before
2013-07-24 21:46:24 < Shiz> oaky I get the same link error under gcc
2013-07-24 21:46:27 < Shiz> so it's not clang's fault
2013-07-24 21:47:27 < muggs_> I can understand the xgetbv problem.. still don't understand the other unresolveds
2013-07-24 21:47:39 < Shiz> yeah the xgetbv was a result of an outdated gcc
2013-07-24 21:47:47 < Shiz> after manually compiling that with clang it proceeded
2013-07-24 21:48:22 < JEEB> and yeah, this looks kind of familiar https://github.com/jeeb/xy-vsfilter/blob/blitzkrieg/src/subtitles/xy_malloc.cpp
2013-07-24 21:48:23 < JEEB> lal
2013-07-24 21:48:39 < Shiz> intersting directory structure
2013-07-24 21:48:40 < nevcairiel> they really invented their own? o.O
2013-07-24 21:48:54 < JEEB> nevcairiel, more like copied from x264
2013-07-24 21:49:04 < JEEB> "//gathered from x264"
2013-07-24 21:49:07 < Shiz> is that HAVE_MEMALIGN_HACK
2013-07-24 21:49:10 < nevcairiel> but renamed it
2013-07-24 21:49:13 < JEEB> yeah
2013-07-24 21:49:34 < JEEB> Shiz, in libav terms, yes
2013-07-24 21:49:36 < nevcairiel> still rather stupid considering there is a native one
2013-07-24 21:49:41 < JEEB> yes
2013-07-24 21:49:52 < JEEB> x264 gets a free pass because it was coded when win2000 was still "OK to use"
2013-07-24 21:50:03 < JEEB> xy-vsfilter's case just makes me go wee-wee
2013-07-24 21:53:32 < nevcairiel> _aligned_malloc should be part of the CRT, not sure the OS version matters
2013-07-24 21:53:56 < Shiz> 7hmm
2013-07-24 21:54:12 < Shiz> can anyone do VERBOSE=1 make
2013-07-24 21:54:20 < Shiz> and tell me what the command of the final link is for them
2013-07-24 21:57:05 < koda> Shiz: lol @ "adding osx compatibility is licensed by the MPEG-LA"
2013-07-24 21:57:19 < koda> so there is going to be a similar CLA for x265 too?
2013-07-24 21:57:31 < muggs_> to be clear about 10 bits, we keep a HIGH_BIT_DEPTH build flag for 16bpp, but it doesn't get tested with 10bit inputs and is almost certainly seriously busted
2013-07-24 21:57:41 < nevcairiel> of course interacting with the apple ecosystem requires special licensing :p
2013-07-24 21:57:50 < Daiz> muggs_: that certainly seemed to be the case
2013-07-24 21:57:58 < Shiz> I should also force profiling to off
2013-07-24 21:58:04 < Daiz> or well, I tried encoding in 10bit
2013-07-24 21:58:06 < muggs_> yes, there will be a CLA almost identical to x264's
2013-07-24 21:58:07 < Shiz> at least, until OSX's librt thing is fixed
2013-07-24 21:58:07 < Daiz> with --depth 10
2013-07-24 21:58:26 < Daiz> trying to feed it 16-bit input just made it crash
2013-07-24 21:58:32 < Daiz> so I ended up just feeding 8-bit input
2013-07-24 21:58:35 < Daiz> then it encoded
2013-07-24 21:58:36 < Shiz> I think OSX embeds some part of librt, but not all
2013-07-24 21:58:38 < Daiz> but the encode was all green
2013-07-24 21:58:40 < muggs_> using --cpuid 1 might help
2013-07-24 21:59:12 < muggs_> it'll probably take a week's worth of debugging to figure all the places we broke 10bit.
2013-07-24 21:59:13 < j-b> I don't assume, I see facts.
2013-07-24 22:00:58 < muggs_> Hi j-b, Tom would like setup a call with the three of us tomorrow if possible
2013-07-24 22:02:04 < muggs_> Shiz: msys make VERBOSE=1  http://privatepaste.com/aec09aef89
2013-07-24 22:02:32 < Shiz> ahah.
2013-07-24 22:02:41 < Daiz> muggs_: well, I wasn't particularly surprised that 10-bit encoding didn't really work at this point
2013-07-24 22:02:47 < Daiz> but I'll be sure to test it out when it does
2013-07-24 22:03:04 < muggs_> I'll definitely announce that here
2013-07-24 22:03:28 < Daiz> maybe the libavcodec HEVC decoder will be able to handle it at that point too!
2013-07-24 22:03:47 < Daiz> so I won't have to use HM for anything
2013-07-24 22:04:07 < nevcairiel> it should be merged first before people start implementing new stuff in it :D
2013-07-24 22:04:21 < Shiz> muggs_: could you upload your common/x86/libPrimitivesASM.a?
2013-07-24 22:04:21 < Daiz> that's totally fine too
2013-07-24 22:04:25 < Shiz> i want to do some comparisons
2013-07-24 22:05:49 < muggs_> https://bitbucket.org/sborho/files/downloads#download-212826
2013-07-24 22:07:15 < muggs_> I can generate one from Linux if it would be more useful
2013-07-24 22:07:50 < Shiz> thanks
2013-07-24 22:07:53 < Shiz> nah it's good
2013-07-24 22:08:48 < Shiz> hmm on the other hand
2013-07-24 22:08:53 < Shiz> ar -x doesn't seem to be able to unpack it properly
2013-07-24 22:11:02 < Shiz> well I can see one issue
2013-07-24 22:11:07 < Shiz> everything is a mach-o executable except the asm parts
2013-07-24 22:11:09 < Shiz> they are elf64
2013-07-24 22:11:24 < Shiz> s/executable/object/
2013-07-24 22:12:31 < muggs_> oh, is that a yasm flag issue?
2013-07-24 22:12:40 < muggs_> I've uploaded a linux version
2013-07-24 22:13:21 < Shiz> I'm checking it out right now
2013-07-24 22:13:30 < muggs_> the msys lib was win32
2013-07-24 22:13:30 < Shiz> and thanks
2013-07-24 22:16:04 < Shiz> error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.
2013-07-24 22:16:06 < Shiz> ho mamma
2013-07-24 22:16:08 < Shiz> this will be fun
2013-07-24 22:18:44 < Skyler_> doesn't x86inc avoid that by using "default rel" or something?
2013-07-24 22:20:45 < Shiz> x265 has it as well
2013-07-24 22:22:22 < Shiz> haha!
2013-07-24 22:22:28 < Shiz> adding -DPIC to the cmdline fixed it
2013-07-24 22:23:00 < muggs_> adding -DPIC to yasm's command line?
2013-07-24 22:23:08 < Shiz> yes
2013-07-24 22:23:17 < Shiz> because it triggers x86inc's default rel
2013-07-24 22:23:39 < Shiz> sadly all the linker errors are still there
2013-07-24 22:23:45 < muggs_> doh
2013-07-24 22:24:20 < Shiz> because the symbols aren't prefixed with a _
2013-07-24 22:24:34 < muggs_> there
2013-07-24 22:24:45 < muggs_> there's a -DPREFIX for that
2013-07-24 22:25:03 < Shiz> or --prefix to yasm
2013-07-24 22:25:26 < muggs_> see x265\source\cmake\CMakeASM_YASMInformation.cmake
2013-07-24 22:26:13 < Shiz> got a hacked up version of that already
2013-07-24 22:26:16 < Shiz> compiling...
2013-07-24 22:26:22 < muggs_> do I need to add a section for darwin?
2013-07-24 22:26:40 < Shiz> I'm adding one in the unix section
2013-07-24 22:26:44 < Shiz> since darwin is still a unix
2013-07-24 22:26:47  * muggs_ crosses fingers
2013-07-24 22:27:00 < Shiz> woo
2013-07-24 22:27:04 < Shiz> only 6 linker errors remain
2013-07-24 22:27:23 < Shiz> and it's all in the primitive setup code
2013-07-24 22:27:27 < muggs_> progress
2013-07-24 22:28:06 < muggs_> vec-primitives.cpp
2013-07-24 22:28:09 < Shiz> yep
2013-07-24 22:28:31 < Shiz> clang was supposed to define __GNUC__
2013-07-24 22:28:33 < Shiz> I thought it did
2013-07-24 22:29:03 < Shiz> oh
2013-07-24 22:29:07 < Shiz> but you do if(GCC)
2013-07-24 22:29:57 < Shiz> in cmakelists
2013-07-24 22:30:37 < muggs_> in cmake, you need to check source/CMakeLists.txt line 34
2013-07-24 22:31:33 < Shiz> I found source/common/vec/CmakeLists.txt to be more useful
2013-07-24 22:31:51 < muggs_> GCC is defined in the earlier file
2013-07-24 22:32:23 < Shiz> yeah
2013-07-24 22:32:32 < muggs_> https://bitbucket.org/sinbad/ogre/commits/ed8006053dfe/#chg-CMake/ConfigureBuild.cmake
2013-07-24 22:32:53 < Shiz> I had the same file in front of me
2013-07-24 22:32:55 < Shiz> :P
2013-07-24 22:33:03 < muggs_> lol
2013-07-24 22:33:11 < muggs_> same googles
2013-07-24 22:38:32 < Shiz> it's not that easy though
2013-07-24 22:38:39 < Shiz> clang is just /usr/bin/c++ on osx
2013-07-24 22:39:48 < Shiz> luckily there is COMPILER_ID
2013-07-24 22:57:19 < muggs_> dinner time, need to be afk for a while
2013-07-24 23:05:49 < Shiz> hmm
2013-07-24 23:05:57 < Shiz> I managed to compile around half of the vector stuff now
2013-07-24 23:05:58 < Shiz> :P
2013-07-24 23:06:05 < Shiz> clang doesn't take kindly to a lot of stuff gcc and msvc allow
2013-07-24 23:06:28 < Shiz> error: signed shift result (0x121212120) requires 34 bits to represent, but 'int' only has 32 bits [-Werror,-Wshift-overflow]
2013-07-24 23:06:30 < Shiz> for instance
2013-07-24 23:22:27 < Shiz> ❯ ./x265                                                                                                                                                                                                                                                          ❯❯❯
2013-07-24 23:22:28 < Shiz> x265 [info]: HEVC encoder version 0.3+26-1c0ec901b7ed
2013-07-24 23:22:30 < Shiz> x265 [info]: build info [Mac OS X][GCC 4.2.1][64 bit] 8bpp
2013-07-24 23:22:32 < Shiz> m_bison_yes.mkv
2013-07-24 23:39:51 < Shiz> I'm encoding 1080p at 0.5~1.0fps right now
2013-07-24 23:40:07 < Shiz> single thread, sse4.2 intrinsics
2013-07-24 23:40:14 < Shiz> and avx
2013-07-24 23:40:50 < muggs_> good stuff
2013-07-24 23:41:22 < Shiz> oh wait, actually 4 threads
2013-07-24 23:41:23 < Shiz> but still
2013-07-24 23:41:40 < muggs_> --wpp?
2013-07-24 23:42:21 < Shiz> no, just 4 cpu cores
2013-07-24 23:42:26 < Shiz> and --thread says it *does* autodetect
2013-07-24 23:42:56 < muggs_> yeah, but it won't use the thread pool if you don't use --wpp or --gops N
2013-07-24 23:43:03 < Shiz> boop
2013-07-24 23:43:07 < Shiz> then it's just single-thread
2013-07-24 23:43:28 < muggs_> it should say in the log
2013-07-24 23:43:55 < Shiz> x265 [info]: Parallelism disabled, single thread mode
2013-07-24 23:43:56 < Shiz> aye
2013-07-24 23:45:43 < Shiz> [1]    51213 segmentation fault  ./x265 --threads 8 --wpp sintel_trailer_2k_1080p24.y4m sintel.mkv
2013-07-24 23:45:46 < Shiz> :awesome:
2013-07-24 23:47:28 < muggs_> keen
2013-07-24 23:49:31 < Shiz> ehrm
2013-07-24 23:49:32 < Shiz> mark           51282 761.8 35.0  9727616 5871416 s010  RN+   1:47am  11:57.38 ./x265 --threads 8 --gops 8 sintel_trailer_2k_1080p24.y4m sintel.mkv
2013-07-24 23:49:43 < Shiz> xcuz me x265 wtf r u doin
2013-07-24 23:50:08 < muggs_> lol --gops 8 will eat memory like nothing..
2013-07-24 23:50:36 < muggs_> I really should rip that out and implement it at the CLI level.
2013-07-24 23:50:38 < Shiz> and cpu apparently
2013-07-24 23:50:48 < muggs_> it would be more efficient
2013-07-24 23:51:13 < Shiz> mid you
2013-07-24 23:51:17 < Shiz> this is 35% of 16gb ram
2013-07-24 23:51:18 < muggs_> all your corez belong to us
2013-07-24 23:52:52 < Shiz> it wouldn't even start encoding though
2013-07-24 23:52:55 < Shiz> so I knocked it off for now
2013-07-24 23:52:57 < Shiz> back to single thread
2013-07-24 23:53:22 < muggs_> when --gops > 1, progress reports are per keyframe
2013-07-24 23:53:34 < Shiz> ah.
2013-07-24 23:54:00 < muggs_> adding --log 3 helps
2013-07-24 23:54:23 < Skyler_> muggs_: I suggest copying x264's logging code
2013-07-24 23:54:52 < Shiz> so many newlines
2013-07-24 23:55:17 < Shiz> I shouldn't keep my laptop at my lap
2013-07-24 23:55:21 < muggs_> Skyler_: it mimics x264 pretty closely, it's just that the encoder blocks for the entire keyframe interval
2013-07-24 23:55:28 < Shiz> at this rate I'm going to lose fertility while encoding pretty soon
2013-07-24 23:55:34 < muggs_> Shiz: not if you want to reproduce :)
2013-07-24 23:56:05 < Skyler_> oh geez
2013-07-24 23:56:13 < Skyler_> blocking for the keyrame interval seems incredibly bizarre though
2013-07-24 23:56:17 < Skyler_> I have no idea why you'd do that
2013-07-24 23:56:43 < muggs_> it has to wait for one to finish before it can fill it up again.. GOP parallelism is ugly
2013-07-24 23:56:47 < Shiz> 0.23fps with 4 gop threads
2013-07-24 23:56:52 < Shiz> o_O
2013-07-24 23:57:15 < Skyler_> I... really don't think that's a workable design
2013-07-24 23:57:25 < Skyler_> how can you implement any remotely acceptable latency like that?
2013-07-24 23:57:51 < muggs_> it's going away. it's just a question of when
2013-07-24 23:57:56 < Skyler_> okay
2013-07-24 23:58:32 < Skyler_> if I might motivate you based on money, in my experience the vast majority of x264 licensees are interested in real-time conversion :p
2013-07-24 23:58:42 < Skyler_> where gop threadnig isn't relevant
2013-07-24 23:59:58 < muggs_> I understand that's where we need to get to
--- Day changed Thu Jul 25 2013
2013-07-25 00:01:34 < muggs_> curious, do most of those customers use baseline profile and slice threads?
2013-07-25 00:08:03 < Skyler_> well, there's definitely a wide rnge of applications; only some are super low latency
2013-07-25 00:08:14 < Skyler_> e.g. some might be streaming video, but not with any serious latency constraints (e.g. broadcast)
2013-07-25 00:08:23 < Skyler_> I don't think anyone seriously uses baseline anymore
2013-07-25 00:16:03 < Shiz> oh, also
2013-07-25 00:16:04 < Shiz> http://software.intel.com/en-us/blogs/2013/07/10/avx-512-instructions
2013-07-25 00:18:24 < muggs> those are for their Phi processors, no?
2013-07-25 00:18:38 < Shiz> yup
2013-07-25 00:20:45 < Shiz> well
2013-07-25 00:20:49 < Shiz> it's the successor of the phi
2013-07-25 00:28:07 < muggs_> Shiz: can you paste-bin the warnings that clang gave for the primitives?  I can have them fixed tonight
2013-07-25 00:30:08 < Shiz> there were shitloads
2013-07-25 00:38:06 < muggs_> hmm, a sampling then
2013-07-25 00:38:27 < Shiz> it mostly caused by -Wshadow and -Wunused
2013-07-25 00:38:34 < Shiz> there were some errors but I fixed those in the source
2013-07-25 00:38:35 < Shiz> it was*
2013-07-25 00:39:59 < Mandarinka> there were some slides that suggested that the Xeon Phi successor might share this 512-bit AVX with Skylake CPU - maybe.
2013-07-25 00:40:20 < Mandarinka> it was not clear how old and how reliable those slides were
2013-07-25 00:40:39 < Mandarinka> (possibly from Hot Chips 2012, but not sure)
2013-07-25 00:55:52 < muggs_> btw: my official policy on the vector/instrinsic primitives is that as soon as we have ASM for them they can be removed
2013-07-25 01:32:08 < Shiz> encoded 1253 frames in 5019.37s (0.25 fps), 327.91 kb/s
2013-07-25 01:37:36 < Shiz> -rw-r--r--  1 mark  staff    12M 25 Jul 03:36 sintel.h264
2013-07-25 01:37:37 < Shiz> -rw-r--r--  1 mark  staff   2.0M 25 Jul 03:17 sintel.h265
2013-07-25 01:37:39 < Shiz> -rw-r--r--  1 mark  staff   3.6G 25 May  2010 sintel_trailer_2k_1080p24.y4m
2013-07-25 01:37:41 < Shiz> not bad, muggs
2013-07-25 01:38:12 < Skyler_> does it look okay at 300kbps?
2013-07-25 01:38:27 < Shiz> that's the thing
2013-07-25 01:38:32 < Shiz> I don't think I have a h265 player here
2013-07-25 01:41:46 < muggs> it's a start
2013-07-25 01:42:12 < muggs> when I want to see the outputs, I use -r recon.y4m.
2013-07-25 01:44:45 < Shiz> http://img.salty-salty-studios.com/priv/x265
2013-07-25 01:44:54 < Shiz> a redistributable 10.8 OSX binary
2013-07-25 10:34:04  * koda is so happy x265 uses mercurial
2013-07-25 10:36:34 < kurosu> Hi, I had a look to test the current state of x265
2013-07-25 10:37:13 < kurosu> from what I see, an avx-capable toolchain (gcc+binutils) is required (had to gut quite a bit of stuff)
2013-07-25 10:37:50 < kurosu> what I wanted to see is how it compares to the actual HM, performance and coding efficiency-wise
2013-07-25 10:38:33 < kurosu> it seems all the coding tools are implemented (from a coding efficiency viewpoint)
2013-07-25 10:39:13 < koda> afaik all image prediction tools are missing so you'll gain speed, but little coding
2013-07-25 10:39:15 < kurosu> The only think I wasn't able to match is the random-access configuration, that uses some kind of hierarchical QPs and frame refs
2013-07-25 10:39:56 < kurosu> "image prediction tools"? as in intra or inter? I saw rectangular/AMP partitions, sign hiding, sao, merge candidates and so on
2013-07-25 10:40:10 < kurosu> I didn't check if the intra preds were all implemented
2013-07-25 10:40:17 < kurosu> s/think/thing
2013-07-25 10:40:41 < JEEB> <kurosu> what I wanted to see is how it compares to the actual HM, performance and coding efficiency-wise <- well, speed-wise it's a lot faster, but I wouldn't be surprised if the end result isn't that pretty :)
2013-07-25 10:40:56 < kurosu> I guess one can currenly only compare the intra configs
2013-07-25 10:41:31 < koda> kurosu, sorry image type analysis (which lead to which is the best prediction mode to use)
2013-07-25 10:41:38 < kurosu> well, the HM config is like 0.1fps, which is probably 10x the speed of the HM
2013-07-25 10:42:09 < kurosu> koda: well, HM does not use that, but rather a fixed configuration
2013-07-25 10:42:53 < kurosu> which is precisely what I can't see a way to emulate
2013-07-25 10:43:43 < JEEB> you mean picture type configuration?
2013-07-25 10:43:47 < JEEB> that is hardcoded
2013-07-25 10:44:08 < JEEB> the pdf in the downloads of the repo IIRC goes over that stuff
2013-07-25 10:44:36 < kurosu> yes, random access configuration, ie what qp delta compared to intra, what coding order and what references to use
2013-07-25 10:44:39 < kurosu> ok
2013-07-25 10:47:18 < kurosu> I don't see anything related to that kind of settings
2013-07-25 10:48:53 < JEEB> yeah, it just says it's hardcoded :P
2013-07-25 10:49:18 < JEEB> there's an intra-only setting, I+P (default) and I+P+B (has to be enabled specifically)
2013-07-25 10:50:02 < koda> mah compiling this is freaking slow :|
2013-07-25 10:50:10 < kurosu> you can somehow emulate lowdelay P then, but I am unsure how you can set the number of ref frames
2013-07-25 10:50:41 < JEEB> you'll most probably have to see the source code to see the exact hardcoded coding type setup
2013-07-25 10:52:51 < kurosu> this was just a lazy evaluation (just test what can be tested out of the box), not planning on tweaking it to match HM configs
2013-07-25 10:59:03 < kurosu> laters
2013-07-25 12:02:56 < koda> hmmm
2013-07-25 12:03:09 < koda> i want to much to change a few command line parameters
2013-07-25 12:03:16 < koda> s/to/so/
2013-07-25 12:05:25 < koda> i'll make a pull request...
2013-07-25 12:05:42 < JEEB> :)
2013-07-25 12:06:18 < JEEB> yeah, seems to be the only way atm, since videolan and MCW seem to have some herp and derp between them because of the caprices of some corps that are funding the project
2013-07-25 12:15:54 < koda> yay black frames when decoding the bitstream with libav
2013-07-25 12:23:39 < Shiz> I have a fantastic video
2013-07-25 12:24:21 < Shiz> http://a.pomf.se/4Et0.mp4
2013-07-25 12:24:26 < Shiz> h265 converted back to mp4
2013-07-25 12:24:56 < Shiz> as you can see x265 is still... yeah....
2013-07-25 12:26:42 < Skyler_> well, it is 300kbps :p
2013-07-25 13:04:07 < koda> sent
2013-07-25 13:05:24 < koda> or rather, created
2013-07-25 14:43:18 < muggs> mornin
2013-07-25 14:45:17  * koda encoded a file with x265 and decoded it with smarter's libav <3
2013-07-25 14:50:05 < JEEBsv> muggs: btw do you have any code left over from HM? I think you should add COPYING.HM or something to doc/ that notes that parts of x265 are based on HM and contains HM's copyright and license. Unless you have made a separate deal with ITU/ISO/IEC regarding that
2013-07-25 14:53:17 < koda> indeed
2013-07-25 14:55:40 < Daiz> JEEBsv: I think there still are parts and such a notice already exists
2013-07-25 14:56:04 < Daiz> https://bitbucket.org/multicoreware/x265/wiki/Mission
2013-07-25 14:56:06 < Daiz> see the Footnote on GPL and BSD Licenses
2013-07-25 14:57:29 < nevcairiel> from a license perspective it is however required that the source includes the license the HM code is licensed under, a footnote on the wiki is not enough
2013-07-25 14:57:59 < JEEBsv> yeah
2013-07-25 14:58:36 < nevcairiel> basically, just copy their license file into the source and be done! :)
2013-07-25 14:59:15 < muggs> source\Lib contains all HM code, and there's a README there that says where it came from
2013-07-25 14:59:30 < muggs> and all their files still have their BSD header
2013-07-25 15:00:25 < nevcairiel> to be completely safe you should probably include the license file in that same dir, but IANAL, and am not sure if the file headers alone are enough to make them happy
2013-07-25 15:00:39 < muggs> the HM's "COPYING" file is the same text thats in their header
2013-07-25 15:01:08 < muggs> but I can copy that into our repo as source\Lib\COPYING.HM
2013-07-25 15:01:25 < JEEBsv> :)
2013-07-25 15:01:40 < nevcairiel> that would at least remove any doubt
2013-07-25 15:01:47 < JEEBsv> yup
2013-07-25 15:02:48 < muggs> done
2013-07-25 15:06:46 < koda> muggs, you also have a few pull requests there ;)
2013-07-25 15:07:25 < muggs> have a phone call atm, will get to those shortly
2013-07-25 15:07:41 < muggs> we need to get our CFA in order too
2013-07-25 15:17:59 < Shiz> hmm
2013-07-25 15:18:10 < Shiz> why is the source height/width in x265_params_t signed?
2013-07-25 15:20:10 < koda> Shiz, it's a new feature of hevc, along with irrational sizes
2013-07-25 15:20:56 < Shiz> ah.
2013-07-25 15:21:06 < Shiz> how would negative size even work
2013-07-25 15:21:22 < Skyler_> I think koda is joking :p
2013-07-25 15:21:33 < JEEBsv> have a negative width and negative stride and you get a down-to-up, right-to-left picture?
2013-07-25 15:22:36 < JEEBsv> I have no other idea why it would be signed :)
2013-07-25 15:23:13 < Skyler_> that'd be positive with, I think
2013-07-25 15:23:14 < Skyler_> *width
2013-07-25 15:24:06 < JEEBsv> positive width would be left-to-right, no?
2013-07-25 15:24:17 < JEEBsv> negative being the other way
2013-07-25 15:24:25 < Skyler_> ... I guess, logically?  it'd probably break everything htough
2013-07-25 15:24:33 < Skyler_> but like, width is a distance, and distances are always positive, so...
2013-07-25 15:24:37 < JEEBsv> yeah
2013-07-25 15:24:43 < JEEBsv> that is true
2013-07-25 15:25:17 < Shiz> Skyler_: is the sad thing here that I wouldn't put it past ISO/IEC to actually do that
2013-07-25 15:25:19 < Shiz> :P
2013-07-25 15:25:33 < Skyler_> pffff
2013-07-25 16:12:54 < muggs> those unsigned's are historical.  the internal vars were unsigned
2013-07-25 16:24:03 < Shiz> but height/width /should/ be unsigned
2013-07-25 16:25:25 < muggs> nearly all of them probably should be
2013-07-25 16:50:45  * muggs shakes fist at Charter
2013-07-25 17:06:00 < muggs> is Vittorio here?
2013-07-25 17:09:28 < Shiz> everyone is dead
2013-07-25 17:11:33 < muggs> our CFA is going to be another day, but I can take your changes and push them under my name if you're ok with it
2013-07-25 17:22:31 < Shiz> or I can just tell you here and now I release my changes under the WTFPL and you are free to do with it as you please
2013-07-25 17:22:36 < Shiz> I can even add it in a pull request comment
2013-07-25 17:22:57 < Shiz> http://www.wtfpl.net/txt/copying/
2013-07-25 17:26:39 < user82> hi all. are there some docs on what you expect from x265 compression wise? i just heard the usual theoretical blabla so far, no real information yet on what is likely to be achieved
2013-07-25 17:27:12 < JEEBsv> you can look at the JCT-VC papers for random numbers created with HM
2013-07-25 17:27:17 < Shiz> well I had 6x times the performance of x264 the other day
2013-07-25 17:27:21 < Shiz> the video was unwatchable though
2013-07-25 17:27:23 < Shiz> ( ≖‿≖)
2013-07-25 17:27:44 < JEEBsv> I would say that the theoretical limit would be that + psychovisual optimizations
2013-07-25 17:27:49 < JEEBsv> and some other stuff
2013-07-25 17:28:57 < JEEBsv> but that's just me throwing up theories, in reality there's no way we can know what this project will end up like :P'
2013-07-25 17:32:40 < muggs> yeah, no predictions from me until we have a lookahead and rate control and can do apples vs apples
2013-07-25 17:33:11 < user82> allright thank you. JEEBsv do you have a link for me? i do not have a great knowledge of their website/style
2013-07-25 17:37:58 < JEEBsv> something like this? http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7580
2013-07-25 17:38:01 < JEEBsv> don't remember exactly
2013-07-25 17:38:11 < JEEBsv> there's also this http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7417
2013-07-25 17:39:36 < user82> found one doc...bitrate saving and psnr is a good start in some graphs
2013-07-25 17:41:55 < muggs> currently adding X265_MALLOC and X265_FREE, using _aligned_malloc() or posix_memalign()
2013-07-25 17:51:19 < JEEBsv> btw, it seems like the place hosting SC29's documents just got hacked last month, which is why it has now had more than a month of downtime
2013-07-25 17:53:34 < muggs> JEEBsv: were you the one interested in removing mingw specific malloc functions?
2013-07-25 17:53:53 < JEEBsv> yeh
2013-07-25 17:54:32 < muggs> I get this if I use _alligned_malloc() directly:  error: '_aligned_malloc' was not declared in this scope
2013-07-25 17:54:42 < JEEBsv> hmm
2013-07-25 17:54:53 < muggs> I can't figure out what to include to get it to compile clean
2013-07-25 17:55:04 < muggs> but mapping it to _mingw_aligned_malloc() does work
2013-07-25 17:55:47 < muggs> this hack: http://sourceforge.net/p/mingw-w64/discussion/723798/thread/ca63be68
2013-07-25 17:55:48 < elenril> doesn't mingw have posix_memalign?
2013-07-25 17:56:06 < JEEBsv> ugh, so there's some hack needed...
2013-07-25 17:56:09 < JEEBsv> lemme restart my browser
2013-07-25 17:56:16 < JEEBsv> this dell 1GB minibook is derp
2013-07-25 17:56:30 < muggs> I'll try posix_memalign once the current build finishes
2013-07-25 17:57:34 < muggs> as a general rule of thumb, I prefer Windows CRT routines when available
2013-07-25 17:57:47 < JEEBsv> huh
2013-07-25 17:58:02 < JEEBsv> that discussion says that _aligned_malloc is in mingw-w64
2013-07-25 17:58:09 < JEEBsv> which is by now the only thing you should be using
2013-07-25 17:58:43 < JEEBsv> or did I read far enough?
2013-07-25 17:59:15 < muggs> that hack is just for mingw32
2013-07-25 17:59:48 < JEEBsv> then you should turn it off for mingw-w64, also mingw-w64 is the only win32/64 mingw toolchain type you should be supporting by now :s
2013-07-25 17:59:53 < JEEBsv> the original mingw is dead by now
2013-07-25 18:00:34 < JEEBsv> (even GCC gave up on supporting original mingw with 4.8)
2013-07-25 18:00:38 < muggs> okey dokey, I missed that memo
2013-07-25 18:01:20 < JEEBsv> basically the only reason to use original mingw is because of win2000 support... and that sounds just like it is :D
2013-07-25 18:02:47  * muggs shivers
2013-07-25 18:03:59 < Daemon404> JEEBsv, dont tell compn
2013-07-25 18:04:01 < Daemon404> he still uses win2k
2013-07-25 18:04:03 < Daemon404> (really)
2013-07-25 18:04:14 < Shiz> is his middle name Adolf perchance
2013-07-25 18:04:15 < JEEBsv> yes, I know
2013-07-25 18:09:06 < Daemon404> muggs, are you gonna be at VDD
2013-07-25 18:09:36 < muggs> my best guess at the moment is no.. but it's not 100%
2013-07-25 18:10:02 < Daemon404> :(
2013-07-25 18:10:11 < muggs> I'll be in Chennai, India for 2 weeks in August, and Amsterdam for 1 week in Sept
2013-07-25 18:10:25 < Daemon404> will any x265 reps be there?
2013-07-25 18:10:57 < muggs> dunno, I'll poke my boss again
2013-07-25 18:16:46 < muggs> ok, just checked.  there's a decent chance I'll be able to attend at least part of it
2013-07-25 18:17:28 < Daemon404> cool
2013-07-25 18:20:47 < Shiz> >Amsterdam for a week
2013-07-25 18:20:49 < Shiz> how terrifying
2013-07-25 18:33:40 < alteregoa> terrifying?
2013-07-25 18:34:35 < alteregoa> are you kidding me? its a very great city, ever been in riijksmuseum? pictures of gaugin or van gogh?
2013-07-25 18:34:36 < alteregoa> rembrandt?
2013-07-25 18:38:13 < Shiz> I live in the Netherlands, so yes
2013-07-25 18:38:20 < Shiz> amsterdam is a shithole
2013-07-25 18:48:04 < muggs> The Netherlands seems setup to draw all of the "Amsterdam" types into the one city, leaving the rest of the country safe for civilization :)
2013-07-25 18:48:28 < alteregoa> shiz
2013-07-25 18:49:04 < alteregoa> well you imported all the arabs, thats the problem
2013-07-25 18:51:03 < alteregoa> all those muslim bastards in belgium and the netherlands are a threat for the freedom, you can't even buy alcohol or pig meat at some places, because you get kicked out by the muslim community
2013-07-25 18:51:27 < alteregoa> and i don't think its racism, its a religion, a retarded religion for my opinion
2013-07-25 18:51:30 < alteregoa> van gogh was killed by a geiteneuker
2013-07-25 18:51:46 < Shiz> protip: stop talking if you have absolutely no idea what you are talking about
2013-07-25 18:52:58 < alteregoa> well i know, it changed a lot from the 80s to yet
2013-07-25 18:52:58 < alteregoa> i'm nto like 15 years
2013-07-25 18:54:21 < Shiz> I do not feel particularly inclined to have this discussion in a channel about an encoder for a next-generation video codec.
2013-07-25 18:54:33 < Shiz> Or online in general.
2013-07-25 18:58:55 < alteregoa> yeah thats the problem of our society, looking away instead of solving the problems. how cowardly
2013-07-25 19:00:07 < JEEB> I think he just really meant that this channel isn't the right place :) Which it isn't
2013-07-25 19:03:16 < Shiz> muggs: possibly accurate.
2013-07-25 19:04:29 < muggs> they're genious if they planned it that way; somehow I doubt it
2013-07-25 19:06:12 < muggs> is this typical?   http://bpaste.net/show/JxPn4Bzw0wbC6XHqI966/
2013-07-25 19:06:55 < Shiz> well, file(1) isn't 100% accurate
2013-07-25 19:07:10 < Shiz> it is accurate in that's a PE32+ file
2013-07-25 19:07:15 < Shiz> (which is PE32 in 64-bit)
2013-07-25 19:07:23 < Daemon404> thats normal in msys
2013-07-25 19:07:38 < JEEB> btw, muggs -- nevcairiel builds toolchains as well :) http://files.1f0.de/mingw/
2013-07-25 19:07:46 < muggs> ok, I'm cool with it then
2013-07-25 19:08:10 < muggs> oh, nice
2013-07-25 19:08:36 < muggs> just realized my old compiler setup was really borked
2013-07-25 19:09:34 < muggs> hmm, does GCC 4.8 support AVX2 intrinsics?
2013-07-25 19:10:00 < Daemon404> if only there was some assembler that supported avx2
2013-07-25 19:10:03 < Daemon404> perhaps called yasm
2013-07-25 19:10:29 < muggs> lol
2013-07-25 19:10:54 < Shiz> inline asm is so dirt
2013-07-25 19:10:56 < Shiz> y
2013-07-25 19:11:01  * muggs mumbles something about birds and bushes
2013-07-25 19:58:31 < muggs> been exciting around my home this morning.  neighbor A got in her car, passed out, and drove through the front of neighbor B's house
2013-07-25 20:08:30 < MCW> but do you have pictures muggs?
2013-07-25 20:09:00 < muggs> there were TV crews here a while ago.  I can get some if you're curious
2013-07-25 20:09:51 < MCW> TV crews?!!   I want video now.  HEVC format please.
2013-07-25 20:19:00 < muggs> lol
2013-07-25 20:40:39 < muggs> pushed 5 minor commits
2013-07-25 21:02:50 < koda> muggs: that's ok, i'll wait for the CLA to shape :)
2013-07-25 22:06:59 < muggs> koda: ok, thanks
2013-07-25 22:34:30 < Shiz> boop
2013-07-25 22:49:04 < muggs> heh, I thought I heard a helicopter:  http://www.ksdk.com/news/article/389831/3/Woman-drives-through-front-of-St-Charles-home
2013-07-25 22:52:13 < muggs> that's across the street from my house
--- Day changed Fri Jul 26 2013
2013-07-26 05:24:17 < muggs> I fixed the reported crash in computeSSD.  working through problems reported by valgrind
2013-07-26 05:29:10 < Skyler_> nice!  let's try to aim to make things valgrind-clean maybe?
2013-07-26 05:29:51 < muggs> seems possible; only two warnings left for the default options
2013-07-26 05:29:59 < muggs> both in HM code
2013-07-26 05:30:17 < muggs> http://bpaste.net/show/09XCGWSesH1nDNRkiXQQ/
2013-07-26 05:36:19 < muggs> fixed, now on to http://bpaste.net/show/FZMtBQ6aIsX6SA442VbI/
2013-07-26 05:39:52 < muggs> this one is trickier
2013-07-26 05:58:21 < muggs> fixed.
2013-07-26 05:58:39 < muggs> I've not used valgrind much.  Should I be using some flags to enable more checking?
2013-07-26 06:01:17 < Skyler_> I don't think so?  there's some useful flags to add more debug info but the defaults should be okay
2013-07-26 06:01:25 < Skyler_> (i.e. to help track things down)
2013-07-26 06:01:42 < muggs> ok, cool then
2013-07-26 11:36:37 < JEEBsv> holy crap, cross-compilation with cmake looks like a major PITA
2013-07-26 11:36:41 < JEEBsv> http://stackoverflow.com/questions/12844772/how-to-cross-compile-cmake-for-arm-with-cmake
2013-07-26 11:55:48 < JEEBsv> http://up-cat.net/p/adf47671
2013-07-26 11:56:00 < JEEBsv> almost there
2013-07-26 12:03:37 < JEEBsv> and after defining the yasm binary name to 'yasm' it works
2013-07-26 12:03:51 < JEEBsv> let's see if it compiles
2013-07-26 12:04:43 < nevcairiel> the way cross-compiling with cmake is usually done is that the source already includes profiles for cross-compiling and you just tell it which to use
2013-07-26 12:05:21 < nevcairiel> of course one person has to figure this out and create the profiles .)
2013-07-26 12:05:45 < JEEBsv> yes, thus in the end you will just try to write the toolchain files :D
2013-07-26 12:06:08 < JEEBsv> and hope the lib/tool checks aren't completely messed up
2013-07-26 12:07:23 < JEEBsv> anyways, the yasm check needs tweaking because if you have a yasm binary and it can be run on the compiling machine you most probably want to use that, esp. if there is no cross-prefix-yasm
2013-07-26 12:07:28 < JEEBsv> instead of erroring out
2013-07-26 12:08:00 < nevcairiel> is there ever a cross-prefix yasm? i thought it takes its target as a parameter
2013-07-26 12:08:26 < JEEBsv> well, it's OK to check for a cross-prefix-yasm, but in general you just check for a "yasm" binary on the host
2013-07-26 12:08:41 < JEEBsv> because yes, yasm just takes target as param
2013-07-26 12:09:39 < JEEBsv> also another lovely part of cmake is that it will ignore any settings you set if you have already configured once :D
2013-07-26 12:09:42 < JEEBsv> all dat caching
2013-07-26 12:09:57 < JEEBsv> it will just warn you: uhh, I will ignore this define you just set lol
2013-07-26 12:10:16 < nevcairiel> most configure systems need a reconfig for such changes :d
2013-07-26 12:10:39 < JEEBsv> yes, but it will not reconfig
2013-07-26 12:11:14 < JEEBsv> you just have to manually rm -rf CMakeCache.txt CMakeCopyOfCache.txt (or so) and CMakeFiles
2013-07-26 12:11:25 < JEEBsv> (file/dir names written off from memory)
2013-07-26 12:11:25 < nevcairiel> no make distclean?
2013-07-26 12:11:37 < JEEBsv> rm -rf CMakeCache.txt CopyOfCMakeCache.txt CMakeFiles/
2013-07-26 12:11:54 < JEEBsv> almost got the middle one right
2013-07-26 12:12:25 < JEEBsv> I only tested make clean, so I would be gladly surprised if make distclean worked and removed all cached stuff
2013-07-26 12:14:41 < nevcairiel> distclean is usually designed to remove the config things as well, but if it does on cmake, who knows
2013-07-26 12:15:26 < nevcairiel> only briefly touched cmake on one project, and not in depth, i dont remember much anymore
2013-07-26 12:15:53 < JEEBsv> I'm waiting to find out that the cmake stuff uses yasm in some incorrect way
2013-07-26 12:16:07 < JEEBsv> but I did set system to windows so it might work
2013-07-26 12:16:37 < nevcairiel> anyhow, i wanted to package a release
2013-07-26 12:16:42  * nevcairiel goes back to doing something useful
2013-07-26 12:16:53 < JEEBsv> :)
2013-07-26 12:40:52 < JEEBsv> http://up-cat.net/p/3a574dea
2013-07-26 12:40:53 < JEEBsv> yay
2013-07-26 12:40:56 < JEEBsv> actually got a binary built \o/
2013-07-26 12:41:31 < nevcairiel> why did you have to cross compile that anyway?
2013-07-26 12:41:52 < JEEBsv> because I wanted to see if I can do it
2013-07-26 12:41:59 < nevcairiel> i see :d
2013-07-26 12:42:14 < JEEBsv> because cmake is always herped a derp at regarding cross-compilation
2013-07-26 12:42:28 < JEEBsv> and I found some problems in the code regarding cross-compilation :)
2013-07-26 12:44:17 < JEEBsv> http://up-cat.net/p/6905517c
2013-07-26 12:46:18 < koda> JEEBsv, did you have to create a profile?
2013-07-26 12:46:32 < JEEBsv> the toolchain file? yes
2013-07-26 12:47:02 < JEEBsv> http://up-cat.net/p/317a0b91
2013-07-26 12:47:28 < koda> thanks
2013-07-26 12:47:57 < JEEBsv> then you just -DCMAKE_TOOLCHAIN_FILE=welp.cmake
2013-07-26 12:48:41 < koda> so you just have to create a welp.cmale file for each triplet you want to support? i686-w64-mingw32, i686-w64-mingw64 etc etc?
2013-07-26 12:48:56 < JEEBsv> yeah
2013-07-26 12:49:38 < koda> meh
2013-07-26 12:55:15 < koda> could be worse i guess
2013-07-26 12:59:57 < JEEBsv> it just shows that not many people think about cross-compilation with cmake :)
2013-07-26 13:00:12 < JEEBsv> esp. with the fact that most lib/tool checks fail in one way or another, like with yasm here
2013-07-26 13:11:05 < JEEBsv> nevcairiel: no make distclean btw
2013-07-26 13:12:23 < nevcairiel> their FAQ says to gtfo and do out-of-tree builds
2013-07-26 13:13:08 < JEEBsv> yeah, well these are such to begin with. I'm just using the pre-set directories where the shell scripts are so I can't just rm -rf the dir
2013-07-26 18:24:00 < muggs> I've added mc-a2.asm to the build for frame_init_lowres_core, but I get unresolved symbols for all but the MMX2 version.  Any guesses as to why?
2013-07-26 18:26:13 < muggs> bah, nevermind, figured it out
2013-07-26 18:29:13 < JEEBsv> muggs: btw I got cross-compilation to work :P
2013-07-26 18:29:26 < muggs> oh, sweet.
2013-07-26 18:29:51 < muggs> how much surgery did it require?
2013-07-26 18:29:57 < JEEBsv> not much
2013-07-26 18:30:08 < JEEBsv> cmake is just a bitch and the yasm test insists on having cross-prefix-yasm
2013-07-26 18:30:19 < JEEBsv> http://up-cat.net/p/6905517c some changes I did
2013-07-26 18:30:38 < JEEBsv> the latter one was the thing that broke build
2013-07-26 18:31:11 < JEEBsv> then you have to make a toolchain file like this http://up-cat.net/p/317a0b91
2013-07-26 18:31:59 < JEEBsv> and then cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=welp.cmake ../../source
2013-07-26 18:32:04 < JEEBsv> and it should pass
2013-07-26 18:32:14 < JEEBsv> the yasm definition would be unneeded if the yasm check was fixed
2013-07-26 18:32:28 < JEEBsv> (as in, don't fail if you find a proper yasm as 'yasm')
2013-07-26 18:35:01 < muggs> I'll try to get those fixes in today, and add the cross-compile notes to the wiki
2013-07-26 18:35:47 < muggs> which yasm check is breaking?  the list of filenames?
2013-07-26 18:36:09 < JEEBsv> basically it finds the yasm just fine that's on PATH
2013-07-26 18:36:19 < JEEBsv> and then tries to find cross-prefix-yasm
2013-07-26 18:36:22 < JEEBsv> which of course fails
2013-07-26 18:36:41 < JEEBsv> f.ex. in case of cross-prefix being i686-w64-mingw32, i686-w64-mingw32-yasm
2013-07-26 18:39:39 < muggs> oh.. I have no idea how to prevent that
2013-07-26 18:41:23 < muggs> hmm, time to resync with the x264 asm I think
2013-07-26 18:55:22 < JEEBsv> muggs: the way to fix the yasm check should be available somewhere
2013-07-26 18:58:41 < JEEBsv> in any case, if I don't have the yasm define the failure looks like this http://up-cat.net/p/36b51ab9
2013-07-26 19:03:17 < muggs> ok, that's helpful. thanks
2013-07-26 21:55:14 < muggs_> thanks JEEBsv: https://bitbucket.org/multicoreware/x265/wiki/CrossCompile
2013-07-26 21:56:54 < JEEBsv> np
2013-07-26 22:05:00 < muggs_> Skyler_: AMD is asking me to present at AFDS on Nov 11 and whether you would like to do an introduction again
2013-07-26 22:09:28 < muggs_> I'm not sure if we'll have anything GPU centric by then
--- Day changed Sat Jul 27 2013
2013-07-27 11:46:51 < Daemon404> [18:09] < muggs_> I'm not sure if we'll have anything GPU centric by then <-- i am curious
2013-07-27 11:46:57 < Daemon404> why are you focusing on SIMD and GPU
2013-07-27 11:46:59 < Daemon404> rather than
2013-07-27 11:47:00 < Daemon404> you knpw
2013-07-27 11:47:02 < Daemon404> ratecontrol.
2013-07-27 11:47:17 < Daemon404> seems like some screwed up priorities if you ask me.
2013-07-27 11:49:55 < Daemon404> (alternatively, s/ratecontrol/<some thing that is desparately needed for decent quality>)
2013-07-27 11:50:51 < JEEB> looking at https://bitbucket.org/multicoreware/x265/wiki/RoadMap
2013-07-27 11:51:01 < JEEB> their current priorities are 8 and 9
2013-07-27 11:51:10 < JEEB> which are ratecontrol and lookahead
2013-07-27 11:51:36 < Daemon404> 600kb of intrinsics says otherwise
2013-07-27 11:52:00 < JEEB> :D
2013-07-27 11:55:25 < JEEB> oh well, I must say you won't be getting that answer right now because the person is not online :)
2013-07-27 11:56:13 < JEEB> also GCC 4.7.3 just failed to build current HEAD
2013-07-27 11:56:51 < JEEB> http://up-cat.net/p/749907b8
2013-07-27 12:06:21 < Daemon404> i think they mostly only test with MSVC
2013-07-27 12:10:12 < JEEB> nah, muggs tests on GCC mostly it seems
2013-07-27 12:42:08 < Kovensky> "Usually same day delivery of encoded frames" laff
2013-07-27 14:19:49 < nevcairiel> Daemon404: because porting existing asm is a rather low hanging fruit for quite a nice benefit, this is how priorities are made :d
2013-07-27 14:21:36 < nevcairiel> (also, didnt he say that they might not have anything GPU related in november, suggesting that its not a priority?)
2013-07-27 14:28:42 < Shiz> a/w 13
2013-07-27 15:31:22 < Daemon404> [10:19] < nevcairiel> Daemon404: because porting existing asm is a rather low hanging fruit for quite a nice benefit, this is how priorities are made :d <-- what part of 500 kb of *new* intrnsics was unclear
2013-07-27 15:31:27 < Daemon404> :P
2013-07-27 15:31:31 < Daemon404> im not talking about the ported asm
2013-07-27 15:33:22 < Skyler_> there could be good reasons, e.g. someone working on the project's main expertise is asm, so let them do their job
2013-07-27 21:55:06 < JEEB> hah, I didn't even have to bring up the GCC werror crashing :D
--- Day changed Sun Jul 28 2013
2013-07-28 00:44:58 < muggs> I'll catch those eventually
--- Day changed Mon Jul 29 2013
2013-07-29 15:26:12 < JEEBsv> oh good riddance!'
2013-07-29 15:26:24 < JEEBsv> 13/08/02
2013-07-29 15:26:31 < JEEBsv> WD of ISO/IEC 14496-15:2013 AMD 2 - Additional technologies for carriage of HEVC
2013-07-29 15:26:42 < JEEBsv> way about time
2013-07-29 15:27:31 < nevcairiel> can haz file now?
2013-07-29 15:27:42 < JEEBsv> says august the 2nd
2013-07-29 15:28:11 < JEEBsv> I motherfucking hope it finally comes out as the last draft
2013-07-29 15:28:15 < JEEBsv> so people can finally implementi t
2013-07-29 15:28:17 < JEEBsv> *it
2013-07-29 15:43:38 < koda> august 2nd for publishing?
2013-07-29 15:44:20 < JEEBsv> for the final draft, preliminarily
2013-07-29 15:49:40 < koda> anything interesting coming out from today meeting?
2013-07-29 15:50:44 < JEEBsv> not that I know
2013-07-29 15:52:35 < koda> maybe some stuff on fpa
2013-07-29 15:52:57 < JEEBsv> in any case I'm happy as hell that 14496-15 AMD2 is finally getting ready
2013-07-29 15:53:08 < JEEBsv> because that should settle matroska as well
2013-07-29 19:55:06 < someday> JEEB : I have yet to experience HEVC, just in reading mode right now.  here  https://bitbucket.org/multicoreware/x265/wiki/RoadMap :
2013-07-29 19:55:21 < someday> we have "Usually same day delivery of encoded frames"
2013-07-29 19:55:25 < someday> :)
2013-07-29 19:55:39 < someday> is it that slow ?
2013-07-29 19:55:56 < JEEB> even HM wasn't that slow for me :P
2013-07-29 19:56:06 < JEEB> Daiz got speeds of around 4fps or so?
2013-07-29 19:56:10 < JEEB> with 720p
2013-07-29 19:56:40 < someday> :)...
2013-07-29 19:59:08 < someday> I guess x265 has lot of work or optimizations to do .....is HEVC is built on the concept of utilizing GPU ?
2013-07-29 19:59:40 < JEEB> I would say "no" at being "built on the concept of utilizing a GPU"
2013-07-29 19:59:41 < Mandarinka> 4K with some rdo enabled (the aq options iirc) probably could take up to a day
2013-07-29 20:00:16 < Mandarinka> I know I had an SD clip for testing, but enabling that stuff made it take about 20 minutes per frame on an AMD
2013-07-29 20:00:38 < JEEB> parallelism-wise HEVC seems to do fine, though
2013-07-29 20:00:46 < JEEB> esp. since every maker wants to use WPP
2013-07-29 20:00:51 < JEEB> including x265
2013-07-29 20:01:02 < JEEB> so you have plenty of threading even inside a single picture
2013-07-29 20:02:44 < Mandarinka> I wonder if there will be a quality hit, like there is for slices
2013-07-29 20:03:08 < Mandarinka> well, there is one for x264's threading too, but that's probably hardly meassurable
2013-07-29 20:04:37 < someday> hmm..may be not ....just faster ?
2013-07-29 20:15:30 < easyfab> ~1% degradation compared to a non parallel mode
2013-07-29 20:16:00 < easyfab> see here : http://forum.doom9.org/showthread.php?p=1638530#post1638530   slide 110
2013-07-29 20:30:46 < Mandarinka> hmm.
2013-07-29 20:33:41 < j-b> muggs_: ping
2013-07-29 20:54:37 < someday> easyfab: that's a good analysis. 1% how much will that be in dB?
2013-07-29 20:57:53 < Skyler_> 0.05
2013-07-29 21:21:56 < someday> hmm...not that much of difference
2013-07-29 21:34:29 < muggs_> j-b: pong
2013-07-29 21:34:50 < muggs_> WPP costs about 1% in compression
2013-07-29 22:05:02 < muggs_> "same day delivery" was a bit tongue in cheek, thus the quotes
2013-07-29 22:54:38 < muggs> btw: people testing visual quality of x265 will want to enable SAO (--sao), it is disabled by default.  It helps banding and ringing
2013-07-29 22:55:07 < Skyler_> is there some reason it's off by default?
2013-07-29 23:06:46 < muggs> don't remember a particularly compelling reason
2013-07-29 23:08:33 < Skyler_> then it should be on by default
2013-07-29 23:08:38 < muggs> enabling...
2013-07-29 23:08:58 < Skyler_> in general, I think x265 should follow from the start the strategy of making the defaults sensible
2013-07-29 23:09:50 < Mandarinka> for years, there were anime rips with way suboptimal settings, just because many options weren't enabled by default :D
2013-07-29 23:10:11 < Mandarinka> frameref was set to 1 for example...
2013-07-29 23:10:37 < muggs> btw: gop parallelism is gone on the default branch, hopefully to be replaced by frame parallelism in the next few weeks
2013-07-29 23:10:56 < Mandarinka> that's fast!
2013-07-29 23:12:08 < muggs> see doc/LookaheadPlan.txt in the repo.  I'm almost to the "apply C4 to TEncGOP" step
2013-07-29 23:16:20 < muggs> enabling AMP by default as well
2013-07-29 23:16:33 < smarter> do you have some stats on how much SAO helps/how long it takes?
2013-07-29 23:17:27 < muggs> it depends a lot on bitrate, etc.  the higher the QP the more it helps
2013-07-29 23:17:42 < muggs> I think it's usually a good trade-off
2013-07-29 23:17:44 < smarter> not sure now, but at some point it was rather costly in the libav hevc decoder
2013-07-29 23:17:58 < Skyler_> I don't think we can judge performance until everything is SIMD'd (decoder-wise)
2013-07-29 23:18:05 < smarter> right :)
2013-07-29 23:19:07 < smarter> but I think what made SAO slow was the huge number of branching decisions
2013-07-29 23:19:27 < kurosu_> it can be implemented using pshufb
2013-07-29 23:19:34 < Mandarinka> good things come to those who wait :D
2013-07-29 23:20:35 < smarter> kurosu_: ah, I should look into that :)
2013-07-29 23:21:08 < Skyler_> pshufb is wonderful and you should use it everywhere
2013-07-29 23:21:52 < smarter> Skyler_: BBB told me that the other day yes :)
2013-07-29 23:22:03 < kurosu_> iirc, it should be less than 10% (highly dependent on how good your simd usage is, and the entropy decoder)
2013-07-29 23:23:00 < Mandarinka> regarding cpu-heavy features: http://i.imgur.com/8dqyEml.jpg :)
2013-07-29 23:24:14 < muggs> when we run vtune, MotionEstimation is #40 on the list
--- Day changed Tue Jul 30 2013
2013-07-30 07:41:40 < j-b> muggs: pong
2013-07-30 16:46:34 < muggs> j-b: ping
2013-07-30 16:52:20 < j-b> muggs: pong
2013-07-30 17:22:24 < muggs> j-b: hi, sorry I missed you yesterday.  did you need something?
2013-07-30 18:06:50 < j-b> muggs: a pubkey :)
2013-07-30 18:10:37 < muggs> aha
2013-07-30 18:12:06 < muggs> I'm actually at the office today so I don't have my typical key handy.  I can email you one later today or I can make a new one now.
2013-07-30 18:12:30 < j-b> nothing is urgent, if I remember correctly our last call.
2013-07-30 18:13:09 < muggs> true, we have a few days to get it all ready
2013-07-30 18:58:59 < BugMaster> j-b: hi. is the location of vdd still not decided?
2013-07-30 20:13:45 < j-b> BugMaster: still in Paris, probably near Madeleine.
2013-07-30 20:13:52 < j-b> BugMaster: would be nice seeing you there.
2013-07-30 21:51:09 < kierank> nice part of paris
2013-07-30 22:35:52 < someday> does VPS make H.265 SVC ?
2013-07-30 22:36:13 < JEEBsv> what
2013-07-30 22:38:27 < someday> using VPS can we move around profiles/levels in H.265 ? like base to extended ?
2013-07-30 22:39:08 < JEEBsv> what :D
2013-07-30 22:39:12 < koda> what :S
2013-07-30 22:39:29 < koda> JEEBsv: called it
2013-07-30 22:39:42 < someday> ok..I would rather ask what is the purpose of VPS :)
2013-07-30 22:40:48 < Daemon404> define vps please
2013-07-30 22:41:18 < someday> VPS is video parameter set
2013-07-30 22:41:29 < someday> its an addition in h.265
2013-07-30 22:41:37 < someday> on top of SPS and PPS
2013-07-30 22:41:49 < JEEBsv> oh right
2013-07-30 22:41:53 < JEEBsv> that VPS
2013-07-30 22:42:33 < someday> its more for backward compatibility ... however was wondering can it be used for SVC
2013-07-30 22:42:49 < Paranoialmaniac> ???
2013-07-30 22:43:26 < Paranoialmaniac> SVC is not published yet
2013-07-30 22:43:29 < someday> Ok ...lets start what is the purpose of VPS :)
2013-07-30 23:15:38 < someday>  For the HEVC extensions for scalable (SHVC) and 3D coding, the VPS
2013-07-30 23:15:39 < someday>    is planned to also convey information about non-temporal layer
2013-07-30 23:15:41 < someday>    dependency, and related side information.  => rtp rfc http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-01
2013-07-30 23:31:31 < j-b> svc, so useful...
2013-07-30 23:43:31 < muggs> j-b: was that sarcasm?
2013-07-30 23:48:22 < muggs> btw: a week or so ago I asked in #freenode about getting channel ops
2013-07-30 23:49:12 < muggs> they asked me to send a message to phc asking for ops to be given to myself or Skyler_,  which I did
2013-07-30 23:49:45 < muggs> and then if I don't hear back in 3 weeks, to go back and get help from a #freenode staff
2013-07-30 23:52:18 < muggs> so there's nothing to do now but wait..
--- Day changed Wed Jul 31 2013
2013-07-31 00:24:59 < muggs> I'm actually looking at pruning some of the tlayer bits from the HM code to make lookahead integration simpler.
2013-07-31 00:25:45 < muggs> relocating. afk for an hour
2013-07-31 05:02:58  * muggs submits VDD registration
2013-07-31 07:31:58 < j-b> muggs: yes it was
2013-07-31 07:55:11 < muggs> heh, phew
2013-07-31 07:56:27 < muggs> looks like I'll be at VDD, just need to order plane tickets
2013-07-31 07:57:35 < j-b> muggs: cool. Can you do a small talk about your work?
2013-07-31 07:57:39 < muggs> I haven't been to Paris since '99
2013-07-31 07:57:58 < muggs> sure, would be good to introduce the work
2013-07-31 07:58:38 < muggs> some rationale for the choices we made; or excuses anyway
--- Day changed Thu Aug 01 2013
2013-08-01 20:02:05 < JEEBsv> lol, it seems HM broke its randomaccess config
--- Day changed Fri Aug 02 2013
2013-08-02 00:22:35 < muggs> JEEBsv: how so?
2013-08-02 04:15:07  * phcsucks 
2013-08-02 04:17:33  * phcsucks x2
2013-08-02 04:18:19  * phcsucks thinks phc smokes pcp
2013-08-02 04:19:07  * phcsucks thinks phc is wrong again
2013-08-02 04:19:09 < phc> u!
2013-08-02 04:19:17  * phcsucks mutiny
2013-08-02 04:19:21 < phc> go ahead set a topic
2013-08-02 04:20:11 < phcsucks> op me
2013-08-02 04:20:46 < phc> new
2013-08-02 04:21:08 < phcsucks> oPmE
2013-08-02 05:22:34 < muggs> unless phc has a change of hearts (which looks doubtful), we'll need to move to #x265-dev
2013-08-02 06:18:58 < easyfab> #x265-dev
2013-08-02 08:01:14 < j-b> 'morning
2013-08-02 08:06:02 < muggs> hello
2013-08-02 08:06:46 < muggs> let me know if you find any objections to the CLA, otherwise I'll post it tomorrow
2013-08-02 08:07:13 < j-b> I'll look at it :)
2013-08-02 08:07:21 < j-b> still waiting for your pubkey though
2013-08-02 08:08:17 < muggs> hmm, let me look
2013-08-02 08:11:49 < muggs> I'll have to boot this laptop into linux to get it, but I'm going to have to do that tomorrow anyway, it's a thg release day
2013-08-02 08:12:26 < muggs> making a note to myself not to forget
2013-08-02 08:13:12 < muggs> do you have a hotel picked out for VDD yet?
2013-08-02 17:28:24 < Shiz> muggs: link to cla
2013-08-02 17:29:10 < muggs> j-b has some small comments, I'm guessing we need to make a few tweaks.  let me poke the guy working on that doc
2013-08-02 17:34:29 < muggs> https://bitbucket.org/multicoreware/x265/downloads
2013-08-02 17:40:16 < BugMaster> are you going to ask sign CLA for every patch somebody sends to you? Otherwise what you going to write in "Description of Contribution" part?
2013-08-02 17:42:21 < Shiz> man, emailing contributions
2013-08-02 17:42:23 < Shiz> sure is 1995 in here
2013-08-02 17:44:59 < j-b> truethat :)
2013-08-02 17:45:48 < muggs> I'm adding a section to the wiki about it.  We only need a CLA for the first contribution
2013-08-02 17:47:47 < muggs> https://bitbucket.org/multicoreware/x265/wiki/Contribute
2013-08-02 17:48:07 < JEEBsv> and I see you got the member shadowing
2013-08-02 17:48:11 < muggs> I thought the part about attaching the contribution was a bit silly myself
2013-08-02 17:48:31 < JEEBsv> was about to poke you about it if it wasn't taken care of :)
2013-08-02 17:48:42 < muggs> JEEBsv: yeah, I need to make it a point to build with gcc-4.8 before pushing
2013-08-02 17:48:53 < muggs> it seems to find warnings nothing else does
2013-08-02 17:49:21 < JEEBsv> at times invalid ones, but so far they've seemed legit enough in the context of this project
2013-08-02 17:49:35 < muggs> making coffee, be back in 5
2013-08-02 17:49:39 < JEEBsv> clang's static analyzer is pretty good too, but unfortunately it's generally off for C++ unless you set a certain system variable
2013-08-02 17:50:37 < j-b> I've been asking gitlab for hg support to get "merge requests"
2013-08-02 17:53:24 < muggs> I know with hg-git you can build a git tree from an hg repo, and pull in the other direction
2013-08-02 17:55:19 < j-b> but that would be ugly for merge requests, no?
2013-08-02 17:56:09 < BugMaster> "We will use commercially reasonable efforts to make any Contribution (or derivative work thereof) available under any license also available under the GNU General Public License (GPL) version 2 (or later)." <- I am little bit concerned by "commercially reasonable" part
2013-08-02 17:56:34 < Shiz> BugMaster: well, guess what the point of a copyright transfer in the first place is
2013-08-02 17:56:42 < Shiz> so that it can be relicensed if they see fit
2013-08-02 17:59:22 < BugMaster> what you mean by relicensed? add addition license? thats ok. but if you mean revoke GPL license that it is not so ok
2013-08-02 18:01:06 < Shiz> that's basically the power you're giving them
2013-08-02 18:01:35 < j-b> BugMaster: they cannot revoke GPL for past works
2013-08-02 18:01:43 < j-b> what has been posted as GPL stays GPL
2013-08-02 18:02:22 < muggs> "also available under the GNU GPL" I think covers that?
2013-08-02 18:03:33 < Shiz> >You agree that each of us can do all things in relation to any Contribution as if each of us were the sole owner, and if one of us makes a derivative work of any Contribution, the one who makes the derivative work (or has it made) will be the sole owner of that derivative work;
2013-08-02 18:03:35 < BugMaster> correct. but I don't like when open source projects closes and become closed source (i.e. new versions are only closed source) or when there is community and Pro version which differ significantly.
2013-08-02 18:03:43 < Shiz> this basically means that they can relicense it to whatever they want
2013-08-02 18:05:06 < j-b> and do commercial forks, no?
2013-08-02 18:05:35 < Shiz> yes
2013-08-02 18:06:24 < muggs> all the work that we do on x265 will be GPL2+ and commercial licensed
2013-08-02 18:09:23 < muggs> I think the "commercially reasonable" clause was to protect us from receiving random patch bombs and being forced to integrate them into the tree even if they're a year old or really terrible
2013-08-02 18:09:52 < muggs> let me ask to be sure
2013-08-02 18:10:07 < j-b> crappy code does not get in, because it's crap.
2013-08-02 18:10:27 < muggs> lord I hope so
2013-08-02 18:10:49 < BugMaster> then you need to say that all patch that will commit in your version would be under GPL also not about commercial reasons to reject which was allowed earlier
2013-08-02 18:12:04 < BugMaster> i.e. not that you will have forever but that while you use it would be available under GPL
2013-08-02 18:13:16 < muggs> something like: "all contributions made towards x265 will always be available under GPL"?
2013-08-02 18:14:46 < BugMaster> dunno (I am not the lawyer). but something similar
2013-08-02 18:15:12 < JEEBsv> doesn't x264 LLC already have a semi-ready CLA?
2013-08-02 18:15:25 < JEEBsv> which could be used as a base
2013-08-02 18:15:58 < muggs> we supposedly based ours on the x264 CLA.. but I honestly haven't read them both
2013-08-02 18:16:31 < Shiz> well supposed the x264 one was only one page
2013-08-02 18:16:34 < Shiz> not 3
2013-08-02 18:17:23 < BugMaster> hm. x264's also had "commercially reasonable efforts" part so may be it is not so bad
2013-08-02 18:17:25 < muggs> ok, the response from Tom wrt to that clause:
2013-08-02 18:17:26 < muggs> This is the language we have in the x264 to x265 agreement.  What we mean by this is that it can take time to make things available in any branch (to merge or refactor, etc).
2013-08-02 18:17:26 < muggs> [1:15:14 PM] Tom Vaughan: We have a full commitment not to have a private commercial fork.
2013-08-02 18:17:26 < muggs> [1:16:11 PM] Tom Vaughan: Any features that ship in a commercial branch (that we deem to be an improvement), will be ported / merged into the GPL branch.  But we need to give muggs time to do that work.
2013-08-02 18:19:47 < muggs> so, any changes to x265 that commercially ships will also be added to the GPL tree
2013-08-02 18:19:57 < BugMaster> I understand commitment (it was also part of Skyler_ work to make sure about this) but I hope this somehow secure by documents (not CLA probably) not only on words
2013-08-02 18:26:31 < muggs> I agree, just not sure how/where to get it done
2013-08-02 18:27:48 < muggs> was that covered in the agreement between x264 and x265?
2013-08-02 18:28:08 < BugMaster> dunno. need to ask Skyler_
2013-08-02 18:29:47 < BugMaster> muggs: btw. little bit offtopic. I noticed your copyright on TortoiseHg. Was that also part of MWC or hobby project?
2013-08-02 18:33:57 < MCW> Hi everyone... Tom V from MCW here (VP of Business Dev).  We have contractually committed to make commercially reasonable efforts to make all changes (improvements) to the x265 Software available as x265 Open Source Software as soon as practicable;
2013-08-02 18:35:16 < MCW> The "as soon as practicable" part is designed to give muggs and the rest of our team the time they need to review / refactor, etc.
2013-08-02 18:37:12 < muggs> BugMaster: I started thg 5 years before joining MCW
2013-08-02 18:38:41 < muggs> my first O/S project was mountapp, circa 1997 I think
2013-08-02 18:39:59 < BugMaster> MCW: hi. I don't see "as soon as practicable" part in version of CLA which was uploaded only "commercially reasonable efforts"
2013-08-02 18:40:01 < muggs> thg was my belated attempt to make sure the "next startup" I worked for would have revision control that didn't suck.  fortunately that actually worked
2013-08-02 18:41:22 < BugMaster> eh. from all tortoise* variants current hg have them most reasonable/useable interface
2013-08-02 18:42:38 < muggs> it's the only one written in Python and QT, as far as I know.  So it's almost an entirely separate code base
2013-08-02 18:43:06 < muggs> one of my engineers just found this:  http://www.heywatchencoding.com/x265
2013-08-02 18:43:10 < MCW> BugMaster:  As you know, we will review every contribution, but won't commit or merge every contribution.  So, this language refers to the fact that it takes time to go from contribution to commit, and that there is no guarantee that a contribution will be accepted as an improvement.
2013-08-02 18:45:15 < BugMaster> and "The decision whether to include Your Contribution in the x265 Software is solely and exclusively in Our discretion, and We are the final arbiter of that decision." part wasn't enough for that?
2013-08-02 18:51:33 < Shiz> nice nickname, MCW
2013-08-02 18:51:35 < Shiz> :p
2013-08-02 18:53:43 < MCW> Bugmaster:  The Contributor Agreement is the same for Commercial Licensees or Open Source Contributors.  The point of this sentence was to more explicitly notify commercial licensees that their contribution, if it is deemed an improvement, will be merged with the root x265 software which is offered under both commercial and GPL licenses.
2013-08-02 18:54:29 < MCW> To be clear, commercial licensees are required to "contribute" all modifications
2013-08-02 18:57:09 < MCW> I can assure you that we are contractually committed to "no private forks".  I can't quote the contract, as it has a confidentiality clause... but Skyler can attest to our commitment.
2013-08-02 18:57:36  * muggs investigates regression in SAO
2013-08-02 19:07:57 < kierank> muggs: seems dodgy. what happens if someone implements a closed spec using x265 like an equivalent to panasonic avc-intra that's under an NDA
2013-08-02 19:08:08 < kierank> commercially reasonable could mean the NDA trumps the GPL requirement
2013-08-02 19:08:46 < kierank> because you can just say it's not an "improvement"
2013-08-02 19:08:56 < kierank> and then people can do all the vendor lockin open source isn't mean to have
2013-08-02 19:11:22 < muggs> I don't think any NDA can trump the GPL.  but what's to prevent someone from doing this with x264?  is it just a matter of trust?
2013-08-02 19:12:00 < kierank> someone couldn't implement avc-intra under the commercial licence afaik
2013-08-02 19:12:12 < kierank> because it would have required code changes that would needed to have been GPLed
2013-08-02 19:12:14 < kierank> and thus break the nda
2013-08-02 19:12:50 < muggs> commercial licensees of x265 are required to contribute all their changes under the GPL
2013-08-02 19:13:01 < muggs> they have to sign the same CLA
2013-08-02 19:13:52 < kierank> but it your decision whether to publish that patch
2013-08-02 19:14:46 < kierank> "19:33:39 <MCW> Hi everyone... Tom V from MCW here (VP of Business Dev).  We have contractually committed to make commercially reasonable efforts to make all changes (improvements) to the x265 Software available as x265 Open Source Software as soon as practicable;"
2013-08-02 19:14:55 < kierank> you can say whatever under "commercially reasonable"
2013-08-02 19:15:21 < kierank> it's not commercially reasonable because we have an nda
2013-08-02 19:15:49 < muggs> so it does boil down to a trust issue.  Would it help if we were obligated to post all code contributions to the mailing list?
2013-08-02 19:16:11 < kierank> yes
2013-08-02 19:16:15 < kierank> afaik this is what Skyler_ does
2013-08-02 19:16:48 < muggs> seems the least I can do
2013-08-02 19:21:13 < muggs> I'll try to get that language into the CLA today
2013-08-02 19:24:21 < muggs> we're going to change this phrase:  "... We may publish Your Contribution on a publicly available website or through a public email mailing list, whether or not we ultimately include it in the x265 Software."
2013-08-02 19:24:34 < muggs> to read: "You understand and agree that We will publish Your Contribution on a publicly available website or through a public email mailing list, whether or not we ultimately include it in the x265 Software."
2013-08-02 19:29:50 < kierank> muggs: is there anything stopping you from BSDing x264
2013-08-02 19:29:54 < kierank> or x265
2013-08-02 19:30:53 < phcisgreat> why all the phc hate?
2013-08-02 19:31:04 < kierank> i dont hate you
2013-08-02 19:31:26 < fyoog> militant fellow there
2013-08-02 19:31:48 < kierank> muggs: also does "Your Contribution" count as all code that gets shipped as part of x265 in a proprietary product
2013-08-02 19:32:05 < muggs> yes
2013-08-02 19:32:20 < muggs> I think the GPL prevents BSD'ing the source
2013-08-02 19:32:31 < kierank> your commercial licence doesn't
2013-08-02 19:32:39 < kierank> Skyler_ could BSD x264 if he wanted to
2013-08-02 19:32:42 < kierank> but could you?
2013-08-02 19:33:06 < muggs> I dunno.  I can't imagine why we would
2013-08-02 19:33:36 < muggs> we're trying to work out an agreement with video-lan so they would take over ownership should MCW cease to have interest in it
2013-08-02 19:33:49 < Mandarink> nice
2013-08-02 20:31:27 < kierank> MCW: are you going to vdd?
2013-08-02 20:31:42 < kierank> you should come
2013-08-02 20:33:39 < MCW> Thanks... I wish I could, but I can't.
2013-08-02 20:52:50 <@muggs> I should be there
2013-08-02 20:55:03  * muggs questions his sanity
2013-08-02 20:56:03 <@muggs> I've pushed some commits to cleanup CPU level indications, but when I use the new enums in the pixel code the compiler ignores them
2013-08-02 20:56:38 <@muggs> msvc and gcc both ignore them, so it must be something in the code, but I don't see it
2013-08-02 21:01:38 <@Skyler_> INSTRSET >= X265_CPU_LEVEL_SSSE3   how can you use greater than values like this? CPU features are, well independent bit masks
2013-08-02 21:03:06 <@Skyler_> #if INSTRSET >= X265_CPU_LEVEL_AVX2 && 0   this looks like it won't run...
2013-08-02 21:03:23 <@Skyler_> why don't you just copy x264's cpu flags or at least something similar?
2013-08-02 21:03:30 <@Skyler_> is there a reason those wouldn't work?
2013-08-02 21:08:53 <@muggs> I've discovered that using defines rather than enums resolves those problems
2013-08-02 21:09:33 <@Skyler_> oh, that makes sense. the value of enums might not be resolved during the preprocessor stage
2013-08-02 21:09:52 <@Skyler_> http://stackoverflow.com/questions/13906508/c-preprocessor-and-enums-mistake-in-my-code
2013-08-02 21:09:53 <@muggs> the CPU detection as an integer level came from Agner Fog's vector class library
2013-08-02 21:10:12 <@Skyler_> I suggest you convert things to use the x264 style, as you cannot assume CPU features are one-dimensional
2013-08-02 21:10:25 <@muggs> there's nothing to prevent us from adopting the x264 approach
2013-08-02 21:10:42 <@Skyler_> (ex: Nehalem, Bulldozer, Haswell cannot be ordered)
2013-08-02 21:11:37 <@muggs> yeah, xop detection is currently un-optimal
2013-08-02 21:11:53 <@Skyler_> it gets more complicated with side-flags like SLOW_LZCNT etc
2013-08-02 21:13:05 <@muggs> we needed to use its build flags in order to generate vector prims for different CPU arches, but I would like to out-grow the vector routines asap
2013-08-02 21:13:54 <@Skyler_> okay
2013-08-02 21:59:36 < MCW> Hi All - So, I've looked at the language in our CLA ...  The concern is that can't create an absolute requirement to publish or include a contribution under the GPL.
2013-08-02 21:59:39 < MCW> When we receive a contribution, we need to review it to be reasonably certain that the contributor had the rights to the contribution that they are attesting that they have..
2013-08-02 22:01:15 < MCW> So, for example, if we have reason to believe that the contribution was copyrighted code from a 3rd party, or was a trade secret protected by an NDA, we won't publish it or consider it for inclusion in x265.
2013-08-02 22:01:36 <@Skyler_> that makes sense, I suppose, if you don't trust the contributors to be competent (which I can believe)
2013-08-02 22:01:49 < MCW> This shouldn't come up often, hopefully... but anyhow, we need to protect the integrity and legality of the code
2013-08-02 22:02:07 <@Skyler_> equally, though, keep in mind that if you discover such a case, you need to stop them from using that code
2013-08-02 22:02:28 < MCW> We have some risk there, obviously... and so we need to have a process in place to get to know our contributors
2013-08-02 22:02:53 <@Skyler_> if Company A is integrating Code B into x265 that it cannot legally contribute to you, you must not only reject Code B, but also hold them liable
2013-08-02 22:02:58 <@Skyler_> and force them to stop using Code B
2013-08-02 22:03:38 <@Skyler_> otherwise, they're creating a proprietary fork, and they can do whatever they want
2013-08-02 22:03:55 <@Skyler_> and the license terms don't allow that
2013-08-02 22:04:27 < MCW> I'm not sure what our obligations would be to the 3rd party whose copyright or protected trade secret is being infringed... but we definitely need to protect our project / brand from contamination and legal problems
2013-08-02 22:04:44 <@Skyler_> yeah, I'm not sure about obligations either, but however things work
2013-08-02 22:04:55 <@Skyler_> it has to be set up so that "integrating proprietary code into x265, by anyone, is illegal"
2013-08-02 22:05:13 <@Skyler_> (unless of course that code will soon cease to be proprietary :P)
2013-08-02 22:05:19 <@Skyler_> or, well
2013-08-02 22:05:27 <@Skyler_> integrating into x265 and then distributing as part of a product or whatever
2013-08-02 22:05:38 <@Skyler_> since, like with the GPL, it doesn't matter if you don't distribute it
2013-08-02 22:05:45 < MCW> Well, clearly it is already illegal to violate someone else's copyright or misappropriate someone's protected trade secret
2013-08-02 22:05:58 <@Skyler_> yeah, I know, that just has to be in the commercial license contract
2013-08-02 22:06:05 <@Skyler_> so that it is a violation
2013-08-02 22:06:36 < MCW> But from our side, even though the contributor attests that they have the rights to their contributions (in the CLA), if they are lying, they put us (MCW and the whole x265 project) at risk
2013-08-02 22:07:01 <@Skyler_> yeah, that's fine
2013-08-02 22:07:15 <@Skyler_> but like I said, if they're lying, they open themselves to liability because they're violating the copyright of the code they contirbuted
2013-08-02 22:07:21 < MCW> Yes, it's in the commercial license agreement..
2013-08-02 22:07:25 <@Skyler_> okay, good
2013-08-02 22:07:38 < MCW> Yeah... I'm less concerned with commercial companies doing this... they have a lot to lose
2013-08-02 22:08:02 <@Skyler_> ahhhhh.  contract work
2013-08-02 22:08:17 < MCW> But it could happen accidentally as well as intentionally
2013-08-02 22:08:26 <@Skyler_> that makes total sense then
2013-08-02 22:08:26 < MCW> yeah... tell me about it...
2013-08-02 22:08:53 <@Skyler_> the contractor isn't contributing though; they're making code for the company hiring them
2013-08-02 22:09:06 <@Skyler_> so it should be okay to arbitrarily delay release of that code, because you're not distributing it yourself or including it in a product etc
2013-08-02 22:09:17 <@Skyler_> so for example, if I hire someone to write a patch for x264
2013-08-02 22:09:26 <@Skyler_> I can keep it to myself for 2 years and never show it to anyone and that's legal
2013-08-02 22:11:31 < MCW> We can chat about this, but I've written our commercial license agreement to be very specific and iron-clad on the requirement to share all modified code back to MCW (back to the x265 software that we license both as commercial and GPL)
2013-08-02 22:11:52 <@Skyler_> I'll trust you on legal specifics like that, you're better than I am :p
2013-08-02 22:13:49 < MCW> * MCW rechecks his commercial license terms
2013-08-02 22:17:48 < MCW> Yeah, it's in there... but you've given me some ideas on possible ways to strengthen it further... thanks
2013-08-02 22:20:04 <@Skyler_> np
2013-08-02 22:28:42 < BugMaster> btw. are there any conditions to what happen with x265 in the case of MWC buyout case by someone not so commited to open source?
2013-08-02 22:29:19 <@Skyler_> that's a good question
2013-08-02 22:29:38 <@Skyler_> as things are we would have "they still have to obey the restrictions on use of x264 code, and x265 would still exist as GPL"
2013-08-02 22:29:44 <@Skyler_> I think
2013-08-02 22:31:09 < BugMaster> that is if license you gave them to use x264 as base for commercial case wouldn't be revoked
2013-08-02 22:34:47 <@Skyler_> well, if they lose the righ to use x264, then x265 will be GPL-only unless they can remove all the x264 code
2013-08-02 22:34:52 <@Skyler_> in which case they could take x265 private, yeah
2013-08-02 22:35:00 <@Skyler_> but of course, the public GPL version would still exist and it could be forked
2013-08-02 22:35:29 <@Skyler_> but this is one of the reasons I like this deal, it nicely ties their hands so that as long as they're not willing to tear apart half the encoder to remove code (years down the line), it will remain open source :p
2013-08-02 22:38:46 < BugMaster> so according to x264's use contract the one who will buyout will still to have to make GPL version or the can't use x264's parts?
2013-08-02 22:42:48 <@Skyler_> basically yes, I think
2013-08-02 22:47:42 < MCW> Skyler is correct... our obligation is binding to us and our respective successors and assigns
2013-08-02 22:48:20 < BugMaster> ic
2013-08-02 22:48:33 < MCW> And obviously... GPL licenses can't be taken back
2013-08-02 22:49:36 < MCW> But we're in this for the long haul... just getting started really
2013-08-02 23:01:09 < koda> what about patents regarding hevc?
2013-08-02 23:01:43 < koda> will the "commercial applicants" have to seek a license at mpegla (or whoever handles that portfolio)?
2013-08-02 23:02:00 <@Skyler_> probably, I can't imagine any other way around it (I mean, GPL users will have to, too, technically)
2013-08-02 23:02:11 <@Skyler_> as will licensees of proprietary encoders
2013-08-02 23:02:38 < koda> hm and what if one of the company has a patent and makes a contribution based on it?
2013-08-02 23:03:23 <@Skyler_> I imagine if that does happen, with a non-essential patent, there might be an intentional choice not to commit it
2013-08-02 23:03:55 <@Skyler_> MCW might add extra constraints to their commercial license agreement to avoid that problem
2013-08-02 23:04:04 < kierank> they have to
2013-08-02 23:04:09 < kierank> otherwise the gpl grant can't exist
2013-08-02 23:04:32 < koda> well they *could* grant a royalty free license for it for x265 users... :p
2013-08-02 23:04:55 < kierank> they do as part of the gpl already
2013-08-02 23:11:24 < BugMaster> it is probably covered by itemt 4 of CLA
2013-08-02 23:11:30 < BugMaster> *item
2013-08-02 23:18:47 < MCW> As with x264, the x265 license doesn't cover patents... it's a license to utilize the copyrighted code... and yes, we explicitly point this out to licensees
2013-08-02 23:20:05 < MCW> koda:  the CLA requires the contributor to give us a license to any patents that they own that cover their contribution
2013-08-02 23:20:37 <@Skyler_> right, that was it
2013-08-02 23:20:40 <@Skyler_> thanks
2013-08-02 23:26:37 < kierank> MCW: and thus that patent licence is granted to every gpl user?
2013-08-02 23:30:07 < MCW> yes
2013-08-02 23:31:25 < MCW> well... effectively... (perhaps not explicitly, because the GPL license doesn't cover patents)
2013-08-02 23:32:55 < koda> umh?
2013-08-02 23:33:00 < koda> iirc it does
2013-08-02 23:33:05 < koda> both v2 and v3
2013-08-02 23:34:44 <@Skyler_> v2 is considered to implicitly cover it (by some interpretations)
2013-08-02 23:34:46 <@Skyler_> while v3 is explicit, I think
2013-08-02 23:37:54 < BugMaster> as I read it v2 cover distribution of binaries. that why France hosting for binaries is good
2013-08-02 23:38:21 < koda> BugMaster: what do you mean?
2013-08-02 23:39:08 < BugMaster> item 7 of http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
2013-08-02 23:41:50 < koda> BugMaster: sorry i was referring to the France part
2013-08-02 23:42:10 < BugMaster> they don't care about software patents
2013-08-02 23:42:19 < kierank> BugMaster: probably true
2013-08-02 23:42:24 < MCW> That's right... there are big differences between the source code that we are licensing under the GPL and binaries that one might create from this source code.
2013-08-02 23:42:30 < koda> ah, well all Europe then :p
2013-08-02 23:44:46 < MCW> But suffice it to say that if a contribution is covered by a patent that the contributor holds, they grant the x265 project administrators (MCW) a license to that patent, and we're not going to offensively assert that patent against x265 licensees of any type
2013-08-02 23:45:15 < kierank> but the licensee can assert it against the gpl users
2013-08-02 23:45:36 < MCW> Let's hope they wouldn't be that dumb... we have the right to sublicense it, and we would
2013-08-02 23:45:44 < BugMaster> in such case MWC probably can sub license it to this party
2013-08-02 23:46:48 < MCW> In other words, the contributor knew that they lost their ability to assert against x265 licensees when they made the contribution... if they wanted to assert the patent they wouldn't have contributed to the project
2013-08-02 23:47:24 < MCW> This isn't like MPEG contributors hoping to become part of the standard so that they can become part of the valuable patent pool... quite the opposite, in fact
2013-08-02 23:51:31 < MCW> Got to go... meeting an old friend for dinner at that German restaurant in Redwood City where the Apple engineer lost his pre-release iPhone a few years ago (Gourmet Haus Staudt).
2013-08-02 23:52:32 < MCW> Ever since that story came out, I've been meaning to check that place out..
2013-08-02 23:52:53 < koda> see if they marked the place where it got lost :p
2013-08-02 23:53:53 < MCW> will do.  I'm sure it hasn't hurt their business.  No such thing as bad PR, especially if you weren't the bad guy.
--- Day changed Sat Aug 03 2013
2013-08-03 06:42:59 < easyfab> comptoir info
2013-08-03 06:43:26 < easyfab> oups
2013-08-03 18:47:40 < Shiz> /ms/w 26
2013-08-03 18:47:44 < Shiz> Disregard.
--- Day changed Sun Aug 04 2013
--- Day changed Mon Aug 05 2013
2013-08-05 12:03:03 < gnaggnoyil> no "install" instruction in x265 makefile generated by cmake?
2013-08-05 12:03:40 < gnaggnoyil> what libraries and headers should i copy to install the whole x265?
2013-08-05 21:48:42 < muggs_> j-b: ping
2013-08-05 21:49:36 < j-b> pong
2013-08-05 21:49:41 < j-b> but going to bed soon
2013-08-05 21:49:49 < j-b> and I'm afraid you need thresh
2013-08-05 21:52:23 < muggs_> ok, just sent an email. it's close
2013-08-05 21:52:44 < j-b> because there is no repo yet :)
2013-08-05 21:52:48 < j-b> you need to push one
2013-08-05 21:52:48 < muggs_> hah
2013-08-05 21:52:55 < muggs_> ok.  I think I can do that
2013-08-05 21:53:06 < j-b> I don't know how to do one in hg (yet)
2013-08-05 21:53:23 < j-b> I still understand nothing on hg (wtf is hg parents and hg tip?)
2013-08-05 21:53:27 < j-b> but I will learn
2013-08-05 21:53:29 < j-b> seems fun
2013-08-05 21:53:49 < muggs_> access denied
2013-08-05 21:54:04 < j-b> ok
2013-08-05 21:54:22 < j-b> Can you tell me what command you used and I'll see with thresh when he wakes up?
2013-08-05 21:54:37 < muggs_> I'll email it
2013-08-05 21:56:44 < muggs_> ok, sent
2013-08-05 23:32:10 <@muggs> how does x264 use AVX2 with FENC_STRIDE 16?  does it not use aligned loads?
2013-08-05 23:41:34 <@Skyler_> FENC is only 16 pixels wide
2013-08-05 23:41:56 <@Skyler_> in x264, "aligned" means "aligned to the size of the load"
2013-08-05 23:42:01 <@Skyler_> it's only 16 pixels wide, so it only needs to be aligned to 16
--- Day changed Tue Aug 06 2013
2013-08-06 00:18:13 <@muggs> got it, so you only need to use the 256 bit aligned loads
2013-08-06 00:18:20 <@muggs> sorry, 128
2013-08-06 00:21:30 <@Skyler_> you can also cheat and load two lines at once
2013-08-06 00:21:34 <@Skyler_> since they're adjacent
2013-08-06 00:21:39 <@Skyler_> (useful in a couple places)
2013-08-06 00:21:51 <@Skyler_> of course, x265 won't work the same way for obvious reasons
2013-08-06 00:21:55 <@Skyler_> (larger supermb size)
2013-08-06 00:29:05 <@muggs> that's a good way to use AVX2 for 16 wide and smaller, though
2013-08-06 00:29:28 <@Skyler_> yeah, you can do multiple rows in one register, that's just an extra shortcut to make loading them easier
2013-08-06 00:31:07 <@muggs> just ran into a haswell crash with 32x32 on AVX2.  I think th efencstride is only aligned to 16 bytes sometimes
2013-08-06 00:33:45 <@Skyler_> well, make sure you align it properly!
2013-08-06 00:33:56 <@Skyler_> ALIGNED_32() in the struct, and making sure your malloc aligns to 32
2013-08-06 07:19:07 < sumalatha> hi
2013-08-06 07:20:56 < sumalatha> we are planning to implement ABR (one pass) in x265, so if any of you can help us or point us to the x264 source code(module) which actually does ABR, it wud be helpful
2013-08-06 07:28:51 < JEEB> I would rather begin with a crf-like rate control mode first, but I would most probably start reading around here http://git.videolan.org/?p=x264.git;a=blob;f=encoder/ratecontrol.c;h=d8cec78403a3fd18480096a1bac25173528ba7bb;hb=HEAD#l197
2013-08-06 07:29:39 < JEEB> most of the rate control code seems to be in that file
2013-08-06 07:30:50 < JEEB> (encoder/ratecontrol.c|h)
2013-08-06 07:36:25 < sumalatha> yea we are checking out the ratecontrol.c already.. looking for the exact place where the qps are being set for each frame depending on the cost and bits targeted for that frame
2013-08-06 07:36:33 <@Skyler_> yeah, I agree, CRF is probably more important than ABR, ABR is just modulating CRF
2013-08-06 07:36:37 <@Skyler_> or, more precisely, I'd say
2013-08-06 07:36:45 <@Skyler_> CRF is more important than 2-pass, 2-pass is more important than 1-pass ABR
2013-08-06 07:36:49 <@Skyler_> because almost nobody uses 1-pass ABR
2013-08-06 07:37:05 <@Skyler_> so if anything, ABR could really come last.
2013-08-06 07:37:29 <@Skyler_> I'll warn you, ratecontrol.c is a little bit of "layers upon layers" with new code stacked upon old.  but you should mostly just be able to copy it, really
2013-08-06 07:38:07 <@Skyler_> http://akuvian.org/src/x264/ratecontrol.txt   <-- this is a (very old) document on ratecontrol
2013-08-06 07:38:25 <@Skyler_> i.e. pre-AQ, pre-mbtree, pre-good-VBV
2013-08-06 07:38:47 <@Skyler_> oh.  doc/ratecontrol.txt is more up to date, I think
2013-08-06 07:38:50 <@Skyler_> in x264's tree
2013-08-06 07:39:09  * Skyler_ sleeps
2013-08-06 09:21:52 < sumalatha> thakns..
2013-08-06 09:22:06 < sumalatha> got an idea abt ABR now..from the code..
2013-08-06 09:22:39 < sumalatha> can u tell us abt the lookahead - where it is being done in x264?  is it done jsut before each frame is encoded in the loop ..ot even before that
--- Day changed Wed Aug 07 2013
2013-08-07 17:53:44 < greenfountain> hi i am looking into the ratecontrol.c of x264.. can anyoe explain the rate_estimate_qscale()  - how does it calculate the bits and qp for single pass ABR alone. m not turning any other params on.
2013-08-07 17:54:01 < greenfountain> --bitrate 1000 -o <output> <input>
2013-08-07 17:54:07 < greenfountain> is how i am running it
2013-08-07 17:54:48 < greenfountain> most of the inner details is harder to trace for me.. i am interesting in learning the exact algorithm its using
2013-08-07 17:58:46 < greenfountain> that is the function where the qp is being set for each frame based on the bits used so far , i guess..
2013-08-07 17:59:45 < BugMaster> it is reactionary algorithm based on statistics from before. I would say take closer look at rc->cplxr_sum and rc->wanted_bits_window variables
2013-08-07 18:01:39 < greenfountain> yea i saw those.. will trace them and check. besides, is there any documentation anywre that gives more info
2013-08-07 18:01:54 < greenfountain> exactly into the code itself
2013-08-07 18:03:09 < BugMaster> I suppose you already read doc\ratecontrol.txt
2013-08-07 18:06:07 < greenfountain> yes but its a bit tricky to uderstand what some of those vars are for.. for eg.. in the case of BFrames.. its trying to take avg qp of nearest 2 frames on either side and arrive at a figure accordingly.
2013-08-07 18:06:36 < greenfountain> durign that computation.. abs(h->fenc->i_poc - h->fref_nearest[0]->i_poc);, what is the i_poc used for
2013-08-07 18:06:48 < greenfountain> m trying rewrite the logic in x265
2013-08-07 18:07:04 < greenfountain> so trying to dig through each line of the code
2013-08-07 18:07:07 < BugMaster> yes. bframes qp-s are based on near frames (references) not by bitrate limits
2013-08-07 18:07:49 < BugMaster> poc is picture order count
2013-08-07 18:08:45 < BugMaster> iirc for cfr and progressive encode it would be presentation order number * 2
2013-08-07 18:09:41 < BugMaster> so poc difference is to find out distance in presentation order between frames
2013-08-07 18:10:37 < greenfountain> ok and the rcc->pb_offset -how do you set that..
2013-08-07 18:11:12 < greenfountain> is it some offset for pframes?
2013-08-07 18:11:44 < BugMaster> it is scaled --pbratio
2013-08-07 18:12:18 < BugMaster> i.e. QP bias to B-frames in compare to P-frames
2013-08-07 18:12:47 < greenfountain> so its set in the init of ratecontrol object..common for all frames right
2013-08-07 18:13:30 < BugMaster> yes. it is global value: rc->pb_offset = 6.0 * log2f( h->param.rc.f_pb_factor );
2013-08-07 18:14:08 < greenfountain> ah ok thanks
--- Day changed Thu Aug 08 2013
2013-08-08 09:17:53 < greenfountain> hi, can anyone explain a bit abt the concept of pulldown? what is timebase_num and timebase_dem.. how is it set up
2013-08-08 09:24:13 < greenfountain> is it the just inverse of framerate..time taken to display 1 frame in the input video..
2013-08-08 18:16:38 < JEEB> greenfountain, the pulldown in x264 is basically for adding metadata that has the player create extra pictures in order to hit another rate
2013-08-08 18:17:55 < JEEB> it's used for example for encoding 24/1.001 pictures per second for something that "needs" 30/1.001 or 60/1.001 pictures per second (it's been used from the ages of DVDs and such from MPEG-2 Video)
2013-08-08 18:18:07 < JEEB> still used in digital TV for example
2013-08-08 18:23:25 < greenfountain> i see..its turned on by the user through an input param option i guess
2013-08-08 18:24:54 < JEEB> the api lets you set arbitrary picture doubling, while x264cli has an option that sets the most used types of pulldown
2013-08-08 18:27:12 < JEEB> and I haven't looked at the code, but timebase is basically the amount of time in a single tick 1001/24000 for example would make then a timestamp of 1 be at 1001/24000, and 2 would be 2002/24000 and so forth (if I recall correctly)
2013-08-08 18:27:41 < JEEB> basically sets the granularity of the timestamps
2013-08-08 18:35:25 < greenfountain> oh i chked the code.. in the parse method - where it parses input options to param structure..i saw sth like  info.timebase_num = info.fps_den;         info.timebase_den = info.fps_num;..and  i am not setting any timebase option in x264cli
2013-08-08 18:35:51 < greenfountain> in this case, i assmed.. it just takes it as an inverse of frame rate..
2013-08-08 18:36:30 < JEEB> yes, for example constant rate 25fps would end up being 1/25 methinks
2013-08-08 18:37:09 < JEEB> don't remember what x264 does with VFR
2013-08-08 18:37:29 < JEEB> although I know you can *set* the timebase for such cases with VFR where you want to limit the timestamp granularity
2013-08-08 18:38:25 < greenfountain> okk
2013-08-08 19:07:46 < greenfountain> one more question -  abt rate tolerance..it is the extent of deviation that is allowed for overflow or underflow of bitrate?
2013-08-08 19:08:31 < JEEB> yes, in simple terms
2013-08-08 19:08:50 < greenfountain> is it always preset to .01?
2013-08-08 19:09:09 < JEEB> looking at the x264cli, --ratetol <float>       Tolerance of ABR ratecontrol and VBV [1.0]
2013-08-08 19:09:45 < JEEB> also the x264 settings wiki page is surprisingly OK explanation-wise on ratetol http://mewiki.project357.com/wiki/X264_Settings#ratetol
2013-08-08 19:20:09 < greenfountain> ok, got it.. if u set it to a higher level, abr_buffer will increase accordingly and qp getting set wont get too high if there is too much of a over/underflow
2013-08-08 19:20:57 < BugMaster> it is NOT how much it can overfkiw or underflow if you think about such things as VBV
2013-08-08 19:21:07 < JEEB> yeah
2013-08-08 19:21:15 < JEEB> VBV changes its workings
2013-08-08 19:22:00 < BugMaster> it more about how aggresive you want to hit *average* target bitrate
2013-08-08 19:22:37 < BugMaster> i.e. it is the option which is better to keep at default and don't mess with it
2013-08-08 19:23:08 < greenfountain> ok
--- Day changed Fri Aug 09 2013
2013-08-09 13:51:33 < greenfountain> hi i am using windows and trying to build x264 with ICL .. i am following this http://software.intel.com/en-us/articles/building-x264-with-intel-compiler-for-windows document
2013-08-09 13:52:04 < greenfountain> in the last step, when i make , i get this error x264res.rc(61) : error RC2104 : undefined keyword or key name: X264_POINTVER make: *** [x264res.o] Error 1
2013-08-09 13:52:13 < greenfountain> how can i fix this
2013-08-09 13:53:29 < JEEBsv> hmm
2013-08-09 13:53:52 < JEEBsv> I think Daemon404 said something about having to patch x264 a bit to have it build with Intel C
2013-08-09 13:54:08 < JEEBsv> I just left my copy installing when I left home, I'll try myself after I get home I guess
2013-08-09 13:54:53 < JEEBsv> that define lacking error seems like something rather simple tho
2013-08-09 13:55:44 < greenfountain> ok, thaks.. what time ull go back :0
2013-08-09 13:56:55 < JEEBsv> in a few hours most probably
2013-08-09 13:57:07 < JEEBsv> might be that Daemon404 will wake up before that
2013-08-09 13:58:34 < greenfountain> ok is this relevant to this case? http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=1c7dbec5f17ee091bae445584a4f05783e4aae9e
2013-08-09 14:12:16 < JEEBsv> not sure, since most includes should have been changed accordingly as well
2013-08-09 14:14:27 < nevcairiel> you did run configure before, right? :d
2013-08-09 14:32:33 < greenfountain> yes yes :P
2013-08-09 14:33:50 < greenfountain>  make Makefile:270: Extraneous text after `else' directive Makefile:280: Extraneous text after `else' directive rc -I. -I./extras -fox264res.o x264res.rc Microsoft (R) Windows (R) Resource Compiler Version 6.2.9200.16384 Copyright (C) Microsoft Corporation.  All rights reserved.  icl -DNDEBUG -O3 -W0 -I. -I. -Qstd=c99 -nologo -Qms0 -DHAVE_STRING_H -I./extras  -c -Fox264.o x264.c x264.c x264.c(401): error: identifier "X264_VERSIO
2013-08-09 14:35:40 < greenfountain> i got the error in x264res.rc first.. then i just tried to put that x264_POINTVER in quotes.. as expected it bombed elsewre.
2013-08-09 15:41:08 <@muggs> does CRF imply adaptive QP, or are they somewhat orthogonal?
2013-08-09 15:49:00 < JEEBsv> yes, the QP does change in CRF
2013-08-09 16:35:02 < Daemon404> [09:53] < JEEBsv> I think Daemon404 said something about having to patch x264 a bit to have it build with Intel C <-- the patch was only for linking to icl-built ffmpeg and ffms2
2013-08-09 16:35:13 < JEEBsv> ah
2013-08-09 16:50:42 < greenfountain> oh so how can i solve this issue
2013-08-09 17:31:19 <@muggs> JEEBsv: I meant does QP change within each block or just at the frame level?
2013-08-09 17:58:45 < Daemon404> Gramner, it Just Works here.
2013-08-09 17:58:56 < Daemon404> with xe 13.10
2013-08-09 17:59:16 < Daemon404> oh he left and tab completion failed
2013-08-09 18:01:32 < JEEB> yeah
2013-08-09 18:22:50 < JEEB> and yeah
2013-08-09 18:22:50 < JEEB> x264 0.135.2345 f0c1c53
2013-08-09 18:22:50 < JEEB> built on Aug  9 2013, intel: 13.10 (20130607)
2013-08-09 18:22:55 < JEEB> WorksForMe
2013-08-09 18:30:14 < Daemon404> indeed
2013-08-09 19:18:17 <@Skyler_> muggs:
2013-08-09 19:18:26 <@Skyler_> CRF = CQP + AQ + (MBtree or qcomp)
2013-08-09 19:18:28 <@Skyler_> or equally
2013-08-09 19:18:36 <@Skyler_> CRF = CQP + (spatial adaptive quant) + (temporal adaptive quant)
2013-08-09 19:18:47 <@Skyler_> qcomp is the simpler temporal adaptive quant: a per-frame offset based on relative overall complexity
2013-08-09 19:18:52 <@Skyler_> mbtree is a smarter, more complex one
2013-08-09 20:06:57 <@muggs> ok, thanks
2013-08-09 20:56:18 <@Skyler_> originally (per the older ratecontrol docs) CRF = CQP + qcomp
--- Day changed Sat Aug 10 2013
--- Day changed Sun Aug 11 2013
2013-08-11 04:44:43 < bookz_> they say Great Gatsby has great picture detail, resolution, and cinematography
2013-08-11 14:27:07 < kierank> bookz_: not really. it's on a red epic which isn't a very good camera
2013-08-11 16:02:32 < Mandarinka> http://lists.libav.org/pipermail/libav-devel/2013-August/049750.html
2013-08-11 17:00:01 < bookz_> hmmmm
--- Day changed Mon Aug 12 2013
2013-08-12 05:19:05 <@muggs> Hi everyone, I'll be in Chennai for the next 10 days, so my hours are shifted
2013-08-12 05:37:17 <@muggs> j-b: ping
2013-08-12 05:39:02 <@muggs> patchworks is barfing on me
2013-08-12 08:13:25 <@muggs> if anyone is interested in full-time paid HEVC work, please contact me.
2013-08-12 09:42:36 < greenfountain> hi can someone brief me abt the mbtree option pls? from the wiki , i see it "improves the compression by keeping track of temporal propagation across frames and weighting accordingly"
2013-08-12 09:42:48 < greenfountain> can anyone explain a lil bit more on this
2013-08-12 09:43:45 < nevcairiel> i think you want #x264
2013-08-12 09:50:27 < JEEB> the original commit message in x264 from 2009 doesn't exactly tell you much more if you couldn't grasp it from the other source :P http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=bb66c482242a0747823661b212114c1a2f015fe3
2013-08-12 09:51:13 < nevcairiel> that commit message needs newlines
2013-08-12 09:51:30 < nevcairiel> looks like svn style commit :p
2013-08-12 09:52:20 <@Skyler_> greenfountain: do you want the paper
2013-08-12 09:52:47 < greenfountain> yes
2013-08-12 09:53:33 <@Skyler_> Um... geez, does x264.nl still have those mirrors up?  I forgot where I last put it...
2013-08-12 09:54:06 < nevcairiel> http://mirror01.x264.nl/ should still work
2013-08-12 09:54:44 < nevcairiel> not sure if it includes what you're looking for
2013-08-12 09:55:30  * Skyler_ uploads it to a random file sharing site
2013-08-12 09:55:40 <@Skyler_> greenfountain: http://www.filedropper.com/mbtreepaper
2013-08-12 10:00:04 < greenfountain> i guess its the same one..http://x264.nl/developers/Dark_Shikari/MBtree%20paper.pdf
2013-08-12 10:00:31 <@Skyler_> Oh, yeah, it's that.
2013-08-12 10:00:37 < JEEB> yup
2013-08-12 10:00:38 < greenfountain> ok thanks . ll take a look
2013-08-12 10:00:52 < JEEB> didn't think the main domain would still be up ^^;
2013-08-12 11:34:45 < greenfountain> hey , in the x264_frame struct - whats the difference betn i_poc and i_frame? i_poc = picture order count = presentation/display order.
2013-08-12 11:35:21 < greenfountain> i_frame is different?
2013-08-12 11:38:40 < JEEB> I would guess it's the input frame number? Looking at the definition quickly seems like that
2013-08-12 11:46:26 < greenfountain> poc is repetitive within every lookahead widow.. and i_frame value is an absolute value of the frame within a video denoting its display order
2013-08-12 11:46:42 < JEEB> yes
2013-08-12 11:46:50 < JEEB> I wouldn't be surprised if that was the case
2013-08-12 11:46:56 < JEEB> either within a GOP or lookahead or whatever :)
2013-08-12 11:54:06 < kierank> poc is what is written to the bitstream
2013-08-12 11:54:13 < JEEB> yeh
2013-08-12 11:54:19 < kierank> and has to increment by 2 to allow for fields
2013-08-12 11:54:30 < kierank> i'm not sure if they kept that or dropped the +2 inrement in hevc
2013-08-12 12:14:05 <@muggs> I've not seen POC increment by two with hevc
2013-08-12 12:14:42 <@muggs> then again, I've not seen streams with the interlaced flag set to 1
2013-08-12 19:58:36 < j-b> muggs?
--- Day changed Tue Aug 13 2013
2013-08-13 17:40:06 < greenfountain> hi .. the difference between the crf option(with mb-tree OFF)  and mbtree -ON option is that crf uses Adaptive quantization and arrives at a qp for each frame as whole. and mb -tree uses lookahead to further adjust qp between differnnt Macro blocks in a frame.. am i correct?
2013-08-13 17:53:25 <@Skyler_> greenfountain: no
2013-08-13 17:53:32 <@Skyler_> CRF without mbtree = CQP + AQ + QCOMP
2013-08-13 17:53:39 <@Skyler_> CRF with mbtree = CQP + AQ + MBTREE
2013-08-13 17:53:41 <@Skyler_> AQ is in both.
2013-08-13 17:53:50 <@Skyler_> qcomp is a per-frame quantizer offset.  MBtree is per-MB.
2013-08-13 18:28:08 < greenfountain> ok thanks. how does AQ differ from MB tree.. AQ also increases / decreases the qp in different segments of the frame depending on the complexity.. MBTREE does the same as AQ + increases QP for those MBs in frame which are referenced higher in future frames etc - which it gets from lookahead?
2013-08-13 18:28:47 <@Skyler_> AQ adjusts each macroblock's QP based on C * log2(variance)
2013-08-13 18:28:56 <@Skyler_> that is, based on spatial complexity
2013-08-13 18:29:08 <@Skyler_> mbtree adjusts each macroblock's QP based on how much it's referenced in future frames
2013-08-13 18:29:12 <@Skyler_> i.e. temporal complexity
2013-08-13 18:29:36 < greenfountain> yes ok, thought so.. thanks
2013-08-13 18:30:44 < greenfountain> so crf with MB tree mostly gives better results than CRF without MBtree.. but may cost in performance
2013-08-13 18:32:18 <@Skyler_> mbtree has a very small performance penalty -- the main reason the old mode is kept around is the absolute fastest speed modes, and /lower latency/
2013-08-13 18:32:33 <@Skyler_> as mbtree requires a big lookahead to be useful
2013-08-13 18:33:00 < greenfountain> i see.. ok
2013-08-13 18:46:34 < someday>  CBR = CQP + AQ + MBTREE + VBV  ?  we give up qp to maintain vbv?
2013-08-13 18:48:26 <@Skyler_> well, a little more specific
2013-08-13 18:48:40 <@Skyler_> CRF + VBV = CQP + AQ + MBTREE + VBV ("capped CRF")
2013-08-13 18:49:06 <@Skyler_> i.e. "there is a maximum quality, but not a minimum quality"
2013-08-13 18:49:21 <@Skyler_> CBR = pure VBV, i.e. "no maximum quality, no mimum quality"
2013-08-13 18:49:29 <@Skyler_> *minimum
2013-08-13 18:49:45 <@Skyler_> so, CRF + VBV + min_rate
2013-08-13 18:50:00 <@Skyler_> rc->b_vbv_min_rate
2013-08-13 18:50:15 <@Skyler_> well, it's not really CRF at all like I said, so
2013-08-13 18:50:51 <@Skyler_> min_rate, though, means that if the VBV is nearly full and x264 is wasting bits, it will intentionally spend more bits, regardless of what the rest of ratecontrol things
2013-08-13 18:51:03 <@Skyler_> naturally this is what you want in CBR; you don't want to throw away unused bits
2013-08-13 18:51:28 <@Skyler_> this is in constrast to CRF+VBV, or ABR+VBV, which wouldn't do that.
2013-08-13 18:51:48 <@Skyler_> so effectively, x264 has three real modes: CRF, ABR, CBR
2013-08-13 18:52:22 <@Skyler_> CRF is the simplest.  ABR is kind of like CRF, but modulates the ratefactor to reach a target bitrate.  2-pass ABR is the same, except that it uses the first pass stats.  CBR is pure VBV, without a maximum quality limit (CRF)
2013-08-13 18:53:32 <@Skyler_> in terms of implementation, VBV can probably come later in x265, because it will be tricky; in x264, VBV works in part by adjusting QPs per-row.  it doesn't have to be per-row (it can be any reasonable gruoping), but naturally that ties in somehow to multithreading, wavefront, and so on.
2013-08-13 18:53:51 <@Skyler_> you can implement VBV without the per-row, and it will work, just not as well.
2013-08-13 19:18:27 < someday> ok!..got that.  will ABR come before CBR ? will it be same as CBR in terms of adjusting qp's per row , grouping
2013-08-13 19:36:24 <@Skyler_> only VBV requires adjusting QPs per row
2013-08-13 19:36:33 <@Skyler_> ABR does not, but I don't think ABR is a very important mode.
2013-08-13 19:36:42 <@Skyler_> most people who use ABR use the 2-pass variant
2013-08-13 19:36:47 <@Skyler_> almost nobody uses 1-pass ABR.
2013-08-13 19:52:28 < someday> is it not  ABR 1-pass better than CBR-1 pass in terms of quality? since most streaming is based on burst mode ABR 1 pass would work better ? why is CBR-1 pass preferred ?
2013-08-13 19:53:59 <@Skyler_> what do you mean by "most streaming is based on burst mode"?
2013-08-13 19:54:25 <@Skyler_> ABR is not suitable for streaming because in streaming, your limitation is the bandwidth, and ABR does not enforce any bandwidth limitations.  That's what VBV is for.
2013-08-13 19:55:09 <@Skyler_> this leaves three options for streaming: ABR+VBV, CRF+VBV, and CBR
2013-08-13 19:55:27 <@Skyler_> CBR is suitable when there is no reason to use less than the maximum bandwidth at all times (e.g. broadcast television)
2013-08-13 19:55:44 <@Skyler_> CRF is suitable for the rest of the applications, because in those cases, you just want to save bandwidth when the full maximum bitrate isn't necessary.
2013-08-13 19:56:06 <@Skyler_> ABR doesn't make sense, because you don't care about having a specific file size in a streaming video.
2013-08-13 19:57:49 < someday> most streaming is based on burst mode => like tcp based : apple hls ,dash, adobe/microsoft hls, pseudo streaming.
2013-08-13 19:59:37 < kierank> ^ what someday said
2013-08-13 19:59:43 < kierank> that is why MCW are working on ABR
2013-08-13 19:59:49 < kierank> because tcp streaming uses it
2013-08-13 19:59:56 < kierank> and you don't have to bother with vbv
2013-08-13 20:01:46 < someday> yeah... ABR+VBV => will this be better than CBR ?
2013-08-13 20:04:09 < someday> better => do we get better quality .
2013-08-13 20:09:33 <@Skyler_> kierank: ABR is still not suitable for pseudo streaming
2013-08-13 20:09:55 < kierank> it is these days because the whole chunk is downloaded
2013-08-13 20:09:58 <@Skyler_> ex: a movie where the first half is low complexity and the second half is high complexity
2013-08-13 20:09:59 < kierank> and the chunks are fixed size
2013-08-13 20:10:02 <@Skyler_> and your bandwidth is 2mbps
2013-08-13 20:10:15 <@Skyler_> for the first half it goes at 1mbps, then it streams at 3mbps for the entire second half of the movie
2013-08-13 20:10:21 <@Skyler_> and it fails
2013-08-13 20:10:29 < kierank> yes the chunks are encoded
2013-08-13 20:10:32 < kierank> using abr
2013-08-13 20:10:35 <@Skyler_> huh?
2013-08-13 20:10:47 < Daemon404> abr on a per-chunk basis
2013-08-13 20:10:51 < kierank> http "streaming" uses chunks these days
2013-08-13 20:10:54 < Daemon404> average for that chunk
2013-08-13 20:10:54 <@Skyler_> Um, yes, I know
2013-08-13 20:10:58 < kierank> it is not the http streaming of yesteryear
2013-08-13 20:11:07 <@Skyler_> you divide the video output by the encoder into chunks
2013-08-13 20:11:10 < kierank> no
2013-08-13 20:11:17 < kierank> you encode each chunk individually using abr
2013-08-13 20:11:19 <@Skyler_> that's insane
2013-08-13 20:11:24 <@Skyler_> nobody does that
2013-08-13 20:11:28 < kierank> yes they do
2013-08-13 20:11:29 < kierank> HDS
2013-08-13 20:11:32 <@Skyler_> not to mention it will break with mb-tree
2013-08-13 20:11:35 < kierank> dynamic streaming
2013-08-13 20:11:38 < kierank> all do things like
2013-08-13 20:11:39 < kierank> that
2013-08-13 20:11:48 < kierank> that's why everyone wants fixed i-frames amongst different resolutions
2013-08-13 20:11:57 <@Skyler_> ??? but those people aren't encoding each chunk separately
2013-08-13 20:12:05 <@Skyler_> they're telling x264 to force I-frames at particular points
2013-08-13 20:12:08 <@Skyler_> so that they can /divide it into chunks after/
2013-08-13 20:12:13 <@Skyler_> they don't shut down x264 after every single I-frame
2013-08-13 20:12:21 <@Skyler_> if they did, they wouldn't need to ask for fixed I-frames
2013-08-13 20:12:31 <@Skyler_> because it would already have them by definition
2013-08-13 20:12:50 < kierank> they do that because the segmenter doesn't understand scenecut i-frames
2013-08-13 20:13:00 <@Skyler_> No, they just turn off scenecut
2013-08-13 20:13:17 < kierank> how does adaptive bitrate work then?
2013-08-13 20:13:36 < kierank> people encode fixed size chunks afaik
2013-08-13 20:13:39 <@Skyler_> They encode multiple x264 instances simultaneuosly at different bitrates, and send each client chunks from the appropriate stream
2013-08-13 20:13:48 <@Skyler_> they do not terminate x264 after every chunk
2013-08-13 20:13:59 <@Skyler_> the latter would not even work, because x264's ABR does not work over such short windows
2013-08-13 20:14:02 <@Skyler_> it would go haywire
2013-08-13 20:14:05 < kierank> 10s is quite long
2013-08-13 20:14:19 <@Skyler_> you underestimate how bad x264's ABR is
2013-08-13 20:14:50 < kierank> then in your 2mbit film where the first part is 1mbit and the second is 3mbit then the second part won't load
2013-08-13 20:14:59 <@Skyler_> huh?
2013-08-13 20:15:07 < kierank> if the connection speed is 2mbit
2013-08-13 20:15:09 <@Skyler_> but you just said they weren't doing that.
2013-08-13 20:15:15 < kierank> that's what you're saying
2013-08-13 20:15:17 <@Skyler_> Um, no I'm not.
2013-08-13 20:15:21 <@Skyler_> I'm saying they use VBV, like everyone else.
2013-08-13 20:15:32 < kierank> web people don't use vbv
2013-08-13 20:15:35 < Daemon404> yes
2013-08-13 20:15:36 <@Skyler_> And to compensate for the weird way chunking works, they use a VBV much shorter than the chunk size
2013-08-13 20:15:36 < Daemon404> we do.
2013-08-13 20:15:40 < Daemon404> <-- web person
2013-08-13 20:15:43 <@Skyler_> trust me, I've consulted half a dozen times for these people
2013-08-13 20:15:45 < kierank> you are competent
2013-08-13 20:15:45 < Daemon404> not live, mind you.
2013-08-13 20:16:00 < kierank> look at all the guides for ffmpeg chunked encoding
2013-08-13 20:16:06 < Daemon404> id rather not
2013-08-13 20:16:10 <@Skyler_> yes, they involve piping an ffmpeg stream to segmenter
2013-08-13 20:16:15 <@Skyler_> and turning off scenecut, and forcing a specific keyint
2013-08-13 20:16:24 <@Skyler_> and then using an arbitrary VBV to try to make the chunks roughly the right size.
2013-08-13 20:16:48 <@Skyler_> now if you want to implement a per-chunk ABR ratecontrol mode in x264/x265, okay, that's toally not unreasonable at all, given it's what people want
2013-08-13 20:17:10 <@Skyler_> that'd be better than any of this
2013-08-13 20:17:22 <@Skyler_> but IMO that's a really specific use-case that comes later, after the basics are functional
2013-08-13 20:17:36 <@Skyler_> and, well, after someone implements H.265 with smooth streaming or whatever
2013-08-13 20:17:38 < kierank> not if MCW need to ship as soon as possible
2013-08-13 20:17:46 <@Skyler_> which browsers support H.265?!
2013-08-13 20:17:48 < Daemon404> [16:16] <@Skyler_> but IMO that's a really specific use-case that comes later, after the basics are functional <-- this is not how Corporate Entities think
2013-08-13 20:17:50 < kierank> none but it's marketing
2013-08-13 20:17:53 < Daemon404> you do whats marketabe
2013-08-13 20:17:55 < Daemon404> not whats useful
2013-08-13 20:17:56 < kierank> it's not for real use
2013-08-13 20:17:58 <@Skyler_> if it's marketing, they don't need to actually implemen it
2013-08-13 20:18:02 < kierank> they need to demo it
2013-08-13 20:18:08 <@Skyler_> you can demo it by just using VBV
2013-08-13 20:18:17 <@Skyler_> you don't need a specific chunked encoding mode to make a demo work
2013-08-13 20:19:33 <@Skyler_> (you don't want to know all the terrible demos I've implemented or seen implemented with completely non-functional features... :P)
2013-08-13 20:19:58 <@Skyler_> like, for example, the first demo of x264 for 1080i realtime broadcast encoding was done back in 2005
2013-08-13 20:20:12 <@Skyler_> this was done despite the fact that interlacing was not yet supported
2013-08-13 20:20:19 <@Skyler_> nor was x264 fast enough to encode 1920*1080 in real time.
2013-08-13 20:20:39 <@Skyler_> they encoded at 1920x540 knowing the STB would scale it up
2013-08-13 20:20:43 <@Skyler_> investors loved it.
2013-08-13 20:20:56 <@Skyler_> nobody knew, everyone was happy :p
2013-08-13 20:21:00 < kierank> 21:15:51 <•Skyler_> and then using an arbitrary VBV to try to make the chunks roughly the right size. --> that's a vbv = to chunk size
2013-08-13 20:21:03 < kierank> Skyler_: that's unethical imo
2013-08-13 20:21:12 <@Skyler_> kierank: it looked better than the hardware encoders at real 1080i
2013-08-13 20:21:35 <@Skyler_> either way, wasn't me who did that.  that was Avail XD
2013-08-13 20:22:23 <@Skyler_> kierank: the thing I remember people complaining about with vbv == chunk size was some chnks would be larger and some smaller
2013-08-13 20:22:46 <@Skyler_> e.g. if your chunk size was 10s, and your bandwidth was 1mbit, you could have a 15mbit chunk, then a 5mbit chunk
2013-08-13 20:23:11 <@Skyler_> anyways, sorry for going on about this.  if people need ABR, they need ABR, just copy in the x264 code and it'll probably do fine.
2013-08-13 20:23:26 < someday> if I remember test result : ABR+VBV performed better than CBR in x264.  are these results in sync with others result ?
2013-08-13 20:23:37 <@Skyler_> what do you mean by that?
2013-08-13 20:23:43 <@Skyler_> "CBR" in x264 is "ABR, with bitrate == maxrate"
2013-08-13 20:24:21 <@Skyler_> so it's impossible to set ABR+VBV (with the same VBV settings) without it being implicitly turned into CBR.
2013-08-13 20:24:43 <@Skyler_> (also, performed better in what way?  I mean, like, faster, or what?)
2013-08-13 20:27:17 < someday> it was in terms of PSNR, some frames higher PSNR , some did lower.
2013-08-13 20:27:36 < someday> on average ..there were more frames with higher PSNR.
2013-08-13 20:29:04 <@Skyler_> I'd have to know the specifics of the test to say anything, really :/
2013-08-13 20:29:18 <@Skyler_> e.g. what the VBV/ABR/CBR settings actually -were-
2013-08-13 20:31:04 < someday> it was while ago... but can run test again later...
--- Day changed Wed Aug 14 2013
2013-08-14 08:28:16 <@muggs> the clunky mini-gop encode cadence is finally gone, and lookahead is beginning to take shape
2013-08-14 09:04:23 < easyfab> muggs: for info with last source (52a709c )  http://pastebin.com/utYYtcee
2013-08-14 12:36:17 <@muggs> easyfab: yeah, sorry about that.  MSVC didn't try to build the new file the first 5 times I hit F7
2013-08-14 12:36:24 <@muggs> should be good now
2013-08-14 12:59:15 < easyfab> muggs: sill failed with e8a95b6 http://pastebin.com/mCzMXptE
2013-08-14 13:01:00 < easyfab> And I don't think F7 rebuilt  a proper project, I always use ctrl+alt+f7 to clear and rebuilt all the project
2013-08-14 13:07:41 < easyfab> It must be VS specific error because mingw build is OK
2013-08-14 13:11:15 <@muggs> wonder if it's vc10 specific.  vc11 builds just fine
2013-08-14 13:17:04 <@muggs> pushed a fix
2013-08-14 13:45:41 < easyfab> build with a506ed0  is ok for me with vc10, thanks .
--- Day changed Thu Aug 15 2013
--- Day changed Fri Aug 16 2013
2013-08-16 08:20:02 < j-b>  'morning
2013-08-16 09:21:08 <@muggs> hi j-b
2013-08-16 13:21:46 < JEEBsv> looking at the fact that every commit I've tried to compile today fails to compile for one reason or another
2013-08-16 13:21:54 < JEEBsv> I guess this project really needs a buildbot in the office
2013-08-16 13:22:29 < JEEBsv> that smacks a developer every time he breaks the build on one of the most common scenario build types
2013-08-16 13:31:26 < JEEBsv> stuff like wrong case used for headers in code (thisHeader.h instead of thisheader.h), or completely unused parameters in functions would not get unnoticed in that case :D
--- Day changed Sat Aug 17 2013
2013-08-17 14:40:36 < JEEB> Daiz, <mraulet> btw I have almost fixed 10bits <mraulet> sequences <mraulet> luma is correct <mraulet> chroma have some artifacts due to the deblocking filter
2013-08-17 14:58:55 < Daiz> neat
2013-08-17 15:01:51 < JEEB> meanwhile I'm trying to find out if I can get access to WG11's documents via SFS or Helsinki Uni :V getting tired of those GPAC bastards having a monopoly on 14496-15 amd2 related stuff
2013-08-17 15:40:28 < kurosu> are there still banding issues with hevc 8bits or is there another expected gain from 10bits ?
2013-08-17 15:43:13 < kurosu> JEEB / Daiz ?
2013-08-17 15:43:27 < Daiz> well in the current state x265 has lots of banding issues
2013-08-17 15:43:34 < Daiz> or at least last I tested
2013-08-17 15:43:40 < Daiz> I could give it a spin again later on
2013-08-17 15:43:49 < Daiz> though I have some encoding to do in an hour
2013-08-17 15:43:54 < Daiz> so gotta be after that at least
2013-08-17 15:46:18 < kurosu> was that with every tool turned on?
2013-08-17 15:46:37 < kurosu> it's just that some of the stuff h264 10bits was providing should supposedly no longer apply, so I'm wondering
2013-08-17 15:47:00 < Daiz> yeah I've read the same too
2013-08-17 15:47:29 < Daiz> and yeah I tried with pretty much all supposedly useful stuff turned on
2013-08-17 15:47:51 < kurosu> does x265 implement the bilinear stuff on intra prediction for 32x32 TUs? it was reported to sometimes fix that kind of issue
2013-08-17 15:48:07 < Daiz> http://check2pic.ru/compare/30357/5/
2013-08-17 15:48:13 < Daiz> that's how it ended up back then
2013-08-17 15:48:20 < Daiz> banding-wise
2013-08-17 15:49:33 < kurosu> have you tried using --strong-intra-smoothing ?
2013-08-17 15:49:51 < Daiz> don't think I had that, but I can give it a spin later
2013-08-17 15:50:57 < kurosu> http://phenix.int-evry.fr/jct/doc_end_user/documents/11_Shanghai/wg11/JCTVC-K0139-v1.zip <- I think you'd better try
2013-08-17 15:52:04 < Daiz> I'm not sure if x265 had the option when I did
2013-08-17 15:52:14 < Daiz> anyway, I'll build a new version from master later today
2013-08-17 15:52:26 < kurosu> no idea either, I have just checked that in the manual, having no idea either
2013-08-17 15:52:47 < Daiz> oh, looks like it is there, idk if it was turned on by default though
--- Day changed Sun Aug 18 2013
2013-08-18 13:47:03 < wiseeebou> hello, I'm encoding some DVD in x264 with avidemux but the pictures are not steady. Does anyone have knowledge in x264 ? I know it's x265 but maybe someone can help me
--- Day changed Mon Aug 19 2013
2013-08-19 04:20:12 <@muggs> good morning
2013-08-19 11:46:24 < greenfountain> in the rate control in x264, while calculating the qscale and conversion of qscale to qp and vice versa.. are those equations mapped to any specific area in H.264 spec? how was it deduced
--- Log closed Mon Aug 19 13:18:07 2013
--- Log opened Mon Aug 19 14:19:31 2013
2013-08-19 14:46:27 < j-b> muggs: ping
2013-08-19 14:50:35 < JEEBsv> he's not around?
2013-08-19 14:51:13 < j-b> sleeping, I guess :)
2013-08-19 14:51:33 < JEEBsv> yeh, most probably
2013-08-19 14:54:48 < j-b> http://hg.videolan.org/x265/
2013-08-19 15:00:54 <@Skyler_> 00:01 <@Skyler_> I don't know if greenfountain reads the logs, but those are defined by the spec, e.g. quantizer is proportional to qscale based on qp^(1/6)
2013-08-19 16:08:09 < greenfountain> @Skyler_ thanks. i am looking through T-REC-H.264-201201-S!!PDF-E trying to find out where they have specified it.. need to compare with HEVC for differences in the spec to tweak that function accordigly
2013-08-19 17:15:39 <@Skyler_> Look in the definition of how dequantization is defined
2013-08-19 17:27:56 < greenfountain> The scaling equations are specified such that the equivalent transform coefficient level scaling factor doubles for every increment of 6 in QPY. Thus, there is an increase in the factor used for scaling of approximately 12 % for each increase of 1 in the value of QPY.
2013-08-19 17:31:34 < greenfountain> it is a linear dependency - qscale to qp..not exponential - accordig to what is mentioned in the spec
2013-08-19 17:39:38 <@Skyler_> Huh?
2013-08-19 17:39:39 <@Skyler_> That's not linear.
2013-08-19 17:39:53 <@Skyler_> If X increases +Y% for each increase in Z, that is an exponential relationship between X and Z.
2013-08-19 17:40:10 <@Skyler_> That means X = C * Z ^ (1 + Y/100)
2013-08-19 17:41:40 <@Skyler_> "doubles every 6" is very much about the least linear thing I could possibly imagine
2013-08-19 18:02:47 < greenfountain> sry. my bad
2013-08-19 18:03:12 <@Skyler_> I'd /guess/ it's probably the same in H.265 as H.264 but I might be wrong
2013-08-19 19:57:27 < JEEB> http://randomascii.wordpress.com/2013/08/19/developers-rejoicewindows-7-stack-corruption-fixed/
--- Day changed Tue Aug 20 2013
2013-08-20 11:40:37 < greenfountain> @Skylar_ I cudnt' find the qscale dependency with Quantizer specified in HEVC standard.. so guess we can use the same as in x264.. but the initial value of the qscale for the 1st I frame ..
2013-08-20 11:40:38 < greenfountain> that is currently set with rceq equation and adjusted with rate factor  (depends on cplxr_sum) .. this is mentioned in the standards ?
2013-08-20 11:44:03 < greenfountain> Rate control as such is not defied in the specs and many are encoder related decisions.. so apart from scaling, which all factors/params  is obtained from the specs..
2013-08-20 11:45:36 < greenfountain> intial cplxrSum - set as  .01 * pow(7.0e5, qCompress) * pow(ncu, 0.5) , rc equation(blurcplx ^ 1-qcomp) -- all these are encoder related calculations only?
2013-08-20 11:46:05 <@Skyler_> qscale chosen for the first frame is completely arbitrary guesswork, so yeah
2013-08-20 11:46:09 <@Skyler_> and yes, that's all encoder calculations
2013-08-20 11:46:22 <@Skyler_> but if you can't find quantization in the HEVC spec, the HEVC spec sounds rather incomplete./
2013-08-20 11:47:43 <@Skyler_> most of the ABR/CRF-related calculations revolve around keeping a blurred moving average of frame complexity, according to some rules
2013-08-20 11:47:46 <@Skyler_> (qcomp only)
2013-08-20 11:47:53 <@Skyler_> with mbtree, qcomp is forced to 1
2013-08-20 11:48:00 <@Skyler_> therefore turning it off
2013-08-20 11:48:08 <@Skyler_> and not using that feature (since mbtree is used instead)
2013-08-20 11:50:31 <@Skyler_> for qscale, qscale is literally defined as a linear version of QP.  qscale is proportional to the number you divide by to quantize a DCT coefficient.
2013-08-20 11:50:46 <@Skyler_> if you can't find that inside the spec, I'm not sure how you could even write an encoder; quantization is a required part of the spec.
2013-08-20 11:51:16 <@Skyler_> or does x265 not do quantization, somehow?
2013-08-20 11:53:39 <@Skyler_> quant[x] = dct[x] / qscale // basically
2013-08-20 12:12:15 < greenfountain> they have a scaling array levelScale[ ] - specified as levelScale[ k ] = { 40, 45, 51, 57, 64, 72 } with k = 0..5. and
2013-08-20 12:12:17 < greenfountain> The scaled transform coefficient d[x ][ y ] is derived as follows:  d[ x ][ y ] = Clip3( −32768, 32767, ( ( TransCoeffLevel[ xTbY ][ yTbY ][ cIdx ][ x ][ y ] * m[ x ][ y ] *     levelScale[ qP%6 ] << (qP / 6 ) ) + ( 1 << ( bdShift −1 ) ) ) >> bdShift )
2013-08-20 12:19:35 <@Skyler_> Therefore qscale is proportional to levelscale[qp%6] << (qp/6), exactly the same as in h264.
2013-08-20 12:36:51 < greenfountain> yes, ok.   q = getQScale(wantedBitsWindow / cplxrSum);  - after deriving qscale for each frame based on its complexity, it is further adjusted by some rate factor - this is done, to increase/decrease qscale - according to excess/short of encoded bits from prev frame?
2013-08-20 12:52:18 <@Skyler_> you mean in ABR mode?  yes
2013-08-20 15:09:53 < JEEBsv> Daiz: <mraulet> elenril: 10bits is now fully working
2013-08-20 15:10:01 < Daiz> cool
2013-08-20 15:10:18 < Daiz> how bout the openhevc decoder?
2013-08-20 15:10:38 < Daiz> though I can obviously use HM if it doesn't, but it would be nice to have that work too
2013-08-20 15:10:44 < Daiz> I'll compile a new build later
2013-08-20 15:10:59 < JEEBsv> he's one of the openhevc dudes, they're trying to get the libavcodec decoder kind of finished
2013-08-20 15:11:09 < JEEBsv> also merged into libav
2013-08-20 15:11:18 < Daiz> oh so that's for decoding specifically?
2013-08-20 15:11:28 < Daiz> nice
2013-08-20 15:11:29 < JEEBsv> yeah
--- Day changed Wed Aug 21 2013
2013-08-21 22:18:31 < kache> Whoa, it really exists
2013-08-21 22:20:07 < Mandarinka> <kache> I am really curious to see the efficiency improvement of anime encoding between hi10 x264 and hi10 x265.
2013-08-21 22:20:23 < Mandarinka> that will ahve to wait, until x265 has the basic infrasturcture done
2013-08-21 22:20:52 < Mandarinka> it currently doesn't have the all-important rate control, and also adaptive quantization and psy RDO is missing
2013-08-21 22:21:06 < kache> Indeed. I wonder how much time it's gonna take, though. There are other h265 encoders already available
2013-08-21 22:22:10 < kierank> no there aren't
2013-08-21 22:22:23 < kierank> there are announcements of availability
2013-08-21 22:22:26 < kierank> which isn't the same
2013-08-21 22:23:24 < kache> strongene is available right now
2013-08-21 22:23:24 < kache> http://xhevc.com/en/downloads/downloadCenter.jsp
2013-08-21 22:23:38 < kierank> that's a pirated x264
2013-08-21 22:23:50 < kache> What do you mean?
2013-08-21 22:24:01 < kierank> they modified x264 and then called it x265 but haven't released source code
2013-08-21 22:24:11 < kierank> the decoder is ffmpeg
2013-08-21 22:24:15 < kierank> the encoder is x264
2013-08-21 22:24:21 < kierank> typical chinese nonsense
2013-08-21 22:24:30 < kache> so it's not hevc at all?
2013-08-21 22:24:33 < kierank> it is hevc
2013-08-21 22:24:41 < kierank> but it's a gpl violation
2013-08-21 22:25:15 < kache> Hmm, judging from the posts on doom9 it appears to produce quite bad results
2013-08-21 22:27:06 < kache> Ok, thanks for all the information ^^
2013-08-21 22:27:28 < kache> As of now, I don't really have any possibility of making a difference, so I guess i'll just stand by and watch how things turn out
2013-08-21 23:43:57 < kurosu> Daiz, have you tried the strong intra smoothing for your tests on anime content ?
--- Day changed Thu Aug 22 2013
2013-08-22 00:18:00 < Mandarinka> what does the feature do, btw?
--- Day changed Fri Aug 23 2013
2013-08-23 14:49:51 < kurosu> --sao-lcu-opt 0 => "SAO picture-based optimization"
2013-08-23 14:50:16 < kurosu> is that the old, deprecated, quadtree-based version of SAO?
2013-08-23 14:50:27 < kurosu> or a vitterbi-like optimization ?
2013-08-23 14:51:27 < kurosu> if the former, you can just drop it, and don't bother with the picture-based version: it's not in the specs and should probably be removed from HM12
2013-08-23 14:54:07 < kurosu> https://hevc.hhi.fraunhofer.de/trac/hevc/changeset/3543
--- Day changed Sat Aug 24 2013
--- Day changed Sun Aug 25 2013
2013-08-25 20:35:34 < JEEBsv> muggs: source/encoder/ratecontrol.cpp
2013-08-25 20:35:44 < JEEBsv> s/rateControl.h/ratecontrol.h/
2013-08-25 20:35:57 < JEEBsv> probably didn't pop up if you compiled only on windows
2013-08-25 22:13:09 <@muggs> JEEBsv: thanks
2013-08-25 22:16:53 <@muggs> kurosu_: we're reviewing the SAO changes in HM12 now.
2013-08-25 22:20:07 <@muggs> slice decisions, simple ABR rate control, and frame parallelism should all go live at various points this week
2013-08-25 22:20:12  * muggs crosses fingers
--- Day changed Mon Aug 26 2013
2013-08-26 07:56:47 < koda> so how are things here? :)
2013-08-26 08:22:24 < koda> i just got a /home/vittorio/x265/source/encoder/framefilter.cpp:39:18: error: 'FALSE' was not declared in this scope
2013-08-26 08:22:24 < koda>  :\
2013-08-26 08:22:55 < JEEB> haven't had that with my mingw cross-compiler at least, unless I didn't get there yet
2013-08-26 08:23:03  * JEEB goes check his atom laptop to see if it finished compiling
2013-08-26 08:23:27 < JEEB> nope, got a binary
2013-08-26 08:23:32 < koda> i'm not xcompiling just yet
2013-08-26 08:24:02 < koda> shouldn't it be false instead of FALSE? :\
2013-08-26 08:24:14 < JEEB> ah, there have been some more commits since
2013-08-26 08:24:25 < koda> yeah
2013-08-26 08:24:27 < koda> false works
2013-08-26 08:24:45 < JEEB> the last I grabbed was 55d7eda
2013-08-26 08:24:47 < JEEB> which fixes a problem I reported
2013-08-26 08:26:00 < koda> i'm on 3682:797c13ec5d2a
2013-08-26 08:28:51 < JEEB> x265 really needs a build bot kind of system that builds the most common setups
2013-08-26 08:29:13 < JEEB> even better if it happens in a gerrit-like environment before the main repository so those who fail it can be slapped
2013-08-26 08:30:00 < JEEB> muggs usually catches GCC/mingw things on windows, but for example it doesn't catch #include rateControl.h when the file is called ratecontrol.h. :)
2013-08-26 08:30:20 < koda> or FALSE/false apparently
2013-08-26 08:30:45 < JEEB> I wouldn't be surprised if muggs just didn't get to building that revision yet
2013-08-26 08:30:49 < JEEB> where that addition was made
2013-08-26 08:32:58 < koda> hm, i rebased a few commits in my repo i wonder what will happen with hg push -f...
2013-08-26 08:34:32  * koda goes for it
2013-08-26 08:37:31 < koda> i basically got a new branch without name
2013-08-26 08:37:34 < koda> aka head
2013-08-26 08:40:23 < koda> yay segfault on a 1920x1088 sequence
2013-08-26 08:43:17 < koda> on a 1920x1080 too
2013-08-26 08:44:18 < koda> also isn't 1080p50 a level 4.2? i get a "Main profile, Level-4.1 (Main tier)" reported
2013-08-26 08:46:05 < koda> Cannot find user-level thread for LWP 1506: generic error
2013-08-26 08:46:05 < koda>  :|
2013-08-26 08:53:52 < nevcairiel> personally i think trying to worry about all kind of build setups during early development is not so important
2013-08-26 08:53:55 < nevcairiel> rather get features done
2013-08-26 08:55:00 < JEEB> well, I would agree if there were actual features that would just not be available in other places
2013-08-26 08:55:15 < JEEB> and it would be a case of "we can then later use some system that is more cross-platform"
2013-08-26 08:55:26 < JEEB> but in general the stuff so far is just pure sloppiness
2013-08-26 08:56:40 < nevcairiel> thats the whole point, let them focus on writing feature code, not 100% perfect code style :p
2013-08-26 08:56:48 < nevcairiel> its still a very early development phase
2013-08-26 08:58:14 < JEEB> that's not what I'm asking, I'm just asking to help the coders do less errors that are really simple :P It really shouldn't take more than a minute generally to fix wrong casing and stuff like that
2013-08-26 08:59:03 < JEEB> also there are people who will never code stuff that will work properly on non-MS things unless forced to do it
2013-08-26 08:59:26 < nevcairiel> and if you want the thing to grow faster, you wont force them, but fix it later :p
2013-08-26 08:59:43 < JEEB> or just leave it as-is and have a MS-only product... right
2013-08-26 09:02:09 < JEEB> anyways, I do understand your point but on the other hand having testing around is always a good thing and helps the developers. Even if it doesn't stop them from pushing further code.
2013-08-26 09:02:12 < nevcairiel> thats the same problem many opensource projects have, especially libav, instead of appreciating contributions, the contributors get pestered with style choices, instead of someone just fixing it up later, and letting the contributor work on the actual feature
2013-08-26 09:02:24 < JEEB> I'm not on that level nev
2013-08-26 09:02:53 < koda> nevcairiel, well some code style is important for big projects
2013-08-26 09:02:54 < JEEB> I'm only speaking of "does it pass a sane amount of couple of compilers, one of which is on a *nix"
2013-08-26 09:03:07 < nevcairiel> i guess in this case its the dev's own fault if they hang on irc to let themself be pestered =p
2013-08-26 09:03:55 < nevcairiel> i dont know if they have a useful workflow yet for someone to contribute patches to fix such things themself, instead of asking a dev to do it
2013-08-26 09:04:01 < JEEB> no
2013-08-26 09:04:09 < JEEB> afaik the CLA is still not finished and all that jazz
2013-08-26 09:04:54 < JEEB> (Yes, there's a PDF on the repository's downloads, but IIRC people raised questions about it and it was taken back to editing)
2013-08-26 09:05:16 < JEEB> otherwise we would have already had patches from people
2013-08-26 09:05:36 < JEEB> like Shiz who poked stuff relatively early. Or that case fix I poked muggs about
2013-08-26 09:08:57 < JEEB> nevcairiel, also really for the record: I am *not* a Diego-type :P
2013-08-26 19:22:09 <@muggs> j-b: ping
2013-08-26 19:25:44 < j-b> muggs: pong
2013-08-26 19:26:12 <@muggs> Hi. Can you make nandaku2 an admin for our patchworks
2013-08-26 19:26:23 < j-b> I think so
2013-08-26 19:26:32 < j-b> muggs: did you psuh on hg.v.o ?
2013-08-26 19:26:51 <@muggs> yes, just a couple minutes ago in fact
2013-08-26 19:26:56 < j-b> ok
2013-08-26 19:27:08 < j-b> You allow anonymous commits?
2013-08-26 19:27:25 <@muggs> anonymous in what way?
2013-08-26 19:27:35 < j-b> people without complete name
2013-08-26 19:28:57 < j-b> nandaku2 has no profile
2013-08-26 19:29:02 <@muggs> we know who we all are internally
2013-08-26 19:29:54 < j-b> this is a public project, not an internal one, no?
2013-08-26 19:29:57 <@muggs> ah, nandaku is Deepthi Nandakumar.  She is the technical lead of the Chennai development team
2013-08-26 19:30:12 < j-b> praveentiwari is not a name
2013-08-26 19:30:41 <@muggs> that is his full name, missing a space
2013-08-26 19:30:54 < j-b> Deepthi is not a name
2013-08-26 19:31:02 < j-b> etc...
2013-08-26 19:31:15 < j-b> and "nandaku is Deepthi Nandakuma" has not created a patches profile
2013-08-26 19:31:41 < j-b> so I cannot make him/her admin
2013-08-26 19:31:43 <@muggs> nandaku2?
2013-08-26 19:32:24 < j-b> neither nandaku2, nor deepthi, nor Nandakuma
2013-08-26 19:32:49 <@muggs> ok; she told me she had.  I'll ask her to create a profile
2013-08-26 19:34:36 < j-b> And you should tell people to use their names for commiting
2013-08-26 19:34:46 < j-b> I'll set the hooks and the commits mailing lists
2013-08-26 19:34:58 <@muggs> sure
2013-08-26 19:37:07 <@muggs> I'll be in Paris Friday morning, but not much interested in theme parks.  Is there anything else going on?
2013-08-26 19:37:29 < j-b> not really
2013-08-26 19:37:36 < j-b> beers on friday night, I guess
2013-08-26 19:37:49 < j-b> muggs: can you do a small talk about x265 on sat morning?
2013-08-26 19:38:13 <@muggs> I assume the hotel has internet, so I'll be online.  my phone doesn't typically work in europe
2013-08-26 19:39:00 < j-b> the hotel has internet
2013-08-26 19:39:20 <@muggs> I can give a talk about what we've done the last 6 months.  What sort of audience will it be?
2013-08-26 19:39:40 < j-b> extremly technical
2013-08-26 19:39:47 < j-b> Most of libav team
2013-08-26 19:39:57 < j-b> 3 x264 developers
2013-08-26 19:40:01 < j-b> 8 FFmpeg developers
2013-08-26 19:40:08 < j-b> all but one VLC developers
2013-08-26 19:40:15 <@muggs> awesome
2013-08-26 19:40:16 < j-b> handbrake, Google and KDE devs
2013-08-26 19:41:03 < j-b> muggs: can you do 20-30 min on it?
2013-08-26 19:41:50 <@muggs> yeah, can I do a simple PPT or something?
2013-08-26 19:42:08 < j-b> sure, why not?
2013-08-26 19:42:33 <@muggs> I meant; will there be a projector or something similar?
2013-08-26 19:42:41 < j-b> Of course
2013-08-26 19:42:49 < j-b> We'll be in a Cinema :)
2013-08-26 19:43:09 <@muggs> that sounds like fun.
2013-08-26 19:43:49 <@muggs> there's every risk I'll write the talk on the plane and in the hotel on Friday, but 20-30 minutes should be easy to manage
2013-08-26 19:43:56 < j-b> talks will be on VP9, x265, codecs and DCP
2013-08-26 19:44:17 < Daemon404> "codecs" ?
2013-08-26 19:57:59 < smarter> j-b: what KDE devs are coming?
2013-08-26 20:44:03 < j-b> smarter: you'll see
2013-08-26 20:47:48 < kierank> Daemon404: kostya i guess
2013-08-26 20:54:03 < Daemon404> i thought soo too
2013-08-26 21:00:04 < koda> hi guys, what did i miss? :)
2013-08-26 21:01:39 <@muggs> there's a whole lot of hacking going on at the moment, but that's not what we talked about
2013-08-26 21:14:26 < koda> i've tried some encodings today and saw that x265 is VERY memory hungry
2013-08-26 21:14:48 < koda> like ~10GB of ram for a 1080p50 encoding at default config
2013-08-26 21:15:19 <@muggs> memory leak is fixed, so is a crash bug, but hashes are currently mismatching
2013-08-26 21:15:48 < koda> and also the final ouput crashed the HM
2013-08-26 21:16:00 < koda> although i could try version 10 only, not the latest
2013-08-26 21:16:17 <@muggs> HM 10 is buggy, suggest HM 11
2013-08-26 21:16:44 <@muggs> there's changes in HM 12 related to SAO we don't have yet.   hope to have that in a couple days
2013-08-26 21:17:09 < koda> are you going to present something at vdd or ibc?
2013-08-26 21:17:33 <@muggs> we're switching subpel plane generation to be row-based for frame parallelism, and it's currently busted
2013-08-26 21:18:04 <@muggs> I'll give a talk at VDD.  We'll be demoing at IBC, assuming I finish all this stuff
2013-08-26 21:19:06 <@Skyler_> generating subpel planes sounds like a bad idea; is it really faster?
2013-08-26 21:19:19 <@Skyler_> the subpel isn't staged like H.264, right?  so I'd assume it'd be mostly just a huge memory hog
2013-08-26 21:19:27 <@Skyler_> unless there's some nice fast way to pre-generate it
2013-08-26 21:19:53 < koda> nice, i'll be at both, i'll come and say hi :)
2013-08-26 21:21:41 <@muggs> it is a memory hog, but we did get a boost from precalculating it
2013-08-26 21:22:28 <@Skyler_> I wonder how much that boost correlates to the subpel search method (e.g. how many times each pixel gets looked at) plus how much worse it gets with multiref (due to memory thrashing)
2013-08-26 21:22:52 <@Skyler_> but huh, I'm surprised it did help
2013-08-26 21:23:04 <@Skyler_> though maybe with proper subpel SIMD it might change too.
2013-08-26 21:23:59 <@muggs> yeah, good points. I think we were mostly using low-latency (all P) configs when we added it.  using many refs probably changes the arithematic
2013-08-26 21:24:23 <@Skyler_> I'm guessing SIMD will change things because it makes calculating cheaper, so the memory accesses are (comparatively) more expensive
2013-08-26 21:25:00 <@Skyler_> using many threads also probably makes it worse, since there's less L3 cache per thread
2013-08-26 21:25:17 <@muggs> it's been SIMD since before we pre-calculated planes
2013-08-26 21:25:20 <@Skyler_> ahh
2013-08-26 21:25:27 <@Skyler_> okay, so you've had asm around for a while then
2013-08-26 21:26:01 <@muggs> well, no.  most of our SIMD is still intrinsic based
2013-08-26 21:26:11 <@Skyler_> oh, sorry, that's what I meant
2013-08-26 21:26:18 <@muggs> yeah
2013-08-26 21:26:25 <@Skyler_> to me "intrinsics" are just a form of asm
2013-08-26 21:27:09 < smarter> HM 12 changed something related to SAO that affects decoding?
2013-08-26 21:27:17 <@muggs> hmmm, this has me thinking.  it would be quite a bit simpler to not generate them at this point.
2013-08-26 21:27:44 <@muggs> smarter: yeah, but I don't know the particulars
2013-08-26 21:27:54 <@Skyler_> I don't know any (optimized) encoder that generates qpel planes, I think (I may be wrong on this)
2013-08-26 21:28:41 < smarter> So the HM wasn't aligned with the spec?
2013-08-26 21:29:08 <@muggs> in HEVC they are 7-tap, so relatively expensive.  but still..
2013-08-26 21:30:35 <@muggs> smarter: must be, because our streams could decode fine with HM 11 but not HM 12.  I think they removed some features that weren't in the spec but were enabled in he HM.  but I don't know the particulars
2013-08-26 21:31:18 < smarter> thanks, I'll have to check that
2013-08-26 21:33:25 <@Skyler_> muggs: it sounds about the same complexity as vp8's?
2013-08-26 21:34:51 <@muggs> yeah
2013-08-26 21:41:38 <@muggs> Skyler_: what did you mean by "the subpel isn't staged like H.264"?
2013-08-26 21:43:29 <@muggs> did you mean QPEL pixels generated from HPEL pixels?
2013-08-26 22:27:05 <@Skyler_> muggs: yes, that's staged subpel
2013-08-26 22:27:27 <@Skyler_> staged qpel is fpel -> hpel -> qpel
2013-08-26 22:27:30 <@Skyler_> unstaged is fpel -> qpel
2013-08-26 22:27:41 <@Skyler_> staged is (apparently) not as good, but allows caching, which is very convenient
2013-08-26 22:35:05 < pengvado> of course staged is not as good. but is it mostly due to the intermediate rounding, or due to constraining the fir coefs?
--- Day changed Tue Aug 27 2013
2013-08-27 08:44:39 < koda> in motion estimation what does TZ stand for?
2013-08-27 08:45:08 < koda> or rather, which option is HM's TZ between dia hex umh star?
2013-08-27 08:52:42 < nevcairiel> there are a few papers for purchase on the TZSearch algorithm, seems to be a specific implementation used in JM/HM, no idea which x264/x265 mode would be similar, if any
2013-08-27 08:53:07 < koda> my bets would be on STAR method
2013-08-27 08:53:12 < koda> according to the comments
2013-08-27 11:45:30 < Daemon404> "papers for purchase"... how nice
2013-08-27 11:45:51  * Daemon404 abuses an ezproxy
2013-08-27 12:17:37 < nevcairiel> ieee likes selling papers
2013-08-27 12:21:27 < koda> previously know as "yeee, making monies"
2013-08-27 12:27:07 < koda> i confirm x265 streams work with hm11
2013-08-27 12:35:38 < Daemon404> nevcairiel, i have strong opinions on academic paywalls ;)
2013-08-27 12:35:45 < Daemon404> and that industry in genera
2013-08-27 12:35:47 < Daemon404> l
2013-08-27 12:36:37 < nevcairiel> i think its funny because its a NPO
--- Day changed Wed Aug 28 2013
--- Day changed Thu Aug 29 2013
--- Day changed Fri Aug 30 2013
--- Day changed Sat Aug 31 2013
2013-08-31 14:09:21 < muggs_> I've pushed a few commits, one of which adds an ENABLE_STATICLIB cmake option.  It enables the generation of libx265enc.a or x265enc.lib depending on your platform
--- Day changed Sun Sep 01 2013
2013-09-01 09:41:39 < Daemon404> muggs_, ping
2013-09-01 09:41:54 < Daemon404> http://chromashift.org/0001-Fix-idiotic-windows-developers.patch
2013-09-01 09:41:55 < Daemon404> http://chromashift.org/0002-motion-Remove-unused-variables.patch
2013-09-01 09:41:58 < Daemon404> for x265.
2013-09-01 09:43:46 < muggs_> Daemon404: thanks; I was in the middle of re-orging those parts myself.
2013-09-01 10:11:12 < koda> muggs_, you could also take some stuff from my branch
2013-09-01 10:12:28 < JEEBsv> :)
2013-09-01 10:17:42 < muggs_> koda: what's your fork link?
2013-09-01 10:25:37 < koda> https://bitbucket.org/kodabb/x265
2013-09-01 10:25:39 < koda> muggs_, ^
2013-09-01 10:32:08 < muggs_> queued a couple of them
2013-09-01 10:35:49 < muggs_> pushed, thanks
--- Day changed Mon Sep 02 2013
2013-09-02 13:07:09 < j-b> 'morning
--- Day changed Tue Sep 03 2013
2013-09-03 21:29:00 < muggs_> j-b: still around?
2013-09-03 21:29:56 < muggs_> we can go live with everything, TS finally made their press release.  I'm afraid to go read it.
2013-09-03 21:54:46 < Mandarinka> heh, x264 "is being leveraged" in said PR :)
2013-09-03 22:46:47 < smarter> \o/
--- Day changed Wed Sep 04 2013
--- Day changed Thu Sep 05 2013
2013-09-05 04:33:47 < min_chen> Phase1, compressMV into other array, and replace all of code that use compressed MV code to it
2013-09-05 04:35:29 < min_chen> phase 2: replace left-above index as index to access origin MV array, so we can remove compressMV stage
2013-09-05 17:04:49 <@muggs> awesome. I see we have a newly announced lgpl competitor
2013-09-05 17:05:13 < BugMaster> where?
2013-09-05 17:05:26 < JEEB> oh, LGPL?
2013-09-05 17:05:27 <@muggs> http://tech.slashdot.org/story/13/09/05/142209/lgpl-h265-codec-implementation-available-encoding-to-come-later
2013-09-05 17:05:32 < JEEB> oh right
2013-09-05 17:05:39 <@muggs> https://github.com/strukturag/libde265
2013-09-05 17:05:41 < JEEB> deh265
2013-09-05 17:05:43 < JEEB> yeah
2013-09-05 17:05:55 < JEEB> I wouldn't think they'd put the encoder under LGPL too, though ;)
2013-09-05 17:06:04 < JEEB> at least it would be surprising
2013-09-05 17:06:23 < Daemon404> that would be a terrible business move
2013-09-05 17:07:29 <@muggs> dunno, I think MCW is expecting to make more on development contracts than on license fees, going forward.
2013-09-05 17:07:51 < Daemon404> that model only lasts for so long
2013-09-05 17:08:05 < Daemon404> until you hit a certain point of stability
2013-09-05 17:08:17 < Daemon404> unless you mean integration work
2013-09-05 17:08:25 <@muggs> people are still offering money for x264 work
2013-09-05 17:08:40 <@muggs> not large money, but it's still there
2013-09-05 17:08:42 < Daemon404> hat does it currently miss?
2013-09-05 17:08:47 < Daemon404> last big thign i remeebr was mbaff
2013-09-05 17:08:52 < JEEB> you mean PAFF
2013-09-05 17:08:54 < JEEB> MBAFF is in
2013-09-05 17:08:58 < Daemon404> o
2013-09-05 17:09:26 <@Skyler_> muggs: I really doubt that, x264 is making $1-2m a year on license fees and has much less marketing budget
2013-09-05 17:09:41 <@Skyler_> there's only so many features one can add to an encoder
2013-09-05 17:09:50 <@Skyler_> license fees go (mostly) forever, a feature can only be sold once
2013-09-05 17:09:56 < Daemon404> clearly x264 needs QNS
2013-09-05 17:09:59 < Daemon404> amirite?
2013-09-05 17:12:16 <@Skyler_> also, very very few customers have asked for new features; the vast majority wanted to use existing, proven ones
2013-09-05 17:13:04 <@muggs> there's also device ports, CPU/GPU arches, etc
2013-09-05 17:16:43 <@muggs> AMD finally has an APU coming out next year with pure shared virtual memory between CPU and GPU, no more PCI bus
2013-09-05 17:17:37 <@muggs> cache coherency both ways, so you can treat the GPU as a big coprocessor
2013-09-05 17:17:46 < BugMaster> so you have lanch date of Kaveri? and it wouldn't happen this year? too bad
2013-09-05 17:18:51 <@muggs> they're waving money at us to make a working demo by January.  I've been trying to wave them off, it's too early.  but I haven't been successful
2013-09-05 17:19:14 <@muggs> I don't have a date, but it won't be this year
2013-09-05 17:19:31 < Mandarinka> Kaveri was supposed to be Q1 2014 according to the official yarn
2013-09-05 17:19:32 < BugMaster> ok. so at least it sounds as Q1
2013-09-05 17:20:21 < Mandarinka> they claim it will "ship" in 2013, but you'll only be able to buy it in early 2014
2013-09-05 17:20:30 < Mandarinka> basically, delay + damage control :D
2013-09-05 17:21:06 <@muggs> sigh
2013-09-05 17:21:25 < BugMaster> I seen roadmap with shippng in Q4 2013 but hopped announce will be also in 2013
2013-09-05 17:21:51 < BugMaster> but Q1 is not so far
2013-09-05 17:22:04 < Mandarinka> well, the slides from CES/Computex made it look like it would appear in autumn, heh.
2013-09-05 17:22:49 <@muggs> I did some work on PCMark 8 for AMD, and at the time Nov was their target
2013-09-05 17:22:56 < Mandarinka> either the slides were too optimistic, or there was some delay I guess /but I'm only an observer or news-reposter/
2013-09-05 17:23:05 < Mandarinka> oh, interesting
2013-09-05 17:38:49 < Daemon404> http://puu.sh/4jMlD.png
2013-09-05 17:38:59 < Daemon404> divx hevc encode is out
2013-09-05 17:40:02 <@muggs> btw: I have a pair of programmers getting spun up on the x264 assembly code; they should appear here or in #x264dev in the next day or so with numerous questions.
2013-09-05 17:41:55 < JEEB> Daemon404, huh -- I thought they still had a timer on their main site
2013-09-05 17:48:18 < Mandarinka> heh, that slashdot thread has a lot of BS
2013-09-05 17:48:47 < Mandarinka> according to some dude, quadro cards can decode 10-bit h.264 in hardware, lol
2013-09-05 17:48:52 < BugMaster> that is slashdot. what do you expected from it
2013-09-05 18:46:04 <@Skyler_> muggs: I'll do my best~
2013-09-05 21:59:38 < muggs_> frame parallelism looks to be mostly functional; still testing.  (-F/--frame-threads)
--- Day changed Fri Sep 06 2013
2013-09-06 12:15:47 < funman> hi
2013-09-06 12:16:05 < funman> make: *** No rule to make target `install'.  Stop.
2013-09-06 12:16:05 < funman> :((
2013-09-06 12:21:59 < BugMaster> hi. have you run cmake?
2013-09-06 12:25:14 < BugMaster> oh. I see you want install library?
2013-09-06 12:29:44 < funman> yeah i just copied the .a / .h manually
2013-09-06 12:38:11 < funman> i'm starting integrating x265 in vlc
2013-09-06 12:44:09 < Daemon404> heh.... divx hevc looks like shit on everything i try
2013-09-06 12:44:27 < Daemon404> as in visibly and obviously worse than x264
2013-09-06 12:46:18 < BugMaster> in what aspects it worse? blocking? banding? something else?
2013-09-06 12:47:17 < Daemon404> blocking/blurring
2013-09-06 12:47:25 < Daemon404> it looks like someone rubbed vaseline on my monitor
2013-09-06 12:53:31 < Daemon404> https://dl.dropboxusercontent.com/u/77349181/parkderp.png
2013-09-06 12:53:48 < Daemon404> at around 1550 kbit/s
2013-09-06 12:53:57 < nevcairiel> parkjoy in winter? :p
2013-09-06 12:54:31 < BugMaster> so they still optimize for psnr and don't have good AQ
2013-09-06 12:54:44 < Daemon404> looks like it
2013-09-06 12:54:52 < Daemon404> it's as if on2 made it :P
2013-09-06 12:55:32 < Daemon404> im aware that res is weird btw
2013-09-06 12:55:45 < Daemon404> there is *no* way to dump yuv from their stuff
2013-09-06 12:56:02 < Daemon404> the matroska files they generate arent even valid in anything but their player
2013-09-06 12:56:11 < Daemon404> so i cant even use HM to decode
2013-09-06 12:57:46 < BugMaster> Daemon404: btw. with 1550 kbit/s bitrate at what fps you made it? 50fps for parkrun?
2013-09-06 12:57:58 < BugMaster> I mean source fps not encoding
2013-09-06 12:58:06 < Daemon404> yes, and i did an equivalent encode with x264
2013-09-06 12:59:58 < Daemon404> i cant really analyze the output of their encoder so well without being able to get it in a format things besides "divx player" can read
2013-09-06 13:00:48 < Daemon404> https://www.dropbox.com/s/l8pefcjx6k0j9xy/divx_hevc.mkv <- if anyone wants to try
2013-09-06 13:16:20 < funman> libPrimitivesASM.a(pixel-a.asm.o): relocation R_X86_64_32 against `x265_pw_00ff' can not be used when making a shared object; recompile with -fPIC
2013-09-06 13:20:48 < funman> btw muggs is not around?
2013-09-06 13:21:23 < Daemon404> probably at his Nth conference
2013-09-06 13:26:11 < funman> https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 doesn't talk about asm :/
2013-09-06 13:28:51 < funman> well that file is a straight copy off x264
2013-09-06 13:31:09 < BugMaster> Daemon404: btw. here is the best one I could get from x264 (without exhausting tweeking) for parkrun at such bitrates: http://www.sendspace.com/file/bzvnr8
2013-09-06 13:31:29 < BugMaster> let see what I could make with x265
2013-09-06 13:33:33 < Daemon404> yes
2013-09-06 13:33:36 < Daemon404> its far better
2013-09-06 13:33:50 < BugMaster> funman: try to link with -Wl,-Bsymbolic
2013-09-06 13:34:08 < funman> i see that x264 .o uses R_X86_64_PC32 rather than R_X86_64_32
2013-09-06 13:34:55 < funman> BugMaster: doesn't help, I'll look at yasm flags
2013-09-06 13:40:23 < JEEBsv> funman: so you're actually trying to use x265's library functionality?
2013-09-06 13:42:23 < funman> yeah
2013-09-06 13:42:36 < JEEBsv> :)
2013-09-06 13:42:42 < funman> bad idea, or worst idea? ;)
2013-09-06 13:44:57 < funman> usr/bin/yasm -f elf64 -DARCH_X86_64=1 -m amd64 -DHAVE_ALIGNED_STACK=1 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o CMakeFiles/PrimitivesASM.dir/pixel-a.asm.o /media/dev/x265/source/common/x86/pixel-a.asm
2013-09-06 13:45:29 < funman> versus
2013-09-06 13:45:29 < funman> yasm -f elf -m amd64 -DHAVE_ALIGNED_STACK=1 -DPIC -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -DARCH_X86_64=1 -I./common/x86/ -o common/x86/pixel-a.o common/x86/pixel-a.asm
2013-09-06 13:45:49 < funman> -f elf64 / elf ?
2013-09-06 13:45:53 < pengvado> -DPIC is the relevant difference
2013-09-06 13:47:00 < funman> oops right
2013-09-06 13:47:14 < funman> is it a x86inc.asm flag?
2013-09-06 13:47:31 < pengvado> yes
2013-09-06 13:49:29 < funman> bah, they don't use ASM_YASM_FLAGS
2013-09-06 14:03:03 < funman> relocation R_X86_64_32 against `x265_pw_8' can not be used when making a shared object; recompile with -fPIC
2013-09-06 14:03:08 < funman> fuu
2013-09-06 14:03:50 < funman> ah i need make clean perhaps :)
2013-09-06 14:05:16 < funman> indeed, never trust cmake
2013-09-06 14:08:13 < funman> going to send http://pastie.org/8303242
2013-09-06 14:38:59 < BugMaster> hm. I can't decode x265 stream not with HM 11, not with HM 12. it assert on "rpcSlice->getSliceQp() <= 51"
2013-09-06 14:39:40 < BugMaster> I tried to encode with ABR 1600 kbps
2013-09-06 15:19:26  * funman slowly encodes some stuff
2013-09-06 17:15:57 < funman> muggs: x265_encoder_encode doesn't give timestamps or frame type (I/P/B) ?
2013-09-06 18:09:35 <@muggs> yeah, that has been percolating up the priority of my TODO list
2013-09-06 18:10:20 <@muggs> would POC and the x265 slice type macro defines be sufficient, or do you want the NAL type?
2013-09-06 18:28:08 <@muggs> wait.. the output pic does have POC already.  I'm adding NAL type.
2013-09-06 18:28:43 <@muggs> funman: am I missing something obvious?
2013-09-06 18:42:30 <@muggs> http://paste.lisp.org/display/138807   ok?
2013-09-06 18:43:54 <@muggs> decided to use sliceType there, since that can be used on the input side too, and NAL types could be looked up
2013-09-06 18:50:39 < funman> muggs: i noticed the poc field but I don't know yet what it represents
2013-09-06 18:50:57 < funman> i was looking for a hevc spec pdf to catch up with any new terminology :P
2013-09-06 18:52:35 < funman> there's http://www.itu.int/rec/T-REC-H.265-201304-I
2013-09-06 18:58:41 < funman> I guess Pic Order Count ?
2013-09-06 18:59:57 < nevcairiel> poc is not new in h265 though =p
2013-09-06 19:00:01 <@muggs> yes, just an increasing number for the display order
2013-09-06 19:00:40 < funman> nevcairiel: never heard about it already although the only encoder i wrote was mpeg-1
2013-09-06 19:00:56 < funman> ok
2013-09-06 19:01:18  * funman needs to refresh his cmake fu
2013-09-06 19:01:29 < nevcairiel> ideally the API would allow you to feed you a timestamp with the raw image, and get the timestamp back with the encoded image matching this, including reordering
2013-09-06 19:05:31 <@muggs> what does "including reordering" imply?  you want the pictures back in the order they were submitted?
2013-09-06 19:05:48 < nevcairiel> i assume the encoder reorders its output into decoding order
2013-09-06 19:06:05 < nevcairiel> and i want the timestamps re-ordered to decoding order as well
2013-09-06 19:06:13 <@muggs> yes, it does.
2013-09-06 19:06:25 < nevcairiel> ie. attach them to an image, and never let them go =P
2013-09-06 19:07:06 < BugMaster> in x264 there is i_pts for input and i_pts/i_dts for output with picture
2013-09-06 19:07:08 <@muggs> basically, we only support cfr, so the poc should be sufficient at the moment
2013-09-06 19:09:37 <@muggs> BugMaster: i_pts can be != i_dts?
2013-09-06 19:10:02 < BugMaster> yes. of course
2013-09-06 19:10:22 <@muggs> maybe I don't understand what dts is in this context
2013-09-06 19:10:31 < BugMaster> pts is presentation time and dst is decoder time so they different if you reorder frames
2013-09-06 19:10:46 <@muggs> dst is just the decode order?
2013-09-06 19:11:29 < BugMaster> you can call it only order. but for vfr it is not only order. it more like reordered pts
2013-09-06 19:11:50 < BugMaster> may be with shift
2013-09-06 19:12:23 < nevcairiel> although shift is rare
2013-09-06 19:12:57 < nevcairiel> in theory it should account for the time the decoder needs to decode, so dts < pts, but without b-frames its usually always dts = pts
2013-09-06 19:12:58 <@muggs> does x264 allow pictures to be entered into the encoder out of pts order?
2013-09-06 19:13:20 < BugMaster> here is code from x264: http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=encoder/encoder.c;h=78ad56ae3cd96eebe596c79367d428c2e9dbd7bd;hb=HEAD#l3324
2013-09-06 19:13:55 < BugMaster> muggs: no. input frames should have monotonicly increasing pts
--- Log closed Fri Sep 06 19:20:31 2013
--- Log opened Fri Sep 06 21:48:42 2013
2013-09-06 22:00:42 < Mandarinka> http://www.agner.org/optimize/blog/read.php?i=285  Some updates by Agner Fog (in case somebody missed)
2013-09-06 22:01:12 < Mandarinka> wait, that was supposed to go to x264. Oh well, not that offtopic I hope :)
2013-09-06 22:21:28 < JEEBsv> definitely not given what is done here :)
2013-09-06 22:25:42 < Mandarinka> yeah, the same people are here too luckily.
2013-09-06 23:02:01  * muggs improves todo wiki page
--- Day changed Sat Sep 07 2013
2013-09-07 15:09:41 < greenfountain> fixed bug in ABR for qp exceeding max level.
2013-09-07 15:09:52 < JEEB> nice
2013-09-07 15:10:10 < greenfountain> @bugmaster can u try out ABR now. it works when i try for 1500~ target bitrate on HD videos
2013-09-07 15:10:34 < JEEB> he's not around right now it seems
2013-09-07 15:11:33 < greenfountain> ok, if you guys are free, pls try and let me know of any bugs/anamolies
2013-09-07 15:11:57 < JEEB> sure
2013-09-07 15:11:59 < JEEB> also, btw
2013-09-07 15:12:24 < JEEB> where should I look in the x265 code base if I were interested in plugging in something like the CRF mode in x264?
2013-09-07 15:12:36 < greenfountain> it kind of overshoots when frame parallelism is enabled.. and no.of threads icrease.. trying to add a scaling factor to reduce the effect
2013-09-07 15:12:40 < greenfountain> ratecontrol.cpp
2013-09-07 15:12:48 < greenfountain> thats where ABR , CQP etc are put in as of now
2013-09-07 15:12:51 < JEEB> ok
2013-09-07 15:12:59 < JEEB> and the selection between them is there as well?
2013-09-07 15:13:06 < greenfountain> yea
2013-09-07 15:13:09 < JEEB> gotcha
2013-09-07 15:13:35 < greenfountain> if u use --bitrate in input parameter, it automatically shifts to ABR mode.. else CQP
2013-09-07 15:16:10 < JEEB> how much of the lookahead is ready atm btW?
2013-09-07 15:18:26 < JEEB> okies, I see where the switch is
2013-09-07 15:18:41 < greenfountain> i think all the fixed GOP cofigs etc which were hardcoded before are removed. slice decision and analysis for B frame enable has been recently integrated..
2013-09-07 15:20:19 < JEEB> at the moment there is a single QP for the whole picture, am I correct?
2013-09-07 15:21:24 < greenfountain> yea
2013-09-07 15:21:38 < JEEB> gotcha
2013-09-07 15:21:41 < greenfountain> single qp for each frame
2013-09-07 15:21:47 < greenfountain> no AQ
--- Day changed Sun Sep 08 2013
--- Day changed Mon Sep 09 2013
2013-09-09 05:50:47 < oneal> Hello, we are integrating x265 encoder into a applicaton, but we have some issues.
2013-09-09 05:51:11 < oneal> my build is a cross platform environment.
2013-09-09 05:53:47 < oneal> I build my application on ubuntu, my target system is win32. so I build the x265 on windows using Mingw, then I copy the binary into Linux system and build my application.
2013-09-09 05:54:30 < oneal> but there are some runtime error when I call some API from x265.
2013-09-09 05:56:04 < oneal> So I want to know whether the x265 runs the test on a cross plaform environment
2013-09-09 09:56:10 < funman> oneal: hello
--- Day changed Tue Sep 10 2013
2013-09-10 06:29:44 < Nabajit> Need help in understanding the x264 sad asm functions
2013-09-10 06:31:26 <@Skyler_> sure, I'm here
2013-09-10 06:33:10 < Nabajit> I notice that there are a lot of macros being used, which is somewhat making it difficult to understand
2013-09-10 06:34:03 < Nabajit> is it just for the reusability purpose ?
2013-09-10 06:35:27 <@Skyler_> macros are used because it avoids massive copy-pasting of the code and makes it more readable and maintainable
2013-09-10 06:35:33 <@Skyler_> though I'll admit, the SAD macros aren't the cleanest and are rather old
2013-09-10 06:36:04 < Nabajit> yeah..
2013-09-10 06:36:45 < Nabajit> is there any particular document that I can refer to for the same
2013-09-10 06:36:52 <@Skyler_> but extending them to do different sizes should be pretty straightforward
2013-09-10 06:36:53 <@Skyler_> Um...
2013-09-10 06:37:00 <@Skyler_> I... really don't think so
2013-09-10 06:37:06 < Nabajit> ohh..
2013-09-10 06:37:09 <@Skyler_> if you have specific questions I can try my best to answer
2013-09-10 06:37:24 <@Skyler_> like if you want a particular function explained or something
2013-09-10 06:37:36 < Nabajit> that will be great
2013-09-10 06:38:00 < Nabajit> suppose we consider the sad4x4 function..
2013-09-10 06:38:45 < Nabajit> can you briefly explain about that
2013-09-10 06:39:31 <@Skyler_> %macro SAD 2
2013-09-10 06:39:31 <@Skyler_> cglobal pixel_sad_%1x%2_mmx2, 4,4 pxor    mm0, mm0
2013-09-10 06:39:31 <@Skyler_> %rep %2/2 SAD_INC_2x%1P
2013-09-10 06:39:31 <@Skyler_> %endrep movd    eax, mm0 RET
2013-09-10 06:39:32 <@Skyler_> %endmacro
2013-09-10 06:39:39 <@Skyler_> 2 parameters: width and height
2013-09-10 06:39:44 <@Skyler_> this macro generates MMX SAD functions.
2013-09-10 06:40:01 <@Skyler_> it does this by zeroing mm0, the accumulator, and then repping the core section, which does 2 rows of either width 4, 8, or 16.
2013-09-10 06:40:12 <@Skyler_> then at the end it moves the result to eax and returns.
2013-09-10 06:40:24 <@Skyler_> SAD_INC_2x4P is the width 4 SAD macro, which gets used for 4x4.
2013-09-10 06:40:43 <@Skyler_> it loads 2 rows, punpckldqs them together, does a SAD, and accumulates.
2013-09-10 06:41:10 <@Skyler_> larger registers aren't useful for width 4, so there's no SSE version anywhere. punpckldq is used because it's faster than doing extra SADs.
2013-09-10 06:42:11 < Nabajit> ok.I will try to figure out the points in the function
2013-09-10 06:42:36 < Nabajit> what about the calling convention ?
2013-09-10 06:42:55 <@Skyler_> All of x264's asm is standard cdecl.
2013-09-10 06:43:33 <@Skyler_> (or, more specifically, it supports x86_32, unix64, and win64, the three standard calling conventions for x86)
2013-09-10 06:44:12 < Nabajit> ok...
2013-09-10 06:44:18 <@Skyler_> so it works like a normal C function.
2013-09-10 06:44:35 < Nabajit> Yes..I got the point
2013-09-10 06:45:53 < Nabajit> By default where does the arguments gets stored.. I mean any particular resisters or the stack?
2013-09-10 06:46:21 < shazeb> seeking help on understanding the vitterbi implementation in x264 lookahead? Seems its a special case, presumes certain probability values? Can anyone explain?
2013-09-10 06:46:30 <@Skyler_> x264 asm syntax looks like this:
2013-09-10 06:47:02 <@Skyler_> cglobal function_name, A,B,C,D
2013-09-10 06:47:03 <@Skyler_> [...]
2013-09-10 06:47:05 <@Skyler_> RET
2013-09-10 06:47:21 <@Skyler_> A is the number of arguments.
2013-09-10 06:47:28 < Nabajit> ok
2013-09-10 06:47:33 <@Skyler_> B is the number of registers you need; naturally, this has to be >= A.
2013-09-10 06:47:45 <@Skyler_> C is optional; the number of xmmregs used (only required if >6, due to win64's weird calling convention)
2013-09-10 06:48:00 <@Skyler_> D is optional; it's a stack offset for automatic creation of scratch space (only used in a few places; a new feature)
2013-09-10 06:48:08 <@Skyler_> A and B are the main ones that matter.
2013-09-10 06:48:17 <@Skyler_> RET restores the stack, pops everything off, and returns.
2013-09-10 06:48:27 < Nabajit> ok
2013-09-10 06:48:29 <@Skyler_> RET isn't ret; "ret" is just the instruction, "RET" is "clean everything up that it automatically did for you at the start".
2013-09-10 06:48:43 <@Skyler_> so if A is 4, our 4 arguments are in r0, r1, r2, and r3.
2013-09-10 06:49:01 <@Skyler_> r0b means "the byte version of r0".  r0w means "the word version of r0".  r0d is doubleword (32-bit).
2013-09-10 06:49:19 <@Skyler_> and so on
2013-09-10 06:49:22 < Nabajit> ok..
2013-09-10 06:49:51 < Nabajit> if args > 4, then remaining args need to be popped from the stack?
2013-09-10 06:49:52 <@Skyler_> shazeb: ummm  let's see if I can remember
2013-09-10 06:50:09 <@Skyler_> Nabajit: x264asm does that automatically for you.  things only get messy if you need more than 7 registers
2013-09-10 06:50:48 <@Skyler_> shazeb: um okay if I'm remembering right...
2013-09-10 06:51:09 <@Skyler_> our rules: All paths must end in P.  There shall be no more than N sequential B-frames (for this example: 2)
2013-09-10 06:51:17 <@Skyler_> The best path of length 1 must, therefore, be P.
2013-09-10 06:51:21 <@Skyler_> since that's the only possible path.
2013-09-10 06:51:44 < Nabajit> ok.. u mean 7 registers for the input arguments or for the full function
2013-09-10 06:51:47 <@Skyler_> For length 2, we have two paths: BP, and _P, where _ is the best path of length 1.  Let's say that BP turned out to be better.  This means BP is the best length 2 path.
2013-09-10 06:51:58 <@Skyler_> Nabajit: latter (if you need more than 7 registers, you can't support 32-bit with that code, basically)
2013-09-10 06:52:14 < Nabajit> ok...
2013-09-10 06:52:23 <@Skyler_> For length 3, we have three possible paths: BBP, _BP, and __P, where _ is the best path of length 1, and __ is the best path of length 2.
2013-09-10 06:52:33 <@Skyler_> let's say BBP is the best for this example.
2013-09-10 06:53:10 <@Skyler_> For length 4, we have three possible paths: _BBP, __BP, and ___P, where _ is the best path of length 1, __ is the best path of length 2, and ___ is th best path of length 3.  BBBP isn't an option, because we capped B-frames to 2.
2013-09-10 06:53:25 <@Skyler_> this process repeats as long as we want, until we reach our maximum path length.
2013-09-10 06:53:32 <@Skyler_> The optimal path we get at that point is the path we choose.
2013-09-10 06:54:10 <@Skyler_> The purpose of this algorithm is a linear time solution to "what is the optimal path of length M", which normally would have 2^M (roughly) possible options.
2013-09-10 06:55:30 < shazeb> maximum path length means max no of Bs allowed? or is this independent?
2013-09-10 06:56:29 <@Skyler_> Maximum path length == length of lookahead
2013-09-10 06:58:49 < shazeb> ok lets assume your example runs for another iteration; then what can be the possible paths considering BBBP (or BBBBP & so on) isn't an option?
2013-09-10 06:59:30 <@Skyler_> okay, let's say that length 4's best turned out to be __BP, in other words, BPBP.
2013-09-10 06:59:35 <@Skyler_> now we go to length 5.
2013-09-10 06:59:49 <@Skyler_> ____P
2013-09-10 06:59:50 <@Skyler_> ___BP
2013-09-10 06:59:52 <@Skyler_> __BBP
2013-09-10 06:59:55 <@Skyler_> we pick the best of those three.
2013-09-10 07:01:25 <@Skyler_> so for each step of length L, we need to know the best path lenths from step L-1, L-2 [...] L-(N+1), where N is the max b-frames.
2013-09-10 07:03:16 <@Skyler_> fortunately we already figured those out in the previous steps :p
2013-09-10 07:03:19 <@Skyler_> it's basically induction/memoization.
2013-09-10 07:03:58 < shazeb> yes
2013-09-10 07:05:54 < shazeb> thanks Skyler_, the strings used in the code seemed cryptic earlier, now its clear, you explained precisely!
2013-09-10 07:06:53 <@Skyler_> yay
2013-09-10 07:07:10 <@Skyler_> I'm shocked I remembered that explanation after like 5 years =_=
2013-09-10 07:07:41 < shazeb> haha, at times we dont remember that we do remember!
2013-09-10 07:12:39 <@Skyler_> (it took me about 2 weeks as a dumb teenager to properly grok how that thing worked)
2013-09-10 09:26:15 < Nabajit> The asm code isnt that complex to understand as it seemed :-)
2013-09-10 09:39:09 < funman> I wonder which subset of options (x265_param_t) I should provide control over in VLC
2013-09-10 10:26:01 < Nabajit> what is "cglobal_internal" used for in the asm code?
2013-09-10 10:30:35 < Nabajit> Do we need to bother about that part now?
2013-09-10 13:22:39 <@Skyler_> @nabajit: cglobal_internal is well, the icky internals of how cglobal is actually implemented
2013-09-10 13:22:56 <@Skyler_> you generally don't have to care about this sort of thing (x86inc is macro hell in order to do things that yasm normally can't do)
2013-09-10 16:26:32 < funman> https://github.com/funman/vlc/commit/0cf9d2670b28b049b551688d701c3095b6bed113
2013-09-10 16:41:14 < Daemon404> funman, those libs sure do pollute namespaces
2013-09-10 16:41:20 < Daemon404> libPrimitivesASM
2013-09-10 16:45:24 < Daemon404> i guess that should be directed at muggs
2013-09-10 16:56:30 < funman> yes there should be one single libx265.a
2013-09-10 16:56:40 < funman> https://github.com/videolan/x265
2013-09-10 17:50:03 <@muggs> funman: does the CMake option ENABLE_STATICLIB improve the situation?
2013-09-10 18:06:53 < Daemon404> muggs, can you also have libx264.so?
2013-09-10 18:31:38 < funman> muggs: let me see
2013-09-10 18:32:02 < Daemon404> also request: make uninstall
2013-09-10 18:32:08 < Daemon404> because its *really* useful sometimes
2013-09-10 18:32:49 < funman> and make install first ^_^
2013-09-10 18:32:56 < Daemon404> it has no make install?
2013-09-10 18:34:29 < funman> muggs: do you come at IBC ?
2013-09-10 18:35:44 < funman> Linking C static library libx265enc.a
2013-09-10 18:35:59 < funman> looks good
2013-09-10 18:36:28 < funman> muggs: I suggest using libx265.a though and drop the enc prefix, and also make this the default (well I would remove the option entirely and switch to a single .a library)
2013-09-10 18:37:12 < Daemon404> also
2013-09-10 18:37:16 < Daemon404> is the api versioned
2013-09-10 18:37:19 < Daemon404> liek x264?
2013-09-10 18:41:17 < funman> it is not but it's very minimal
2013-09-10 18:41:35 < funman> though i'm not sure what is extensible here
2013-09-10 18:41:37 < Daemon404> just dont fall into the elenril trap
2013-09-10 18:41:40 < Daemon404> of ever changing APIs
2013-09-10 20:08:41 < j-b> https://mailman.videolan.org/listinfo/x265-devel
2013-09-10 20:08:48 < j-b> http://mailman.videolan.org/pipermail/x265-devel/
2013-09-10 20:08:54 < JEEB> woot \o/
2013-09-10 20:09:04  * JEEB quietly licks j-b 
2013-09-10 20:09:20 < Daemon404> now if only mailmal wasnt crap
2013-09-10 20:09:29 < Daemon404> i bet it still sends me my password in plain text
2013-09-10 20:09:33 < nevcairiel> it does
2013-09-10 20:09:53 < nevcairiel> but did someone really invent an alternative? everyone seems to still be using it
2013-09-10 20:10:27 < Daemon404> i dont see whats so hard about not emaling people their plaintet password
2013-09-10 20:10:28 < j-b> we used ecartis in the past
2013-09-10 20:10:32 < j-b> it got discontinued
2013-09-10 20:10:46 < JEEB> yeah, that's why I generally just have "mehaetsplaintextpasswordsyodawg" kind of passwords on mailmans
2013-09-10 20:10:47 < nevcairiel> i just use some dummy password for mailing lists
2013-09-10 20:11:14 < Daemon404> so do i
2013-09-10 20:11:19 < Daemon404> doesnt matter if i forget it
2013-09-10 20:11:44 < j-b> https://mailman.videolan.org/admin/x265-commits
2013-09-10 20:12:10 <@muggs> funman: I will be at IBC, I leave here tomorrow
2013-09-10 20:12:55 < funman> j-b: thank you
2013-09-10 20:13:11 <@muggs> sorry, been super distracted today, just catching up with the backlog
2013-09-10 20:13:17 < funman> muggs: which stand will you be on?
2013-09-10 20:13:40 <@muggs> I will be walking, for the most part.
2013-09-10 20:13:41  * funman will probably spend some time in u-pipe booth
2013-09-10 20:14:04 < funman> muggs: eheh me too :) we might bump into each other
2013-09-10 20:14:28 < j-b> friday is visiting the stands
2013-09-10 20:14:32 < j-b> saturday is meeting day
2013-09-10 20:15:28 < funman> sunday drugs and hookers
2013-09-10 20:15:40 <@muggs> btw: that STL patch has been rejected.  beyond the use of long types, it also has a leak
2013-09-10 20:16:05 <@muggs> funman: that's called sight-seeing, when you fill your expense report
2013-09-10 20:16:55 <@muggs> cmake still won't let me have libx264.a and x264(.exe) in the same build; thus the 'enc' suffix
2013-09-10 20:17:09 <@muggs> err s/264/265/g
2013-09-10 20:17:13 < j-b> http://mailman.videolan.org/pipermail/x265-commits/
2013-09-10 20:18:47 <@muggs> awesome, thanks j-b
2013-09-10 20:21:26 < funman> muggs: i will look
2013-09-10 20:22:58 <@muggs> hmm, let me try this hack
2013-09-10 20:24:46 < funman> mv x265bin x265 ?
2013-09-10 20:25:04 < funman> http://www.cmake.org/Wiki/CMake/Policies#Setting_Policies_Individually
2013-09-10 20:25:18 < funman> they say duplicate target names are forbidden by policy
2013-09-10 20:25:45 <@muggs> I think I have a workaround, let me test it with MinGW
2013-09-10 20:29:03 <@muggs> http://privatepaste.com/dcd8b269b3
2013-09-10 20:29:07 <@muggs> still testing
2013-09-10 20:32:38 < roxlu_> muggs: can't you just add a nother target?
2013-09-10 20:33:09 < roxlu_> add_library() and add_executable() ? (sorry .. just falling right into the discussion)
2013-09-10 20:34:02 < funman> that's the two being used with (x265, ...) yes
2013-09-10 20:34:25 < funman> muggs: looks good, does it work?
2013-09-10 20:34:49 <@muggs> still waiting for gcc build to finish (more gcc warnings added last night)
2013-09-10 20:41:59 <@muggs> ok, looks good with MinGW and MSVC.  pushed.
2013-09-10 20:43:34 <@muggs> let me see if I can cleanly make this the default
2013-09-10 20:49:23 <@muggs> btw: we're also trying to get rid of STL use as well; it is a real PITA for integration
2013-09-10 20:50:16 < funman> muggs: removing merge_static_libraries and inlining it
2013-09-10 20:50:41 <@muggs> yeah, testing that.  I don't think I need to link PLATFORM_LIBS into libx265 either
2013-09-10 20:53:14 < funman> no
2013-09-10 20:53:14 < funman> these have to go in the .pc
2013-09-10 20:53:34 <@muggs> does VLC link correctly with libx265.a now?
2013-09-10 20:56:17 <@muggs> this seems to work here:   http://privatepaste.com/7005180ecc
2013-09-10 20:56:54 < funman> muggs: didn't try yet
2013-09-10 20:57:22 < funman> i guess target_link_libraries is for shared only ?
2013-09-10 20:59:31 <@muggs> it's mainly for dynamic libs or exes
2013-09-10 20:59:57 <@muggs> btw:  I suggest frameNumThreads of 2 or 3, unless you know you have 16 cores
2013-09-10 21:02:04 <@muggs> and I believe you'll need to initialize pic.bitDepth to 8.  we should probably provide a function to initialize pic
2013-09-10 21:18:19 < Daemon404> um
2013-09-10 21:18:30 < Daemon404> hy is the x265-devel list sending me things dated the 4th of sep?
2013-09-10 21:18:43 < Daemon404> is it allowing broken clients to pass their date through?
2013-09-10 21:19:22 < j-b> that's called moderation
2013-09-10 21:19:28 < j-b> because big emails got blocked
2013-09-10 21:19:42 < Daemon404> heh
2013-09-10 21:23:18 <@muggs> both patches were dealt with a week ago
2013-09-10 21:23:36 < j-b> sorry, I can't guess that
2013-09-10 21:25:24 <@muggs> np; I didn't know they were stuck in moderation.
2013-09-10 21:34:19 < thresh> muggs: sorry, I see no ssh connects to hg@
2013-09-10 21:34:39 < thresh> and I have just hg pushed to some test repo on hg.v.o and it worked :/
2013-09-10 22:32:59 <@muggs> still doesn't work here; fwiw
--- Day changed Wed Sep 11 2013
2013-09-11 06:01:39 < Nabajit> @Skyler_what is "cglobal_internal" used for in the asm code?
2013-09-11 07:00:50 <@Skyler_> 23:21 <@Skyler_> @nabajit: cglobal_internal is well, the icky internals of how cglobal is actually implemented
2013-09-11 07:00:54 <@Skyler_> 23:21 <@Skyler_> you generally don't have to care about this sort of thing
2013-09-11 07:00:56 <@Skyler_>                  (x86inc is macro hell in order to do things that yasm normally
2013-09-11 07:00:58 <@Skyler_>                  can't do)
2013-09-11 07:25:42 < Nabajit> ok
2013-09-11 08:23:46 < Nabajit> To extend the existing sad function to different size, i believe we can reuse the existing macros
2013-09-11 08:24:25 < Nabajit> Am I right?
2013-09-11 08:29:06 < Nabajit> current max supported size is 16x16... so to extend it to 32x32 for example, is it fine that we use 16x16 for 4 times with proper offsets
2013-09-11 09:38:22 < j-b> 'morning
2013-09-11 10:12:05 < Daemon404> i will start trying to 'review' some patches tonight
2013-09-11 10:12:07 < Daemon404> or at least comment
2013-09-11 10:12:18 < Daemon404> @ j-b / muggs (who isnt here)
2013-09-11 10:12:38 < Daemon404> Nabajit, by the definition of SAD that would be OK
2013-09-11 10:12:52 < Daemon404> not sure if there are better methods perf-wise for 32x32
2013-09-11 10:16:39 < j-b> Daemon404: you know we have a patchwork, right?
2013-09-11 10:18:40 < Daemon404> nope
2013-09-11 10:18:56 < Daemon404> patchwork isnt useful for much besides supplementing the ML though, no?
2013-09-11 10:19:22 < Nabajit> @Daemon404 : So existing SAD can be used to extend sad functionality for any supported size
2013-09-11 10:19:58 < Daemon404> it's a sum...
2013-09-11 10:21:16 < Daemon404> the sum of N blocks i the sum of the whole
2013-09-11 10:21:19 < Daemon404> is*
2013-09-11 10:21:20 < Nabajit> yes
2013-09-11 10:23:12 < Nabajit> its the total sum of all the sub blocks
2013-09-11 10:23:41 < Daemon404> so.. what's the problem?
2013-09-11 10:24:10 < Nabajit> I was just clarifying..no problems
2013-09-11 10:24:59 < Daemon404> ok.
2013-09-11 11:13:19 < shazeb> whats the logic behind calculation of cost2p1 with in FAST mode in x264_slicetype_analyse with b_intra_penalty as 1?
2013-09-11 12:52:43 < Daemon404> j-b, where can i find the patchwork install?
2013-09-11 12:53:40 < Daemon404> nvm found
2013-09-11 13:24:29 < j-b> Daemon404: <3
2013-09-11 13:24:48 < Daemon404> 2 reviews sent
2013-09-11 13:24:56 < Daemon404> tho i see pushes to x265's repo that were not on the ML
2013-09-11 13:24:58 < Daemon404> so :V
2013-09-11 13:25:14 < nevcairiel> i dont think the main developers care yet =P
2013-09-11 13:25:25 < Daemon404> likely not.
2013-09-11 13:29:18 < Daemon404> i nearl shat myself when i saw a reimplementation if list
2013-09-11 13:29:21 < Daemon404> in c++
2013-09-11 13:29:22 < Daemon404> :logic:
2013-09-11 13:29:26 < Daemon404> of*
2013-09-11 13:30:10 < j-b> I don't get the usecase of a new list implementation
2013-09-11 13:30:27 < Daemon404> j-b, i understand it if theyre moving to C
2013-09-11 13:30:32 < Daemon404> obviously cant use std::list
2013-09-11 13:30:37 < Daemon404> but... in C++... yeha
2013-09-11 13:30:40 < Daemon404> yeah*
2013-09-11 13:30:41 < BugMaster> mix of C and C++ is the thing that scare me the most
2013-09-11 13:30:45 < Daemon404> yeah
2013-09-11 13:31:17 < j-b> it's not really scary
2013-09-11 13:31:24 < j-b> it can be done in steps
2013-09-11 13:31:36 < Daemon404> j-b, theyre addinng *new* mixed usages of new and malloc
2013-09-11 13:31:38 < Daemon404> which is just bad.
2013-09-11 13:31:45 < j-b> that is true
2013-09-11 13:32:19 < Daemon404> the only dev that seems to put reasonable coe in is muggs
2013-09-11 13:32:20 < Daemon404> code*
2013-09-11 13:32:47 < JEEB> more or less, yes
2013-09-11 14:17:57 < nevcairiel> you know how it goes, all the people with good smarts about algorithms and stuff just cant code C
2013-09-11 14:18:07 < nevcairiel> well not all
2013-09-11 14:18:10 < nevcairiel> but its common anyway :P
2013-09-11 14:18:20 < Daemon404> :P
2013-09-11 14:18:23 < Daemon404> we call them engineers
2013-09-11 14:29:59 < Daemon404> ....
2013-09-11 14:30:03 < Daemon404> http://mailman.videolan.org/pipermail/x265-devel/2013-September/000702.html
2013-09-11 14:30:06 < Daemon404> then just now:
2013-09-11 14:30:10 < Daemon404> http://mailman.videolan.org/pipermail/x265-devel/2013-September/000703.html
2013-09-11 14:30:14 < Daemon404> i don't even....
2013-09-11 14:35:21 < j-b> Daemon404: http://mailman.videolan.org/pipermail/x265-devel/2013-September/000705.html he updated it
2013-09-11 14:36:29 <@Skyler_> nabajit: IMO it would be better to create a width-32 SAD macro
2013-09-11 14:36:38 <@Skyler_> it'd be faster (esp. with AVX) than doing 4 16x16 blocks
2013-09-11 14:38:00 < Daemon404> j-b, yeah i got it
2013-09-11 14:38:11 < Daemon404> already replie
2013-09-11 14:38:12 < Daemon404> d
2013-09-11 14:38:30 < Daemon404> Skyler_, wouldnt you need 32-bit intermediates then?
2013-09-11 14:38:34 < Daemon404> isn't that potentially slower
2013-09-11 14:39:09 < Daemon404> (note: im a simd newb)
2013-09-11 14:44:17 <@Skyler_> that would depend on the number of rows, not the width of the row
2013-09-11 14:44:35 <@Skyler_> also, psadbw technically could use up to 64-bit intermediates and be pretty okay
2013-09-11 14:44:55 <@Skyler_> the max would be 32 * 8 * 255 which looks like it still fits in 16-bit
2013-09-11 14:54:56 < j-b> sucess
2013-09-11 14:55:29 < Daemon404> Skyler_, ah ok
2013-09-11 14:55:55 < Daemon404> i misread your suggestion as 32x32
2013-09-11 14:58:30 <@Skyler_> you'd need 32-bit adds in the final part, but that's not any slower
2013-09-11 14:58:36 <@Skyler_> (and I don't think you can avoid them)
2013-09-11 15:07:30 <@Skyler_> 1 row: 32x 8-bit -> 4x 16-bit
2013-09-11 15:07:44 <@Skyler_> 32 rows: 4x (0-1020) * 32
2013-09-11 15:07:56 <@Skyler_> = 4x (0 to 32640)
2013-09-11 15:08:09 <@Skyler_> but either way it's just swapping paddw for paddd.
2013-09-11 15:24:27 < Daemon404> hmm... it seems impossible to list the option properly in cmake for x265
2013-09-11 15:24:39 < Daemon404> it doesnt list anything at all related to shared/statc lib builds aside from flags
2013-09-11 15:30:00 < Daemon404> $ find -name *.so
2013-09-11 15:30:01 < Daemon404> ./common/vec/libPrimitivesVec.so
2013-09-11 15:30:11 < Daemon404> well ok... it only builds one random hared lib if enabled
2013-09-11 15:30:13  * Daemon404 shrugs
2013-09-11 15:31:01 < Daemon404> and it links to that lib using an absolute path
2013-09-11 15:31:04 < Daemon404> making it unportable
2013-09-11 15:50:57 < spaam> why did they choose cmake as a build system?
2013-09-11 15:51:16 < spaam> just beacuse it got some output stuff for visual studio?
2013-09-11 15:51:24 < Daemon404> yes.
2013-09-11 15:51:33 < Daemon404> all teh devs but muggs exclusively ue MSV
2013-09-11 15:51:34 < Daemon404> S
2013-09-11 19:01:19 <@muggs> morning all, I'm in Houston for just an hour or so, then jumping on the next plane
2013-09-11 19:02:05 <@muggs> I have a patch series that 1) allows x265 to build in Xcode and 2) fixes the threading problems on Mac OS X
2013-09-11 19:02:48 <@muggs> the problem with threading was that Mac OS X doesn't support unnamed semaphores, so sem_init() just returned SEM_FAILED and we had insufficient error checking
2013-09-11 19:03:31 <@muggs> I've switched the POSIX Event class to use sem_open() and named semaphores, but it's not clear if I should make this a Mac only change or whether it is ok for Linux
2013-09-11 19:06:01 < Daemon404> muggs, just fyi shared libs are completely broken
2013-09-11 19:06:36 <@muggs> missing symbols for vec and asm primitives?
2013-09-11 19:06:48 < Daemon404> no
2013-09-11 19:06:52 < Daemon404> as in they simply dont work
2013-09-11 19:07:00 <@muggs> don't build?
2013-09-11 19:07:05 < Daemon404> enabling a shared build builds libPrimitivesASM.so, and the rest are static
2013-09-11 19:07:09 < Daemon404> thats it.
2013-09-11 19:08:01 <@muggs> oh, you mean maiking a libx265.dll?
2013-09-11 19:08:14 <@muggs> or .so?
2013-09-11 19:08:17 < Daemon404> yes
2013-09-11 19:08:29 < Daemon404> only libPrimitivesASM gets built as shared
2013-09-11 19:08:33 < Daemon404> nothign else
2013-09-11 19:08:51 <@muggs> ah, yes.  I had a patch that started that process some time ago, but haven't finished it.  I can give that a go again on the plane
2013-09-11 19:09:00 < Daemon404> ok
2013-09-11 19:09:16 < Daemon404> its pretty important if you want libx265 to be used in other projects
2013-09-11 19:11:19 < nevcairiel> as long as the final goal is one libx265.dll, and all the "internal" libs statically linked into that dll, i'll also be happy
2013-09-11 19:11:31 < Daemon404> same
2013-09-11 19:11:35 < Daemon404> the otehrs have very generic names
2013-09-11 19:21:35 <@muggs> we have a single static lib now, just not a shared one
2013-09-11 19:22:04 <@muggs> I've put it on my short-term TODO list
--- Day changed Thu Sep 12 2013
2013-09-12 09:26:56 < Daemon404> muggs, ping when you wake up
2013-09-12 09:38:37 <@muggs> Daemon404: I just arrived in Amsterdam
2013-09-12 09:39:37 < Daemon404> muggs, i was initially going to bombard you with some questions, re: overall x265 practices
2013-09-12 09:39:44 < Daemon404> but i think ill send a proper discussion email to the ML
2013-09-12 09:39:59 < Daemon404> so just keep an eye out for it.
2013-09-12 09:39:59 <@muggs> fair enough
2013-09-12 11:03:48 < j-b> Daemon404: 4 spaces, no tabs
2013-09-12 11:04:14 < j-b> Daemon404: but why on x264-devel ?
2013-09-12 11:05:07 < Daemon404> i typo'd the email
2013-09-12 11:05:08 < Daemon404> i fixed it
2013-09-12 11:05:11 < Daemon404> to the proper ML
2013-09-12 11:05:15 < j-b> cool thx
2013-09-12 11:05:35 < Daemon404> dangerous email address is dangerous
2013-09-12 11:45:53 < nevcairiel> i still think that the developers just cba to do it and will continue to work on encoding instead of listening to some FOSS ideals about good looking code =P
2013-09-12 11:46:26 < nevcairiel> functionality -> speed -> pretty code
2013-09-12 11:46:37 < nevcairiel> priorities ^
2013-09-12 11:46:41 < Daemon404> nope
2013-09-12 11:46:49 < Daemon404> speed -> functionality -> pretty code
2013-09-12 11:46:50 < Daemon404> is theirs
2013-09-12 11:46:51 < Daemon404> ;)
2013-09-12 11:46:59 < nevcairiel> in any case, pretty code is last :P
2013-09-12 11:54:36 < BugMaster> and where in the list is stable/bug free code?
2013-09-12 11:55:00 < nevcairiel> who wants that?
2013-09-12 11:55:21 < Daemon404> BugMaster,
2013-09-12 11:55:22 < Daemon404> http://mailman.videolan.org/pipermail/x265-devel/2013-September/000730.html
2013-09-12 11:55:23 < Daemon404> and
2013-09-12 11:55:23 < BugMaster> oh. I forgot that is demo code not production
2013-09-12 11:55:30 < Daemon404> http://mailman.videolan.org/pipermail/x265-devel/2013-September/000731.html
2013-09-12 11:55:36 < Daemon404> feel free add to it
2013-09-12 11:55:54 < BugMaster> I read it already. I am registered at ML
2013-09-12 11:56:03 < Daemon404> ah ok
2013-09-12 11:57:28 < nevcairiel> personally i have nothing against cmake, it just needs a bit more plumbing on the projects side to make stuff a bit easier
2013-09-12 11:57:53 < Daemon404> nevcairiel, cmake is epic pain for cross-compiling
2013-09-12 11:58:03 < Daemon404> and other things
2013-09-12 11:58:11 < nevcairiel> and in contrast to autotools, you can actually read the config files without a masters degree in gnu
2013-09-12 11:58:31 < Daemon404> i simply cannot agere cmake is a better choice :)
2013-09-12 11:58:42 < Daemon404> i used to work on openembedded
2013-09-12 11:58:46 < Daemon404> cmake was the bane of my existence
2013-09-12 11:58:57 < nevcairiel> and i cannot agree that autotools is ever a good choice :P
2013-09-12 11:59:13 < Daemon404> i can only call naiive ;)
2013-09-12 11:59:29 < Daemon404> where's flameyes when you need him
2013-09-12 12:00:09 < nevcairiel> autotools is horrible, and just because some other things may be lacking in some use-cases doesn't actually make it good
2013-09-12 12:00:48 < Daemon404> its by far the least bad
2013-09-12 12:00:58 < nevcairiel> still horrible
2013-09-12 12:01:12 < Daemon404> that doesnt mean you should use even worse systems
2013-09-12 12:01:25 < nevcairiel> if that means i get by without m4, then yes, it does =P
2013-09-12 12:01:43 < Daemon404> i dont agree with the notion
2013-09-12 12:01:47 < Daemon404> m4 is simply a language.
2013-09-12 12:02:21 < nevcairiel> and the fact that a configure system needs its own language is a sign of its failure
2013-09-12 12:02:42 < Daemon404> m4 was not "for configure"
2013-09-12 12:03:02 < Daemon404> its actually the official macro language for POSIX/UNIX
2013-09-12 12:03:21 < BugMaster> cool down. no need for this flame wars here
2013-09-12 12:03:26 < Daemon404> anyway, theres no use arguing with someone who hans texperience the pure pain f dealing with all the other systems
2013-09-12 12:03:31 < Daemon404> at a distro level
2013-09-12 12:03:32 < Daemon404> ;)
2013-09-12 12:03:36  * Daemon404 goes to buy soem kebab
2013-09-12 12:55:47 <@muggs> Daemon404: I'll try to give that a proper response first thing after a good sleep; I'm wiped
2013-09-12 12:57:12 < Daemon404> ok
2013-09-12 12:58:50 <@muggs> btw: shazeb_, nandaku2, and aarthi are all MCW Chennai engineers (saw them all on for a time, lurking)
2013-09-12 12:59:03 <@muggs> perhaps we need a wiki page to identify each other
2013-09-12 13:39:23 < koda> so anyone at ibc? :)
2013-09-12 13:40:45 < j-b> tomorrow
2013-09-12 13:43:12  * funman tomorrow too
2013-09-12 15:29:28 < Daemon404> http://chromashift.org/tools/linux/divx_mkvtoolnix.7z a windows build of mkvtoolnix with divx's hacked-in hevc support, i ncase anyone can be arsed to fiddle with it
2013-09-12 15:30:29 < Daizz> so apparently divx's hevc encoder is pretty damn terrible
2013-09-12 15:30:43 < Daiz> at least the one they ship out for free
2013-09-12 15:30:48 < Daiz> quality is atrocious
2013-09-12 15:30:52 < Daemon404> yes
2013-09-12 15:30:53 < Daemon404> it is
2013-09-12 15:30:54 < Daemon404> i tested
2013-09-12 15:30:58 < Daemon404> it did better than x265 though
2013-09-12 15:31:03 < Daemon404> currently.
2013-09-12 15:31:06 < Daiz> really
2013-09-12 15:31:12 < Daemon404> i was gonna make some pretty graphs
2013-09-12 15:31:13 < Daiz> the shots I saw looked like total garbage
2013-09-12 15:31:15 < Daemon404> for doom9
2013-09-12 15:31:30 < Daiz> whereas x265 is actually faring pretty nicely
2013-09-12 15:31:32 < Daiz> though well
2013-09-12 15:31:36 < Daiz> with a build I made yesterday
2013-09-12 15:31:45 < Daiz> x265 --no-strong-intra-smoothing -q 20
2013-09-12 15:31:55 < Daiz> looks worse than x264-10bit --preset veryslow --tune animation
2013-09-12 15:31:57 < Daiz> at the same bitrate
2013-09-12 15:32:05 < Daemon404> Daiz, http://chromashift.org/x265_parkrun_2000kbit.avi
2013-09-12 15:32:16 < Daemon404> heres x265 at 2000 kbit/s ABR
2013-09-12 15:32:26 < Daemon404> (transcoded to utvideo so you can actually view it)
2013-09-12 15:32:28 < Daiz> but at least banding-wise it looks better than a good while back
2013-09-12 15:32:47 < Daiz> is 10-bit encoding still borked in x265?
2013-09-12 15:32:52 < Daemon404> probably
2013-09-12 15:32:54 < Daemon404> i tested 8 bit
2013-09-12 15:32:57 < Daiz> me too
2013-09-12 15:34:34 < Daemon404> hmm a stream i created with divx makes HM segfault 3 frames in
2013-09-12 15:34:52  * Daemon404 bets he must fine the Correct Compatible HM Revision
2013-09-12 15:35:20 < Daemon404> yup.. 11 worky, 12 no worky
2013-09-12 15:35:21 < Daiz> also x265 managed to crash at the last frame of my test encode
2013-09-12 15:35:26 < JEEBsv> SAO related stuff
2013-09-12 15:35:59 < JEEBsv> because SAO changed before 11 and 12
2013-09-12 15:36:09 < Daemon404> yea
2013-09-12 15:36:15 < Daemon404> x265 works with HM12
2013-09-12 15:36:18 < Daemon404> fun
2013-09-12 15:36:35 < JEEBsv> oh, divx? dunno about that :D
2013-09-12 15:36:40 < j-b> seriously... Isn't HEVC supposed to be finished?
2013-09-12 15:36:44 < JEEBsv> yes
2013-09-12 15:36:45 < JEEBsv> spec is
2013-09-12 15:36:52 < Daemon404> JEEBsv, yes divx needs HM11
2013-09-12 15:36:52 < JEEBsv> HM just has all kinds of random crap in there
2013-09-12 15:36:57 < Daemon404> x265 needs 12
2013-09-12 15:36:57 < Daemon404> :D
2013-09-12 15:38:26 < Daemon404> looks liek x265 explodes on g++ again... meh
2013-09-12 15:38:27 < Daemon404> /mnt/tc/dev/x265/source/common/threading.h:146: error: ‘O_CREAT’ was not declared in this scope
2013-09-12 15:38:30 < Daemon404> /mnt/tc/dev/x265/source/common/threading.h:146: error: ‘O_EXCL’ was not declared in this scope
2013-09-12 15:38:40 < JEEBsv> Daiz: also you might be interested about http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html too
2013-09-12 15:39:10 < Daiz> anyway, looking a bit, it seems like x265 is faring much better with gradients now than the last time I tested
2013-09-12 15:39:12 < Daiz> http://screenshotcomparison.com/comparison/40825
2013-09-12 15:39:25 < Daiz> (also that should be --no-strong-intra-smoothing)
2013-09-12 15:40:25 < j-b> interesting
2013-09-12 15:40:54 < Daemon404> Daiz, im rebuilding/rerunning
2013-09-12 15:40:54 < j-b> Daemon404: threading.h ? Don't we have enough pthread implementations already ?
2013-09-12 15:41:03 < Daemon404> you would think.
2013-09-12 15:41:11 < JEEBsv> :D
2013-09-12 15:41:34 < Daemon404> https://github.com/videolan/x265/commit/a17e57cdcf7bafe4bc460710667424e3e6a3319c
2013-09-12 15:41:38 < Daemon404> reverting this makes it build
2013-09-12 15:41:56 < Daiz> though I didn't compare with strong intra smoothing on yet
2013-09-12 15:41:58 < Daiz> I'll do that now
2013-09-12 15:42:04 < Daemon404> altenratively
2013-09-12 15:42:08 < Daemon404> include <sys/stat.h>
2013-09-12 15:42:31 < Daemon404> i will send a patch
2013-09-12 15:56:14 < Daiz> strong intra smoothing doesn't seem to really make a difference banding-wise
2013-09-12 15:58:42 < Daemon404> patch sent
2013-09-12 15:58:45 < Daemon404> man i hate hg
2013-09-12 15:59:09 < JEEBsv> I have to have a git-hg thing open in a tab all the time
2013-09-12 15:59:16 < Daemon404> well i wanted to use hg email
2013-09-12 15:59:20 < Daemon404> so they could apply it
2013-09-12 15:59:34 < JEEBsv> :D
2013-09-12 16:00:25 < Daemon404> basically: work in git -> patch -p1 < 000N-xxx.patch && hg commit && hg email
2013-09-12 16:00:28  * Daemon404 ashamed
2013-09-12 16:12:10 < spaam> Nice mail to x264 :)
2013-09-12 16:13:03 < JEEBsv> it's after all relatively easy to typo
2013-09-12 16:13:30 < spaam> yes :)
2013-09-12 16:15:28 < Daemon404> j-b && funman -- whats the status of buildbots?
2013-09-12 16:15:37 < Daemon404> would be nice if it didnt break on linux every 2nd day for me
2013-09-12 16:18:42 < j-b> Daemon404: well, doing that this week-end, but it will be on hg.v.o
2013-09-12 16:19:27 < Daemon404> i figured
--- Day changed Fri Sep 13 2013
2013-09-13 06:13:14 < Nabajit> Can I directly use the rN registers as loop counters in asm code?
2013-09-13 06:19:30 <@Skyler_> Yes, though generally you want to use rNd, as loop counters only need to be 32-bit.
2013-09-13 06:19:39 <@Skyler_> a very common construct looks like this:
2013-09-13 06:19:44 <@Skyler_> mov r4d, 4
2013-09-13 06:19:45 <@Skyler_> .loop:
2013-09-13 06:19:47 <@Skyler_> <stuff>
2013-09-13 06:19:50 <@Skyler_> dec r4d
2013-09-13 06:19:53 <@Skyler_> jg .loop
2013-09-13 06:19:58 <@Skyler_> (for various values of r4d and 4)
2013-09-13 06:25:28 < Nabajit> ok..
2013-09-13 06:26:43 < Nabajit> isnt by default rN registers are 32 bit
2013-09-13 06:38:47 < Nabajit> Ok I got it  rN is 32 or 64 bits, depeneding on OS,  rNd is 32 bits
2013-09-13 06:51:32 <@Skyler_> rN is native size, yes
2013-09-13 06:51:44 <@Skyler_> so if you need a pointer, use "r0", if you need an int, use "r0d"
2013-09-13 06:53:10 < min_chen> if you use 'hg email', you need turn on 'patchbomb' extensions, I waste some time here.
2013-09-13 07:00:08 < Nabajit> ok..thanks
2013-09-13 09:52:34 < nandaku2> Hello.
2013-09-13 09:53:50 < nandaku2> I'd like some suggestions on the best way to handle patches submitted by developers. To incorporate feedback, do they strip their local hg repos?
2013-09-13 09:55:07 < nandaku2> Supposing they submit patch1 (which is under review), and plan to work on patch2 (which is based on patch1) - whats the best way?
2013-09-13 09:57:09 < Daemon404> nandaku2, it depends how long patch2 can take
2013-09-13 09:57:21 < Daemon404> if it's short, you can send the as a set
2013-09-13 09:57:47 < Daemon404> otherwise, you can work on patch2 and rebasee (or... what's the hg term of this?) on top of any changes to patch1
2013-09-13 09:58:09 < Daemon404> they can still be reviewed simultaniously, but you should explicitly note it in your email (or patch2)
2013-09-13 10:00:57 < nandaku2> ok.. Until now, patch1 submission, patch1 review, patch2 development, patch2 sub.... etc happened in almost sequential fashion
2013-09-13 10:01:44 < nandaku2> patch2 submission will be fine, if patch1 has been accepted and pushed. Then, they could simply rebase, like you suggested.
2013-09-13 10:02:22 < Daemon404> yes
2013-09-13 10:02:35 < nevcairiel> does hg have rebase? i thought it didn't
2013-09-13 10:02:44 < Daemon404> i does if you use a plugin/extension
2013-09-13 10:02:50 < Daemon404> or do what i do, and use git-hg
2013-09-13 10:02:51 < Daemon404> :P
2013-09-13 10:02:51 < nevcairiel> so thats a no
2013-09-13 10:04:11 < Daemon404> man im ding so many reviews
2013-09-13 10:04:19 < Daemon404> this is so unlike me... somethign must be wrong with my brain
2013-09-13 10:05:35 < nandaku2> just curious, what does LGTM mean?
2013-09-13 10:06:08 < Daemon404> Looks Good To Me
2013-09-13 10:06:25 < nandaku2> ok
2013-09-13 10:07:11 < nandaku2> So, in 2 of the earlier patches which were reviwed and which I will push in now- there is a bit of fuzz
2013-09-13 10:07:34 < Daemon404> if it applies cleanly with fuzz, it's fine.
2013-09-13 10:07:40 < Daemon404> i don't know much about hg...
2013-09-13 10:07:44 < Daemon404> im a git man.
2013-09-13 10:09:58 < nandaku2> Instead of a long-winded description, I will push it in  (with what I hope is a very clear commit message) - pls review and let us know how we can do it better next time.
2013-09-13 10:10:24 < Daemon404> if it's been OK'd, then it's fine
2013-09-13 10:12:22 < nandaku2> pushed
2013-09-13 10:12:59 < Daemon404> ok
2013-09-13 10:13:03 < Daemon404> i only have one comment on it
2013-09-13 10:13:04 < Daemon404> https://bitbucket.org/multicoreware/x265/commits/fc32e3804b8b2a3d22e37ea930db0fdfc3ea4ac3
2013-09-13 10:13:12 < Daemon404> teh author should be ste to Gopu
2013-09-13 10:13:14 < Daemon404> set*
2013-09-13 10:13:36 < nandaku2> is there a way that can be changed now?
2013-09-13 10:13:53 < Daemon404> not now
2013-09-13 10:14:07 < Daemon404> just saying to do that in the future
2013-09-13 10:14:26 < Daemon404> btw: https://patches.videolan.org/project/x265-devel/list/
2013-09-13 10:14:36 < Daemon404> if you didnt know about it.
2013-09-13 10:14:46 < Daemon404> makes it easier to grab patches
2013-09-13 10:14:53 < nandaku2> yep - tried to remedy it somewhat by adding [Gopu] in commit message.
2013-09-13 10:15:04 < nandaku2> yep, we use it, yes.
2013-09-13 10:15:07 < Daemon404> ok
2013-09-13 10:15:23 < Daemon404> there's a way to apply the author automatically in hg
2013-09-13 10:15:26 < Daemon404> i just dont know...
2013-09-13 10:15:29 < Daemon404> ask steve.
2013-09-13 10:16:12 < nandaku2> The commit message had to be changed - thats why the author also changed automatically.
2013-09-13 10:16:33 < Daemon404> hmm
2013-09-13 10:17:02 < nandaku2> Anyway, next time, the patches will be based on the tip (instead of on top of each other, as this one was)
2013-09-13 10:17:06 < Daemon404> hmm
2013-09-13 10:17:11 < Daemon404> did you use `hg comit --amend` ?
2013-09-13 10:17:18 < Daemon404> i think that keeps the author
2013-09-13 10:17:25 < Daemon404> s/comit/commit/
2013-09-13 10:17:46 < Daemon404> ah... right. i forgot hg doesnt have rebase.
2013-09-13 10:20:34 < nandaku2> should check with steve. I used rollback and commit again...
2013-09-13 10:21:17 < Daemon404> yeah
2013-09-13 10:21:21 < Daemon404> i dont know hg very well.
2013-09-13 10:25:04 < nandaku2> https://bitbucket.org/multicoreware/x265/wiki/IRC
2013-09-13 10:25:15 < nandaku2> would be good if all interested developers added themselves here
2013-09-13 10:25:48 < nandaku2> Chennai team, pls do the honours (Gopu, Shazeb.. whoever is online)
2013-09-13 10:26:38 < Daemon404> btw: I'm Derek on the list.
2013-09-13 10:26:43 < Daemon404> if it wasn't obvious.
2013-09-13 10:28:09 < greenfountain> quite obvious
2013-09-13 10:28:23 < Daemon404> figured so.
2013-09-13 10:31:04 < quaz0r> i am the great cornholio
2013-09-13 10:31:34 < Cracker> I am Gopu
2013-09-13 10:33:40 < BugMaster> there is histedit extension in hg which is similar to git rebase --interactive if you want to change comments or reorder commits. but it is for cli use only (no support in TortoiseHg GUI which probably most of developers use)
2013-09-13 10:34:20 < Daemon404> BugMaster, it's easier to just use git-hg
2013-09-13 10:34:33 < Daemon404> or https://github.com/videolan/x265
2013-09-13 10:34:37  * Daemon404 runs
2013-09-13 10:35:55 < BugMaster> for x265 may be. but at work where we currently start to use Hg no. So it is from my small experience with Hg at work.
2013-09-13 10:36:05 < Daemon404> ah
2013-09-13 10:36:18 < Daemon404> we use a local github enterprise install at work... i am lucky.
2013-09-13 10:39:56 < nandaku2> thanks, will check out histedit
2013-09-13 10:40:48 < BugMaster> also may be it is possible with MQ patches but I am not good with it
2013-09-13 10:42:06 < BugMaster> anyway it probably better to ask muggs because he for sure have much better expirience with Hg
2013-09-13 10:43:13 < shazeb> I too hail from x265 Chennai Team, usrname is my name itself
2013-09-13 10:46:27 < Nabajit> Myself also from Chennai team..
2013-09-13 15:30:30 < Daemon404> some POSIX  fixes coming
2013-09-13 15:30:32 < Daemon404> % file ./x265
2013-09-13 15:30:32 < Daemon404> ./x265: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.1, not stripped
2013-09-13 15:30:35 < Daemon404> :)
2013-09-13 16:05:17 < Daemon404> moser, ping
2013-09-13 16:05:22 < Daemon404> oh muggs isnt online
2013-09-13 16:30:33 < roxlu> Daemon404: ping ;-)
2013-09-13 20:20:45 < funman> Daemon404: some say they met muggs at ibc
2013-09-13 20:22:05 < Daemon404> i knew he was at ibc
--- Day changed Sat Sep 14 2013
2013-09-14 15:30:29 <@muggs> anyone know where the videolan meetup is at IBC?
2013-09-14 15:31:03 < JEEB> poking j-b and kierank might be a good idea regarding that
2013-09-14 15:31:18 <@muggs> I sent J-b an email
2013-09-14 15:31:28 <@muggs> j-b: ping
2013-09-14 15:31:44 <@muggs> kierank: ping
2013-09-14 15:36:10 < kodabb> muggs, it's in Open Broadcast Systems booth
2013-09-14 15:36:41 < kodabb> muggs,  4.A61g in the UK area
2013-09-14 15:37:23 <@muggs> kodabb: thanks!
2013-09-14 22:20:50 < kierank> muggs: yeah i don't have irc at ibc
--- Day changed Sun Sep 15 2013
--- Day changed Mon Sep 16 2013
2013-09-16 09:27:02 < Cracker> Daemon404, we are planing to have our own list implementation with limitted and API Support(basic push, pop, remove ..etc) in x265 std::list replacement,
2013-09-16 09:27:54 < Cracker> can i move the list.h into commom or need have separate folder structure like util
2013-09-16 09:29:00 < j-b> I think util/ would be nice
2013-09-16 09:32:50 < Cracker> ok .., and x265 using splice API from list .., its just transfering the element from one list to another list for that we have provide the implementation or we can achive without splice implementation
2013-09-16 09:33:31 < Cracker> i mean we can traverse the list and transfer to anothr list
2013-09-16 09:33:59 < Daemon404> that sounds rather slow
2013-09-16 09:34:08 < Daemon404> there would be no benefit to using a list at all then
2013-09-16 09:35:15 < j-b> depends if it is a list of elements or pointer to elements :)
2013-09-16 09:36:50 < Cracker> I think its a list of elements ..,
2013-09-16 12:51:03 < SagarG> Sagar ^_^
2013-09-16 12:52:52 < SagarG> > shazeb = Sagar < :D
2013-09-16 18:11:38 < j-b> https://github.com/taglib/taglib/blob/master/CMakeLists.txt
2013-09-16 18:11:41 < j-b> https://github.com/taglib/taglib/blob/master/taglib/taglib_export.h
2013-09-16 18:11:50 < j-b> Daemon404: this is a sample for taglib
2013-09-16 18:12:13  * Daemon404 reads
--- Day changed Tue Sep 17 2013
2013-09-17 09:02:31 < nandaku2> Has anyone here working knowledge of ratecontrol for x264?
2013-09-17 09:03:42 < nandaku2> we're focussing on a) finalise the ABR algorithm b)ABR support with frame parallelism enabled
2013-09-17 09:08:18 < BugMaster> be more specific what you want to know about x264 RC and may be I will try to explain it
2013-09-17 09:09:50 < nandaku2> So how does rate control in x264 sync between multiple threads? our ABR algorithm requires the exact no. of bits for previous frame
2013-09-17 09:10:00 < nandaku2> for complexity summation
2013-09-17 09:14:19 < BugMaster> it doesn't sync it in this way. the real bit budget of frames currently in process is unknown in general (in case of VBV it is predicted and have some synchronization but it is still no bit exact because this prediction)
2013-09-17 09:36:58 < nandaku2> I see some synchronization of the RC state in x264 (x264_thread_sync_ratecontrol),
2013-09-17 09:38:11 < nandaku2> the order in which RC_start is called and estimated bits calculated is serialised then?
2013-09-17 09:41:45 < BugMaster> x264_thread_sync_ratecontrol is called to sync data of already finished frames or the values we set in x264_ratecontrol_start of previous frame
2013-09-17 09:42:18 < BugMaster> not the frames that are in the fly
2013-09-17 09:44:57 < BugMaster> as I said frames in the fly are only used in case of VBV iirc i.e. look at update_vbv_plan
2013-09-17 09:45:25 < BugMaster> and clip_qscale
2013-09-17 11:50:42  * funman sends git patch
2013-09-17 11:53:40 < spaam> omg
2013-09-17 11:55:48 < Daemon404> funman, i always use git and then patch -p1 in hg
2013-09-17 11:55:50 < Daemon404> and use hg email
2013-09-17 11:55:52 < Daemon404> pain~
2013-09-17 12:32:34 < funman> coding unit is the new macroblock?
2013-09-17 12:40:03 < greenfountain> yes
2013-09-17 12:41:09 < funman> hmm debug mode build fails
2013-09-17 13:03:46 < funman> I can't use thread encoding
2013-09-17 13:03:57 < funman> x265 [info]: WPP streams / pool / frames  : 17 / 8 / 1
2013-09-17 13:05:23 < funman> http://pastie.org/8332932
2013-09-17 16:37:23 < funman> ihttp://git.videolan.org/?p=vlc.git;a=commit;h=f1d6824164a1b33c3befc8ad7e16aa94f866ee04
2013-09-17 16:37:24 < funman> http://git.videolan.org/?p=vlc.git;a=commit;h=f1d6824164a1b33c3befc8ad7e16aa94f866ee04
2013-09-17 16:37:31 < funman> now we need a .pc file
2013-09-17 16:37:53 < Daemon404> and shared libs
2013-09-17 16:37:56 < Daemon404> and a versioned API
2013-09-17 16:38:30 < nevcairiel> you should let them finish the first version before you version it =P
2013-09-17 16:38:51 < Daemon404> indeed
2013-09-17 16:39:08 < greenfountain> hi, in x264 -         /* estimated ratio that produces a reasonable QP for the first I-frame */
2013-09-17 16:39:08 < greenfountain>         rc->cplxr_sum = .01 * pow( 7.0e5, rc->qcompress ) * pow( h->mb.i_mb_count, 0.5 );
2013-09-17 16:39:12 < greenfountain> how was this derived
2013-09-17 19:27:58 <@Skyler_> @greenfountain probably wild guessing
2013-09-17 19:28:03 <@Skyler_> It's extremely old code though
2013-09-17 19:28:14 <@Skyler_> check git blame or something; I can imagine it's as old as 2004
2013-09-17 20:44:34 < Daemon404> could have been bruteforced
2013-09-17 20:49:50 < smarter> it's not a real encoder until there's a hundred hand-tuned constants
2013-09-17 20:50:13 < Daemon404> smarter, there are some nice legends
2013-09-17 20:50:28 < Daemon404> like pengvado using clusters to bruteforce good numbers
2013-09-17 20:50:33 < Daemon404> and good params for encodes
2013-09-17 20:56:20 < Mandarinka> it was just because ffmpeg's ASP encoder was horrible :) </troll>
2013-09-17 20:56:25 < Mandarinka> *is
2013-09-17 20:58:02 < Daemon404> i still have his encode
2013-09-17 20:58:06 < Daemon404> oh wait, no i dont
2013-09-17 20:58:13 < Daemon404> i threw out my cd-ro backups when i moved
--- Day changed Wed Sep 18 2013
2013-09-18 11:50:12 < elfring> I have looked a bit at the source files.
2013-09-18 11:50:14 < elfring> https://bitbucket.org/multicoreware/x265/src/1c66f40da3e9/source/x265.h#cl-157
2013-09-18 11:50:15 < elfring> Would you like to replace more defines for constant values by enumerations to stress their relationships?
2013-09-18 11:51:34 < JEEB> an enum would indeed be another way of doing those
2013-09-18 11:57:04 < elfring> Are bug reports also discussed on this communication channel?
2013-09-18 12:00:21 < JEEB> developers are here at times, muggs is the US guy and then there's people from the chennai office at least. Since I can't see an issue tracker yet, I would say that sending an e-mail to x265-devel mailing list isn't exactly incorrect either. It is much more looked upon it seems
2013-09-18 12:06:11 < elfring> How do you think about corrections for the signal handler?
2013-09-18 12:06:12 < elfring> https://bitbucket.org/multicoreware/x265/src/d11de33521cf/source/x265.cpp#cl-79
2013-09-18 12:14:26 < Daemon404> my reviews will be late today... forgot to turn on my box with my email client
2013-09-18 12:15:31 < j-b> JEEB: <3
2013-09-18 12:15:44 < JEEB> :D
2013-09-18 12:15:53 < JEEB> inb4 he just did a copypasta mistake tho
2013-09-18 12:15:56 < JEEB> in the message
2013-09-18 12:16:04 < JEEB> but I kind of...
2013-09-18 12:16:21 < JEEB> had to reply to it >_>
2013-09-18 12:16:59 < j-b> yeah, thx
2013-09-18 12:17:16 < j-b> in video decoding and encoding, OOM is not a weird chimera that never happens
2013-09-18 12:17:45 < JEEB> aye
2013-09-18 12:17:54 < elfring> https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers
2013-09-18 12:19:15 < JEEB> elfring, since there is no issue tracker I would voice my concerns on the mailing list in the case of the MCW folk not being active at that point of time
2013-09-18 12:19:28 < JEEB> https://mailman.videolan.org/listinfo/x265-devel
2013-09-18 12:23:40 < mahesh_> What is the numCulPartsLevel in SAO, it has total 5 levels each having some value in increasing order.
2013-09-18 12:28:32 < j-b> wow, I really hate his MTA
2013-09-18 12:31:01 < JEEB> mahesh_, can't find that naming from the spec
2013-09-18 12:32:16 < JEEB> ok, it's in the SAO-related code
2013-09-18 12:33:25  * JEEB curses hg grep not having the C option to show lines around the found line
2013-09-18 12:35:19 < JEEB> it seems to set the amount of something per-level
2013-09-18 12:35:34 < JEEB> or well, define
2013-09-18 12:36:56 < mahesh_> its definition is in TComSampleAdaptiveOffset.cpp
2013-09-18 12:37:00 < JEEB> yes
2013-09-18 12:40:27 < mahesh_> depending upon the value of the level in m_numCulPartsLevel, the m_numTotalParts is set I dont what m_numTotalParts means
2013-09-18 12:44:50 < JEEB> as far as I can see it defines the amount of something to at least 3. and then it is used for memory allocation and looping through some things
2013-09-18 12:45:25 < JEEB> http://up-cat.net/p/2e19090d
2013-09-18 13:34:47 < funman> elfring should learn about patches :)
2013-09-18 14:48:52 < spaam> funman: write a mail to the person and say it :)
2013-09-18 14:58:02 < BugMaster> signal handling is probably direct copy from x264 and in x265 b_exit_on_ctrl_c is never set to true so this exit() never really happen
2013-09-18 19:12:41 < Daemon404> hey
2013-09-18 19:12:54 < Daemon404> muggs, ive been meaning to ask: whats with the UInt stuff
2013-09-18 19:14:01 < muggs> the HM define Capitalized data types and used them everywhere, Int, Bool, Void, etc
2013-09-18 19:14:31 < muggs> I've nuked most of them, UInt is one of the stragglers
2013-09-18 19:15:02 < Daemon404> using stdint?
2013-09-18 19:15:22 < muggs> int, bool, void.
2013-09-18 19:15:34 < muggs> I plan to replace UInt with uint32_t
2013-09-18 19:15:52 < JEEB> yeah, even MSVC has that header nowadays \o/
2013-09-18 19:16:13 < radek> A success for all embedded systems engineers everywhere, I imagine.
2013-09-18 19:16:13 < JEEB> inttypes.h was missing for a while, but now even that is around AFAIK
2013-09-18 19:16:28 < Daemon404> radek, ill change them all to long and long long
2013-09-18 19:16:29 < Daemon404> just for you
2013-09-18 19:16:31 <@Skyler_> UInt should probably be "unsigned" or "unsigned int"
2013-09-18 19:16:37 < radek> I find that applications that don't have efficiency constraints don't use those types.
2013-09-18 19:16:47 <@Skyler_> IMO you should only use "uint32_t" and other fixed-size types when you actually specifically need a type of a specific size
2013-09-18 19:16:52 < radek> Daemon404: I'm not complaining, I'm rejoicing.
2013-09-18 19:16:52 <@Skyler_> just for clarity's sake, at least
2013-09-18 19:17:05 < Daemon404> Skyler_, well it's also a microoptimization technically
2013-09-18 19:17:10 < Daemon404> "int performs better!!!"
2013-09-18 19:17:14 < radek> I like to know what sizes are my types.
2013-09-18 19:18:38 <@Skyler_> basically "C types when it doesn't matter, fixed size types when it does"
2013-09-18 19:19:15 <@Skyler_> but if you want to use fixed-size types where it doesn't matter that's probably okay, though I think performance wise using <32-bit fixed types in such cases can be bad
2013-09-18 19:19:21 <@Skyler_> at least on x86
2013-09-18 19:19:38 < radek> Yeah, I actually don't code on x86 at all.
2013-09-18 19:19:54 <@Skyler_> I think it's potentially worse on non-x86
2013-09-18 19:19:59 < radek> So all of my opinions are biased towards writing code that's architecture independent.
2013-09-18 19:20:26 <@Skyler_> e.g. not all CPUs can natively deal with 8-bit values (they might have to constantly play the sign extension game)
2013-09-18 19:20:46 < radek> Haven't looked at it that way, huh.
2013-09-18 19:21:02 <@Skyler_> I notice even gcc on x86 often generates worse code if you try to make all your local variables the smallest possible size (instead of just using int)
2013-09-18 19:21:20 < radek> Seems counter-intuitive.
2013-09-18 19:21:23 <@Skyler_> I can see doing it from an Ada-esque perspective (explicitly stating the ranges of your variables, or, well, at least getting a little closer to that)
2013-09-18 19:21:43 <@Skyler_> well the reason is because the overflow rules are different, I think
2013-09-18 19:21:50 < muggs> probably helps automated code verifiers
2013-09-18 19:21:53 <@Skyler_> like, uint16_t x;  uint16_t y;   z = x * y;
2013-09-18 19:21:59 <@Skyler_> gcc isn't allowed to pretend x and y are 32-bit
2013-09-18 19:22:07 <@Skyler_> because that wouldn't give the same result, IIRC?
2013-09-18 19:23:05 <@Skyler_> so I guess the general rule I always learned was use int for ordinary local variables because it's usually a size the system/compiler likes
2013-09-18 19:23:12 <@Skyler_> (like loop indices)
2013-09-18 19:23:26 <@Skyler_> but I guess really none of it is that big a deal, it doesn't matter too much.
2013-09-18 19:23:47 < radek> It's fun to discuss, though. ;)
2013-09-18 19:23:54 < muggs> Skyler_: Markus Elfring thinks the x264 SIGINT handler is dangerous by calling exit()
2013-09-18 19:24:29 < radek> Skyler_: little things like that are, for some people, good job interview questions.
2013-09-18 19:24:57 < Daemon404> radek, when i interviewed for my prvious job working on yocto/openembedded
2013-09-18 19:25:01 < Daemon404> my main question was
2013-09-18 19:25:04 < Daemon404> "why do you hate gcc?"
2013-09-18 19:25:15 < Daemon404> thats pretty sufficient for embedded devs i think ;)
2013-09-18 19:25:26 < muggs> lol
2013-09-18 19:27:31 < radek> Unfortunately I'm not experienced with gcc enough to understand the joke. :/
2013-09-18 19:28:12 < radek> What are the particularly hateworthy features of gcc?
2013-09-18 19:28:14 < muggs> familiarity breeds contempt
2013-09-18 19:28:38 < radek> Yeah, a lot of people learn to hate tools over time.
2013-09-18 19:29:34 < Daemon404> the gcc broken code generator
2013-09-18 19:35:28 < muggs> back to Daemon404's original point:  UInt is currently defined "typedef unsigned int   UInt;"
2013-09-18 19:35:39 < muggs> should I change that?
2013-09-18 19:37:01 < muggs> there's similar UChar an UShort defines
2013-09-18 19:38:58 < Daemon404> UShort seems evil
2013-09-18 19:39:04 < Daemon404> short in general
2013-09-18 19:40:13 < muggs> true; it is assumed to be 16bits in all our code
2013-09-18 19:41:37 <@Skyler_> personally I don't like using short or long anywhere
2013-09-18 19:41:42 <@Skyler_> char is kind of evil unless it's for actual strings/chars
2013-09-18 19:41:53 <@Skyler_> muggs: what's the reason he doesn't like the handler?
2013-09-18 19:42:47 <@Skyler_> (I say char is kind of evil because I spent a day hunting down a bug caused by char being used as a pixel data type)
2013-09-18 19:42:52 <@Skyler_> (signedness.)
2013-09-18 19:42:59 < muggs> he says it's not safe to use exit() there, it should be _exit() or some other mechanism
2013-09-18 19:43:45 <@Skyler_> what's the difference?
2013-09-18 19:44:14 <@Skyler_> oh, I see, so exit() isn't necessarliy okay in a signal handler
2013-09-18 19:44:48 < muggs> looking for uses of UChar, they all appear to be 8bit storage of recursion depths and partition ids.  the HM has Pel for storing pixels
2013-09-18 19:45:10 < funman> hi
2013-09-18 19:45:43 < muggs> Hi funman
2013-09-18 19:46:05 <@Skyler_> uchar is probably an okay thing, char is just kinda evil <.<
2013-09-18 19:46:22 < muggs> yeah, agreed
2013-09-18 19:48:01 < funman> hmm i receive SF Markus emails but not the ones he's answering to
2013-09-18 19:48:27 < muggs> uh oh.
2013-09-18 19:48:39 < funman> muggs: are you sending PMs ? :)
2013-09-18 19:49:47 < muggs> that's not my intention..
2013-09-18 19:50:27 < muggs> no.. the to: in my replies is x265@videolan.org.  not sure why you're not getting them
2013-09-18 19:51:12 < funman> in Fix signal handler I only received <CACD6pqO9_AtxjD12yebMT73B5bq6j1FcsqM_UD8QbM0w683LGw@mail.gmail.com> from you
2013-09-18 19:52:12 < funman> http://mailman.videolan.org/pipermail/x265-devel/2013-September/thread.html
2013-09-18 19:52:16 < funman> oh.. he's talking alone
2013-09-18 20:04:45 < muggs> funman: http://tny.cz/dd019493
2013-09-18 20:04:56 < BugMaster> imho we could remove b_exit_on_ctrl_c case in x264 also. it only used with HAVE_VISUALIZE (doubt anyone really use this also) and I am dunno why it need fast exit in this case
2013-09-18 20:05:54 < BugMaster> only if this is some way of go out of some infinite loop in visualization
2013-09-18 20:06:00 < funman> muggs: why not abort() ? Can a release build still run in this state?
2013-09-18 20:06:47 < funman> muggs: ah btw can you give me the error you have when pushing on videolan.org repo?
2013-09-18 20:07:08 < muggs> sorry, on the phone for a bit
2013-09-18 20:43:42 < muggs> funman: http://tny.cz/bb6a846d
2013-09-18 20:44:40 < funman> muggs: nice, works for me
2013-09-18 20:44:51 < muggs> ok, thanks
2013-09-18 20:48:27 < muggs> funman: oops, I was trying to repro the push failure and it actually worked
2013-09-18 20:50:06 < funman> muggs: =)
2013-09-18 21:03:10 < muggs> off the phone finally
--- Day changed Thu Sep 19 2013
2013-09-19 09:41:56 < plonk420> does divx watch this channel?
2013-09-19 09:42:12 < koda> why
2013-09-19 09:42:25 < plonk420> just wanted to upload some random encode sample
2013-09-19 09:44:35 < JEEB> I don't really see why DivX would be watching this channel, it's a completely separate vendor after all
2013-09-19 09:47:58 < plonk420> should be done uploading in ~30 mins http://desu.xxx/screenshots/3x01-1800-split-001.mkv
2013-09-19 09:49:29 < plonk420> anyone screwed around with the divx encoder? i'm getting flashes during the playback (avisynth script SEEEEMS good)
2013-09-19 09:50:27 < plonk420> or should Other Encoder talk be done elsewhere?
2013-09-19 09:50:29 < JEEB> the divx encoder doesn't seem to be too promising, its rate control seems to always hit under and the compression doesn't seem too good.
2013-09-19 09:53:50 < koda> JEEB, btw how did you demux it?
2013-09-19 09:56:14 < JEEB> koda, the cli encoder of theirs gives out Annex B
2013-09-19 09:56:46 < JEEB> although if you build your own mkvtoolnix with my or divx's repo you'd be able to demux an annex b stream out of the mkv file
2013-09-19 11:38:36 < Praveen_> %macro SECTION_RODATA 0-1 16
2013-09-19 11:38:36 < Praveen_>     SECTION .rodata align=%1
2013-09-19 11:38:37 < Praveen_> %endmacro why 0-1 in x264 sad-a.asm file ? Nasm syntax manula says macro parameter range can't be zero.
2013-09-19 11:39:09 < Daemon404> Praveen_, x264 requires YASM, not NASM
2013-09-19 11:39:17 < Daemon404> look at libav perhaps
2013-09-19 11:39:19 < Daemon404> it supports NASM
2013-09-19 11:39:50 < Praveen_> doees YASM allows macro with zero range?
2013-09-19 11:39:57 < Praveen_> *does
2013-09-19 11:40:11 < nevcairiel> obviously, since it works :p
2013-09-19 11:43:50 < Praveen_> what is role of ARCH_X86_64?
2013-09-19 11:45:09 < nevcairiel> it identifies the x86_64 architecture?
2013-09-19 11:45:42 < nevcairiel> also known as amd64 or em64t or x64
2013-09-19 11:49:55 < Daemon404> btw i wrote libx265.c for libavcodec
2013-09-19 11:49:58 < Daemon404> but i havent added it yet
2013-09-19 11:50:06 < Daemon404> sinc teh api is not versioned properly
2013-09-19 11:55:31 < Daemon404> hmm
2013-09-19 11:55:34 < Daemon404> <stdint> is c++11 only?
2013-09-19 11:55:39 < Daemon404> er <cstdint>
2013-09-19 11:55:40 < Daemon404> lul
2013-09-19 11:58:54 < Praveen_> %macro SECTION_RODATA 0-1 16
2013-09-19 11:58:54 < Praveen_>     SECTION .rodata align=%1
2013-09-19 11:58:54 < Praveen_> %endmacro whic kind of alingment is done here?
2013-09-19 11:59:52 < Praveen_> I mean align=%1
2013-09-19 12:00:32 < Praveen_> why it is done so/
2013-09-19 12:02:21 < Praveen_> why different sections need alingment?
2013-09-19 12:06:42 < Daemon404> Praveen_, some instruction sets need different amounts of alignment
2013-09-19 12:06:45 < Daemon404> perhaps that is why.
2013-09-19 12:31:38 < Praveen_> what movu does?
2013-09-19 12:32:55 < Daemon404> see http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=5cc926a4dad3b73da4458a54b194c926f91cacd3
2013-09-19 13:35:02 < Daemon404> perhaps Skyler_ or pengvado can review the asm
2013-09-19 13:40:40 < BugMaster> imho if you want named params in asm it is better to use this feature of cglobal than make defines
2013-09-19 13:41:08 < Daemon404> i did wonder about that.
2013-09-19 13:41:50 < BugMaster> btw. I also doubt this names improve readability
2013-09-19 13:42:18 < Daemon404> can you reply on the ML?
2013-09-19 13:42:25 < Daemon404> or should i forward your comments
2013-09-19 13:44:37 < BugMaster> can't we simply ping Praveen_ here?
2013-09-19 13:44:56 < Daemon404> true
2013-09-19 14:22:02 <@Skyler_> did someone need reviewing asm?
2013-09-19 14:25:39 < Daemon404> first asm patches arrived on x265-devel
2013-09-19 14:27:12 < nevcairiel> i'm not good with cglobal, but that usage looks already weird/wrong
2013-09-19 14:29:09 < Daemon404> yeah
2013-09-19 14:29:15 < kierank> it looks ok
2013-09-19 14:29:24 < kierank> except the first arg
2013-09-19 14:29:29 < kierank> oh and other stuff
2013-09-19 14:29:39 < nevcairiel> the params shouldnt be defines but just put as a list there
2013-09-19 14:30:09 < Daemon404> 31
2013-09-19 14:30:11 < Daemon404> g 31
2013-09-19 14:30:14 < Daemon404> ... dammit
2013-09-19 14:43:38 <@Skyler_> oh, I guess I should really subscribe to that.
2013-09-19 14:44:37 < Daemon404> Skyler_, http://thread.gmane.org/gmane.comp.video.x265.devel/170
2013-09-19 14:45:38 <@Skyler_> "leftmask" can be replaced with an unaligned load from a smaller table, I think
2013-09-19 14:45:51 <@Skyler_> "movq" should probably be "movh"
2013-09-19 14:46:12 < Daemon404> its dev left the channel
2013-09-19 14:46:18 <@Skyler_> :/
2013-09-19 14:46:30 < Daemon404> i can forward a review
2013-09-19 14:46:31 < Daemon404> if you want
2013-09-19 14:46:33 < Daemon404> to the ML
2013-09-19 14:46:42 <@Skyler_> can you forward it to my email and I'll respond with a review?
2013-09-19 14:46:46 <@Skyler_> I didn't have the ML subscribed to
2013-09-19 14:46:58 < Daemon404> jason@x264?
2013-09-19 14:47:04 <@Skyler_> yes
2013-09-19 14:47:06 < Daemon404> ok
2013-09-19 14:47:08 <@Skyler_> thanks ^^
2013-09-19 14:48:01 < Daemon404> Skyler_, sent
2013-09-19 14:55:36 <@Skyler_> thanks, I'll finish reviewing it at work
2013-09-19 17:19:28 <@muggs> I've been bugging our asm developers to post their work in progress to the ML; so would appreciate it if someone could review it
2013-09-19 17:41:20 < Daemon404> muggs, skyler is
2013-09-19 17:41:24 < Daemon404> when he gets to work
2013-09-19 17:41:50 <@muggs> cool
2013-09-19 18:20:52 < funman> j-b: pinhg
2013-09-19 19:28:52 <@Skyler_> muggs: okay, rviewing now
2013-09-19 19:29:32 <@Skyler_> I posted a review for the asm
2013-09-19 19:31:09 <@Skyler_> as a general guideline, most of the things I'll post are suggestions -- if I have an idea of a way to do it faster, but it'd be icky or a lot of work or whatever, you don't have to do it.
2013-09-19 19:31:29 <@Skyler_> I just kind of try to throw out ideas and things
2013-09-19 19:40:17 <@muggs> it looks like great feedback; they were probably unaware of all those details.
2013-09-19 19:40:34 <@muggs> we're asm n00bs
2013-09-19 19:46:16 <@Skyler_> no problem, I'm happy to elaborate on anything
2013-09-19 19:46:20 <@Skyler_> the code is really pretty good so far
2013-09-19 19:58:44 <@muggs> thanks; they'll be glad to hear that
2013-09-19 20:08:20 < funman> motivate the troops :D
2013-09-19 20:10:09 <@muggs> getting started on assembly can be demoralizing :)
2013-09-19 20:18:10 <@Skyler_> yeah, I know what you mean >_<
2013-09-19 20:18:31 <@Skyler_> really the code is quite good, like, it's clearly written by people with an algorithmic grasp of assembly rather than naively implementing the "obvious" algorithm without understanding of what's fast
2013-09-19 20:18:47 <@Skyler_> which is what I worry about most, because that's the hardest to teach (it just requires experience, really)
2013-09-19 20:53:37 <@muggs> if this patch is ok, I can push an 0.4 tag: http://mailman.videolan.org/pipermail/x265-devel/2013-September/000926.html
--- Day changed Fri Sep 20 2013
2013-09-20 00:32:08 <@muggs> mystery solved with the push problems to videolan; I had two different ssh keys and didn't realize it.
2013-09-20 05:08:17 < min_chen> yes, leftmask can convert to unaligned load, but we need calculate a offset, I don't worry about memory size, so I use simplest way, ^_^
2013-09-20 05:11:38 < min_chen> maskmovq is a bad select here, it is a expendsive instruction, but I am not more time to design it
2013-09-20 05:14:59 < min_chen> oh, leftmask can reduce to 16 bytes, and read from [tab_leftmask + widthleft - 7]
2013-09-20 05:17:21 < min_chen> to sleep...
2013-09-20 05:43:07 <@Skyler_> maskmovq?  I don't think I ever recommended that...
2013-09-20 05:43:43 <@Skyler_> and yeah, 16 bytes was what I meant, that memmory addressing looks right.
2013-09-20 05:43:46 <@Skyler_> (@min_chen)
2013-09-20 06:05:34 < min_chen> my fault, I forgot I replace maskmovq to pblendvb, the maskmovq live in vector code
2013-09-20 06:06:41 < min_chen> your idea can reduce memory with zero cost, good idea, thanks
2013-09-20 06:26:03 < Praveen_> does rNmp counted in %2; %2 = number of registers used. pushes callee-saved regs if needed.
2013-09-20 06:27:15 < min_chen> I think rNmp count in %1
2013-09-20 06:28:01 < min_chen> I guess if you want to use automatic load, you can use it, I often disable it and load myself
2013-09-20 06:29:10 < Praveen_> any differnce in performance?
2013-09-20 06:31:55 < min_chen> I am not sure, a little, since there a few load instruction
2013-09-20 06:32:07 < min_chen> every instruction ~0.33 cycles
2013-09-20 09:07:55 < dlan> hi, it seems that x265 code lack "make install" target, what should be installed to target system, header file? library? exec image.
2013-09-20 09:28:12 < funman> dlan: libx265.a and x265.h
2013-09-20 09:29:16 < nevcairiel> and any x265 cli binary
2013-09-20 11:49:38 < Praveen_> what are x86inc named parameters?
2013-09-20 12:33:25 < BugMaster> Praveen_: read comments for cglobal and PROLOGUE http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/x86/x86inc.asm;h=a38948551bbc70cd0a7bfb10a219a183d1b577c0;hb=HEAD#l93
2013-09-20 12:33:33 < BugMaster> it have params 4+/5+
2013-09-20 12:36:04 < Praveen_> do u mean %4+/%5+ = list of names to define to registers?
2013-09-20 12:36:18 < BugMaster> yes
2013-09-20 12:43:56 <@Skyler_> min_chen: I always use automatic load unless there's a good reason not to (e.g. I don't need all the input parameters, I'm out of registers)
2013-09-20 12:44:28 <@Skyler_> maskmovq: I know you didn't use it, but to everyone, that should be on a list of instructions to never ever use
2013-09-20 12:44:46 <@Skyler_> beyond being merely kind of slow, there are chips where it can take up to ~1000 clock cycles
2013-09-20 12:47:58 < Praveen_> how %define src r0  will be replced with x86inc named parameters?
2013-09-20 12:51:46 < Praveen_> any replacement for maskmovq? or we have to change at algorithmic level?
2013-09-20 13:06:53 < nevcairiel> you would just put "cglobal name, 5, 5, 5, src, dst, foo, bar, ham", and you have 5 named parameters
2013-09-20 13:12:15 <@Skyler_> I've never in 5+ years come up with a reason to use maskmovq in the first place
2013-09-20 13:12:30 <@Skyler_> if you need to do a pblend, use pblend or the like, or pand/por?
2013-09-20 13:14:32 <@Skyler_> IIRC the reason maskmovq exists is to provide compilers a way to do masked writes to avoid introducing new memory accesses (and thus possibly faults) when doing vectorization
2013-09-20 13:14:43 <@Skyler_> but I can't see it being very useful for hand-written code where you don't need to do that.
2013-09-20 13:18:05 < Praveen_>  "cglobal name, 5, 5, 5, src, dst, foo, bar, ham", and you have 5 named parameters, do we not need %4 argument for it like  "cglobal name, 5, 5, 5, 5, src, dst, foo, bar, ham", and ew have 5 named parameters?
2013-09-20 13:19:28 < nevcairiel> the last argument is optional
2013-09-20 13:19:46 < nevcairiel> it defines stack size you need, but you can skip it if you dont need stack
2013-09-20 13:19:58 < Praveen_> it means both way are correct?
2013-09-20 13:20:59 < nevcairiel> there is only one correct version for the function you write, but yes =)
2013-09-20 13:21:53 < Nabajit> Does it mean that the five params  "src, dst, foo, bar, ham" gets mapped to the 5 regs r0-r4
2013-09-20 13:31:55 <@Skyler_> Nabajit: yes
2013-09-20 13:36:49 < Nabajit> ok..thnaks
2013-09-20 13:39:21 < Nabajit> @Skyler: In the review comments of the asm function, you suggested to move the loop conditions at the end
2013-09-20 13:42:53 <@Skyler_> yes
2013-09-20 13:43:03 < Nabajit> But before entering into any loop , we need to check the condition
2013-09-20 13:43:18 <@Skyler_> why?
2013-09-20 13:43:25 <@Skyler_> Do you call a motion compensation function on zero rows of data?
2013-09-20 13:43:41 <@Skyler_> Unless you do, you don't need to check whether "rows" is zero.
2013-09-20 13:44:10 < Nabajit> ok..
2013-09-20 13:45:03 <@Skyler_> in other words, most asm loops are more like do/while loops than for loops, because you know a priori that the first iteration will always happen.
2013-09-20 13:45:43 < Nabajit> got it now..
2013-09-20 14:55:00 < mraulet> I have one question regarding wpp. You mention that you support wpp bitstreams. Did you try it with a parallel video decoder supporting it?
2013-09-20 15:04:26 < min_chen> good idea, we can use pand and pnand to avoid pblend
2013-09-20 15:07:37 <@Skyler_> min_chen: pblend is faster though (1 uop) if the alternative would be multiple instructions
2013-09-20 15:07:51 <@Skyler_> so I recommend %if cpuflag(sse4) pblend %else alternate instruction sequence %endif
2013-09-20 15:09:43 < min_chen> good, thanks
2013-09-20 15:10:24 < min_chen> now, we have a lot of works need to do, so I think we can assume CPU always SSE4 or higher, if dont so, we can overwrite pointer to old version
2013-09-20 15:13:56 <@Skyler_> you should at least check with the CPU flags like x264 does, e.g. if( we have sse4 ) { load sse4 version }
2013-09-20 15:14:17 <@Skyler_> IMO ssse3 is about the minimum we have to optimize for nowadays
2013-09-20 15:22:49 < min_chen> yes, pmaddubsw require SSSE3
2013-09-20 15:23:24 < min_chen> Steve have series setup functions to check CPU type and fill pointer, so I don't worry about it
2013-09-20 15:47:30 < dlan> funman: nevcairiel: I have no problem to install *.a and x265.h, cli binary manually, but would be great to provide such "instal" target, for better future compatibility.
2013-09-20 16:28:29 < funman> j-b: ping
2013-09-20 16:31:01 < j-b> funman: pong?
2013-09-20 16:31:28 < funman> j-b: muggs can push to the hg repo on videolan.org now, is there some plan for a transition from bitbucket to videolan.org ?
2013-09-20 16:32:15 < j-b> Why do we need a transition?
2013-09-20 16:32:17 < j-b> just push there
2013-09-20 16:32:29 < j-b> and then, we'll check the hooks for x265-commits@
2013-09-20 16:32:40 < funman> git^H^H^Hhgweb ?
2013-09-20 16:33:03 < j-b> already exists
2013-09-20 16:33:08 <@muggs> the push issues are all resolved; I had two different keys and didn't realize it.
2013-09-20 16:33:19 < funman> j-b: where's the web intf?
2013-09-20 16:33:23 <@muggs> (and the error mode is less than helpful)
2013-09-20 16:34:26 < funman> muggs: so should we switch to videolan.org repo now?
2013-09-20 16:34:32 < funman> I don't even remember the url
2013-09-20 16:35:31 <@muggs> you should be able to work from either, I plan to keep them both synchronized
2013-09-20 16:36:03 < j-b> funman: hg.videolan.org
2013-09-20 16:36:05 < j-b> funman: come on...
2013-09-20 16:36:41 < funman> j-b: eh, must be obvious for you
2013-09-20 16:36:55 < j-b> sorry, it is.
2013-09-20 16:36:56 <@muggs> http://hg.videolan.org/x265/graph/tip
2013-09-20 16:37:08 < j-b> git.videolan.org, svn.videolan.org hg.videolan.org
2013-09-20 16:37:27 < funman> well i need to remember to not ask you anything
2013-09-20 16:43:41 < funman> muggs: we can add automatic mirroring
2013-09-20 16:43:55 < funman> I do that for https://github.com/videolan/x265 already
2013-09-20 16:44:09 <@muggs> I've no problem with that
2013-09-20 16:44:29 < funman> bitbucket auth needs ssh?
2013-09-20 16:48:37 < Daemon404> is x265 on hg.v.o exclusively now?
2013-09-20 16:48:42 < Daemon404> i.e. i should point repo tere
2013-09-20 16:57:15 <@muggs> bitbucket takes ssh or https
2013-09-20 16:57:53 < j-b> Daemon404: who is this "SF" guy ?
2013-09-20 16:57:56 <@muggs> Daemon404: the plan is to push to both simultaneously
2013-09-20 17:00:36 < Daemon404> j-b, who
2013-09-20 17:00:38 < Daemon404> ?
2013-09-20 17:00:55 < Daemon404> oh the ML guy
2013-09-20 17:00:59 < Daemon404> no ida
2013-09-20 17:01:02 < Daemon404> idea*
2013-09-20 17:09:35 < funman> j-b: he came on IRC
2013-09-20 17:09:51 < funman> as 'elfring'
2013-09-20 17:10:32 <@muggs> http://sourceforge.net/users/elfring/
2013-09-20 17:11:12 <@muggs> http://sourceforge.net/projects/xawdecode/
2013-09-20 17:11:54 < funman> seems to be a long going project
2013-09-20 17:12:18 < j-b> funman: that's disgusting! :D
2013-09-20 17:13:14  * funman don't judge german people
2013-09-20 17:16:03 < Daemon404> hmm wtf
2013-09-20 17:16:04 < Daemon404>  --bitrate 3000
2013-09-20 17:16:06 < Daemon404> ->
2013-09-20 17:16:12 < Daemon404> encoded 15691 frames in 37843.31s (0.41 fps), 88.85 kb/s, Global PSNR: 35.664
2013-09-20 17:16:21 < Daemon404> @_@
2013-09-20 17:16:26 < j-b> Daemon404: metric system, man!
2013-09-20 17:16:35  * j-b runs from an angry Daemon404 
2013-09-20 17:16:39 < Daemon404> im canadian
2013-09-20 17:16:43 < Daemon404> metric system is superior
2013-09-20 17:16:54 < Daemon404> but yeah...
2013-09-20 17:16:59 < funman> Daemon404: how do you measure water temperature?
2013-09-20 17:17:02 < j-b> weird, indeed
2013-09-20 17:17:18 < funman> (re: canadian)
2013-09-20 17:17:25 < Daemon404> funman, in celciuss?
2013-09-20 17:17:29 < Daemon404> -rw-r--r-- 1 derek dev  46G Sep 19 17:39 elephants_dream_1080p24.y4m
2013-09-20 17:17:29 < Daemon404> -rw-r--r-- 1 derek dev 7.0M Sep 20 04:27 elep.hevc
2013-09-20 17:17:37 < Daemon404> interested to see what it looks like.
2013-09-20 17:17:54 < funman> Daemon404: ok, crazy quebecois use farhenheit for water and celsius for air
2013-09-20 17:18:07 < Daemon404> quebecois arent canadians
2013-09-20 17:18:10 < Daemon404> nor do they want to be
2013-09-20 17:18:22 < funman> you know http://www.youtube.com/watch?v=TncdhLGjFTE ?
2013-09-20 17:19:03 < Daemon404> of coure
2013-09-20 17:19:18 < Daemon404> http://www.youtube.com/watch?v=WULsZJxPfws
2013-09-20 17:19:20 < Daemon404> i prefer this
2013-09-20 17:19:27 < funman> :)
2013-09-20 17:21:45 < j-b> Nova Scotia ftw
2013-09-20 17:22:58 < Daemon404> muggs, any idea wtf could have happened?
2013-09-20 17:23:04 < Daemon404> almost every frame is qp51
2013-09-20 17:24:15 <@muggs> what is the full command line?
2013-09-20 17:24:56 < Daemon404> at the time i just randomly used ./x265 -F 1 -o elep.hevc --me 4 -m 7 --b-adapt 2 --bitrate 3000 --sao-lcu-bounds 1 --input  elephants_dream_1080p24.y4m
2013-09-20 17:27:29 < Daemon404> i was on changeset:   4047:e51ecfcabcaa
2013-09-20 17:27:34 <@muggs> we still have lookahead problems, but that shouldn't have that much of an affect on rate control.
2013-09-20 17:28:45 <@muggs> there are some rate control fixes after that commit, and one queued from the ML last evening
2013-09-20 17:29:31 < Daemon404> pretty big bug
2013-09-20 17:29:36 < Daemon404> 88 vs 3000
2013-09-20 17:29:55 < nevcairiel> is there anything visible left of the video? :D
2013-09-20 17:30:04 < Daemon404> only on I frames
2013-09-20 17:30:25 < Daemon404>  http://chromashift.org/elep.hevc
2013-09-20 17:30:27 < Daemon404> here have a look
2013-09-20 17:30:30 < Daemon404> i watched it with hm12
2013-09-20 17:50:15 <@muggs> yeah, that's pretty bad.
2013-09-20 18:06:30 <@muggs> I've passed that on to the RC team to have a look at; they'll probably be downloading that video all weekend
2013-09-20 18:06:54 < Daemon404> lol
2013-09-20 18:06:58 < Daemon404> its only 7 mb
2013-09-20 18:07:13 < Daemon404> or the src? thats a 7 gb dl
2013-09-20 18:07:21 <@muggs> oh, that's the trailer, not the movie?
2013-09-20 18:07:25 < Daemon404> no
2013-09-20 18:07:29 < Daemon404> its the movie
2013-09-20 18:07:38 < Daemon404> .y4m.xz from xiph is 7gb
2013-09-20 18:07:41 < Daemon404> extracts to 46
2013-09-20 18:07:50 <@muggs> got it
2013-09-20 18:08:07 < Daemon404> http://media.xiph.org/video/derf/y4m/elephants_dream_1080p24.y4m.xz
2013-09-20 18:24:56 <@muggs> funman: can we have commit notifications piped here?
2013-09-20 18:36:30 < Daemon404> [  1%] Building CXX object encoder/CMakeFiles/encoder.dir/encoder.cpp.o
2013-09-20 18:36:30 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp: In member function ‘int x265_t::extract_naldata(x265::AccessUnit&, size_t&)’:
2013-09-20 18:36:33 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:490: error: jump to label ‘fail’
2013-09-20 18:36:36 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:440: error:   from here
2013-09-20 18:36:38 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:482: error:   crosses initialization of ‘size_t offset’
2013-09-20 18:36:41 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:490: error: jump to label ‘fail’
2013-09-20 18:36:44 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:439: error:   from here
2013-09-20 18:36:46 < Daemon404> /mnt/tc/dev/x265/source/encoder/encoder.cpp:482: error:   crosses initialization of ‘size_t offset’
2013-09-20 18:36:49 < Daemon404> make[2]: *** [encoder/CMakeFiles/encoder.dir/encoder.cpp.o] Error 1
2013-09-20 18:37:03 < Daemon404> mixed code / deccl fun
2013-09-20 18:40:04 <@muggs> uhm, yeah.  just ran into that 30 seconds ago
2013-09-20 18:40:43 <@muggs> might finally be time to add -fpermissive
2013-09-20 18:45:33 < Daemon404> build bots soon i hope
2013-09-20 18:45:45 < Daemon404> also muggs
2013-09-20 18:45:48 < Daemon404> why is asm not build by default
2013-09-20 18:45:53 < Daemon404> i had to explicitly enable it
2013-09-20 18:46:26 <@muggs> if yasm is found, assembly is enabled by default
2013-09-20 18:46:38 < Daemon404> no
2013-09-20 18:46:41 < Daemon404> it isnt.
2013-09-20 18:46:43 < Daemon404> it found yasm
2013-09-20 18:46:46 < Daemon404> asm is not enabed
2013-09-20 18:46:52 < Daemon404> in fact an option to enable it isnt even listed
2013-09-20 18:46:58 < Daemon404> i had to do -D...=true
2013-09-20 18:47:25 <@muggs> option(ENABLE_PRIMITIVES_VEC "Enable use of SIMD vector class primitives" ON)
2013-09-20 18:47:36 < Daemon404> you can paste that
2013-09-20 18:47:40 < Daemon404> but it doesnt mean it works
2013-09-20 18:47:40 < Daemon404> :)
2013-09-20 18:47:42 <@muggs> oops
2013-09-20 18:47:45 <@muggs> option(ENABLE_PRIMITIVES_ASM "Enable use of assembly coded primitives" ON)
2013-09-20 18:48:06 <@muggs> so my guess is it didn't find yasm, or it thought it found an old asm
2013-09-20 18:48:15 <@muggs> do you still have the cmake logs?
2013-09-20 18:50:15 < Daemon404> muggs, http://pastebin.com/raw.php?i=XA2Spchn
2013-09-20 18:51:16 <@muggs> it looks like it couldn't determine the version
2013-09-20 18:51:35 < Daemon404> its vanilla yasm
2013-09-20 18:51:36 <@muggs> what does yasm --version return?
2013-09-20 18:51:48 < Daemon404> yasm 1.2.0
2013-09-20 18:51:48 < Daemon404> Compiled on Mar 15 2012.
2013-09-20 18:51:48 < Daemon404> Copyright (c) 2001-2011 Peter Johnson and other Yasm developers.
2013-09-20 18:51:48 < Daemon404> Run yasm --license for licensing overview and summary.
2013-09-20 18:52:10 <@muggs> roughly the same here, hmm
2013-09-20 18:55:54 <@muggs> I can at least force it to add the build flag in that case
2013-09-20 18:58:20 < Daemon404> thats a weird regex for the version
2013-09-20 18:58:28 < Daemon404> what syntax is it? grep? pcre?
2013-09-20 18:59:51 <@muggs> VERSION_LESS?
2013-09-20 19:00:23 <@muggs> some internal cmake magic.  what version of cmake do you have?  I've tested this on CentOS 6/cmake 2.6 and it worked ok
2013-09-20 19:00:53 < Daemon404> cmake version 2.6-patch 4
2013-09-20 19:01:10 < Daemon404> $ cat /etc/redhat-release
2013-09-20 19:01:10 < Daemon404> CentOS release 6.4 (Final)
2013-09-20 19:01:35 <@muggs> if you mean the code in FindYasm, yeah that's a regexp
2013-09-20 19:02:08 < Daemon404> yes
2013-09-20 19:04:25 <@muggs> http://pastebin.com/sRdm7FQT  <- should suck less
2013-09-20 19:05:04 < Daemon404> doesnt explain why it's been misdetected though
2013-09-20 19:05:30 <@muggs> no; just makes the failure less total
2013-09-20 19:09:26 <@muggs> I'm utterly failing at taking a day off
2013-09-20 19:09:56 < Daemon404> o ddnt know
2013-09-20 19:12:03 <@muggs> not your fault, it's my email inbox
2013-09-20 19:29:58 < funman> muggs: we can
2013-09-20 19:30:24 < funman> muggs: the bot we have on #videolan is managed by thresh and I think he's in vacations
2013-09-20 19:30:48 <@muggs> ok, it's no rush
2013-09-20 19:37:24 <@muggs> I've pushed 5 cleanup commits to my personal repo:  https://bitbucket.org/sborho/x265/commits/all
2013-09-20 19:37:33 <@muggs> fixes the GCC build among other things
2013-09-20 19:38:27 <@muggs> I can publish those once someone ok's them
2013-09-20 19:39:06 < Daemon404> im regularily testing on freebsd with the clang++ in the base system
2013-09-20 19:39:08 < Daemon404> in 9.
2013-09-20 19:39:10 < Daemon404> just fyi
2013-09-20 19:39:18 < Daemon404> er 9.1
2013-09-20 19:40:06 <@muggs> how different is that from the compiler in OS X 10.8?
2013-09-20 19:40:15 < Daemon404> not sure
2013-09-20 19:40:24 < Daemon404> it's apples internal fork
2013-09-20 19:40:32 <@muggs> blech
2013-09-20 19:47:33 < funman> muggs: what do you think about named branches instaed of personal repo? O:-)
2013-09-20 19:47:57 <@muggs> I've never seen that turn out well
2013-09-20 19:48:09 < funman> i'm fine with forking instead of branches
2013-09-20 19:48:18 < funman> maybe branches help when there are a thousand developers
2013-09-20 19:48:36 < nevcairiel> branches get worse the more developers you have
2013-09-20 19:50:02 < Daemon404> funman, branches dont work so well in hg
2013-09-20 19:50:05 < Daemon404> compared to git
2013-09-20 19:50:08 < Daemon404> (IMHO)
2013-09-20 19:50:25 <@muggs> I got the sense he was arguing just to be argumentative; so I'm stopped responding
2013-09-20 19:50:40 < funman> good I think
2013-09-20 19:51:15 < funman> ah btw we need the same kind of commit hook for an IRC bot than for buildbot
2013-09-20 19:51:36 < funman> although I need to check what is the state of hg support in buildbot
2013-09-20 19:51:43 < funman> in any case I can still have buildbot run hg commands manually
2013-09-20 19:51:49 < nevcairiel> build bots traditionally also work well with polling :d
2013-09-20 19:52:01 < funman> nevcairiel: ah? never used that
2013-09-20 19:52:17 < funman> we get a message from x264.git / vlc.git whenever there's a commit(s) pushed
2013-09-20 19:52:17 < nevcairiel> and while irc hooks can in theory also poll, the delay is kinda annoying
2013-09-20 19:52:41 < nevcairiel> notifications are better of course
2013-09-20 19:53:39 < funman> hmm and I can bring the buildbot irc bot here but it'd also announce vlc build results
2013-09-20 19:53:51 < funman> maybe it's time for some python hacking and per-channel-reporting
2013-09-20 19:54:59 < funman> muggs: did you remove yasm 1.2.0 features?
2013-09-20 19:55:16 < funman> (2a00fe5)
2013-09-20 19:55:26 < Daemon404> funman, better if it only reports failures
2013-09-20 19:55:37 < Daemon404> no need for the "everything's ok alarm"
2013-09-20 19:55:40 <@muggs> no; that change just makes sure the variable is there but it is still disabled by default
2013-09-20 19:56:01 < funman> Daemon404: current config reports change (good -> bad and bad -> good) but well that's configurable
2013-09-20 19:56:10 < Daemon404> right
2013-09-20 19:56:12 < funman> muggs: oh ok
2013-09-20 19:56:39 < funman> 7291eaa looks good
2013-09-20 19:57:02 < funman> and I say this as the VideoLAN whitespace manager
2013-09-20 19:57:48 < Daemon404> funman, can you match up to diego?
2013-09-20 19:57:51 < Daemon404> Mr. Nit
2013-09-20 19:58:05 < funman> :D
2013-09-20 19:58:18 < funman> muggs: about fd70bf0 I thought replacing Uint by their typedefs was preferred
2013-09-20 19:59:18 <@muggs> there was some fudging about UInt; that "unsigned int" has a purpose
2013-09-20 19:59:26 < funman> would it be s/int/unsigned/ rather ?
2013-09-20 19:59:49 < funman> well except that bikescheding the 5 commits look good
2013-09-20 19:59:50 <@muggs> but in this case, there's a plausible case to make them uint32_t
2013-09-20 20:00:27 < funman> and making them UInt marks them for an upcoming 'grep UInt' review
2013-09-20 20:02:35 <@muggs> I went ahead and changed those to uint32_t and pushed the batch
2013-09-20 20:04:57 <@muggs> that function probably shouldn't take a size_t arg, but that will get cleaned up when AccessUnit is nuked
2013-09-20 20:23:35 <@muggs> IBC went well, we now have 4 consortium members.  but unfortunately most of them want to stay anonymous
2013-09-20 20:35:10 < funman> muggs: who are the non-anonymous ones?
2013-09-20 20:35:53 <@muggs> one is Telestream; they've been public for a while.  the other is still finalizing paperwork, but should announce next week
2013-09-20 20:36:39 <@muggs> one will go public next year; the other probably never
2013-09-20 20:36:49 < funman> cool
2013-09-20 20:37:22 < funman> at next IBC I want to print thousands of "proud open source user" stickers and walk around putting them on all the related booths
2013-09-20 20:37:46 <@muggs> that would make a fun documentary movie
2013-09-20 20:39:14 < radek> Huh.
2013-09-20 20:39:56 < radek> I naively ported the angular intraprediction primitive to OpenCL and it only performs WAY slower.
2013-09-20 20:40:12 <@muggs> for NAB next april we are obligated to deliver HRD/VBV, 30fps HD on any hardware, and range-extensions support.
2013-09-20 20:42:05 <@muggs> "any hardware" means our choice.
2013-09-20 20:42:59 <@muggs> radek: you did just one angular mode?
2013-09-20 20:43:09 < radek> Yep, it's only an experiment.
2013-09-20 20:43:31 < radek> As in, template<int size>
2013-09-20 20:43:31 < radek> 	void PredIntraAngs_C
2013-09-20 20:43:45 < radek> Blah, that copied badly.
2013-09-20 20:43:50 <@muggs> comparing kernel runtime to C code, or to ASM?
2013-09-20 20:43:54 < radek> C code.
2013-09-20 20:44:15 <@muggs> oh, I see, yeah that's kinda brutal
2013-09-20 20:44:25 < radek> Yeah, didn't expect anything else.
2013-09-20 20:44:55 < radek> My experiment is to mainly show that it will be way slower and why.
2013-09-20 20:46:28 < radek> I've studied the x264 OpenCL parts and they seem to work because the parallelism is much higher.
2013-09-20 20:46:55 < radek> A lot more of the data is being taken care of at once.
2013-09-20 20:47:07 <@muggs> yeah, the lookahead has much lighter data dependencies
2013-09-20 20:47:19 <@Skyler_> yeah, and keep in mind that *despite* that, the opencl is not very fast
2013-09-20 20:47:27 <@Skyler_> so without those advantages, it will be even worse, most likely
2013-09-20 20:47:56 < radek> I would like to se some data on how fast the x264 implementation is, will have to measure that tomorrow.
2013-09-20 20:48:04 <@muggs> well optimized assembly is hard to beat
2013-09-20 20:48:27 < radek> Fortunately, I'm not trying to beat anything ;)
2013-09-20 20:48:39 < radek> I'm just trying to finish my thesis
2013-09-20 20:48:45 <@muggs> lucky you
2013-09-20 20:48:48 < radek> And it's only master's
2013-09-20 20:49:07 < radek> so, just measuring and analysis should be enough
2013-09-20 20:49:50 < radek> I wouldn't say I'm lucky, the thesis is due next week and I'm actually already 2 years behind.
2013-09-20 20:50:14 <@muggs> ouch
2013-09-20 20:50:34 < radek> I chose the topic myself this time, though.
2013-09-20 20:51:27 < radek> And I had one stroke of luck, the x265 project happened, otherwise I would have to write about HM and that code is not easy to understand.
2013-09-20 20:52:14  * muggs is not sure we've improved upon it all that much yet
2013-09-20 20:53:28 < radek> I think the code is more readable, at least.
2013-09-20 20:54:00 <@muggs> hmm, DXVA supports HEVC now
2013-09-20 20:54:02 < radek> A lot of things that didn't go into the standard are gone
2013-09-20 20:54:34 < radek> Yeah, I was going to try to run that, but I have a little Microsoft allergy.
2013-09-20 20:55:04 < nevcairiel> muggs: i've seen the spec, but who knows when the first device actually supporting it shows up
2013-09-20 21:29:01 < funman> muggs: oh, from which GPU vendor? or did Microsoft just lay the abstraction layer?
2013-09-20 21:29:23 <@muggs> they just plumbed the API, I think
2013-09-20 21:32:58 < j-b> http://msdn.microsoft.com/en-us/library/windows/hardware/dn343543.aspxhttp://msdn.microsoft.com/en-us/library/windows/hardware/dn343543.aspx
2013-09-20 21:33:02 < j-b> http://msdn.microsoft.com/en-us/library/windows/hardware/dn343543.aspx
2013-09-20 21:33:09 < j-b> and the spec
2013-09-20 21:33:10 < j-b> http://www.microsoft.com/en-pk/download/details.aspx?id=39947
2013-09-20 21:35:41 < nevcairiel> i'm not sure what these test pages are for, they have them for so much stuff and i never found them useful
2013-09-20 21:36:14 < nevcairiel> anyhow the spec is very similar to H264, just with some changes to the data structures, no surprises
2013-09-20 21:36:22 < nevcairiel> the nice thing is that they specced Main10 as well
2013-09-20 21:36:36 < j-b> v210 ?
2013-09-20 21:37:07 <@muggs> v210 implies 4:2:2 I think; Main10 is 10bit 4:2:0
2013-09-20 21:37:23 < funman> wait, hevc can output v210?
2013-09-20 21:37:48 < nevcairiel> the spec doesnt say which surface format is used for output, never does, its up to the driver really
2013-09-20 21:37:59 <@muggs> range extensions aren't finalized yet, so no 4:2:2
2013-09-20 21:38:09 <@muggs> I've got to drop, have a nice weekend everyone
2013-09-20 21:38:15 < j-b> CU
2013-09-20 21:41:00 < kierank> in software you would decode in nv12 and then pack to v210
2013-09-20 21:41:08 < kierank> nv20 to be more precise
2013-09-20 21:41:22 < kierank> in hardware yes you could decode i think in v210
2013-09-20 21:41:42 < nevcairiel> its not going to decode in a packed format
2013-09-20 21:41:43 < j-b> why in software to nv12?
2013-09-20 21:42:55 < nevcairiel> if i had to guess, it would be P010, because thats MS favorite 10-bit format, and basically equivalent to NV12 with more bits
2013-09-20 21:45:03 < nevcairiel> but until i have a GPU at hand that supports it, its impossible to say
2013-09-20 21:45:07 < nevcairiel> and that will take a while
2013-09-20 21:46:41 < kierank> j-b: slightly faster than i420
2013-09-20 21:46:56 < kierank> and faster to pack to v210
2013-09-20 21:47:29 < nevcairiel> but not enough bits for main10, so no point
--- Day changed Sat Sep 21 2013
--- Day changed Sun Sep 22 2013
--- Day changed Mon Sep 23 2013
2013-09-23 05:13:25 < Praveen> I have few things for x86inc named parameters like cglobal foo, 2, 3, 0, dst, src, tmp does it means %define dst = r0, %define src = r1, %define tmp = r3 or only %define tmp = r0?
2013-09-23 05:16:24 < Praveen> and what about xmm registers can we map them also?
2013-09-23 05:18:51 < Praveen> like foo 0, 2, 1, dst, src, tmp does it means %define dst = r0, %define src = r1, %define tmp = m0?
2013-09-23 05:46:45 < kurosu_> yes for gprs
2013-09-23 05:47:08 < kurosu_> afaik no for simd regs but maybe this has changed
2013-09-23 10:33:52  * kodab sighs at mkvtoolnix taking ages to compile
2013-09-23 10:34:10 < JEEB> aye
2013-09-23 10:34:13 < JEEB> all those dependencies too
2013-09-23 10:34:49  * JEEB keeps a repo with the divx changes on top of the current mkvtoolnix repo
2013-09-23 10:37:38 < kodab> i'm trying out the divx repo
2013-09-23 10:41:58 < kodab> Error in the Matroska file structure at position 12712130. Resyncing to the next level 1 element
2013-09-23 10:42:04 < kodab> but a file is created
2013-09-23 10:42:07 < kodab> success? :s
2013-09-23 10:42:15 < JEEB> o_O
2013-09-23 10:42:28 < JEEB> try grabbing my repo and see how that fares?
2013-09-23 10:42:43 < JEEB> https://github.com/jeeb/mkvtoolnix
2013-09-23 10:43:37 < kodab> wait let me decode the generated file first
2013-09-23 10:47:02 < kodab> meh, blackscreen with divxplayer
2013-09-23 10:47:13 < kodab> while i get hm i'll try yours JEEB
2013-09-23 10:52:03 < kodab> hm works \o/
2013-09-23 10:52:16 < JEEB> \o/
2013-09-23 12:11:28 < kodab> JEEB, same error with your repo, but it works anyway
2013-09-23 12:12:15 < JEEB> funky
2013-09-23 12:12:28 < JEEB> wonder what it fails at
2013-09-23 12:12:34 < Daemon404> also remember
2013-09-23 12:12:37 < Daemon404> divx is for hm11
2013-09-23 12:12:44 < Daemon404> x265 is hm12
2013-09-23 12:12:46 < Daemon404> if it matters
2013-09-23 12:13:16 < JEEB> Divx seems to do something funky at IRAPs
2013-09-23 12:13:22 < JEEB> since that's when it crashes with HM12
2013-09-23 12:13:23 < Daemon404> shocking
2013-09-23 12:13:52 < kodab> and libav is hm11
2013-09-23 12:14:21 < Daemon404> kodab, yes but libav will be updated to the final standard
2013-09-23 12:14:28 < Daemon404> divx... probably not
2013-09-23 12:14:34 < kodab> :D
2013-09-23 12:15:32 < Daemon404> related: JEEB -- how goes matroska-devel wrt hevc
2013-09-23 12:15:42 < JEEB> it's pretty much done
2013-09-23 12:15:54 < Daemon404> just needs mosu to impl it?
2013-09-23 12:16:07 < JEEB> only some details left regarding how switching from off-band to in-band parameter sets should work
2013-09-23 12:16:23 < JEEB> also funny how divx's spec differs by just one bit in extradata
2013-09-23 12:16:28 < Daemon404> did you ever work out intra-refresh?
2013-09-23 12:16:32 < Daemon404> or is it DNW
2013-09-23 12:16:32 < JEEB> no
2013-09-23 12:16:48 < JEEB> the current thing used for opus is like
2013-09-23 12:16:55 < JEEB> decode this many time units
2013-09-23 12:17:03 < JEEB> I guess it could be used?
2013-09-23 12:17:09 < JEEB> but it's unspecific :<
2013-09-23 12:17:15 < Daemon404> that kind of defets the zero latency use case of intra refresh
2013-09-23 12:17:16 < Daemon404> doesnt it?
2013-09-23 12:17:19 < Daemon404> defeats*
2013-09-23 12:17:33 < JEEB> well the idea of intra refresh is to decode X samples
2013-09-23 12:17:40 < JEEB> and then you should get a full picture
2013-09-23 12:17:46 < JEEB> so no, it doesn't
2013-09-23 12:18:06 < Daemon404> well i know what it is, but you can still 'start' with a broken picture
2013-09-23 12:18:08 < Daemon404> if you want
2013-09-23 12:18:13 < Daemon404> bradcasters do this iirc?
2013-09-23 12:18:33 < Daemon404> anyway, im not concerned...
2013-09-23 12:18:36 < JEEB> well yes, but then you might as well just make every picture a random access point :P
2013-09-23 12:18:40 < JEEB> which is broken as fuck
2013-09-23 12:18:44 < JEEB> but that's how it'd go
2013-09-23 12:19:05 < JEEB> or well, actually it would be that extra structure + every picture is a random access point
2013-09-23 12:19:27 < JEEB> and possibly something that says that if you want to seek to X, you should then start decoding at X - Y
2013-09-23 12:19:41 < JEEB> that's not yet in the v4 stuff IIRC?
2013-09-23 12:20:21 < Daemon404> ddunno
2013-09-23 12:20:40 < Daemon404> i didnt bother subscribing to that ml
2013-09-23 12:20:49 < Daemon404> since it's 1) dead b) only half info (rest is on irc)
2013-09-23 12:21:00 < JEEB> it only says that you should decode X amount of time of samples before outputting stuff, but it wouldn't tell you to go back
2013-09-23 12:21:12 < JEEB> but I guess it depends on the implementation?
2013-09-23 12:21:16 < Daemon404> i guess
2013-09-23 12:21:18  * JEEB shrugs
2013-09-23 12:21:27 < JEEB> although now that I think of it
2013-09-23 12:21:32 < JEEB> the opus thing is just encoder delay
2013-09-23 12:21:53 < JEEB> so you can't really use it as a solution to "seek back"
2013-09-23 12:21:55 < Daemon404> it always seemed like that to be, but everyone kept saying it as special
2013-09-23 12:21:57  * JEEB shrugs
2013-09-23 12:22:00 < Daemon404> to me*
2013-09-23 12:22:03 < Daemon404> was*
2013-09-23 12:29:04 < JEEB> heh, actual x86inc-based asm on the ML \o/
2013-09-23 12:29:57 < Daemon404> yea
2013-09-23 12:30:04 < Daemon404> too bad im useless at reviewing it
2013-09-23 12:36:06 < nevcairiel> without fatal flaws this time? :d
2013-09-23 12:42:48 < kodab> also x265 got integrated in vlc
2013-09-23 12:43:11 < Daemon404> yes
2013-09-23 12:43:18 < Daemon404> i have a patch for libav
2013-09-23 12:43:28 < Daemon404> but im waiting until libx265 takes being library seriously
2013-09-23 12:43:35 < Daemon404> it cant even be built as a shared lib currently
2013-09-23 12:43:35 < kodab> lol
2013-09-23 12:43:40 < Daemon404> and it has no versioning
2013-09-23 12:43:46 < kodab> i'd be waiting until it gets ported to C :D
2013-09-23 12:43:53 < Daemon404> the api is c
2013-09-23 12:43:59 < Daemon404> thats all people care about
2013-09-23 12:44:09 < Daemon404> the other issue is that if we static link
2013-09-23 12:44:14 < Daemon404> we need to add -lstdc++
2013-09-23 12:44:15 < nevcairiel> gcc is c++ these days, people should stop whining about c++ implementations
2013-09-23 12:44:20 < Daemon404> whch adds all sorts of fun
2013-09-23 12:44:29 < Daemon404> nevcairiel, c++ abi is undefined
2013-09-23 12:44:32 < Daemon404> people can keep whining
2013-09-23 12:44:45 < nevcairiel> but there is a C api/abi :p
2013-09-23 12:44:55 < Daemon404> [13:42] < Daemon404> the api is c
2013-09-23 12:44:55 < Daemon404> [13:42] < Daemon404> thats all people care about
2013-09-23 12:45:03 < JEEB> yup
2013-09-23 12:45:19 < Daemon404> people, in this context, mean downstream users
2013-09-23 12:45:36 < JEEB> aye, anti-c++ folk will keep herping a derp until the end of time anyways :P
2013-09-23 12:45:47 < Daemon404> theyre not wrong
2013-09-23 12:45:56 < Daemon404> if you dont use a well defined subset, youre fucked
2013-09-23 12:46:41 < kodab> i'm not anti c++ but i dislike linking stdc++ :\
2013-09-23 12:46:49 < nevcairiel> dynamic linking :)
2013-09-23 12:47:01 < Daemon404> nevcairiel, yes but the build system still needs to support it
2013-09-23 12:47:18 < Daemon404> also [13:42] < Daemon404> it cant even be built as a shared lib currently
2013-09-23 12:47:21 < Daemon404> kind of relevant :)
2013-09-23 12:47:30 < nevcairiel> i still stick to my opinion that its way too early to complain about such things
2013-09-23 12:47:40 < Daemon404> of course
2013-09-23 12:47:42 < nevcairiel> also, send patches
2013-09-23 12:47:42 < nevcairiel> :D
2013-09-23 12:47:59 < Daemon404> im waiting on a certain someone to rewrite the library cmake code sanely
2013-09-23 12:48:06 < Daemon404> teh current mergestaticlibs.cmake is insane
2013-09-23 12:48:14 < Daemon404> as are most cmake things
2013-09-23 12:48:19 < nevcairiel> i'm going on a 3 week vacation soon, and i'm kinda hoping that at least the decoder makes it into libav by then
2013-09-23 12:48:26 < nevcairiel> but i'm not sure its warranted hope :p
2013-09-23 12:48:34 < Daemon404> i havent seen it move in weeks
2013-09-23 12:48:38 < Daemon404> or at all since VDD
2013-09-23 12:48:48 < Daemon404> anton is not around
2013-09-23 12:48:54 < Daemon404> smarter got stolen by Big Corp
2013-09-23 12:49:02 < nevcairiel> he should be more around again now, he finished his thing with the university, iirc
2013-09-23 12:49:14 < Daemon404> aye
2013-09-23 12:49:45 < nevcairiel> and my last update was that it can at least decode all conformance samples now
2013-09-23 12:49:54 < Daemon404> right
2013-09-23 12:50:04 < nevcairiel> so only cleaning to go, i guess?
2013-09-23 12:50:12 < Daemon404> fuzzing too
2013-09-23 12:50:14 < Daemon404> it crashes lots
2013-09-23 12:50:43 < nevcairiel> should face the fact that its never going to be perfect, so merge it and make it easier for people to contribute such fixes
2013-09-23 12:51:00 < Daemon404> i only mean a reaosnable amount
2013-09-23 12:51:10 < Daemon404> currently i can crash it using valid streams
2013-09-23 12:51:10 < Daemon404> :P
2013-09-23 12:51:25 < nevcairiel> well sure, but you know how certain libav people can be
2013-09-23 12:51:35 < Daemon404> i have no idea to whom you refer.
2013-09-23 12:51:36 < Daemon404> not one clue.
2013-09-23 12:52:18 < JEEB> <Daemon404> i havent seen it move in weeks <- openhevc side and koda etc. did basically work on it, and then anton merges
2013-09-23 12:53:10 < Daemon404> i meant the merge effort
2013-09-23 12:53:13 < Daemon404> to mainline
2013-09-23 12:53:23 < JEEB> I think it gets updated every now and then
2013-09-23 12:53:26 < JEEB> I see force pushes
2013-09-23 12:53:45 < nevcairiel> should ask mini, it would be in ffmpeg in a few hours :P
2013-09-23 12:54:03 < kodab> the ones that ate my branches entirely
2013-09-23 12:54:25 < kodab> nah, there'll be a bunch of fixes after libav is merged
2013-09-23 12:54:32 < kodab> has*
2013-09-23 14:59:16 <@Skyler_> @praveen, please don't have redundant jumps in your loops if you can
2013-09-23 16:09:23 < greenfountain> Daemon404 : i tried running --bitrate 3000 with big buck bunny, there was this bug in RC when the frame was fully dark - estimated frame cost was 0 and it blew up the cplxrSum (real cost) for the next few frames to infinity.. fixed it..
2013-09-23 16:09:39 < Daemon404> cool :)
2013-09-23 16:10:46 < greenfountain> the elephant dream(1080p) is giving decent reuslts with --bitrate 3k..been running it fopr 600 frames and bitrate hovers around 2990s..kb..
2013-09-23 16:11:15 < greenfountain> u were saying it bombed for the same video right.. how many frames were u testing
2013-09-23 16:12:33 < Daemon404> all of them.
2013-09-23 16:13:02 < greenfountain> the video has 15691 frames. its 42 gig :\
2013-09-23 16:13:07 < greenfountain> u ran the entire thing?
2013-09-23 16:13:48 < Daemon404> yup
2013-09-23 16:13:56 < Daemon404> but it bombed right away
2013-09-23 16:14:03 < Daemon404> apparently
2013-09-23 16:14:58 < greenfountain> yea yea that must have been the same bug i fixed. ok, ll let it encode the full stream overnight, just to confirm . so far it seems ok (~700 frames)
2013-09-23 16:17:24 < Daemon404> ok
2013-09-23 16:50:08 < Daemon404> hey muggs ping
2013-09-23 16:50:32 < Daemon404> actually nvm, see ML in a few secs
2013-09-23 17:09:55 <@muggs> ok
2013-09-23 17:16:45 <@muggs> fun
2013-09-23 17:17:51 < Daemon404> lol
2013-09-23 17:18:01 < Daemon404> i dont expect them to be pushed
2013-09-23 17:18:03 < Daemon404> obviously
2013-09-23 17:19:23 < Daemon404> also excuse my screwed utf8 n the first email
2013-09-23 17:19:32 < Daemon404> i added a unicode char to a 7bit email
2013-09-23 17:32:00 < Daemon404> muggs, do you happen to know how hg email handles removals of large binaries
2013-09-23 17:32:11 < Daemon404> i dont want to send massive base64 encoded patches to the ML
2013-09-23 17:33:09 <@muggs> hg email just sends patches, and those patches would contain large base64 changes
2013-09-23 17:33:53 <@muggs> for things like this pull requests are easier to deal with; or I can just do the deletions locally
2013-09-23 17:36:03 < jb_afk> Daemon404: I do not see the emails on the ml
2013-09-23 17:36:55 < Daemon404> jb_afk, i havent sent huge ones
2013-09-23 17:37:00 < Daemon404> i have sent the RFC though
2013-09-23 17:37:05 < jb_afk> yes
2013-09-23 17:37:11 < jb_afk> but no patches attached?
2013-09-23 17:37:19 < Daemon404> 5 rfc patches
2013-09-23 17:37:24 < Daemon404> muggs, where / how do i sen a PR
2013-09-23 17:37:27 < Daemon404> just a bitbucket PR?
2013-09-23 17:39:50 <@muggs> <pedantic>make a fork, push changes to your fork, then there will be a pull request button near top right</pedantic>
2013-09-23 17:40:02 < Daemon404> im well aware of teh workflow
2013-09-23 17:40:15 < Daemon404> most foss projects i contribute to prefer ML pathes
2013-09-23 17:40:18 < Daemon404> patches even
2013-09-23 17:42:53 < jb_afk> the workflow shouldn't depend on non-open-source tools, like bitbucket...
2013-09-23 17:44:16 < Daemon404> jb_afk, well hg is not so nice compared to git
2013-09-23 17:44:20 < Daemon404> for patch/ML
2013-09-23 17:44:26 < Daemon404> as seen above
2013-09-23 17:44:51 < jb_afk> well, you can still publish your fork, no?
2013-09-23 17:45:13 < Daemon404> if by publsh you mean "url is public" then yes
2013-09-23 17:45:43 < Daemon404> merging has always seemed meh to me
2013-09-23 17:45:44 < Daemon404> fwiw
2013-09-23 17:45:48 < Daemon404> i like a linear history
2013-09-23 17:46:11 < Daemon404> but then again you cant rebase in hg...
2013-09-23 17:46:12 < Daemon404> meh
2013-09-23 17:46:13 < Daemon404> :)
2013-09-23 17:46:28 < Daemon404> (protip: i hate hg)
2013-09-23 17:52:41 < Daemon404> muggs, i will send a pr for 4 patches
2013-09-23 17:52:49 < Daemon404> and re-send the cmake stuff
2013-09-23 17:54:27 < Daemon404> muggs, sent
2013-09-23 17:54:57 <@muggs> I can rebase with hg
2013-09-23 17:55:02 < Daemon404> its nontrivial
2013-09-23 17:55:09 < Daemon404> especially if you want to update a remote branch
2013-09-23 17:55:13 < Daemon404> with something akin to push -f in git
2013-09-23 17:55:38 <@muggs> hg has this strange notion; published commits don't change
2013-09-23 17:55:53 < Daemon404> thats not so good for in-progress development branches
2013-09-23 17:56:01 <@muggs> but prior to being published; you can munge them like crazy
2013-09-23 17:56:22 < Daemon404> yes i know hg devs dont do the whole "WIP dev branch"
2013-09-23 17:56:28 < Daemon404> its a different ideaology
2013-09-23 17:56:47 < Daemon404> if i only cared about local, id use  git-hg
2013-09-23 17:57:02 <@muggs> Min Chen works that way 100%, I think
2013-09-23 17:57:55 < Daemon404> as it stands you imply cannot do dev branches in a sane with imh
2013-09-23 17:58:04 < Daemon404> without 4000 "merge from master" or whatever
2013-09-23 17:58:07 < Daemon404> simply*
2013-09-23 17:58:08 < Daemon404> afaik
2013-09-23 17:58:18 <@muggs> I'm pretty flexible; if you had a public git tree that you pushed changes to; I could pull and rebase and push
2013-09-23 17:58:19 < Daemon404> e.g. github workflow, updating PRs
2013-09-23 17:58:48 < Daemon404> my personal preference has always been ML patches
2013-09-23 17:58:53 < Daemon404> since revewing branches is a pain
2013-09-23 17:59:28 <@muggs> yeah; me too.  that works decently. so long as you're not mangling binary files
2013-09-23 17:59:28 < jb_afk> it's no that bad if you have less than 20 patches
2013-09-23 18:01:47 < jb_afk> Daemon404: note that we can provide you a git/hg repo at your conveniance on videolan.org
2013-09-23 18:01:47 < Daemon404> ive been poking the github mirror
2013-09-23 18:01:47 < Daemon404> and using patch to apply to hg
2013-09-23 18:01:47 < Daemon404> and commit
2013-09-23 18:01:47 < Daemon404> cumbersome at best ;)
2013-09-23 18:01:47 <@muggs> hg import <PATCHFILE>
2013-09-23 18:01:47 <@muggs> might help slightly
2013-09-23 18:01:47 < Daemon404> i dont think it can eat  git patches?
2013-09-23 18:01:47 <@muggs> it does
2013-09-23 18:01:47 < Daemon404> interesting
2013-09-23 18:01:47 < Daemon404> didnt know that.
2013-09-23 18:01:47 <@muggs> it can output git patches:  hg diff --git
2013-09-23 18:01:55 < Daemon404> mostly i like using git's format-patch and send-email facilities better
2013-09-23 18:02:01 < Daemon404> its more flexible for me
2013-09-23 18:02:25 < Daemon404> i cant even figure out how to do something akin to `git format-patch -3`
2013-09-23 18:02:50 < Daemon404> or format-patch origin/HEAD..HEAD
2013-09-23 18:08:48 <@muggs> git patches to the ML should be fine.
2013-09-23 18:10:22 <@muggs> hg email supports revsets; but to be honest I'm spoiled by thg.  I just ctrl+click on the revs to send and export->email
2013-09-23 18:10:53 < Daemon404> heh
2013-09-23 18:10:58 < Daemon404> i dont use guis
2013-09-23 18:11:02 < Daemon404> and a lot of my work is over ssh
2013-09-23 18:17:49 < kierank> you're missing out
2013-09-23 18:17:53 < kierank> atlassian sourcetree is good
2013-09-23 18:27:06 <@muggs> I'm probably going to drop an 0.4.1 tag on the RC and lookahead fixes.  waiting for one more RC fix to arrive
2013-09-23 18:28:23 < Daemon404> kierank, ive never needed a gui for git
2013-09-23 19:02:45 < Daemon404> random nvidia mail
2013-09-23 19:09:04 < Mandarinka> oh, that person posted it in the doom9 forum first, so they got a presence there too :)
2013-09-23 19:09:37 < JEEB> yes, the x265_project person was it?
2013-09-23 19:13:56 <@muggs> I guess they're telegraphing they have an HEVC decoder in the works
2013-09-23 19:14:36 < JEEB> ooh, that nvidia guy posted on d9
2013-09-23 19:18:46 < Daemon404> everyone has a HEVC en/decoder in the works
2013-09-23 19:18:53 < Daemon404> literally every company.
2013-09-23 19:19:15 < Daemon404> i bet dolce and gabbana even do
2013-09-23 19:19:18 < JEEB> :D
2013-09-23 19:19:19 < kierank> lol
2013-09-23 19:19:27 < JEEB> pretty much I'd think
2013-09-23 19:20:15 <@muggs> it does seem that way sometimes
2013-09-23 19:34:47 < Mandarinka> yeah, hopefully the HW ramp-up will be faster and the chips will be more feature-complete from the start
2013-09-23 19:35:07 < Mandarinka> could make the format adoption faster than with AVC
--- Day changed Tue Sep 24 2013
2013-09-24 06:17:10 < nightfox> @muggs I am getting while integrating my asm code, ipfilter8.asm.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
2013-09-24 06:47:07 <@muggs> have you tried nm or objdump to see if anything is in the output file?
2013-09-24 06:47:40 <@muggs> are you building for 32bit?  have you checked that yasm arguments?
2013-09-24 06:49:12 < min_chen> if you compile with X64, you will get this warning, since the code is empty in this mode
2013-09-24 06:50:12 < min_chen> "%if ARCH_X86_64 == 0", so all of code will remove in X64 mode
2013-09-24 06:50:32 < nightfox> we are build 64 bits
2013-09-24 06:50:53 < min_chen> I think you need a new code to support it
2013-09-24 06:51:28 < nightfox> new code, i did not got u?
2013-09-24 06:52:22 <@muggs> for now, you need to test a 32bit build
2013-09-24 06:53:00 < nightfox> why so?
2013-09-24 06:53:47 <@muggs> there is no 64bit function in the file
2013-09-24 07:16:55 < min_chen> the current code have 32 bits branch only, you need write a 64 bits branch
2013-09-24 09:18:56 < Nabajit> Is there any syntax error in this line ----movq        leftmask,   [tab_leftmask + (7 - widthleft)]
2013-09-24 09:19:38 < Nabajit> I get an error like this .. error: invalid effective address
2013-09-24 09:21:15 < Nabajit> widthleft seems to create the problem
2013-09-24 10:09:34 < Manao> Nabajit: could it be that widthleft extends into a register ? in that case [reg1 - reg2] is not a valid address. you can only do [reg1 + x*reg2 + y], with x = 1, 2, 4 or 8
2013-09-24 10:10:20 < Nabajit> yes widthleft extends into a register
2013-09-24 10:12:33 < Nabajit> That may be the problem then.. but why is it not allowed?
2013-09-24 10:13:02 < nightfox> why [reg1 - reg2] is not allowed?
2013-09-24 10:14:50 < Manao> why would it be ? they had 2 bits to code x in the instruction, they (those who made x86) decided that 1, 2, 4 and 8 were better choice than -1, 1, 2 and 4
2013-09-24 10:16:47 < nightfox> can u suugest me an alternative solution to [tab_leftmask + (7 - widthleft)]
2013-09-24 10:20:17 < Manao> try to negate widthleft before using it in an address ?
2013-09-24 10:20:41 < Manao> it really depends on the code before, and how you obtained widthleft
2013-09-24 10:20:55 < Manao> but if widthleft=a-b, then just to b-a instead
2013-09-24 10:22:01 < nightfox> okay, thnks
2013-09-24 13:48:49 < jb_afk> Daemon404: good morning
2013-09-24 13:49:23 < Daemon404> at 3pm?
2013-09-24 15:15:51 < jb_sad> Daemon404: it's always morning on iRC
2013-09-24 15:17:23 < Daemon404> heh true
2013-09-24 15:22:13 <@muggs> feels like Monday
2013-09-24 18:03:58 <@muggs> Skyler_: ping
2013-09-24 18:11:21 <@muggs> btw: I get quite a lot of requests for establishing performance presets a-la x264
2013-09-24 18:15:39 < nevcairiel> i think its a good idea, although a bit premature still i guess
2013-09-24 18:16:15 < JEEB> yeah
2013-09-24 18:17:10 < nevcairiel> with x264 i usually dont think about the settings much at all, i pick a speed preset and a crf value and just go
2013-09-24 18:17:13 < nevcairiel> ease of use ftw
2013-09-24 18:23:59 <@muggs> we have quite a lot of tuning knobs already; but not as many features
2013-09-24 18:26:34 < JEEB> personally I'd say that some kind of CRF-like rate control mode would make many use cases possible. It seems to share a lot of code with ABR in x264 so I'd think it shouldn't be too hard to implement
2013-09-24 18:28:58 <@muggs> I think CRF needs AQ and a couple of other minor features; but would be excellent to have
2013-09-24 18:32:41 < JEEB> I don't CRF per se needs AQ
2013-09-24 18:33:01 < JEEB> of course with AQ the encoder in general becomes more capable
2013-09-24 18:33:12 < JEEB> but it's mostly just a case of variable QP
2013-09-24 18:33:19 < JEEB> from picture to picture
2013-09-24 18:33:23 < JEEB> IIRC
2013-09-24 18:33:40 < JEEB> I think it began with the crf value set as the QP?
2013-09-24 18:34:05 < nevcairiel> isnt that --qp ? :p
2013-09-24 18:34:07  * JEEB read some of the x264's rate control code some time ago
2013-09-24 18:34:23 < JEEB> nevcairiel, that's constant qp
2013-09-24 18:34:49 < JEEB> I think CRF start with the value as QP and then applied ABR-like rate control to move that value
2013-09-24 18:35:02 <@muggs> dunno; is there any chance I can talk you into looking at it?
2013-09-24 18:47:24 < Mandarinka> the presets are based on compression usefulness of features relative to their speed costs IIRC - you would have to keep changing them as you will add more (assembly) optimizations
2013-09-24 18:48:22 < Mandarinka> although few presets for start (--fast --medium --slow) would perhaps be doable even now? Dunno how many unoptimised parts are there in x265
2013-09-24 18:48:44 <@muggs> I'm not sure assembly would necessarily change the balance as much as make all the presets a bit faster
2013-09-24 18:49:07 < nevcairiel> depends if there is a special mode thats just extremely slow now bit with asm becomes viable
2013-09-24 18:49:28 <@muggs> yeah, I was kind of thinking the middle three would make some sense now.
2013-09-24 18:50:08 <@muggs> I wouldn't call anything x265 does today as "superfast" :)  and we're still missing features that would be used for "placebo"
2013-09-24 18:50:48 <@muggs> (multiple refs, esa, etc)
2013-09-24 18:50:56 < JEEB> muggs, I could read more into it, I only read it generally as I didn't have too much time at the time
2013-09-24 18:52:27 <@muggs> thanks; it would be helpful to just have an idea of what exactly is missing at present.
2013-09-24 18:52:30 < Mandarinka> crf IIRC works even without AQ (or used to before AQ appeared in 2008) - each frame would have constant QPs, but QPs of individual frames would vary based on the qcomp compensation or like that.
2013-09-24 18:52:42 < JEEB> yes
2013-09-24 18:52:50 < Mandarinka> (note that I am just a user though)
2013-09-24 18:53:23 < JEEB> it mostly uses the same code path as ABR, but then there're some specifics behind ifs
2013-09-24 18:54:20 < Mandarinka> wasn't the relation reversed actually? I mean, that two-pass ABR was operating through determining an "average factor" to use, and then encoded with that in crf mode?
2013-09-24 18:57:41 < JEEB> I mean single-pass ABR
2013-09-24 18:59:47 < JEEB> x264_ratecontrol_new, x264_ratecontrol_start
2013-09-24 19:00:00 < JEEB> and x264_ratecontrol_init_reconfigurable
2013-09-24 19:00:30 < JEEB> @ encoder/ratecontrol.c
2013-09-24 19:56:18 <@Skyler_> I would say presets are probably hard to meaningfully make until you have proper SIMD optimization and such, so you have an idea how much things will actually cost speed-wise
2013-09-24 19:56:35 <@Skyler_> but you could make ones that are marginally guesswork-ly accurate now and change them later, I guess
2013-09-24 20:01:29 < Daemon404> kind of silly to think about preets until basic things like non-abr ratecontrol work
2013-09-24 20:01:32 < Daemon404> imo
2013-09-24 20:01:35 < Daemon404> :)
2013-09-24 20:16:14 <@muggs> I guess the question is how much pain is involved to change the meaning of the presets later
2013-09-24 20:56:02 <@Skyler_> muggs: well in x264's system it would be easy enough
--- Day changed Wed Sep 25 2013
2013-09-25 08:42:19 < nightfox> is there any tool available to debug asm code?
2013-09-25 09:28:16 < greenfountain> what is the main difference between aqmode 1 and 2 in x264? i read aq mode 2 gives better results in visual perception of the quality but how is it implemented in the code?
2013-09-25 09:29:34 < JEEB> I think the thing was that there was no consensus on the modes yet, other than AQ mode 2 seemed to give better SSIM
2013-09-25 09:30:03 < JEEB> so IIRC aq mode 2 is used with --tune ssim and aq mode 1 is otherwise the default
2013-09-25 09:33:10 < JEEB> as for the implementation, I think reading the code would most probably be the best way of getting there :P
2013-09-25 09:33:18 < greenfountain> hmm ok.. there are some slight differences.. qcomp is raised to 1 for aq mode 2 only and for ad mode 1, the  qp_adj is cliped between -5 to 5.. maybe these affect the quality
2013-09-25 09:33:47 < greenfountain> yea i am going thru the code now ..  http://git.videolan.org/?p=x264.git;a=commitdiff;h=dc4f40ce74c996a1e15021b82ab71ebcb8652d0b
2013-09-25 09:35:55 < JEEB> uhh, current AQ mode 2 was added in 2010
2013-09-25 09:35:56 < JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=74f2fd65af6840aced812e295e1a551ba295459f
2013-09-25 10:00:34 < greenfountain> fail!  thanks.
2013-09-25 10:43:16 < mahesh__> which functions in TEncSampleAdaptiveOffset or in general entire the SAO module are compute/data intensive, any suggestions
2013-09-25 11:48:01 < nightfox> I am trying to use x86inc named parameters in my asm code insted of %define, but i am getting a build error: undefined symbol `width' (first use). I have decleared my function like: cglobal fun, 0 7, 8, width so my purpose is to avoide code %define width r0
2013-09-25 11:48:22 < nevcairiel> if thats copy paste, you're lacking a , there
2013-09-25 11:48:57 < nevcairiel> also, the first argument is the number of arguments
2013-09-25 11:49:07 < nevcairiel> is width an argument?
2013-09-25 11:49:18 < nightfox> yes
2013-09-25 11:50:17 < nightfox> yes, typo mistake, it is like cglobal fun, 0, 7, 8, width
2013-09-25 11:50:41 < nevcairiel> like i said, the 0 should be the number of arguments there
2013-09-25 11:51:08 < nevcairiel> although it should probably still map width to a temporary variable otherwise
2013-09-25 11:53:50 < nightfox> yes, our purpose it to match with temporary variable but we tried with passing the number of arguments too but we are getting same build error.
2013-09-25 11:55:30 < nightfox> *map
2013-09-25 11:56:32 < nightfox> it's workig fine when I am doing: cglobal fun, 0, 7, 8
2013-09-25 11:56:44 < nightfox> %define width r0
2013-09-25 12:50:18 < Daemon404> i am always impressed that pixel-a.asm takes longer than any other file
2013-09-25 12:50:21 < Daemon404> including templated c++
2013-09-25 13:02:07 < Daemon404>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2013-09-25 13:02:07 < Daemon404> 32682 derek     20   0  967m 598m 2712 S 878.4  0.6  22:10.97 x265
2013-09-25 13:02:07 < Daemon404> ->
2013-09-25 13:02:07 < Daemon404> [0.4%] 57/15691 frames, 0.26 fps, 2848.78 kb/s, eta 16:53:28
2013-09-25 13:02:10 < Daemon404> this gonna be a while...
2013-09-25 13:31:00 <@Skyler_> @grenfountain, AQ mode 2 basically just has a slight bias based on the overall QP offset of the frame
2013-09-25 13:31:13 <@Skyler_> whereas AQ mode 1 is stateless (the same MB gets the same QP offset no matter where in the video it is)
2013-09-25 13:31:31 <@Skyler_> If you implement anything, start with 1; 2 can come later, since it's more complex
2013-09-25 13:31:51 <@Skyler_> (We never really concluded which was better, and if 2 was at all better, *how* it could be better)
2013-09-25 13:31:56 <@Skyler_> *greenfountain
2013-09-25 13:32:42 <@Skyler_> Daemon404: keep in mind that with x264asm, literally every single instruction is actually a complex, hundreds-of-lines nested macro xD
2013-09-25 13:33:57 < Daemon404> indeed
2013-09-25 13:34:09 < Daemon404> slower than big c++ files is impressive though
2013-09-25 13:35:04 < Daemon404> on a side note
2013-09-25 13:35:06 < Daemon404> [4.0%] 622/15691 frames, 0.28 fps, 2998.02 kb/s, eta 14:52:32
2013-09-25 13:35:11 < Daemon404> i wonder if the ABR RC is too strict
2013-09-25 13:38:19 < JEEB> Skyler_, btw Bugmaster had some patches for a bit modified versions of his AQ, too. Which some people found rather nice. It's a mess and we'd really need to get some real testing done if we want to get definitive answers to things :D
2013-09-25 13:40:08 <@Skyler_> yeah, there's a lot more possibilities than what we have already
2013-09-25 13:41:18 < JEEB> also one of the weirdest things that came out of now-dead (?) seraphy was MixAQ, which mixed x264's selected AQ modes and Haali's AQ. I think I tested it a bit with black pearl back in the day
2013-09-25 13:41:59 <@Skyler_> I do have a suspicion that an AQ with a stronger curve (towards lower QP) near flatness, like haali's, would be quite good
2013-09-25 13:42:15 <@Skyler_> at least in part because it would help mitigate 8-bitness
2013-09-25 13:42:38 <@Skyler_> but I was never really sure how to do it, or howm uch of that should really have been based on brightness or something
2013-09-25 13:42:59 < mahesh__> what does 'm_count' in TComSampleAdaptiveOffset class contains, which information?
2013-09-25 13:43:21 < JEEB> Skyler_, yeah -- it contains a lot of unspecified variables :/
2013-09-25 13:53:10 < Daemon404> hmmm
2013-09-25 13:53:15 < Daemon404> i wish muggs would stay online
2013-09-25 13:53:16 < Daemon404> or get a bnc
2013-09-25 13:53:26 < Daemon404> easier to leave msgs
2013-09-25 13:54:37 < Daemon404> maybe funman knows -- do you know if x265 plans to introduce something like x264_param_parse?
2013-09-25 13:54:42 < Daemon404> makes it much easier for Libav to integrate
2013-09-25 14:44:28 < pengvado> Skyler_: is it really due to hundreds-of-lines of nested macro, or is yasm still using its lousy hash implementation to lookup macro names?
2013-09-25 14:46:16 <@Skyler_> oh.  I guess it could be that <.<
2013-09-25 16:14:44 < greenfountain> yes, saw that  'strength' of each frame  in AQ mode 2 is set based on complexity in each frame
2013-09-25 16:16:05 < greenfountain> but sice we anyway use qcomp and offset aq  qp for each mb based on that, it shouldnt matter much between the 2 modes
2013-09-25 16:22:26 < BugMaster> aq strength mostly regulates not full frame offset (this is what qcomp also do) but deviation of QPs inside frame
2013-09-25 17:48:36 < greenfountain> can anyone explain what this function does - ac_energy_plane()
2013-09-25 17:50:58 < greenfountain> how do u obtain energy of each MB in aq..what is it basically
2013-09-25 19:14:16 <@Skyler_> @greenfountain the variance
2013-09-25 19:14:41 <@Skyler_> sum( (pix - avg)^2 ) for all pixels in a block, where avg is the average of those pixels
2013-09-25 19:14:45 <@Skyler_> summed over the three planes
2013-09-25 19:15:03 <@Skyler_> this is equal to (sum of squares) - (sum * sum / N), where N is the number of pixels
2013-09-25 19:15:14 <@Skyler_> I do hope people read the logs ^^;
2013-09-25 19:15:43 < Daemon404> people should get bncs / screen
2013-09-25 19:51:32 < smarter> Speaking of AQ, I have an experimental implementation of something like --aq-mode 1 for VP9 in https://gerrit.chromium.org/gerrit/#/c/65426/
2013-09-25 19:52:00 < smarter> It works, but the gains are much smaller than what you get with x264
2013-09-25 19:52:59 <@Skyler_> that's strange, I wonder why
2013-09-25 19:53:31 < smarter> one thing that is tricky(and you'll run into the same thing with HEVC) is that if you use the variance of the current transform block to change the QP, if you try different partitioning you'll end up comparing block with different QP
2013-09-25 19:53:35 < smarter> so different lambdas
2013-09-25 19:53:40 <@Skyler_> Oh, does VP9 have delta quants?
2013-09-25 19:53:47 < smarter> it doesn't, it has 8 segments
2013-09-25 19:53:52 <@Skyler_> oh.  I'm guessing that's why it helps less
2013-09-25 19:54:14 < smarter> but I tried crippling x264 in a similar way and it still seemed to work well
2013-09-25 19:54:20 <@Skyler_> if it's anything like vp8 (I hope not, but...) the arithmetic coding for segment decisions is not very efficient
2013-09-25 19:54:37 <@Skyler_> I remember vp8 basically took two bits per segment if segmentation was on, which was pretty painful.
2013-09-25 19:54:45 <@Skyler_> and with 8 segments I guess that'd be 3 bits.
2013-09-25 19:55:00 < smarter> from my tests, the segmentation signaling overhead is insignificant at high enough bitrates, and it still doesn't work very well
2013-09-25 19:55:11 <@Skyler_> Huh  that's really strange
2013-09-25 19:55:22 <@Skyler_> is lambda being changed along with QP?
2013-09-25 19:55:34 < smarter> right now, that's what I'm doing yes
2013-09-25 19:55:50 <@Skyler_> okay, yeah, just checking, since in x264 lambda is always tied to QP (until qprd is run but that doesn't matter)
2013-09-25 19:56:21 < smarter> lambda = c*qstep^2 in both x264 and libvpx afaik
2013-09-25 19:56:57 < smarter> derf suggested I try letting the lambda fixed and instead weighting distortion(by weighting each subblock by its "ideal" QP)
2013-09-25 19:57:20 < smarter> but I didn't manage to get that to work well
2013-09-25 19:57:31 <@Skyler_> I tried that in x264 too, that seems like "the right way to do it", but it's hard to get right
2013-09-25 19:58:38 < smarter> so right now, if the block is <= 16x16 I use the variance of the 16x16 block it's in, otherwise I use the variance of the block itself
2013-09-25 19:59:14 <@Skyler_> what's the granularity of QP in vp9?
2013-09-25 19:59:18 <@Skyler_> as in block size
2013-09-25 19:59:50 < smarter> you can set it at the 8x8 block level
2013-09-25 20:00:07 < smarter> if your partitioning goes down to that level of course
2013-09-25 20:01:11 <@Skyler_> so it's based on partition size, not dct size
2013-09-25 20:01:18 < smarter> yup
2013-09-25 20:01:48 < smarter> oh, and the QStep I use are base_qstep*(1.8)^(x/3) with x between -3 and 3, so I end up using 7 segments
2013-09-25 20:02:21 < smarter> so that the range is similar to [qp-5,qp+5] in h264
2013-09-25 20:04:04 < smarter> Skyler_: did you try not decreasing the QP for block with variance close to 0? It seems that most of these are noise and you can't tell the difference when you put more bits in them
2013-09-25 20:06:47 <@Skyler_> I found the opposite problem, those are often the blocks you need even more bits in, because of banding
2013-09-25 20:07:12 <@Skyler_> some anime encoders use this strange AQ that's a hybrid of Haali's (extremely low QP for flat blocks) and regular AQ
2013-09-25 20:07:14 < smarter> I'm thinking of clips like blue_sky and pedestrian_area (http://media.xiph.org/video/derf/)
2013-09-25 20:07:30 < smarter> hmm, I haven't looked at anime content
2013-09-25 20:08:16 <@Skyler_> banding in general becomes a huge problem with very flat blocks
2013-09-25 20:08:20 <@Skyler_> not only anime, but anime's a common case
2013-09-25 20:09:30 < Mandarinka> yes, everything should be based on anime :>
2013-09-25 20:09:39 < Mandarinka> but the old cel ones :D
2013-09-25 20:10:11 < JEEB> I'm not sure how used MixAQ is any more, but people still build with it at least. The little testing I did with it was actually with a live action sample back in the day. But yes, it gives a good example of how funky the needs of an AQ can be.
2013-09-25 20:10:15 < Daemon404> most video related foss is based on anime
2013-09-25 20:10:19 < Daemon404> an the people too
2013-09-25 20:10:20  * Daemon404 runs
2013-09-25 20:10:48 < Daemon404> i remember Skyler_ before irc ... ;)
2013-09-25 20:10:57 < Daemon404> on a certain anime encoding forum
2013-09-25 20:11:53 < JEEB> lol
2013-09-25 20:12:15 < JEEB> that astrataro Chinese builder seems to have merged OreAQ and MixAQ and all that stuff into a single patch
2013-09-25 20:12:17 < JEEB> https://github.com/astrataro/x264_tMod/commit/38d84d8089b68a46c3534d18fb5139b98c7bb0df
2013-09-25 20:12:28 < Daemon404> i still dont know what all these japanese aq do
2013-09-25 20:12:49 < koda> chinese?
2013-09-25 20:12:54 < JEEB> yeah
2013-09-25 20:12:55 < Daemon404> arent these the same people keeping Skyler_'s old FGO patch around?
2013-09-25 20:13:06 < Daemon404> koda, chinese merging japanese code
2013-09-25 20:13:07 < Daemon404> ;)
2013-09-25 20:13:14 < JEEB> MixAQ was simple. You had strengths for the normal AQ and the Haali AQ, and the result was then somehow merged
2013-09-25 20:13:17 < koda> lmao
2013-09-25 20:13:32 < JEEB> astrataro does tend to mingle around .jp encoding stuff
2013-09-25 20:13:37 < Daemon404> haali aq brings back memories.
2013-09-25 20:13:42 < JEEB> yes, it's *old*
2013-09-25 20:13:52 < JEEB> anyways, RIP seraphy who made OreAQ and MixAQ
2013-09-25 20:13:56 < Daemon404> he died?
2013-09-25 20:13:57 < JEEB> OreAQ was then something almost unusable
2013-09-25 20:14:02 < JEEB> Daemon404, off the internet at least
2013-09-25 20:14:19 < Daemon404> winny/share bust obviously
2013-09-25 20:14:20  * Daemon404 runs
2013-09-25 20:14:27 < JEEB> OreAQ made you use an AviUtl preview plugin to set the specific values of how it worked
2013-09-25 20:14:35 < koda> Daemon404: you already ran before
2013-09-25 20:14:37 < JEEB> and thus you pretty much pin-pointed the AQ for your clip
2013-09-25 20:14:49 < Daemon404> koda, one can run infinite times on the intertubes
2013-09-25 20:15:07 < Daemon404> just like one can be stabbed infinite times
2013-09-25 20:15:55  * koda brings the problem of gdb on the table
2013-09-25 20:16:09 < Daemon404> youre going to have to be more specific
2013-09-25 20:16:26 < koda> lol
2013-09-25 20:17:02 < koda> can't remember now, there was some msvc/gdb/lldb discussion the other day and you simply stopped talking and ran away :p
2013-09-25 20:26:00 < smarter> Skyler_: I think that comparing the RD cost of different partitionings (e.g. 64x64 block with QP x vs two 64x32 blocks with QP y and z) gives weird results
2013-09-25 20:26:33 <@muggs> Daemon404: can you elaborate on your assert() complaint.  what do you think they should be used for?
2013-09-25 20:26:44 < smarter> maybe the comparaison should be done with another cost function
2013-09-25 20:27:26 < Daemon404> muggs, i was under the impression that the function was called differently
2013-09-25 20:27:34 < Daemon404> i guess its OK if it checks for invalid usage
2013-09-25 20:27:36 < Daemon404> and is internal
2013-09-25 20:27:38 <@muggs> oh
2013-09-25 20:27:41 <@muggs> ok
2013-09-25 20:29:13 < smarter> Skyler: but it's kinda hard to answer "Is it better to give a high QP to this block because it has high energy, or split it and give low QPs to some of the subblocks because they have low energy"
2013-09-25 20:29:31 <@muggs> I don't particularly care for the new function name: subpelInterpolate2
2013-09-25 20:29:47 < Daemon404> me neither
2013-09-25 20:35:06 <@Skyler_> smarter: yeah, I'm not sure how to do it, "fortunately" x264 didn't have that problem, but...
2013-09-25 20:36:00 < smarter> heh :)
2013-09-25 20:36:09 < smarter> I still need to try aq-mode 2
2013-09-25 20:37:43 < BugMaster> try to always use 16x16 block cost not matter how you partition it to mimic x264
2013-09-25 20:38:16 < smarter> BugMaster: I'm not sure what you mean
2013-09-25 20:38:37 < smarter> are you talking about aq-mode 2?
2013-09-25 20:38:43 < BugMaster> I mean use variance of 16x16 blocks only to calc QP offset
2013-09-25 20:38:44  * koda suggests 4x4
2013-09-25 20:39:07 < smarter> BugMaster: so, what offset do you choose for a 32x32 block?
2013-09-25 20:39:23 < BugMaster> average of 4 16x16 blocks
2013-09-25 20:40:18 < smarter> I tried something like that (use average of subblock variances for blocks > 16x16) and it didn't work well
2013-09-25 20:41:11 < smarter> I didn't try always using the average of 16x16 variance for a 64x64 block, but I doubt it would work well
2013-09-25 20:42:15 < BugMaster> do you used average of variances or average of QP offsets?
2013-09-25 20:43:20 < smarter> average of variance
2013-09-25 20:44:49 < BugMaster> try with average of QP offsets. i.e. like all blocks are 16x16 and if it smaller all that inside will get this 16x16 QP offset and if it >16x16 it will get average of QP offsets
2013-09-25 20:45:50 < Daemon404> muggs, btw i hope i didnt come off as a douche to your boss
2013-09-25 20:45:55 < Daemon404> i tried extra hard to not be a douche
2013-09-25 20:46:11  * Daemon404 is just naturally douchey
2013-09-25 20:46:24 < smarter> BugMaster: I'll try, any reason why this would work better?
2013-09-25 20:47:30 < BugMaster> is vp9 QP scale is linear or not?
2013-09-25 20:48:04 < smarter> it's similar to h264 but much more fine-grained
2013-09-25 20:48:26 < smarter> but for each frame, you can only use 8 QPs because it's signaled at the segment level and there's 8 segments
2013-09-25 20:48:43 <@muggs> Daemon404: lol, no complaints.  it's hard in emails not to sound like an a-hole
2013-09-25 20:48:44 < smarter> <smarter> oh, and the QStep I use are base_qstep*(1.8)^(x/3) with x between -3 and 3, so I end up using 7 segments
2013-09-25 20:48:44 < smarter> <smarter> so that the range is similar to [qp-5,qp+5] in h264
2013-09-25 20:48:52 < Daemon404> muggs, true dat
2013-09-25 20:50:39 <@muggs> I sent a cleaned up patch to the ML.  I would like to clean it up a bit more in a second patch; making subpelCompare use subpelInterpolate, so we only have one MC function
2013-09-25 20:50:40 < smarter> qp[i+1]=MIN(qp[i]+1, qp[i]*1.01975);
2013-09-25 20:50:56 < smarter> in vp9
2013-09-25 20:51:10 < Daemon404> magic tuned numbers?
2013-09-25 20:51:36 < smarter> tuned so that you get 256 QP values
2013-09-25 21:30:19 <@muggs> BTW: I've opened the bitbucket issue tracker on the x265 repo.  you have to be logged into to create new issues (a lame attempt to reduce spam)
2013-09-25 21:31:57 < Daemon404> if i had a nickel for every bug tracker ive created for a one off
2013-09-25 21:32:00 < Daemon404> and then forgot
2013-09-25 21:32:07 < Daemon404> and then created a new acount next time.
2013-09-25 21:36:44 < nevcairiel> should always use the same name, then you notice that its taken
2013-09-25 21:47:39 <@muggs> Daemon404: you already have a BB login
2013-09-25 21:50:15 < Daemon404> i know
--- Day changed Thu Sep 26 2013
2013-09-26 00:23:08 < smarter> hmm, so the HM lambda is not c*Qstep^2 but a*R^b, where a and b depend on various things: http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=6473
2013-09-26 00:26:29 <@Skyler_> what's R?
2013-09-26 00:47:31 < smarter> rate
2013-09-26 00:47:50 < smarter> in "bits per pixel" apparently
2013-09-26 00:49:28 <@Skyler_> that... that makes so little sense
2013-09-26 00:49:35 <@Skyler_> bitrate is a consequence of lambda, not vice versa... (?)
2013-09-26 00:51:07 <@Skyler_> that's really strange ratecontrol...
2013-09-26 01:03:18 < smarter> if you have a target bitrate, you want to set your lambda so that you can achieve that bitrate
2013-09-26 01:04:20 < smarter> it's not much more weird that tweaking your QP so that you can achieve some bitrate
2013-09-26 01:07:31 <@Skyler_> I thought you meant that bitrate X means lambda Y
2013-09-26 01:07:39 <@Skyler_> regardless of the video content
2013-09-26 01:07:43 <@Skyler_> or, well, bits per pixel X means lambda Y
2013-09-26 01:08:32 <@Skyler_> lambda = c*qstep   ->    "I will vary qstep to achieve a lambda"
2013-09-26 01:08:47 <@Skyler_> lambda = a*R^B   "I will very rate to achieve a lambda (?!)"
2013-09-26 01:09:18 <@Skyler_> it also seems a little weird because ratecontrol doesn't have to be about bitrate at all... how would you do CRF with a scheme that bakes bitrate into the formula?
2013-09-26 01:09:27 <@Skyler_> unless I'm totally misunderstanding this
2013-09-26 01:09:55 < smarter> the a and b are different depending on what kind of frame this is
2013-09-26 01:10:09 < smarter> and change inside the frame too I think
2013-09-26 01:12:07 <@Skyler_> "what kind of frame"?
2013-09-26 01:12:22 <@Skyler_> how do they derive a and b based on the frame content?
2013-09-26 01:19:48 < smarter> look at the powerpoint in http://phenix.it-sudparis.eu/jct/doc_end_user/documents/11_Shanghai/wg11/JCTVC-K0103-v2.zip for the details, I'll get it wrong if I try to paraphrase :)
2013-09-26 01:28:56 <@Skyler_> ohhhhhh I see the purpose of this
2013-09-26 01:29:15 <@Skyler_> this is really a more accurate version of qp2qscale
2013-09-26 01:29:27 <@Skyler_> that tries to better guess how a different qp (lambda) will affect bitrate
2013-09-26 01:29:47 <@Skyler_> thus allowing a slightly more accurate ratecontrol than one that simply assumes bitrate scales based on linearized quantizer
2013-09-26 01:30:24 <@Skyler_> but if I understand right, this is *not* a way to derive lambda from QP, it's a way to better adapt in target-bitrate mode
2013-09-26 01:30:39 <@Skyler_> so if implemented in x264, this would not affect the interface or anything outside of ratecontrol.c.
2013-09-26 01:30:45 <@Skyler_> unless I'm not understanding it right.
2013-09-26 01:32:43 < smarter> I think it's QP that is derived from the lambda
2013-09-26 01:38:13 < smarter> ah no, lambda is derived from QP in HM currently
2013-09-26 01:41:03 < smarter> actually there's both, see TEncRCPic::getLCUEstLambdaAndQP(Double bpp, Int clipPicQP, Int *estQP) in TEncRateCtrl.cpp
2013-09-26 01:42:16 < smarter> or getLCUEstQP(Double lambda, Int clipPicQP) in x265
2013-09-26 01:48:40 <@Skyler_> oh geez, both:/
2013-09-26 09:49:12 < nightfox> is _mm_blendv_epi8 supported in VS11 32 bit?
2013-09-26 09:49:21 < nightfox> that instruction seems to create a problem
2013-09-26 09:49:46 < nightfox> code is :   pblendvb    xmm3, xmm2, xmm0
2013-09-26 09:50:14 < nightfox> but it looks like it is generating some wrong code
2013-09-26 09:50:19 < nightfox> 00F0DADE  movdqa      xmm3,xmm2
2013-09-26 09:50:27 < nightfox> 00F0DAE2  pblendvb    xmm3,xmm0,xmm0
2013-09-26 09:50:52 < nightfox> but,the value of xmm3 should not be corrupted in the code
2013-09-26 09:58:35 < nightfox> oops...my mistake
2013-09-26 09:59:00 < nightfox> now its correct.. wrong usage of params
2013-09-26 18:44:03  * Daemon404 doesnt understand the point of mp4 support in x265
2013-09-26 18:44:06 < Daemon404> (or x264 for that matter)
2013-09-26 18:51:07 < JEEB> timestamps on the stream would be my guess
2013-09-26 18:52:39 < kierank> yeah
2013-09-26 18:52:42 < kierank> vfr timestamps
2013-09-26 18:53:21 < Daemon404> which x265 cant do yet
2013-09-26 18:53:48 < JEEB> I do agree with you that it's way too early to start outputting anything else but raw Annex B at this point :P
2013-09-26 18:53:55 < JEEB> just sayan', you know?
2013-09-26 19:08:38 < BugMaster> do lsmash as library already implemented HEVC/H.265 support?
2013-09-26 19:08:59 < Daemon404> BugMaster, mostly yes
2013-09-26 19:09:08 < Daemon404> but i dont think it shoud bundled.
2013-09-26 19:11:05 < BugMaster> so the specs was made public (wasn't the case last time I heard about hevc in mp4 and so in mkv)
2013-09-26 19:11:09 < BugMaster> ?
2013-09-26 19:11:17 < Daemon404> im not sure
2013-09-26 19:11:20 < Daemon404> something was
2013-09-26 19:11:34 < JEEB> 14496-15 3rd ed was leaked
2013-09-26 19:11:46 < JEEB> the FDIS draft
2013-09-26 19:12:00 < JEEB> that's what was used to implement HEVC-in-mp4 in L-SMASH
2013-09-26 19:12:20 < JEEB> leaked here http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
2013-09-26 19:12:23 < JEEB> uhh
2013-09-26 19:12:25 < JEEB> linked here
2013-09-26 19:12:25 < JEEB> I mean
2013-09-26 19:13:39 < JEEB> I do hate the idea that these actually have to be leaked in order to not have to copy GPAC's implementation based on their code -_-
2013-09-26 19:47:34 <@muggs> I don't follow; why is it bad to be able to output mp4 other than obvious patent issues?
2013-09-26 19:48:36 < JEEB> it's not bad, just that in most cases outputting video into mp4 without audio isn't that useful because you would have to remux again
2013-09-26 19:48:50 < JEEB> of course there are cases like VFR where having timestamps with the video is a good thing
2013-09-26 19:49:06 < JEEB> mp4 as such is pretty much free for people to implement as far as I know
2013-09-26 19:49:07 <@muggs> ah, got it.
2013-09-26 19:49:25 <@muggs> they'd have to just demux it again anyway
2013-09-26 19:52:17 < Daemon404> muggs, i dont see teh advantage of having in in x265 or x265
2013-09-26 19:52:28 < Daemon404> when you can build ffmpeg/libav with libx265 or libx264
2013-09-26 19:52:35 < Daemon404> kind of backwards to me
2013-09-26 19:54:35 <@muggs> agreed; though we don't have ffmpeg integration just yet.  I expect it will happen soon
2013-09-26 19:56:02 <@muggs> though, for me it would be nice to debug/evaluate x265 by being able to playback an mp4 - but it would be mostly useless outside of debugging
2013-09-26 19:56:19 < Daemon404> i have a libx265.c mostly-ish there
2013-09-26 19:56:31 < Daemon404> but it lack even a hevc codec id right now
2013-09-26 19:56:31 <@muggs> oh, cool
2013-09-26 19:56:33 < Daemon404> or any way to mux
2013-09-26 19:56:37 < Daemon404> so theres no point in sending it
2013-09-26 19:56:46 <@muggs> right
2013-09-26 19:57:08 < Daemon404> btw lsmash can mux hevc
2013-09-26 19:57:11 < Daemon404> using its standalone app
2013-09-26 19:57:15 < Daemon404> just fyi.
2013-09-26 19:57:23 < JEEB> yeah
2013-09-26 19:57:49 < JEEB> also I guess libavformat stuff will start getting HEVC support after the decoder gets worked upon
2013-09-26 19:58:36 < Daemon404> ill send it after that
2013-09-26 19:58:46 < Daemon404> also
2013-09-26 19:58:52 < Daemon404> testing my libx265.c is a pain
2013-09-26 19:58:59 < Daemon404> due to x265's lack of install
2013-09-26 19:59:01 < Daemon404> and shared libs
2013-09-26 20:02:20 <@muggs> understood
2013-09-26 21:40:43 < Daemon404> muggs, whats with all thw fwd: replies
2013-09-26 21:40:46 < Daemon404> on the ML
--- Day changed Fri Sep 27 2013
2013-09-27 05:07:16 <@muggs> Daemon404: I don't see what you mean.  Are you getting CC'd on some of the mails or something?
2013-09-27 09:32:42 < Daemon404> sd
2013-09-27 09:32:44 < Daemon404> woops
2013-09-27 09:37:54 < Daemon404> damn hes gone
2013-09-27 12:00:12 < Daemon404> http://chromashift.org/img/x265/comparison_abr_27sep2013.png
2013-09-27 12:00:16 < Daemon404> for anyoen curious
2013-09-27 12:09:04 < kurosu_> Daemon404: you may have inverted the options used for x264 and x265
2013-09-27 12:09:14 < Daemon404> define inverted
2013-09-27 12:09:16 < kurosu_> (in the legends)
2013-09-27 12:09:24 < Daemon404> i dont think so
2013-09-27 12:09:26 < Daemon404> i checked
2013-09-27 12:09:35 < kurosu_> ok
2013-09-27 12:09:46 < Daemon404> (i made separate graphs originally)
2013-09-27 12:09:51 < JEEBsv> so defaults for x264 and palcebo+no-psy for x265? :D
2013-09-27 12:09:56 < Daemon404> yes
2013-09-27 12:10:04 < Daemon404> http://chromashift.org/img/x265/
2013-09-27 12:10:07 < JEEBsv> ...
2013-09-27 12:10:10 < Daemon404> streams themselevs can be found here
2013-09-27 12:10:15 < JEEBsv> I don't think x265 doesn't have presets yet
2013-09-27 12:10:18 < JEEBsv> nor tunes
2013-09-27 12:10:25 < Daemon404> OH
2013-09-27 12:10:26 < Daemon404> im dumb
2013-09-27 12:10:31 < JEEBsv> :D
2013-09-27 12:10:35 < Daemon404> i put the ptons beside te wrong names
2013-09-27 12:10:38 < Daemon404> the names are correct
2013-09-27 12:10:40 < JEEBsv> yeah
2013-09-27 12:10:44 < JEEBsv> it looked like that
2013-09-27 12:11:09 < kurosu_> how good is the abr for x265? I would expect most codecs with proper rc to beat a superior codec without
2013-09-27 12:11:20 < JEEBsv> it's  better than divx's
2013-09-27 12:11:24 < JEEBsv> I would think
2013-09-27 12:11:54 < Daemon404> divx undershoots massively
2013-09-27 12:11:57 < Daemon404> and blurs a lo
2013-09-27 12:11:58 < Daemon404> r
2013-09-27 12:11:59 < Daemon404> lot*
2013-09-27 12:12:00 < kurosu_> (I include in rc frame type and quantizer decision)
2013-09-27 12:12:25 < Daemon404> fixed the egend
2013-09-27 12:12:30 < Daemon404> legend*
2013-09-27 12:12:58 < Daemon404> i should also note x265 took 16-17 hrs
2013-09-27 12:13:01 < Daemon404> while x265 took 1
2013-09-27 12:13:06 < Daemon404> on this machine
2013-09-27 12:13:35 < JEEBsv> Daemon404: I loved how divx just suddenly decides on the third gop to go over 40 with QPs
2013-09-27 12:26:46 < greenfountain> can anyone explain the SSIM computation done in x264 - in x264_pixel_ssim_wxh()
2013-09-27 12:50:14 < Nabajit> Incase we need more than 8 xmm regs, what can be done?
2013-09-27 12:50:45 < Nabajit> How can the stack in this case?
2013-09-27 12:50:54 < Nabajit> *stack be used
2013-09-27 12:52:06 < Nabajit> Can someone please refer any particular example of that in x264 asm?
2013-09-27 15:40:16 <@Skyler_> @nabajit: lots of DCT/iDCT functions (dct-32.asm for example) as well as deblock
2013-09-27 18:50:55 < Daemon404> muggs, hey
2013-09-27 18:51:10 < Daemon404> by fwd i meant some of the MCW dev replies have "Fwd:" in the subject
2013-09-27 18:51:11 < Daemon404> it's weird
--- Day changed Sat Sep 28 2013
2013-09-28 11:02:14 <@Skyler_> muggs: I really do not understand what your asm coders are trying to do in creating MC functions for blocks 5 pixels wide or something
2013-09-28 11:02:21 <@Skyler_> I am pretty sure such blocks don't exist
2013-09-28 11:10:16 <@Skyler_> in particular, they seem to be writing asm "to the test", without understanding that their tests are simply wrong
2013-09-28 11:10:51 <@Skyler_> unless I'm missing something and HEVC now has completely arbitrary-shaped blocks
2013-09-28 11:11:16 < kurosu> smallest width is 4 (for unidir 4x8 blocks)
2013-09-28 11:12:01 < kurosu> (and for luma)
2013-09-28 11:16:01 <@Skyler_> does it have 5x8 blocks?
2013-09-28 11:16:58 <@Skyler_> as far as I can tell from the mailing list post, they're designing the asm functions to handle arbitrary widths, including nubmers like 3 or 5 or 7, which confuses me
2013-09-28 11:17:02 <@Skyler_> because I didn't think those existed.
2013-09-28 11:36:17 < Manao> they do not. partition sizes are NxN, Nx2N, 2NxN, (Nx4N, 3Nx4N), (4NxN, 4Nx3), with N=4, 8, 16, 32 (only for the first 3) or 64 (only for the first)
2013-09-28 11:36:40 < Manao> s/4Nx3/4Nx3N/
2013-09-28 11:55:22 < Manao> oh, and there is no 4x4 for inter prediction
2013-09-28 13:14:27 < kierank> Skyler_: they think it's c
2013-09-28 13:15:17 < kierank> and perhaps are not aware that you write different optimisations depending on the width/height
2013-09-28 13:59:08 < Daemon404> kierank, kind of demeans the entire point of SIMD
2013-09-28 13:59:23 < kierank> no shit
--- Day changed Sun Sep 29 2013
--- Day changed Mon Sep 30 2013
2013-09-30 08:54:25 < thresh> ohai
2013-09-30 08:57:33 < thresh> I have just set up hooks to notify x265-commits mailing list with emails per commit
2013-09-30 08:57:46 < thresh> please test/enjoy/submit bug reports
2013-09-30 08:59:45 < thresh> by default those mails will use From: with your username defined in ~/.hgrc
2013-09-30 08:59:54 < thresh> (I guess)
2013-09-30 10:44:46 < funman> thresh: cheers
2013-09-30 13:19:49  * Daemon404 still things the "reimplement STL" bt is really, really stupid.
2013-09-30 19:12:50 < muggs> Skyler_: the odd block sizes come from combining HPEL refine candidates together into one interpolation: two 4x8 interpolations that are off by one pixel can be measured by one 5x8
2013-09-30 19:26:59 <@Skyler_> muggs: but in that case, there is never any harm in interpolating /too many/ pixels
2013-09-30 19:27:11 <@Skyler_> so it doesn't make sense to do extra work
2013-09-30 19:27:15 <@Skyler_> in order to pblend things
2013-09-30 19:27:17 < muggs> I agree, that's what I told them
2013-09-30 19:27:41 < muggs> Min seems to think it's less efficient that way
2013-09-30 19:43:50 <@Skyler_> what's min's logic?
2013-09-30 19:49:25 < muggs> looking for his comments...
2013-09-30 19:50:41 < muggs> ah, he was arguing against my suggestion of padding width to nearest 4
2013-09-30 19:51:44 < muggs> you are simply suggesting to not try to prevent writes past the end?  so assume stride is large enough and the pixels to the right are mungeable?
2013-09-30 19:55:26 <@Skyler_> yes, which should work okay for the hpel case since it's just a buffer on the stack that is of arbitrary size and stride
2013-09-30 19:55:36 <@Skyler_> and needs to be padded for alignment anyways
2013-09-30 19:55:52 <@Skyler_> e.g. in x264 we need a width-17 MC, but the buffer has stride 32 (rounded from 16)
2013-09-30 19:56:01 <@Skyler_> so we can write past all we want without problem
2013-09-30 19:56:37 <@Skyler_> a lot of small width things in x264 write past the end without trouble because of the h264 scan order
2013-09-30 19:56:45 <@Skyler_> e.g. intra predict asm has many functions that write off the right side
2013-09-30 19:56:51 <@Skyler_> those work because the right side has never been encoded yet
2013-09-30 19:58:56 < muggs> sure, and for real MC we will only be interpolating actual inter block sizes
2013-09-30 19:59:16 < smarter> Skyler_: I noticed that x264 can do deblocking during RDO, what's the impact of that feature on speed/quality like?
2013-09-30 20:00:13 < smarter> and I didn't check, but I guess that the missing encoded blocks are replaced by the source blocks for this deblocking?
2013-09-30 20:01:47 <@Skyler_> Very small impact, and it's limited since it can't do block edges
2013-09-30 20:01:50 <@Skyler_> only inner edges
2013-09-30 20:02:13 <@Skyler_> it's only on in slower modes
2013-09-30 20:02:50 <@Skyler_> ah, ~0.5%, but a bit larger if QPRD is on
2013-09-30 20:04:14 < smarter> ok, thanks
2013-09-30 20:04:15 < muggs> how does QP RD work in x264?
2013-09-30 20:04:47 < smarter> muggs: it reencodes with QP lower and lower and see if RD cost gets better
2013-09-30 20:04:51 <@Skyler_> and higher and higher
2013-09-30 20:04:56 <@Skyler_> it just changes QP at the same lambda
2013-09-30 20:05:05 < muggs> at the MB level?
2013-09-30 20:05:07 <@Skyler_> it's a final refine step of RD, after picking modes and such, enabled on the slowest modes
2013-09-30 20:05:11 <@Skyler_> yeah
2013-09-30 20:05:28 < muggs> oh, so it's not re-doing analysis, just quant?
2013-09-30 20:05:52 <@Skyler_> just quant, yeah.
2013-09-30 20:06:05 <@Skyler_> "can trellis come up with a better way, given the same lambda, to encode this block at a different QP?"
2013-09-30 20:06:23 <@Skyler_> technically it redoes all of the encoding, so the dct+mc is redundant, but almost all the time is spent in trellis.
2013-09-30 20:06:33 < smarter> why do you let the lambda fixed?
2013-09-30 20:06:44 <@Skyler_> because it's ratecontrol's job to pick the lambda
2013-09-30 20:07:02 <@Skyler_> lambda represents "how important is this block, quality-wise"
2013-09-30 20:07:08 <@Skyler_> analysis' job is to find the best way to encode a block given that lambda.
2013-09-30 20:07:22 <@Skyler_> ratecontrol + psy has the job of picking the lambda to begin with.
2013-09-30 20:08:48 <@Skyler_> if analysis could change the lambda, it would just pick the lowest lambda possible, because that would give the lowest RD score.
2013-09-30 20:10:32 < smarter> not if changing the lambda also change the QP?
2013-09-30 20:15:44 <@Skyler_> then it'd pick QP 0 every single time, because QP0 has the lowest lambda
2013-09-30 20:16:15 <@Skyler_> RD = bits * lambda^2 + distortion
2013-09-30 20:16:17 < smarter> it does, but the rate would be much higher so the RD score could be bigger than the RD score at a lower QP
2013-09-30 20:16:26 <@Skyler_> but it wouldn't, because the lambda would be smaller!
2013-09-30 20:16:28 < smarter> *higher QP
2013-09-30 20:16:32 <@Skyler_> qp 0 has a much smaller lambda than the higher QP does.
2013-09-30 20:17:04 <@Skyler_> qp0 lambda^2: 14       qp32 lambda^2: 23407
2013-09-30 20:17:17 <@Skyler_> 14 * 1000 bits + dist <<<<<<< 23407 * 100 bits + dist
2013-09-30 20:20:07 < smarter> right, if the delta is very big you can get this kind of stuff
2013-09-30 20:20:30 <@Skyler_> if you let the QPRD loop do that, it will simply iterate down picking lower QPs each time
2013-09-30 20:20:36 <@Skyler_> I've tried it; it literally picks QP 0 for every MB
2013-09-30 20:20:53 <@Skyler_> or whatever you set the limit to
2013-09-30 20:21:26 < smarter> that's interesting, I'd expect that when you only go down 1 or 2 QP, the lambda doesn't change that much so the difference in rate could be enough to get a bigger RD score
2013-09-30 20:21:39 <@Skyler_> the lambda changes enormously
2013-09-30 20:21:53 <@Skyler_> e.g. 32 is 23407, 29 is 11703
2013-09-30 20:21:57 <@Skyler_> (lambda squared)
2013-09-30 20:24:37 < smarter> yeah, that's probably one of the reason why my AQ patch for VP9 isn't working great, the different partitioning get different QPs and different lambdas, and comparaison becomes impossible
2013-09-30 20:24:54 < smarter> I tried using a fixed lambda for the whole frame but it gave terrible results
2013-09-30 20:25:31 <@Skyler_> I suggest picking QPs before analysis, not after
2013-09-30 20:25:42 <@Skyler_> or, well, picking lambdas at least.
2013-09-30 20:26:28 < smarter> I tried picking a QP for the whole 64x64 superblock and that didn't work well either, I guess I could try using the lambda corresponding to that QP as the fixed lambda for partitioning this superblock
2013-09-30 20:26:39 <@Skyler_> so like, you could pick the lambdas for each 8x8 or 16x16 block, then figure out how to partition from there
2013-09-30 20:27:20 < smarter> hmm, I don't follow, if you pick lambda for each subblock, what lambda do you use for the superblock they're part of?
2013-09-30 20:33:20 < BugMaster> as there is no such problem in H.264 so it is part of your research to find out. but you have not so many varaints: min / max / avg
2013-09-30 20:34:54 < smarter> yeah I tried some of that stuff(like using the average QPs of the 16x16 blocks like you suggested the other day), but this doesn't get rid of the fact that I'm comparing partitioning with different lambdas
2013-09-30 20:35:56 < smarter> I didn't try averaging the lambdas themselves actually, I don't know if that would help
2013-09-30 20:39:36 < BugMaster> can't you try decide partioning using constant lambda (some average one) and make final encode with lamdas of decided partioning
2013-09-30 20:41:53 <@Skyler_> smarter: you don't have to use a constant lambda for a single bock
2013-09-30 20:41:54 <@Skyler_> *block
2013-09-30 20:41:57 < smarter> hmm, that might work. I just tried doing the partitioning with the frame lambda and frame QP, this sounds better
2013-09-30 20:42:02 <@Skyler_> you can use different lambdas for different parts of a block.
2013-09-30 20:42:14 <@Skyler_> and keep the lambdas identical no matter what the partitioning is.
2013-09-30 20:43:54 < smarter> ah, that I didn't try. I did try letting the lambda fixed and weighting the distortion which should have had a similar effect
2013-09-30 20:45:26 <@Skyler_> yeah, that's effectively the same thing, I've tried that in x264 though it's less applicable there
2013-09-30 20:48:24 < smarter> on a related subject, why does x264 use SATD instead of SSE as a distortion metrics for some of the mode decisions?
2013-09-30 20:54:09 <@Skyler_> it doesn't
2013-09-30 20:54:18 <@Skyler_> SATD is a bit cost measurement, not a distortion measurement
2013-09-30 20:54:53 <@Skyler_> non-RD mode decision is about measuring the bit cost of coding the difference between a prediction and source pixels
2013-09-30 20:55:16 <@Skyler_> you can't really accurately measure the distortion that will be left over after quantizing that difference without actual encoding, which is what RD is for
2013-09-30 20:55:27 <@Skyler_> so we just try to approximate the bit cost.
2013-09-30 21:30:01 < smarter> Skyler_: what about SATD in "SATD0 = SATD + lambda*bits" ?
2013-09-30 21:31:26 <@Skyler_> which code are you referring to?
2013-09-30 21:31:58 < smarter> I'm looking at the x264 paper: http://akuvian.org/src/x264/overview_x264_v8_5.pdf :)
2013-09-30 21:32:56 <@Skyler_> That's talking about the approximate bit cost of syntax elements being added to the approximate bit cost of the residual
2013-09-30 21:33:05 <@Skyler_> SATD score = SATD of residual + lambda * (bit cost of syntax elements)
2013-09-30 21:33:06 <@Skyler_> e.g. MV costs
2013-09-30 21:34:07 < smarter> oh, okay, how is the lambda determined here?
2013-09-30 21:35:14 <@Skyler_> it's the lambda derived from the QP, based on a table
2013-09-30 21:38:16 < smarter> makes sense, thanks for the explanations!
2013-09-30 21:38:52 <@Skyler_> np ^^
2013-09-30 22:13:10 < muggs> Daemon404: I can't square your wanting us to migrate to C with your wanting us to keep STL
2013-09-30 22:13:40 < muggs> none of the recent patches are replacing classes with classes, they're replacing classes with malloc/free, etc
2013-09-30 22:40:42 < Daemon404> thats quite a different motivation than 'compiler support'
2013-09-30 23:18:02 < davety> Hi all.  I just updated the coding style part of the wiki to include the _t postfix in the naming standards based on a recent mailing list comment about it.
2013-09-30 23:21:19 < davety> I know not all of the code meets the naming standards of prefixes and the typedef postfix,  If there are no objections I would like to add a comment to the wiki about updating names as part of making other changes if that seams reasonable and no one objects.
2013-09-30 23:24:28 < Daemon404> that seems reasonable
2013-09-30 23:24:44 < Daemon404> its been bthering me to see patches change functions without fixing the names
2013-09-30 23:32:21 < davety> I thought at the least people should know the naming convention isn't currently applied everywhere
2013-09-30 23:34:06 < davety> ugh... I am getting "Internal Server Error" when trying to view the wiki
--- Day changed Tue Oct 01 2013
2013-10-01 06:05:29 < nightfox> what changes we need to make in 32-bit asm code to make it 64-bit?
2013-10-01 06:05:54 < nightfox> does x264 have any macro to do it?
2013-10-01 06:23:48 < greenfountain> in one of the doom forum threads, I saw that for SSIM in x264 "blocks are overlapped differently specifically to avoid the pitfall of the SSIM calculation blocks matching x264's DCT blocks " . what is the pitfall if it match with DCT blocks? why is it done this way
2013-10-01 07:32:13 <@Skyler_> nightfox: that's what x86inc does.  x86_64 and x86_32 asm code is identitical.
2013-10-01 07:32:54 <@Skyler_> greenfountain: SSIM is often calculated blockwise instead of the ideal/correct way because the ideal/correct way is incredibly slow
2013-10-01 07:33:42 <@Skyler_> however, if those blocks match up with DCT blocks, e.g. block edges never have their quality measured, it may bias SSIM upwards, especially at lower quality levels where the video is more blocky
2013-10-01 07:34:20 < nightfox> @Skyler_ so do we need to add any extra macro
2013-10-01 07:40:25 <@Skyler_> no, it does it automatically.
2013-10-01 07:40:35 <@Skyler_> it's possible to break compatibility, e.g. if you write code that explicitly assumes one or the other
2013-10-01 07:40:58 <@Skyler_> but normally you don't have to do anything if the code is right.
2013-10-01 07:42:40 < nightfox> then I think we should not use %if ARCH_X86_64 == 0?
2013-10-01 07:43:31 < nightfox> if we want our code to be run for both 32 and 64-bit
2013-10-01 07:46:49 <@Skyler_> Yes, that kind of disables your code on 64-bit.
2013-10-01 07:47:11 <@Skyler_> that would be what you'd put in if you wanted a 32-bit only function
2013-10-01 08:06:03 < p0nce> Skyler_: do x86inc account for excess registers in x86_64 then?
2013-10-01 08:11:18 <@Skyler_> what do you mean?
2013-10-01 08:31:30 < p0nce> I meant: can you use extra registers (eg: xmm8..xmm15) if 32-bits asm and 64-bits asm is merged?
2013-10-01 09:09:41 < nightfox> when I am trying to build my 32-bit code as 64-bit code it's genrating  error: invalid size for operand 1
2013-10-01 09:10:10 < nightfox> corresponding instruction is: mov         src,        r0m
2013-10-01 09:10:46 < nightfox> is it actual source of problem?
2013-10-01 09:45:44 < nightfox> our src is: %define src         r0
2013-10-01 11:30:15 <@Skyler_> p0nce: no, of course you can't use xmm8-xmm15 in 32-bit mode
2013-10-01 11:31:34 <@Skyler_> nightfox: That code is invalid in 64-bit mode; this is why bypassing x86inc to do things like parameter loading can be tricky and generally makes it harder to be platform independent
2013-10-01 11:31:51 <@Skyler_> you probably want something like movifnidn src, r0m
2013-10-01 11:32:13 <@Skyler_> keep in mind the first parameter is not on the stack in 64-bit mode
2013-10-01 11:32:53 <@Skyler_> or maybe movifnidn src, r0mp (?)   I don't remember exactly, I rarely fiddle with it, I ususally let x86inc do it for me.
2013-10-01 11:33:50 <@Skyler_> ... okay, I think that's right.
2013-10-01 11:34:57 <@Skyler_> basically, the instant you start messing around with the stack, the exact locations of parameters, and so on, you're making life harder for yourself.
2013-10-01 11:37:20 < nightfox> how we can solve it using  x86inc?
2013-10-01 11:37:26 <@Skyler_> Where's the code?
2013-10-01 11:39:24 <@Skyler_> the other thing is you can't simply assume register sizes
2013-10-01 11:39:35 <@Skyler_> on 32-bit, everything is 32-bit, but on 64-bit you don't want all your variables to be 64-bit
2013-10-01 11:39:42 <@Skyler_> so simply %defining parameters like the code does can't work
2013-10-01 11:39:44 < nightfox> its the horizontal filter patch for 32 bit that you reviewed
2013-10-01 11:40:01 < nightfox> we want to reuse the same code for 64 bit
2013-10-01 11:40:01 <@Skyler_> that's one of the reasons I recommended against that; it won't work on 64-bit, because %define doesn't propagate suffixes
2013-10-01 11:41:00 <@Skyler_> okay, let me try
2013-10-01 11:41:20 < nightfox> does x86 named parameters propagate suffixes?
2013-10-01 11:41:58 <@Skyler_> yes, let me see if I can find a good example
2013-10-01 11:42:48 <@Skyler_> random code grabbed from libav
2013-10-01 11:42:50 <@Skyler_> cglobal ac3_exponent_min, 3, 4, 2, exp, reuse_blks, expn, offset shl  reuse_blksq, 8 jz .end LOOP_ALIGN
2013-10-01 11:42:53 <@Skyler_> .nextexp: mov      offsetq, reuse_blksq
2013-10-01 11:43:11 <@Skyler_> cglobal ac3_exponent_min, 3, 4, 2, exp, reuse_blks, expn, offset shl  reuse_blksq, 8 jz .end LOOP_ALIGN
2013-10-01 11:43:15 <@Skyler_> .nextexp: mov      offsetq, reuse_blksq
2013-10-01 11:43:17 <@Skyler_> gah, it won't add the line breaks -_-  I'll pastebin it
2013-10-01 11:43:31 <@Skyler_> http://pastebin.com/PN87Z7sC
2013-10-01 11:43:39 <@Skyler_> notice for example "offsetq"
2013-10-01 11:44:07 <@Skyler_> "offsetd" would be the 32-bit version of offset, "offsetq" would be the full-size version, "offsetw" would be the 16-bit version, etc
2013-10-01 11:46:43 < nightfox> ok
2013-10-01 11:58:06 <@Skyler_> http://pastebin.com/xrUnWzj2  okay, does this work?  or something like this
2013-10-01 12:00:04 <@Skyler_> hmm mI guess that is slightly wrong.
2013-10-01 12:00:36  * Skyler_ tries to understand all of this code...
2013-10-01 12:01:20 < nightfox> thanks
2013-10-01 12:04:41 <@Skyler_> http://pastebin.com/eM2VggEK
2013-10-01 12:04:48 <@Skyler_> okay this is a simpler version that just writes over the edge
2013-10-01 12:05:04 <@Skyler_> erm, http://pastebin.com/3WZDRd6G
2013-10-01 12:05:14 <@Skyler_> basically the idea:
2013-10-01 12:05:21 <@Skyler_> lines 13-16: do the coef thing
2013-10-01 12:05:50 <@Skyler_> 21-22: round our width up, effectively (so if our width is 12 we have to do 8 pixels at 8-15, and 8 pixels at 0-7
2013-10-01 12:05:54 <@Skyler_> )
2013-10-01 12:06:10 <@Skyler_> 26-31: inner loop, just goes 24, 16, 8, 0... then is done
2013-10-01 12:06:27 <@Skyler_> http://pastebin.com/U05EQipz    wow I am bad this morning with obvious typos
2013-10-01 12:06:39 <@Skyler_> and then just the outer loop.
2013-10-01 12:07:24 <@Skyler_> yes, register allocation gets complicated if you start needing a ton of registers, unfortunately
2013-10-01 12:19:41 < Nabajit> @Skyler : In case we need a couple of more registers than being provided by the system, what is the best way to go ahead in that?
2013-10-01 12:23:58 <@Skyler_> there's a few possibilities
2013-10-01 12:24:31 <@Skyler_> you can allocate stack space and use that, especially for variables which aren't used much
2013-10-01 12:24:46 <@Skyler_> if you have parameters beyond the first 6, you can leave those on the stack, since even on linux64 they'll still be on the stack
2013-10-01 12:25:15 <@Skyler_> I'd say it's preeettty rare that I ever needed more than 4-6ish registers.
2013-10-01 12:25:49 <@Skyler_> maybe you can start with the simpler functions that need fewer, and if something needs way too many registers, leave the intrinsic version for now and let the compiler handle it?
2013-10-01 12:30:02 <@Skyler_> I guess the only function I could think of that used an absurd number of GPRs is trellis?
2013-10-01 12:36:29 < nightfox> while compiling the code I got error: undefined symbol `src' (first use) error: undefined symbol `col' (first use)
2013-10-01 12:36:39 < nightfox> for 64 bit
2013-10-01 12:37:47 < nightfox> it is http://pastebin.com/xrUnWzj2
2013-10-01 12:47:18 < nightfox> same problem in http://pastebin.com/eM2VggEK
2013-10-01 12:47:46 < nightfox> I think we are missing col
2013-10-01 12:49:14 <@Skyler_> ohhh, that's because col is used in the filter macro.
2013-10-01 12:49:23 <@Skyler_> you'll have to replace "col" with r6.
2013-10-01 12:49:28 <@Skyler_> and "src" with "srcq"
2013-10-01 12:49:36 <@Skyler_> sorry, I missed that.
2013-10-01 12:51:00 < nightfox> ok...
2013-10-01 12:53:47 < nightfox> what is error: invalid size for operand 1 in instruction  dec     heightm
2013-10-01 13:01:46 < nightfox> we do need to replace it with dec     heightq
2013-10-01 13:01:48 < nightfox> ?
2013-10-01 13:23:20 <@Skyler_> nightfox: oh, I see
2013-10-01 13:23:44 <@Skyler_> um, "dec heightd" should work okay?
2013-10-01 13:23:58 <@Skyler_> which heightm are you talking about?  http://pastebin.com/U05EQipz  has no heightm
2013-10-01 13:24:13 < nightfox>     add        srcq, srcstrideq
2013-10-01 13:24:13 < nightfox>     add        dstq, dststrideq
2013-10-01 13:24:13 < nightfox>     dec        heightm
2013-10-01 13:24:18 <@Skyler_> +    add        srcq, srcstrideq
2013-10-01 13:24:18 <@Skyler_> +    add        dstq, dststrideq
2013-10-01 13:24:18 <@Skyler_> +    dec     heightd
2013-10-01 13:24:23 < nightfox> yes
2013-10-01 13:24:26 < nightfox> same
2013-10-01 13:25:07 < nightfox> oh sorry
2013-10-01 13:25:23 < nightfox> http://pastebin.com/xrUnWzj2
2013-10-01 13:25:37 < nightfox> i got it
2013-10-01 13:27:10 < nightfox> error LNK2017: 'ADDR32' relocation to 'tab_leftmask' invalid without /LARGEADDRESSAWARE:NO ?
2013-10-01 13:27:25 < nightfox> what is this linker error?
2013-10-01 13:31:37 <@Skyler_> okay, that's because of position-independent code
2013-10-01 13:31:46 <@Skyler_> if you want to support position-independent code, you cannot have references that look like
2013-10-01 13:31:52 <@Skyler_> [some_global_constant + register]
2013-10-01 13:32:09 <@Skyler_> because with PIC on, they get converted to [some_global_constant wrt rip]
2013-10-01 13:32:16 <@Skyler_> which doesn't allow offsets
2013-10-01 13:32:24 <@Skyler_> so for example
2013-10-01 13:32:51 <@Skyler_> %ifdef PIC
2013-10-01 13:33:32 <@Skyler_> lea tmp, [some_global_constant]
2013-10-01 13:33:35 <@Skyler_> add tmp, register
2013-10-01 13:33:50 <@Skyler_> mov tmp, [tmp]
2013-10-01 13:33:51 <@Skyler_> %else
2013-10-01 13:33:58 <@Skyler_> mov tmp, [some_global_constant+register]
2013-10-01 13:33:59 <@Skyler_> %endif
2013-10-01 13:34:26 <@Skyler_> x264 doesn't support PIC on 32-bit, which is probably why you didn't run into this before
2013-10-01 13:34:34 <@Skyler_> (PIC on 32-bit is 1000 times more of a hassle and generally not necessary)
2013-10-01 13:35:37 <@Skyler_> if you need to do this a lot in a single function there's some tricks to speed it up, but it looks like just one place here.
2013-10-01 13:37:48 < nightfox> so what i need to do to fix it?
2013-10-01 13:38:06 < nightfox> do i need tmps?
2013-10-01 13:55:10 < Daemon404> Skyler_, wouldnt that mean x264 can be a 32-bit shared lib?
2013-10-01 13:55:15 < Daemon404> er cant
2013-10-01 13:57:09 <@Skyler_> shared libs on 32-bit do not require PIC
2013-10-01 13:57:14 <@Skyler_> nightfox: you need to add an ifdef
2013-10-01 13:57:31 <@Skyler_> I don't think you need more registers for this case.
2013-10-01 13:58:02 < nightfox> ok
2013-10-01 13:58:08 < nightfox> do u mean like
2013-10-01 13:58:09 < nightfox>     %ifdef PIC
2013-10-01 13:58:10 < nightfox>     lea tmp, [tab_leftmask]
2013-10-01 13:58:10 < nightfox>     add tmp, register
2013-10-01 13:58:10 < nightfox>     mov tmp, [tmp]
2013-10-01 13:58:10 < nightfox>     %else
2013-10-01 13:58:10 < nightfox>     mov tmp, [tab_leftmask + register]
2013-10-01 13:58:12 < nightfox>     %endif
2013-10-01 15:14:48 < Daemon404> [x265] [PATCH] Replace sad_12, sad_24, sad_32 vector class functions with intrinsics
2013-10-01 15:14:51 < Daemon404> :(
2013-10-01 15:15:46 <@Skyler_> nightfox: yes... I mean like the thing I just gave an example of
2013-10-01 15:25:25 < nightfox> how we will manage tmp? do we need extra register for it?
2013-10-01 15:32:37 < nightfox>  I have done
2013-10-01 15:32:39 < nightfox> %define tmp         r0
2013-10-01 15:32:51 < nightfox>     %ifdef PIC
2013-10-01 15:32:52 < nightfox>     lea tmp, [tab_leftmask]
2013-10-01 15:32:52 < nightfox>     add  r6,   7
2013-10-01 15:32:52 < nightfox>     add tmp,  r6
2013-10-01 15:32:52 < nightfox>     mov tmp, [tmp]
2013-10-01 15:32:52 < nightfox>     %else
2013-10-01 15:32:54 < nightfox>     mov tmp, [tab_leftmask + (7 + r6)]
2013-10-01 15:32:56 < nightfox>     %endif
2013-10-01 15:33:06 < nightfox> but seems some problem
2013-10-01 15:34:12 < nightfox> its building but crasing while runing
2013-10-01 15:47:37 < nightfox> is  %define tmp         r0 gain problem?
2013-10-01 18:39:36 < j-b> Hello trollz
2013-10-01 18:40:17 < Daemon404> hello benevolent leader
2013-10-01 18:50:32 <@muggs> all hail  :)
2013-10-01 18:56:45 < pengvado> Skyler_, nightfox: that asm has some unnecessary adds. you can use adds in an address, just not in the same instruction as a pic global address.
2013-10-01 19:10:29 <@muggs> hello pengvado
2013-10-01 20:09:47 < Daemon404> muggs, fyi when i tested x265 it roughly tied x264, while havign much lower peaks in some areas
2013-10-01 20:11:10 < Daemon404> in terms of ssim
2013-10-01 20:23:52 < muggs> interesting; since we're not tuning for ssim at all yet
2013-10-01 20:31:43 < Daemon404> wont tuning just for PSNR heavil favor blurring
2013-10-01 20:32:12 < muggs> yep
2013-10-01 20:32:32 < Daemon404> also i need to re-run it, since i had x265 on default (which took 16.5 hrs!)
2013-10-01 20:32:53 < muggs> awesome
2013-10-01 20:33:10 < Daemon404> http://chromashift.org/img/x265/comparison_abr_27sep2013.png
2013-10-01 20:33:15 < Daemon404> that was the yield last time
2013-10-01 20:34:04 < Daemon404> http://chromashift.org/img/x265/comparison_abr_29sep2013.png <-- width divx hevc overlayed here
2013-10-01 20:34:13 < Daemon404> although it makes it unreadable more or less
2013-10-01 20:35:12 < muggs> the peaks are blank frames?
2013-10-01 20:35:25 < Daemon404> 1.0 ssim
2013-10-01 20:35:29 < Daemon404> so yeah
2013-10-01 20:35:32 < Daemon404> pure black probably
2013-10-01 20:36:51 < muggs> I've heard the DIVX HEVC encoder is essentially MainConcept
2013-10-01 20:37:09 < Daemon404> it is; they use the MC api
2013-10-01 20:37:16 < Daemon404> but in a very limited way
2013-10-01 20:37:20 < Daemon404> gimped, so to speak
2013-10-01 20:37:30 < Daemon404> i had to encode 4 times to attain 3000 kbit/s
2013-10-01 20:37:34 < Daemon404> due to their terrible ratecontrol
2013-10-01 20:37:50 < JEEB> yeah, it's really overtrying to not go over the set bit rate
2013-10-01 20:38:25 < Daemon404> requestion 3900 to get 3000 is a pretty dan big undershoot
2013-10-01 20:38:29 < Daemon404> requesting*
2013-10-01 20:38:43 < JEEB> yup
2013-10-01 20:40:25 < Daemon404> i would try touhou, but that would be unfair to !x264
2013-10-01 20:40:54 < Mandarinka> divx: "it compresses so well, I told it to use 4000 and it only needed 3000! Such a great encoder!!1"
2013-10-01 20:41:20 < muggs> see my recent ML response; x265's equiv to x264 placebo would enable --refs 16, --b-adapt 2 --rc-lookahead 60
2013-10-01 20:41:31 < Daemon404> muggs, nothing else?
2013-10-01 20:41:42 < muggs> and weightp is not yet functional; which matters a lot in elephant dream
2013-10-01 20:41:43 < Daemon404> i will rerun whilst i sleep tonight
2013-10-01 20:41:47 < Daemon404> ah
2013-10-01 20:42:11 < muggs> --me 5 if you have all day to run it :)
2013-10-01 20:42:18 < Daemon404> ;)
2013-10-01 20:42:35 < Daemon404> i noticed x265 has trouble utilizing more than 4-6 cores currently
2013-10-01 20:42:43 < Daemon404> re: speed
2013-10-01 20:43:19 < muggs> with 64x64 blocks, you can't get sufficient frame parallelism until you get ~3 B frames between each P
2013-10-01 20:43:34 < muggs> https://bitbucket.org/multicoreware/x265/wiki/Performance
2013-10-01 20:44:28 < muggs> --b-adapt 1 won't generally give you enough Bs
2013-10-01 20:45:00 < Daemon404> i dont recall there being a way to set the maximum bframe run length
2013-10-01 20:45:05 < Daemon404> is this forthcoming?
2013-10-01 20:45:19 < muggs> --b-adapt 2 --bframes N - works now
2013-10-01 20:45:24 < Daemon404> right
2013-10-01 20:45:48 < muggs> so does --b-adapt 0 --bframes N, it forces PBBBPBBBP for -b3
2013-10-01 20:45:57 < Daemon404> refs should ake a big diff on elephant's dream too
2013-10-01 20:46:02 < Daemon404> it loos like, anywya
2013-10-01 20:46:04 < Daemon404> looks*
2013-10-01 20:46:18 < muggs> that's enabled on default tip now
2013-10-01 20:46:26 < Daemon404> right.
2013-10-01 20:46:34 < Daemon404> well i have a train to catch tomorow night
2013-10-01 20:46:39 < Daemon404> so ill ste off a run before i hop on it
2013-10-01 20:46:48 < muggs> lots of time AFK ;)
2013-10-01 20:46:55 < Daemon404> aye
2013-10-01 20:47:07 < Daemon404> i find i peek too much at it if im awake or around
2013-10-01 20:47:13 < Daemon404> a watched pot never boils, etc
2013-10-01 20:49:14 < Mandarinka> hehe, yes.
--- Day changed Wed Oct 02 2013
2013-10-02 13:16:50 < Daemon404> j-b, which is the canonical url for x265's hg
2013-10-02 13:16:54 < Daemon404> v.o or bitbucket
2013-10-02 13:19:07 < j-b> As far as I am concerned, v.o
2013-10-02 13:19:25 < Daemon404> ok.
2013-10-02 13:19:37 < Daemon404> slight issue then
2013-10-02 13:19:38 < Daemon404> http://hg.videolan.org/x265/
2013-10-02 13:19:43 < Daemon404> i cannot find how to clone it
2013-10-02 13:19:49 < Daemon404> it doesnt say anywhere
2013-10-02 13:19:55 < j-b> lol
2013-10-02 13:19:59 < j-b> thresh: ping :)
2013-10-02 13:20:33 < Daemon404> lovely... http://hg.videolan.org/x265/ works
2013-10-02 13:20:34 < Daemon404> evil
2013-10-02 13:20:46 < thresh> fuck do I know :)
2013-10-02 13:20:59 < thresh> not sure how to put that in hgweb
2013-10-02 13:21:10 < Daemon404> :
2013-10-02 13:21:10 < Daemon404> :D
2013-10-02 13:21:19 < j-b> hgweb is really bad
2013-10-02 13:21:21 < Daemon404> btw cloning is *slow*
2013-10-02 13:21:25 < Daemon404> compared to bitbucket
2013-10-02 13:21:29 < Daemon404> orders of magnitude slower
2013-10-02 13:22:44 < Daemon404> thresh, complaint 2: no ssl
2013-10-02 13:22:48 < Daemon404> y u no ssl
2013-10-02 13:22:59 < thresh> what for
2013-10-02 13:23:14 < Daemon404> seems to be pretty bog standard for VCS pushes.
2013-10-02 13:23:23 < thresh> you push to ssh
2013-10-02 13:23:36 < Daemon404> well all right
2013-10-02 13:23:41 < Daemon404> still cloning.
2013-10-02 13:24:18 < Daemon404> time: 4 mins
2013-10-02 13:25:09 < thresh> where are you geographically?
2013-10-02 13:25:18 < j-b> mighty USA
2013-10-02 13:25:19 < thresh> cloned in a few seconds for me
2013-10-02 13:26:06 < thresh> hg clone http://hg.videolan.org/x265/  5.17s user 0.48s system 38% cpu 14.637 total
2013-10-02 13:26:32 < Daemon404> i am in UK
2013-10-02 13:26:35 < Daemon404> server im on is in NYC
2013-10-02 13:26:58 < j-b> hg clone http://hg.videolan.org/x265/  5,15s user 0,25s system 62% cpu 8,623 total
2013-10-02 13:27:13 < Daemon404> heh
2013-10-02 13:27:14 < Daemon404> anyway
2013-10-02 13:27:15 < Daemon404> https://www.ohloh.net/p/x265
2013-10-02 13:27:22 < thresh> it's indeed slow from San Diego
2013-10-02 13:27:31 < thresh> and I don't think we can do anything about it
2013-10-02 13:28:20 < thresh> except providing a r/o mirror maybe
2013-10-02 13:28:39 < Daemon404> thresh, why does v.o git work so well then?
2013-10-02 13:28:41 < Daemon404> diff ISP?
2013-10-02 13:29:11 < thresh> no, it's the same machine actually
2013-10-02 13:29:18 < Daemon404> ... that is weird
2013-10-02 13:29:27 < Daemon404> i get several mbyte/s from git
2013-10-02 13:29:39 < thresh> with git:// ?
2013-10-02 13:29:44 < Daemon404> yeah
2013-10-02 13:29:50 < thresh> can you try dumb transport?
2013-10-02 13:29:51 < thresh> like http
2013-10-02 13:29:55 < Daemon404> sure
2013-10-02 13:30:49 < Daemon404> woah wut
2013-10-02 13:30:54 < Daemon404> it goes 50 kbit/s
2013-10-02 13:30:58 < Daemon404> er kbyte
2013-10-02 13:31:02 < Daemon404> from git://
2013-10-02 13:31:07 < Daemon404> this never used to be the case
2013-10-02 13:31:25 < Daemon404> i used to clone from v.o for yearss
2013-10-02 13:31:25 < thresh> well
2013-10-02 13:31:36 < thresh> looks like NSA also shut itself down
2013-10-02 13:31:39 < Daemon404> 30 kbyte/s
2013-10-02 13:31:42 < Daemon404> dismal.
2013-10-02 13:31:42 < thresh> so every connection from US gets lagged
2013-10-02 13:31:42 < thresh> :)
2013-10-02 13:31:46 < Daemon404> heh
2013-10-02 13:31:52 < Daemon404> did you not switch isps or something?
2013-10-02 13:32:07 < thresh> we did not
2013-10-02 13:32:13 < thresh> but we cant say for routing in between us
2013-10-02 13:32:27 < Daemon404> indeed...
2013-10-02 13:41:04 < j-b> we need a CDN?
2013-10-02 13:41:52 < Daemon404> you could just ask the isp
2013-10-02 13:41:54 < Daemon404> ?
2013-10-02 13:42:02 < Daemon404> 30 kbyte/s is pretty dismal routing
2013-10-02 13:43:07 < ILEoo> Daemon404: did you check traceroute for example on your side?
2013-10-02 13:43:31 < ILEoo> maybe your isp is selling your ip packets to russians ;)
2013-10-02 13:45:09 < Daemon404> tracing
2013-10-02 13:45:16 < thresh> from my side, looks like cogent routing is fucked up
2013-10-02 13:45:47 < Daemon404> same
2013-10-02 13:49:42 < j-b> cogent
2013-10-02 13:49:43 < j-b> LOL
2013-10-02 13:52:51 < kierank> lol  cogent
2013-10-02 13:52:57 < kierank> my file at free was downloading from cogent
2013-10-02 13:53:00 < kierank> slooooow
2013-10-02 15:40:11 < Daemon404> http://pastie.org/pastes/8372433/text?key=5knqbptbavlsyqu1ohxca
2013-10-02 15:44:24 < j-b> time?
2013-10-02 15:49:33 < Daemon404> j-b, ?
2013-10-02 15:49:39 < Daemon404> 'time'?
2013-10-02 15:50:26 < koda> a few hours
2013-10-02 15:51:00 < Daemon404> http://lists.libav.org/pipermail/libav-devel/2013-October/051599.html
2013-10-02 15:51:02 < Daemon404> in any case.
2013-10-02 15:58:20 < j-b> Daemon404: U rock
--- Day changed Thu Oct 03 2013
2013-10-03 03:24:15  * muggs hacks on shared library support
2013-10-03 06:56:00 < Praveen__> I have replaced mov tmp, [tab_leftmask + (7 + r6)]
2013-10-03 06:56:03 < Praveen__> with
2013-10-03 06:56:17 < Praveen__> %define tmp         r7
2013-10-03 06:56:28 < Praveen__>     %ifdef PIC
2013-10-03 06:56:28 < Praveen__>     lea tmp, [tab_leftmask]
2013-10-03 06:56:28 < Praveen__>     add tmp,  r6
2013-10-03 06:56:28 < Praveen__>     mov tmp, [tmp]
2013-10-03 06:56:28 < Praveen__>     %else
2013-10-03 06:56:29 < Praveen__>     mov tmp, [tab_leftmask + (7 + r6)]
2013-10-03 06:56:31 < Praveen__>     %endif
2013-10-03 06:56:39 < Praveen__> but my code is crashing
2013-10-03 06:57:55 < Praveen__> is it due to %define?
2013-10-03 07:24:28 < Praveen__> I just tried to fixed error LNK2017: 'ADDR32' relocation to 'tab_leftmask' invalid without /LARGEADDRESSAWARE:NO
2013-10-03 07:24:31 < Praveen__> of code
2013-10-03 07:24:47 < Praveen__> http://pastebin.com/xrUnWzj2
2013-10-03 08:45:08 < nightfox> @SKyler Itried to build and run the code http://pastebin.com/eM2VggEK but it also crashing
2013-10-03 11:05:47 <@Skyler_> nightfox: well, yes, the code is not necessarily right
2013-10-03 11:05:57 <@Skyler_> you have to debug it if it's crashing, find the mistake, and fix it
2013-10-03 11:07:10 <@Skyler_> this is what writing asm is about
2013-10-03 11:07:18 <@Skyler_> if you do something, and it doesn't work, you need to debug it and figure out what's wrong
2013-10-03 11:08:12 <@Skyler_> praveen: that code isn't even the same as the original; the original code loads leftmask into m0, not "tmp".
2013-10-03 11:08:20 <@Skyler_> and it uses movq, not "mov"
2013-10-03 11:08:42 <@Skyler_> and you can't use r7 on 32-bit
2013-10-03 11:09:11 <@Skyler_> please *think* about code before you paste it in, that code is very obviously not doing an identical thing
2013-10-03 11:09:43 <@Skyler_> I posted that code as an example of how to use PIC, not lines to just copy and paste into your program.
2013-10-03 11:10:03 <@Skyler_> please do not copy and paste any of the code I write, /write it yourself/
2013-10-03 11:10:23 <@Skyler_> understand, learn, and do it yourself -- I can't do it for you or you won't learn anything.
2013-10-03 11:16:02 < nightfox> we made changes to the code...and its working in Debug mode..
2013-10-03 11:16:24 < nightfox> but its not running in Release mode
2013-10-03 11:16:42 <@Skyler_> then you need to debug it and see where it's crashing
2013-10-03 11:16:55 <@Skyler_> maybe your function is clobbering one of its input registers?  if you have unit tests, your unit test should check for that.
2013-10-03 11:16:58 < nightfox> no no its not crashing
2013-10-03 11:17:03 <@Skyler_> ?
2013-10-03 11:17:11 <@Skyler_> what does "not working" mean then?
2013-10-03 11:17:44 < nightfox> its failing output is not matching
2013-10-03 11:17:52 < nightfox> we are look for that
2013-10-03 11:18:04 <@Skyler_> I'd say "clobbering a register" is pretty likely, that's the first thing I can think of
2013-10-03 11:18:31 <@Skyler_> another is maybe somehow messing up the stack (?)
2013-10-03 11:18:36 < nightfox> yes, seems so..
2013-10-03 11:19:50 <@Skyler_> if you have the code somewhere I could try looking at it?
2013-10-03 11:20:28 < nightfox> sure
2013-10-03 11:21:44 < Nabajit> http://pastebin.com/UhGAiHBt
2013-10-03 11:25:00 <@Skyler_> "mov r6, r6m" doesn't make much sense; the function uses "7" as its number of arguments to auto-load into registers
2013-10-03 11:25:08 <@Skyler_> so "mov r6, r6m" is already being done as part of the prologue
2013-10-03 11:25:56 < Nabajit> ok
2013-10-03 11:26:13 <@Skyler_> there might also be an issue related to the fact that this one writes over the edge and the old one doesn't?
2013-10-03 11:26:33 <@Skyler_> I don't know if that would cause problems if the code around it doesn't expect it
2013-10-03 11:26:59 <@Skyler_> the function uses more than 7 registers, so it won't work on x86.
2013-10-03 11:29:01 < Nabajit> any suggestion to make it work in x86 also
2013-10-03 11:29:40 <@Skyler_> ... use fewer registers?
2013-10-03 11:30:39 <@Skyler_> I'm sorry, but maybe you'd be better off using intrinsics...
2013-10-03 11:32:26  * Skyler_ goes back to sleep maybe
2013-10-03 12:16:52 < koda> This is the effort to get rid of the GPL vector class headers   We're
2013-10-03 12:16:53 < koda> replacing primitives that use those classes with intrinsics because the GPL
2013-10-03 12:16:53 < koda> headers have to be gone by November  [...]
2013-10-03 12:17:00 < koda> ^ why?
2013-10-03 12:18:11 < JEEB> it seems that at some point they took some GPL-only code in
2013-10-03 12:18:17 < JEEB> and they are trying to remove it
2013-10-03 12:18:43 < koda> :O i wasn't awake x264 had gpl only parts
2013-10-03 12:18:47 < koda> aware*
2013-10-03 12:18:55 < JEEB> I'm pretty sure it wasn't from x264
2013-10-03 12:18:56 < koda> but why by november?
2013-10-03 12:19:00 < JEEB> although that has those, too
2013-10-03 12:19:04 < JEEB> probably internal reasons :P
2013-10-03 12:19:42 < JEEB> I think most of libx264 and x264 is dual, and then some of the x264cli stuff and such is GPL-only
2013-10-03 12:22:15 < koda> i c
2013-10-03 12:52:56 < Daemon404> i want to reply to that email
2013-10-03 12:53:05 < Daemon404> but there is no way i can without being an asshole
2013-10-03 13:24:01 < koda> Daemon404, just add lots of 'in my personal/humble opition' and you're set
2013-10-03 13:26:18 < Daemon404> lol
2013-10-03 13:39:10 < j-b> seriously, is that that hard to do .asm files instead of writing new intrinsincs?
2013-10-03 14:48:34 < Daemon404> j-b, intrinsics are faster because they dont get reviewed.
2013-10-03 14:48:44 < Daemon404> as oppose to Skyler_'s asm review
2013-10-03 14:49:40 < Daemon404> i also love the arbitrary november date
2013-10-03 14:51:01 < Daemon404> oh holy sad intrinsics spam...
2013-10-03 14:51:49 < Daemon404> there's no way that isn't just copy/pasted bullshit.
2013-10-03 15:10:07 < Daemon404> also
2013-10-03 15:10:16 < Daemon404> arent these intrinsics possibly going to be super crappy
2013-10-03 15:10:19 < Daemon404> due to register allocation
2013-10-03 20:44:18 < davety> Hi all, I am not having much luck in finding any documentation on the intrinsics used in x265.  The closest I can find is either simd assembler or seemingly unrelated intrinsics from microsoft or gcc.  Does anyone have a good reference on the web?
2013-10-03 21:09:34 < davety> never mind I think I found it.
--- Day changed Fri Oct 04 2013
2013-10-04 20:46:18 < davety> ok, I have just processed a yuv file with x265, is there anything I can use to play the output to test it?
2013-10-04 20:48:10 < JEEB> mpv with the HEVC-enabled libav for example
2013-10-04 20:48:16 < JEEB> or build ffms2 with it
2013-10-04 20:49:22 < JEEB> since the multithreading over at elenril's repo seems to have borked something, I guess you could use this repo https://github.com/VFR-maniac/libav/commits/hevc_nalff
2013-10-04 20:50:23 < JEEB> that VFR Maniac's branch also can handle L-SMASH/mp4box muxed HEVC
2013-10-04 20:51:36 < JEEB> http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream <- this is the elenril's repo that is the one that's being reviewed/fuzzed at the moment (the frame mt thing seems to bork some things)
2013-10-04 20:52:34 < JEEB> can't wait for the libavcodec decoder to be finished in review :)
2013-10-04 20:53:11 < koda> what things were borked?
2013-10-04 20:54:16 < davety> thanks JEEB, I will try it
2013-10-04 20:54:19 < JEEB> <Ohimesamaniac> lc->edge_emu_bufferをav_mallocするところでnull dereferenceする ("there is a null dereference around the place where lc->edge_emu_buffer gets av_malloc'd")
2013-10-04 20:54:46 <@muggs> for the patience impaired, you can use -r recon.y4m with x265, then you can play back the recon video in VLC
2013-10-04 20:55:19 < JEEB> also it seems like it's not borked in avconv, but all frames except for the first one are completely bonkers
2013-10-04 20:55:29 < JEEB> I haven't built it myself yet so I can't confirm
2013-10-04 20:56:21 < koda> so it's just hevc still image profile
2013-10-04 20:57:30 < JEEB> he says it's borked with http://x264.fushizen.eu/samples/hevc/railgun_s_op_bd_HM10.1_randomaccess_qp30.hevc for example, which I'm pretty sure is not still image
2013-10-04 20:57:49 < JEEB> otherwise the decoder is mighty gut tho :3 decodes everything I throw at it
2013-10-04 20:58:04 < JEEB> (except divx's stuff, which I think no-one is surprised is giving out nonstandard output)
2013-10-04 20:58:37 < koda> and noone is going to use
2013-10-04 20:58:39 < koda> right?
2013-10-04 20:59:04 < JEEB> I hope at least, the amount it is off with its rate control is phenominal
2013-10-04 20:59:24 < JEEB> "yeah this thing seems to kind of get faster so let's use QP over 40 for the next GOP and a half"
2013-10-04 20:59:36 < JEEB> s/faster/complex/
2013-10-04 21:00:26  * koda is glad QP unit measure is not in thousands or the risk of someone proposing "QP over 9000" would be quite probable
2013-10-04 21:04:26 < Mandarink> <davety> ok, I have just processed a yuv file with x265, is there anything I can use to play the output to test it? --- IIRC there is a dump yuv option... if you use that and encode the dump losslessly with x264, you could watch it easily I'd say
2013-10-04 21:05:20 < Mandarink> oh, nvm, already pointed out
2013-10-04 21:06:09 < davety> muggs, is reconstruction simply decoded video output to a file or video that is reconstructed from some intermediate video data?
2013-10-04 21:06:42 <@muggs> it's the output pictures that a decoder would generate
2013-10-04 21:07:24 <@muggs> in raw YUV format; so the file will be huge
2013-10-04 21:08:05 < davety> it created output exactly the same size as the source yuv that I tested with
2013-10-04 21:09:27 < thresh> muggs: you should have received the mail from the x265-commits-bounces @ videolan, can you forward it (with headers) to me? $nick at videolan.org
2013-10-04 21:17:23 <@muggs> davety: yeah, that is correct.  decompressed raw video is the same size as the pre-compressed raw video
2013-10-04 21:18:13 <@muggs> thresh: on the way
2013-10-04 21:19:13 <@muggs> so I need to subscribe to x265-commits, or can you white-list me?
2013-10-04 21:19:39 < kierank> what kind of documentation do you want
2013-10-04 21:19:52 < kierank> davety:
2013-10-04 21:20:03 < kierank> oh never mind
2013-10-04 21:21:54 < thresh> muggs: none of the above, hg is supposed to use hg@v.o to send mails there
2013-10-04 21:22:08 <@muggs> I see
2013-10-04 21:22:15 < thresh> it should do that now, actually
2013-10-04 22:24:47 < smarter_> JEEB: mraulet told me openhevc/libav should be able to decode divx stuff
2013-10-04 22:24:56 < smarter_> needs to be merged with elenril branch
--- Day changed Sat Oct 05 2013
2013-10-05 16:38:23 < Daemon404> muggs_, i will try the shared lib support now
2013-10-05 16:57:36 < Daemon404> thresh, Receiving objects: 100% (412343/412343), 215.58 MiB | 3.51 MiB/s, done.
2013-10-05 16:57:45 < Daemon404> suddenly vlc's git is fast
2013-10-05 16:57:47 < Daemon404> to america
2013-10-05 16:57:58 < Daemon404> cogent must have unscrewed itself
2013-10-05 20:33:00 < thresh> Daemon404: unpossible
2013-10-05 22:01:55 < JEEB> saying it here, too
2013-10-05 22:01:58 < JEEB> doom9 is compromised
2013-10-05 22:02:31 < JEEB> disabling JS seems "OK" for now, but there is no way of knowing if they got access to an admin as well, and not only a moderator
2013-10-05 22:03:50 < JEEB> if you had opened a (sub)forum and it took a while and had an announcement, and you had JS enabled, you can be relatively sure that your username/password combo got sent out to a 3rd party server
--- Day changed Sun Oct 06 2013
--- Day changed Mon Oct 07 2013
2013-10-07 15:07:32 < gdos> just exactly whats the difference between the x264 and x265 codecs?
2013-10-07 15:08:51 < |some1|> first of all name is different
2013-10-07 15:10:05 < gdos> aren't they both encoders?
2013-10-07 15:10:27 < Daemon404> one is for h264
2013-10-07 15:10:29 < Daemon404> one is for h265
2013-10-07 16:24:39 < win32vb> gdos: Yes, they are both encoders.  H.264 (AVC) and H.265 (HEVC) respectively.  H.265 is a new codec that should be able to compress video smaller than H.264 while maintaining the same visual playback quality.
2013-10-07 16:25:48 < gdos> thanks. somehow that same question started a troll war in the #x264dev channel. you answered my question perfectly.
2013-10-07 17:30:29 < rumy> where can I get hevc decoder 11.0 for linux?
2013-10-07 17:31:02 < rumy> or source alternatively?
2013-10-07 17:31:38 < JEEB> you mean HM?
2013-10-07 17:31:46 < JEEB> http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git
2013-10-07 17:32:07 < rumy> yes the latest decoder version? perhaps HM 11
2013-10-07 17:33:17 < JEEB> 12 is the currently newest "release", and then there's further commits in the 12-dev branch
2013-10-07 17:36:40 < rumy> thanks a lot JEEB
2013-10-07 20:13:45 < muggs_> Daemon404: ping
2013-10-07 20:13:54 < Daemon404> hi.
2013-10-07 20:21:41 < muggs_> What API changes did you have in mind?
2013-10-07 20:22:50 < Daemon404> currently the api lacks a few thinks
2013-10-07 20:22:51 < Daemon404> like PTS
2013-10-07 20:22:57 < Daemon404> and also importantly for Libav
2013-10-07 20:23:17 < Daemon404> something like x264_param_parse
2013-10-07 20:23:23 < Daemon404> so it doesnt have to clone your options table
2013-10-07 20:23:51 < muggs_> does it need VFR? or just a PTS that goes in and comes out with the same picture?
2013-10-07 20:24:07 < Daemon404> you either need to add pts for future vfr
2013-10-07 20:24:11 < Daemon404> or version the api
2013-10-07 20:24:16 < Daemon404> actually, always version the api
2013-10-07 20:25:00 < Daemon404> it also lags encoder_reconfigure
2013-10-07 20:25:03 < Daemon404> lacks*
2013-10-07 20:25:39 < muggs_> does libav use reconfigure?
2013-10-07 20:25:44 < Daemon404> for x264 it does
2013-10-07 20:25:50 < Daemon404> for midstream sar or res changes
2013-10-07 20:25:53 < Daemon404> and such
2013-10-07 20:26:14 < muggs_> hmm, wow ok.
2013-10-07 20:26:47 < Daemon404> #1 imho right now is x264_param_parse-alike and versioning
2013-10-07 20:26:57 < muggs_> a passthrough PTS is just a few lines of code
2013-10-07 20:27:20 < Daemon404> right now im kind of making up the fraerate to give to x265's api
2013-10-07 20:27:22 < Daemon404> via the timebase
2013-10-07 20:27:27 < Daemon404> which obviously isnt correct(tm)
2013-10-07 20:28:10 < Daemon404> maybe peek at libx264.c in libav
2013-10-07 20:28:40 < muggs_> API versioning is fairly simple, the parse function is tedious but not difficult
2013-10-07 20:29:02 < Daemon404> id rather not clone your option table
2013-10-07 20:29:07 < Daemon404> it's also not version-independent
2013-10-07 20:29:11 < Daemon404> kind of messy
2013-10-07 20:29:22 < muggs_> sure
2013-10-07 20:31:41 < muggs_> making a list so we can track this; I think I'll add a section to the TODO page with these items
2013-10-07 20:34:02 < muggs_> https://bitbucket.org/multicoreware/x265/wiki/TODO  did I miss anything?
2013-10-07 20:34:33 < Daemon404> im half asleep
2013-10-07 20:34:35 < Daemon404> so i probably did.
2013-10-07 20:35:10 < muggs_> heh; feel free to add items later
--- Day changed Tue Oct 08 2013
2013-10-08 21:35:36  * muggs_ contemplates autoconf for *nix targets
2013-10-08 21:40:55  * koda keeps fangirls quiet
2013-10-08 21:43:10 < muggs_> lol. that assembly PIC issue is driving me nuts
2013-10-08 21:54:48 < BugMaster> at first I thought it may be something connected to elf and hidden visibility needed but x86inc.asm looks up to date where const already marked as hidden. As it used only asm so I also don't have idea why it happen. And -Wl,-Bsymbolic probably also wouldn't help
2013-10-08 21:55:34 < muggs_> I think it is using those link flags; will double check
2013-10-08 21:55:46 < BugMaster> do you test with new enough yasm?
2013-10-08 21:55:56 < muggs_> we require 1.2.0
2013-10-08 21:59:00 < BugMaster> than I am out of ideas (but I am not good linux). in x264 with similar code we don't have this problem afaik. there was something similar only without -Wl,-Bsymbolic because we used asm const in C code
2013-10-08 21:59:15 < BugMaster> *not good with
2013-10-08 21:59:34 < muggs_> ok, thanks
--- Day changed Wed Oct 09 2013
2013-10-09 03:00:59 <@muggs> +1 karma points for BugMaster for his -Wl,-Bsymbolic suggestion
2013-10-09 19:42:31 < davety> Hi All.  I just did a pull and update and now I am getting cmake errors when I run make-Makefiles.bash.  I can post error messages if anyone would like to see them
2013-10-09 19:48:17 < muggs> what version of cmake?  I'll take a look
2013-10-09 20:26:17 < davety> sorry for the slow response.  cmake 2.8.7
2013-10-09 20:26:26 < davety> is that too old/new?
2013-10-09 20:27:04 < muggs> sorry, otp at the moment.  It might be too old
2013-10-09 20:31:08 < davety> all of the errors are "Cannot find source file:"...
2013-10-09 20:48:29 < muggs> it seems you need 2.8.8
2013-10-09 20:48:40 < muggs> http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
2013-10-09 20:50:30  * muggs is bumping minimum requirement to 2.8.8 in root CMakeLists.txt
2013-10-09 20:51:14 < davety> It looks like 2.8.11 is the latest stable version.  would I be better off upgrading to something newer than 2.8.8?
2013-10-09 20:55:36 < muggs> it shouldn't matter
2013-10-09 20:55:48 < muggs> or should I say; it wouldn't hurt
2013-10-09 20:57:43 < davety> thanks muggs
2013-10-09 20:58:41 < muggs> no prob; I should be appologizing for bumping the cmake version requirement :)
--- Day changed Thu Oct 10 2013
2013-10-10 01:01:55 < SilverbackNet> Question on some of the recent patches posted to the mailing list: Aren't all of sse_ss16 through 64 now exactly the same function with different loop counters?
2013-10-10 18:54:02 < DaveY> In the files Lib/TLibEncoder/NALwrite.cpp and Lib/TLibCommon/TComSlice.h the include of cstring (or string.h) needs to be restored for memcpy.
2013-10-10 18:56:25 < DaveY> Hasn't anyone else run into the build error of "memcpy has not been declared"?
2013-10-10 18:56:59 < JEEB> the build testing at times isn't too high, only MSVC seems to be generally used by most of the china/india office people
2013-10-10 18:57:08 < JEEB> and then muggs is the only guy testing with GCC and friends
2013-10-10 18:57:48 < JEEB> so yeah, if the build breaks, it's generally nice to report it
2013-10-10 18:58:52 < DaveY> I also am using gcc, actually, I am very windows/MSVC ignorant
2013-10-10 19:17:50 <@muggs> hmm, I just fixed that yesterday, did it get rebroke?
2013-10-10 19:18:35 <@muggs> oh, yeah, I missed that delete from Gopu
2013-10-10 19:19:10 <@muggs> usually MinGW will catch those problems but some of them I don't find until I boot into Linux and/or open a Mac
2013-10-10 19:23:00 < DaveY> I have never used msvc, will it build without explicitly including cstring?
2013-10-10 19:23:06 <@muggs> I have a set of patches ready to push; will test on my Mac real quick and then let them go
2013-10-10 19:23:39 <@muggs> yeah, msvc and MinGW gcc on windows both build it ok without it; it's a system header thing.  I think mempcy is available in multiple headers
2013-10-10 19:24:25 < DaveY> ok, thanks
2013-10-10 19:29:13 <@muggs> pushed; let me know if there's still any problems
2013-10-10 19:37:45 <@muggs> been deleting a lot of code lately; always fun
2013-10-10 20:03:30 < DaveY> muggs, TComSlice.h still needs <cstring>, NALwrite.cpp looks good
2013-10-10 20:45:26 < radek> I just realized there's a serious downside to x264's popularity
2013-10-10 20:45:35 < radek> I tried googling x264 architecture
2013-10-10 20:45:46 < radek> I got a lot of torrents like Architecture.101.2012.x264
2013-10-10 20:46:25 < JEEBsv> yeah, although to be honest I wouldn't expect many results with such a search :)
2013-10-10 20:46:30 <@Skyler_> http://akuvian.org/src/x264/overview_x264_v8_5.pdf
2013-10-10 20:46:46 < JEEBsv> yeah, there's that overview and then the docs in doc/
2013-10-10 20:48:17 < radek> my thesis supervisor wants me to analyze OpenCL usage in x264, I figure I'm probably stuck with analyzing the code itself
2013-10-10 20:49:15 < radek> JEEBsv: I find that a lot of docs in projects like these are more of stream-of-consciousness type of things
2013-10-10 20:49:39 < radek> and they represent more the state of mind of the developer than actual documentation ;)
2013-10-10 21:20:56 <@muggs> I have an OpenCL arch doc for x265; but I won't be able to release it till late November at the earliest
--- Day changed Fri Oct 11 2013
--- Day changed Sat Oct 12 2013
--- Day changed Sun Oct 13 2013
--- Day changed Mon Oct 14 2013
2013-10-14 12:15:30 < funman> I got a segfault with last tree : http://pastie.org/8401200
2013-10-14 12:15:58 < funman> doens't segfault if I don't use X265_RC_ABR
2013-10-14 18:41:55 < muggs> all4edgar
2013-10-14 18:42:15 < muggs> wrong keyboard lol
--- Day changed Tue Oct 15 2013
--- Day changed Wed Oct 16 2013
2013-10-16 14:05:07 < JEEBsv> http://up-cat.net/p/7dc6e1b9
2013-10-16 14:05:11 < JEEBsv> currently on OS X with clang-3.3
2013-10-16 14:05:22 < JEEBsv> what am I doing wrong :D
2013-10-16 14:06:05 < j-b> using OSX
2013-10-16 14:06:19 < JEEBsv> ba-dum-tssh
2013-10-16 14:06:26 < JEEBsv> at least I haven't paid a dime for this machine :)
2013-10-16 14:06:35 < j-b> i hope so
2013-10-16 14:33:10 < koda> which verison of osx?
2013-10-16 14:33:27  * koda want not to pay dimes for macbooks too :<
2013-10-16 14:36:26 < Daemon404> probably 10.6
2013-10-16 14:37:19 < JEEBsv> yup, 10.6
2013-10-16 14:37:29 < JEEBsv> built llvm+clang 3.3 with homebrew
2013-10-16 14:38:11 < JEEBsv> koda: it's just seven years old (2006) and the battery is dead :D
2013-10-16 18:57:16 < JEEB> nice, AQ
2013-10-16 18:57:28 < Daemon404> aq before rc?
2013-10-16 18:57:33 < Daemon404> logic.tiff
2013-10-16 19:00:14 < smarter> The mix of C and C++ is so trippy
2013-10-16 19:00:46 < Daemon404> its pretty schizo
2013-10-16 19:13:24 < smarter> so, there's an m_qpAqOffset to store the delta-qp but it's not actually used anywhere :p
2013-10-16 19:14:06 < smarter> the hardcoded "avgQp /= 16" seems weird too if I understand the code correctly, I thought the size of CUs was variable
2013-10-16 21:44:46  * muggs pushes x265_param_parse()
2013-10-16 21:45:39 <@muggs> I'm curious on opinions about X265_BUILD.  Should it be implemented every time x265.h is changed, or can we do it each time a tagged release is made which changes API?
2013-10-16 21:45:48 <@muggs> (I'd prefer the latter myself)
2013-10-16 21:46:03 <@muggs> s/implemented/incremented/
2013-10-16 21:48:12 < j-b> Why do you need X265_BUILD if you have a correct release policy?
2013-10-16 21:50:32 <@muggs> good question.  right now it is used to prevent static linking version skew
2013-10-16 21:50:55 <@muggs> perhaps we don't need it for soname on shared libs.
2013-10-16 21:56:05 < j-b> Even for static linking, why do you care?
2013-10-16 21:56:30 < j-b> and why not use the X265_VERSION_MAJOR, MINOR, MICRO in a version.h header?
2013-10-16 21:56:53 < j-b> And update them only when something significant happens?
2013-10-16 22:02:53 <@muggs> I can see a lot of bug reports being caused by linking to old libs using new headers; I think it's worth the pain to version the API to prevent that.
--- Day changed Thu Oct 17 2013
--- Day changed Fri Oct 18 2013
2013-10-18 04:02:02 <@muggs> Daemon404: reading through the libav patch
2013-10-18 04:02:53 <@muggs> the current frame size requirement is it must be a multiple of the *minimum* cu size, which is 4.  It doesn't matter what the max CU size is.  Best to leave it as 64
2013-10-18 04:03:19 <@muggs> There's a guy working on removing the 4byte alignment requirement
2013-10-18 04:05:18 <@muggs> that's the first I've heard _t is not POSIX compliant. I think we're still a young enough project to nuke them.
2013-10-18 11:19:50 < j-b> Hello :)
2013-10-18 12:05:29 < Daemon404> why so happy j-b
2013-10-18 12:12:38 < j-b> Daemon404: Y not?
2013-10-18 12:12:53 < Daemon404> im just learning to be british
2013-10-18 12:13:00 < Daemon404> happiness is not allowed in England
2013-10-18 14:26:00 < kierank> Daemon404: damn straight
2013-10-18 14:26:17 < kierank> you're only allowed to be "alright"
2013-10-18 14:27:39 < Daemon404> indeed
--- Day changed Sat Oct 19 2013
--- Day changed Sun Oct 20 2013
--- Day changed Mon Oct 21 2013
2013-10-21 11:24:44 < funman> does ABR work already?
2013-10-21 11:26:31 < JEEB> yeah
2013-10-21 11:26:35 < JEEB> better than divx/mc's methinks
2013-10-21 11:26:52 < JEEB> which always hits like 20-30% under what you set
2013-10-21 11:26:55 < funman> I think I'm missing an option when using from VLC
2013-10-21 11:27:38 < funman> I'm getting 46kbps after requesting 800
2013-10-21 11:34:38 < Daemon404> O.o
2013-10-21 11:38:13 < ILEoo> funman: what output you're using with vlc when testing?
2013-10-21 11:45:28 < funman> file output with raw mux
2013-10-21 11:59:40 < Daemon404> worked for my wrapper
2013-10-21 12:24:58 < funman> here's the output: http://pastie.org/8418498
2013-10-21 12:25:59 < Daemon404> looks like x265 is simply broken
2013-10-21 12:26:03 < Daemon404> shocking
2013-10-21 12:26:29 < funman> I use x265_param_default, frameNumThreads = 8, bEnableWaveFront = 0, maxCUSize = 16, rc.bitrate = 800 and rc.rateControlMode = X265_RC_ABR
2013-10-21 12:26:51 < Daemon404> probably happen with x265 cli too
2013-10-21 12:26:54 < Daemon404> i.e. broken
2013-10-21 12:29:50 < funman> hm am I the only one to try ABR ? JEEB says it works for him (with the cli i suppose)
2013-10-21 12:30:09 < JEEB> I haven't tried it myself
2013-10-21 12:30:15 < JEEB> this was during the test Daemon404 did
2013-10-21 12:30:20 < JEEB> on the 27th of september
2013-10-21 12:32:47 < funman> let me try the cli
2013-10-21 12:37:56 < Mandarinka> are there any windows builds anywhere, btw?
2013-10-21 12:38:31 < Mandarinka> I'd have a look but like most, I'm not going to learn how to compile
2013-10-21 12:41:43 < funman> #0  0x0000000000455123 in x265::RateControl::rateEstimateQscale (this=this@entry=0x108cbf0, rce=rce@entry=0x1080eb0) at /media/dev/x265/source/encoder/ratecontrol.cpp:348
2013-10-21 12:41:46 < funman> 348	                lqmax /= pow(lstep, rfAdapt / frameThreads);
2013-10-21 12:41:48 < funman> (gdb) print frameThreads
2013-10-21 12:41:51 < funman> $1 = 0
2013-10-21 12:44:04  * funman pulls just in case
2013-10-21 13:10:44 < funman> cli seems to have the same effect
2013-10-21 13:56:11 < funman> http://pastie.org/8418711
2013-10-21 13:56:41  * Daemon404 has totally given on x265 and ignores it no
2013-10-21 13:56:43 < Daemon404> w
2013-10-21 13:58:26 < funman> /kick Daemon404 ok
2013-10-21 13:58:44  * Daemon404 made his choice based on observation
2013-10-21 18:41:44 < funman> muggs: hello
2013-10-21 18:54:00 < funman> muggs: is ABR ready yet ? http://pastie.org/8418711
2013-10-21 18:54:03 < funman> what can I do to help?
2013-10-21 19:26:41 <@muggs> it was broken by a recent refactor; I have a fix queued
2013-10-21 19:27:19 <@muggs> we're adding ABR to the nightly regressions so it doesn't keep getting busted (or doesn't stay busted so long)
2013-10-21 21:13:55 < funman> muggs: do you use buildbot/jenkins?
--- Day changed Tue Oct 22 2013
2013-10-22 00:02:30 <@muggs> funman: we do now, but it doesn't do ABR testing yet
2013-10-22 06:41:35 < greenfountain> ABR was broken with 4417 (ce889cef37be) rc: added TEncCfg instance to RateControl to reuse all the rc params directly.
2013-10-22 06:41:40 < greenfountain> fixed just now
2013-10-22 09:25:36 < funman> greenfountain: thanks
2013-10-22 11:01:12  * funman sends patch to mercurial
2013-10-22 12:20:42 < funman> http://www.selenic.com/pipermail/mercurial-devel/2013-October/054391.html \o/
2013-10-22 12:27:14 < Daemon404> the only fix for hg is rm -rf hg && install_git
2013-10-22 12:27:16  * Daemon404 rus
2013-10-22 12:27:17 < Daemon404> runs*
2013-10-22 12:48:09 < JEEB> funny how I often have problems accessing selenic.com
2013-10-22 15:33:04 <@muggs> can I convince anyone to review the vertical interpolation assembly code?
2013-10-22 15:33:41 < Daemon404> Skyler_ when he's awake?
2013-10-22 15:34:03 < Daemon404> also did the API versioning stuff ever go in?
2013-10-22 15:34:10 <@muggs> it's all in
2013-10-22 15:34:15 < Daemon404> ok
2013-10-22 15:34:28 <@muggs> going to make an 0.5 tag in the next day or so
2013-10-22 15:34:37 <@muggs> fixing up some loose ends.
2013-10-22 15:35:08 <@muggs> how useful would a pkgconfig file be for the install rule?
2013-10-22 15:35:12 < Daemon404> very
2013-10-22 15:35:24 < Daemon404> specifically for handling libstdc++
2013-10-22 15:35:31 < Daemon404> which is or isnt needed depending on a static or shared build
2013-10-22 15:35:43 < Daemon404> and possible other c++ libs
2013-10-22 15:35:45 < Daemon404> like -lc++
2013-10-22 15:35:57 < Daemon404> and msvc
2013-10-22 15:36:22 <@muggs> is pkgconfig supported on Windows?
2013-10-22 15:36:37 < Daemon404> libav requires msys for msvc
2013-10-22 15:36:45 < Daemon404> so it is feasible
2013-10-22 15:36:55 < Daemon404> we dont wanna hardcode -lstdc++ as a dep
2013-10-22 15:36:58 < Daemon404> its not portable at all
2013-10-22 15:37:04 < koda> +1
2013-10-22 15:38:11 <@muggs> ok; I'll see what I can do tonight when I have some time to hack on it.
2013-10-22 15:39:22 <@muggs> how does it work with x264; does the configure script write x264.pc?
2013-10-22 15:39:32 < Daemon404> yes
2013-10-22 15:39:49 <@muggs> ok
2013-10-22 15:44:03 <@muggs> the 0.5 release should remove the "multiple of 4" resolution requirement
2013-10-22 15:44:57 < Daemon404> pkg-confg would also ease verson checking
2013-10-22 15:45:01 < Daemon404> for >=0.5 e.g.
2013-10-22 15:45:53 <@muggs> did you see my earlier comment about the _t type suffix?
2013-10-22 15:46:00 < Daemon404> nuking it?
2013-10-22 15:46:04 <@muggs> yes
2013-10-22 15:46:19 < Daemon404> its still early enough probably
2013-10-22 15:46:24 <@muggs> if I'm going to; the sooner the better
2013-10-22 15:46:24 < Daemon404> only vlc has pushed a wrapper
2013-10-22 15:46:47 < j-b> and not in a release
2013-10-22 15:50:11 <@muggs> funman: I see you sent a patch to mercurial-devel; nice
2013-10-22 15:51:46 < funman> muggs: waiting for someone to comment on it!
2013-10-22 15:54:08 <@muggs> they just started their code freeze for the Nov 1 release
2013-10-22 15:54:24 < Daemon404> eh
2013-10-22 15:54:32 < Daemon404> i dont understand why people freeze master
2013-10-22 15:54:35 < funman> i just hope that the people who apply my patches can use this hg patch to not bork my name
2013-10-22 15:54:38 < Daemon404> fork a frozen branch
2013-10-22 15:54:40 < Daemon404> for the release
2013-10-22 15:54:42 < Daemon404> and work on master
2013-10-22 15:54:45 < Daemon404> whats so hard
2013-10-22 15:54:45 < Daemon404> ?
2013-10-22 15:55:25 <@muggs> personal preference of Matt; he wants all the developers to focus on testing and bug fixes
2013-10-22 15:55:57 <@muggs> just a policy decision
2013-10-22 15:56:09 < Daemon404> heh
2013-10-22 16:07:31 <@muggs> funman: btw, ABR is mostly working again but there's still a lookahead issue to track down that causes it to be less effective than it should
2013-10-22 16:31:40 < funman> muggs: ok, I will make more tests this week
2013-10-22 16:32:03 < funman> https://x265.cc/
2013-10-22 16:44:12 <@muggs> oh, interesting
2013-10-22 17:27:52 < Daemon404> funman, is that yours?
2013-10-22 17:28:01 < Daemon404> i can add icl13 or icl14 too
2013-10-22 17:28:08 < Daemon404> i run FATE with them anyway
2013-10-22 17:38:16 < funman> Daemon404: nope
2013-10-22 17:38:22 < funman> mine is buildbot.videolan.org
2013-10-22 17:38:26 < Daemon404> o ok
2013-10-22 17:38:42 < funman> I will add a buildbot when x265 has a pkg-config file
--- Day changed Wed Oct 23 2013
2013-10-23 09:26:20 < j-b> 'morning
2013-10-23 19:04:54 <@muggs> the vector class replacement effort is nearly done; and assembly work is accelerating.
2013-10-23 20:00:19 < easyfab> Is/will be asm test in testbench ? i'm curious to see asm vs intrinsic
2013-10-23 21:15:41 <@muggs> the testbench verifies intrinsics and assembly, and measures the most optimized version
2013-10-23 21:16:05 <@muggs> you could hack the testbench pretty easily measure only intrinsics or only assembly
2013-10-23 21:16:53 <@muggs> btw: I just nuked the last file that used vector classes for 8bpp primitives; so that effort is officially done.  no new intrinsic code
2013-10-23 21:17:46 <@muggs> I've been deleting intrinsic functions as we get assembly coverage; so there's not a lot of places you can do 1::1 comparisons right now
2013-10-23 23:20:42 < Sean_> hi there.  Is there a way to get x265 to accept a FIFO file as input?  EG have ffmpeg output yuv4mpeg formated raw video to a fifo file and have x265 read from that fifo.  I see here http://forum.doom9.org/showthread.php?p=1642418 they discuss a possible way to add it into the code, but I just can't get it to work.  Sure would speed up testing to not have to keep a super large raw frames .yuv file lying around.
2013-10-23 23:27:11 < Sean_> I thought this would work , but it appears that x265 always inspects the input file to see how many frames there are.
2013-10-23 23:27:50 < Sean_> so when it "inspects" the fifo file , it see zero frames and exits immediately .
2013-10-23 23:34:33 < Sean_> even when I tell that it that it needs to only do a certain number of frames, it still appears to inspect the input file to be sure that the specified number of frames exists
2013-10-23 23:36:13 < Sean_> I know that there is an incredible amount that is being done outside of this one thing, but I think it would be helpful, in many scenarios, to add this ability in.
2013-10-23 23:37:22 < smarter_> I thought that reading from a fifo file blocked until someone wrote something in it
2013-10-23 23:40:17 < Sean_> In my testing, I first run the ffmepg command that sends decoded raw frames into the fifo.  the ffmpeg command executes and displays some info on the the input file, then sits there doing nothing (waiting for something to start grabbing data from the other end).  Then I go and start the x265 command, and it sees the fifo file as containing "-1" frames, and exits
2013-10-23 23:40:47 < Sean_> once the x265 command exits, so does the ffmpeg command
2013-10-23 23:46:30 < Sean_> to be honest, I haven't tried first running the x265 command and then running the ffmpeg second.  but, I assume the same result will be had.
2013-10-23 23:53:48 < smarter_> oh okay, it tries to seek to the end in guessFrameCount and ignore the error result when using a pipe
2013-10-23 23:55:35 < Sean_> so , it does support the use of pipes?  do I just need to direct the frames from ffmpeg into x265 via STDIN instead?
2013-10-23 23:55:52 < Sean_> well, via STDIN and pipes?
2013-10-23 23:55:59 < smarter_> no, but patching it so that it does should be trivial
2013-10-23 23:57:01 < Sean_> trivial , once one knows where to put the code. :/
2013-10-23 23:58:18 < Sean_> I guess my problem is that I'm not well acquainted with the x265 code to do such a thing currently
2013-10-23 23:58:50 < Sean_> An , I'm guessing that this is considerably low on the priority of others who are well acquainted?
2013-10-23 23:59:46 < Sean_> looks as though x265gui http://forum.videohelp.com/threads/357754-[HEVC]-x265-EXE-mingw-builds?p=2261554&viewfull=1 may be doing something similar
--- Day changed Thu Oct 24 2013
2013-10-24 00:03:25 < Sean_> thanks for your help.  must leave.
2013-10-24 03:02:57 <@muggs> reading video from stdin is being added now; will be done tomorrow is my guess
2013-10-24 05:02:15 < Yukikaze> that makes me so happy to hear muggs
--- Day changed Fri Oct 25 2013
2013-10-25 12:05:37 < j-b> Cool, asm code :)
2013-10-25 14:09:18 < Daemon404> j-b, yeah. now if only we had some other stuff
2013-10-25 14:09:20 < Daemon404> like ratecontrol
2013-10-25 14:09:29 < j-b> Daemon404: they will come.
2013-10-25 14:09:36 < j-b> today, I'm in an optimistic mood
2013-10-25 14:09:40  * Daemon404 stares at "csv support"
2013-10-25 14:09:44 < Daemon404> i am certain this is for excel imports
2013-10-25 14:09:46  * Daemon404 runs
2013-10-25 14:09:52 < j-b> excel > *
2013-10-25 14:10:05 < Daemon404> depends on the purpose
2013-10-25 14:10:13 < Daemon404> it's quite terriblr at some things
2013-10-25 14:12:12 < j-b> no
2013-10-25 14:12:22 < j-b> it's the best tool EVAR :)
2013-10-25 14:14:08 < Daemon404> its extremely terrible at graphing, and running maths on very large data sets
2013-10-25 14:15:49 < j-b> but very good at compiling :)
2013-10-25 14:16:25 < j-b> and being the backbone of Information SYstem of huge companies...
2013-10-25 17:01:48 < funman> Daemon404: rc works
2013-10-25 18:33:26 < Daemon404> funman, i mean actual useful rc
2013-10-25 18:33:31 < Daemon404> which abr is not
2013-10-25 18:55:02 < easyfab> I try the new stdin function but I get this http://pastebin.com/DJPV9Snt  also try with ffmpeg -f rawvideo and yuv4mpegpipe -> doesn't work , did I miss something ?
2013-10-25 19:02:25 <@muggs> easyfab: this help?  http://pastebin.com/9DJRjLW6
2013-10-25 19:12:43 < easyfab> muggs: no http://pastebin.com/285adEr4 but the encoder doesn't start and I must break ctrl+c to exit
2013-10-25 19:16:07 <@muggs> I'll have to debug that locally, but I need to work  through some regression failures first
2013-10-25 19:16:38 < easyfab> np
2013-10-25 19:56:52 <@muggs> easyfab: can you try to pull and build from https://bitbucket.org/sborho/x265?
2013-10-25 20:20:28 < easyfab> muggs: no doesn't start and with debug version error code 0xc0000013
2013-10-25 20:21:43 <@muggs> what happens to it? does it just block?
2013-10-25 20:26:50 < easyfab> with realese no message error but encoder doesn't start and with debug http://postimg.org/image/9bdin345z/
2013-10-25 20:28:26 <@muggs> I thought cin.read() would block if no data was ready but perhaps it's returning an error
2013-10-25 20:55:36 < easyfab> muggs: It seems I'm not the only one who try here 2 others on doom9 http://forum.doom9.org/showpost.php?p=1649934&postcount=49 don't know if it helps
2013-10-25 20:55:46 <@muggs> ok, fixed a number of problems including the deadlock, but the main issue is that cin.good() always returns false
2013-10-25 20:56:15 <@muggs> I've fixed that problem already
2013-10-25 21:17:00 <@muggs> I've pushed more changes to my personal repo
2013-10-25 21:25:13 < easyfab> muggs: http://pastebin.com/J4KThEAg
2013-10-25 21:25:23 <@muggs> hmm, cin.read(framesize) fails on Windows but works  on Linux.  What are you testing on?
2013-10-25 21:27:01 <@muggs> http://pastebin.com/MJLyuu4a
2013-10-25 21:28:22 < easyfab> I'm testing foreman.yuv in avs but same with ffmpeg http://pastebin.com/cHU0EnAr -f rawviedeo
2013-10-25 21:29:26 <@muggs> what platform are you testing on?
2013-10-25 21:30:37 <@muggs> ah, drive letters, Windows.
2013-10-25 21:30:47 <@muggs> so this appears to be a Windows STDIN issue
2013-10-25 21:31:01 <@muggs> we might have to do some minor read buffering
2013-10-25 21:31:02 < easyfab> windows 7 x64 and build with vc10, will try with mingw if different
2013-10-25 21:33:27 <@muggs> short answer: ifstream stdin on Windows is full of fail
2013-10-25 21:33:29 <@muggs> http://compgroups.net/comp.unix.programmer/how-can-i-reopen-std-cin-and-std-cout-in/327672
2013-10-25 21:34:38 <@muggs> hmm, binmode.obj. let me try that
2013-10-25 21:35:54 < JEEBsv> oh right, windows had you set it to binary mode
2013-10-25 21:37:29 < JEEBsv> wait... std::cin and cout don't have options to enable bin mode?
2013-10-25 21:37:44 <@muggs> no
2013-10-25 21:38:09  * JEEBsv golfclaps
2013-10-25 21:38:12 <@muggs> you normally do that on file open,  and those are pre-opened
2013-10-25 21:38:17 < JEEBsv> yeah
2013-10-25 21:38:53 <@muggs> I think I'll just have them re-write these files with FILE* and be done with it
2013-10-25 21:39:02 < JEEBsv> sounds like a better way
2013-10-25 21:39:24 < easyfab> and how is it in x264 and vpx for example
2013-10-25 21:39:30 < JEEBsv> now I think I have seen one reason for why no-one uses those things multiplatform-wise where I see
2013-10-25 21:39:47 < JEEBsv> easyfab: x264 and friends use fopen and friends and set the flag IIRC
2013-10-25 21:40:12 <@muggs> setmode(fileno(stdin), O_BINARY);
2013-10-25 21:40:25 < JEEBsv> yup
2013-10-25 21:40:35 <@muggs> hmm... I wonder if that just works for cin
2013-10-25 21:43:32 <@muggs> \o/
2013-10-25 21:43:40 < JEEBsv> :D
2013-10-25 21:46:03 <@muggs> so now stdin reads are working, but it seems to be stuck
2013-10-25 21:46:55 <@muggs> pushed all this to the main repo
2013-10-25 21:48:53 < JEEBsv> ok... stuff seems to be read into the lookahead at least
2013-10-25 21:49:14 < JEEBsv> since I can see the input app having output X pictures
2013-10-25 21:49:19 <@muggs> I had --no-progress in my CLI opts and forgot about it.  it seems to be ok
2013-10-25 21:49:36 < JEEBsv> :)
2013-10-25 21:49:41 < JEEBsv> yeah, seems OK'ish so far
2013-10-25 21:50:47 <@muggs> well, that was fun.  need to sign off.  have a good weekened
2013-10-25 21:50:56 < JEEBsv> same to you :)
2013-10-25 21:50:58 <@muggs> or weekend, even
2013-10-25 21:52:11 < easyfab> yes Thanks muggs , it works
2013-10-25 21:52:30 < easyfab> good w-e to you
--- Day changed Sat Oct 26 2013
--- Day changed Sun Oct 27 2013
--- Day changed Mon Oct 28 2013
2013-10-28 19:25:20 <@muggs> Y4M on stdin is pushed
2013-10-28 19:32:03 < JEEB> yay
--- Day changed Tue Oct 29 2013
2013-10-29 20:02:42 < easyfab> Hey nice speed up  after the recent asm commit :)
2013-10-29 20:04:45 < easyfab> after asm can we expect to see some opencl commit soon ?
2013-10-29 20:06:51 < nevcairiel> opencl didnt really help x264, are there really expectations for that this time around?
2013-10-29 20:11:30 < easyfab> IIRC HEVC is more “parallelizable” than AVC so perhaps opencl will be more useful
2013-10-29 20:11:30 < Mandarinka> opencl isn't really a big thing imho
2013-10-29 20:11:43  * Mandarinka is looking forward to AQ and such stuff.
2013-10-29 20:12:19 < easyfab> Yes sure i'm not against more quality
2013-10-29 20:12:57 < JEEB> HEVC has more possibilities for parallelization (WPP/tiles) but I'm not sure how more useful they make GPUs
2013-10-29 20:13:11 < JEEB> personally I wouldn't bet on any kind of GPU-based parallelization too much
2013-10-29 20:13:45 < Mandarinka> in the end, it still require extra hardware that is expensive and power hungry, so what'S the point
2013-10-29 20:34:07 <@muggs> OpenCL public release will be early next year
2013-10-29 20:34:51 <@muggs> most of the perf improvement is from early-exit optimizations
2013-10-29 20:35:14 <@muggs> we've done a lot of MC asm but none of it is hooked up yet.
--- Day changed Wed Oct 30 2013
2013-10-30 09:26:24 < JEEB> ooh, a crf patch
2013-10-30 10:05:07 < quaz0r> thats what she said
2013-10-30 18:19:09 <@muggs> it's quite a lot of fun to delete intrinsic functions
2013-10-30 19:02:10 < JEEB> :D
2013-10-30 19:02:34 < JEEB> also I noticed someone poked around to do something a la CRF
2013-10-30 19:02:43 < JEEB> the coding was clearly done in VS :D
2013-10-30 19:02:59 < JEEB> (nothing else defaults to tabs as tabs even if the file doesn't use them like that)
2013-10-30 19:21:16 <@muggs> heh
--- Day changed Thu Oct 31 2013
--- Day changed Fri Nov 01 2013
--- Day changed Sat Nov 02 2013
--- Day changed Sun Nov 03 2013
2013-11-03 09:51:12 < j-b> 'morning
2013-11-03 20:31:54 < Mandarinka> hmm, I see on bitbucket that the crf patch got merged?
--- Day changed Mon Nov 04 2013
2013-11-04 15:12:22 < JEEB> did x265 have settings for setting the VUI info?
2013-11-04 15:12:29 < JEEB> I mean like --colormatrix with x264
2013-11-04 15:12:32 < Daemon404> not afaik
2013-11-04 15:20:13 < Daemon404> i see the roadmap from tom on d9 *still* does not include proper ratecontrol
2013-11-04 15:20:14 < Daemon404> -_-
2013-11-04 15:20:58 < koda> link
2013-11-04 15:21:26 < JEEB> Daemon404, crf is in
2013-11-04 15:21:56 < Daemon404> http://forum.doom9.org/showpost.php?p=1650549&postcount=59
2013-11-04 15:21:59 < Daemon404> JEEB, is it?
2013-11-04 15:22:02 < JEEB> yes
2013-11-04 15:22:09 < Daemon404> 2pass too?
2013-11-04 15:22:15 < JEEB> nope
2013-11-04 15:22:17 < JEEB> just CRF
2013-11-04 15:22:23 < Daemon404> makes testing kind of hard then
2013-11-04 15:25:08 < Daemon404> JEEB, played much with it
2013-11-04 15:25:23 < Daemon404> i.e. how does its scale work out
2013-11-04 15:25:37 < Daemon404> like x264's 'standard' crf 18
2013-11-04 15:26:45 < JEEB> haven't tried it yet
2013-11-04 15:29:59 < Daemon404> muggs, ping
--- Day changed Tue Nov 05 2013
2013-11-05 09:46:31 < j-b> hello
2013-11-05 09:48:22 < koda> hi
2013-11-05 20:23:27 < _muggs> Main10 patches on the way
2013-11-05 20:24:36 < JEEB> cool :)
2013-11-05 20:24:50 < JEEB> also I noticed a patch to enable the AQ
2013-11-05 20:25:16 < _muggs> yeah, still highly experimental; but it's getting there
2013-11-05 20:26:55 < JEEB> should test stuff tomorrow :) Also need to check if you can set VUI values (matrix coeffs f.ex.)
2013-11-05 20:27:01 < JEEB> from the cli
2013-11-05 20:28:14 < _muggs> eh, no.  there's remnant support there from the HM, but it needs to be hooked up
2013-11-05 20:28:26 < JEEB> ok
2013-11-05 20:28:44 < JEEB> I just fixed the libavcodec decoder to actually hook those things up to libavcodec itself
2013-11-05 20:28:48 < JEEB> they were parsed, but not used :D
2013-11-05 20:29:00 < j-b> and the decoder is slow
2013-11-05 20:29:29 < JEEB> hey, I'm happy being able to play 720p with a core 2 duo p8400 :)
2013-11-05 20:29:39 < j-b> 2K is slow
--- Day changed Wed Nov 06 2013
--- Day changed Thu Nov 07 2013
2013-11-07 12:20:49 < line1> is there any way to convince x265 to output main10, yet? all my attempts so far have resulted in crashes
2013-11-07 12:22:26 < line1> e.g. avs2pipemod -rawvideo V:\T\ntest_10i.avs | .\x265.exe --preset veryslow --input-depth 10 --input-res 1920x1080 --fps 24000/1001 --input-csp i420 --recon-depth 10 - -o V:\T\ntest_x265_10.hevc
2013-11-07 14:29:40 < quaz0r> so what exactly is the state of x265 right now
2013-11-07 16:05:21 < line0> the main10 crash seems to happen in x265.exe!x265::TComPicYuv::copyFromPicture(const x265_picture & pic, int * pad) Line 354
2013-11-07 16:16:27 < JEEBsv> quaz0r: some stuff *seems* to work, but expect almost every revision to be a gamble regarding various things :)
2013-11-07 16:16:47 < JEEBsv> it's a rather young project
2013-11-07 16:19:57 < quaz0r> heh
2013-11-07 19:40:50 < funman> muggs: can we assume backward compatibility when X265_BUILD is incremented?
2013-11-07 19:41:07 < funman> e.g. use #if X265_BUILD >= 3 versus #if X265_BUILD == 3 in our code
2013-11-07 21:06:03 < muggs_> funman: it hasn't thus far.
2013-11-07 21:10:37 < funman> muggs_: so code that built with BUILD == 3 won't build with BUILD == 4 ?
2013-11-07 21:10:54 < funman> I think it boils down to only adding new APIs and not removing/modifying existing ones
2013-11-07 21:11:17 < muggs_> between 1 and 2 we dropped _t suffixes
2013-11-07 21:11:55 < muggs_> and I expect we'll be adding members to x265_param quite often
2013-11-07 21:12:42 < muggs_> if you use x265_param_parse you'll be mostly immune to that
2013-11-07 21:13:22 < funman> ah nice I didn't see it was added
2013-11-07 21:13:28 < funman> need to catch up I guess
2013-11-07 21:13:40 < smarter> adding members shouldn't break the API
2013-11-07 21:14:59 < muggs_> it would break the encoder if you passed an old param to a new funtion
2013-11-07 21:20:56 < muggs_> perhaps we need to make an x265_param_alloc() so you could treat as 100% opaque
2013-11-07 21:21:07 < muggs_> the encoder would know the right size for it
2013-11-07 21:24:30 < funman> it would help yes
2013-11-07 21:24:35 < funman> not sure if it is enough though
2013-11-07 21:26:34 < funman> except _t suffix removal it seems only x265_param changed so it might be enough indeed
2013-11-07 21:27:08 < muggs_> going forward, it might be enough
2013-11-07 21:28:20 < muggs_> perhaps x265_picture_alloc() as well
2013-11-07 21:28:29 < funman> btw i got no follow up on that mercurial patch i sent :/
2013-11-07 21:28:36 < muggs_> it is likely to bloat
2013-11-07 21:28:59 < muggs_> I saw an email response to your patch asking for a test
2013-11-07 21:29:14 < funman> yeah I sent the test but the test fails
2013-11-07 21:29:30 < muggs_> lol
2013-11-07 21:29:33 < funman> strings are all using local encoding
2013-11-07 21:29:47 < funman> and the tests run with ASCII local encoding which obviously can't represent full unicode
2013-11-07 21:30:03 < muggs_> localization in Python is a bit of a mess; and Python3 makes it somewhat worse
2013-11-07 21:30:06 < funman> so instead of having my name be base64 encoded I become Rafa?l Carr?
2013-11-07 21:31:01 < funman> it's a shame especially when strings are converted to unicode before final output
2013-11-07 21:31:29 < muggs_> it's acceptable etiquite to re-poke an email discussion if you don't get any response in a week or so.. or raise a fuss on #mercurial
2013-11-07 21:31:49 < funman> yeah i should do that
--- Day changed Fri Nov 08 2013
2013-11-08 19:57:24 < muggs_> exciting; we got 4:4:4 I frames working last evening
2013-11-08 21:10:06 < kurosu> muggs, with 4:4:4 not yet stable? I mean, 4:4:4 might have changed a lot since the version you tested
2013-11-08 21:16:28 < kurosu> muggs_: ^
2013-11-08 21:28:41 < muggs_> you mean the range extensions are not yet finalized?
2013-11-08 21:28:57 < line0> what about main10 and 10bit input? the evaluator's guide seems to indicate it already works
2013-11-08 21:29:53 < muggs_> it only works today with --cpuid 1 (disable simd)
2013-11-08 21:30:08 < muggs_> and obvisouly you must build with HIGH_BIT_DEPTH enabled in cmake
2013-11-08 21:30:47 < muggs_> 4:4:4 work is not in the main repo yet
2013-11-08 21:30:47 < line0> yeah, i did just that, but it always crashed on me
2013-11-08 21:31:15 < line0> i'll see if it works without simd, but i guess it's going to be unbearably slow
2013-11-08 21:31:42 < muggs_> not much difference, there's very little SIMD code for HIGH_BIT_DEPTH
2013-11-08 21:32:41 < line0> nope, still crashes with --cpuid 1
2013-11-08 21:33:28 < muggs_> YUV10 inputs?
2013-11-08 21:33:36 < line0> yeah
2013-11-08 21:33:46 < muggs_> command line?
2013-11-08 21:33:58 < muggs_> I've just pushed today's batch of changes
2013-11-08 21:34:09 < line0> avs2pipemod -rawvideo V:\T\ntest_10i.avs | .\x265.exe --preset veryslow --cpuid 1 --input-depth 10 --input-res 1920x1080 --fps 24000/1001 --input-csp i420 --recon-depth 10 - -o V:\T\ntest_x265_10.hevc
2013-11-08 21:34:39 < line0> err, also tried with input-csp X265_CSP_I420
2013-11-08 21:34:57 < muggs_> we don't do fractional fps, just use 24 for now
2013-11-08 21:35:26 < muggs_> i420 is implied if no CSP is specified
2013-11-08 21:36:34 < line0> no luck with 24fps, either
2013-11-08 21:36:43 < line0> i'll try to rebuild with the latest changes
2013-11-08 21:36:52 < muggs_> --recon-depth is unnecessary if you're not outputing a recon YUV
2013-11-08 21:37:41 < line0> i thought so, too but x265 [error]: Bit depth of the recon file should be the same as input bit depth
2013-11-08 21:37:53 < line0> even when not specifying a recon file
2013-11-08 21:37:54 < muggs_> hmm; I'll fix that
2013-11-08 21:38:48 < line0> crashes in x265.exe!x265::TComPicYuv::copyFromPicture(const x265_picture & pic, int * pad) Line 354
2013-11-08 21:42:50 < muggs_> are you on the stable branch?  line 354 is pady = rem ? 16 - rem : pady;  not really crash worthy
2013-11-08 21:43:21 < muggs_> pushed a fix for the recon depth check
2013-11-08 21:44:37 < muggs_> main10 is only expected to work on the default branch; it hasn't been released to stable yet
2013-11-08 21:44:54 < line0> ah wait, i added a patch from the mailing list to TComPicYuv.cpp to see if it fixed the problem
2013-11-08 21:45:13 < line0> so the line number is different. sec
2013-11-08 22:03:33 < line0> nope
2013-11-08 22:03:35 < line0> still crashes
2013-11-08 22:03:50 < line0> x265.exe!x265::TComPicYuv::copyFromPicture(const x265_picture & pic, int * pad) Line 368
2013-11-08 22:07:35 < line0> Y[c] = (Pel)y[c];
2013-11-08 22:16:22 < muggs_> that function looks ok; let me double check the yuv reader
2013-11-08 22:16:43 < line0> do you need any additional debugging information?
2013-11-08 22:18:00 < line0> or a sample of the clip i'm trying to encode?
2013-11-08 22:18:25 < muggs_> does it crash right away?
2013-11-08 22:19:42 < line0> pretty much http://pastebin.com/qRGxdeWi
2013-11-08 22:19:52 < line0> almost instantly
2013-11-08 22:22:26 < muggs_> the YUV reader is CSP unaware, so it must be i420, but that's obviously not your problem here
2013-11-08 22:26:16 < muggs_> I've pushed a couple of minor nits; one might help, please try.
2013-11-08 22:26:24 < muggs_> if not; I'll have to look at this later tonight
2013-11-08 22:47:36 < line0> still crashes in the same location with the new changes
2013-11-08 22:50:15 < koda> muggs: are you interested in writing an opencl hwaccel driver for avconv? :)
2013-11-08 23:12:15 < muggs_> hah; not anytime soon
2013-11-08 23:12:41 < muggs_> I'm downloading some 10bit test sequences, will look into this more closely tonight or tomorrw
2013-11-08 23:13:10 < muggs_> I'll be at the AMD APU13 conf next week, then a Mercurial sprint next weekend; so won't be on IRC much
2013-11-08 23:14:36 < line0> https://files.line0.in/samples/ntest_10i.yuv.7z sample clip and thanks for the help
--- Day changed Sat Nov 09 2013
2013-11-09 09:43:26 < kurosu> muggs_: no it is not (delayed by one meeting cycle), and in particular 4:4:4 has a new coding tool
2013-11-09 09:43:37 < kurosu> afaik only 4:2:2 is unchanged
2013-11-09 09:45:27 < kurosu> there also lots of new screen content tools, but it is unclear what 4:4:4 profiles will emerge
2013-11-09 15:51:13 < muggs> figured out the 10bit problem; pic.stride is counting bytes, but it is being used to increment a uint16_t *
2013-11-09 16:11:30 < muggs> at medium preset, 2560x1600 10bit YUV encodes at 0.14fps on my desktop PC :)
2013-11-09 16:21:57 < kurosu> muggs: do you have any asm for 10bits, eg motion compensation/estimation?
2013-11-09 16:28:24 < line0> muggs, thanks, works now
2013-11-09 23:08:40 < Mandarinka> hmm, I notice that the mention of qcomp disappeared from the todo page in the wiki. Has the mechanism been introduced into x265?
2013-11-09 23:24:09 < Mandarinka> also, enabling aq helps preserve grain (I am testing with ~placebo options and crf 16), yay!
2013-11-09 23:24:59 < Mandarinka> although to really preserve grain, psyrdo will need to come, I guess. (psyrdo or maybe at least CQMs?)
--- Day changed Sun Nov 10 2013
2013-11-10 12:46:09 < line0> still getting lots of artifacts in main10, like this: http://puu.sh/5dUaQ.png
--- Day changed Mon Nov 11 2013
--- Day changed Tue Nov 12 2013
2013-11-12 15:37:25 < Daemon404> fails to build with g++ *again*
2013-11-12 15:37:29 < Daemon404> this is gettng really old
2013-11-12 15:37:54 < nevcairiel> so are your complaints :P
2013-11-12 15:38:43 < Daemon404> i dont think "check to see if it compiles on anything but msvc" is an invalid complaint
2013-11-12 15:56:53 < Daemon404> /mnt/tc/dev/x/x265/source/Lib/TLibEncoder/TEncSearch.cpp:3022: error: no matching function for call to ‘x265::TEncSearch::xEstimateResidualQT(x265::TComDataCU*&, int, int, x265::TShortYUV*&, x265::UChar, uint64_t&, unsigned int&, unsigned int&, uint32_t*, bool&)’
2013-11-12 15:56:57 < Daemon404> /mnt/tc/dev/x/x265/source/Lib/TLibEncoder/TEncSearch.h:252: note: candidates are: void x265::TEncSearch::xEstimateResidualQT(x265::TComDataCU*, uint32_t, uint32_t, x265::TShortYUV*, uint32_t, x265::UInt64&, uint32_t&, uint32_t&, uint32_t*, bool)
2013-11-12 15:57:01 < Daemon404> seems just like bad code to me
--- Day changed Wed Nov 13 2013
2013-11-13 05:23:18 < greenfountain> hi , i was playing around with AQ in both x264 and x265.. there are some questions reg aq in x264..
2013-11-13 05:23:21 < greenfountain>  i was trying it out with ABR, no mb tree.. for fast moving videos, AQ kicks in only at higher bitrates.. for lower bitrates aq mode 1 reports lower ssim compared to non-aq..
2013-11-13 05:25:06 < greenfountain> -b-pyramid 0 --bitrate 1000 --weightp 0  --threads 1  --no-mbtree  -o out.x265  E:\Aarthi\HEVCsamples\BasketballDrive_1920x1080_50.y4m --keyint 250 --ssim --frames 100  --aq-mode 0  : gives ssim -  x264 [info]: SSIM Mean Y:0.7225816 ( 5.569db)
2013-11-13 05:25:29 < greenfountain> same setting with aq-mode 1  : x264 [info]: SSIM Mean Y:0.7147596 ( 5.448db)
2013-11-13 05:26:04 < greenfountain> but with bitrates  -- bitrate 3000 or higher, AQ shows better results
2013-11-13 05:27:28 < greenfountain> isnt AQ supposed to help put when bitrates are lower? assigning more bits to slow moving blocks to  improve quality, especially when video is scaled to lower bitrates ?
2013-11-13 05:29:37 < greenfountain> also for slow moving videos, (i tried out FourPeople_1280x720_60.y4m) .. AQ dosnt show good results for any bitrate. is there some reason behind this behaviour?
2013-11-13 05:43:58 < theHH> how to get started encoding in x265?
2013-11-13 05:46:34 < theHH> anyone alive?
2013-11-13 05:48:23 < theHH> ?
2013-11-13 06:01:52 < theHH>  how to get started encoding in x265?
--- Day changed Thu Nov 14 2013
2013-11-14 00:14:33 < Mandarinka> < greenfountain> isnt AQ supposed to help put when bitrates are lower? assigning more bits to slow moving blocks to  improve quality, especially when video is scaled to lower bitrates ?
2013-11-14 00:14:33 < Mandarinka> < greenfountain> also for slow moving videos, (i tried out FourPeople_1280x720_60.y4m) .. AQ dosnt show good results for any bitrate. is there some reason behind this behaviour?
2013-11-14 00:14:49 < Mandarinka> x265's AQ is IIRC ported over from x264
2013-11-14 00:15:00 < Mandarinka> the method doesn't do what you describe
2013-11-14 00:15:26 < Mandarinka> it works spatially, and basically assigns more bits to blocks based on some metric
2013-11-14 00:16:11 < Mandarinka> based on "variance" IIRC
2013-11-14 00:17:26 < Mandarinka> from the code:
2013-11-14 00:17:27 < Mandarinka> +* x264_adaptive_quant:
2013-11-14 00:17:27 < Mandarinka> + * adjust macroblock QP based on variance (AC energy) of the MB.
2013-11-14 00:17:27 < Mandarinka> + * high variance  = higher QP
2013-11-14 00:17:27 < Mandarinka> + * low variance = lower QP
2013-11-14 00:17:27 < Mandarinka> + * This generally increases SSIM and lowers PSNR.
2013-11-14 00:18:49 < Mandarinka> /my completely amateurish and possibly wrong explanation is that it puts more bits into flat areas like backgrounds, to preserve their texture - such places generally get blurred and decimated by conventional encoders/
2013-11-14 00:20:05 < Mandarinka> hmm, and of course, now I notice that while he joined not long ago, he also quit later (I'll PM it to him when he returns I guess.)
2013-11-14 02:02:54 < smarter> your explanation is correct
2013-11-14 06:15:36 < greenfountain> < Mandarinka> I understand.. what I don't get is , say for a test sequence, while testing with ABR,  AQ seems to show results when --bitrate is set to a higher value
2013-11-14 06:16:15 < greenfountain> and for lower bitrates, it decreases SSIM.. since its the same test sequence that is being used, the variance calculations are the same in both cases..
2013-11-14 09:29:45 < greenfountain> does --tune ssim also use satd to compute the distortion for mode decisions in x264?
--- Day changed Fri Nov 15 2013
2013-11-15 14:26:05 < Daemon404> ...
2013-11-15 14:26:07 < Daemon404> goddammiit
2013-11-15 14:26:17 < Daemon404> Segmentation fault (core dumped)5 kb/
2013-11-15 14:26:20 < Daemon404> after 16 hrs of encoding
2013-11-15 14:26:22 < Daemon404> :(
2013-11-15 16:04:28 < nevcairiel> some scene group released a whole movie encoded with x265, took over 7 days of encoding, lucky them it didnt crash :p
2013-11-15 16:04:55 < Daemon404> and it likely looked worse than x264
2013-11-15 16:05:01 < Daemon404> and also didnt conform to their standards
2013-11-15 16:05:04 < Daemon404> i.e. would be nuked
2013-11-15 16:05:29 < nevcairiel> of course there is no standard, but i didnt have the file myself to check its quality
2013-11-15 16:05:52 < Daemon404> complete lack of psychovisual opts probably doesnt help...
2013-11-15 16:13:21 < smarter> well, there's AQ now, but I doubt it helps much
2013-11-15 16:13:30 < Daemon404> you cant even set its strength
2013-11-15 16:13:34 < Daemon404> thats hardly useful...
2013-11-15 16:15:05 < smarter> in libvpx I didn't bother with a strength setting because I couldn't find a clip where it was worth it
2013-11-15 16:15:28 < Daemon404> its made quite a large difference setting it for me in x264
2013-11-15 16:15:41 < Daemon404> depending in the overall brightness/colors of the scene / video
2013-11-15 16:16:00 < Daemon404> specifically in anime and/or grainy things
--- Day changed Sat Nov 16 2013
2013-11-16 00:27:26 < Mandarinka> < smarter> in libvpx I didn't bother with a strength setting because I couldn't find a clip where it was worth it < Daemon404> specifically in anime and/or grainy things
2013-11-16 00:27:32 < Mandarinka> it definitely helps in x265
2013-11-16 00:28:34 < Mandarinka> but to really preserve grain and behave nicely with "dirty" video like x264 does, it probably needs psyrdo too (and maybe other things too, dunno)
2013-11-16 00:29:28 < Mandarinka> the strength parameter would be nice, of course (I generally set it to 0.8 in x264)
2013-11-16 00:29:59 < smarter> you tried different strenghs with x265?
2013-11-16 00:30:09 < Mandarinka> BTW, since I already mention this... would it be possible to also add a --qpmax parameter like x264 does? To cap the maximum qp the encoder can use.
2013-11-16 00:30:28 < Mandarinka> nope, x265 doesn't have strenght parameter :)
2013-11-16 00:30:41 < Mandarinka> unless I missed something
2013-11-16 00:30:42 < smarter> so you're saying AQ helps
2013-11-16 00:31:04 < Mandarinka> x265 smooths less with it.
2013-11-16 00:31:06 < smarter> well, for testing purpose it wouldn't be hard to change the strength hardcoded in the source
2013-11-16 00:32:05 < Mandarinka> yeah, but I'm just a fansub/dvdripping encoder, I never learned to compile stuff :D
2013-11-16 00:34:03 < smarter> you learned enough to compile x265 :p
2013-11-16 00:35:28 < Mandarinka> naw, I just grabbed a test build from somewhere (forgot)
2013-11-16 00:36:01 < smarter> actually, there is an aqStrength parameter in x265, there just isn't a corresponding command-line flag
2013-11-16 00:36:06 < JEEB> building x265 is really simple tho
2013-11-16 00:36:09 < Mandarinka> ah.
2013-11-16 00:36:23 < JEEB> cmake, yasm, visual studio express on windows
2013-11-16 00:36:30 < JEEB> (since vs is the main tested compiler)
2013-11-16 00:36:42 < smarter> if you wanted to give it a shot, you'd just have to change the 1.0 in "param->rc.aqStrength = 1.0;" in source/common/common.cpp
2013-11-16 00:36:54 < Mandarinka> well, I think I will stick to easier methods of slacking in between work :D
2013-11-16 16:20:49 < Daemon404> Segmentation fault (core dumped)kb/s
2013-11-16 16:20:51 < Daemon404> ARGH
2013-11-16 16:24:10 < smarter> x265 hates you
2013-11-16 16:24:37 < Daemon404> x265 hates anything that isnt MSVC
2013-11-16 16:24:40 < Daemon404> more or less.
2013-11-16 17:11:27 < quaz0r> so its a bunch of windows nerds behind x265?
2013-11-16 17:13:13 < Daemon404> it's an outsourcing company.
2013-11-16 17:14:51 < j-b> MSVC compiles now libav/FFmpeg and mostly x264
2013-11-16 17:35:31 < muggs> I've pushed a number of fixes to BB; don't have my videolan ssh key with me
2013-11-16 17:35:43 < muggs> working on my Mac this weekend
2013-11-16 17:47:25 < Daemon404> j-b, soon c99wrap wont be needed at all for libav/ffmpeg
2013-11-16 17:47:26 < Daemon404> i hope.
2013-11-16 17:47:41 < j-b> it is not needed anymore already for libav
2013-11-16 17:48:03 < Daemon404> c99conv isnt
2013-11-16 17:48:05 < Daemon404> c99wrap is
2013-11-16 17:48:18 < j-b> ah? I missed that one :)
2013-11-16 17:48:30 < Daemon404> also makedef is for dlls
2013-11-16 17:48:38 < Daemon404> im going to submit a patch to import it
2013-11-16 17:48:40 < Daemon404> soon
2013-11-16 17:55:05 < BugMaster> j-b: have you really tried new msvc on x264?
2013-11-16 17:55:30 < j-b> and reported 4 bugs to MSVC team, yes
2013-11-16 17:58:37 < JEEB> cool
2013-11-16 17:59:47 < Daemon404> :D
2013-11-16 18:00:44 < muggs> Daemon404: still having crash issues with tip?
2013-11-16 18:05:41 < Daemon404> yes
2013-11-16 18:05:44 < Daemon404> at the end of encodes
2013-11-16 18:05:49 < Daemon404> well, i compiled 1 day ago
2013-11-16 18:05:51 < Daemon404> (or 2?)
2013-11-16 18:05:55 < Daemon404> since it took ~16 hrs to encode
2013-11-16 18:07:21 < muggs> I don't recall any recent crash bugs at exit.  do you have the command line handy?
2013-11-16 18:07:57 < Daemon404> sec...
2013-11-16 18:07:59 < Daemon404> i need to connect to vpn
2013-11-16 18:08:34 < muggs> my sprint group is heading for lunch; be back in 30 probably
2013-11-16 18:09:08 < muggs> btw: weightp will probably be enabled by default by Monday, and I have early bpyramid patches for review
2013-11-16 18:09:45 < Daemon404> ffmpeg -i source.mov -an -f yuv4mpegpipe - 2>/dev/null | ./xb/x265 --y4m --input - -o a24.hevc --preset placebo --me full --rd 2 --crf 24 --aq-mode 1
2013-11-16 19:49:50 < muggs> ah, crf and aq.  both are still pretty experimental. let me see what happens when I try them
2013-11-16 20:12:16 < Mandarinka> didn't crash for me - but I used a yuv raw file.
2013-11-16 20:12:35 < Mandarinka> oh, and my build was few days old
2013-11-16 20:13:18 < Mandarinka> and I encoded just ~2200 frames.
2013-11-16 20:13:36 < Daemon404> this was about 37k
2013-11-16 20:16:09  * Mandarinka feels the pain.
2013-11-16 20:16:16 < Mandarinka> mine took like 10 or more hours.
2013-11-16 20:16:19 < Mandarinka> and that was SD
2013-11-16 20:16:26 < Daemon404> In most situations,
2013-11-16 20:16:26 < Daemon404> GUI designers should not be forced to fight each other with
2013-11-16 20:16:26 < Daemon404> tridents and nets as I yell “THERE ARE NO MODAL DIALOGS
2013-11-16 20:16:33 < Daemon404> er... totally wrong channel
2013-11-16 20:16:57 < muggs> placebo and me full is kind of aiming both pistols at your feet, perf wise
2013-11-16 20:17:05 < Mandarinka> ah, I used --ref 16, probably the reason why it was so slow :D
2013-11-16 20:17:10 < Daemon404> muggs, work server over the weekend
2013-11-16 20:17:16 < Daemon404> not exactly slowin me down
2013-11-16 20:24:13 < muggs> in my profiling, there is not much compression difference yet between slower and placebo.
2013-11-16 20:24:32 < Daemon404> again, it was set it and forget it for 2 days
2013-11-16 20:24:35 < muggs> I'm hoping mb-tree and bpyramid improve things there
2013-11-16 20:24:36 < Daemon404> /care
2013-11-16 20:28:05 < Mandarinka> trellis quantization might
2013-11-16 20:28:36 < Mandarinka> dunno if x265 does RDO on QPs, like x264 during subme 10
2013-11-16 20:28:48 < muggs> ah, yes.  I think slow->slower enables the HM's RDOQ.
2013-11-16 20:29:52 < muggs> not sure how much it resembles x264's trellis and QP RDO
2013-11-16 20:31:47 < muggs> http://tny.cz/8cd1175f
2013-11-16 20:31:55 < Daemon404> does x265 have a buidlbot or jenkins yet?
2013-11-16 20:32:07 < Daemon404> cause every time i go to poke it, it fails to build on !msvc
2013-11-16 20:32:09 < Daemon404> for day(s)
2013-11-16 20:33:25 < muggs> there's 4-5 people working on Jenkins automation; trying to expand what gets tested.  Linux and Mac are being added
2013-11-16 20:33:45 < Daemon404> it seems msvc lets you get away with a lot sloppier code
2013-11-16 20:34:44 < muggs> I'm typically building at least on msys each day; I'm surprised Linux is broken that much.
2013-11-16 20:35:11 < muggs> I might switch to doing day-to-day work on Mac
2013-11-16 20:35:21 < Daemon404> i generally build on centos lately
2013-11-16 20:35:24 < Daemon404> gcc 4.4.X
2013-11-16 20:36:43 < Daemon404> [20:33] < muggs> I might switch to doing day-to-day work on Mac <-- C++ is prett hellish to work with on anything but the msvs ide...
2013-11-16 20:36:44 < muggs> hmm, my msys env has gcc 4.8.1; but I thought 4.8 would be more strict
2013-11-16 20:37:10 < JEEB> 4.8 is indeed more strict :)
2013-11-16 20:37:34 < Daemon404> you can never be sure with gcc
2013-11-16 20:37:40 < Daemon404> it calls rand() to see when to fail
2013-11-16 20:38:36 < muggs> heh, rand() is the most popular reason our testbench fails on linux.  on Windows rand() returns a 15bit value; on Linux its 32bits
2013-11-16 20:40:14 < Daemon404> why is rand() used at all
2013-11-16 20:40:41 < muggs> random input pixels, mostly
2013-11-16 20:41:00 < Daemon404> why not use rotozoom.c and pals
2013-11-16 20:41:04 < Daemon404> from libav/ffmpeg
2013-11-16 20:41:52 < muggs> we copied the approach from checkasm; is rotozoom better than rand?
2013-11-16 20:42:06 < Daemon404> no idea about checkasm
2013-11-16 20:42:31 < Daemon404> rotozoom and pals are used to to encode/decode regression testing on ffmpeg/libav
2013-11-16 20:42:43 < Daemon404> designed to test diff parts of the encoder iirc
2013-11-16 20:43:10 < muggs> our testbench is just for the performance primitives like satd/satd, etc.
2013-11-16 20:43:18 < Daemon404> ah.
2013-11-16 20:43:47 < muggs> there's external tools for regression and smoke testing
2013-11-16 21:12:56 < muggs> btw: --me full is not doing what you expect.  we don't do string parsing there, it is casted to an int and you get DIA
2013-11-16 21:18:27 < Daemon404> woops
2013-11-16 21:18:32 < Daemon404> right...
2013-11-16 21:18:37 < Daemon404> damn ints
2013-11-16 21:18:40  * Daemon404 hate
2013-11-16 21:19:13 < Mandarinka> hmm, fun stuff :)
2013-11-16 21:19:36 < Mandarinka> wouldn't it be better if the sanity check refused such commandlines?
2013-11-16 21:19:53 < muggs> we should be doing string parsing there.. it would be a one-line change now, I think
2013-11-16 21:59:06 < muggs> not quite a one-line, but pushed
--- Day changed Sun Nov 17 2013
--- Day changed Mon Nov 18 2013
2013-11-18 13:29:40 < funman> i have a segfault in x265_pixel_satd_8x8_internal2_avx
2013-11-18 13:29:48 < funman> http://pastie.org/8489686
2013-11-18 13:30:56 < funman> => 0x0000000000516318 <x265_pixel_satd_8x8_internal2_avx+264>:	vmovddup (%rdx,%rcx,1),%xmm5
--- Day changed Tue Nov 19 2013
2013-11-19 03:57:24 < Yukikaze> am I kawaii uguu~
2013-11-19 04:05:46 < Yukikaze> sorry about that
2013-11-19 19:31:49 < easyfab> hey b-pyramid is here  :)  now I'm waiting mbtree for some real testing on anime source .
2013-11-19 20:02:39 < easyfab> muggs: just out of curiosity, can you tell me the percentage of time spent in each function in x265. Is it like in x264 ?
2013-11-19 20:02:58 < easyfab> If I'm not mistaken skyler at once established this graph http://i49.tinypic.com/kybr7.jpg
2013-11-19 20:03:51 < easyfab> Is it the same ?
2013-11-19 20:05:40 < Daemon404> use perf?
2013-11-19 20:05:41  * Mandarinka thinks psyrdo will be more important than mbtree
2013-11-19 20:05:57 < Daemon404> doesnt psy rely on mbtree or vice versa
2013-11-19 20:06:21 < Daemon404> wait im thinking of aq.
2013-11-19 20:08:27 < easyfab> Daemon404: I'm on windows or msys  can you give me a tool link for perf ?
2013-11-19 20:08:34 < Mandarinka> mbtree relies on aq perhaps (well duh, it needs non-constatnt qp)
2013-11-19 20:08:52 < Mandarinka> psyrdo was in first anyway
2013-11-19 20:10:10 < Daemon404> easyfab, no
2013-11-19 20:10:12 < Daemon404> perf is linux only.
2013-11-19 20:10:30 < Daemon404> Mandarinka, "in"
2013-11-19 20:10:37 < Daemon404> haali's aq predates psyrd massively
2013-11-19 20:10:39 < Daemon404> ;)
2013-11-19 20:10:55 < Mandarinka> vaq predates it too
2013-11-19 20:11:04 < Mandarinka> I mean that psyrdo was in befor embtree
2013-11-19 20:11:23 < Daemon404> o
2013-11-19 20:11:39 < Mandarinka> I was refering to yours <Daemon404> doesnt psy rely on mbtree or vice versa
2013-11-19 20:12:46 < easyfab> For anime I remember that mbtree give a nice quality  increased for the same bitrate
2013-11-19 20:12:49 < Paranoialmaniac> fgoﾏﾀﾞｰ？
2013-11-19 20:12:52 < Daemon404> easyfab, no...
2013-11-19 20:12:53 < Daemon404> it did not
2013-11-19 20:13:08 < Daemon404> early on it absoltely estroyed hgh action scenes
2013-11-19 20:13:14 < Daemon404> in anime
2013-11-19 20:13:19 < Daemon404> still does if you dont tune it down
2013-11-19 20:27:27 < Mandarinka> it probably has a more positive effect on low bitrates
2013-11-19 20:27:33 < Mandarinka> but low bitrates suck anyway
2013-11-19 20:29:05 <@muggs> x265 will have similar profiles but it's pretty hard to summarize performance that way - every preset is different
2013-11-19 20:34:28 <@muggs> on Windows, there's a free profiler called "Very Sleepy" that is decent - you just need to build x265 with "RelWithDebInfo" so it can resolve addresses
2013-11-19 20:35:21 <@muggs> http://www.codersnotes.com/sleepy/
2013-11-19 20:38:21 < nevcairiel> i used intels profiler in the past, but of course its not free
2013-11-19 20:38:45 <@muggs> Very Sleepy is GPL
2013-11-19 20:40:45 <@muggs> VBV work is in the early stages, we're starting with ixda's patch.  mb-tree will get started soon, perhaps december
2013-11-19 20:43:16 < easyfab> Thank muggs will try very sleepy
--- Day changed Wed Nov 20 2013
--- Day changed Thu Nov 21 2013
--- Day changed Fri Nov 22 2013
2013-11-22 10:16:54 < ubitux> +cglobal pixel_add_ps_%1x%2, 6, 7, 4, dest, destride, src0, scr1, srcStride0, srcStride1 ← why are you defining the arguments and not use them in the following asm?
2013-11-22 18:26:04 < Bercik> Hello
2013-11-22 18:59:22 < muggs> the amount of intrinsic code left is down to about half.. shrinks each day
2013-11-22 19:00:58 < Daemon404> \o/
2013-11-22 19:01:13 < Daemon404> o i started an encode days ago
2013-11-22 19:01:15 < Daemon404> i should check it
--- Day changed Sat Nov 23 2013
--- Day changed Sun Nov 24 2013
--- Day changed Mon Nov 25 2013
2013-11-25 15:12:03 < Daemon404> segfault 3000 frames in
2013-11-25 15:12:04 < Daemon404> meh
2013-11-25 15:12:21 < nevcairiel> i hope you report these crashes!
2013-11-25 15:12:43 < Daemon404> i never had useful info
2013-11-25 15:12:55 < Daemon404> maybe i should just run every encode under gdb
2013-11-25 15:12:58 < Daemon404> since they always crash
2013-11-25 15:13:10 < nevcairiel> guess nix cant be configured to spit out a crash dump on a crash?
2013-11-25 15:13:19 < JEEB> it can, but no-one generally sets that
2013-11-25 15:13:39 < nevcairiel> callstack would probably be plenty for many things
2013-11-25 15:38:47 < j-b> good morning
2013-11-25 17:45:06 < smarter> Daemon404: you don't need to run it under gdb if you have a core dump
2013-11-25 20:15:24 < easyfab> I did a quick test to give me an idea of x265 performances vs x264 at about the same speed/bitrate : http://pastebin.com/A1mtnJNe
2013-11-25 20:16:47 < easyfab> really good for a so young projet, with mbtree, psy-rd ... x265 will become a killer :)
2013-11-25 20:19:08 < JEEB> hint for the next time
2013-11-25 20:19:31 < JEEB> use crf with x265 to get a non-ABR encode done and to get the target rate
2013-11-25 20:19:47 < JEEB> and then use similar means or 2pass VBR with x264 to encode the H.264 one
2013-11-25 20:20:16 < smarter> if you want to compare psnr or ssim scores you should use "--tune psnr" or "--tune ssim"
2013-11-25 20:20:25 < JEEB> and yes
2013-11-25 20:21:26 < nevcairiel> last i heard these options are still NOPs for x265
2013-11-25 20:21:35 < smarter> but not for x264 :)
2013-11-25 20:21:40 < easyfab> I don't use --tune psnr or ssim because it's not really ok in x265 for the moment ( aq-mode sucks for me for example)
2013-11-25 20:22:00 < smarter> well, x265 has aq-mode but I don't know if it's turned on by default and correctly turned off by --tune psn
2013-11-25 20:22:16 < JEEB> well, you could say that x265 tunes for SSIM when you have AQ enabled and for PSNR when you have it off
2013-11-25 20:22:40 < smarter> depends if aq actually works or if it does terrible thingw
2013-11-25 20:22:45 < JEEB> true
2013-11-25 20:23:32 < easyfab> IIRC for x265 default = --tune psnr and --tune ssim activate aq-mode 1
2013-11-25 20:36:18 < BugMaster> as minimum when you compare PSNR or SSIM you need to disable PsyRD (--psy-rd 0) if you don't want to optimize to any specific metric
2013-11-25 20:36:32 < BugMaster> *for x264
2013-11-25 20:38:20 < smarter> --no-psy even I think
2013-11-25 20:39:31 < BugMaster> --no-psy is ok but I usually don't use it because it don't represent how ratecontrol will be for real encode
2013-11-25 20:41:11 < BugMaster> and that was options minimum (--psy-rd 0 is part of --no-psy)
2013-11-25 20:42:20 < easyfab> If I set --tune psnr  in X264 is it ok to compare the psnr x264 vs x265 ?
2013-11-25 20:43:50 < BugMaster> it should be ok. but for the note disabling AQ (part of what ---tune psnr do) is not always give better PSNR result (sometimes it backfires)
2013-11-25 20:44:11 < smarter> BugMaster: do you know of any clip where PSNR gets better with AQ disabled?
2013-11-25 20:44:18 < smarter> *enabled
2013-11-25 20:44:19 < smarter> sorry
2013-11-25 20:44:58 < BugMaster> I remember the was some but I can't say which one that was
2013-11-25 20:45:41 < smarter> easyfab: yes, but note that cross-encoder PSNR comparaisons are not always good (e.g., if one encoder output is a lot more blurry than the other)
2013-11-25 20:50:23 < easyfab> For me it's not really to know wich is the better by 2 or 3 % but to have an idea of HEVC potential vs AVC and to follow x265 progress
2013-11-25 21:56:36 < muggs> yeah, our AQ still has problems; and the mode decision code still makes choices based on SSD even when AQ is enabled
2013-11-25 21:57:16 < muggs> the latter likely causes most of the former
2013-11-25 21:57:36 <@Skyler_> is that bad?  x264 uses SSD with AQ too
2013-11-25 21:58:23 < muggs> Hi Skyler_, you're the guy I need to talk to; we have a lot of confusion about how this actually works in x264
2013-11-25 21:58:51 <@Skyler_> 1) adjust QPs by C * log2(variance)
2013-11-25 21:59:02 <@Skyler_> 2) lambda is derived from QP, so this changes the lambda
2013-11-25 21:59:04 <@Skyler_> that should be sufficient?
2013-11-25 21:59:08 <@Skyler_> is there some problem beyond that?
2013-11-25 21:59:46 < muggs> this is essentially what we do at the 64x64 block level; currently looking at doing it at various split levels as well
2013-11-25 21:59:51 <@Skyler_> I guess there's the problem of choosing CU size (or whatever level the delta quants are coded at?)
2013-11-25 21:59:59 <@Skyler_> okay so for that
2013-11-25 22:00:36 <@Skyler_> you could have a QP for the overall 64x64 block, and then offsets for each minimum-size unit (I guess 8x8 or 16x16?) from that QP
2013-11-25 22:00:40 <@Skyler_> then
2013-11-25 22:00:46 <@Skyler_> when you do RD on that block to decide split modes
2013-11-25 22:00:54 <@Skyler_> apply offsets to the distortion measurement for each minimum size block based on those offsets
2013-11-25 22:01:17 < muggs> what does --tune psnr do to x264; if SSD is used for mode decisions?
2013-11-25 22:01:18 <@Skyler_> this will RD-wise reward you for getting the lambda right for those blocks, so it will bias towards smaller splits where the QP varies a lot within the 64x64 block
2013-11-25 22:01:24 <@Skyler_> it just means AQ is off.
2013-11-25 22:01:40 < muggs> oh
2013-11-25 22:02:16 < muggs> does --tune ssim turn anything on/off?
2013-11-25 22:02:25 <@Skyler_> it turns AQ on.
2013-11-25 22:02:33 <@Skyler_> and psy-rd/etc off
2013-11-25 22:02:37 <@Skyler_> (which are also off with psnr)
2013-11-25 22:03:03 < muggs> should enabling AQ improve SSIM scores?  that's what we're fighting with right now; it often makes it worse
2013-11-25 22:03:08 <@Skyler_> yes, it should, always
2013-11-25 22:03:32 <@Skyler_> I've almost never seen a source that didn't benefit significantly from AQ
2013-11-25 22:03:38 <@Skyler_> are you forgetting to adjust lambda or something?
2013-11-25 22:03:51 <@Skyler_> if you think the problem is splits, have you tried just forcing splits and comparing in order to match x264's behavior?
2013-11-25 22:04:46 < muggs> we probably are not updating lambda - that's a good place to start
2013-11-25 22:05:11 <@Skyler_> the point of AQ is to adjust lambda
2013-11-25 22:05:18 <@Skyler_> quantizer just generally goes along with it
2013-11-25 22:05:19 < smarter> muggs: try to get increased SSIM with parkjoy first, it should be easier than most clips
2013-11-25 22:05:49 < muggs> smarter: thanks, that's helpful.
2013-11-25 22:06:03 < smarter> you should be able to see the improvements visually too
2013-11-25 22:06:57 < muggs> right
2013-11-25 22:07:59 < smarter> muggs: instead of using the average delta-qp of the subblocks, try using the basic formula on your whole block for 32x32 and 64x64 blocks, in VP9 it worked better
2013-11-25 22:08:22 < muggs> Skyler_: back to residual cost measurements:  satd is used to select best intra and intra, then ssd is used to pick intra/inter/split/skip?
2013-11-25 22:08:32 < smarter> I didn't managed to get the weighted distortion approach to work, but I'm going to try again
2013-11-25 22:08:35 < smarter> *manage
2013-11-25 22:09:09 <@Skyler_> muggs: erm... not quite
2013-11-25 22:09:13 <@Skyler_> SSD isn't used to pick anything
2013-11-25 22:09:25 <@Skyler_> there are 3 metrics: SAD, SATD, RD  (you could pick other metrics if you wanted)
2013-11-25 22:09:29 <@Skyler_> SAD is the worst, SATD is better, RD is best
2013-11-25 22:09:48 <@Skyler_> which ones you use where will depend what your performance settings are, but typically you use SAD  and/or SATD to narrow down modes and RD to pick the best
2013-11-25 22:10:31 <@Skyler_> so in x264, SAD is used for fullpel, SATD for subpel/intra, then either SATD or RD for picking between final modes
2013-11-25 22:10:37 <@Skyler_> but how you design that hierarchy is your choice
2013-11-25 22:10:43 <@Skyler_> RD = SSD + bits * lambda
2013-11-25 22:10:49 <@Skyler_> SSD alone as a metric is totally useless.
2013-11-25 22:10:58 <@Skyler_> (well, bits * lambda^2)
2013-11-25 22:11:51 < smarter> Skyler_: by the way, would taking the sum of the differences of the unquantized and quantized transform coefficients instead of SATD work for psy-rd? Or is there something magic about the Hadamard Transform beside the fact that it's cheap and similar to a DCT?
2013-11-25 22:12:15 <@Skyler_> the problem with that isn't the transform
2013-11-25 22:12:29 <@Skyler_> it's because psy-rd is about the energy of the reconstructed signal
2013-11-25 22:12:31 <@Skyler_> not the quantized signal
2013-11-25 22:12:41 <@Skyler_> so merely counting up the energy of the quantized (residual) coefficients isn't enough.
2013-11-25 22:12:55 <@Skyler_> reconstructed = quantized + prediction, so you'd need to add the transform of the prediction too.
2013-11-25 22:13:29 < muggs> that's where my confusion comes from: when I think RD I think bit counting CABAC.  so cheap RD is SSD + bits*lambda
2013-11-25 22:13:32 <@Skyler_> psy-rd isn't very smart though; you could probaly make it a lot better by e.g. weighting the coefficients.
2013-11-25 22:13:38 < smarter> Skyler_: yeah but you're doing (quantized + prediction) - (unquantized + prediction) = quantized - unquantized, no?
2013-11-25 22:13:41 <@Skyler_> muggs: how is that "cheap RD"?
2013-11-25 22:13:49 <@Skyler_> "bit counting CABAC" is RD.
2013-11-25 22:13:53 < muggs> cheaper than counting bits
2013-11-25 22:14:03 <@Skyler_> ... but... SSD + bits * lambda involves counting bits.
2013-11-25 22:14:07 <@Skyler_> how can you calculate that if you don't know what bits is.
2013-11-25 22:15:00 <@Skyler_> smarter: I... I think that's wrong because of signs?
2013-11-25 22:15:03 < muggs> the bits in that equation is just signaling bits, no? not the coded residual coeff
2013-11-25 22:15:10 <@Skyler_> muggs: no, it's the total bits of the block
2013-11-25 22:15:21 <@Skyler_> RD = (total bits of that block) * lambda^2 + (total SSD of the block)
2013-11-25 22:15:39 <@Skyler_> when calculating the cost of modes you MUST measure ALL the bits.  this means either a bit-counting metric (e.g. SATD) or actual bits.
2013-11-25 22:15:42 <@Skyler_> SSD is *NOT* a bit-counting metric.
2013-11-25 22:15:52 <@Skyler_> SSD is a *distortion* metric, and can only be used to measure distortion.
2013-11-25 22:16:06 <@Skyler_> if you're not counting all the bits, you're not doing RD, you're doing smoething else.
2013-11-25 22:16:14 <@Skyler_> smarter: okay so um.  maybe an example
2013-11-25 22:17:38 <@Skyler_> source coeff: "4.5".  predicted coefficient: "2.8".  residual: "-1.7".  quantized residual: "-1".  reconstructed coeff: "3.5"
2013-11-25 22:18:49 <@Skyler_> according to your formula, the residual has 0.7 less energy than perfect matching.
2013-11-25 22:19:01 <@Skyler_> according to my formula, the residual has 0.7 more energy than perfect matching.
2013-11-25 22:19:12 <@Skyler_> I... I hope that makes sense?
2013-11-25 22:19:17 <@Skyler_> unless I got that wrong
2013-11-25 22:19:35 <@Skyler_> or um.  oops I probably swapped something there
2013-11-25 22:19:49 <@Skyler_> but basically it's a sign issue I think?
2013-11-25 22:19:57 <@Skyler_> an absolute-larger residual can decrease the reconstructed residual.
2013-11-25 22:20:05 <@Skyler_> and an absolute-smaller residual can increase the reconstructed residual.
2013-11-25 22:21:04 < smarter> now I'm confused :p
2013-11-25 22:21:08 <@Skyler_> okay um.  let me try again
2013-11-25 22:21:46 <@Skyler_> if the prediction has a larger absolute magnitude than the source pixels for a given coefficient, the residual will be moving that coefficient towards zero.
2013-11-25 22:21:59 <@Skyler_> this means if we make our coefficient smaller, we increase the energy, paradoxically
2013-11-25 22:22:06 <@Skyler_> and if we make our coefficient bigger, we decrease the energy
2013-11-25 22:22:13 < smarter> oooh
2013-11-25 22:22:54 <@Skyler_> so basically it's abs(abs(prediction + unquantized) - abs(prediction + quantized))
2013-11-25 22:23:01 <@Skyler_> so you can't reorder things outside the abs().
2013-11-25 22:23:47 <@Skyler_> so psy-rd/trellis are in part about "we want to take advantage of large coefficients in the prediction and not make them smaller, because that gives us free energy"
2013-11-25 22:24:01 <@Skyler_> because we want to retain energy as best as we can in the cheapest possible way
2013-11-25 22:24:09 <@Skyler_> in practice this means Inter Is Good because it generates a lot of energy.
2013-11-25 22:24:29 < smarter> that totally makes sense, thanks!
2013-11-25 22:24:31 <@Skyler_> yay
2013-11-25 22:24:51 <@Skyler_> psy-rd is, I should warn you, a very very cheap hack; it's overly strong and (obviously) doesn't do any actual coefficient optimization
2013-11-25 22:24:57 <@Skyler_> so it's largely just a way of picking The Good Mode
2013-11-25 22:25:20 < smarter> I was wondering if psy-rd would make sense for vp9 and there, the ssd is computed using the transformed coefficients, that's why I was wondering about that :)
2013-11-25 22:25:38 <@Skyler_> yeah, you have to calculate it on reconstructed data.  the xvid-style (I think) SSD shortcut doesn't work.
2013-11-25 22:25:42 < smarter> you mentioned weighting the coefficients, what weighting would you use?
2013-11-25 22:25:46 <@Skyler_> I have absolutely no idea
2013-11-25 22:25:55 <@Skyler_> I guess I would weight higher energy as more important.
2013-11-25 22:25:58 <@Skyler_> er, higher-frequency energy
2013-11-25 22:26:00 < smarter> I could try transforming the prediction too :]
2013-11-25 22:26:11 <@Skyler_> I would say transforming the prediction is probably slower.
2013-11-25 22:26:49 <@Skyler_> basically, everything psy-* is a total hack and really should be unified into some nice general concept, but it's hard to get a good balance where you optimize for energy while not making things look totally awful sometimes.
2013-11-25 22:27:06 <@Skyler_> maybe you could do something with splitting energy between bands or rewarding energy that's "close to" the right area of the dct block or I don't know
2013-11-25 22:27:07 < smarter> I'm surprised there doesn't seem to be any published research on the subject
2013-11-25 22:27:16 <@Skyler_> I think it's very much an audio thing
2013-11-25 22:27:20 <@Skyler_> I stole the idea from CELT/vorbis
2013-11-25 22:27:44 <@Skyler_> Daala is basically, in part, an attempt to do psy-* right by integrating it into the format
2013-11-25 22:28:06 < smarter> yes, the vector quantization seems wicked cool
2013-11-25 22:28:09 < JEEB> yup
2013-11-25 22:28:25 <@Skyler_> all I know is: "I think retaining visual energy seems to make sense, and it often helps keep texture and grain, but I have no idea how to do it without horrid hacks, and every attempt I've made to do it more cleanly or optimize for it more effectively makes things worse"
2013-11-25 22:28:41 <@Skyler_> it feels like I'm kind of on the edge of something more generally useful, but finding that in the infinite phase space of algorithms is hard.
2013-11-25 22:29:22 <@Skyler_> an example of a failure mode: if you optimize coefficients fully for psy-rd (e.g. with QNS), you very often get it bunching all your energy into one coefficient in a rather ugly way
2013-11-25 22:29:30 < smarter> QNS?
2013-11-25 22:29:39 <@Skyler_> greedy coefficient optimization
2013-11-25 22:30:05 <@Skyler_> 1.  quant with trellis    2.  twiddle each coeff up and down by 1  3.  pick the best result from 2) and apply it  4.  goto 2 unless nothing helped, otherwise exit
2013-11-25 22:30:19 <@Skyler_> 3) is done with RD (Whatever Metric You Want + bits * lambda)
2013-11-25 22:30:30 < smarter> I see
2013-11-25 22:30:40 <@Skyler_> it's like N^2*log(N) compared to N-ish for trellis, but trellis only works with SSD.
2013-11-25 22:30:45 <@Skyler_> while this works with Any Metric You Want.
2013-11-25 22:31:06 < smarter> why does trellis only work with SSD?
2013-11-25 22:31:39 <@Skyler_> you can only use trellis on metrics that are a) possible to calculate efficiently in the frequency domain b) do not have interdependency between coefficients in a way that is difficult to track within the trellis
2013-11-25 22:31:55 <@Skyler_> e.g. in x264's CABAC trellis, the CABAC bit cost is simplified slightly to make b) not an issue.
2013-11-25 22:32:02 <@Skyler_> to avoid extra dependencies that force it into exponential time
2013-11-25 22:32:19 <@Skyler_> this is also why CAVLC trellis is very difficult (I don't know if it's been done, it's been done in one paper but they ignored one of the 5 syntax elements to make it work)
2013-11-25 22:32:40 <@Skyler_> equally it means if your quality metric depends on *all* coefficients *simultaneously*, the linearization of trellis no longer works because coefficients aren't independent.
2013-11-25 22:32:57 <@Skyler_> it's probably possibe to hack a trellis that tracks frequency-domain energy totals
2013-11-25 22:33:04 < smarter> interesting
2013-11-25 22:33:17 <@Skyler_> but if you likee xperimentation, QNS is probably easier because it is super easy to modify your metric
2013-11-25 22:33:23 <@Skyler_> instead of having to spend weeks designing an algorithm to make it work
2013-11-25 22:33:33 < smarter> I was wondering if there was any deep reason why VP9 trellis doesn't seem to help as much as x264 trellis (only ~2% on PSNR I think)
2013-11-25 22:33:48 <@Skyler_> does VP9 have that weird thing where they have a quantization algorithm that biases towards larger zero runs and stuff?
2013-11-25 22:33:55 <@Skyler_> I remember VP8 had a Thing that was halfway between regular quant and trellis
2013-11-25 22:34:01 < smarter> what does QNS stands for?
2013-11-25 22:34:02 <@Skyler_> like, I mean, the non-trellis one.
2013-11-25 22:34:05 <@Skyler_> Quantization Noise Shaping
2013-11-25 22:34:18 <@Skyler_> libavcodec has it as a (very) slow option to optimize for hiding error in places with high variance
2013-11-25 22:34:21 <@Skyler_> on the dct block level
2013-11-25 22:34:28 < smarter> cool, will take a look
2013-11-25 22:34:32 <@Skyler_> i.e. the metric is basically SSD-weighted-by-local-variance
2013-11-25 22:34:48 <@Skyler_> it's heavily optimized for this though, and not as generally written (since it's /even slower/) if written naively
2013-11-25 22:34:59 <@Skyler_> CAVLC trellis in x264 is kind of a QNS, just optimized and shortcutted a lot.
2013-11-25 22:35:06 <@Skyler_> (it's really not a trellis at all)
2013-11-25 22:36:45 < smarter> I haven't really tried to understand the VP9 trellis stuff, it did not look simple :)
2013-11-25 22:37:21 <@Skyler_> trellis was literally the last thing in x264 I understood, it's kind of difficult especially if you're not familliar with viterbi stuff
2013-11-25 22:37:29 <@Skyler_> I recommend not touching it as long as you can <.<
2013-11-25 22:37:38 < muggs> lol
2013-11-25 22:38:12 <@Skyler_> so my guess above was "VP9 trellis doesn't help as much because their 'regular quant' isn't super fast SIMD quant but rather a slightly smarter thing"
2013-11-25 22:38:21 < muggs> it's looming on my horizon
2013-11-25 22:41:52 < smarter> Skyler_: VP9 quantization step seems normal to me, there's just a somewhat adaptive deadzone: https://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/encoder/vp9_quantize.c;h=d24be96f64fa35841bdd1049078bc2662fb5ecf5;hb=refs/heads/master#l25
2013-11-25 22:42:46 < smarter> the interesting thing about VP9 quantization is that there's 255 different values instead of 64 in VP8 (I think?) and 53 in H.264/HEVC
2013-11-25 22:43:03 <@Skyler_> that's not normal, that's the whole zbin thing
2013-11-25 22:43:07 <@Skyler_> that's way more complicataed than x264 quant
2013-11-25 22:44:08 < smarter> what's wrong with zbin?
2013-11-25 22:45:15 < smarter> or do you mean that zbin helps so trellis doesn't help as much anymore?
2013-11-25 22:45:32 <@Skyler_> yes.  I mean that their quant is better than a normal quant
2013-11-25 22:45:39 <@Skyler_> therefore, the delta between that and trellis is less.
2013-11-25 22:45:45 <@Skyler_> yeah
2013-11-25 22:45:48 < smarter> okay :)
2013-11-25 22:48:53 < smarter> do you see any way of doing/faking a weighted distortion (like weighting each subblock depending on its variance) without transforming back the transform coefficients?
2013-11-25 22:49:52 < smarter> I guess there's the stuff Daala is trying for merging/splitting transform coefficient blocks (https://people.xiph.org/~xiphmont/demo/daala/demo3.shtml) but that's probably not worth it
2013-11-25 22:51:05 <@Skyler_> I don't think there is
2013-11-25 22:54:28 < smarter> I guess a more effective use of my time would be to try to use SATD in VP9 :)
2013-11-25 22:54:45 < smarter> I wonder how much of a performance difference it would make (compared to full RD everywhere)
2013-11-25 22:57:23 < smarter> anyway, thanks for all the tips!
2013-11-25 22:57:27 < smarter> you should write a book some day :p
--- Day changed Tue Nov 26 2013
2013-11-26 07:13:35 < nandaku2> @Skyler:
2013-11-26 07:13:51 < nandaku2> found the discussion on metrics for mode decision very interesting
2013-11-26 07:14:21 < nandaku2> so what happens for intra in inter MBs?
2013-11-26 07:14:42 < nandaku2> If a full CABAC encode and generate-recon is not done
2013-11-26 08:00:29 <@Skyler_> nandaku2: what do you mean, what happens?
2013-11-26 08:01:48 < nandaku2> the recon is not available for intra prediction
2013-11-26 08:02:18 < nandaku2> within a CU,
2013-11-26 08:11:18 <@Skyler_> nandaku2: why not?
2013-11-26 08:14:09 <@Skyler_> if you're intra-encoding a block, the previous ones in raster order should already be encoded, right?
2013-11-26 08:15:07 <@Skyler_> 19:09 <@Skyler_> nandaku2: why not?
2013-11-26 08:15:07 <@Skyler_> 19:12 <@Skyler_> if you're intra-encoding a block, the previous ones in raster order should already be encoded, right?
2013-11-26 08:15:33 < nandaku2_> So the way it works in x265 currently is
2013-11-26 08:16:04 < nandaku2_> the mode decision algorithm recurses over depth (larger to smaller blocks)
2013-11-26 08:16:20 < nandaku2_> at each depth, the best mode among inter, intra and merge is chosen
2013-11-26 08:16:39 < nandaku2_> and then compared with all possible combinations of split modes
2013-11-26 08:16:51 <@Skyler_> what's 'merge'?
2013-11-26 08:17:08 <@Skyler_> I can see a block having possible modes: inter, intra, and split into some smaller set of modes (like a quadtree, right?)
2013-11-26 08:17:12 < nandaku2_> merge is a fancier version of skip from h.264
2013-11-26 08:17:16 <@Skyler_> okay
2013-11-26 08:17:35 < nandaku2_> yes, it IS a quadtree
2013-11-26 08:17:42 <@Skyler_> okay
2013-11-26 08:17:56 < nandaku2_> so currently, we have a full encode at each depth
2013-11-26 08:18:12 <@Skyler_> okay so basically
2013-11-26 08:18:18 < nandaku2_> and the RDcost is used to compute across depths
2013-11-26 08:18:26 <@Skyler_> first we decide whether to use 64x64, or split into 32x32s, right?
2013-11-26 08:18:32 <@Skyler_> or what's the max size
2013-11-26 08:22:19 < nandaku2_> No, we compute RD-cost recursively at each depth starting with the largest, and then as we exit the recursive loop, we choose which split mode has the best cost
2013-11-26 08:22:56 <@Skyler_> yes I know, so in other words
2013-11-26 08:23:01 <@Skyler_> we test 64x64 first, and SPLIT
2013-11-26 08:23:07 <@Skyler_> split is 32x32
2013-11-26 08:23:15 <@Skyler_> when calculating 32x32, we check whether to do 32x32, or split
2013-11-26 08:23:21 <@Skyler_> when calculating 16x16, wwe choose whether to do 16x16 or split
2013-11-26 08:23:24 <@Skyler_> and so on, right?
2013-11-26 08:23:32 <@Skyler_> so it's recursive.
2013-11-26 08:23:52 < nandaku2_> we test 64x64 first, calc best RD-cost, and split.
2013-11-26 08:23:57 <@Skyler_> yes
2013-11-26 08:24:12 < nandaku2_> so on, until 8x8, best RDcost is calculated. Then we exit the last depth,
2013-11-26 08:24:35 < nandaku2_> compare 8x8 cost with 16x16cost, choose the best, then exit
2013-11-26 08:24:41 <@Skyler_> yes, that's what I meant
2013-11-26 08:24:49 <@Skyler_> so, suppose we are calculating 32x32's cost.
2013-11-26 08:24:49 < nandaku2_> yeah..
2013-11-26 08:24:59 <@Skyler_> this consists of going through each 32x32, calculating its cost, and summing up the 4 squares.
2013-11-26 08:25:05 < nandaku2_> yup
2013-11-26 08:25:08 <@Skyler_> "calculating its cost" is a recursive thing, but let's ignore that for now
2013-11-26 08:25:16 < nandaku2_> right on
2013-11-26 08:25:22 <@Skyler_> so, first we do the first 32x32, and calculate The Best Mode for that 32x32 block (which might be split into a billion smaller htings, whatever)
2013-11-26 08:25:26 <@Skyler_> then, we encode That Best Mode.
2013-11-26 08:25:35 <@Skyler_> now, when we encode the second 32x32, we can predict from it, because the best mode was encoded.
2013-11-26 08:25:36 < nandaku2_> yes
2013-11-26 08:25:45 <@Skyler_> this means we don't have to encode any modes other than the best one.
2013-11-26 08:25:58 <@Skyler_> because if it wasn't the best, it wouldn't be picked, so we wouldn't have to encode it in order to predict from it.
2013-11-26 08:26:11 <@Skyler_> this assumes that all possible combinations of 4 quadtree modes can be independently chosen, but I'm guessing that's probably okay
2013-11-26 08:26:21 <@Skyler_> or well, chosen in order
2013-11-26 08:27:13 <@Skyler_> this effectively means we do one "full CU encode" (amortized) per split level analysed, instead of per mode.
2013-11-26 08:28:04 <@Skyler_> I'm guessing this can probably be chosen for speed; e.g. if this turns out to be really bad you can use source pixels for intra analysis, but I find that icky.
2013-11-26 08:28:20 < nandaku2_> Yes - so actually we dont have a "final" encode stage for that CU, because its already been encoded
2013-11-26 08:28:26 <@Skyler_> that makes esnse.
2013-11-26 08:28:29 < nandaku2_> but
2013-11-26 08:29:33 < nandaku2_> we now need to do atleast 2 full encodes at each depth (encoding modes that arnt really the final best mode)
2013-11-26 08:29:58 <@Skyler_> why 2?
2013-11-26 08:30:27 < nandaku2_> intra and inter
2013-11-26 08:30:33 <@Skyler_> why not only the best mode?
2013-11-26 08:30:52 < nandaku2_> suppose I'm processing second block of 8x8 (raster)
2013-11-26 08:31:05 < nandaku2_> it needs the first block of 8x8 to be encoded
2013-11-26 08:31:11 <@Skyler_> yup
2013-11-26 08:31:50 < nandaku2_> extrapolate - all 8x8 split modes have been encoded. However, I may very well decide that 8x8 is not the best mode and choose inter16x16 or whatever
2013-11-26 08:32:04 < nandaku2_> when I exit that depth
2013-11-26 08:32:10 <@Skyler_> yes.
2013-11-26 08:33:09 <@Skyler_> that means you do one full encode at depth 8x8, whether or not you chooe 8x8
2013-11-26 08:33:11 <@Skyler_> *choose
2013-11-26 08:33:13 <@Skyler_> so one encode per depth
2013-11-26 08:33:37 <@Skyler_> unless I'm missing something?
2013-11-26 08:34:50 < nandaku2_> right. we currently have 3 encodes per depth (intra, inter and merge), but we're gonna replace this with one encode per depth (using satd to choose)
2013-11-26 08:35:14 < nandaku2_> But, is there any way to avoid this one encode per depth - and just have one encode per CU for the best mode
2013-11-26 08:35:30 <@Skyler_> simplest idea:
2013-11-26 08:36:40 <@Skyler_> slowest mode: always RD    slow mode: like you said, except once the split depth is picked, RD all the modes   medium mode: like you said    fast mode: use source pixels for intra analysis (?)
2013-11-26 08:36:53 <@Skyler_> well, okay, more precise:
2013-11-26 08:37:10 <@Skyler_> medium mode: like you said   fast mode: encode, but don't RD (like what x264 does)  fastest mode: use source pixels?
2013-11-26 08:37:32 <@Skyler_> for intra analysis, x264 encodes each block to predict the next, but doesn't do RD
2013-11-26 08:38:03 <@Skyler_> which is sort of an in-between?  I mean obviously this is a lot worse in h265 because you can't skip intra modes as much for the whole mb and it's all quadtreeish
2013-11-26 08:39:26 < nandaku2_> okay.
2013-11-26 08:39:39 <@Skyler_> I'm not sure how that tradeoff will be in x265
2013-11-26 08:40:11 <@Skyler_> in x264 see e.g.
2013-11-26 08:40:11 <@Skyler_>             /* we need to encode this block now (for next ones) */
2013-11-26 08:40:12 <@Skyler_>             x264_mb_encode_i8x8( h, 0, idx, a->i_qp, a->i_predict8x8[idx], edge, 0 );
2013-11-26 08:40:16 < nandaku2_> so we dont have a good understanding of the performance implications - for instance, whats the gap between encode+RD versus encode only
2013-11-26 08:40:40 <@Skyler_> it should be significantly better; no CABAC, I suppose
2013-11-26 08:41:02 < nandaku2_> by encode, you mean CABAC, right?
2013-11-26 08:41:09 < nandaku2_> meant*
2013-11-26 08:41:14 <@Skyler_> by encode I mean macroblock_encode in x264, e.g. predict, fdct, quant, dequant, idct
2013-11-26 08:41:33 < nandaku2_> ah
2013-11-26 08:41:51 <@Skyler_> I admit x264's solution might not be the best; iirc the encoding now (with heavily optimized prediction analysis) takes /longer/ than the actual prediction analysis
2013-11-26 08:41:58 <@Skyler_> e.g. we can check 9 modes' SATD faster than encoding one block
2013-11-26 08:42:01 <@Skyler_> faster/similar speed
2013-11-26 08:42:44 <@Skyler_> albeit this is more an artifact of insanely fast analysis routines (e.g. like 100 cycles for 9x 4x4)
2013-11-26 08:43:02 <@Skyler_> in h265 it might not be as bad then again, since you have a lot more intra modes, but I'm not sure if you exhaustively check those
2013-11-26 08:43:27 < nandaku2_> hmm, yes, we do
2013-11-26 08:44:05 <@Skyler_> gosh, that sounds nightmarish
2013-11-26 08:44:40 < nandaku2_> intra is a big chunk of our cycles, yes. we do satd to narrow down to few modes
2013-11-26 08:44:51 < nandaku2_> then RD to pick the best one
2013-11-26 08:47:05 < nandaku2_> going back to the fast mode suggestion you had
2013-11-26 08:47:48 < nandaku2_> you mean, use satd(orig, recon) + lambda*(mv+signalbits) for mode decision
2013-11-26 08:48:09 < nandaku2_> across depths
2013-11-26 08:49:59 <@Skyler_> yeah, I guess, an equivalent would be
2013-11-26 08:50:16 <@Skyler_> "fast mode" == subme between 2 and 5 in x264 (no RD anywhere, use SATD to pick the best mode, encode as needed for intra but don't RD)
2013-11-26 08:50:28 <@Skyler_> "super fast mode" == subme 1, same as above but with SAD instead of SATD
2013-11-26 08:51:04 <@Skyler_> "medium mode" == SATD the best split, then thresholded-RD the best mode (maybe?  I'm not sure whether it's best to RD the split and SATD the mode or RD the mode and SATD the split)
2013-11-26 08:52:16 < nandaku2_> ok, thanks a lot for all the suggestions. There's some experimenting we need to do here
2013-11-26 08:52:44 <@Skyler_> how is transform size related to prediction size, by the way?  can you use any transform size with any prediction size for inter and intra?
2013-11-26 18:23:46 < kurosu> Skyler_: (your question didn't seem to get an answer) There is another quadtree to specify when to use smaller transforms
2013-11-26 18:24:35 < kurosu> iirc it takes into account the rule that a transform block should not overlap 2 partitions
2013-11-26 18:25:35 < kurosu> maximum transform size is 32x32, smallest 4x4 (no hadamard)
--- Day changed Wed Nov 27 2013
2013-11-27 00:43:26 < nandaku2> @Skyler: sorry got logged out, but you got your answer on transforms...
--- Day changed Thu Nov 28 2013
--- Day changed Fri Nov 29 2013
--- Day changed Sat Nov 30 2013
2013-11-30 13:13:51 < Rodeo> any chance Zhang Zhiqiang (or a colleague) is here?
--- Day changed Sun Dec 01 2013
--- Day changed Mon Dec 02 2013
--- Day changed Tue Dec 03 2013
2013-12-03 15:40:57 < JEEB> do variable length GOPs work yet? I see the keyint min and max being set to the same value
2013-12-03 15:41:27 < JEEB> as in, would it be OK to set min to a similar value as with, say, x265
2013-12-03 15:41:29 < JEEB> *x264
2013-12-03 17:32:46 < JEEB> do I understand it right that the pdb that is output with RelWithDebInfo is for the DLL, not the exe?
2013-12-03 17:32:52 < JEEB> :D
--- Day changed Wed Dec 04 2013
2013-12-04 09:25:54 < JEEB> did some encodes yesterday, and someone was nice enough to create some preliminary graphs http://imgur.com/a/Ijs37
2013-12-04 09:26:38 < JEEB> both at placebo, x265 has AQ on, x264 --tune ssim, x265 encoded first with CRF, and then x264 matched up to it with 2pass
2013-12-04 09:58:48 < smarter> might be worth testing x265 without AQ as I don't think the x265 developers are confident about it yet
2013-12-04 10:03:38 < JEEB> I'll test it like that later
2013-12-04 11:10:17 < koda> JEEB, that looks interesting
2013-12-04 11:14:25 < JEEB> tested an animated clip with rates 467, 801, 1401 kbps (crf 32, 28, 24 accordingly)
2013-12-04 11:14:32 < JEEB> 720p24
2013-12-04 16:11:32 < Daemon404> JEEB, you should probably grav 1/(1 - ssim)
2013-12-04 16:12:14 < koda> Daemon404, why?
2013-12-04 16:13:04 < Daemon404> because in linearizes it
2013-12-04 16:13:09 < Daemon404> the 0-1 range is not linear
2013-12-04 16:13:21 < Daemon404> 0.98 is twice as good as 0.96
2013-12-04 16:13:29 < Daemon404> s/in/it/
2013-12-04 16:14:35 < koda> oh right
2013-12-04 16:14:47 < Daemon404> also
2013-12-04 16:14:48 < Daemon404> fyi
2013-12-04 16:14:49 < Daemon404> https://git.xiph.org/?p=daala.git;a=blob;f=tools/dump_ssim.c;h=3ac54b6fb642cffa76d1514ccd7a612c78eb332a;hb=HEAD
2013-12-04 16:14:57 < Daemon404> is a simple tool with it built in
2013-12-04 16:15:02 < Daemon404> just dont try and read the derfcode
2013-12-04 16:17:42  * koda stops at  /*Yes, yes, we're going to hell.*/
2013-12-04 16:19:17 < Daemon404> standard xiph header i assume.
2013-12-04 16:19:34 < nevcairiel> they have such comments around every #ifdef, apparently the really dont like them
2013-12-04 16:19:59 < Daemon404> i only see it by win32 ifdefs
2013-12-04 16:20:04 < nevcairiel> there is a bigger comment blob a bit later
2013-12-04 16:20:10 < nevcairiel> well maybe arch specific ifdefs then
2013-12-04 16:20:28 < Daemon404> real men use gmp
2013-12-04 16:20:28 < Daemon404> duh
2013-12-04 16:26:12 < JEEBsv> Daemon404: nice
--- Day changed Thu Dec 05 2013
2013-12-05 01:42:00 < nandaku2> Hi! I just wanted to pose a general question. We dont tune for SSIM very well at this point - AQ is still experimental and has many bugs.
2013-12-05 01:42:32 < nandaku2> However, we have integrated CUTree (MBtree ported from x264) and while we're waiting around for AQ to be fixed
2013-12-05 01:42:59 < nandaku2> we tested x265 with CUTree ON and OFF and measured psnr/ssim
2013-12-05 01:43:23 < nandaku2> posting the results here
2013-12-05 01:43:59 < nandaku2> cuTree=1 crf=21 - encoded 100 frames in 58.79s (1.70 fps), 9587.36 kb/s, Global PSNR: 36.850 Global SSIM: 0.909 cuTree=0 crf=21 - encoded 100 frames in 64.58s (1.55 fps), 10145.77 kb/s, Global PSNR: 36.765 Global SSIM: 0.908  cuTree=1 crf=24 - encoded 100 frames in 53.95s (1.85 fps), 5931.34 kb/s, Global PSNR: 36.628 Global SSIM: 0.896 cuTree=0 crf=24 - encoded 100 frames in 50.26s (1.99 fps), 6571.09 kb/s, Global PSNR: 36.299 Global
2013-12-05 01:44:09 < nandaku2> sorry, that didnt come out so well
2013-12-05 01:45:14 < nandaku2> not sure how those results can be posted in a readable form.
2013-12-05 01:45:21 <@Skyler_> I think it's missing \ns?
2013-12-05 01:45:31 < nandaku2> summary, bitrate reduces noticeably.
2013-12-05 01:46:04 < nandaku2> psnr improves (all except one)
2013-12-05 01:46:10 <@Skyler_> note: mbtree was tuned for x264 such that (over a wide range of corpuses, on average) the bitrate remained the same      [this still led to dramatic changes among individual files, of course]
2013-12-05 01:46:16 < nandaku2> ssim reduces in all
2013-12-05 01:46:42 <@Skyler_> SSIM dropping but PSNR increasing feels weird though; in x264, mbtree helped SSIM way more than PSNR
2013-12-05 01:47:02 < nandaku2> @Skyler: you mean in x264, bitrate stayed the same, but ssim/quality increased significantly?
2013-12-05 01:47:34 <@Skyler_> I meant, at the same bitrate
2013-12-05 01:47:49 <@Skyler_> normalized for bitrate, SSIM increased tons, PSNR increased somewhat
2013-12-05 01:48:05 <@Skyler_> (the reason is probably because of the way SSIM is averaged vs the way PSNR is averaged, I think)
2013-12-05 01:49:11 <@Skyler_> an extreme example was on one my touhou clips I think, SSIM increased ~70% or something absurd
2013-12-05 01:50:02 < nandaku2> hmm... have you ever seen anything where ssim and psnr went opposite ways?
2013-12-05 01:50:26 <@Skyler_> AQ is a classic example :p
2013-12-05 01:50:30 <@Skyler_> it ruins PSNR, but helps SSIM
2013-12-05 01:50:55 <@Skyler_> if you mean with mbtree specifically... I don't think so...?
2013-12-05 01:51:00 <@Skyler_> it might relate to whether you use avg psnr or overall psnr
2013-12-05 01:51:44 < nandaku2> whats the difference?
2013-12-05 01:52:13 <@Skyler_> OPSNR treats the whole video as one frame, APSNR averages the PSNR of each frame
2013-12-05 01:52:25 <@Skyler_> OPSNR effectively penalizes you more for lower-quality sections than APSNR does
2013-12-05 01:52:47 < KeithW> Skyler_: Would you mind expanding on that a bit -- how is SSIM averaged? Do you average SSIM on a per-frame basis and optimize for that, or average 1/(1-ssim) and optimize for that, or...?
2013-12-05 01:53:37 <@Skyler_> well, like, SSIM is effectively averaged block by block
2013-12-05 01:54:04 <@Skyler_> like, with PSNR, if you have one small section of a frame that's 10db PSNR, and the rest is 40db PSNR
2013-12-05 01:54:13 <@Skyler_> the 10db section will pull the average down so much
2013-12-05 01:54:32 <@Skyler_> but with SSIM, if you have a section that's 0.6, and the rest is 0.95, it won't have the same level of effect, I think?
2013-12-05 01:54:35 < KeithW> Ah, I see, ok.
2013-12-05 01:54:43 <@Skyler_> this is important because MB-tree often has the effect of making large static sections of a frame way higher quality
2013-12-05 01:54:47 <@Skyler_> or near-static
2013-12-05 01:54:52 < KeithW> I was thinking about the remarks here earlier about how one should graph 1/(1-ssim) instead of just graphing ssim.
2013-12-05 01:54:54 <@Skyler_> which artificially inflates SSIM a whole bunch (more than it inflates PSNR)
2013-12-05 01:55:06 <@Skyler_> yeah, x264 actually prints db for SSIM, I don't know if that's better?
2013-12-05 01:55:31 < KeithW> What does x264 optimize for with --tune ssim? Average ssim, or average 1/(1-ssim), or something else?
2013-12-05 01:56:03 <@Skyler_> I've never seen "average 1/(1-ssim)" used anywhere for anything
2013-12-05 01:56:08 <@Skyler_> but that doesn't mean it's worse
2013-12-05 01:56:20 <@Skyler_> x264 just optimizes for the largest output SSIM (the number in the log)
2013-12-05 02:00:15 <@Skyler_> (example of an SSIM-biased example.... in this touhou clip...
2013-12-05 02:00:21 <@Skyler_> SSIM: 0.944 -> 0.964
2013-12-05 02:00:27 <@Skyler_> PSNR: 32.639 -> 33.576
2013-12-05 02:04:01 < nandaku2> ok - this is consistent, big boosts for SSIM and PSNR. But for AQ you have seen cases where SSIM gets a big boost but psnr drops?
2013-12-05 02:06:25 <@Skyler_> every single case
2013-12-05 02:06:37 <@Skyler_> if AQ raised PSNR in any situation, I would be shocked and assume my code was broken
2013-12-05 02:06:48 <@Skyler_> AQ will almost universally drop PSNR by huge amounts
2013-12-05 02:06:49 < nandaku2> aha
2013-12-05 02:07:20 <@Skyler_> AQ is /basically/ designed to raise SSIM and lower PSNR XD
2013-12-05 02:08:08 <@Skyler_> oh, huh, here's a case of mbtree doing the opposite:  45.109->47.400db PSNR, 0.9876 -> 0.9892 SSIM  (way more PSNR boost than SSIM)
2013-12-05 02:10:54 < nandaku2> and for most AQ testing, it makes sense to use it along with ABR?
2013-12-05 02:11:12 <@Skyler_> I would use 2-pass bitrate and keep the bitrate the same in both passes, or graph RD charts or something similar
2013-12-05 02:11:18 <@Skyler_> you can't compare quality without normalizing for bitrate
2013-12-05 02:12:08 < nandaku2> ok, and the basic understanding here is that AQ improves quality - not reduces bitrate/maybe improve quality as well?
2013-12-05 02:12:22 <@Skyler_> you can't really say either of those
2013-12-05 02:12:26 <@Skyler_> AQ redefines ratecontrol
2013-12-05 02:12:37 <@Skyler_> it includes a term to attempt to normalize the bitrate, but that's only on average over all sources
2013-12-05 02:12:43 <@Skyler_> on some sources it may increase bitrate, on others it may decrease bitrate
2013-12-05 02:12:46 <@Skyler_> (at the same CRF)
2013-12-05 02:12:49 <@Skyler_> this is a *good thing*
2013-12-05 02:12:56 <@Skyler_> because it makes CRF more accurately represent "real quality"
2013-12-05 02:14:03 <@Skyler_> e.g. on video X, AQ might decrease QP in every single macroblock
2013-12-05 02:14:15 <@Skyler_> because video X is all very flat and needs a lower QP for the same effective quality
2013-12-05 02:14:24 <@Skyler_> while on video Y it might increase QP in every macroblock.
2013-12-05 02:14:49 <@Skyler_> possible video Y example: husky.cif
2013-12-05 02:15:45 <@Skyler_> ("every" being a really rough approximation, of course)
2013-12-05 02:17:34 < nandaku2> ok. So does that mean rate-control ie ABR (we dont have 2-pass yet) has a tougher job controlling overflows/underfflows for the specified bitrate if AQ is on?
2013-12-05 02:17:56 <@Skyler_> I... don't see why it would have any harder or easier job?
2013-12-05 02:18:57 < nandaku2> with parallel frames?
2013-12-05 02:19:56 <@Skyler_> I mean, how would AQ affect it?
2013-12-05 02:24:50 < nandaku2> hmm - we've had a lot of trouble there. calls for some revisiting..
2013-12-05 02:27:19 <@Skyler_> I guess maybe AQ changes the relationship between frame base quantizer and bit count?
2013-12-05 02:27:26 <@Skyler_> but I'm not sure AQ makes it harder to prdict, just different?
2013-12-05 02:27:47 <@Skyler_> plus, x264 uses AQ offsets in the lookahead to calculate bit count accurately
2013-12-05 02:27:49 <@Skyler_> so I don't think it matters??
2013-12-05 02:27:58 <@Skyler_> so it should be identical from RC's perspective
2013-12-05 02:28:29  * Skyler_ forgot about that for a moment
2013-12-05 02:28:40 <@Skyler_>         if( h->param.rc.i_aq_mode )
2013-12-05 02:28:41 <@Skyler_>             i_bcost_aq = (i_bcost_aq * fenc->i_inv_qscale_factor[i_mb_xy] + 128) >> 8;
2013-12-05 02:28:45 <@Skyler_> that should make AQ neutral to RC.
2013-12-05 02:29:18 < nandaku2> x265 does the same - AQ offsets in lookahead
2013-12-05 02:30:02 <@Skyler_> that should make it okay if the frame costs are calculated using them ...?
2013-12-05 02:35:27 < nandaku2> hmm - thanks for the discussion! will be back in 90 mins
2013-12-05 02:38:48 <@Skyler_> gosh, and this time I run tests I find a bunch of clips where PSNR increases more than SSIM.
2013-12-05 02:38:54 <@Skyler_> old_town_cross gets >1db from mb-tree
2013-12-05 09:29:53 < j-b> 'morning
2013-12-05 11:25:12 < greenfountain> hi, do you know any quality measurement tools that measure SSIM? I tried the MSU tool - but it doesn't allow HD video inputs in the free version
2013-12-05 11:29:50 < JEEB> there's the tool by the xiph folk in the daala repo
2013-12-05 11:30:36 < JEEB> and then there's the avisynth SSIM filter
2013-12-05 11:36:24 < JEEB> I was going to build the daala tool yesterday but its need of libogg and other stuff kind of turned me off ("let's build this thing later")
2013-12-05 11:36:45 < JEEB> https://git.xiph.org/?p=daala.git;a=blob;f=tools/dump_ssim.c;h=3ac54b6fb642cffa76d1514ccd7a612c78eb332a;hb=HEAD
2013-12-05 11:36:47 < JEEB> this thing
2013-12-05 12:08:26 < greenfountain> thanks
2013-12-05 14:18:34 < di1ettant> hey greenfountain! >>> <greenfountain> hi, do you know any quality measurement tools that measure SSIM? I tried the MSU tool - but it doesn't allow HD video inputs in the free version
2013-12-05 14:19:41 < di1ettant> You can try ancent version of MSU VQMT. It doesn't have source size restrictions
2013-12-05 14:20:15 < JEEB> also I just noticed that xiph tool that Daemon404 linked yesterday is herp and derp to build
2013-12-05 14:20:43 < JEEB> their makefile is created by autoconf yet it lacks any -l, -L, -I flags
2013-12-05 14:20:51 < JEEB> for the tools
2013-12-05 14:21:17 < di1ettant> *ancient
2013-12-05 14:21:41 < di1ettant> http://netload.in/datei4wDZtCrKwi/msu_vmt_noinstall.zip.htm
2013-12-05 14:23:26 < di1ettant> Ver 1.52 of year 2007
2013-12-05 14:24:09 < smarter> there's also tiny_ssim.c hidden in ffmpeg: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/tiny_ssim.c;h=759a84b4208e05cc69f5dedc16a8f02421cea2b3;hb=HEAD
2013-12-05 14:25:27 < JEEB> the xiph tool was nice because it output the non-logarithmic values
2013-12-05 14:25:32 < JEEB> better for graphing
2013-12-05 14:26:20 < JEEB> 10*log10(1/(1-ssim)
2013-12-05 14:26:27 < JEEB> was IIRC the way to get it to non-logarithmic
2013-12-05 16:41:15 < Daemon404> JEEB, :D
--- Day changed Fri Dec 06 2013
2013-12-06 13:50:39 < flying_toaster> hi there
2013-12-06 13:51:30 < flying_toaster> I'm looking for reference YUV sequences (BasketBallDrive, Kimono, and so on). Does anyone know where I can find it ?
2013-12-06 15:05:06 < easyfab> flying_toaster: see here http://ces.itec.kit.edu/~khan/HEVC_resources.htm  but  ftp://hvc:US88Hula@ftp.tnt.uni-hannover.de/testsequences   but the site doesn't seem to work now
2013-12-06 15:21:56 < flying_toaster> easyfab: indeed... my ftp client bothers me with a credentials request
2013-12-06 15:41:52 < BugMaster> what sequences you wanted? look like there is access at least some of them at ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences
2013-12-06 15:44:28 < flying_toaster> hi BugMaster, I'm looking for Park Scene 1080p, Basketball Drive 1080p, Kimono1 1080p, Johnny 720p and Kristen and Sara 720p
2013-12-06 16:02:19 < BugMaster> I have BasketballDrill_832x480_50.zip / Kimono1_1920x1080_24.yuv.zip and ParkScene_1920x1080_24.yuv.zip but I don't remember from which link I downloaded them so can provide them
2013-12-06 16:02:41 < BugMaster> *can't provide them
2013-12-06 16:07:06 < flying_toaster> http://basakoztas.net/hevc-test-sequences/ <= it gives the same URL, and... "If you cannot access it, don’t give up right away. When I tried to access the server, it was on and off all the time." :/
2013-12-06 16:07:21 < flying_toaster> thanks anyway
2013-12-06 16:08:09 < BugMaster> eh. according to logs I downloaded them from ftp://hvc:US88Hula@ftp.tnt.uni-hannover.de/testsequences/ but it doesn't work now (probably acess closed)
2013-12-06 16:10:07 < flying_toaster> are the streams directly in the testsequences folder ? I guess I'll make a script to download them in case ther's a working window during the week-end
2013-12-06 16:11:25 < BugMaster> yes, there were directly in this folder. i.e. ftp://hvc:US88Hula@ftp.tnt.uni-hannover.de/testsequences/Kimono1_1920x1080_24.yuv.zip or ftp://hvc:US88Hula@ftp.tnt.uni-hannover.de/testsequences/ParkScene_1920x1080_24.yuv.zip
2013-12-06 16:11:36 < flying_toaster> ok
2013-12-06 16:11:39 < flying_toaster> thanks a lot
2013-12-06 16:22:09 < flying_toaster> I hope I'll get some results soon :)
2013-12-06 16:22:20 < flying_toaster> thanks BugMaster and easyfab
2013-12-06 16:42:27 < easyfab> bad news : http://translate.google.fr/translate?hl=fr&sl=zh-CN&tl=en&u=http%3A%2F%2Fwww.chinavideo.org%2Fforum.php%3Fmod%3Dviewthread%26tid%3D17384
2013-12-06 16:43:38 < smarter> flying_toaster: ftp://pcs:tnt2013@ftp.tnt.uni-hannover.de/ has some clips
2013-12-06 18:05:46 < j-b> 'morning
2013-12-06 22:17:55 < Rodeo> muggs: ping
--- Day changed Sat Dec 07 2013
--- Day changed Sun Dec 08 2013
--- Day changed Mon Dec 09 2013
2013-12-09 04:54:44 < nandaku2> we had a few interesting observations about QP in x264
2013-12-09 04:55:05 < nandaku2> at low bitrates, QP is in the range 60-69
2013-12-09 04:55:21 < nandaku2> whereas H.264 limits qp to 51 (as does HEVC)
2013-12-09 05:47:22 < pengvado> nandaku2: yes, x264 has "virtual" QPs beyond the spec's max. these higher values aren't written into the bitstream, they instead mean "delete some dct coefs to save bits, then quantize the remaining coefs at QP 51".
2013-12-09 05:47:53 < nandaku2> aha
2013-12-09 05:48:11 < nandaku2> so the decoder still sees qp 51?
2013-12-09 05:49:10 < nandaku2> neat. debugging x264, we saw qp's 60-69 and were left scratching our heads
2013-12-09 05:50:29 < nandaku2> can you point us to code snippets where these virtual qp's are implemented?
2013-12-09 06:23:34 <@Skyler_> nandaku2: 395-409 in analyse.c
2013-12-09 06:25:00 < greenfountain> when the qp's are out of the spec, they are reset to 51, before encoding but the lambda used belong to the qp (before clipping to 51) ?
2013-12-09 06:25:24 <@Skyler_> yeah, the "virtual QP" is used to decide on lambdas and such, so it allows lambdas higher than the lambda for qp 51
2013-12-09 06:25:43 < nandaku2> looks good. we were investigating some low bitrate tests, thats when we noticed this
2013-12-09 06:25:48 <@Skyler_> the noise reduction is a bit of a hack for just reducing coefficient magnitudes; in theory you could get the same effect with a sufficiently decimate-happy trellis combined with the super high lambda values.
2013-12-09 06:26:15 <@Skyler_> this was added for VBV emergency mode, because there were test cases (like the Doremi Labs test box thing) that would break VBV even at QP 51
2013-12-09 06:26:22 <@Skyler_> and broadcast people didn't like that
2013-12-09 06:34:36 < greenfountain> is QP_MAX_MAX used anywre..
2013-12-09 06:35:00 <@Skyler_> analyse.c
2013-12-09 09:16:42 < j-b> 'morning
2013-12-09 09:51:05 < greenfountain> hi, i was going through the logs.. I understand generally x264 always gives better output(in terms of SSIM)  with AQ mode enabled. i was testing some clips,
2013-12-09 09:52:18 < greenfountain> with BQMall howefver, I found SSIM drop in AQ mode.. i am not sure if the way i test is wrong.. i checked with x264.exe  -o out.x265  C:\x265\testFiles\BQMall_832x480_60.y4m --keyint 2 50 --threads 1  --ssim --tune psnr  --crf 45 --frames 50 (for no AQ)
2013-12-09 09:52:31 < greenfountain> and C:\x265>x264.exe  -o out.x265 C:\x265\testFiles\BQMall_832x480_60.y4m --keyint 2 50 --threads 1  --ssim --tune ssim  --crf 45 --frames 50 (for AQ enable)
2013-12-09 09:52:48 < greenfountain> and compared the SSIM values for both..
2013-12-09 17:08:11 < JEEB> re-calculated my SSIM to be "proper" with the xiph tool, and normalized... http://fushizen.eu/u/jeeb/2013-12-03-x265_x264_test/hyouka_op/ssim/hyouka_op_03_low.pdf
2013-12-09 17:22:37 < smarter> now, how the hell do you interpret that? :)
2013-12-09 17:24:53 < Daemon404> it's in db
2013-12-09 17:24:56 < Daemon404> per-frame
2013-12-09 17:25:00 < Daemon404> afaik
2013-12-09 17:26:22 < smarter> I mean, what insight can you get from staring at that graph
2013-12-09 17:27:23 < nevcairiel> i dont even know if higher is better, or lower :D
2013-12-09 17:32:11 < JEEB> higher is better
2013-12-09 17:32:23 < JEEB> black frames are those Very High Things
2013-12-09 17:33:41 < Daemon404> infinitely high actually
2013-12-09 17:33:45 < JEEB> yes
2013-12-09 17:34:11 < JEEB> I wasn't sure how to put INF into Excel so I just made it be 100 for now :s
2013-12-09 17:34:31 < Daemon404> i just usually clamp my axes
2013-12-09 17:35:48 < JEEB> also the streams can be found here http://fushizen.eu/u/jeeb/2013-12-03-x265_x264_test/hyouka_op/
2013-12-09 17:35:58 < JEEB> (and the actual SSIM data in under ssim/ )
2013-12-09 17:36:21 < JEEB> I decided to try out a few bit rate points with a sample
--- Day changed Tue Dec 10 2013
2013-12-10 07:29:25 < j-b> 'morning
2013-12-10 08:27:33 < dlan> hi, current vlc only support x265 X265_BUILD==1?
2013-12-10 08:33:16 < ILEoo> most likely, has the api and stuff changed greatly?
--- Day changed Wed Dec 11 2013
2013-12-11 12:29:08 < dlan> ILEoo: hi, recent x265(git version) changed to 4, and break vlc build.
2013-12-11 12:29:42 < dlan> If there is anyone willing to fix this, I'd like to give it a try (vlc + x265)
--- Day changed Thu Dec 12 2013
2013-12-12 18:55:05 < funman> I get sem_open() returning ENOSYS even after mounting /dev/shm
--- Day changed Fri Dec 13 2013
2013-12-13 02:32:28 < Demogorii> Hi, I am working on a projet for school and I have a couple questions regarding x265 settings
2013-12-13 02:34:25 < Demogorii> we are trying to compare PSNR/QP/Debit/Filesize for x265 and x264 but we cannot seem to have convincing results, can someone with experience regarding the matter PM me? :)
--- Day changed Sat Dec 14 2013
--- Day changed Sun Dec 15 2013
2013-12-15 13:22:17 < j-b> m
2013-12-15 17:11:24 < Daemon404> n
--- Day changed Mon Dec 16 2013
--- Log closed Mon Dec 16 15:51:41 2013
--- Log opened Mon Dec 16 18:47:14 2013
--- Day changed Tue Dec 17 2013
2013-12-17 15:41:36 < funman> muggs: ping
2013-12-17 23:52:29 < funman> I don't understand how the X265_LATEST_TAG is generate
2013-12-17 23:52:31 < funman> d
2013-12-17 23:52:35 < funman> can't find any .hg_archival.txt
2013-12-17 23:52:54 < funman> ftr I'd like to build a static x265 lib with a x265.pc, and ideally from a git checkout
--- Day changed Wed Dec 18 2013
2013-12-18 17:05:38 < Daemon404> heh, i wrote an (uncontributed) input module
2013-12-18 17:06:07 < Daemon404> i gotta say, an inheritance-based sstem is... ugh
2013-12-18 19:22:08 < j-b> 'evening
--- Day changed Thu Dec 19 2013
--- Day changed Fri Dec 20 2013
2013-12-20 02:05:49 -SLAYBoz:#x265- anybody here?
2013-12-20 15:38:49  * funman summons a muggs
2013-12-20 15:45:38  * kodab plays counterspell on funman 
--- Day changed Sat Dec 21 2013
2013-12-21 02:56:40 < Daemon404> http://chromashift.org/img/x265/20dec2013.png
2013-12-21 03:02:12 < Daemon404> along with
2013-12-21 03:02:16 < Daemon404> http://chromashift.org/img/x265/params_20dec2013.txt
2013-12-21 03:02:22 < Daemon404> http://chromashift.org/img/x265/encoded_20dec2013.tar.xz
2013-12-21 13:28:03 < kierank> cif :(
2013-12-21 17:13:07 < Daemon404> kierank, and it still took 2 hrs to encod those *cif* vids
2013-12-21 17:13:09 < Daemon404> ;)
2013-12-21 17:14:24 < nevcairiel> since i cba to think, is higher or lower on that graph better? :p
2013-12-21 17:14:41 < JEEB> higher
2013-12-21 20:09:32 < easyfab> Daemon404: I see your post on D9
2013-12-21 20:09:43 < easyfab> could you encode with --crf 26  --preset veryslow or placebo  --no-cutree and tell me where it goes on your chart because I think  aq--mode  and cutree are not yet very usefull.
2013-12-21 20:24:42 < Daemon404> sec.
2013-12-21 20:26:49 < Daemon404> $ ../b/x265 --preset placebo --no-cutree --crf 26 -o test.hevc foreman_cif.y4m
2013-12-21 20:26:51 < Daemon404> running
2013-12-21 20:31:52 < Daemon404> 200.73 kbit/s, 10*log10(1/(1-ssim)) = Total: 11.9966
2013-12-21 20:33:40 < easyfab> Ok so better than with aq-mode and cu-tree and better than x264 ?
2013-12-21 20:34:06 < Daemon404> ssim-wise, seems so
2013-12-21 20:34:12 < Daemon404> viually sitll ugly as all hell
2013-12-21 20:34:16 < Daemon404> details destroyed
2013-12-21 20:34:20 < Daemon404> cant even see the bricks
2013-12-21 20:34:46 < easyfab> right
2013-12-21 20:37:30 < Daemon404> sidenote: i also feel someone should fix x265's website
2013-12-21 20:37:36 < Daemon404> it contains extremely misleading information
2013-12-21 20:38:23 < Daemon404> mostly regarding "when do you need to pay to use it"
2013-12-21 20:39:07 < Daemon404> social media links at the bottom are broken
--- Day changed Sun Dec 22 2013
2013-12-22 18:34:08 < j-b> 'morning
--- Day changed Mon Dec 23 2013
--- Day changed Tue Dec 24 2013
2013-12-24 14:40:31 < Rodeo> Merry Christmas!
2013-12-24 14:42:57 < Rodeo> quick Q: how can I get in touch with someone from MCW?
2013-12-24 14:51:15 < JEEBcz> the mailing list I would guess
2013-12-24 14:56:13 < Rodeo> OK
2013-12-24 14:56:33 < Rodeo> so none of them ever come on IRC?
2013-12-24 14:56:50 < JEEBcz> nah, muggs does
2013-12-24 14:56:53 < JEEBcz> and some others as well
2013-12-24 14:57:03 < JEEBcz> it's just usually quicker to get in hold of them on the mailing list :)
2013-12-24 14:58:14 < Rodeo> hehe
2013-12-24 14:59:20 < Rodeo> thanks
--- Day changed Wed Dec 25 2013
--- Day changed Thu Dec 26 2013
2013-12-26 14:23:57  * funman waits for the next push
2013-12-26 14:24:24 < funman> JEEB: I didn't see muggs here for some time
2013-12-26 15:39:45 < kierank> it's a holiday you know...
2013-12-26 16:11:59 < funman> kierank: I know but he has been missing for a while
2013-12-26 16:14:19 < funman> kierank: "it's never a holiday on IRC" or something like that? :)
2013-12-26 16:16:58 < koda> unless you get a netsplit
2013-12-26 16:17:22 < nevcairiel> he posted on d9 a while ago
2013-12-26 16:17:37 < nevcairiel> might show up here again after the holidays, who knows
2013-12-26 16:28:34 < easyfab> He's last activity was to push funman patches and after he vanished, are those patches bewitched, funman have you something to tell us ? ;)
2013-12-26 16:35:46 < funman> easyfab: ah I missed that push
2013-12-26 16:35:59 < funman> http://hg.videolan.org/x265/
2013-12-26 16:36:10 < funman> he said they were queued
2013-12-26 16:36:37 < funman> https://bitbucket.org/multicoreware/x265/commits/all oh they are here ..
2013-12-26 16:36:43 < funman> we definitely need to automate mirroring
2013-12-26 16:37:52 < funman> and the hashes do not match :s
2013-12-26 16:38:08 < funman> oh wait they do
2013-12-26 16:38:15 < funman> http://hg.videolan.org/x265/rev/5cbea1cd3d3a https://bitbucket.org/multicoreware/x265/commits/5cbea1cd3d3a61adb35b05966a7cf45a7e96a848
--- Day changed Fri Dec 27 2013
2013-12-27 08:52:41 < j-b> 'morning
2013-12-27 15:40:47 < funman> muggs: ping
--- Day changed Sat Dec 28 2013
2013-12-28 04:34:09 < nandaku2> Hello!
2013-12-28 04:34:31 < nandaku2> Folks have been asking for someone from multicoreware?
2013-12-28 04:35:21 < nandaku2> We are in the process of preparing a roadmap, so would be glad to consider wishlists from this community
2013-12-28 04:36:10 < nandaku2> AQ and CUTree are more or less done - there are a couple of issues to be sorted out, (such as the interaction b/w cutree and lookahead)
2013-12-28 04:36:26 < nandaku2> but our results already show some improvements.
--- Day changed Sun Dec 29 2013
2013-12-29 05:46:05 < hakoneko> ホロドロップｷﾀ━(ﾟ∀ﾟ)━!?と思ったら飛龍さんだった
2013-12-29 05:47:15 < hakoneko> oh, wrong channel Σ(ﾟДﾟ)
2013-12-29 05:48:03 < hakoneko> lol sorry
--- Day changed Mon Dec 30 2013
--- Day changed Tue Dec 31 2013
2013-12-31 19:14:39 < Rodeo> Happy New Year!
--- Day changed Wed Jan 01 2014
--- Day changed Thu Jan 02 2014
2014-01-02 09:33:55 < j-b> 'morning
--- Day changed Fri Jan 03 2014
--- Day changed Sat Jan 04 2014
--- Day changed Sun Jan 05 2014
2014-01-05 14:41:06 < user82> hi. is there an easy way to test x264 in ubuntu? just compile and then give it something to eat via ffmped pipe would that work?
2014-01-05 14:41:16 < user82> *x265 (of course)
2014-01-05 15:02:10 < user82> what would i use to merge the raw h264 file? mkvmerge does not seem to support it yet?
2014-01-05 15:45:43 < JEEB> user82, you can build mkvmerge with rovi/mc/divx's patches on top from here https://github.com/jeeb/mkvtoolnix/tree/hevc_support
2014-01-05 15:47:26 < JEEB> I could rebase that branch I guess
2014-01-05 16:07:59 < user82> thanks JEEB
2014-01-05 17:22:42 < Daemon404> JEEB, is hevc-in-mkv finalized?
2014-01-05 17:23:46 < JEEB> no real updates since my tl;dr
2014-01-05 17:23:55 < Daemon404> shocking.
2014-01-05 17:24:03 < Daemon404> not like its useful yet anyway i guess
2014-01-05 17:24:56 < JEEB> well, functionally it's pretty much finalized
2014-01-05 17:25:06 < JEEB> the last thing is to wait for 14496-15 3rd ed to get out of the ballot
2014-01-05 17:25:15 < JEEB> and then the version entry can be bumped
2014-01-05 17:25:16 < JEEB> and that's it
2014-01-05 17:27:30 < Daemon404> wait thats still not out?
2014-01-05 17:27:31 < Daemon404> lolz
2014-01-05 17:27:52 < JEEB> still in the ballot
2014-01-05 17:28:18  * muken still waits
2014-01-05 17:30:37 < JEEB> geez, lucia still doesn't have it even
--- Day changed Mon Jan 06 2014
2014-01-06 08:15:15 < j-b> 'morning
2014-01-06 15:48:23 < phc_office> happy monday
--- Day changed Tue Jan 07 2014
2014-01-07 00:04:59 < Mandarink> http://www.sweclockers.com/image/red/2014/01/06/Kaveri_186.jpeg?t=original&k=a21b7f48
2014-01-07 00:05:25 < Mandarink> Kaveri slide - "hevc encode/decode" "accelerated with HSA"
2014-01-07 00:05:40  * Mandarink wonders if MCW has anything to do with that :)
2014-01-07 00:06:13 < Daemon404> "hsa" ?
2014-01-07 00:09:15 < JEEBsv> those look like telestream slides
2014-01-07 00:09:40 < JEEBsv> so I would guess telestream/ASIC
2014-01-07 00:47:37 < Mandarink> it is AMS slide
2014-01-07 00:47:44 < Mandarink> *AMD
2014-01-07 00:48:02 < Mandarink> HSA = marketing word for apu/fusion
2014-01-07 00:48:34 < Mandarink> basically, gpu and cpu with shared memory
2014-01-07 00:48:53 < Mandarink> which means they can effectively mix cpu and gpu code... in theory/slides
2014-01-07 00:50:38 < Mandarink> oh hehe
2014-01-07 00:51:14 < Mandarink> the slides shows logos of open source projects using acceleration via "heterogenous architectures"
2014-01-07 00:51:34 < Mandarink> there is x264 and ffmpeg, but not libav :D </troll>
2014-01-07 01:00:10 < kierank> yeah because libav doesn't have that chinese gpu code
2014-01-07 01:06:01 < Rodeo> is that OpenCL or something else?
2014-01-07 01:08:49 < Daemon404> kierank, the gpu code that is used for absolutely nothing useful at all?
2014-01-07 01:48:40 < Mandarink> how else :)
2014-01-07 01:48:43 < Mandarink> and ic.
2014-01-07 07:43:02 < j-b> 'morning
2014-01-07 09:18:16 < guesst> hi.. x265 is PC only or do you care about dsp implementations as well?
2014-01-07 09:21:38 < guesst> i am looking for realtime 4k encoder (24-30p).. preferably low power
2014-01-07 09:26:37 < JEEB> ASICs would end up being rather different to yer usual software implementation, so I would guess that this is PC only. Also do note that _all_ HEVC encoders at this point are in very early stages. Do not buy into _anyone's_ kool aid, no matter what the strippers and powerpoint slides say.
2014-01-07 09:27:47 < guesst> I see... I still have a per quadrant h264 as backup plan
2014-01-07 09:27:49 < JEEB> also do note that other than by the name and by the ability to use x264's double-licensed parts of code, x265 has very little to do with x264.
2014-01-07 09:28:24 < JEEB> guesst, depending on your power consumption needs you could also just have x264 running with the full 4K picture
2014-01-07 09:29:14 < guesst> usual hardware is rated for 1080p60 at most, so that is not an option
2014-01-07 09:29:23 < JEEB> what?
2014-01-07 09:30:07 < JEEB> I know x264 was successfully tested with live 4K encoding with i5 or i7 CPUs a couple of years ago
2014-01-07 09:30:29 < JEEB> so as long as you have the input, it should be possible
2014-01-07 09:30:32 < guesst> so that is like 80W+ ... i want <10W
2014-01-07 09:30:51 < JEEB> well, OK -- such limitations make a difference of course :)
2014-01-07 09:31:17 < JEEB> (which is why I noted "depending on your power consumption needs")
2014-01-07 09:32:28 < guesst> i can provide 200fps live at 4K... so it will be paralelised and I do not want to end up with a jug kettle :)
2014-01-07 09:34:51 < JEEB> If only hardware encoders didn't suck as much, and at that have a lolhueg price tag :/ after seeing the things I've seen I'm generally afraid of limiting myself with costly black boxes to be quite honest
--- Day changed Wed Jan 08 2014
2014-01-08 23:12:45 < kierank> Manao: do you know if HEVC are going to deal with the chroma positioning in interlaced video?
2014-01-08 23:12:55 < kierank> jvt-vc i mean
2014-01-08 23:31:51 < JEEBsv> hasn't come up yet at least
2014-01-08 23:31:59 < JEEBsv> unless one of the documents have it there
2014-01-08 23:32:06 < JEEBsv> did someone post a report on their trac?
2014-01-08 23:32:50 < Daemon404> damn broadcasters
2014-01-08 23:33:32 < KeithW> Has the chroma co-siting changed since MPEG-2?
2014-01-08 23:33:49 < Daemon404> avc had various iirc
2014-01-08 23:33:52 < Daemon404> settable in flags
2014-01-08 23:33:54 < Daemon404> (dont quote me)
2014-01-08 23:35:32 < kierank> yes but mpeg-2 is the one everyone used
2014-01-08 23:35:55 < kierank> KeithW: no but in the current interlaced coding mode (i.e no special interlaced coding) chroma is coded incorrectly
2014-01-08 23:35:58 < Daemon404> in practice nothing else was supported
2014-01-08 23:36:05 < Daemon404> but it was there, technically.
2014-01-08 23:36:25 < KeithW> Cool, didn't know about that.
2014-01-08 23:54:22 < Mandarinka> x264 --chromaloc option
--- Day changed Thu Jan 09 2014
2014-01-09 17:26:07 < Manao> kierank, Daemon404 : hevc can signal chroma positioning as h264 does
2014-01-09 17:26:51 < Manao> however, it does not offset motion vector correctly when field parity between prediction and encoding changes to account for the difference in chroma/luma positionning between both field parities
2014-01-09 17:27:14 < Manao> in that regards, it behaves like mpeg2, while h264 does that properly
2014-01-09 17:42:30 < kierank> Manao: are there any plans to fix that MV chroma offset problem
2014-01-09 20:15:02 < kurosu_> the fujitsu guys working on that have been pretty unsuccessfull at being heard
2014-01-09 20:20:17 < JEEB> so it was reported?
2014-01-09 20:20:26 < koda> yeah, why worry about interlacing
2014-01-09 20:21:00 < Manao> most don't want to fix it, it has been rejected several times, so I don't think it'll get fixed
2014-01-09 20:21:24 < JEEB> ah, so that is the deal
2014-01-09 20:21:26 < JEEB> gotchas
2014-01-09 20:22:54 < Manao> i don't think it'll matter in the long run. HEVC is a bit underwhelming at small resolutions, which 1920x540 (1080i encoded in field) is
2014-01-09 20:24:12 < Manao> lack of good interlacing will probably make 1080p50 & 4K arrive sooner
2014-01-09 20:24:26 < koda> ok delay its adoption in us
2014-01-09 20:24:45 < kurosu_> meanwhile, people are thinking about avc1080i to hevc{1080p,4K} *scalability*
2014-01-09 20:25:39 < KeithW> Does this bug only happen if you use field pictures? (Is that still a thing in AVC/HEVC?)
2014-01-09 20:25:52 < KeithW> Because most interlaced 1080i MPEG-2 video in the wild just uses interlaced frame pictures.
2014-01-09 20:26:24 < Manao> it's not a bug, it's a coding inefficiency
2014-01-09 20:26:35 < Manao> that could have been easily avoided
2014-01-09 20:26:37 < KeithW> (In fact I have never seen a field picture used with the vertical resolution > 576.)
2014-01-09 20:42:08 < Daemon404> i assuming you refer to real temporally differing fields
2014-01-09 20:42:10 < Daemon404> and not telecine
2014-01-09 20:42:11 < Daemon404> im*
2014-01-09 20:52:03 < kierank> 8:23 PM <KeithW> (In fact I have never seen a field picture used with the vertical resolution > 576.) --> a lot of AVC in Europe
2014-01-09 20:52:05 < kierank> is PAFF encoded
2014-01-09 20:52:20 < kierank> kurosu_: fujitsu seem to be quite big on the chroma reproduction stuff
2014-01-09 20:52:26 < kierank> there's a smpte spec and IPR associated with it
2014-01-09 20:52:49 < Daemon404> kierank, i assume he means avtual interlaced content
2014-01-09 20:52:55 < Daemon404> not erely being encoded as such.
2014-01-09 20:52:59 < Daemon404> merely*
2014-01-09 20:53:25 < kierank> oh field picture > 576
2014-01-09 20:53:27 < kierank> yeah ok
2014-01-09 20:53:36 < kierank> was thinking total lines
2014-01-09 20:53:52 < kierank> there was some japanese thing that was > 1080 lines
2014-01-09 20:54:06 < JEEB> reminds me of analog HD
2014-01-09 20:54:51 < JEEB> 1125/60 高精細度テレビジョン (HDTV) 方式
2014-01-09 20:55:41 < koda> amazing 1125
2014-01-09 20:59:10 < KeithW> In MPEG-2, you can code an interlaced video sequence using either interlaced frame pictures (using the picture coding extension to mark which field goes first) OR with field pictures.
2014-01-09 20:59:44 < KeithW> I don't know for sure if AVC preserves this. I was just asking whether the problem affects interlaced frame pictures, or just field pictures.
2014-01-09 21:01:45 < JEEB> AVC and HEVC have the same feature
--- Day changed Fri Jan 10 2014
2014-01-10 02:18:56 < kierank> the only time i have seen mpeg-2 field pictures is in a conformance video
2014-01-10 03:04:37 < KeithW> I believe I have seen them on a digital cable QAM pay-per-view stream.
2014-01-10 03:05:14 < KeithW> But other than that, yes, just as a conformance test.
--- Day changed Sat Jan 11 2014
2014-01-11 00:44:46 < user82> what would i use to play a h265 file in a mp4 container with ubuntu? vlc 2.20 from the ppa does not play the file
2014-01-11 00:45:11 < Nosomy> vlc supports hevc?
2014-01-11 00:46:13 < smarter> it does starting with 2.1.1: http://www.jbkempf.com/blog/post/2013/VLC-2.1.1-and-2.0.9
2014-01-11 00:46:16 < user82> Nosomy, i hoped so. maybe a muxing problem?
2014-01-11 00:46:48 < smarter> user82: ask on #videolan
2014-01-11 00:46:57 < user82> ok
--- Day changed Sun Jan 12 2014
--- Day changed Mon Jan 13 2014
2014-01-13 08:19:15 < funman> so muggs is not coming back ?
2014-01-13 09:33:02 < funman> is the last iso13818-1 in the wild or should I ask my boss to participate in iso racket and pay for it?
2014-01-13 09:33:53 < funman> i'm looking at http://mpeg.chiariglione.org/ if I can find the transport stream id for hevc
2014-01-13 09:46:19 < JEEB> funman, I'm pretty sure that 2013 version is the same as this, which doesn't contain HEVC http://www.itu.int/rec/T-REC-H.222.0-201206-I/en
2014-01-13 09:47:28 < funman> "HEVC support in MPEG-2 transport stream and ISO base media file" dates from august apparently
2014-01-13 09:48:15 < JEEB> the specs are pretty much ready but they're not going through with them for whatever political reason
2014-01-13 09:48:28 < JEEB> I just noted that on mp4-sys there was an e-mail like this
2014-01-13 09:48:49 < JEEB> "...the publication of the new edition of Part 15 has been unfortunately delayed."
2014-01-13 09:49:09 < JEEB> I think 13818-1 is probably in better shape but still not officially released
2014-01-13 09:49:17 < JEEB> by now it should most probably be 2014
2014-01-13 09:49:24 < JEEB> since the ballot was in the very late 2013
2014-01-13 09:49:44 < funman> https://mailman.videolan.org/pipermail/vlc-devel/2014-January/096247.html
2014-01-13 09:51:11 < JEEB> http://lucia.itscj.ipsj.or.jp/standard/servlets/DocumentSearch?ID=112&sn=1381800104030001&stp=1&sg=86&st=1&m=1
2014-01-13 09:51:42 < JEEB> yeah, the ballot was in the very last part of 2013
2014-01-13 09:51:57 < JEEB> but yes, drafts that were available at places probably contained the info that people are nowadays posting
2014-01-13 09:52:11 < JEEB> both libavcodec and some other entities just used whatever was in the drafts
2014-01-13 09:52:58 < funman>     { 0x24, AVMEDIA_TYPE_VIDEO,       AV_CODEC_ID_HEVC },
2014-01-13 09:53:40 < JEEB> I will guess that was gained from the drafts
2014-01-13 09:54:08 < JEEB> they recently made it harder to get to the drafts on the working group's site (requires http auth now :< )
2014-01-13 09:54:23 < JEEB> so can't check if that's what's in the last version
2014-01-13 09:55:52 < funman> 93c1fe4d libavformat/mpegts.c (Mickaël Raulet        2013-10-11 21:43:58 +0200  622)     { 0x24, AVMEDIA_TYPE_VIDEO,       AV_CODEC_ID_HEVC },
2014-01-13 09:55:57 < funman> I guess he's http://www.ietr.fr/spip.php?auteur195
2014-01-13 09:57:07 < funman> hm the muxer has not been updated though
2014-01-13 09:58:58 < JEEB> yeah, he's the GPAC dude
2014-01-13 09:59:03 < JEEB> GPAC/OpenHEVC
2014-01-13 09:59:20 < JEEB> mraulet on IRC
2014-01-13 17:43:52 < phc_office> muggs is not coming back here?
2014-01-13 17:45:46 < JEEB> I don't know, he hasn't noted into one way or anotehr
2014-01-13 17:53:11 < Daemon404> he hasnt been on the ML either
2014-01-13 17:54:19 < Mandarinka> possibly a vacation during holiday, and ces last week. Dunno if MCW was there
2014-01-13 20:49:40 < phc_office> yeah
2014-01-13 21:31:32 < funman> he committed 3 days ago
2014-01-13 22:36:20 < funman> http://git.videolan.org/?p=vlc.git;a=commit;h=d03f05479f46ec10f8194e62cddb4e77815bc7e0
2014-01-13 22:36:27 < funman> soon in a vlc windows build near you!
--- Day changed Tue Jan 14 2014
2014-01-14 12:26:47 < Rodeo> funman: referring to yourself in the third person?
2014-01-14 12:28:03 < funman> Rodeo: I was talking about mugg
2014-01-14 12:28:05 < funman> s
2014-01-14 12:28:22 < funman> x265 in vlc dates from yesterday and it's available on http://nightlies.videolan.org/build/win32/vlc-2.2.0-20140114-1156/
2014-01-14 12:28:41 < Rodeo> yes, but Rafaël Carré is not muggs, and he is the one who did the commit, AFAICT
2014-01-14 12:28:48 < Rodeo> as opposed to just the author
2014-01-14 12:30:01 < funman> I was mentioning that he committed in x265.hg
2014-01-14 12:30:12 < funman> I surely hope Rafaël Carré is not muggs :P
2014-01-14 12:30:26 < funman> my vlc commit was a new discussion
2014-01-14 12:30:46 < funman> https://bitbucket.org/multicoreware/x265/commits/all
2014-01-14 12:46:26 < j-b> good morning
2014-01-14 13:42:09 < Daemon404> http://forum.doom9.org/showthread.php?p=1662036#post1662036 <-- fun
--- Day changed Wed Jan 15 2014
--- Day changed Thu Jan 16 2014
2014-01-16 01:30:59 < Brian666> When will x265 become mainstream
2014-01-16 01:37:09  * Mandarinka says psyrdo.
2014-01-16 01:38:01 < Mandarinka> well, or at least, with psyrdo we should be able to check it against x264 in a meaningful (not SSIM/PSNR) way
2014-01-16 01:38:54 < Mandarinka> damn, I can't wait for it to be useful. Even if I don't look forward to the CPU upgrade that encoding at superslow settings will prolly require ><
2014-01-16 01:39:45 < Mandarinka> * useful = beats x264 at everything :)
2014-01-16 14:37:53  * funman spots a muggs passing by
2014-01-16 18:52:51 < muggs> hey everyone, sorry for being so scarce lately
2014-01-16 19:55:44 < funman> muggs: hi, nice to see you back
2014-01-16 19:56:25 < muggs> hi funman, thanks.
2014-01-16 19:56:51 < funman> muggs: VLC binaries now ship with x265 0.6
2014-01-16 19:57:07 < muggs> sweet
2014-01-16 19:57:52 < muggs> I have a patch from idxa that adds dts to x265_picture.  Would VLC use it?
2014-01-16 20:26:59 < Daemon404> muggs, i assume it adds it at the end of the struct
2014-01-16 20:27:02 < Daemon404> ffffff
2014-01-16 20:27:09 < Daemon404> why can he never friggen stay online
2014-01-16 21:23:22 < JEEB> just gonna note
2014-01-16 21:23:28 < JEEB> that
2014-01-16 21:23:29 < JEEB> <pengvado> BBB: you're running into this bug: http://akuvian.org/paste/ee7e76e8.diff
2014-01-16 21:23:36 < JEEB> ^ this makes x265 build way quicker
2014-01-16 21:23:49 < JEEB> basically patch yasm with this, and use that binary
2014-01-16 21:24:07 < Daemon404> pixel-a.asm wont take 400 years?
2014-01-16 21:24:20 < JEEB> yup
2014-01-16 21:24:32 < JEEB> I mean, x265 used to build in 22 MINUTES with the latest release
2014-01-16 21:24:39 < JEEB> on my c2d
2014-01-16 21:24:42 < JEEB> now it's
2014-01-16 21:24:48 < JEEB> Time Elapsed 00:04:37.19
2014-01-16 21:25:13 <@Skyler_> 22 minutes? @_@
2014-01-16 21:25:24 < JEEB> yes
2014-01-16 21:25:30 < JEEB> yasm is _that_ slow
2014-01-16 21:25:32 < JEEB> on the macros
2014-01-16 21:26:12 < JEEB> pengvado's fix is basically to enlargen the number of hash values used for the macro lookup table
2014-01-16 21:26:34 <@Skyler_> out of curiosity how does his x86inc ""fix"" fix it?  it just changes %s to _
2014-01-16 21:26:39 < JEEB> default value is 31, his fix sets it to 511
2014-01-16 21:27:22 <@Skyler_> I meant the other patch
2014-01-16 21:27:47 < JEEB> <pengvado> yes, the ones in x86inc.asm that define new temporary variables for every instruction instantiated
2014-01-16 21:27:47 < JEEB> <pengvado> using %% to get local variables doesn't actually limit their scope, they still go in the global hash of macro names
2014-01-16 21:28:03 < JEEB> so I guess he tried to make them more local? Not exactly sure what the _ does
2014-01-16 21:28:26 < JEEB> or in any other way tried to minimize the amount of macro names in the global scope
2014-01-16 21:28:42 < muggs> the assembly compiles are painful
2014-01-16 21:29:08 < JEEB> the diff I linked should make that much, much less painful
2014-01-16 21:29:19 < JEEB> build yasm with that and it will make it X times faster
2014-01-16 21:29:38 < muggs> has yasm accepted that patch upstream?
2014-01-16 21:29:50 < JEEB> not yet
2014-01-16 21:30:03 < JEEB> they have a fixme in there
2014-01-16 21:30:03 < JEEB>  * FIXME: We should *really* be able to configure this at run time,
2014-01-16 21:30:03 < JEEB>  * or even have the hash table automatically expanding when necessary.
2014-01-16 21:30:14 < JEEB> and this was in the end never touched :P
2014-01-16 21:30:48 < muggs> I know how that goes
2014-01-16 21:32:27 < muggs> might be worth the trouble to build yasm.exe with that patch and host it on our wiki
2014-01-16 21:33:41 < JEEB> yeah
2014-01-16 21:54:55 < muggs> hmm; when I build yasm myself, for one it is pretty small and for two it complains it cannot load standard modules.
2014-01-16 21:55:41 < Daemon404> [19:55] < muggs> I have a patch from idxa that adds dts to x265_picture.  Would VLC use it? <-- elenril has been asking for this for libav
2014-01-16 21:55:49 < Daemon404> because x264 uses it iirc
2014-01-16 21:55:58 < Daemon404> api-wise
2014-01-16 21:56:04 < muggs> ok; I'll queue it up today
2014-01-16 21:56:06 < Daemon404> also
2014-01-16 21:56:11 < Daemon404> i assume you will bump the soname
2014-01-16 21:56:14 < Daemon404> it is an ABI break.
2014-01-16 21:57:06 < muggs> sure
2014-01-16 22:26:28 < funman> muggs: hm yeah if dts is added we would use it
2014-01-16 22:29:57  * funman patches yasm
2014-01-16 22:30:30 < muggs> I got it built on VC9/Win32; quite a bit of a pain
2014-01-16 22:34:06 < JEEBsv> autoconf + mingw was rather simple for me
2014-01-16 22:34:23 < JEEBsv> although I built HEAD so I had to create that one file created by a random python script
2014-01-16 22:34:56 < muggs> I was about to go that route, but I think binaries built that way still need GCC runtime DLLs?
2014-01-16 22:35:35 < JEEBsv> depends on the toolchain
2014-01-16 22:36:00 < JEEBsv> I use ones that don't try to link everything shared by default
2014-01-16 22:36:30 < JEEBsv> http://files.1f0.de/mingw/
2014-01-16 22:36:45 < JEEBsv> and zeranoe's build script on *nix, which leads to same kind of setup
2014-01-16 22:37:26 < JEEBsv> the only dependency or dependencies you usually get are MS DLLs that are available from XP forwards
2014-01-16 22:38:58 < muggs> that sounds handy
2014-01-16 22:40:11 < j-b> GCC runtime DLLs are only necessary if you compiled gcc with shared
2014-01-16 22:40:12 < muggs> man, bitbucket seems broken at the moment, I'll have to upload it later
2014-01-16 22:40:14 < funman> muggs: http://people.videolan.org/~funman/win/howto-gcc
2014-01-16 22:40:37 < funman> it's for debian although needs little adaptation for other distros
2014-01-16 22:40:50 < funman> on arch the libraries were all in /usr/i686-.../{lib,bin}
2014-01-16 22:41:30 < funman> j-b: or if you didn't build gcc at all
2014-01-16 22:41:49 < funman> muggs: btw I want to have hg.videolan.org automatically mirror bitbucket
2014-01-16 22:43:07 < funman> and/or have a git mirror on videolan.org instead of github
2014-01-16 22:43:14 < muggs> funman: I've no complaints about that
2014-01-16 22:43:49 < funman> since we'd be more likely to use git and no information should be lost between the 2 repos I'd tend to have just one hg repo on bitbucket and one git on videolan
2014-01-16 22:44:38 < muggs> you'd have to arm-wrestle with j-b about dropping the hg repo on videolan
2014-01-16 22:45:16 < funman> j-b: i'm left handed but i'll beat you anyway, can we remove the hg repo and create a git one? I'll handle the mirroring part
2014-01-16 23:38:38 < muggs> patched yasm.exe is on the wiki now, including a link to the patch
2014-01-16 23:56:00 < j-b> I will think about it, and let's discuss it at FOSDEM
--- Day changed Fri Jan 17 2014
2014-01-17 02:04:15 < smarter> Note that: [21:12:37] <pengvado> http://akuvian.org/paste/434723e7.diff provides almost as much speedup as fixing yasm
2014-01-17 02:04:22 < smarter> so patching yasm might not be necessary
2014-01-17 12:22:24 < quaz0r> Playing: torrents/Ultramagnetic MC's - Critical Beatdown [2004. CD, FLAC]/(21) Ultramagnetic MC's - Mentally Mad .flac
2014-01-17 12:29:48 < JEEB> smarter, after the discussion on #x264dev it seems like in the end the yasm patch is the better way to fix it
2014-01-17 12:30:07 < JEEB> Gramner seems to have poked yasm-devel or so with a patch
2014-01-17 12:30:35 < Daemon404> yasm-deve is a thing?
2014-01-17 12:30:36 < nevcairiel> so the next yasm release in 25 years will have a fix?
2014-01-17 12:31:04 < JEEB> Daemon404, he said it was some ML
2014-01-17 12:31:12 < Daemon404> o ok
2014-01-17 12:31:21 < JEEB> <Gramner> sent a patch for that to yasm-devel, will probably be ignored though i guess since yasm seems pretty dead nowadays
2014-01-17 15:25:04 < funman> [matroska @ 0x7f5b6c00f300] pts (33070390) < dts (33070432) in stream 1
2014-01-17 15:25:08 < funman> apparently I got dts wrong in VLC ..
2014-01-17 15:25:33 < funman>     p_block->i_pts = p_sys->initial_date + pic.poc * p_block->i_length;
2014-01-17 15:25:34 < funman>     p_block->i_dts = p_sys->initial_date + p_sys->dts++ * p_block->i_length;
2014-01-17 15:26:25 < funman> http://cvs.tortall.net/pipermail/yasm-devel/ no mails since april 2013 ..
2014-01-17 15:27:04 < funman> Gramner: perhaps it should be sent through https://github.com/yasm/yasm
2014-01-17 15:27:49 < funman>  BrianGladman authored 2 months ago
2014-01-17 15:39:56 < kierank> funman: matroska doesn't have dts
2014-01-17 15:41:24 < quaz0r> Playing: torrents/Ultramagnetic MC's - Critical Beatdown [2004. CD, FLAC]/(21) Ultramagnetic MC's - Mentally Mad .flac
2014-01-17 15:41:48 < quaz0r> yall playaz cant deal wit me
2014-01-17 15:46:05 < funman> kierank: it could be a generic avformat check
--- Day changed Sat Jan 18 2014
--- Day changed Sun Jan 19 2014
2014-01-19 08:23:22 < KeithW> Did H.265 remove the SI- and SP-frames that are in H.264?
2014-01-19 08:24:21 < KeithW> I'm finding the reference to STSA pictures in the H.265 spec, but that seems to be about temporal scalability. I don't see anything about switching frames.
2014-01-19 08:32:04 <@Skyler_> I don't think they made it into H.265, no
2014-01-19 08:32:11 <@Skyler_> I kinda assumed most of the Baseline-only non-features didn't
2014-01-19 08:33:43 < KeithW> Were SI/SP just a dud that nobody ended up using...? They seem better than periodic IDR frames for a YouTube or Netflix-like application.
2014-01-19 08:34:56 <@Skyler_> they don't really serve the same role as periodic IDR frames
2014-01-19 08:35:13 <@Skyler_> http://akuvian.org/src/x264/switching_pictures.txt
2014-01-19 08:35:50 <@Skyler_> they're complex, nothing anywhere supported them, they weren't useful enough to justify the complexity
2014-01-19 08:36:13 <@Skyler_> and they required baseline profile, which ruled them out for most applications, since it's rarely worrth sacrificing 40-50% compression in order to use switching pictures
2014-01-19 08:36:50 < KeithW> Why do you think they standardized it that way? Historically more-complex features were lumped in with other more-complex features in a profile.
2014-01-19 08:36:56 <@Skyler_> I really don't know
2014-01-19 08:37:09 <@Skyler_> non-constrained baseline profile ended up with a bunch of features that nobody ever supported
2014-01-19 08:37:27 <@Skyler_> I don't know the political reason behind it; it almost feels like it was a "feature ghetto" where they exiled all the things people wanted, but nobody intended to actually support.
2014-01-19 08:37:48 <@Skyler_> *all the things [some particular person] wanted
2014-01-19 08:38:39 < KeithW> Hmm.
2014-01-19 08:39:15 < KeithW> What is the state of the art in letting users seek to an arbitrary frame in a YouTube-like application? Just "find the most recent IDR frame and decode forward from there until you hit the one the user wanted"? Or is there some fancier technique?
2014-01-19 08:39:48 <@Skyler_> I don't see how SI/SP pictures help that?
2014-01-19 08:40:03 <@Skyler_> SI/SP pictures might be useful in some kind of hypothetical adaptive streaming application, like DASH
2014-01-19 08:41:15 < KeithW> Well, no, I wasn't trying to constrain the question to SI/SP frames.
2014-01-19 08:41:26 <@Skyler_> I'm pretty sure you seek to the most recent IDR frame, yeah
2014-01-19 08:41:38 <@Skyler_> though youtube-like applications often involve icky things like header rewriting
2014-01-19 08:41:40 <@Skyler_> I think
2014-01-19 09:50:43 < kierank> YouTube uses dash now
2014-01-19 10:30:26 < Manao> baseline has been replaced by SHVC as a feature ghetto for HEVC
2014-01-19 10:31:02 < JEEB> :D
2014-01-19 11:43:00 < j-b> 'morning
2014-01-19 14:14:07 < kierank> 10:27 AM <Manao> baseline has been replaced by SHVC as a feature ghetto for HEVC --> what about AVC/HEVC scalability
2014-01-19 14:14:19 < kierank> seems like another academic playground
2014-01-19 14:14:45 < JEEB> that's pretty much it :D
2014-01-19 14:14:56 < JEEB> scalable extensions for HEVC
2014-01-19 14:15:19 < JEEB> and yes, I really don't see the main points in many of the scalable extensions things
2014-01-19 14:15:31 < kierank> they have a use
2014-01-19 14:15:38 < smarter> JEEB: AVC/HEVC scalability is when you have a base layer in AVC and an enhancement layer in HEVC
2014-01-19 14:15:43 < JEEB> yeah
2014-01-19 14:15:57 < JEEB> I think I just plugged the two dots together
2014-01-19 14:16:01 < kierank> SVC is useful for when you have packet loss
2014-01-19 14:16:15 < smarter> I don't know if that's part of the SHVC part or it's a separate thing
2014-01-19 14:16:19 < smarter> *SHVC spec
2014-01-19 14:16:27 < kierank> rather have half-resolution than artefacts
--- Day changed Mon Jan 20 2014
2014-01-20 18:47:52 < Mandarinka> http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/MPEG-LA-Announces-Proposed-HEVC-Licensing-Terms-94308.aspx
2014-01-20 18:48:07 < Mandarinka> the PR: http://www.mpegla.com/main/Pages/Media.aspx
2014-01-20 18:51:48 < Mandarinka> no content royalties it seems, just decoder/encoder
2014-01-20 18:51:56 < Mandarinka> but higher annual cap.
2014-01-20 19:29:53 < KeithW> $25 million! Maybe Cisco, Adobe, and Microsoft can get together to form an LLC to pay that on behalf of everybody else, OpenH264-style.
2014-01-20 19:39:28 < Mandarinka> well, 20 cents still sound like peanuts for a good technology, to me.
2014-01-20 19:40:22 < KeithW> Well, how does something like x265 deal with this? Do you cap your download sites at 100,000 downloads per year?
2014-01-20 19:40:50 < KeithW> (Or do the patent owners not care about distributions in source-code form?)
2014-01-20 19:43:09 < Daemon404> you dont pay for sources.
2014-01-20 19:46:07 < Mandarinka> yes, source = no distribution, no liability
2014-01-20 19:46:20 < Mandarinka> the vendor to pay would be the build maker/hoster
2014-01-20 19:46:41 < Mandarinka> same with x264
2014-01-20 19:46:43 < KeithW> Who says you don't pay for sources -- is that part of the H.264 licensing terms?
2014-01-20 19:47:03 < Mandarinka> dunno but they actually confirmed it to some people
2014-01-20 19:47:19 < Mandarinka> f.e. Donald Graft :)
2014-01-20 19:47:29 < Mandarinka> a.k.a. Neuron2
2014-01-20 19:47:51 < KeithW> Yeah, I think that's unsteady ground to stand on, but if all players are ok with it it's probably fine.
2014-01-20 19:48:53 < Mandarinka> no, it is not unsteady, it is established fact as far as I can tell
2014-01-20 19:49:05 < KeithW> It's a question of law, not fact.
2014-01-20 19:49:46 < Mandarinka> it is even accepted on webrtc list! (which is something, with all that anti-mpeg fud going on there, hehe)
2014-01-20 19:51:36 < KeithW> Hmm, that's not my read of the discussion. The Cisco hack is great but its value is in covering these binary modules. It's not a license for anybody to redistribute OpenH264 sources.
2014-01-20 19:51:46 < KeithW> But I don't want to pollute your IRC channel with legal mumblings.
2014-01-20 19:52:46 < Mandarinka> license for anybody to redistribute OpenH264 sources. --- source distribution is under BSD
2014-01-20 19:53:23 < Mandarinka> and anybody can use the sources for free software without any mpeg-la licensing, as long as he also just distributes sources
2014-01-20 19:53:30 < Mandarinka> like Gentoo/x264/etc
2014-01-20 19:54:09 < KeithW> Look, tell me first if you actually want to have a legal discussion or if I'm just polluting your channel.
2014-01-20 19:54:27 < KeithW> If you want to have the legal discussion, we can have it. :-)
2014-01-20 19:57:04 < Mandarinka> it's not "my" channel.
2014-01-20 20:05:49 < Daemon404> [19:44] < KeithW> Yeah, I think that's unsteady ground to stand on, but if all players are ok with it it's probably fine. <-- no mpeg-la sent a written letter to some people
2014-01-20 20:05:53 < Daemon404> its not unsteady at all.
2014-01-20 20:07:04 < Daemon404> oh i didnt read.
2014-01-20 20:07:17 < KeithW> Do you have a pointer to the letter? I'm interested to read it.
2014-01-20 20:08:18 < KeithW> In general, MPEG-LA is not a patent owner. As far as I know, they only way they can immunize somebody from liability is by entering into a license with them for the patents covered by the pool. But I could be wrong here.
2014-01-20 20:09:15 < KeithW> Debian has recently (in the last 3-4 years) taken the position that the patent law doesn't actually require them to do anything until a patent owner complains, and so in the absence of any complaints, they're just not going to talk about it and will be happy to distribute mp3 encoders/decoders, mpeg2 encoders/decoders, etc. (Which is a change from 4-5 years ago.) And so far that strategy seems to be working fine for them.
2014-01-20 20:10:53 < Daemon404> im trying to find the thread with n2
2014-01-20 20:11:09 < Daemon404> aso keep in mind, big companies like intel also rely on the source-istribution methd
2014-01-20 20:11:13 < Daemon404> its not exactly untested.
2014-01-20 20:14:05 < KeithW> I'd be interested to read that thread, so thanks for looking.
2014-01-20 20:14:18 < Daemon404> http://forum.doom9.org/showthread.php?t=156599
2014-01-20 20:14:26 < Daemon404> i think that was it.
2014-01-20 20:14:34 < KeithW> I think my original question has been answered, though, which is that projects like x264 and x265 rely on the fact that the H.264 and 265 patent owners don't seem to object to source-only distribution.
2014-01-20 20:14:46 < Daemon404> yes
2014-01-20 20:15:15 < Daemon404> be warned
2014-01-20 20:15:26 < Daemon404> that thread devolves rapidly into Skyler_ and n2 arguing
2014-01-20 20:15:40 < Daemon404> so you may want to skip the end parts.
2014-01-20 20:35:29 < Mandarinka> heh heh
2014-01-20 20:36:03 < Mandarinka> reminds me of the great ffmpeg schism
2014-01-20 20:36:45 < muggs> this is the reason we do not offer any builds of x265 for download, to avoid MPEG-LA issues.
2014-01-20 20:37:03 < Daemon404> how does vlc skirt the issue?
2014-01-20 20:37:06 < Daemon404> some special france-ness?
2014-01-20 20:37:12 < muggs> mostly, I think
2014-01-20 20:39:02 < nevcairiel> not being in the US helps in many cases
2014-01-20 20:39:21 < muggs> not having a lot of money to lose in a lawsuit helps as well
2014-01-20 21:24:24 < easyfab> Hey the new yasm from x265's bitbucket rocks :  pixel-a.asm build in less than 15 sec vs 2 min before . :)
2014-01-20 21:24:53 < JEEB> yeah, gramner sent them a patch
2014-01-20 21:25:28 < JEEB> basically people noticed that yasm was getting slow and pengvado pointed at the fact that it was using 31 values to look through all the macros
2014-01-20 21:25:36 < JEEB> to save memory, possibly
2014-01-20 21:25:57 < JEEB> you could safely up that to >1000 and that'd still only be a few kilobytes extra
2014-01-20 21:26:05 < JEEB> meanwhile speed would go way down
2014-01-20 21:27:43 < Gramner> that yasm binary uses loren's patch. we both wrote similar patches at the same time. original size is 31, he changed it to 511, i changed it to 4096
2014-01-20 21:29:39 < easyfab> Oh Pengvado and Gramner patch  . So better than yasm's team  :) You are really amazing guys
2014-01-20 21:30:08 < easyfab> 1000x with a few lines of code
2014-01-20 21:30:46 < kierank> KeithW: i have a letter from mpeg-la saying sources are fine to distribute
2014-01-20 21:31:34 < nevcairiel> now all we need is a tiny compiler, and all problems are solved
2014-01-20 21:31:47 < kierank> In principle I can send .o files
2014-01-20 21:31:56 < Gramner> dunno what the mod2-1 of the original and loren's patch is about. it doesn't help and the code uses modulus size for some calculations so in theory mod2 is faster since it can use a bitwise and for that, but that's neglible
2014-01-20 21:59:54 < BugMaster> Gramner: this probably have something todo with this comment https://github.com/yasm/yasm/blob/master/modules/preprocs/nasm/nasm-pp.c#L1095 and values of multipliers there
2014-01-20 22:05:50 < Gramner> that's probably just part of the hash implementation (which I haven't really looked into)
2014-01-20 22:07:06 < BugMaster> yes. and this hash implementation may need NHASH to be mod2-1 to be "applying a perfectly normal hash function"
2014-01-20 22:07:25 < BugMaster> dunno if it is really so
2014-01-20 22:09:45 < Gramner> NHASH is the size ofthe hash table that stores the hashes. it doesn't affect the actual hashing algorithm
2014-01-20 22:10:11 < BugMaster> h %= NHASH;
2014-01-20 22:10:31 < Gramner> yes, that function calculates the index in the hash table
2014-01-20 22:11:12 < BugMaster> imho indexing is also part of hashing algorithm
2014-01-20 22:11:36 < Gramner> no, it just stores the hashes. the hashes themselves doesn't change
2014-01-20 22:14:32 < BugMaster> if hash sum give 1 and 17 and then you mod it by 16 they both became 1. and if you mod it by 15 they will be 1 and 2. so it is different hashes with little bit different qualities.
2014-01-20 22:14:59 < BugMaster> and optimal mod can depend from coefficients for multiplies in sum
2014-01-20 22:15:48 < BugMaster> so it not like mod2 wouldn't work. it simply can have little bit different qualities
2014-01-20 22:17:39 < BugMaster> but without original author of hash funtion it difficult to say if there was any hidden meaning there
--- Day changed Tue Jan 21 2014
--- Day changed Wed Jan 22 2014
--- Day changed Thu Jan 23 2014
--- Day changed Fri Jan 24 2014
2014-01-24 01:59:14 < theHH> Hello
2014-01-24 02:02:08 < theHH> Irc channels are always dumb
--- Day changed Sat Jan 25 2014
--- Day changed Sun Jan 26 2014
2014-01-26 18:02:50 < theHH> Hello can anyone answer my simple question
2014-01-26 18:04:00 < theHH> ?
2014-01-26 18:05:34 < JEEB> the general gist on IRC is that you don't ask to ask, you just ask
2014-01-26 18:05:52 < JEEB> because answering people with 'yes, you may ask your question' usually is not very interesting
2014-01-26 18:05:58 < JEEB> and thus people don't answer
2014-01-26 18:07:16 < theHH> How can i use an bluray mkv file to be used as input
2014-01-26 18:11:55 < theHH> How to get the uncompressed frame video for using??
2014-01-26 18:12:24 < theHH> I have compiled it but dont know how to make in yuv planer ?
2014-01-26 18:12:28 < JEEB> what's your OS?
2014-01-26 18:12:35 < theHH> Win 8
2014-01-26 18:12:44 < JEEB> ok, go grab zeranoe's ffmpeg build
2014-01-26 18:12:49 < JEEB> and then pipe its output to x265
2014-01-26 18:13:03 < theHH> Thats it?
2014-01-26 18:13:35 < JEEB> ffmpeg -i welp.m2ts -an -f yuv4mpegpipe - | x265 - -y4m --other --settings
2014-01-26 18:13:43 < JEEB> I think it was -y4m? or was it --y4m
2014-01-26 18:13:46 < JEEB> don't remember
2014-01-26 18:13:50 < JEEB> in any case, that shoulda work
2014-01-26 18:14:09 < JEEB> http://ffmpeg.zeranoe.com/builds/
2014-01-26 18:14:16 < JEEB> you can grab a static ffmpeg from here
2014-01-26 18:15:52 < theHH> Now?
2014-01-26 18:18:07 < theHH> Can megui or staxrip do it?
2014-01-26 18:23:27 < theHH> ?
2014-01-26 18:38:30 < Mandarinka> you could take the avisynth script file megui uses and pipe it to x265 (similar command like above) using avs2yuv (another program)
2014-01-26 18:39:19 < JEEB>  he left
2014-01-26 18:56:37 < Mandarinka> hmm, right
2014-01-26 18:56:44 < Mandarinka> sigh
--- Day changed Mon Jan 27 2014
2014-01-27 16:23:50 < DaKaZ__> hey all, I just saw that telestream is offering HEVC via x.265, congrats!
2014-01-27 16:27:28 < nevcairiel> too bad that the encoder is still rather bad though
2014-01-27 16:27:41 < Daemon404> still looks worse than  x264 for me
2014-01-27 16:27:43 < Daemon404> viually
2014-01-27 16:27:46 < Daemon404> vsually*
2014-01-27 16:27:49 < Daemon404> ffffffffffff
2014-01-27 16:27:51 < Daemon404> visually*
2014-01-27 16:28:36 < j-b> fuckit*
2014-01-27 16:28:37 < koda> 0xffffff
2014-01-27 19:36:12 < Easyfab> Any news for finalised  hevc in mp4 aka 14496-15 ?  because according wikipedia -> January 25, 2013: Final Draft International Standard and ITU-T Consent
2014-01-27 19:36:46 < Easyfab> so more than 1 year to finalise tha container support ???
2014-01-27 19:37:11 < nevcairiel> it got postponed and whatnot, not sure what the exact status is now
2014-01-27 19:38:54 < JEEB> yeah
2014-01-27 19:39:17 < JEEB> they have not actually done actual changes to it for over half a year tho
2014-01-27 19:39:22 < Easyfab> and we see alot of new 4k TV with HEVC support, so all is ready  except the container
2014-01-27 19:39:56 < JEEB> I wouldn't be surprised if MPEG-TS would get spec'd first :P
2014-01-27 19:40:08 < JEEB> both went to FDIS ballot some time ago
2014-01-27 19:40:13 < JEEB> Hi
2014-01-27 19:40:13 < JEEB> the codes have not yet been put in the RA because the publication of the new edition of Part 15 has been unfortunately delayed.  You will need this to see the codes used and what the requirements are, of course, but hvc1 and hev1 are both defined there.
2014-01-27 19:40:18 < JEEB> ^ last I heard about 14496-15
2014-01-27 19:40:25 < JEEB> this was jan 8th
2014-01-27 19:40:28 < Daemon404> Status: Fuck You
2014-01-27 19:41:03 < JEEB> it's FDIS so they can't actually even change it too much, yet somehow it's been going around "when will get to FDIS ballot" for more than half a year
2014-01-27 19:41:11 < JEEB> even for ISO/IEC, it's going slow
2014-01-27 19:44:46 < Easyfab> So it's more political than technical
2014-01-27 19:46:41 < JEEB> unrelated quote from another ISO/IEC related mailing list "But, no… you spend your budgets on drugs to get through each meeting.."
2014-01-27 19:47:19 < Daemon404> is that a public list?
2014-01-27 19:47:22 < Daemon404> i.e. archived
2014-01-27 19:47:28 < JEEB> it is archived
2014-01-27 19:47:31 < JEEB> you just have to register
2014-01-27 19:47:36 < Daemon404> meh
2014-01-27 20:35:21 < muggs> lol
--- Day changed Tue Jan 28 2014
--- Day changed Wed Jan 29 2014
2014-01-29 21:58:20 < guesst> Mandarinka: bot or not ? :)
2014-01-29 21:58:40 < Mandarinka> what?
2014-01-29 21:58:50 < guesst> i see you got a czech address
2014-01-29 21:58:55 < Mandarinka> and?
2014-01-29 21:59:08 < guesst> do you have any experience with h265? we are building a 4k camera in prague
2014-01-29 21:59:55 < Mandarinka> not really, I only do normal plain encoding at home (for which h265 isn't really ready yet)
2014-01-29 22:00:29 < guesst> so just 8b/h264?
2014-01-29 22:00:33 < guesst> 8bit
2014-01-29 22:01:53 < Mandarinka> 10bit h.264 actually.
2014-01-29 22:02:08 < guesst> what is the source there?
2014-01-29 22:02:22 < Mandarinka> anime dvds.
2014-01-29 22:02:55 < Mandarinka> as I said, plain (slow) encodes at home.
2014-01-29 22:03:02 < guesst> dvd is not 10 bit
2014-01-29 22:03:10 < Mandarinka> quite the silly hobby
2014-01-29 22:03:34 < Mandarinka> <guesst> dvd is not 10 bit --- it isn't, but encoding it so is supposed to be a little bit more efficient
2014-01-29 22:03:46 < guesst> ah, ok
2014-01-29 22:03:48 < Mandarinka> according to the devs (TM)
2014-01-29 22:04:32 < Mandarinka> you probably want 8bit encoding if you are going to use x264 though, since at 4K, you quite need hardware decoding
2014-01-29 22:05:41 < guesst> not sure if there is any hw decoder capable of 4k
2014-01-29 22:10:26 < Mandarinka> I heard Intel's Ivy Bridge/Haswell can do it, just not sure if at 60 fps
2014-01-29 22:10:38 < Mandarinka> http://diit.cz/clanek/test-akcelerace-4k-h264-na-integrovane-grafice/test-intel-ivy-bridge <--- from this article
2014-01-29 22:11:20 < Mandarinka> not sure about AMD/Nvidia discrete cards
2014-01-29 22:15:17 < guesst> ok, gn today
--- Day changed Thu Jan 30 2014
2014-01-30 00:44:33 < Mandarinka> https://news.ycombinator.com/item?id=7142987 https://github.com/ultravideo/kvazaar http://ultravideo.cs.tut.fi/#encoder
2014-01-30 00:44:48 < Mandarinka> seems like a finnish academic HEVC encoder (gplv2)
2014-01-30 00:45:00 < Mandarinka> probably in early stages
2014-01-30 00:45:29 < smarter> first commit in May 2012
2014-01-30 00:47:11 < Mandarinka> well, but has no bframes yet according to roadmaps, etc
2014-01-30 00:49:27 < Mandarinka> but hey, a windows build for download. I guess I can try it later :)
2014-01-30 01:04:50 < Mandarinka> hmm, the hacker news thread is full of useless gpl/bsd/patents comments.
2014-01-30 09:04:50 < j-b> 'morning
2014-01-30 15:47:07 < Daemon404> i see x265 utterly fails to build on !x86..
2014-01-30 15:54:14 < kierank> Daemon404: then fix it
2014-01-30 15:54:20 < Daemon404> cant be arsed
2014-01-30 15:54:28 < kierank> let's be honest x265 at the current state is only designed for x86
2014-01-30 15:54:31 < Daemon404> encoing 1 frame in 6 days isnt interesting
2014-01-30 15:54:41 < kierank> you've proven your own point
2014-01-30 15:54:45 < kierank> :sigh:
2014-01-30 16:00:15 < Daemon404> of course
2014-01-30 16:00:38 < Daemon404> i merely think hardcoding things like -msse2 is a bit silly.
2014-01-30 16:00:38 < j-b> but but
2014-01-30 16:00:43 < j-b> but ARM is amazing
2014-01-30 16:40:28 < muggs> the -msse2 was required in order to make gcc emit actual implementations of __sync_and_* functions
2014-01-30 16:40:38 < muggs> but, obviously, it could have been done better
2014-01-30 17:15:15 < Daemon404> muggs, also hardcoding march
2014-01-30 17:15:34 < Daemon404> its trying to use march=i686 on arm.
2014-01-30 17:44:14 < muggs> yeah, march=i686 was for __sync intrinsics, the -msse* were for the intrinsic primitives.  both in common/CMakeLists.txt
2014-01-30 17:55:53 < muggs> Daemon404: can you test arm patches if I make a few?
2014-01-30 17:55:59 < Daemon404> ye
2014-01-30 17:56:00 < Daemon404> s
2014-01-30 17:56:01 < Daemon404> btw
2014-01-30 17:56:09 < Daemon404> that camke requirement is fricking annoying
2014-01-30 17:56:18 < Daemon404> i have to compile my own cmake on 4 different distos ive tried
2014-01-30 17:56:25 < Daemon404> because distro cmake package isnt new enough
2014-01-30 17:57:30 < Daemon404> e.g. ubuntu has cmake 6.8.7
2014-01-30 17:57:30 < muggs> yeah, I know.  same happens to me with CentOS and Redhat
2014-01-30 17:57:36 < Daemon404> and we need 6.8.8
2014-01-30 17:57:43 < Daemon404> how do we depend on a minor version?
2014-01-30 17:57:54 < Daemon404> or is cmake braindead and adds features in minor versions
2014-01-30 17:58:27 < muggs> they added the whole object library feature in 2.8.8
2014-01-30 17:58:34 < Daemon404> what the fuck?
2014-01-30 18:23:44 < muggs> http://pastebin.com/30RrZF74
2014-01-30 18:24:05 < Daemon404> k
2014-01-30 18:28:39 < Daemon404> /home/daemon404/x265/source/common/primitives.cpp: In function ‘void x265_cpu_cpuid(uint32_t, uint32_t*, uint32_t*, uint32_t*, uint32_t*)’:
2014-01-30 18:28:42 < Daemon404> /home/daemon404/x265/source/common/primitives.cpp:181:5: error: impossible constraint in ‘asm’
2014-01-30 18:28:45 < Daemon404> make[2]: *** [common/CMakeFiles/common.dir/primitives.cpp.o] Error 1
2014-01-30 18:29:39 < Daemon404> makes sense
2014-01-30 18:30:01 < Daemon404> xgetbv and pals will obv fail too
2014-01-30 18:32:58 < muggs> yes, let me take a look there
2014-01-30 18:51:03 < muggs> does something as simple as this work? http://pastebin.com/QFSXCZ6f
2014-01-30 18:57:54 < Daemon404> no
2014-01-30 18:57:57 < Daemon404> same error
2014-01-30 19:05:31 < muggs> sorry, how about this one: http://pastebin.com/11B53ENC
2014-01-30 19:19:54 < Daemon404> cc1plus: error: bad value (i686) for -march switch
2014-01-30 19:19:54 < Daemon404> make[2]: *** [encoder/CMakeFiles/encoder.dir/framefilter.cpp.o] Error 1
2014-01-30 20:20:52 < kurosu_> xgetbx requires -mavx or whatever is the flag for avx, iirc
2014-01-30 20:20:59 < kurosu_> *xgetbv
2014-01-30 20:21:12 < kurosu_> last I tested (some months ago)
2014-01-30 20:21:27 < kurosu_> or maybe that was an old gcc version, can't recall
2014-01-30 22:32:45 < muggs> http://pastebin.com/Fa86C5rh
--- Day changed Fri Jan 31 2014
2014-01-31 13:59:30 < Xexe> any way to control the level of fine details? the picture seems way too smooth to me.
2014-01-31 14:00:10 < JEEB> push the quantizer/rate factor down
2014-01-31 14:00:13 < Xexe> the way it's done in x264. via deblocking strength?
2014-01-31 14:00:32 < Xexe> i use 19 at the moment
2014-01-31 14:08:42 < Xexe> crf of course, guess it's already low enough.
2014-01-31 14:09:39 < JEEB> if it's blurring it means it's trying to compress more, so lowering it will make it do less of that
2014-01-31 14:10:20 < Xexe> how x264 and x265 crfs values relate to each other? the same perceptual quality?
2014-01-31 14:10:30 < JEEB> at the moment as far as I know they don't correlate
2014-01-31 14:12:51 < Xexe> yes, but i'm comparing to x264. if i push crf even lower i won't get the desired compression efficiency.
2014-01-31 14:13:09 < Xexe> what filesize x265/x264 ratio should i expect? provided the percept quality is the same
2014-01-31 14:13:57 < Xexe> i'm trying to reach 0.5.
2014-01-31 14:14:04 < JEEB> you will not get it
2014-01-31 14:14:21 < JEEB> x265 is in very early stages and psy is very lacking to put it nicely
2014-01-31 14:14:59 < Xexe> hmmm, what then is the value i should expect right now?
2014-01-31 14:15:04 < JEEB> dunno
2014-01-31 14:15:28 < JEEB> PSNR-wise it might even beat x264 a bit, but that's PSNR, not visual quality
2014-01-31 14:15:34 < JEEB> and PSNR loves smoothing
2014-01-31 14:15:58 < Xexe> i'm looking at ssim metric
2014-01-31 14:16:32 < JEEB> the last I tested SSIM was relatively close, but I might remake the test again soon
2014-01-31 14:16:33 < Xexe> i got 0.97778
2014-01-31 14:16:53 < JEEB> also I recommend if you're going to compare SSIM that you use a 3rd party calculation tool like the one in daala's repository
2014-01-31 14:16:57 < JEEB> to make sure you calculate it the same way
2014-01-31 14:17:01 < JEEB> for both clips
2014-01-31 14:18:32 < Xexe> i should check daala xiph repo first. the internal x265 ssim routine isn't reliable enough?
2014-01-31 14:19:18 < JEEB> that's not the thing, the thing is that you want to make sure you're using the same algorithm
2014-01-31 14:19:52 < Xexe> i've discovered aq-strength can help against excessive bluring . but then again the filesize jumps way to fast
2014-01-31 14:20:11 < JEEB> you should not expect two encoders to calculate their metrics the same way
2014-01-31 14:20:17 < JEEB> that's what it boils to
2014-01-31 14:20:59 < Xexe> ahh ok, that's true. the metric was from x265 alone. source/encoded.
2014-01-31 14:25:29 < Xexe> is deblocking contribute to bluring the most? in x264 i used to tune it with deblokcing stength/threshold.
2014-01-31 14:25:56 < Xexe> or some other internal routines can smooth too?
2014-01-31 14:26:51 < Xexe> so there's no deblocking stength tuning in x265 for the moment? right?
2014-01-31 14:27:27 < JEEB> no idea
2014-01-31 14:27:33 < Xexe> ok
2014-01-31 17:38:16 < muggs> there should be an 0.7 tag today - we've fixed a number of stability issues that have been nagging for a while
2014-01-31 17:47:44 < JEEB> nice
2014-01-31 17:51:01 < muggs> the last one was a doozy - on Windows, new uint64_t[2] doesn't return a sufficiently aligned pointer.  On multi-socket Windows servers, atomic_cas was malfunctioning, leading to multiple threads working on the same row
2014-01-31 17:51:45 < muggs> which most of the time would work fine, they just did the same work; but sometimes they would catch each other changing a pointer and boom!
2014-01-31 17:52:11 < JEEB> I bet that was "fun" to debug ^^;
2014-01-31 17:52:15 < nevcairiel> who uses new to allocate basic datatypes <.<
2014-01-31 17:53:36 < muggs> obviously we used to
--- Day changed Sat Feb 01 2014
--- Day changed Sun Feb 02 2014
--- Day changed Mon Feb 03 2014
--- Log closed Mon Feb 03 00:34:29 2014
--- Log opened Mon Feb 03 09:16:49 2014
--- Log closed Mon Feb 03 09:16:49 2014
--- Log opened Mon Feb 03 13:55:35 2014
--- Day changed Tue Feb 04 2014
2014-02-04 22:57:06 < muggs> Would anyone be offended if 16bit-per-pixels builds were only supported on 64bit architectures?
2014-02-04 23:01:46 < koda> muggs: why is that?
2014-02-04 23:08:50 < muggs> it's too easy to blow past the address space limitation
--- Day changed Wed Feb 05 2014
--- Day changed Thu Feb 06 2014
2014-02-06 09:30:14 < FreeBird> Hi.I'm working on importing VBV lookahead to x265 . I've few doubts in this and need clarification.What does vbv_lookahead do in general?What are the purposes of variables like i_coded_fields_lookahead, i_cpb_delay_lookahead ?
2014-02-06 09:32:23 < Skyler_> I think those relate to weird stuff involving interlacing/pulldown and VBV?  kierank might know
2014-02-06 09:32:40 < Skyler_> VBV lookahead basically comes up with a plan for VBV based on futu frames, so that quality suffers less
2014-02-06 09:33:01 < Skyler_> it's probably not the smartest algorithm (it simply tries to achieve constant quality over the lookahead) but it's something
2014-02-06 10:25:47 < kierank> FreeBird: can't remember the specifics but they deal with weird corner cases with interlaced
2014-02-06 10:38:11 < FreeBird> Ok. I also observed while debugging that the variable i_cpb_duration is always getting the value 2. What does it mean?
2014-02-06 10:41:23 < kierank> 2 fields
2014-02-06 10:53:09 < kierank> this value only changes during pulldown
2014-02-06 11:07:30 < FreeBird> Ok. Got the point thanks.
--- Day changed Fri Feb 07 2014
2014-02-07 17:03:04 < JEEB> hmm, have there been any checks on how much wavefront processing affects compression with x265? I remember when the feature was tested in JCT-VC it was around 5% or so?
2014-02-07 17:32:44 < JEEB> oh, tried disabling wpp and that disabled threading too
2014-02-07 17:32:54 < JEEB> so no picture-based threading it seems
2014-02-07 17:34:59 < JEEB> muggs, does disabling wpp even enable any potential gains or are the coding tools pre-emptively only limited to possibilities available with wpp?
2014-02-07 17:39:15 < JEEB> oh, wpp was limited to CABAC
2014-02-07 17:39:30 < kierank> limited to cabac?
2014-02-07 17:39:36 < JEEB> why the heck did I think it also had an effect on the inter-block dependencies
2014-02-07 17:40:49 < JEEB> kierank, the CABAC probabilities of the first LCU of the second wave are reset to the probabilities obtained after processing the second LCU of the first wave, and so forth
2014-02-07 17:43:08 < JEEB> you seemingly can also convert between a wavefront and non-wavefront parallelly processible bit stream by just redoing the coding
2014-02-07 17:46:54 < kurosu_> I've heard there's a very particular setup where this is not possible but I was never explained why
2014-02-07 18:04:18 < muggs> --no-wpp -F4 gives you more x264 style frame parallelism
2014-02-07 18:04:36 < JEEB> oh
2014-02-07 18:04:50 < JEEB> I thought -F was related to WPP parallelism
2014-02-07 18:05:01 < muggs> --num-frame-threads
2014-02-07 18:05:26 < muggs> --threads is the WPP (and lookahead) thread pool
2014-02-07 18:05:27 < JEEB> yeah, but I kind of assumed it would only control WPP-related threading since it didn't fall back on it
2014-02-07 18:05:29 < JEEB> ah
2014-02-07 18:07:30 < JEEB> but yeah, if it only affects CABAC then I'm not sure if disabling WPP is needed, seems like I had somewhat incorrect view on what it was exactly
2014-02-07 18:13:07 < muggs> I missed the start of this conversation; what was it you were trying to prevent?
2014-02-07 18:13:40 < JEEB> I somehow had a misconception about what WPP actually does limit
2014-02-07 18:14:04 < JEEB> then I actually read some PDFs and it seems like WPP only affects how CABAC is handled
2014-02-07 18:14:08 < JEEB> not references
2014-02-07 18:19:46 < muggs> yeah, the compression loss from WPP is from header bloat (row starts), row byte padding, and context resets.
2014-02-07 18:20:07 < muggs> it doesn't effect analysis at all
2014-02-07 18:20:14 < JEEB> yup
2014-02-07 18:22:48 < muggs> I think I get to delete source/common/vec/intra-ssse3.cpp today
2014-02-07 18:49:28 < smarter> JEEB asked if you had any numbers on how much WPP affect compression
2014-02-07 18:49:45 < muggs> about 1%
2014-02-07 18:49:52 < smarter> that's not bad at all
2014-02-07 18:50:34 < smarter> that's for 1080p I guess?
2014-02-07 19:17:26 < Manao> for WPP, the larger the frame, the bigger the loss, because you reduce cabac's ability to adapt to the content
2014-02-07 19:19:18 < Manao> kurosu_: WPP also change how delta quantizers are written, so when converting from WPP to non WPP, you must take care to recompute all delta quantizer syntax element
2014-02-07 19:20:34 < kurosu_> ok, that might have been the reason, but I had understood it as "this combination makes it impossible"
2014-02-07 19:20:51 < kurosu_> (the conversion)
2014-02-07 19:36:33 < JEEB> http://connect.microsoft.com/VisualStudio/feedback/details/811093
2014-02-07 19:40:09 < JEEB> muggs, btw is it intended that the x265.pdb debugging symbols seem to be for the DLL, not the cli?
2014-02-07 19:40:58 < muggs> not really, what compiler?
2014-02-07 19:41:06 < JEEB> MSVC
2014-02-07 19:41:10 < muggs> oh duh, ignore that
2014-02-07 19:41:19 < JEEB> the relwithdebinfo configuration
2014-02-07 19:41:44 < JEEB> at least the last time I tried I ended up with "nope, those debug symbols ain't gonna work for me"
2014-02-07 19:41:52 < JEEB> and since the DLL has the same name
2014-02-07 19:42:05 < JEEB> (and is output to the same directory)
2014-02-07 19:42:20 < muggs> yeah, lots of name conflicts
2014-02-07 19:42:37 < muggs> if you're not using the DLL you can disable it getting built
2014-02-07 19:42:53 < JEEB> true
2014-02-07 19:43:39 < muggs> hmm; that explains why debug builds sometime need to be run twice; they can conflict writing that pdb twice
2014-02-07 19:47:20 < muggs> is that FMA issue affecting x265?  I haven't used vc12 yet
2014-02-07 19:52:25 < JEEB> well, I use vs2013 and the 64bit builds run just fine on my ivy box and on this C2D, that seems somewhat more specific, although I'm still not sure
2014-02-07 19:52:30 < JEEB> not exactly a funny bug though
2014-02-07 20:04:24 < muggs> the workaround is simple enough; we could detect vs2013 and x64 and disable fma3
--- Day changed Sat Feb 08 2014
2014-02-08 19:32:48 < LigH> Hello.
2014-02-08 19:33:36 < LigH> I'm just comparng different presets. Is it desired that the quantizer seems to fluctuate more in faster presets than in slower?
2014-02-08 19:37:17 < phc> just hang out for awhile. this channel's slow on weekends.
2014-02-08 19:38:19 < LigH> So this is a "worktime channel"? ;)
2014-02-08 19:41:12 < muggs> most development is funded, yes
2014-02-08 19:41:36 < muggs> are you referring to ABR?
2014-02-08 19:42:44 < LigH> No, CBR. Except for a few parts, the nQP and QP values appear to be pretty stable in more elaborate presets than the fastest.
2014-02-08 20:11:55 < muggs> we don't have anything called CBR, are you referring to x264?
2014-02-08 20:12:29 < LigH> Sorry ... CRF.
2014-02-08 20:13:20 < LigH> Oh, preset placebo immedately crashes.
2014-02-08 20:14:37 < LigH> I ran a loop with a small Y4M with options: --preset %preset% --psnr --ssim --log 3 --csv
2014-02-08 20:14:50 < LigH> v0.6+282
2014-02-08 20:15:29 < muggs> ah.. there were a lot of bug fixes just before the 0.7 tag; you want to be on a revision above it
2014-02-08 20:15:35 < LigH> --crf 28 is the default.
2014-02-08 20:16:08 < JEEB> btw, did some testing yesterday/today
2014-02-08 20:16:11 < JEEB> http://abload.de/img/matched_visual_opt7ryvz.png http://abload.de/img/checking00173789z9e.png
2014-02-08 20:16:15 < LigH> Well, where do I get a current binary, since 'x265.cc' stopped his autobuilds due to the trademark trouble?
2014-02-08 20:16:59 < muggs> I thought videolan did builds
2014-02-08 20:17:15 < JEEB> (that's with --preset placebo --crf 32 --tune ssim --bframes 16 --ref 16)
2014-02-08 20:17:17 < LigH> Must have missed that in pages of forum posts...
2014-02-08 20:17:38 < JEEB> (and matching bit rate x264 encode with --preset placebo)
2014-02-08 20:18:12 < JEEB> also overall clip SSIM seems to be higher on both mixed/luma/chromaB/chromaR when compared with --tune ssim x264
2014-02-08 20:18:15 < JEEB> :)
2014-02-08 20:18:25 < muggs> which is which?
2014-02-08 20:18:48 < JEEB> it's pretty obvious which is optimizing in the way that x265 currently optimizes :)
2014-02-08 20:19:05 < JEEB> (the matched_visual_opt one is x264, checking... is x265)
2014-02-08 20:19:29 < LigH> x265 is "smooth as an android's ass".
2014-02-08 20:19:54 < BugMaster> x264 was encoded with psy-rd?
2014-02-08 20:20:04 < JEEB> yes, for visual comparison
2014-02-08 20:20:43 < JEEB> http://abload.de/img/matched0jzi1.png
2014-02-08 20:20:47 < JEEB> this is x264 with --tune ssim
2014-02-08 20:20:47 < BugMaster> at such bitrates imho I would disable it. too much artefacts
2014-02-08 20:21:45 < JEEB> http://fushizen.eu/samples/hevc/hyouka/
2014-02-08 20:21:47 < JEEB> full encodes
2014-02-08 20:21:48 < muggs> that's closer to x265 output
2014-02-08 20:21:56 < JEEB> yeah
2014-02-08 20:22:11 < JEEB> psy-rd tries to create the details even if it means artifacts
2014-02-08 20:22:33 < muggs> the backgrounds match almost exactly, it seems cuTree is finally working correctly
2014-02-08 20:22:55 < LigH> Well, such extreme low-bitrate tests ... how meaningful are they?
2014-02-08 20:23:19 < JEEB> you can see more differences
2014-02-08 20:23:21 < JEEB> d'uh
2014-02-08 20:23:28 < JEEB> I'm encoding at crf 24 now because 20 is way too low for any visual comparison
2014-02-08 20:23:51 < JEEB> original picture http://abload.de/img/hyouka_op000868lyavb.png
2014-02-08 20:24:51 < LigH> OK, true, CRF 24 is already great.
2014-02-08 20:25:02 < JEEB> crf 24 encode is almost done so I can then encode the matching x264 encode after that
2014-02-08 20:25:15 < JEEB> well, 24 still leaves some artifacts around :P
2014-02-08 20:25:19 < LigH> And Anime is a quite extreme material with the sharp details.
2014-02-08 20:25:39 < JEEB> (which is the idea, the idea is to /compare/ after all)
2014-02-08 20:25:48 < muggs> do you see any less blurring in anime if --no-sao is used?
2014-02-08 20:26:00 < JEEB> I can try that later
2014-02-08 20:26:16 < JEEB> I've mostly kept to defaults, except for --ref and --bframes
2014-02-08 20:26:22 < muggs> sure
2014-02-08 20:26:29 < LigH> Where on videolan.org are x265 builds? At least not presented on the website.
2014-02-08 20:26:29 < JEEB> since for whatever reason preset placebo doesn't max those out
2014-02-08 20:28:45 < muggs> hmm, I thought we had a web page on videoalan, but I don't see it.  is j-b angry at us?
2014-02-08 20:29:27 < LigH> JEEB: Maximum parameters are not necessarily maximum efficiency... ;)
2014-02-08 20:29:44 < JEEB> LigH, I know that very well
2014-02-08 20:29:52 < JEEB> like with Microsoft's own H.264 encoder
2014-02-08 20:29:59 < JEEB> the more bframes you added the more crappy it got
2014-02-08 20:30:08 < JEEB> because it had no adaptive stuff
2014-02-08 20:30:22 < JEEB> that said, in x265 this should be fine
2014-02-08 20:30:36 < LigH> muggs: Link?
2014-02-08 20:31:53 < muggs> http://x265.ru/en has binaries but they are old.  I don't know any other place that hosts them.
2014-02-08 20:32:09 < muggs> Do you have a compiler?  We support just about everything
2014-02-08 20:32:28 < LigH> I am no C developer.
2014-02-08 20:33:02 < muggs> we can't offer binaries for download ourselves, else MPEG-LA would come after us.
2014-02-08 20:33:14 < LigH> I guess Selur could build some; but I doubt he would host them, not sure how risky that may be regarding licensing and patents.
2014-02-08 20:33:29 < LigH> That's what I mean.
2014-02-08 20:33:35 < JEEB> to be honest, if you're not a company doing it
2014-02-08 20:33:43 < JEEB> the MPEG-LA really doesn't give two beeps
2014-02-08 20:33:46 < j-b> muggs: I'm not
2014-02-08 20:33:54 < j-b> muggs: I don't get why it was not activated
2014-02-08 20:34:06 < j-b> I thought it was already done
2014-02-08 20:34:16 < j-b> will at it to the top of my todo list for 2morrow
2014-02-08 20:34:16 < muggs> so did I
2014-02-08 20:34:24 < muggs> ok, thanks.
2014-02-08 20:34:41 < j-b> now, time is for beers
2014-02-08 20:34:54 < LigH> My current build is the one supported by MeGUI.
2014-02-08 20:34:57 < muggs> enjoy
2014-02-08 20:35:03 < LigH> Cheers.
2014-02-08 20:35:19 < JEEB> hurf, my crf 24 encode isn't being liked by L-SMASH's muxer
2014-02-08 20:35:24 < JEEB> wonder what's wrong
2014-02-08 20:35:50 < Paranoialmaniac> JEEB: send sample to me :P
2014-02-08 20:35:55 < muggs> you have l-smash integrated with x265?
2014-02-08 20:36:29 < Paranoialmaniac> i never work on x265
2014-02-08 20:38:04 < JEEB> Paranoialmaniac, http://fushizen.eu/samples/hevc/hyouka/2014_02_07-hyouka_op_placebo_ssim_crf24.hevc
2014-02-08 21:00:18 < JEEB> Paranoialmaniac, could you replicate?
2014-02-08 21:00:54 < Paranoialmaniac> yes, but i'm still investigating
2014-02-08 21:01:00 < JEEB> k
2014-02-08 21:11:38 < kurosu_> *crf32.mp4 is hevc and avc.mp4 is avc ?
2014-02-08 21:12:05 < kurosu_> JEEB: because in your screenshots I wonder how far are the bitrates
2014-02-08 21:12:14 < JEEB> yes
2014-02-08 21:12:20 < JEEB> the bit rates are quite close
2014-02-08 21:12:20 < kurosu_> if the above should be fine, within 0.5%
2014-02-08 21:12:34 < JEEB> not exactly the same, but close enough
2014-02-08 21:13:29 < LigH> Some samples for those who may be interested: https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC
2014-02-08 21:15:24 < kurosu_> I'm wondering what's the impact of --no-strong-intra-smoothing on anime
2014-02-08 21:25:31 < Skyler_> is strong intra smoothing a global parameter (e.g. SPS)?
2014-02-08 21:28:21 < JEEB> s->sps->sps_strong_intra_smoothing_enable_flag
2014-02-08 21:28:23 < JEEB> seems so
2014-02-08 21:41:58 < LigH> Strange filesize development over the presets.
2014-02-08 21:42:45 < LigH> ultrafast < veryfast < faster (gets bigger); then a drop to half the size for fast.
--- Day changed Sun Feb 09 2014
2014-02-09 14:11:30 < LigH> \o
2014-02-09 14:12:08 < LigH> The guide by El Heggunte was a little brief in places; but I was successful making x265 v0.7+95 :)
2014-02-09 14:12:30 < LigH> Scene detection is certainly a useful new feature.
2014-02-09 14:16:16 < Easyfab_> Guide to build x265 ? you only need to run make-Makefiles.sh or make-solutions.bat
2014-02-09 14:21:00 < LigH> So you assume that I already have any C compiler installed? ... Nope.
2014-02-09 14:23:06 < Easyfab_> Oh, to install the build system, windows ? GCC ?
2014-02-09 14:24:23 < LigH> Yes. A few details were not really clear (CMD or MSYS console?), but I passed the test ;) and the compiling went through.
2014-02-09 14:24:58 < LigH> Now I wonder where to configure it "simply" for e.g. AMD64 CPU target or 16bpp.
2014-02-09 14:25:11 < LigH> But the Win32 build works.
2014-02-09 14:33:18 < Easyfab_> You must use msys and yes high depth is no longer an option under msys ?
2014-02-09 14:34:40 < Easyfab_> For a msys/mingw x64 build, I can give you my method, if you want.
2014-02-09 14:34:47 < LigH> I have no experience, neither with C nor with make tools nor with Linux related things in general.
2014-02-09 14:35:07 < LigH> So I wouldn't know on my own whre to search for what kind of options.
2014-02-09 14:35:16 < LigH> But...
2014-02-09 14:35:25 < LigH> I'm just running a comparison between presets.
2014-02-09 14:35:50 < LigH> First I wondered why the file sizes are so extremely different.
2014-02-09 14:36:05 < LigH> Then I wondered why the smaller files look so disgustingly bad.
2014-02-09 14:36:22 < LigH> I believe the preset control is somehow borked...
2014-02-09 14:36:29 < LigH> Will upload results soon.
2014-02-09 14:37:48 < LigH> Is there a current Evaluators' Guide for v0.7?
2014-02-09 14:38:06 < LigH> No current download on the bitbucked downloads area.
2014-02-09 14:38:07 < Easyfab_> I think that preset < fast disable cutree and so crf/size is extremely different
2014-02-09 14:39:37 < LigH> Results with preset fast and slower have only about 1/5 the size of the result of preset faster; and the quality is not comparable.
2014-02-09 14:40:06 < Easyfab_> they probably need to adjust crf setting for more consistency
2014-02-09 14:40:47 < JEEB> nah, crf was never meant to be static in any way or form
2014-02-09 14:40:56 < JEEB> if you changed settings crf is different
2014-02-09 14:41:17 < JEEB> *if you changed settings, the result of the same CRF value _will_ be different
2014-02-09 14:41:54 < JEEB> there can be extra funzies in MCW's code of course, but in general trying to expect the same from the same CRF value is very muchos not correct
2014-02-09 14:42:06 < LigH> So the default of CRF 28 fives pretty results for preset faster, and ugly results for preset fast ... hmmm. And this is intended?!
2014-02-09 14:42:10 < LigH> *gives
2014-02-09 14:42:49 < JEEB> yes, there can be differences. Just like with x264
2014-02-09 14:43:29 < LigH> I don't mean differences in terms magnifiers, but magnitudes.
2014-02-09 14:43:30 < JEEB> but as I said, there can be extra funzies in MCW's code, which is a whole separate range of discussion. The discussion starting from "adjusting crf" is completely wrong, since IIRC the CRF algo is a very simple addition on top of ABR :P
2014-02-09 14:43:53 < JEEB> also, well, currently as far as I can see x265 really doesn't have an edge over x264 unless you're doing placebo+ encoding so I have no idea why you're even testing the faster stuff
2014-02-09 14:47:45 < LigH> If you want to have an impression ... https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC
2014-02-09 14:47:57 < LigH> sintel_trailer_360_fast[er]_hevc.mp4
2014-02-09 14:48:26 < LigH> CLI: --preset %preset% --psnr --ssim --log 3 --csv
2014-02-09 14:48:51 < JEEB> As far as I can see you've completely ignored or not been able to understand what I just said. Congratulations.
2014-02-09 14:49:23 < smarter> well, he can do experimentations if he wants to
2014-02-09 14:49:44 < smarter> and it can help in tracking progress
2014-02-09 14:50:06 < JEEB> I'm more derping about the fact that someone tries to assume some things about CRF that were never true
2014-02-09 14:50:44 < JEEB> also even better when Easyfab then notes that MCW should adjust _CRF_ for it (Which seems to be a relatively simple thing on top of the ABR rate control)
2014-02-09 14:50:46 < smarter> well, crf is advertised as "constant quality"
2014-02-09 14:51:16 < JEEB> no, I've gotten scolded by pengv for calling it that :P
2014-02-09 14:51:17 < Daemon404> nobody involved in x64 or x265 advertises it as that
2014-02-09 14:51:18 < Mandarinka> well, they hear the short explanation "if you just care about certain wuality and not bitrate, use crf" and draw a logic conclusion
2014-02-09 14:51:20 < Daemon404> thats fuckign doom9
2014-02-09 14:51:26 < smarter> http://mewiki.project357.com/wiki/X264_Settings#crf
2014-02-09 14:51:47 < JEEB> it's "the closest we currently have to constant quality", but nobody ever says that it works between settings
2014-02-09 14:52:13 < Daemon404> smarter, thats not official
2014-02-09 14:52:16 < JEEB> if you change your settings and keep the CRF value the same it has never and will never mean that you get the same quality out
2014-02-09 14:52:35 < JEEB> and even that doesn't say it works between settings
2014-02-09 14:52:40 < smarter> that makes sense, but might not be obvious :)
2014-02-09 14:53:24 < LigH> I certainly understand that you shall not expect very similar visual quality for the same CRF values, but different other options. But if the results are "worlds apart", then this value has no meaning for a user.
2014-02-09 14:53:49 < JEEB> also I might even be more derping towards Easyfab_'s comment than just the idea that LigH doesn't understand what CRF is supposed to be.
2014-02-09 14:53:50 < smarter> I think the usecase is: 1) pick a set of settings 2) play with crf until it's good enough
2014-02-09 14:54:43 < JEEB> (also I'm not saying that the CRF algo can't have bugs, but I'd rather look at MCW's code than stuff that was more or less 1-1 ported from x264)
2014-02-09 14:54:52 < JEEB> *the CRF algo in x265
2014-02-09 14:56:35 < LigH> The x264 project was able to tweak their presets so that the default options should create quite convenient results for all presets; I believe x265 has this goal on a future TODO. Understandable, technical aspects are more important.
2014-02-09 15:06:20 < LigH> Easyfab_: Preset 'faster' and faster, nQP and QP are variable around 27; preset 'fast' and slower, they are quite stable at 33 for B frames.
2014-02-09 15:07:37 < LigH> Shall the use of CUTree legitimate +6 quantization?
2014-02-09 15:14:19 < LigH> I'll check again. Forgot to delete the CSV files before they get appended...
2014-02-09 15:15:22 < LigH> As far as I can see, watching the console output, the quantizer ranges are pretty different.
2014-02-09 15:17:23 < LigH> Well, I was not completely wrong.
2014-02-09 15:18:33 < LigH> In presets 'fast' (and probably slower), the quantization drops remarkably and doesn't fluctuate anymore after a brief blackness part. In faster presets, quantizers change as expected for a CRF algorithm.
2014-02-09 15:19:06 < Easyfab_> Oh JEEB is right about CRF, I was wrong , I meant ajust preset and not ajust CRF . What I meant is that for certain CRF I expect roughly the same quality whatever the preset you use .  Like X264 does .
2014-02-09 15:19:44 < JEEB> no, it's not supposed to be even /roughly/
2014-02-09 15:19:46 < JEEB> as far as I know
2014-02-09 15:20:05 < JEEB> the fact that it currently more or less works like that is just a thing caused by other factors
2014-02-09 15:20:46 < Easyfab_> But x264 give roughly the same SSIM for a certain CRF whatever the preset you use, right ?
2014-02-09 15:20:56 < JEEB> no
2014-02-09 15:21:10 < JEEB> even if you put the "roughly" in there
2014-02-09 15:22:25 < LigH> Still, I believe that it is not intended to have the quantizer almost constant at such a coarse value when CUTree is used.
2014-02-09 15:22:43 < JEEB> that's a whole separate thing then :P
2014-02-09 15:22:50 < Easyfab_> But You don't have 2 DB difference ( SSIM ) like preset faster and fast in X265
2014-02-09 15:23:26 < LigH> So my tests are not completely useless, even if their results are not much related to a meaning of CRF.
2014-02-09 15:23:59 < smarter> LigH: you know that CUTree means that QP is adjusted for each CU inside each frame, right?
2014-02-09 15:24:21 < LigH> No, I don't really know the details of this technique.
2014-02-09 15:24:56 < LigH> I don't even know the meaning of "CU" right now...
2014-02-09 15:25:00 < smarter> basically, the frame QP becomes meaningless because each block can have its own QP
2014-02-09 15:25:01 < smarter> coding unit
2014-02-09 15:25:04 < LigH> Is it already documented...
2014-02-09 15:25:35 < smarter> it's like x264 mbtree which is documented here http://x264.nl/developers/Dark_Shikari/MBtree%20paper.pdf
2014-02-09 15:25:42 < LigH> Aha. I would "roughly" ;) imagine that as very small slices across the frame.
2014-02-09 15:26:21 < LigH> xat JPEG Optimizer uses something similar to optimize JPEG compression by having different quantizers per MB.
2014-02-09 15:27:23 < LigH> So the CU quantizer adjustment may not yet work as intended?
2014-02-09 15:27:58 < smarter> why?
2014-02-09 15:29:39 < LigH> Why is it so hard for developers to put themselves into the position of a user?
2014-02-09 15:29:42 < LigH> ;)
2014-02-09 15:30:54 < LigH> Users tend to assume from experiences.
2014-02-09 15:31:36 < smarter> you can do tests by enabling and disabling CUTree and seeing what happens
2014-02-09 15:31:52 < LigH> If they made the experience that a number has a meaning, even if that is just "a coincidence", they believe in it.
2014-02-09 15:40:18 < kurosu_> jpeg doesn't have actual variable quantizer but more something like slices where you can change things
2014-02-09 15:42:14 < LigH> I guess the image is parted into as many slices as necessary to have regions of different quantizations.
2014-02-09 15:43:07 < LigH> Until today, there is no freeware tool known to me which does the same as the commercial and abandoned JPEG Optimizer...
2014-02-09 15:43:58 < kurosu_> I think loren wrote something using this to adapt huffman tables
2014-02-09 15:55:50 < kierank> there's a perl script somewhere
2014-02-09 17:49:58 < LigH> smarter: CUTree may not be the main issue. Even disabled, the quantizers get a boost from 'fast' on. And SSIM drops from ~20 dB to ~16 dB.
2014-02-09 20:35:15 < superdump> i have a vague memory of a LigH on Doom9 / Hydrogen Audio but perhaps i'm mistaken
2014-02-09 20:35:25 < superdump> a long time ago
2014-02-09 20:35:57 < LigH> Yes.
2014-02-09 20:36:01 < LigH> There I am as well.
--- Day changed Mon Feb 10 2014
2014-02-10 11:39:32 < FreeBird> Hi .what is the purpose of using MinCR in vbv?
--- Log closed Mon Feb 10 12:05:00 2014
--- Log opened Mon Feb 10 12:20:35 2014
2014-02-10 13:25:34 < kierank> oh freebird is gone
2014-02-10 13:25:38 < kierank> it's just some random thing in the spec
2014-02-10 13:25:48 < kierank> presumably to cap frame sizes for hardware
2014-02-10 18:02:34 < j-b> muggs: done
2014-02-10 18:02:36 < j-b> JEEB: ping
2014-02-10 18:02:53 < JEEB> j-b, pong
2014-02-10 18:04:15 < muggs> j-b: thanks
2014-02-10 18:10:52 < BugMaster> j-b: how about adding link from all projects page or dropdown list?
2014-02-10 18:11:20 < j-b> BugMaster: sure.
2014-02-10 18:11:26 < j-b> http://svn.videolan.org/filedetails.php?repname=VideoLAN+Websites&path=%2Fwww.videolan.org%2Fdevelopers%2Fx265.php
2014-02-10 18:11:30 < j-b> patches welcome
2014-02-10 20:02:10  * muggs unpacks a new 39" 4k monitor
2014-02-10 20:03:35 < JEEB> congrats on a nice piece of tech
2014-02-10 20:04:28 < muggs> now I need a new GPU.  only my macbook can drive it, and only at 1080p
2014-02-10 20:05:07 < muggs> heh, maybe I can wait a bit longer on my next eyeglass prescription
2014-02-10 20:14:35 <@Skyler_> muggs: eyebuydirect.com      now you can get both
2014-02-10 20:14:51 <@Skyler_> (if you're remotely serious XD)
2014-02-10 20:15:54 < muggs> I was serious, I'm overdue for a re-eval.
2014-02-10 20:34:34 < Daemon404> muggs, ping
2014-02-10 20:35:22 < muggs> Daemon404: pong
2014-02-10 20:35:32 < Daemon404> muggs,
2014-02-10 20:35:33 < Daemon404> http://pastebin.com/KpDW2hWa
2014-02-10 20:35:34 < Daemon404> what
2014-02-10 20:35:35 < Daemon404> the fuck
2014-02-10 20:35:36 < Daemon404> is this
2014-02-10 20:35:44 < Daemon404> this wrapper wil lseriously take me 30 mins to fix up
2014-02-10 20:35:54 < Daemon404> (i have existing, public code on libav-devel)
2014-02-10 20:35:59 < Daemon404> i am not going to "Coordinate with china"
2014-02-10 20:37:31 < muggs> that's fine with me; we didn't want to block you with a no-response.
2014-02-10 20:37:52 < muggs> because they haven't answered my questions, since they're mostly still on vacation
2014-02-10 20:37:58 < kierank> Daemon404: that's not uncommon
2014-02-10 20:38:21 < Daemon404> a response that is so corporate that i can barely parse it isnt much better than no response
2014-02-10 20:38:41 < Daemon404> also good job at 0 communication with libav/ffmpeg communities, which already have existing code
2014-02-10 20:38:44 < Daemon404> :V
2014-02-10 20:39:15 < muggs> they're answer will likely be 'no, we weren't working on it'
2014-02-10 20:39:30 < Daemon404> why couldnt you guys just say that
2014-02-10 20:39:37 < Daemon404> because this response is ridiculous.
2014-02-10 20:39:52 < Daemon404> i also fail ot see why this had to be done in private
2014-02-10 20:40:01 < Daemon404> i am tempted merely to forward it to x265-devel
2014-02-10 20:43:01 < muggs> I don't think that would be any problem; I think there's just an impedence mismatch on what each side consider's polite
2014-02-10 20:44:13 < Daemon404> i consider corprorate speak offensive to me
2014-02-10 20:44:50 < muggs> I'll try to answer your questions in the future before Tom gets to it then
2014-02-10 20:45:51 < phc_office> i got an email from my HR, and it was so convoluted that i sent the thing into weaselwords website - a web site that focuses on corporate-speak - and they published the whole thing
2014-02-10 20:46:16 < phc_office> it was that bad
2014-02-10 20:46:41 < muggs> HR is the worst,  political correctness to the bone
2014-02-10 20:48:56 < phc_office> our goal for excellence is to adapt our strategy to incorporate vision for the future in order to facilitate cooperation between stakeholders
2014-02-10 20:49:00 < phc_office> !
2014-02-10 20:50:02 < muggs> that's good
2014-02-10 20:50:10 < Daemon404> pfft
2014-02-10 20:50:15 < Daemon404> no synergizing?
2014-02-10 20:50:23 < Daemon404> or touching base?
2014-02-10 20:50:46 < Daemon404> muggs, also tom tried to sell us (vimeo) decoders that run an ARM once.
2014-02-10 20:50:49 < Daemon404> just a fun fact.
2014-02-10 20:50:58 < Daemon404> it was bizzarre ;)
2014-02-10 20:51:35  * muggs is not surprised
2014-02-10 21:01:21 < kierank> " I think there's just an impedence mismatch on what each side consider's polite" --> quite a nice way of putting it
2014-02-10 21:04:05 < Daemon404> man... i swear nobody on doom9 knows how to test encoders properly at all
2014-02-10 21:04:49 < JEEB> or decoders for that matter, even
2014-02-10 21:05:00 < Daemon404> that too
2014-02-10 21:10:40 < Daemon404> btw
2014-02-10 21:10:48 < Daemon404> i can set up msvc and icl nightlies for x265
2014-02-10 21:10:58 < Daemon404> if anyone wants
2014-02-10 21:12:15 < Daemon404> i run msvc and icl FATE for ffmpeg and libav anyway
2014-02-10 22:15:26 < Daemon404> http://forum.doom9.org/showpost.php?p=1667380&postcount=478
2014-02-10 22:55:30 < Daemon404> added msvc and high bit depth builds.
2014-02-10 23:13:27 < muggs> nice
--- Day changed Tue Feb 11 2014
2014-02-11 06:17:46 < muggs> j-b: the clone command on the web-page is wrong, the URL needs to be http:// not hg://
2014-02-11 17:31:07 < Daemon404> muggs, ping when youre here
2014-02-11 17:36:10 < Daemon404> i have one last question about the API
2014-02-11 17:48:37 < muggs> oh hey
2014-02-11 17:48:58 < Daemon404> muggs, so
2014-02-11 17:48:58 < Daemon404> like
2014-02-11 17:49:02 < Daemon404> why is frameRate an integer.
2014-02-11 17:49:26 < muggs> the HM had it that way; we're trying to fix that right now
2014-02-11 17:49:35 < Daemon404> yeah its pretty igly
2014-02-11 17:49:41 < Daemon404> im fudging some stuff with timebase
2014-02-11 17:49:43 < Daemon404> but its not pretty
2014-02-11 17:49:43 < muggs> so we can create a real VUI
2014-02-11 17:50:01 < Daemon404> ok
2014-02-11 17:50:17 < Daemon404> lastly: is it feasible for x265 to take timestamps for input too
2014-02-11 17:50:24 < Daemon404> right now we have to keep a buffer of inputted timestamps
2014-02-11 17:50:29 < Daemon404> and appyl x265's reordering later
2014-02-11 17:50:35 < Daemon404> so user timestamps dont get destroyed
2014-02-11 17:50:49 < muggs> implying we take frames out of order?
2014-02-11 17:50:54 < Daemon404> no
2014-02-11 17:50:58 < Daemon404> you return them out of order
2014-02-11 17:51:09 < Daemon404> we need to set the dts properly based on input timestamps
2014-02-11 17:51:12 < muggs> I think we do that for dts now
2014-02-11 17:51:26 < muggs> lookahead reorders dts
2014-02-11 17:51:38 < Daemon404> well hevc obviously reorders frames
2014-02-11 17:51:41 < Daemon404> due to bframes etc
2014-02-11 17:51:48 < Daemon404> we just need to know how
2014-02-11 17:51:50 < muggs> idxa copied the dts processing from x24
2014-02-11 17:51:54 < Daemon404> oic
2014-02-11 17:52:03 < Daemon404> i didnt see an api to input timestamps
2014-02-11 17:52:18 < muggs> just the dts on the input x265_picture
2014-02-11 17:52:38 < Daemon404> cant i set pts too?
2014-02-11 17:52:40 < Daemon404> or will it be ignored
2014-02-11 17:52:53 < muggs> you can set it, it gets carried to the output picture
2014-02-11 17:52:59 < Daemon404> excellent!
2014-02-11 17:53:16 < Daemon404> so i dont need to worry about params->frameRate except for ratecontrol
2014-02-11 17:53:17 < muggs> technically, it never moves
2014-02-11 17:53:44 < muggs> yeah.. I think it's only a real pain where duration is calculated, and elapsed time
2014-02-11 17:54:01 < Daemon404> right
2014-02-11 17:54:01 < muggs> mostly stats
2014-02-11 17:54:08 < Daemon404> well i dont care much about stats ;)
2014-02-11 17:54:12 < Daemon404> ffmpeg/libav have their own
2014-02-11 17:54:21 < muggs> ok
2014-02-11 17:54:32 < Daemon404> let me add that then submit it
2014-02-11 17:54:40 < Daemon404> i have support for 10bit input as well
2014-02-11 17:54:43 < Daemon404> should be fun.
2014-02-11 17:54:58 < muggs> yeah.. lots of fun.
2014-02-11 17:55:21 < muggs> I'm adding support for arbitrary input pixel size; we'll downscale internally to internal bit depth
2014-02-11 17:55:24 < Daemon404> also it's ... weird that shared lib stuff and pkg-config dont work from snapshots
2014-02-11 17:55:29 < Daemon404> i guess it relies on hg to otput ver info
2014-02-11 17:55:47 < muggs> ah, it needs a version
2014-02-11 17:56:01 < Daemon404> [17:52] < muggs> I'm adding support for arbitrary input pixel size; we'll downscale internally to internal bit depth <-- no need for us
2014-02-11 17:56:02 < muggs> but I thought we could read that from .hgtags
2014-02-11 17:56:06 < Daemon404> we can pass the proper bit depth
2014-02-11 17:56:14 < muggs> ok
2014-02-11 17:56:34 < Daemon404> header says only 4:2:0 is currently supported
2014-02-11 17:56:39 < Daemon404> i assume that holds?
2014-02-11 17:57:02 < muggs> 4:4:4 patches will start getting pushed this week; we've been holding them off while we squished bugs
2014-02-11 17:57:07 < Daemon404> nifty
2014-02-11 17:57:17 < Daemon404> are you subscribed to ffmpeg-devel or libav-devel?
2014-02-11 17:57:25 < Daemon404> it would be nice if you could review
2014-02-11 17:57:43 < muggs> nope; but I'll check the archives
2014-02-11 17:57:47 < Daemon404> ok
2014-02-11 17:58:06  * Daemon404 adds pts/dts stuff now
2014-02-11 17:59:43 < Daemon404> muggs, last question: if i only set input pts, will it generate output dts accordinly from said input pts?
2014-02-11 18:00:30 < muggs> nope, we never set dts internally.  just return the dts you gave us, in decode order
2014-02-11 18:01:16 < Daemon404> hmm
2014-02-11 18:01:20 < Daemon404> thats bad
2014-02-11 18:01:42 < Daemon404> x264 will set the dts properly based on input pts
2014-02-11 18:02:04 < muggs> hmm; should we set dts to last pts?
2014-02-11 18:02:44 < Daemon404> dts should just be based on input pts, but reordered in decode order, no?
2014-02-11 18:02:49 < Daemon404> if its not set on iput
2014-02-11 18:02:56 < Daemon404> maybe Skyler_ is around, or kierank or Paranoialmaniac
2014-02-11 18:03:00 < Daemon404> they know x264 better
2014-02-11 18:03:40 < muggs> staring at x264.c now
2014-02-11 18:03:40 < Paranoialmaniac> muggs: you need not set any dts for input
2014-02-11 18:04:05 < Paranoialmaniac> all dts are generated by pts properly
2014-02-11 18:04:16 < Daemon404> thats why i thought x265 was funny
2014-02-11 18:04:20 < Paranoialmaniac> even if vfr
2014-02-11 18:04:26 < Daemon404> output dts should be generated from input pts
2014-02-11 18:04:28 < Daemon404> right?
2014-02-11 18:04:32 < Paranoialmaniac> yes
2014-02-11 18:04:37 < Daemon404> yeah
2014-02-11 18:05:53 < muggs> so we only support cfr now; so if input dts is 0 we copy pts from previous frame to cur dts?
2014-02-11 18:06:08 < Daemon404> there should be no input dts at all
2014-02-11 18:06:10 < Daemon404> it doesnt make sense
2014-02-11 18:06:38 < Daemon404> this is true for cfr too
2014-02-11 18:06:43 < Paranoialmaniac> you shall not input dts
2014-02-11 18:06:43 < muggs> ok; well we have one x265_picture struct for input and output
2014-02-11 18:07:01 < Daemon404> thats what documentation is for :P
2014-02-11 18:07:08 < muggs> heh
2014-02-11 18:07:11 < Daemon404> "if dts is set on input, it is ignored"
2014-02-11 18:07:13 < Daemon404> or such.
2014-02-11 18:07:54 < muggs> right; so unconditionally set dts from prev pts.  what about frame 0?  negative duration?
2014-02-11 18:08:10 < Paranoialmaniac> duration?
2014-02-11 18:08:43 < Daemon404> he means dts probably
2014-02-11 18:08:50 < muggs> 1 / frame rate
2014-02-11 18:09:07 < Daemon404> muggs, we dont call anything 'duration' :P
2014-02-11 18:09:13 < Daemon404> only pts and dts exist in mp4 land
2014-02-11 18:09:14 < Paranoialmaniac> yes. negative dts are generated at the first few frames
2014-02-11 18:09:18 < Daemon404> and yeah
2014-02-11 18:09:32 < kierank> yeah negative dts
2014-02-11 18:09:44 < muggs> hi dtyx265
2014-02-11 18:09:44 < kierank> written specifically because gstreamer has unsigned timestamps
2014-02-11 18:09:55 < dtyx265> hi muggs
2014-02-11 18:11:10 < Daemon404> muggs, make sense now?
2014-02-11 18:11:13 < Paranoialmaniac> i think i need translation of this http://vfrmaniac.fushizen.eu/contents/pts_dts_generation.html i wrote the algorithm in japanese
2014-02-11 18:11:22 < Daemon404> annoyj
2014-02-11 18:11:24 < Daemon404> jeeb*
2014-02-11 18:12:03 < muggs> I follow the general idea; just not sure how to really test it effectively outside of something like libav
2014-02-11 18:12:23 < Daemon404> muggs, good thing i wrote a libav encoder using x265 then?
2014-02-11 18:12:40 < muggs> yes, good thing
2014-02-11 18:13:34 < Daemon404> i think dts thing is the only thing its missing before i can submit
2014-02-11 18:13:40 < Daemon404> (muxers need to know iirc)
2014-02-11 18:14:57 < muggs> working on a commit now
2014-02-11 18:15:42 < Daemon404> nifty
2014-02-11 18:16:28 < muggs> so.. to validate my mental model. you expect dts on output to be pts from input with a slight lag, in the same order
2014-02-11 18:17:15 < Paranoialmaniac> lag?
2014-02-11 18:17:20 < Daemon404> no
2014-02-11 18:17:22 < Daemon404> not same order
2014-02-11 18:17:25 < Daemon404> it will be out of order
2014-02-11 18:17:28 < Daemon404> due to b frame reordering
2014-02-11 18:17:48 < Daemon404> errrrrrrrrrrrrrrr
2014-02-11 18:17:50 < Daemon404> dts will be in order
2014-02-11 18:17:57 < Daemon404> pts will be out of order
2014-02-11 18:18:00 < muggs> yeah.
2014-02-11 18:18:15 < Paranoialmaniac> Daemon404: for avc and hevc, p and i-pictures also can be reordered
2014-02-11 18:18:18 < Daemon404> yeah
2014-02-11 18:18:24 < Daemon404> muggs, just remember to bump X265_BUILD
2014-02-11 18:18:27 < muggs> lag as in the first frame out will have a dts one before the first pts
2014-02-11 18:18:27 < Daemon404> so i can add a check
2014-02-11 18:18:43 < Paranoialmaniac> there is no lags
2014-02-11 18:18:57 < Paranoialmaniac> there is only offset between dts and pts
2014-02-11 18:19:19 < Paranoialmaniac> the output itself is delayed by reordering
2014-02-11 18:19:49 < muggs> if you consider the set of all dts, and the set of all pts, the dts set will be "behind" the pts set?
2014-02-11 18:20:16 < Paranoialmaniac> *there is no lags about between pts and dts of corresponding picture
2014-02-11 18:20:17 < Daemon404> i dont think you can describe it as 'lag'
2014-02-11 18:20:21 < Daemon404> just reordering
2014-02-11 18:20:44 < muggs> I get why you want to keep the language clean.. :)
2014-02-11 18:20:59 < Daemon404> pts/dts are fun business
2014-02-11 18:24:46 < Rodeo> does x265 support 2-pass yet?
2014-02-11 18:24:53 < Daemon404> nope
2014-02-11 18:24:58 < Paranoialmaniac> note that we can get rid of presentation delay by dts compression, somewhat hacky though
2014-02-11 18:25:03 < Daemon404> crf, abr, and cqp
2014-02-11 18:25:17 < Rodeo> 2-pass CRF???
2014-02-11 18:25:17 < Daemon404> Paranoialmaniac, i wouldnt bother with that for now
2014-02-11 18:25:22 < Daemon404> Rodeo, ?
2014-02-11 18:25:38 < Rodeo> nah, OK, you weren't answering my question, makes more sense
2014-02-11 18:25:47 < Daemon404> lol k.
2014-02-11 18:25:49 < Rodeo> though libvpx has 2-pass "CQ", whatever that is
2014-02-11 18:25:53 < Daemon404> wut
2014-02-11 18:25:58 < Daemon404> oh
2014-02-11 18:26:01 < Daemon404> waitwut.
2014-02-11 18:26:57 < muggs> VBV is being finished now; working on mid-frame updates, which is fun with WPP
2014-02-11 18:27:20 < muggs> two-pass a bit later
2014-02-11 18:27:53 < Daemon404> it shouldnt be *that* hard
2014-02-11 18:28:04 < Daemon404> isnt it mostly caculating teh ratefactor from an abr pass
2014-02-11 18:28:09 < Daemon404> and 2nd pass is crf
2014-02-11 18:28:10 < Rodeo> OK, cool
2014-02-11 18:28:13 < Daemon404> with that ratefactor
2014-02-11 18:29:49 < muggs> I expect 2-pass to be easier than VBV
2014-02-11 18:30:23 < muggs> so.. looking at the current code, I think we are ignoring dts on input and assigning it from pts
2014-02-11 18:30:57 < Daemon404> lol
2014-02-11 18:31:01 < Daemon404> so it's already correct?
2014-02-11 18:31:34  * Daemon404 tries a test encode
2014-02-11 18:32:11 < muggs> https://bitbucket.org/multicoreware/x265/src/07b5d6b82f5fbcb78ecab12cb8abcf13c78fe552/source/encoder/encoder.cpp?at=default#cl-361
2014-02-11 18:33:38 < Daemon404> btw i didnt test, but does x265.pc set the c++ stdlib correctly
2014-02-11 18:33:47 < Daemon404> i.e. libc++ on freebsd 10
2014-02-11 18:34:13 < muggs> it uses the detected stdlib found by cmake.. so I think so
2014-02-11 18:34:38 < nevcairiel> if cmake cannot do that for you, it would seem kinda futile =)
2014-02-11 18:34:49 < nevcairiel> its gotta be good for somethin'
2014-02-11 18:35:16 < Daemon404> ok
2014-02-11 18:35:26  * Daemon404 encodes foreman.cif
2014-02-11 18:35:33 < nevcairiel> you and your cif files
2014-02-11 18:37:47 < Daemon404> muggs, indeed it works
2014-02-11 18:37:55 < Daemon404> dts and pts are correct
2014-02-11 18:38:01 < muggs> cool.. idxa ftw
2014-02-11 18:38:25 < muggs> I'll go ahead and pushed these improved comments for x265_picture
2014-02-11 18:39:43 < muggs> hmm, how much does it suck that the CLI app ignores pts/dts entirely?
2014-02-11 18:40:04 < muggs> we support no muxers yet
2014-02-11 18:43:22 < Daemon404> ok
2014-02-11 18:43:26 < Daemon404> sent to ffmpeg and libav
2014-02-11 18:46:37 < muggs> don't knock cif files; we can plausibly encode those in real time :)
2014-02-11 18:46:43 < Daemon404> i dunno
2014-02-11 18:46:50 < Daemon404> preset veryfast and foreman.cif got me 20 fps
2014-02-11 18:46:52 < Daemon404> on an i7
2014-02-11 18:47:14 < Daemon404> in a vm mind you.
2014-02-11 18:47:40 < muggs> hmm, how many cores?
2014-02-11 18:48:00 < Daemon404> 4 physical, 8 logical
2014-02-11 18:48:00 < Daemon404> (HT)
2014-02-11 18:48:06 < Daemon404> mac mini i7
2014-02-11 18:48:11 < nevcairiel> you gave all your cores to the VM? :d
2014-02-11 18:48:17 < Daemon404> yep!
2014-02-11 18:48:43 < muggs> these haswell macs are quite nice
2014-02-11 18:51:46 < muggs> looking at version.cmake; we only install the shared lib if you use a tagged release source package
2014-02-11 18:52:24 < Daemon404> it installs from tip too
2014-02-11 18:52:55 < muggs> from a repo it will always install
2014-02-11 18:54:57 < muggs> the .hg_archival.txt file has a latesttag line, we should be able to use that for soname
2014-02-11 18:55:22 < Daemon404> i only grabbed a snapshot cause i was too lazy to install hg
2014-02-11 18:56:52 < muggs> the question is, should it work?  My guess is it should.
2014-02-11 18:57:01 < Daemon404> probably
2014-02-11 18:57:04 < muggs> 3-line fix
2014-02-11 18:57:20 < Daemon404> on an unrelated note
2014-02-11 18:57:28 < Daemon404> i think i scared tom away from emailing me ever again
2014-02-11 18:57:32 < Daemon404> ~o~
2014-02-11 18:58:01 < muggs> mission accomplished
2014-02-11 18:59:51 < Rodeo> :-)
2014-02-11 19:00:55 < Daemon404> also
2014-02-11 19:00:58 < Daemon404> realistically
2014-02-11 19:01:02 < Daemon404> there are no hevc muxers.
2014-02-11 19:01:10 < Daemon404> mp4 spec isnt finalized, no mkv spec iirc
2014-02-11 19:03:06 < kierank> gpac
2014-02-11 19:03:46 < JEEB> L-SMASH implements it as well
2014-02-11 19:04:01 < JEEB> everyone basically implemented it according to the last FDIS draft from last year's june
2014-02-11 19:04:20 < JEEB> and as far as I know there have been no major edits since
2014-02-11 19:04:27 < JEEB> but it hasn't entered FDIS ballot yet (!?)
2014-02-11 19:04:35 < JEEB> thus we are in this kind of limbo
2014-02-11 19:04:39 < JEEB> where in theory it could change
2014-02-11 19:04:40 < Daemon404> let me rephrase
2014-02-11 19:04:44 < Daemon404> no spec-compliant muxers
2014-02-11 19:04:49 < Paranoialmaniac> the latest draft of the mp4 spec for hevc  http://mpeg.chiariglione.org/standards/mpeg-4/carriage-nal-unit-structured-video-iso-base-media-file-format/wd-isoiec-14496
2014-02-11 19:04:59 < JEEB> Paranoialmaniac, that's amendment to the FDIS as far as I can see
2014-02-11 19:05:20 < Daemon404> its fucking annoying
2014-02-11 19:05:32 < JEEB> see how it is "Enhanced carriage"
2014-02-11 19:05:32 < Daemon404> *muxing* of all things is a bottleneck
2014-02-11 19:05:34 < JEEB> and not carriage
2014-02-11 19:05:57 < JEEB> it is already part of "Part:
2014-02-11 19:05:57 < JEEB> Carriage of NAL unit structured video in the ISO Base Media File Format"
2014-02-11 19:06:04 < JEEB> which is what the FDIS is
2014-02-11 19:06:28 < JEEB> so basically all that means is that they're working on stuff on top of the basic 14496-15 3rd ed
2014-02-11 19:07:23 < JEEB> Daemon404, yes -- it is aggravating, and is made even worse by the fact that people with access to the FDIS drafts have just gone and implemented it as if it is done
2014-02-11 19:07:24 < Paranoialmaniac> but the wd is usable as the latest reference
2014-02-11 19:07:38 < JEEB> true, but it also contains other stuff that might change in the future more
2014-02-11 19:07:42 < Daemon404> JEEB, *cough*divx*cough*
2014-02-11 19:07:44 < Daemon404> re: containers
2014-02-11 19:07:48 < JEEB> yes
2014-02-11 19:08:01 < JEEB> although we did get them change the matroska mapping to be a copy of the 14496-15 3rd ed FDIS
2014-02-11 19:28:11 < Daemon404> muggs, would be awesome if you could review the patch sometime today btw :)
2014-02-11 19:28:25 < Daemon404> there's a few constraints im unsure of
2014-02-11 19:28:31 < muggs> on my TODO list
2014-02-11 19:28:38 < Daemon404> gotcha
2014-02-11 19:29:01 < muggs> are they different patches for the two ML?
2014-02-11 19:29:09 < Daemon404> code is the same
2014-02-11 19:29:14 < Daemon404> only difference is version.h change
2014-02-11 19:29:21 < muggs> ok
2014-02-11 20:19:37 < muggs> Daemon404: there are no height/width restrictions any more
2014-02-11 20:22:32 < Daemon404> oh
2014-02-11 20:22:34 < Daemon404> coo
2014-02-11 20:22:34 < Daemon404> l
2014-02-11 20:22:42 < Daemon404> thats what i was unsure about
2014-02-11 20:24:04 < JEEB> muggs, btw how tested is the main10 encoding support?
2014-02-11 20:24:13 < JEEB> as in, does it make sense to test it right now
2014-02-11 20:24:47 < muggs> it's getting tested each night for decoder hash mismatches and obvious bugs; and it seems to be ok in that regard
2014-02-11 20:25:07 < muggs> but I think there are CRF issues; it's being looked at.
2014-02-11 20:25:18 < Daemon404> muggs, is that your only comment?
2014-02-11 20:25:29 < muggs> there's a 'teh' in one of the strings
2014-02-11 20:25:42 < Daemon404> yeah i saw
2014-02-11 20:25:54 < Daemon404> mostly looking for api usage stuff
2014-02-11 20:26:00 < muggs> ah, just saw that you saw :)
2014-02-11 20:26:16 < muggs> x265_param_free() can handle a NULL
2014-02-11 20:26:20 < JEEB> thanks :)
2014-02-11 20:26:40 < Daemon404> great
2014-02-11 20:26:53 < muggs> encoder_close(), not so much
2014-02-11 20:29:22 < muggs> I don't see any other obvious problems with it.  I can fix x265_encoder_close(), but that won't be in build 5 so it doesn't help you
2014-02-11 20:29:30 < Daemon404> nah
2014-02-11 20:30:58 < dtyx265> I just ran a test and the reconstructed video doesn't play.
2014-02-11 20:31:39 < dtyx265> Is there anything about the current state of the code where that should be expected?
2014-02-11 20:33:24 < Mandarinka> reconstructed? that should be just raw yuv, so it should work no matter how broken the contents
2014-02-11 20:34:45 < muggs> if you use `--recon recon.y4m` you can play the recon stream in VLC
2014-02-11 20:36:47 < dtyx265> it plays in vlc with no picture.
2014-02-11 20:37:10 < muggs> what type of file?
2014-02-11 20:37:38 < dtyx265> I am running on linux with not the latest hardware.  I have used cif and y4m
2014-02-11 20:39:41 < muggs> the recon y4m playing in VLC and it's all black
2014-02-11 20:39:43 < muggs> ?
2014-02-11 20:40:21 < dtyx265> not black, just no picture, vlc plays as if it were playing a silent audio file
2014-02-11 20:41:56 < muggs> can it play the input y4m file?  assuming the input cif was in y4m
2014-02-11 20:42:04 < dtyx265> yes
2014-02-11 20:42:25 < Mandarinka> when I was testing, I always reencoded it to lossless h.264
2014-02-11 20:42:40 < Mandarinka> easier :)
2014-02-11 20:43:02 < muggs> lol, I like that idea
2014-02-11 20:43:56 < muggs> does the recon file have a proper y4m header?
2014-02-11 20:44:54 < dtyx265> how can I check for that?
2014-02-11 20:45:26 < muggs> head -c 30 foo.y4m
2014-02-11 20:45:44 < Daemon404> or strings foo.y4m | head -1
2014-02-11 20:45:45 < Daemon404> ;)
2014-02-11 20:46:58 < dtyx265> (((''''&&%%$$$################
2014-02-11 20:47:17 < JEEB> so nope
2014-02-11 20:47:22 < muggs> http://wiki.multimedia.cx/index.php?title=YUV4MPEG2
2014-02-11 20:47:55 < muggs> that is probably the HEVC bitstream
2014-02-11 20:48:54 < muggs> what command line are you using for the encoder?
2014-02-11 20:50:25 < dtyx265> for the y4m, I used only -r recon.file, for the cif, I also used --fps 30 and --input-res 352x288
2014-02-11 20:51:23 < muggs> those are ignored if the input is y4m. what's the full command line?
2014-02-11 20:53:51 < dtyx265> ./x265 --fps 30 --input-res 352x288 ~/Videos/highway-cif/highway.cif -o ~/Videos/highway-cif/highway.no_vui -r ~/Videos/highway-cif/highway.reconnv
2014-02-11 20:55:10 < muggs> ah, ok.  the recon output file will be YUV unless you give it a .y4m extension add --y4m to the cli
2014-02-11 20:55:29 < dtyx265> ok, thanks
2014-02-11 20:55:37 < muggs> give it a .y4m extension *or* add --y4m, sorry
2014-02-11 20:56:19 < muggs> no wait.. --y4m is for input not output.  so it must have a .y4m extension
2014-02-11 20:57:25 < muggs> and your command line is telling the encoder highway.cif is a 4:2:0 8bit YUV file.  Which hopefully it is
2014-02-11 21:04:58 < dtyx265> yes, it is
2014-02-11 21:05:45 < dtyx265> ok, it's working now.  Thanks for the help
2014-02-11 21:07:23 < muggs> np
2014-02-11 21:12:38 < muggs> perhaps we should add a line of log info about the recon file, if one is requested
--- Day changed Wed Feb 12 2014
2014-02-12 13:18:07 < Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=bb6b1731eba2fac424ff8ad3003fe58b308debd1
2014-02-12 13:18:10 < Daemon404> or
2014-02-12 13:18:13 < Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=50ea93158d4c480f64069e8bd1da388486dcf4ba
2014-02-12 13:18:18 < JEEB> d-d-double push
2014-02-12 13:18:42 < j-b> c-c-combo
2014-02-12 13:39:03 < kierank> Daemon404: the api is stable?
2014-02-12 13:39:37 < Daemon404> should be yes
2014-02-12 13:54:19 < koda> \o/
--- Log closed Wed Feb 12 15:54:37 2014
--- Log opened Wed Feb 12 16:57:47 2014
2014-02-12 17:12:17 < JEEBcz> http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=65216
2014-02-12 17:12:21 < JEEBcz> goddamn finally
2014-02-12 17:12:26 < JEEBcz> 50.20
2014-02-12 17:12:30 < JEEBcz> aka "FDIS in progress"
2014-02-12 17:13:04 < JEEBcz> it's most definitely not gonna get kicked out at this point, and there are no edits since june so people can finally implement it
2014-02-12 17:13:06 < nevcairiel> you know these numbers by heart already? :p
2014-02-12 17:13:17 < JEEBcz> more or less
2014-02-12 17:14:08 < Daemon404> pervert
2014-02-12 17:14:32 < JEEBcz> I'm going to IRAP your BLA if you know what I mean :P
2014-02-12 17:44:54 < Daemon404> muggs, i have a small API feature request for you guys for The Future
2014-02-12 17:45:02 < Daemon404> a function to query possible params
2014-02-12 17:45:02 < muggs> k
2014-02-12 17:45:09 < Daemon404> an array of strings or w/e
2014-02-12 17:45:17 < muggs> interesting
2014-02-12 17:45:23 < Daemon404> currently user have to guess or read x265's src
2014-02-12 17:45:26 < Daemon404> x264 has ths problem too
2014-02-12 17:45:50 < Daemon404> just a Nice To Have thing
2014-02-12 17:45:54 < muggs> if we exposed param2string, would that resolve things?  you'd have to space-split it
2014-02-12 17:46:03 < Daemon404> well
2014-02-12 17:46:05 < Daemon404> more like
2014-02-12 17:46:10 < Daemon404> get_params or something
2014-02-12 17:46:15 < Daemon404> return a list of possible params
2014-02-12 17:46:27 < Daemon404> there's no pragmatic way for me to, e.g., list them in avconv's help
2014-02-12 17:46:31 < Daemon404> unless i write them out by hand
2014-02-12 17:46:42 < muggs> non-optimal
2014-02-12 17:46:50 < Daemon404> indeed
2014-02-12 17:47:49 < muggs> I'll think about that; optimally there would be one string table used for param2string, param_parse, and the CLI functions.. just to make sure they don't all get out of sync
2014-02-12 17:48:05 < Daemon404> an extern array is ok too
2014-02-12 17:48:14 < muggs> right
2014-02-12 17:48:22 < Daemon404> although
2014-02-12 17:48:31 < Daemon404> i dont think you handle them properly for dynamic linking on windows right now
2014-02-12 17:48:51 < muggs> externs?
2014-02-12 17:49:06 < Daemon404> https://github.com/DarkShikari/x264-devel/blob/master/x264.h#L46-L55
2014-02-12 17:49:10 < Daemon404> this is what x264 does
2014-02-12 17:50:12 < muggs> ah; you might need to bind them by hand then.  they are exported, I checked that far
2014-02-12 17:50:19 < Daemon404> yeah
2014-02-12 17:50:29 < Daemon404> its just if you want to link a downstream project taht is built with msvc
2014-02-12 17:50:40 < Daemon404> windows is fun.
2014-02-12 17:51:07 < Daemon404> rather, if said project wants to link to x265
2014-02-12 17:55:52 < muggs> BTW: been working on getting x265 to compile on a Raspbery Pi, just for kicks
2014-02-12 17:56:02 < Daemon404> 1 frame a day?
2014-02-12 17:56:09 < Daemon404> and then the board melts
2014-02-12 17:56:11 < muggs> it builds, doesn't yet link
2014-02-12 17:56:34 < muggs> I was mostly curious about what it would take
2014-02-12 17:57:48 < Daemon404> btw if you saw, i pushed support for x265 to avcodec
2014-02-12 18:00:09 < muggs> awesome
2014-02-12 19:19:33 < Daemon404> http://www.phoronix.com/scan.php?page=news_item&px=MTYwMTg
2014-02-12 19:19:34 < Daemon404> lulz.
2014-02-12 19:21:48 < Mandarinka> toda I randomly came upon an article ont aht web that claimed that mesa devs made Hi10p H.264 working on UVD in AMD cards.
2014-02-12 19:21:56 < Mandarinka> *on that web
2014-02-12 19:22:04 < Daemon404> the internet wouldnt lie
2014-02-12 19:22:07 < Daemon404> who do you think we are?
2014-02-12 19:23:14 < nevcairiel> Mandarinka: i read that some time ago, total misinterpretation of some changes in the code
2014-02-12 19:23:23 < nevcairiel> the hardware cannto decode it. the story ends there :p
2014-02-12 19:23:24 < JEEB> yes
2014-02-12 19:23:44 < JEEB> and there were plenty of little birdy interwebs users on #mpv-player who brought it up
2014-02-12 19:23:54 < JEEB> I think I even got quoted on some forums with my tl;dr regarding it :P
2014-02-12 19:24:03 < nevcairiel> it was funny how it spread around the web so quickly, guess some of those silly news sites posted it :p
2014-02-12 19:24:04 < Mandarinka> yeah, but the funny part is how there was no dementi at all or any sort of disclaimer that it was not true
2014-02-12 19:24:12 < Mandarinka> quality journalism
2014-02-12 19:24:15 < muggs> oh look! we're in the news :)
2014-02-12 19:24:22 < Daemon404> "news"
2014-02-12 19:24:25 < Daemon404> it's moronix
2014-02-12 19:25:02 < Daemon404> it's mostly "a guy posted a patch on the X mailing list"
2014-02-12 19:25:03 < Daemon404> and such
2014-02-12 19:25:15 < Mandarinka> <JEEB> I think I even got quoted on some forums with my tl;dr regarding it :P --- yeah, you are in the comments there. But nor the author, neither further commenters grasped it it seemed.
2014-02-12 19:25:27 < Easyfab_> Daemon404: thanks, I just try your x265 wrapper for ffmpeg and I was suprised that I can  mux in mkv :)
2014-02-12 19:25:28 < nevcairiel> sadly a whole bunch of half-witted sheeple follow every word they post on that page
2014-02-12 19:25:33 < muggs> it's hard to convey sarcasm on irc.. I need to add </sarcasm> tags
2014-02-12 19:25:48 < Daemon404> Easyfab_, i have no idea how valid that mkv is
2014-02-12 19:25:50 < nevcairiel> Easyfab_: it'll most likely not refuse to mux, but its not a spec compliant file
2014-02-12 19:26:30 < Easyfab_> less valid than Divx mkv ?
2014-02-12 19:26:33 < nevcairiel> its a bit of a design issue that it'll simply mux anything
2014-02-12 19:26:44 < nevcairiel> arent the latest divx mkv mostly valid
2014-02-12 19:26:47 < nevcairiel> but yes, completely invalid
2014-02-12 19:27:26 < nevcairiel> ffmpeg itself can probably read it, since its rather flexible
2014-02-12 19:27:31 < nevcairiel> but not all software will
2014-02-12 19:27:34 < Mandarinka> ffmpeg/libav always try to do everything (not always correctly or well) :)
2014-02-12 19:27:50 < muggs> never say no
2014-02-12 19:27:51 < Daemon404> i'd wait for mkvtoolnix to get support
2014-02-12 19:27:54 < Daemon404> which mosu is working on now
2014-02-12 19:27:59 < Daemon404> backporting from divx's fork i think
2014-02-12 19:27:59 < Mandarinka> oh, great
2014-02-12 19:28:04 < Easyfab_> So a simple remux in future can be possible
2014-02-12 19:28:08 < nevcairiel> yeah he said he would start
2014-02-12 19:28:20 < nevcairiel> Easyfab_: it will most likely not be happy to read such broken mkvs
2014-02-12 19:28:44 < nevcairiel> personally i would stay away from muxing hevc into mkv or mp4 with ffmpeg until its officially implemented
2014-02-12 19:29:35 < nevcairiel> which kinda leaves you with no containers to mux it in =p
2014-02-12 19:30:48 < JEEB> output raw annex b and use l-smash's muxer
2014-02-12 19:30:59 < Easyfab_> What are the official raw extension in ffmeg ? .hevc work but .265 doesn't
2014-02-12 19:31:07 < smarter> blame Daemon404 :p
2014-02-12 19:31:17 < JEEB> there is no official extensions
2014-02-12 19:31:21 < JEEB> *are
2014-02-12 19:31:23 < nevcairiel> i think only hevc is in the list as of now
2014-02-12 19:31:31 < nevcairiel> .hevc that is
2014-02-12 19:31:36 < JEEB> just use .hevc
2014-02-12 19:31:51 < smarter> it makes Charglione happy inside
2014-02-12 19:31:56 < Easyfab_> ok  let go for .hevc
2014-02-12 19:32:24 < JEEB> smarter, I don't give a fuck about him but I still prefer calling it hevk
2014-02-12 19:33:01 < JEEB> (or eich-ii-vii-sii)
2014-02-12 19:33:34 < smarter> I like hevc too
2014-02-12 19:33:51 < smarter> (or ache-euh-vé-cé :])
2014-02-12 19:33:59 < JEEB> :)
2014-02-12 19:34:15 < muggs> lol
2014-02-12 19:38:28 < Daemon404> you can also force it
2014-02-12 19:38:38 < Daemon404> -c:v libx265 -f hevc out.h265
2014-02-12 20:39:42 < Easyfab_> Daemon404:  http://pastebin.com/6xm1A9De  only I frames are encoded ?  Some files are ok with IPB encoding but other like this are only encoding I frames
2014-02-12 20:47:52 < nevcairiel> the warning about keyframe interval seems suspicious
2014-02-12 20:48:00 < nevcairiel> almost looks like some uninitialized data
2014-02-12 20:52:53 < Easyfab_> Some command line but with -c:v libx264 -> http://pastebin.com/YHiR3RKX
2014-02-12 20:53:02 < Easyfab_> *same
2014-02-12 20:56:42 < Daemon404> i dont know
2014-02-12 20:56:48 < Daemon404> the stats look like i initialized it properly
2014-02-12 20:56:58 < Daemon404> maybe its an x265 bug
2014-02-12 20:58:50 < Easyfab_> Can you reproduce it on some files ?  or is perhaps my x265 build broken ?
2014-02-12 20:59:38 < muggs> is that an old x265 build? it's not reporting a version number.
2014-02-12 21:01:08 < Daemon404> i cant repro it
2014-02-12 21:01:14 < Daemon404> (on linu)
2014-02-12 21:02:15 < Easyfab_> rev 6107  d83f25c
2014-02-12 21:02:40 < Easyfab_> cross build under unbuntu for windows
2014-02-12 21:05:27 < Easyfab_> I will try tomorrow directly under msys/mingw and report
2014-02-12 21:35:47 < muggs> oh, right. the version info output is triggered by the CLI
2014-02-12 23:36:55 < muggs> I think I'm going to change the name of the MSVC built shared library to "libx265" to avoid filename collisions with the CLI files (PDB and ILK)
2014-02-12 23:37:08 < JEEB> yeah, sounds good
2014-02-12 23:38:22 < muggs> you'll have libx265.[dll|exp|ilk|lib|pdb] and x265.[exe|ilk|pdb] and x265-static.lib
2014-02-12 23:39:16 < muggs> more closely matches MinGW outputs anyway
2014-02-12 23:45:34 < muggs> MSVC builds will now add version info to the DLL and EXE; unfortunately cmake and MinGW windres do not get along
--- Day changed Thu Feb 13 2014
--- Log closed Thu Feb 13 02:18:19 2014
--- Log opened Thu Feb 13 03:42:04 2014
2014-02-13 13:47:04 < Daemon404> the ailing list is funky
2014-02-13 13:47:17 < Daemon404> it allos impossible dates...
2014-02-13 13:47:24  * Daemon404 sees emails from the future
2014-02-13 13:47:41 < nevcairiel> not many things actually really block that
2014-02-13 13:47:52 < nevcairiel> spam filters typically check for it, but  clients or stuff like that...
2014-02-13 13:48:10 < Daemon404> i think the ML software should
2014-02-13 13:48:19 < Daemon404> or you get the mplayerhq ML
2014-02-13 13:48:26 < Daemon404> which has an email in its archives from like 2020
2014-02-13 13:48:30 < JEEB> lol
2014-02-13 13:52:37 < nevcairiel> i have always wondered a bit why the dates even work like that in email. why not have the sender fill in a informative date, but have the mail server set a "receiption" date which is primarily used.
2014-02-13 13:52:55 < Daemon404> yeah. exactly.
2014-02-13 13:53:02 < Daemon404> but like most old protocols its full of problems
2014-02-13 13:53:05 < Daemon404> just like e.g. ftp
2014-02-13 13:58:59 < Daemon404> maybe i should make my buildbot send an email to teh ML every time they break teh build
2014-02-13 13:59:06 < Daemon404> i dont even know how you manage that.
2014-02-13 14:50:39 < Daemon404> [ 96%] Building RC object CMakeFiles/cli.dir/x265.rc.res
2014-02-13 14:50:40 < Daemon404> fatal error RC1106: invalid option: -4
2014-02-13 14:50:42 < Daemon404> \o/
2014-02-13 20:24:37 < Daemon404> Easyfab, poing
2014-02-13 20:25:32 < Daemon404> muggs, you too
2014-02-13 20:28:42 < Easyfab> Daemon404: pong
2014-02-13 20:28:52 < Daemon404> http://pastebin.com/UQLDpBeE
2014-02-13 20:28:55 < Daemon404> this is the same issue you had
2014-02-13 20:28:56 < Daemon404> right?
2014-02-13 20:31:21 < Easyfab> Right with  static build, I try with shared build and now it's ok
2014-02-13 20:31:31 < Daemon404> O_o
2014-02-13 20:31:32 < Daemon404> wtf?
2014-02-13 20:31:36 < Daemon404> really?
2014-02-13 20:32:37 < Easyfab> yes sintel_trailer-1080.y4m is now ok but I didn't make others test
2014-02-13 20:32:46 < Daemon404> thats.... really fucked up
2014-02-13 20:32:53 < Daemon404> muggs, ping
2014-02-13 20:32:58 < Daemon404> this sounds like an x265 bu
2014-02-13 20:32:59 < Daemon404> g
2014-02-13 20:33:15 < muggs> hey
2014-02-13 20:34:22 < muggs> yeah, probably a param_parse() bug
2014-02-13 20:34:43 < Daemon404> i emaild 'gary' back
2014-02-13 20:34:44 < Daemon404> to ask
2014-02-13 20:35:39 < muggs> hmm, keyint and min-keyint are in there.  I would expect errors returned if they weren't
2014-02-13 20:36:25 < Daemon404> look at my paste
2014-02-13 20:36:31 < Daemon404> theyre clearly set
2014-02-13 20:36:49 < muggs> oh.. are you initializing pic_in->type to AUTO?
2014-02-13 20:37:36 < Daemon404> hmm, its not init'd to anything
2014-02-13 20:37:39 < muggs> sliceType = X265_TYPE_AUTO
2014-02-13 20:37:44 < Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx265.c;h=d37fa1554c5743c945461ea47608d40d7f38b201;hb=HEAD#l185
2014-02-13 20:37:57 < Daemon404> i didnt think i had to manually specify the slicetype...
2014-02-13 20:38:57 < muggs> you need to set the type, or call x265_picture_init() in it
2014-02-13 20:39:28 < muggs> right now it seems to think you're requesting I slice type for each picture
2014-02-13 20:39:58 < Daemon404> only when static linking apparently
2014-02-13 20:40:10 < Daemon404> uninit'd memory is just different i guess
2014-02-13 20:40:21 < muggs> yeah, sounds like it
2014-02-13 20:41:33 < muggs> you could init one pic structure and use it to pass all inputs; we don't keep any references to it when x265_encoder_encode() exits
2014-02-13 20:42:25 < Daemon404> Initialize an x265_picture structure to default values
2014-02-13 20:42:27 < Daemon404> doesnt  tell me much
2014-02-13 20:46:00 < muggs> x265_picture needs more docs in general
2014-02-13 20:47:14 < Daemon404> muggs, the code is weird
2014-02-13 20:47:17 < Daemon404> it memsets it to 0
2014-02-13 20:47:26 < Daemon404> so colorSpace is 0
2014-02-13 20:47:27 < Daemon404> but
2014-02-13 20:47:31 < Daemon404> #define X265_CSP_I400           0  /* yuv 4:0:0 planar */
2014-02-13 20:47:33 < Daemon404> ????
2014-02-13 20:47:45 < muggs> yes, the colorSpace is a bug; I saw that too.  Was just about to fix it.
2014-02-13 20:47:52 < muggs> we obviously don't look at it yet.
2014-02-13 20:57:08 < Daemon404> Easyfab, https://patches.libav.org/patch/47265/mbox/
2014-02-13 20:58:23 < Easyfab> Daemon404: ok with try your patch
2014-02-13 20:58:31 < Easyfab> *will
2014-02-13 21:00:12 < Daemon404> oh muggs
2014-02-13 21:00:15 < Daemon404> build is busted on msvc
2014-02-13 21:00:18 < Daemon404> .rc file fails
2014-02-13 21:00:29 < muggs> error msg?
2014-02-13 21:00:42 < Daemon404> [14:47] < Daemon404> [ 96%] Building RC object CMakeFiles/cli.dir/x265.rc.res
2014-02-13 21:00:42 < Daemon404> [14:47] < Daemon404> fatal error RC1106: invalid option: -4
2014-02-13 21:00:42 < Daemon404> [14:47] < Daemon404> \o/
2014-02-13 21:01:04 < muggs> uh
2014-02-13 21:01:16 < muggs> 4?
2014-02-13 21:01:20 < Daemon404> apparently.
2014-02-13 21:06:30 < muggs> can you paste-bin the x265.rc file it generated?
2014-02-13 21:08:41 < Daemon404> uh sec
2014-02-13 21:09:20 < Daemon404> http://pastie.org/8731076
2014-02-13 21:09:55 < muggs> ok, that looks happy
2014-02-13 21:11:14 < muggs> can you get the RC compile command line out of the build log?
2014-02-13 21:11:39 < Easyfab> Daemon404: your patch fixed the problem for me with static build :) thanks
2014-02-13 21:11:53 < Daemon404> cool
2014-02-13 21:11:58 < Daemon404> muggs, sec
2014-02-13 21:15:57 < Daemon404> rc.exe  -IC:\msys\1.0\devel\x\x265\source\. -IC:\msys\1.0\devel\x\x265\source\Lib -IC:\msys\1.0\devel\x\x265\source\common -IC:\msys\1.0\devel\x\x265\source\encoder -IC:\msys\1.0\devel\x\x265-icl64 -IC:\msys\1.0\devel\x\x265\source\compat\getopt    /W4 /WX /Ob2 /Oi /MP -DHIGH_BIT_DEPTH=0 -DLOG_CU_STATISTICS=0 -DX265_ARCH_X86=1 -DX86_64=1 -D_CRT_SECURE_NO_WARNINGS /foCMakeFiles\cli.dir\x265.rc.res C:\msys\1.0\devel\x\x265-icl64\x265.rc
2014-02-13 21:16:03 < Daemon404> (i hope that didnt get cut off)
2014-02-13 21:16:17 < muggs> looks ok
2014-02-13 21:17:14 < muggs> I wonder if the hack I added for MinGW would fix this for MSVC (removing flags).
2014-02-13 21:17:23 < Daemon404> its coming from /W4
2014-02-13 21:17:34 < Daemon404> it also hates /Ob2, /Oi, /MP
2014-02-13 21:17:35 < Daemon404> etc
2014-02-13 21:17:56 < muggs> I don't understand why this broke for you, but works on all our machines
2014-02-13 21:18:14 < Daemon404> do you have any msvs2012 boxes?
2014-02-13 21:19:25 < Daemon404> aha
2014-02-13 21:19:26 < Daemon404> got it
2014-02-13 21:19:33 < Daemon404> its picking up C:/Program Files (x86)/Windows Kits/8.0/bin/x64/rc.exe
2014-02-13 21:19:40 < Daemon404> instead of the msvs2012 one
2014-02-13 21:19:52 < muggs> can you try this: http://pastie.org/8731091
2014-02-13 21:21:33 < Daemon404> sec
2014-02-13 21:24:46 < Daemon404>         C:\PROGRA~2\WI3CF2~1\8.0\bin\x64\rc.exe  -O coff -DHIGH_BIT_DEPTH=0 -DLOG_CU_STATISTICS=0 -DX265_ARCH_X86=1 -DX8
2014-02-13 21:24:49 < Daemon404> 6_64=1 -D_CRT_SECURE_NO_WARNINGS -i C:\msys\1.0\devel\x\x265-icl64\x265.rc -o CMakeFiles\cli.dir\x265.rc.res
2014-02-13 21:25:53 < Daemon404> ov
2014-02-13 21:25:54 < Daemon404> obv*
2014-02-13 21:25:59 < Daemon404> rc != windres
2014-02-13 21:26:12 < muggs> oh, oops
2014-02-13 21:26:54 < muggs> I need to finish up my half-finished patches, then I'll fix that one
2014-02-13 21:27:06 < Daemon404> k
2014-02-13 21:30:23 < muggs> might be cleaner to just remove <DEFINES> and <FLAGS> from the CMAKE_RC_COMPILE_OBJECT string
2014-02-13 21:30:33 < muggs> I'll give that a try
2014-02-13 21:55:07 < muggs> ok, fix pushed.  tested locally on MinGW and VC11
2014-02-13 22:17:43 < muggs> j-b: pushes to hg.videolan.org are failing
--- Day changed Fri Feb 14 2014
2014-02-14 00:25:46 < JEEB> muggs, thanks for fixing the pdb problem
2014-02-14 01:07:42 < muggs> j-b: nevermind about the push problem; all on my side.  it's ok now
2014-02-14 02:01:26 < relaxed> I'm trying to build a static avconv with libx265 support but libav's configure fails with the following (config.log): http://pastebin.com/raw.php?i=3biEKNJX
2014-02-14 02:04:03 < relaxed> I don't have issues with including any other external libs statically, such as libx264 or libvpx
2014-02-14 02:04:40 < relaxed> this is on x86_64 Linux
2014-02-14 02:16:14 < relaxed> I'm using the latest source from both projects. Any ideas?
2014-02-14 02:30:41 < Daemon404> hmm
2014-02-14 02:30:59 < Daemon404> looks like maybe double pthread
2014-02-14 02:31:11 < Daemon404> which would be an issue with x265.pc
2014-02-14 02:31:28 < Daemon404> muggs, ^
2014-02-14 02:31:47 < Daemon404> i dont think -lpthread should be in the .pc file
2014-02-14 02:32:02 < Daemon404> (-pthread cflag is correct iirc?)
2014-02-14 02:32:06 < relaxed> http://pastebin.com/raw.php?i=DSWzSHgg
2014-02-14 02:32:44 < Daemon404> can you remove the -lpthread and try
2014-02-14 02:32:56 < relaxed> will do
2014-02-14 02:36:25 < relaxed> same thing http://pastebin.com/raw.php?i=apBcuiyC
2014-02-14 02:37:03 < Daemon404> hmm still two -pthread
2014-02-14 02:39:03 < Daemon404> muggs maybe knows
2014-02-14 02:39:16 < Daemon404> ill try tomorrow
2014-02-14 02:39:19 < Daemon404> 2:30am...
2014-02-14 02:39:31 < relaxed> ok, thanks. I'll lurk here
2014-02-14 02:39:36 < muggs> hello
2014-02-14 02:39:52 < Daemon404> muggs can probably help
2014-02-14 02:41:00 < muggs> oh, the -pthread -lpthread issue?
2014-02-14 02:41:34 < Daemon404> theres two -pthread
2014-02-14 02:41:37 < Daemon404> and one -pthread
2014-02-14 02:41:40 < Daemon404> somehow
2014-02-14 02:42:44 < muggs> I think we discussed making a blacklist of strings to remove from Libs.private, but nothing was ever done
2014-02-14 02:43:17 < Daemon404> it still fails in -lpthread is remove
2014-02-14 02:43:20 < Daemon404> as seen above
2014-02-14 02:44:46 < muggs> should "-lm -lc -lpthread -lrt" all be removed?
2014-02-14 02:45:06 < Daemon404> -lc sure isnt needed
2014-02-14 02:46:03 < Daemon404> ah ok its libc and pthread conflict
2014-02-14 02:46:31 < Daemon404> muggs, iirc the recommended way to use pthreads is -pthread
2014-02-14 02:46:44 < Daemon404> lm and lrt are proably needed
2014-02-14 02:46:54 < Daemon404> a blacklist may be the correct solution
2014-02-14 02:48:43 < muggs> I guess the main question is whether removing -lpthread from his x265.pc allows avconv to build
2014-02-14 02:48:52 < Daemon404> it doesnt
2014-02-14 02:48:58 < Daemon404> removing -lc proably would
2014-02-14 02:49:19 < Daemon404> since thats supposed to be handled internally
2014-02-14 02:49:35 < Daemon404> well rather, removing -lc and -lpthread
2014-02-14 02:50:00 < Daemon404> relaxed, ^
2014-02-14 02:55:05 < relaxed> I'll try and report back soon
2014-02-14 04:23:09 < relaxed> Daemon404 muggs: that did it, thanks
2014-02-14 04:25:55 < muggs> thanks, I'll push that patch then
2014-02-14 04:31:31 < relaxed> muggs: I only needed to remove -lc
2014-02-14 04:31:43 < muggs> interesting.
2014-02-14 04:32:04 < muggs> so.. is removing -lpthread bad?
2014-02-14 04:32:54 < relaxed> That I do not know.
2014-02-14 04:34:25 < relaxed> muggs: x264.pc has "Libs: -L${exec_prefix}/lib -lx264 -lpthread -lm -ldl"
2014-02-14 04:35:25 < muggs> ok; well it will be easy enough to remove it from the blacklist should it be necessary
2014-02-14 17:45:47 < muggs> any more x265.pc problems reported?
2014-02-14 17:50:27 < Daemon404> nope
2014-02-14 17:59:46 < muggs> ok, good
2014-02-14 18:07:05 < Daemon404>  /g 42
2014-02-14 18:07:09 < Daemon404> fff
2014-02-14 21:58:21 < muggs> how does ffmpeg and libav deal with 10bit encodes? for x264 and x265 these are compile options
2014-02-14 21:59:14 <@Skyler_> for decoding?
2014-02-14 21:59:28 < muggs> encoding
2014-02-14 21:59:42 <@Skyler_> well, they don't.  they don't encode h264 or h265
2014-02-14 22:00:07 <@Skyler_> you mean for calling libx264, or... ?   I'm not sure what the problem would be there
2014-02-14 22:00:38 < muggs> yeah, do they need to pick at link time whether to link an 8 or 10bit build of libx264?
2014-02-14 22:00:51 <@Skyler_> they just link to the one that's installed
2014-02-14 22:02:49 < muggs> can a 10bit build of x264 encode an 8bit stream?
2014-02-14 22:03:09 <@Skyler_> yes, by converting it
2014-02-14 22:03:49 < muggs> who does the conversion? libx264 or libav
2014-02-14 22:10:38 <@Skyler_> libav
2014-02-14 22:10:43 <@Skyler_> the caller does the conversion, whether it's x264cli or libav
2014-02-14 22:11:08 < muggs> I see, thanks.
2014-02-14 22:12:00 < Rodeo> Skyler_: is there one of the two which does a better job, or x264cli or libav*?
2014-02-14 22:12:06 < Rodeo> s/or/of
2014-02-14 22:12:13 <@Skyler_> um, I'd assume it's similar
2014-02-14 22:12:19 <@Skyler_> there's really only one way to do upconversion
2014-02-14 22:12:33 <@Skyler_> unless you count something complex like gradfunning or whatever which neither do
2014-02-14 22:12:57 < muggs> one could dither, I suppose
2014-02-14 22:13:42 <@Skyler_> you can only really dither on downconversion
2014-02-14 22:13:55 <@Skyler_> on upconversion you have to do something like reconstructing the gradients at a higher depth and dithering down from /that/
2014-02-14 22:13:58 <@Skyler_> which is what gradfun does
2014-02-14 22:36:42 < Rodeo> OK, thanks
--- Day changed Sat Feb 15 2014
--- Day changed Sun Feb 16 2014
2014-02-16 00:35:09 < funman> Rodeo: we're going to work on hevc with TypX tomorrow afternoon, wanna join us remotely?
2014-02-16 01:24:34 < Rodeo> funman: maybe
2014-02-16 01:27:46 < Rodeo> I'll talk to you tomorrow
2014-02-16 01:39:07 < koda> funman: what’s cooking? :)
2014-02-16 08:59:40 < nevcairiel> hey Daemon404, muggs broke your encoder wrapper :p
2014-02-16 15:32:12 < Rodeo> nevcairiel: how?
2014-02-16 15:32:23 < Rodeo> funman: ping
2014-02-16 15:32:47 < nevcairiel> Apparently some context member was renamed, since it was commonly used for the wrong thing, or somehting
2014-02-16 15:34:53 < funman> Rodeo: pong
2014-02-16 15:35:21 < funman> where would we put SPS/PPS/VPS in a ts? in the PID before the stream starts/
2014-02-16 15:35:23 < funman> ?*
2014-02-16 15:35:24 < Rodeo> I'm arorund for a little while, why did you have in mind yesterday re: working on HEVC?
2014-02-16 15:35:37 < Rodeo> oh, no idea…
2014-02-16 15:35:44 < funman> I think with x264 in vlc we put them in the stream once in a while
2014-02-16 15:35:52 < nevcairiel> same concept applys here
2014-02-16 15:36:01 < Rodeo> j45 is the one who knows ts
2014-02-16 15:36:21 < Rodeo> anyway, can't help you with that I'm afraid
2014-02-16 15:36:23 < nevcairiel> its just a NAL like any other, it should be before any actual frames, and for random access repeated occasionally
2014-02-16 15:36:52 < nevcairiel> TS doesn't carry codec configuration  data in any "special" way
2014-02-16 15:38:24 < funman> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/mux/mpeg/ts.c;h=e631e7e8f419b5639ad90c117732cdfc491eb289;hb=HEAD#l2178
2014-02-16 15:38:55 < Rodeo> nevcairiel: is that what you're referring to? https://bitbucket.org/multicoreware/x265/commits/b1f5fd6#chg-source/x265.h
2014-02-16 15:39:05 < nevcairiel> yeah thats it
2014-02-16 15:39:36 < Rodeo> let me check our own wrapper
2014-02-16 15:40:48 < Rodeo> OK, we're not setting it
2014-02-16 16:28:26 < funman> so we can write .ts but I don't want to use ID 0x24 if there's no official spec to not flood the net with bad files
2014-02-16 16:32:32 < funman> VLC will mux it into mp4 before libavformat ;)
2014-02-16 16:36:39 < JEEB> 14496-15 3rd ed is finally in the FDIS ballot, so you can in theory start implementing it from the last leaked draft or the first working draft of the first extension of the new HEVC stuff :D
2014-02-16 16:38:21 < funman> JEEB: TypX is on it
2014-02-16 16:38:32 < funman> with your pdf :)
2014-02-16 16:38:58 < JEEB> :)
2014-02-16 16:39:07 < JEEB> it will officially only be out in april tho :s
2014-02-16 16:39:25 < JEEB> since the ballot takes two months
2014-02-16 16:41:00 < funman> well it's boring enough to code </typX>
2014-02-16 16:41:52 < JEEB> it's kind of funny tho, they decide in the summer that it's OK to rename, then they ballot it out to actually change it and now we finally get the final ballot to get the non-AVC additions :D
2014-02-16 18:57:47 < Rodeo> ISO/IEC23008-2 is the same as the ITU-T H.265 document, correct?
2014-02-16 19:41:54 < nevcairiel> yes
2014-02-16 20:38:04 < BugMaster> This part of ISO/IEC 23008 is technically aligned with Rec. ITU-T H.265 (04/2013) but is not published as identical text.
2014-02-16 20:38:34 < BugMaster> quote from  ISO/IEC23008-2
2014-02-16 20:39:28 < JEEB> for all intents and purposes they're the same, though. I'm not even sure if they got anything into the spec during the time they played around to start the final ballot
--- Day changed Mon Feb 17 2014
2014-02-17 16:47:25 < barthalion> rather a quick question… are you going to get rid of executable stack?
--- Day changed Tue Feb 18 2014
2014-02-18 00:51:14 < dtyx265> muggs, I have added code so that a VUI can be added to the SPS.
2014-02-18 00:54:59 < dtyx265> actually, not quite yet, I have updated the command line and x265_param so that vui stuff can be passed on the command line.  I just need to add code to propagate it to the encoder object which won't take long.
2014-02-18 00:55:29 < muggs> oh, cool
2014-02-18 00:56:12 < dtyx265> my question is, other that looking at hex of encoded x265 output, is there a good way to examine encoded video to check if it actually has a VUI?
2014-02-18 00:56:47 < muggs> various stream analyzers have free evals
2014-02-18 00:57:32 < muggs> You can also enable ENC_DEC_TRACE, to get a dump of the stream
2014-02-18 00:59:25 < muggs> have you done any work to make framerate have a numerator and denominator?
2014-02-18 00:59:37 < muggs> if not, I can pick that up
2014-02-18 00:59:50 < dtyx265> not yet.
2014-02-18 01:00:47 < muggs> I was actually just fixing to work on it this evening
2014-02-18 01:01:01 < dtyx265> I have spent a lot of time trying to figure out the meaning of the VUI parameters and I am still not clear on some of them.
2014-02-18 01:01:54 < dtyx265> while there is timing related stuff, I don't know if any of them actually represents framerate
2014-02-18 01:02:09 < dtyx265> at least not as frames per second
2014-02-18 01:03:15 < dtyx265> it mostly seems tick based
2014-02-18 01:04:40 < muggs> the ticks would determine the time base, or denominator, I suppose
2014-02-18 01:09:17 < dtyx265> by the way, I tried to encode a file and it stopped immediately with "Illegal instructions"
2014-02-18 01:14:47 < muggs> that's been fixed; a primitive that was supposed to be SSE2 safe was using SSE4.1 instructions
2014-02-18 01:15:07 < muggs> I just pushed the fix a few minutes ago
2014-02-18 01:16:13 < dtyx265> thanks, my old machine is limited to SSE2Slow..
2014-02-18 15:39:38 < Daemon404> ffffs
2014-02-18 15:39:54 < Daemon404> there was no soname bump
2014-02-18 15:40:05 < Daemon404> silent api breakage :(
2014-02-18 15:40:18 < nevcairiel> technically you also used it wrong!
2014-02-18 15:40:39  * Daemon404 is building now to see what breaks
2014-02-18 15:40:45  * Daemon404 sees what he 'used wrong'
2014-02-18 15:42:10 < Daemon404> hmm
2014-02-18 15:42:22 < Daemon404> nevcairiel, it builds and runs with x265 tip
2014-02-18 15:42:25 < Daemon404> and libav master
2014-02-18 15:42:32 < Daemon404> what exactly fails?
2014-02-18 15:42:49 < nevcairiel> maybe they fixed the api break?
2014-02-18 15:42:56 < Daemon404> indeed
2014-02-18 15:42:59 < nevcairiel> lets check
2014-02-18 15:43:15 < nevcairiel> https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0
2014-02-18 15:43:17 < nevcairiel> fix ^
2014-02-18 15:43:21 < Daemon404> ah
2014-02-18 15:43:26 < nevcairiel> but you still use it wrong
2014-02-18 15:43:37 < nevcairiel> the variable is for internalBitDepth, not input
2014-02-18 15:43:42 < Daemon404> ...
2014-02-18 15:43:49 < Daemon404> how the fuck did i use it wrong when that is teh only member
2014-02-18 15:43:54 < Daemon404> and it was named that
2014-02-18 15:43:58 < nevcairiel> it was
2014-02-18 15:44:04 < Daemon404> and before when i wrote it
2014-02-18 15:44:06 < Daemon404> it WAS inut depth
2014-02-18 15:44:10 < Daemon404> it's *their* fault
2014-02-18 15:44:24 < Daemon404> the whole internal depth thing is new
2014-02-18 15:44:25 < nevcairiel> https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389
2014-02-18 15:44:44 < Daemon404> yes my libx265.c predates that
2014-02-18 15:44:46 < Daemon404> they repurposes it
2014-02-18 15:44:47 < Rodeo> probably better off not setting it at all and setting the input depth in x265_picture
2014-02-18 15:44:51 < Daemon404> repurposed*
2014-02-18 15:44:57 < nevcairiel> thats what the commit says to do
2014-02-18 15:45:18 < Daemon404> the init func for x265_pic used to copy from the x265_param
2014-02-18 15:45:21 < Daemon404> also thats an api break
2014-02-18 15:45:23 < Daemon404> teh worst kind
2014-02-18 15:45:30 < Daemon404> change behavior, not the functions/names
2014-02-18 15:45:36 < Daemon404> reporuposing stuff =s fuckign evil
2014-02-18 15:45:38 < nevcairiel> they changed the name first
2014-02-18 15:45:46 < Daemon404> without bumping API #
2014-02-18 15:45:46 < nevcairiel> they only changed it back because people complained :P
2014-02-18 15:45:49 < Daemon404> (still not bumped)
2014-02-18 15:45:54 < Daemon404> so i fail to see how it is in any way my fault
2014-02-18 15:46:17 < nevcairiel> in any case, set pic.bitDepth instead
2014-02-18 15:46:25 < Daemon404> im also sending an emai lto 265-ml
2014-02-18 15:46:33 < nevcairiel> like they care
2014-02-18 15:46:35 < Daemon404> to yell at them for poor practices
2014-02-18 15:46:53 < Daemon404> muggs probably cares
2014-02-18 15:46:56 < Daemon404> (and nobody else)
2014-02-18 15:50:18 < nevcairiel> personally the way i see it, they are free to break master as much as they want, as long as the bump is eventually added before it enters the stable branch
2014-02-18 15:50:29 < nevcairiel> cant bump the soname for every change, or you end up with INT_MAX
2014-02-18 15:50:46 < Daemon404> you absolutely should bump it for API breaking changes
2014-02-18 15:50:55 < nevcairiel> i dont agree
2014-02-18 15:51:03 < Daemon404> but moreover
2014-02-18 15:51:11 < Daemon404> you should NEVER EVER silently chaneg behavior
2014-02-18 15:51:12 < nevcairiel> not in a potentially unstable dev branch
2014-02-18 15:51:17 < Daemon404> that will allow code to keep compilign
2014-02-18 15:51:19 < Daemon404> but work differently
2014-02-18 15:51:23 < Daemon404> even if you bump teh version #
2014-02-18 15:51:25 < Daemon404> it is NOT ok.
2014-02-18 15:51:35 < nevcairiel> the original change didnt do that :p
2014-02-18 15:51:47 < Daemon404> the 'fix' was worse that the change
2014-02-18 15:52:46 < Daemon404> i did do one thing wrong in my wrapper
2014-02-18 15:52:49 < Daemon404> i forgot ot set extradata
2014-02-18 15:52:52 < Daemon404> so no muxers can use it
2014-02-18 15:52:53 < Daemon404> :D
2014-02-18 15:54:20 < nevcairiel> can libx265 create annexb like libx264?
2014-02-18 15:54:36 < Daemon404> it does the same thing afaik
2014-02-18 15:54:43 < Daemon404> the way we use it anyway
2014-02-18 16:26:47 < Daemon404> https://chromashift.org/x.txt
2014-02-18 16:26:48 < Daemon404> \o/
2014-02-18 16:27:15 < nevcairiel> you crashed it, yay?
2014-02-18 16:27:31 < Daemon404> indeed
2014-02-18 16:47:42 < Daemon404> fyi it crashes the cli util too ;)
2014-02-18 19:42:04 < Daemon404> hey muggs ping
2014-02-18 19:42:10 < Daemon404> (this isnt abou api breakage)
2014-02-18 19:42:11 < muggs> Hello
2014-02-18 19:42:17 < muggs> np
2014-02-18 19:42:38 < Daemon404> https://github.com/libav/libav/blob/master/libavcodec/libx264.c#L204-L211
2014-02-18 19:42:50 < Daemon404> is there any way to get the encoder delay in x265?
2014-02-18 19:43:03 < Daemon404> currently im not flushing frames properly when stream length < dela
2014-02-18 19:43:05 < Daemon404> y
2014-02-18 19:45:01 < muggs> let me look at x264's docs for what they're returning exactly.
2014-02-18 19:46:26 < Daemon404> ok
2014-02-18 19:46:35 < muggs> oh, it's returning the number of pictures not yet encoded, but in the encoder?
2014-02-18 19:48:56 < Daemon404> yeah
2014-02-18 19:49:59 < muggs> you could call x265_encoder_encode() until it returns 0 (empty) or -1 (error)
2014-02-18 19:52:29 < Daemon404> hmm
2014-02-18 19:52:57 < muggs> how does flush work now? it's not obvious just looking at libx265.c
2014-02-18 20:03:17 < Daemon404> muggs, im not 100% mself
2014-02-18 20:03:17 < Daemon404> myself
2014-02-18 20:32:08 < Daemon404> muggs, oh right
2014-02-18 20:32:12 < Daemon404> i have a crasher for x265
2014-02-18 20:32:22 < Daemon404> repro'd in ffmpeg and in x265's own cli
2014-02-18 20:33:11 < muggs> Those 4:4:4 changes broke RDOQ; does the repro use a very slow preset?
2014-02-18 20:33:21 < Daemon404> placebo
2014-02-18 20:33:23 < Daemon404> yea
2014-02-18 20:33:40 < muggs> yeah; they know where it's at, just haven't given me a patch for it yet.
2014-02-18 20:34:17 < Daemon404> ok
2014-02-18 20:34:24 < muggs> it sucks: I had them run those tests through the full regression suite, but apparently the bug was introduced when they were rebased to tip
2014-02-18 20:34:29 < Daemon404> https://chromashift.org/x-cli.txt
2014-02-18 20:34:34 < Daemon404> in case it helps (lolno)
2014-02-18 20:35:06 < muggs> yeah, xRateDistOptQuant
2014-02-18 20:36:40 < muggs> how do you pretty print a stack trace in gdb like that?
2014-02-18 20:42:39 < Daemon404> bt full ?
2014-02-18 20:43:00 < muggs> ah, ok
--- Day changed Wed Feb 19 2014
2014-02-19 02:03:14 < kutemo> hi, is there a way to cross-compile x265 in linux for windows?
2014-02-19 13:54:22 < j-b> good morning
2014-02-19 15:34:36 < Daemon404> j-b, at 2:30pn?
2014-02-19 15:34:37 < Daemon404> pm
2014-02-19 15:34:40 < Daemon404> assuming .fr
2014-02-19 15:49:15 < j-b> Daemon404: it's always morning on IRC
2014-02-19 15:49:25 < Daemon404> 5 oclock somewhere
2014-02-19 16:13:08 < koda> it’s always a good monring in j-bland
2014-02-19 16:28:24 < j-b> koda: indeed
2014-02-19 16:31:59 < brontosaurusrex> how would i build this on debian stable?
2014-02-19 16:32:24 < Daemon404> you first need to build a new enough cmake
2014-02-19 16:32:29 < Daemon404> debian stable is too old
2014-02-19 16:33:01 < brontosaurusrex> oh ok
2014-02-19 16:33:20 < Daemon404> 2.8.8 is the min req
2014-02-19 16:33:30 < brontosaurusrex> any static debs online?
2014-02-19 16:33:31 < Daemon404> other than that, stable's g++ will work fine
2014-02-19 16:33:41 < Daemon404> i wouldnt recommend custom debs
2014-02-19 16:33:45 < Daemon404> unless you like pain
2014-02-19 16:33:52 < brontosaurusrex> ok
2014-02-19 16:34:01  * Daemon404 does it locally and sets PATH
2014-02-19 16:35:13 < brontosaurusrex> any danger with updated cmake?
2014-02-19 16:35:18 < brontosaurusrex> for the system i mean
2014-02-19 16:35:36 < JEEB> don't overwrite your stuff and you'll be fine?
2014-02-19 16:35:38 < JEEB> use a custom --prefix
2014-02-19 16:36:19 < brontosaurusrex> so install new cmake with custom prefix?
2014-02-19 16:43:50 < JEEB> yes?
2014-02-19 16:43:58 < JEEB> /usr/local for example
2014-02-19 16:44:05 < brontosaurusrex> mkqa
2014-02-19 16:44:06 < JEEB> since that gets added to PATH by default
2014-02-19 16:44:08 < brontosaurusrex> mkay*
2014-02-19 16:44:19 < JEEB> (And that doesn't get populated by default, either)
2014-02-19 16:44:37 < JEEB> or if you don't want to touch root-only spaces at all, just set prefix to under your homedir?
2014-02-19 17:06:41 < brontosaurusrex> JEEB, yeah i'll do a homedir version
2014-02-19 17:22:05 < brontosaurusrex> hmm, actually cmake version 2.8.11.1 should be good enough no?
2014-02-19 17:23:55 < JEEB> I think so
2014-02-19 17:27:58 < brontosaurusrex> x265 [info]: HEVC encoder version 0.7+216-591ca91f0501b167 < could be
2014-02-19 17:28:06 < brontosaurusrex> I'am good
2014-02-19 17:28:57 < brontosaurusrex> so i need a yuv file?
2014-02-19 17:29:01 < brontosaurusrex> as input?
2014-02-19 17:50:34 < Daemon404> still segfaults
2014-02-19 18:00:50 < brontosaurusrex> ok, so 422 is not good enough ...
2014-02-19 18:01:06 < brontosaurusrex> y4m 444 might just work?
2014-02-19 18:03:19 < Daemon404> 4:2:0 currently crashes on slower settings
2014-02-19 18:03:24 < Daemon404> no ide about 444
2014-02-19 18:16:54 < brontosaurusrex> so how do i mux that to mp4 or mkv or something?
2014-02-19 18:18:17 < JEEB> HEVC?
2014-02-19 18:18:19 < JEEB> http://fushizen.eu/builds/l-smash/l-smash_tools_r855_b5a2d08_hevc_enabled.7z
2014-02-19 18:20:00 < JEEB> oh right, linux
2014-02-19 18:20:28 < JEEB> buildcurrent l-smash with this https://github.com/l-smash/l-smash/pull/14
2014-02-19 18:22:35 < brontosaurusrex> thanks
2014-02-19 18:23:42 < brontosaurusrex> git clone https://github.com/l-smash/l-smash.git ?
2014-02-19 18:26:53 < JEEB> something like that
2014-02-19 18:28:23 < brontosaurusrex> anything special i need to do ? http://paste.debian.net/plain/82927
2014-02-19 18:29:38 < JEEB> that pull request
2014-02-19 18:29:49 < JEEB> otherwise cil blocks ebv
2014-02-19 18:31:45 < brontosaurusrex> JEEB, sorry?
2014-02-19 18:37:08 < JEEB> patch it with the patch from the pull request
2014-02-19 18:37:18 < JEEB> otherwise the cli tool blocks HEVC muxing :P
2014-02-19 18:37:45 < brontosaurusrex> oh
2014-02-19 18:44:38 < brontosaurusrex> good, but i guess nothing plays 444 hevc?
2014-02-19 18:45:20 < j-b> sample for 444 hevc?
2014-02-19 18:45:30 < brontosaurusrex> j-b, hold on ...
2014-02-19 18:47:17 < JEEB> rext are not finished
2014-02-19 18:47:24 < JEEB> so yeah
2014-02-19 18:49:20 < brontosaurusrex> absolutely not sure if this sample is correct, but here https://dl.dropboxusercontent.com/u/79532365/tmp/bbbHEVC444.mp4
2014-02-19 18:54:00 < Mandarinka> are rande extensions just 4:4:4 and 4:2:0, or are they going to add new compression tools in general? (like high profiled of H.264)
2014-02-19 18:54:03 < brontosaurusrex> trying 420 ....
2014-02-19 18:54:10 < Mandarinka> *range extension
2014-02-19 18:54:38 < brontosaurusrex> encoding speed is not so bad at all, 360p on this crappy machine goes 25 fps
2014-02-19 18:55:10 < brontosaurusrex> default settings and 420 y4m input.
2014-02-19 19:09:16 < muggs> I guess it's all relative to your expectations
2014-02-19 19:11:08 < brontosaurusrex> muggs, thats wisdom.
2014-02-19 20:06:04 < JEEB> brontosaurusrex, basically the specification for >4:2:0 and >10bit profiles isn't ready yet so stuff like libavcodec probably isn't going to be supporting that yet :)
2014-02-19 20:06:19 < JEEB> it's called "Range Extensions" and it's one of the two additions coming for HEVC
2014-02-19 20:06:28 < brontosaurusrex> JEEB, sure, I'am just playing around
--- Day changed Thu Feb 20 2014
2014-02-20 05:58:46 < greenfountain> i have a question, when computing  frameCost (last_satd) in vbv, for each row, the difference between intracost and lowresCost(inter) of all mb are added onto the rowSatd..why is this done
2014-02-20 06:17:05 < muggs> you might find an answer by using the x264 git web interface to find the last commit that modified the line
2014-02-20 07:10:01 < greenfountain> aah ok i got it.frameCostRecalculates reset rowSatd to accumulate only inter costs of each mb, so they add intra cost difference to it later.
2014-02-20 07:36:22 < relaxed> Is there an easy way to script a different install prefix after running ./make-Makefiles.bash ?
2014-02-20 10:17:33 < brontosaurusrex> any "best" crf defaults you people use?
2014-02-20 10:17:47 < brontosaurusrex> the default is of 28 seems to be of low quality
2014-02-20 10:17:54 < brontosaurusrex> now i'am trying --crf 20
2014-02-20 10:18:05 < brontosaurusrex> -is*
2014-02-20 10:19:37 < relaxed> if it's anything like x264 you'll want 18 or lower
2014-02-20 10:20:17 < relaxed> keep going down one until you're happy
2014-02-20 10:31:31 < brontosaurusrex> can't figure out how to pipe from ffmpeg via y4m named pipe
2014-02-20 10:31:51 < brontosaurusrex> ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 fifo.y4m & x265 --crf 20 fifo.y4m -o bbb.hevc < this is not working
2014-02-20 10:33:51 < relaxed> try,  ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 -f yuv4mpegpipe -> fifo.y4m </dev/null  2>ff.log & x265 --crf 20 fifo.y4m -o bbb.hevc
2014-02-20 10:37:24 < relaxed> Do I really have to resort to awk to change the installed prefix if I don't want to run ./make-Makefiles.bash?
2014-02-20 10:39:19 < brontosaurusrex> seems like
2014-02-20 10:39:20 < brontosaurusrex> ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 -f yuv4mpegpipe - 2> /dev/null | x265 --crf 20 -o bbb.hevc - --y4m
2014-02-20 10:39:25 < brontosaurusrex> is doing something
2014-02-20 10:40:07 < relaxed> maybe cmake -D is what I'm after
2014-02-20 11:07:54 < brontosaurusrex> hrm, getting 10000 kb/s with crf 20
2014-02-20 11:08:12 < brontosaurusrex> suppose thats "average bitrate till now"?
2014-02-20 12:05:18 < fatalhalt> dsf
2014-02-20 12:05:34 < fatalhalt> compton
2014-02-20 13:33:19 < brontosaurusrex> ok, my try at big bucks bunny (crf26), https://dl.dropboxusercontent.com/u/79532365/tmp/bbb26hifi.mp4
2014-02-20 13:33:26 < brontosaurusrex> 420
2014-02-20 13:34:20 < brontosaurusrex> the "average bitrate till now" is obviously buggy, was showing 10 megabits at the end of the encode ...
2014-02-20 18:44:09 < Daemon404> muggs, https://chromashift.org/cur.txt
2014-02-20 18:44:12 < Daemon404> with tip an hr ago
2014-02-20 19:12:23 < muggs> awesome; a pile of patches got pushed last night without my review
2014-02-20 19:13:19 < muggs> the placebo bug is still there; I know where it's at but I need to analyze all the function callers to fix it properly
2014-02-20 19:13:41 < Daemon404> im starting to evaluate commercal hevc encoders too
2014-02-20 19:13:48 < Daemon404> so a workign x265 would b nice
2014-02-20 19:13:49 < Daemon404> ;P
2014-02-20 19:13:55 < Daemon404> to compare
2014-02-20 19:14:20 < Daemon404> [19:09] < muggs> awesome; a pile of patches got pushed last night without my review <-- why not move to a gatekeeper syste?
2014-02-20 19:14:28 < Daemon404> i.e. only 1-2 people with push access
2014-02-20 19:14:45 < muggs> indeed it would.  I'm trying to get an 0.8 stable tag next week
2014-02-20 19:15:07 < muggs> we do only have two people with push access; just a communication failure today
2014-02-20 19:16:25 < Daemon404> o ok
2014-02-20 19:26:19 < brontosaurusrex> Daemon404, what OS?
2014-02-20 19:33:42 < Daemon404> brontosaurusrex, thats linux
2014-02-20 19:34:01 < brontosaurusrex> well, its working for me on wheezy
2014-02-20 19:34:10 < Daemon404> it only breaks on slower presets
2014-02-20 19:34:15 < brontosaurusrex> oooohhhh
2014-02-20 19:34:21 < Daemon404> look at my log
2014-02-20 19:34:23 < Daemon404> the params
2014-02-20 19:34:29 < brontosaurusrex> i only ever tested the defaults so far
2014-02-20 19:34:40 < Daemon404> ;)
2014-02-20 19:34:46 < JEEB> the defaults aren't really interest-worth that much
2014-02-20 19:35:01 < Daemon404> only the slower presets beat x264 tright now
2014-02-20 19:35:02 < Daemon404> iirc
2014-02-20 19:35:05 < JEEB> yes
2014-02-20 19:35:28 < Daemon404> the other big issue is
2014-02-20 19:35:29 < Daemon404> no 2pass
2014-02-20 19:35:34 < Daemon404> makes x265 useless for my job
2014-02-20 19:35:34 < Daemon404> :P
2014-02-20 19:35:46 < JEEB> yeah, and it makes it hard to not match stuff for testing
2014-02-20 19:35:51 < JEEB> so you have to encode with x265 first
2014-02-20 19:35:56 < JEEB> and then match up other encoders against it
2014-02-20 19:35:57 < Daemon404> i always use crf for x265
2014-02-20 19:35:59 < Daemon404> and match with x264
2014-02-20 19:36:02 < JEEB> yup
2014-02-20 19:36:07 < JEEB> that's the only way to do it correctly right now
2014-02-20 19:36:16 < Daemon404> libvpx also has shit raecontrol
2014-02-20 19:36:20 < Daemon404> so it cant match
2014-02-20 19:36:28 < Daemon404> you have to use newton's method
2014-02-20 19:36:31 < Daemon404> -_-
2014-02-20 19:36:53 < brontosaurusrex> and speed matching?
2014-02-20 19:37:08 < Daemon404> not sure
2014-02-20 19:37:10 < Daemon404> since x265 crashes
2014-02-20 19:37:13 < Daemon404> i dont have an up to date test
2014-02-20 19:37:14 < Daemon404> ;
2014-02-20 19:37:15 < Daemon404> ;)
2014-02-20 19:37:21 < JEEB> when I tested the difference was ~10x
2014-02-20 19:37:28 < Daemon404> i mean vp9 vs x265
2014-02-20 19:37:31 < JEEB> x264's --preset placebo 10x faster
2014-02-20 19:37:43 < JEEB> than x265 --preset placebo --bframes 16 --ref 16
2014-02-20 19:37:53 < brontosaurusrex> right, so nothing to really test at this point i guess
2014-02-20 19:38:01 < Daemon404> i have high10 4k content to test on x265
2014-02-20 19:38:05 < Daemon404> i expect days of encoding
2014-02-20 19:38:13 < brontosaurusrex> unless x264 is 3 times better than x264
2014-02-20 19:38:18 < brontosaurusrex> x265*
2014-02-20 19:38:25 < Daemon404> its not
2014-02-20 19:39:57 < brontosaurusrex> so basically crf from x265 and then bitrate matched to x264
2014-02-20 19:40:06 < Daemon404> yep
2014-02-20 19:40:27 < brontosaurusrex> well, x265 clearly wins on the tests light did on doom9
2014-02-20 19:41:21 < Daemon404> i have my own issues with those tests
2014-02-20 19:41:23 < Daemon404> ;)
2014-02-20 19:41:35 < brontosaurusrex> Daemon404, share?
2014-02-20 19:41:43 < Daemon404> ill post on d9 maybe
2014-02-20 19:41:52 < Daemon404> easier public trolls than irc
2014-02-20 19:42:14 < brontosaurusrex> sounds fair
2014-02-20 19:43:26 < brontosaurusrex> anyway for /me that blender movie is the worst they did, so its really hard to be objective.
2014-02-20 19:43:36 < Daemon404> ive been testing on real content
2014-02-20 19:43:45 < Daemon404> user uploaded content from my job :P
2014-02-20 19:43:50 < Daemon404> and on 4k test clips
2014-02-20 19:43:54 < Daemon404> the beyondhd ones
2014-02-20 19:45:04 < brontosaurusrex> 10 bit stuff or what? raw red?
2014-02-20 19:45:12 < muggs> our 10bit CRF is still buggered, btw.  it uses QPs that are too high compared to 8bit CRF
2014-02-20 19:45:29 < Daemon404> brontosaurusrex, 10bit, msotly 8bit
2014-02-20 19:45:30 < JEEB> yeah, I noticed random artifacting
2014-02-20 19:45:37 < Daemon404> because user content is all 8bit
2014-02-20 19:45:38 < Daemon404> more or less
2014-02-20 19:45:44 < Daemon404> aside from 'pro' stuff
2014-02-20 19:47:21 < brontosaurusrex> i still doubt x264 would beat this default bbb encode, but i'll try tomorrow maybe https://dl.dropboxusercontent.com/u/79532365/tmp/bbb26hifi.mp4
2014-02-20 19:47:40 < Daemon404> things like BBB arent very interesting to me
2014-02-20 19:47:48 < Daemon404> theyre impossinly clean
2014-02-20 19:47:51 < Daemon404> real content isnt like that
2014-02-20 19:48:33 < brontosaurusrex> well, its not video
2014-02-20 19:48:41 < brontosaurusrex> but it is a real content.
2014-02-20 19:48:42 < danieeel> how it is with the speed of x265 encoding currently? at FHD
2014-02-20 19:49:09 < Daemon404> brontosaurusrex, it's also very biased towards blur
2014-02-20 19:49:12 < Daemon404> rather than detail
2014-02-20 19:49:13 < brontosaurusrex> i'am getting 2.2 fps (but this machine sucks)
2014-02-20 19:49:15 < Daemon404> due to its CG nature
2014-02-20 19:49:54 < brontosaurusrex> Daemon404, did you see the encode i posted?
2014-02-20 19:49:55 < Daemon404> if you look at that clip, the fur looks like crap
2014-02-20 19:49:57 < Daemon404> yes
2014-02-20 19:50:06 < brontosaurusrex> imho thats plenty of detail for 600 kbps
2014-02-20 19:50:19 < Daemon404> it's all relative
2014-02-20 19:50:30 < Daemon404> thats statement alone means nothing
2014-02-20 19:50:34 < danieeel> brontosaurusrex: thanks. hope one day we can do realtime :)
2014-02-20 19:50:52 < JEEB> danieeel, expect ~10x slower than x264 currently with settings that can possibly beat x264 (more or less, 4fps vs 0.4fps)
2014-02-20 19:51:19 < Daemon404> fyi: more asm will not make x265 suitable fast
2014-02-20 19:51:24 < Daemon404> it needs arcitectural changes
2014-02-20 19:51:27 < Daemon404> e.g. in mode decision
2014-02-20 19:52:11 < brontosaurusrex> Daemon404, ok, details aside, picture is stable enough to be watchable imho
2014-02-20 19:52:17 < brontosaurusrex> but again, thats subjective
2014-02-20 19:52:33 < Daemon404> sure, but that doesnt mean it's at all useful compared to what x264 currently is
2014-02-20 19:52:48 < Daemon404> (even if you disregard cpu time costs)
2014-02-20 19:53:13 < brontosaurusrex> well, AVC is supported by my fridge, so hevc will always loose for the next decade anyway
2014-02-20 19:53:31 < Daemon404> well see
2014-02-20 19:53:41 < Daemon404> there are a few items tah tsupport it
2014-02-20 19:53:46 < Daemon404> my phone has a hevc decoder, but its useless
2014-02-20 19:53:47 < Daemon404> ;)
2014-02-20 19:53:58 < Daemon404> would probably melt the damn thing
2014-02-20 19:53:58 < danieeel> uselless in what sense?
2014-02-20 19:54:04 < Daemon404> it's software
2014-02-20 19:54:11 < JEEB> also has to be used via the API
2014-02-20 19:54:11 < Daemon404> on an arm cortex-a15 (or 9)
2014-02-20 19:54:29 < JEEB> haven't noticed it supporting anything (container-wise) with HEVC
2014-02-20 19:54:31 < danieeel> what does it play or you havent tried?
2014-02-20 19:54:40 < JEEB> you'd have to write your own player
2014-02-20 19:54:51 < Daemon404> its not portable between phones
2014-02-20 19:54:54 < Daemon404> it's samsung specific
2014-02-20 19:54:55 < Daemon404> so nobody will
2014-02-20 19:55:06 < Daemon404> also
2014-02-20 19:55:14 < Daemon404> those smart tvs that play hevc / 4k?
2014-02-20 19:55:24 < Daemon404> they use several kW of energy
2014-02-20 19:55:27 < Daemon404> yes kilo
2014-02-20 19:55:29 < Daemon404> \o/
2014-02-20 19:55:44 < danieeel> i have not yet meat a 4k tv which can play 4k content by itself :)
2014-02-20 19:55:53 < Daemon404> there's one
2014-02-20 19:55:57 < Daemon404> that one netflix supports
2014-02-20 19:55:58 < Daemon404> the sole tv.
2014-02-20 19:56:15 < brontosaurusrex> a singular 4k smart tv?
2014-02-20 19:56:22 < danieeel> it is quite funny when you ask in a shop for such thing... the seller looks to you - "what?! You want to play 4k on a 4k tv? " :)))
2014-02-20 19:56:51 < Daemon404> muggs, btw mcw employee keeps emailing me about libx265 in libav
2014-02-20 19:56:55 < Daemon404> it's kind :V
2014-02-20 19:56:57 < Daemon404> kinda*
2014-02-20 19:57:14 < danieeel> but showing off 4k jpegs from my cam lead to the worst experience.. it is just not that nice as on a PC
2014-02-20 19:57:19 < Daemon404> lol
2014-02-20 19:57:26 < Daemon404> at the office, we just got a 4k red camera
2014-02-20 19:57:31 < Daemon404> im looking forward to making some test clips
2014-02-20 19:58:03 < brontosaurusrex> I woudn't even know how to buy that thingy
2014-02-20 19:58:10 < brontosaurusrex> with all the freaking modularity
2014-02-20 19:58:16 < Daemon404> be employed by a company who can buy it for you
2014-02-20 19:58:18 < Daemon404> thats how
2014-02-20 19:58:19 < Daemon404> :D
2014-02-20 19:58:20 < danieeel> lol, you havent seen my modularity :)
2014-02-20 19:58:50 < brontosaurusrex> Daemon404, I mean, i wouldn't even know how to buy all the pieces
2014-02-20 19:59:03 < danieeel> i wanted 4k but could not afford RED.. so I built a cam from ground
2014-02-20 19:59:03 < Daemon404> yes i didnt handle that
2014-02-20 19:59:08 < Daemon404> the production team did
2014-02-20 19:59:13 < Daemon404> i know fuck all about cameras
2014-02-20 19:59:32 < brontosaurusrex> i'am still with 7d
2014-02-20 19:59:57 < danieeel> red is not much better... still rolling shutter
2014-02-20 20:00:24 < brontosaurusrex> danieeel, and blackmagicks ?
2014-02-20 20:00:35 < danieeel> limited at 30fps
2014-02-20 20:00:43 < brontosaurusrex> rolling shutter?
2014-02-20 20:00:45 < muggs> didn't they name the camera after the color or makeup all the actors have to wear when they shoot with it?
2014-02-20 20:00:48 < danieeel> global only
2014-02-20 20:00:57 < muggs> s/or/of
2014-02-20 20:01:40 < brontosaurusrex> muggs, red one?
2014-02-20 20:02:05 < Mandarinka> <JEEB> x264's --preset placebo 10x faster
2014-02-20 20:02:05 < Mandarinka> <JEEB> than x265 --preset placebo --bframes 16 --ref 16 --- only 10x ? that doesn't actually sound *that* bad. Although x265 has no tesa.
2014-02-20 20:02:45 < brontosaurusrex> Mandarinka, preset default is 30x times faster with x264 on this machine
2014-02-20 20:05:01  * Mandarinka only cares about the slow settings
2014-02-20 20:05:03 < muggs> brontosaurusrex: yes
2014-02-20 20:05:45 < muggs> I think x264 placebo is doing more RDO than we are
2014-02-20 20:06:29 < JEEB> <brontosaurusrex> Mandarinka, preset default is 30x times faster with x264 on this machine <- you cannot really compare them that much, they are not aligned with regards to what they do AFAIK
2014-02-20 20:06:52 < JEEB> what you can, though, compare is the slowest preset (and then some, like the refs and bframes I noted)
2014-02-20 20:07:08 < brontosaurusrex> JEEB, sure, only as what devs think its a wise default.
2014-02-20 20:07:53 < JEEB> uhh, if you would comment like that when the encoder would be more mature, I would agree with you
2014-02-20 20:07:56 < JEEB> right now, nope.avi
2014-02-20 20:08:04 < brontosaurusrex> ok
2014-02-20 20:08:22 < JEEB> because right now primary concerns are more with regards to actually getting the encoder to work correctly
2014-02-20 20:08:27 < JEEB> as far as I can see
2014-02-20 20:08:32 < JEEB> and getting it actually competitive
2014-02-20 20:08:48 < brontosaurusrex> < just a user, its a blackbox for me.
2014-02-20 20:09:22 < JEEB> thus such comments are even more dangerous than you think
2014-02-20 20:09:49 < Mandarinka> JEEB might find you IRL and come one night...
2014-02-20 20:16:12 < brontosaurusrex> no, I wanna be a good friend with JEEB , so i'll admit anything
2014-02-20 20:16:23 < brontosaurusrex> how can i apologize?
2014-02-20 20:16:45 < JEEB> eh, you haven't really offended me >_>
2014-02-20 20:16:54 < brontosaurusrex> ok, so we are good?
2014-02-20 20:16:58 < JEEB> naturally
2014-02-20 20:17:02 < brontosaurusrex> thanks
2014-02-20 20:17:22 < JEEB> it's just that I was noting certain things and I'd like it if people take it into mention
2014-02-20 20:19:17 < brontosaurusrex> l8r ~
2014-02-20 20:33:25 < muggs> testing a fix for the placebo heap corruption
2014-02-20 20:54:25 < muggs> Daemon404: we crossed review comments
2014-02-20 20:54:32 < Daemon404> ?
2014-02-20 20:54:42 < Daemon404> oh
2014-02-20 20:54:50 < Daemon404> i have a hard time reading your emails
2014-02-20 20:54:51 < Daemon404> it's mangled html
2014-02-20 20:54:59 < Daemon404> eally ugly, big fonts
2014-02-20 20:55:16 < muggs> seriously? I thought gmail was configured for plain text
2014-02-20 20:55:29 < Daemon404> no
2014-02-20 20:55:32 < Daemon404> yours are always html
2014-02-20 20:55:43 < muggs> crap
2014-02-20 20:56:00 < Daemon404> moreover
2014-02-20 20:56:06 < Daemon404> the text version (its sent as both)
2014-02-20 20:56:10 < Daemon404> is flowed
2014-02-20 20:58:46 < muggs> someone should have slapped me around earlier
2014-02-20 20:58:55 < muggs> I sent a test response, is it better>
2014-02-20 21:15:42 < muggs> placebo crash fixed, but there is still a hash mistake at the slower presets that we're debugging
2014-02-20 22:30:57 < Rodeo> Daemon404: so they committed the VUI stuff without any of the improvements suggested by muggs?
2014-02-20 22:34:51 < dtyx265> Rodeo, I am working on it...
2014-02-20 22:35:18 < Rodeo> yeah, as long as the API is there, it's fixable, still
2014-02-20 22:35:52 < Rodeo> nice that this is finally here anyway
2014-02-20 22:41:07 < dtyx265> It still needs work, I think I have only completed the easy part of VUI support
--- Day changed Fri Feb 21 2014
2014-02-21 04:49:41 < relaxed> Should `make x265-static` create a static cli x265? Because I'm not seeing it.
2014-02-21 04:52:02 < relaxed> For a project that wants to be similar to x264 you sure diverged from from how it's maintained and built :/
2014-02-21 17:05:30 < Daemon404>     /* Aspect ratio idc to be added to the VUI.  The default is 0 indicating
2014-02-21 17:05:31 < Daemon404>      * the apsect ratio is unspecified.  If set to EXTENDED_SAR(255) then
2014-02-21 17:05:31 < Daemon404>      * sarWidth and sarHeight must also be set. */
2014-02-21 17:05:31 < Daemon404>     int       aspectRatioIdc;
2014-02-21 17:05:33 < Daemon404> how useless
2014-02-21 17:05:39 < Daemon404> EXTENDED_SAR(255) isnt defiend anywhere
2014-02-21 17:06:02 < Daemon404> oh it's just shitty spacing
2014-02-21 17:06:12 < Daemon404> s/R(/R (/
2014-02-21 17:06:24 < JEEB> yeah
2014-02-21 17:25:27 < Daemon404> x265 [error]: Search method is not supported value (0:DIA 1:HEX 2:UMH 3:HM 5:FULL)
2014-02-21 17:25:27 < Daemon404> x265 [error]: failed to open encoder
2014-02-21 17:25:31 < Daemon404> with --me 5
2014-02-21 17:25:35 < Daemon404> someone has problems counting
2014-02-21 17:29:00 < Nosomy> where is 4?
2014-02-21 17:29:20 < Daemon404> thatsthepoint.jg
2014-02-21 17:29:22 < Daemon404> jpg
2014-02-21 17:36:46 < nevcairiel> Daemon404: i think you should be setting x265_picture.bitDepth based on the pixel format
2014-02-21 17:37:04 < Daemon404> look at the documents for it.
2014-02-21 17:37:18 < Daemon404> "must be" 8, and "must be" 10
2014-02-21 17:37:21 < Daemon404> according to x265.h
2014-02-21 17:37:29 < nevcairiel> https://bitbucket.org/multicoreware/x265/src/5e2043f89aa11363dffe33a0ff06550a7d862326/source/x265.h?at=default#cl-100
2014-02-21 17:37:32 < nevcairiel> doesnt say that here
2014-02-21 17:38:00 < Daemon404> oh, i was referring to internalBitDepth
2014-02-21 17:38:06 < nevcairiel> well i wasnt :P
2014-02-21 17:38:09  * Daemon404 was hopign to be lazy and have picture_init set it
2014-02-21 17:38:26 < nevcairiel> how would it know, you dont tell it the actual input depth anymore
2014-02-21 17:38:47 < Daemon404> yeah
2014-02-21 17:38:52 < Daemon404> i noticed now
2014-02-21 17:41:49 < Daemon404> nevcairiel, ... as a libav dev OKs the whole set
2014-02-21 17:41:54 < Daemon404> before i get a v2 sent
2014-02-21 17:41:56 < Daemon404> lulz
2014-02-21 17:42:08 < nevcairiel> every commit is reviewed
2014-02-21 17:42:23 < nevcairiel> they never said a quality review
2014-02-21 17:42:34 < Daemon404> hah
2014-02-21 17:43:30 < Daemon404> errrrr
2014-02-21 17:43:31 < Daemon404>  if (pic_in->colorSpace != param.internalCsp)
2014-02-21 17:43:31 < Daemon404>         {
2014-02-21 17:43:31 < Daemon404>             x265_log(&param, X265_LOG_ERROR, "Unsupported color space (%d) on input\n",
2014-02-21 17:43:34 < Daemon404>                      pic_in->colorSpace);
2014-02-21 17:43:37 < Daemon404>             return -1;
2014-02-21 17:43:39 < Daemon404>         }
2014-02-21 17:43:44 < Daemon404> i guess the v2 is correct, but still lulz
2014-02-21 17:44:11  * Daemon404 should remove 8bt input for a 10/12 bit build i guess...
2014-02-21 17:44:17 < Daemon404> or no, fuck that
2014-02-21 17:44:17 < nevcairiel> wonder why pic_in gets a colorSpace anyway, just document that it has to be the same as you initialized with
2014-02-21 17:44:33 < Daemon404> init sets it like that yes
2014-02-21 17:44:41 < Daemon404> also my brain mixed up csp and bitdepth right now
2014-02-21 17:44:46 < Daemon404> i blame swscale for mixing the two
2014-02-21 17:44:50 < nevcairiel> heh
2014-02-21 17:45:25 < nevcairiel> yeah bitdepth differences are fine
2014-02-21 17:45:28 < nevcairiel> it'll juts shift around
2014-02-21 17:47:35 < Daemon404> yea
2014-02-21 17:47:40 < Daemon404> anyway i sent a v2
2014-02-21 17:47:48 < Daemon404> thanks for teh (actual) review
2014-02-21 19:27:16 < Daemon404> as far as i can tell --extended-sar is completely broken
2014-02-21 19:27:23  * Daemon404 is luckily using the api directly instead of x265 cli
2014-02-21 19:28:58 < Daemon404> oh
2014-02-21 19:29:14 < Daemon404> it was a previous cli argu silently eating the next param
2014-02-21 19:29:15 < Daemon404> via atoi
2014-02-21 19:29:21 < Daemon404> thats... pretty ugly
2014-02-21 19:29:23  * Daemon404 may fix
2014-02-21 19:35:47 < muggs> ooh, nice
2014-02-21 19:36:38 < muggs> oh, I thought perhaps it didn't say it needed an argument.  what's broken with it?
2014-02-21 19:36:50 < Daemon404> muggs, e.g. if oyu do
2014-02-21 19:37:02 < Daemon404> --sar --extended-sar 1x1
2014-02-21 19:37:06 < Daemon404> since --sar needs a param
2014-02-21 19:37:10 < Daemon404> --extended-sar gets eaten as that param
2014-02-21 19:37:12 < Daemon404> by atoi
2014-02-21 19:37:19 < Daemon404> silently
2014-02-21 19:37:19 < muggs> hah
2014-02-21 19:37:59 < muggs> that would be true of any argument that needed a value?
2014-02-21 19:39:51 < muggs> hmm, wondering why we need both --sar and --extended-sar
2014-02-21 19:40:00 < Daemon404> ]$ x264 station2_1080p25.y4m -o lol.h264 --bframes --sar 1:1
2014-02-21 19:40:03 < Daemon404> x264 [error]: invalid argument: bframes = --sar
2014-02-21 19:40:08 < Daemon404> thats the proper way to handle it
2014-02-21 19:40:12 < Daemon404> not silently eating it via atoi
2014-02-21 19:43:08 < muggs> we must be missing some sort of error indication from getopt?
2014-02-21 19:45:27 < muggs> oh.. x264_atoi() catches it, I think
2014-02-21 19:46:41 < Daemon404> sounds likely
2014-02-21 19:51:38 < muggs> I'm adding checks for the output of sscanf, to make sure all values are provided
2014-02-21 19:57:40 < muggs> x264_param_parse() doesn't free name_buf in all return paths.. heh
2014-02-21 19:59:55 < Daemon404> yell at Skyler_ ?
2014-02-21 20:03:45 < Daemon404> muggs, btw i CC'd you on an email to ffmpeg-devel
2014-02-21 20:03:50 < Daemon404> something needs calrification
2014-02-21 20:04:52 < muggs> oh, ok. I haven't made it to my other mailboxes yet. I'll respond this afternoon
2014-02-21 20:05:02 < Daemon404> k
2014-02-21 20:20:17 < dtyx265> muggs, Daemon404, you don't need to specify both --sar and --extended-sar, just one or the other
2014-02-21 20:20:52 < Daemon404> yes i know
2014-02-21 20:20:57 < Daemon404> i was merely using it as a contrived example
2014-02-21 20:21:00 < muggs> can --sar just check a string table, and if no match is found, try WxH?
2014-02-21 20:26:54 < muggs> also, I think all the strings for color spaces, etc need to be added to x265.h
2014-02-21 20:29:15 < Daemon404> muggs, oh also
2014-02-21 20:29:17 < Daemon404> you missed
2014-02-21 20:29:27 < Daemon404> [17:22] < Daemon404> x265 [error]: Search method is not supported value (0:DIA 1:HEX 2:UMH 3:HM 5:FULL)
2014-02-21 20:29:30 < Daemon404> [17:22] < Daemon404> x265 [error]: failed to open encoder
2014-02-21 20:29:32 < Daemon404> [17:22] < Daemon404> with --me 5
2014-02-21 20:29:35 < Daemon404> [17:22] < Daemon404> someone has problems counting
2014-02-21 20:29:55 < dtyx265> Strings? or enums?
2014-02-21 20:29:58 < muggs> document fail
2014-02-21 20:30:30 < muggs> the string is wrong
2014-02-21 20:30:33 < Daemon404> well it would be nice if i didnt have to memorize ints
2014-02-21 20:30:37 < Daemon404> it feels liek ffmpeg from 2005
2014-02-21 20:30:59 < nevcairiel> did you try --me full for giggles? :d
2014-02-21 20:31:05 < Daemon404> indeed
2014-02-21 20:31:19 < Daemon404> it silently works
2014-02-21 20:31:21 < Daemon404> and sets me 0
2014-02-21 20:31:21 < Daemon404> iirc
2014-02-21 20:31:24 < Daemon404> lol.
2014-02-21 20:31:31 < nevcairiel> i thought they started working on reconigzing strings
2014-02-21 20:31:53 < Daemon404> nope
2014-02-21 20:31:55 < dtyx265> ok, I will make sar and the color stuff more user friendly
2014-02-21 20:31:56 < Daemon404> not here anyway
2014-02-21 20:32:07 < Daemon404> dtyx265, only one complain
2014-02-21 20:32:14 < Daemon404> every other app in existence uses x:y
2014-02-21 20:32:17 < Daemon404> not WxH
2014-02-21 20:32:19 < Daemon404> for sar
2014-02-21 20:32:25 < Daemon404> it's a ratio after all.
2014-02-21 20:33:38 < dtyx265> yeah, I guess I was just following the input-res option
2014-02-21 20:33:48 < muggs> I'll fix that while I'm diffing here
2014-02-21 20:34:01 < muggs> (--me full)
2014-02-21 20:35:28 < Daemon404> cool
2014-02-21 20:38:53 < dtyx265> one other thing about cli options, for chromaloc, there are top and bottom field parameters but x264's cli only takes one value and sets both to the same thing.  I copied this into x265.  Do they need to be set individually?
2014-02-21 20:39:30 < muggs> we don't support interlaced pictures yet; so it's somewhat arbitrary.
2014-02-21 20:39:51 < muggs> my guess is no
2014-02-21 20:40:30 < Daemon404> well
2014-02-21 20:40:35 < Daemon404> hevc doesnt have interlacing per se
2014-02-21 20:40:37 < Daemon404> ;)
2014-02-21 20:40:39 < JEEB> btw, does x265 output a massive warning about range extensions not being finished yet when encoding with stuff specified in the drafts?
2014-02-21 20:40:46 < Daemon404> it does not
2014-02-21 20:40:51 < Daemon404> which is why i didnt know
2014-02-21 20:40:53 < JEEB> pls do fix
2014-02-21 20:42:24 < muggs> so 4:4:4 needs to emit a deadly looking warning?
2014-02-21 20:42:56 < JEEB> at least until it hits FDIS and your implementation follows it, IMHO
2014-02-21 20:43:02 < muggs> ok
2014-02-21 20:43:28 < JEEB> because entering FDIS ballot = no more changes are possible in the technical sense
2014-02-21 20:45:04 < JEEB> or if ISO/IEC takes its sweet time with 14496-15, when ITU-T releases their version
2014-02-21 20:45:11 < JEEB> *like with
2014-02-21 20:45:22 < Daemon404> i never understood
2014-02-21 20:45:27 < Daemon404> why do both have the same docs lots of times
2014-02-21 20:45:28 < Daemon404> but itu is free
2014-02-21 20:45:31 < Daemon404> and iso is like $300
2014-02-21 20:56:17 < muggs> x265 [error]: invalid argument: sar = --extended-sar
2014-02-21 21:07:36 < muggs> ok, x265_param_parse fixes pushed
2014-02-21 21:16:13 < muggs> dtyx265: http://pastie.org/8756679
2014-02-21 21:20:27 < dtyx265> yeah, I saw x264 does something similar.  I will add it.
2014-02-21 21:21:15 < muggs> ok; the color primary list seems wierd.. 0 and 2 seem to be the same, and 3 has no string?
2014-02-21 21:21:29 < dtyx265> So, if calling x265 as a lib, x265_param is the interface, correct?
2014-02-21 21:21:43 < dtyx265> 3 is reserved in the spec, not to be used....
2014-02-21 21:22:49 < dtyx265> I can add enums for interfacing with x265_param if that would be useful
2014-02-21 21:24:03 < nevcairiel> 0 says reserved as well in my list, but maybe mine is outdated
2014-02-21 21:24:39 < muggs> a lot of apps will use x265_param_alloc() and x265_param_parse() to avoid having to rebuild their app every time our param structure changes
2014-02-21 21:24:54 < dtyx265> some parameters use 0, some don't
2014-02-21 21:24:55 < muggs> so many of them will set params as strings
2014-02-21 21:27:15 < muggs> probably most
2014-02-21 21:34:26 < muggs> dtyx265: the SAR also needs to be read and returned by the y4m header; do you want to tackle this or shall I put it on my TODO?
2014-02-21 21:36:53 < dtyx265> I will take a look at it and let you know
2014-02-21 21:39:15 < muggs> Daemon404: x265_max_bit_depth is now correctly set to 10 for HIGH_BIT_DEPTH builds, since 12bit support is incomplete
2014-02-21 21:39:32 < muggs> x265_param_defaults() will set internalBitDepth correctly
2014-02-21 21:41:23 < Daemon404> mkay
2014-02-21 22:07:30 < muggs> hmm, perhaps there should be a #define for X265_EXTENDED_SAR 255
2014-02-21 22:07:57 < Daemon404> [17:02] < Daemon404>     /* Aspect ratio idc to be added to the VUI.  The default is 0 indicating
2014-02-21 22:08:01 < Daemon404> [17:02] < Daemon404>      * the apsect ratio is unspecified.  If set to EXTENDED_SAR(255) then
2014-02-21 22:08:03 < Daemon404> [17:02] < Daemon404>      * sarWidth and sarHeight must also be set. */
2014-02-21 22:08:06 < Daemon404> [17:02] < Daemon404>     int       aspectRatioIdc;
2014-02-21 22:08:08 < Daemon404> [17:02] < Daemon404> how useless
2014-02-21 22:08:11 < Daemon404> [17:02] < Daemon404> EXTENDED_SAR(255) isnt defiend anywhere
2014-02-21 22:08:13 < Daemon404> [17:02] < Daemon404> oh it's just shitty spacing
2014-02-21 22:08:16 < Daemon404> [17:02] < Daemon404> s/R(/R (/
2014-02-21 22:08:18 < Daemon404> [17:03] < JEEB> yeah
2014-02-21 22:08:21 < Daemon404> earlier ^
2014-02-21 22:09:51 < muggs> will fix
2014-02-21 22:10:33 < Daemon404> i was thinking it was a macro i needed to call
2014-02-21 22:10:34 < Daemon404> or something
2014-02-21 23:47:41 < JEEB> dtyx265, don't use tv/pc, but full/limited if you need to name those options btw. While many people call them like that, the limited/full is kind of more meaningful and general (at least in my opinion)
2014-02-21 23:48:15 < Daemon404> where did tv/pc even come from
2014-02-21 23:48:25 < Daemon404> the first thing i remember it in was dvd2avi
2014-02-21 23:48:38 < JEEB> also no, do not try to guess range by looking at the input colorimetry things
2014-02-21 23:48:46 < JEEB> unless the spec says so
2014-02-21 23:49:02 < JEEB> having 4:2:0 full range BT.709 colorimetry content is fully valid
2014-02-21 23:49:19 < Daemon404> guessing = bad
2014-02-21 23:49:22 < Daemon404> end of story
2014-02-21 23:50:50 < JEEB> well, the only guess you should be doing is that with YCbCr the range is limited, and with RGB it's full. And the latter only applies to 4:4:4, which isn't set yet. At least I think with H.264 4:2:0 + RGB colorimetry was invalid
2014-02-21 23:51:52 < JEEB> (as in, no guessing and keeping the implicit default in most cases, and guessing in case of RGB)
2014-02-21 23:52:34 < JEEB> and yeah, --[no-]full-range is better than --[no-]range
2014-02-21 23:53:42 < JEEB> --input-csp rgb --no-full-range f.ex. looks kind of understandable, although --input-csp rgb --range limited is understandable as well (and the opposite example for YCbCr)
2014-02-21 23:54:29 < dtyx265> full and limited sounds good
--- Day changed Sat Feb 22 2014
--- Log closed Sat Feb 22 14:36:14 2014
--- Log opened Sat Feb 22 18:39:01 2014
--- Day changed Sun Feb 23 2014
--- Log closed Sun Feb 23 11:40:44 2014
--- Log opened Sun Feb 23 16:10:53 2014
--- Log closed Mon Feb 24 00:53:48 2014
--- Log opened Mon Feb 24 02:28:20 2014
2014-02-24 16:38:58  * Daemon404 notes that satoshi guy has hilarious commit messages
2014-02-24 16:52:07 < Rodeo> Daemon404: only noticed it now?
2014-02-24 16:52:26 < Rodeo> he's not the only one, IIRC
2014-02-24 16:53:05 < Daemon404> yes
2014-02-24 16:53:11 < Daemon404> i used to troll constantly
2014-02-24 16:53:21 < Daemon404> but it just seems impossible to hammer common sense into people
2014-02-24 16:53:28  * Daemon404 spent some time torlling tom instead
2014-02-24 17:38:20 < phc> Twitch Plays My Organization's Management   - newest twitch - actually, it seems like they've been playing since i started working here
--- Day changed Tue Feb 25 2014
2014-02-25 15:57:30 < Daemon404> hmm
2014-02-25 15:57:33 < Daemon404> left x265 overnight
2014-02-25 15:57:36 < Daemon404> it seems to have deadlocked
2014-02-25 15:57:37 < Daemon404> :(
2014-02-25 15:59:04 < Daemon404> muggs, is still hung -- i can feasibly get some info
2014-02-25 15:59:08 < Daemon404> if youd like
2014-02-25 17:47:09 < muggs> Daemon404: yeah, any stack info would be helpful
2014-02-25 17:47:31 < Daemon404> i guess i need to remember how the hell to grab that from a running process
2014-02-25 17:47:36 < Daemon404> with gdb
2014-02-25 17:48:04 < nevcairiel> gdb -p PID
2014-02-25 17:48:26 < nevcairiel> or "attach" inside the gdb shell
2014-02-25 17:48:27 < Daemon404> (gdb) bt
2014-02-25 17:48:27 < Daemon404> #0  0x00000034dd20d720 in sem_wait () from /lib64/libpthread.so.0
2014-02-25 17:48:28 < Daemon404> #1  0x0000000000527b89 in x265::FrameEncoder::getEncodedPicture(x265::NALUnitEBSP**) ()
2014-02-25 17:48:31 < Daemon404> #2  0x0000000000441f54 in x265::Encoder::encode(bool, x265_picture const*, x265_picture*, x265::NALUnitEBSP**) ()
2014-02-25 17:48:34 < Daemon404> #3  0x0000000000442348 in x265_encoder_encode ()
2014-02-25 17:48:36 < Daemon404> #4  0x000000000043ea17 in main ()
2014-02-25 17:48:38 < Daemon404> threading deadlock
2014-02-25 17:48:57 < nevcairiel> now find the other thread holding the same thing ;)
2014-02-25 17:49:21 < Daemon404> threads with gdb... my favourite thing in the world
2014-02-25 17:49:25 < Daemon404> reminds me of windbg
2014-02-25 17:49:43 < nevcairiel> with windbg i would at least know how to simply dump a stack of all threads
2014-02-25 17:49:54 < Daemon404> yeah
2014-02-25 17:50:00 < nevcairiel> no clue in gdb :)
2014-02-25 17:50:25 < Daemon404> thread apply all backtrace
2014-02-25 17:50:26 < muggs> the API thread is blocking for a frame encoder to finish; that's natural
2014-02-25 17:50:26 < Daemon404> apparently
2014-02-25 17:51:32 < Daemon404> https://chromashift.org/hang.txt
2014-02-25 17:51:34 < muggs> I take it the encode was quite a ways into the video when it locked?
2014-02-25 17:51:36 < Daemon404> all thread stacks
2014-02-25 17:51:44 < muggs> thanks
2014-02-25 17:51:56 < Daemon404> [88.6%] 12013/13553 frames, 2.23 fps, 422.14 kb/s, eta 0:11:31
2014-02-25 17:52:00 < Daemon404> is where it hung
2014-02-25 17:52:40 < Daemon404> clearly i should run all future encodes under gdb recording
2014-02-25 17:52:41 < Daemon404> ;)
2014-02-25 17:53:16 < muggs> hmm; every thread is twiddling it's thumbs thinking they are idle; except the frame encoders which are waiting for their processes to be done
2014-02-25 17:53:44 < muggs> bugger
2014-02-25 17:54:18 < muggs> anything unusual about this run?  the only thing that's changed recently was the sem_open() name convention
2014-02-25 17:54:44 < Daemon404> nope...
2014-02-25 17:55:00 < Daemon404> ]$ in/bin/x265 --input ele_848x480.yuv --preset veryslow --crf 23 --input-res 848x480 --output x_v3.hevc --fps 25
2014-02-25 17:55:07 < Daemon404> pretty standard
2014-02-25 17:56:07 < muggs> what does x265 -V report?
2014-02-25 17:56:50 < Daemon404> x265 [info]: HEVC encoder version 0.7+295-57ce7f0f4f4c
2014-02-25 17:56:50 < Daemon404> x265 [info]: build info [Linux][GCC 4.4.7][64 bit] 8bpp
2014-02-25 17:56:50 < Daemon404> x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2
2014-02-25 17:58:06 < muggs> ok, that doesn't have the sem_open changes.  has it ever hung up on your server before?
2014-02-25 17:59:21 < Daemon404> nope
2014-02-25 18:05:21  * muggs scratches head
2014-02-25 19:33:29 < q_bit> I've got a "pipe" error between ffmpeg and x265, althought it might be painful to duplicate.
2014-02-25 19:33:57 < Daemon404> pastebin it?
2014-02-25 19:34:07 < Daemon404> also you can build ffmoeg with libx265 support, which may be less painful
2014-02-25 19:36:06 < q_bit> it's more convoluted, i was using ffmbc hoping that would be using 709 formula for rgb->yuv
2014-02-25 19:36:22 < Daemon404> you dont need ffmbc for that
2014-02-25 19:37:16 < q_bit> ok...i was trying to 'fake' some UHD content from prores and if I just upscale it seems to work but if I add a unsharp then the pipe breaks. I'll show you the line it is short
2014-02-25 19:37:36 < Daemon404> i would suggest using ffmpeg
2014-02-25 19:37:43 < Daemon404> ffmbc's code is ancient
2014-02-25 19:37:47 < Daemon404> and only one guy supports it
2014-02-25 19:38:36 < q_bit> ffmbc.exe -y -i $input -r 23.976 -t 0.25 -sws_flags lanczos -vf "scale=3840:-1,unsharp=3:3:1.4:3:3:0.0" -pix_fmt yuv420p10le -an -f rawvideo - | x265.exe --input - --input-depth 10 --input-res 3840x2160 --fps 23.976 --crf $qp --vbv-maxrate 75000 --vbv-bufsize 300000 -p fast -o $output".bin"
2014-02-25 19:39:03 < q_bit> ok i will switch back over then, ffmbc did seem dated, i was trying to understand the purpose for the fork
2014-02-25 19:39:13 < Daemon404> "rboadcast reasons"
2014-02-25 19:39:16 < Daemon404> which are less relevant in 2014
2014-02-25 19:39:21 < JEEB> to bring baptiste money?
2014-02-25 19:39:27 < Daemon404> i was trying to be nice.
2014-02-25 19:40:10 < q_bit> the secondary issue is that with these tools it's not possible to match color correctly
2014-02-25 19:40:46 < q_bit> i think (going to check over next few days) that the ProRes input is going to 422 using correct 709 formula (not the 601 where Y=.299R etc..)
2014-02-25 19:41:04 < q_bit> but vlc and any other computer tool plays back using 601 so it is wrong color
2014-02-25 19:41:22 < Daemon404> you can set that in vf scale n ffmpeg nowadays
2014-02-25 19:41:23 < Daemon404> http://ffmpeg.org/ffmpeg-filters.html#Options
2014-02-25 19:41:24 < Daemon404> iirc
2014-02-25 19:41:39 < JEEB> that only matters for RGB to YCbCr (and vice versa) conversions
2014-02-25 19:41:40 < q_bit> yes, but in vf it drops it down to 8 bits
2014-02-25 19:41:49 < Daemon404> it shouldnt be
2014-02-25 19:41:58 < JEEB> and for players I think that completely depends on the renderer used in the player that handles the conversion
2014-02-25 19:42:20 < JEEB> and I'm pretty damn sure that a lot of stuff does _not_ default to BT.601 always
2014-02-25 19:42:42 < Daemon404> and yes youre not touchign rgb at all it seems
2014-02-25 19:42:45 < JEEB> of course I think x265 only lately got support for tagging the stream properly, but if your resolution is high enough most players should auto-check
2014-02-25 19:42:45 < q_bit> that would make sense JEEB
2014-02-25 19:42:47 < Daemon404> which means the best you can do is set teh VUI
2014-02-25 19:42:56 < Daemon404> or mabe the colr (????) atom
2014-02-25 19:42:58 < JEEB> no
2014-02-25 19:42:59 < JEEB> not that
2014-02-25 19:43:02 < JEEB> just VUI
2014-02-25 19:43:32 < JEEB> anyways, if you need something relatively nice I recommend mpv's opengl output
2014-02-25 19:43:54 < JEEB> https://github.com/mpv-player/mpv/releases
2014-02-25 19:44:46 < JEEB> (also seems like lachs0r is slacking on the windows builds, I will need to try making them myself again :V )
2014-02-25 19:46:11 < q_bit> what is mpv?
2014-02-25 19:46:33 < q_bit> i dug through vlc code and found that it's opengl output does choose 709 for yuv to rgb conversion
2014-02-25 19:46:54 < q_bit> but i couldn't figure out how to make it output that way
2014-02-25 19:49:30 < q_bit> interesting with latest ffmpeg i get the same pipe error
2014-02-25 19:50:04 < q_bit> it is related to the vf, if i upscale and sharpen i get the pipe error -vf "scale=3840:-1,unsharp=3:3:1.4:3:3:0.0"
2014-02-25 19:50:19 < q_bit> but without the sharpen -vf "scale=3840:-1" it works
2014-02-25 19:50:43 < q_bit> this is all on a PC/windows on my slackware system i have no issue whatsoever just that other box is faster
2014-02-25 19:52:14 < Daemon404> you havent acually told us the error
2014-02-25 19:52:16 < Daemon404> just fyi
2014-02-25 20:19:10 < q_bit> sheesh rite av_interleaved_write_frame(): Operation not permitted
2014-02-25 20:19:51 < q_bit> apparently ffmpeg barfs this out when it can't dump into that pipe properly, maybe some kind of race condition waiting on vf finishing with the more complex unsharp idk
2014-02-25 20:44:59 < muggs> I'm hoping that's not one of the filters MCW worked on
--- Day changed Wed Feb 26 2014
2014-02-26 04:48:11 < q_bit> btw JEEB thanks for tip on mpv player, very nice, performs better than VLC on these encodes
2014-02-26 19:06:57 < Daemon404> muggs, i dont understand how people dont understand the concept of writing commti messages
2014-02-26 19:07:01 < Daemon404> i dont even.
2014-02-26 19:08:55 < muggs> at times it seems like a lost art
2014-02-26 19:09:26 < Daemon404> i get so angry every time a message is "fix bug"
2014-02-26 19:09:30 < Daemon404> "change files"
2014-02-26 19:10:56 < muggs> I think for the current group it is a language thing; they're not comfortable writing lots of English
2014-02-26 19:11:51 < Daemon404> but when they send follow ups, they explain it well enough
2014-02-26 19:11:57 < Daemon404> i want to say "why didnt you include that originally"
2014-02-26 19:12:20 < muggs> you might as well; shame generally works
2014-02-26 19:13:01 < Daemon404> lul
2014-02-26 19:16:06 < muggs> Anyone understand what QP_BD_OFFSET is supposed to to?  It seems to be responsible for the vast difference in CRF behavior between 8 and 10 bit encodes
2014-02-26 19:16:18 < BugMaster> Daemon404: x264 devs also think it's fine to violate the C99 spec. <- you think shame will work on us also?
2014-02-26 19:16:23 < Daemon404> no
2014-02-26 19:16:26 < Daemon404> you guys have no shame
2014-02-26 19:16:27 < Daemon404> ;)
2014-02-26 19:16:35 < BugMaster> btw. about which violation your are talking
2014-02-26 19:16:50 < Daemon404> types with _t are reserved under the C spec
2014-02-26 19:16:50 < BugMaster> don't say shifts of negative values
2014-02-26 19:16:58 < muggs> if I #define it to 0, the SSIMs will roughly match
2014-02-26 19:17:00 < Daemon404> it is illegal to typedef them
2014-02-26 19:17:43 < BugMaster> ah. you talking about that. than we really don't have shame
2014-02-26 19:18:18 < Daemon404> well also x264 uses gnu extensions (gnu99)
2014-02-26 19:18:24 < Daemon404> which i guess is a better example
2014-02-26 19:18:55 < muggs> btw: does x264 build under VC12?
2014-02-26 19:19:27 < BugMaster> iirc anything really needed for gnu99 is only in checkasm
2014-02-26 19:19:27 < JEEB> muggs, seems to be the difference between the max quantizer value between bit depths
2014-02-26 19:19:29 < Daemon404> muggs, no
2014-02-26 19:19:47 < JEEB> #define QP_BD_OFFSET (6*(BIT_DEPTH-8))
2014-02-26 19:19:58 < JEEB> which becomes 12 with 10bit for example
2014-02-26 19:20:11 < JEEB> and then you have #define QP_MAX_SPEC (51+QP_BD_OFFSET)
2014-02-26 19:20:58 < JEEB> and the max for 10bit indeed IIRC Is 51+12
2014-02-26 19:21:31 < JEEB> it seems to be used around various places in x264's rate control additionally
2014-02-26 19:22:57 < muggs> yeah, it's applied to the base QP, which makes CRF use QP values +12 from 8bit QP values
2014-02-26 19:23:37 < muggs> I mean: 10bit CRF uses QPs +12 from 8bit CRF
2014-02-26 19:31:32 < JEEB> well, I have no idea if your rate control is correct (haven't looked at it), but x264 in the end did try to match up the CRF values by adjusting it for higher bit depths
2014-02-26 19:31:40 < JEEB> so you should keep that in mind as well
2014-02-26 19:32:57 < JEEB> h->param.rc.f_rf_constant = x264_clip3f( h->param.rc.f_rf_constant, -QP_BD_OFFSET, 51 );
2014-02-26 19:33:37 < JEEB> (and same for rf_constant_max)
2014-02-26 19:38:12 < muggs> Daemon404: do you know what C99 features VC12 is still missing wrt x264?
2014-02-26 19:38:58 < Daemon404> it fails at some mixed var decls
2014-02-26 19:39:00 < Daemon404> and some union evil
2014-02-26 19:39:01 < Daemon404> iirc
2014-02-26 19:39:16 < Daemon404> mixed code / var decls i mean
2014-02-26 19:39:28 < muggs> ah, I see
--- Day changed Thu Feb 27 2014
2014-02-27 14:15:15 < Rodeo> Daemon404: I guess HandBrake violates the C99 spec. too then (_t), big deal
2014-02-27 15:29:42 < Daemon404> Rodeo, i still think #defining stdlib funcs is stupid
2014-02-27 15:29:59 < Daemon404> theres no reason to other than laziness
2014-02-27 16:01:28 <@Skyler_> Daemon404: aren't types with _t reserved under posix
2014-02-27 16:01:31 <@Skyler_> not C99
2014-02-27 16:03:11 < Daemon404> hmm, you could be correct
2014-02-27 16:03:13  * Daemon404 google
2014-02-27 16:03:47 < Daemon404> yep POSIX
2014-02-27 16:03:48 < Daemon404> my bad
2014-02-27 16:04:01 <@Skyler_> iirc, the reason this became a thing is because posix did not originally reserve them, and people followed the example of posix and used _t for their own types
2014-02-27 16:04:10 <@Skyler_> then later on posix decided to reserve them
2014-02-27 16:04:22 <@Skyler_> and suddenly everyone was caught having used _t for all their types because posix did that
2014-02-27 16:04:31 <@Skyler_> I might be wrong though
2014-02-27 16:04:43 < Daemon404> one would have to check when posix introduced them
2014-02-27 16:05:13 < Daemon404> _t isn't quite as ugly as #defining an stdlib func though IMO
2014-02-27 16:05:19 < Daemon404> i also hate how libav defines printf
2014-02-27 16:05:44 < Daemon404> first thing i do when debugging is #undef printf\n#include <stdio.h>
2014-02-27 16:12:21 < nevcairiel> i just use av_log
2014-02-27 16:12:36 < Daemon404> it's effort to use it
2014-02-27 16:12:49 < Daemon404> and it will not display repeating lines
2014-02-27 16:38:50 < Daemon404> libvpx and x265 on placebo both encding 600 frames of a 4k clip
2014-02-27 16:38:52 < Daemon404> who will win?
2014-02-27 16:39:01  * Daemon404 has set aside several days of cpu time for them
2014-02-27 16:39:11 < Daemon404> by win i mean finish
2014-02-27 16:39:42 < nevcairiel> vpx will at least finish
2014-02-27 16:39:54 < nevcairiel> when is another question
2014-02-27 16:39:55 < Daemon404> hah!
2014-02-27 16:40:26 < nevcairiel> x265 may crash or hang after a few days of encoding
2014-02-27 16:40:26 < Daemon404> i also tested a proprietary hevc encoder
2014-02-27 16:40:32 < Daemon404> lost badly to x264
2014-02-27 16:45:00 < smarter> Daemon404: pretty sure libav doesn't define printf anymore
2014-02-27 19:20:43 < Mista-D> can't build x265 on centos 5.3, just updated cmake  http://pastebin.ca/2647675
2014-02-27 19:24:14 < Daemon404> Mista-D, same here
2014-02-27 19:24:18 < Daemon404> they broke the build
2014-02-27 19:24:19 < Daemon404> again.
2014-02-27 19:24:47 < Daemon404> mostly because the devs only use MSVC.
2014-02-27 19:30:40 < muggs> actually it was because I used a Mac
2014-02-27 19:30:44 < muggs> anyway it's fixed
2014-02-27 21:31:00 < muggs> anyone here know what the likely() unlikely() macros do in the VLC code base?
2014-02-27 21:31:19 < muggs> is that a compiler hint of some kind?
2014-02-27 21:31:58 < muggs> I see it just does #define unlikely(p) (!!(p))
2014-02-27 21:32:30 < Daemon404> thats certainly a misleading name
2014-02-27 21:32:55 < muggs> #define likely(p) (!!(p))
2014-02-27 21:32:58 < muggs> does the same thing
2014-02-27 21:33:16 < Daemon404> wtf
2014-02-27 21:34:37 <@Skyler_> are you sure?
2014-02-27 21:34:40 <@Skyler_> normally likely is defined as
2014-02-27 21:34:54 <@Skyler_> #define likely(expr) __builtin_expect(expr, 1)
2014-02-27 21:35:11 < muggs> I was going from: http://www.videolan.org/developers/vlc/doc/doxygen/html/vlc__common_8h.html
2014-02-27 21:35:15 < muggs> perhaps not a very good source
2014-02-27 21:35:32 <@Skyler_> that may depend on the #defines used.
2014-02-27 21:35:36 <@Skyler_> for example, it might look like this
2014-02-27 21:35:42 < muggs> that makes much more sense
2014-02-27 21:35:43 <@Skyler_> #ifdef real_compiler
2014-02-27 21:35:44 <@Skyler_> #define likely(expr) __builtin_expect(expr, 1)
2014-02-27 21:35:47 <@Skyler_> #else
2014-02-27 21:35:56 <@Skyler_> #define likely(expr) (!!(expr))
2014-02-27 21:35:58 < Daemon404> Skyler_, still means their docs are faulty
2014-02-27 21:36:03 < muggs> yes, that's likely..
2014-02-27 21:36:06 <@Skyler_> the docs are probably autogenerated
2014-02-27 21:36:16 < muggs> it's Doxygen
2014-02-27 21:36:18 <@Skyler_> and doxygen might not be run with the correct #defines
2014-02-27 21:36:19 < Daemon404> yeah... man i hate doxygen
2014-02-27 21:36:46 <@Skyler_> personally I don't like likely/unlikely as it doesn't often seem very useful and a simple fprofiled compile eliminates the need for all of them
2014-02-27 21:36:58 <@Skyler_> I can see the point in a codebase that isn't easily profiled though, like a very large one (ffmpeg, linux kernel)
2014-02-27 21:37:19 < Daemon404> vlc is even nharder
2014-02-27 21:38:19 <@Skyler_> yeah
2014-02-27 21:38:22 < muggs> I thought perhaps those macros were used to catch rare runtime errors; but seems not
--- Day changed Fri Feb 28 2014
2014-02-28 18:39:24 < dynaflash> Rodeo, that controller patch for the granularity of the rf slider seems fine.
2014-02-28 18:39:41 < dynaflash> lol. oops wrong window
2014-02-28 18:49:53 < Rodeo> dynaflash: well, I did come up with it while testing x265 in-GUI, so not necessarily the wrong one
2014-02-28 21:20:19 < muggs> has ffmpeg been lgpl since forever, or is that a recentish change?
2014-02-28 21:20:36 < Daemon404> forever
2014-02-28 21:21:25 <@Skyler_> it's libvlc that was relicensed
2014-02-28 21:22:56 < muggs> ah, ok
--- Day changed Sat Mar 01 2014
--- Day changed Sun Mar 02 2014
--- Day changed Mon Mar 03 2014
2014-03-03 04:53:24 < q_bit> Is there anyway to set the compile to high bit depth (main10) without using make-Makefiles.bash (e.g. ccmake). I can't get my system to install libncurses5-dev to build ccmake from.
2014-03-03 05:10:18 < q_bit> nvm...got it
2014-03-03 16:14:29 < Daemon404> Rodeo, pong
2014-03-03 16:14:30 < Daemon404> er
2014-03-03 16:14:30 < Daemon404> ping
2014-03-03 16:14:42 < Rodeo> yeah, that makes more sense
2014-03-03 16:14:58 < Daemon404> are you going to add extradata stuff to libx265.c, or shall i
2014-03-03 16:15:04 < Daemon404> mostly my issue is i cannot test it properly
2014-03-03 16:15:07 < Daemon404> due to lack of muxer
2014-03-03 16:15:17 < Rodeo> my patches are on the ML
2014-03-03 16:15:25 < Daemon404> right
2014-03-03 16:15:32 < Rodeo> just apply them to test
2014-03-03 16:15:46 < Rodeo> anyway, here's what I thought were issues when I last checked
2014-03-03 16:15:49 < Daemon404> i think this might be annoying also... the elementary stream seems to need it at the head
2014-03-03 16:15:54 < Daemon404> or i fucke up somewhere
2014-03-03 16:16:07 < Daemon404> (im currently writing it as a header intead of extradata iirc)
2014-03-03 16:16:16 < Rodeo> - not setting the context extradata when CODEC_FLAG_GLOBAL_HEADER is set
2014-03-03 16:16:24 < Daemon404> yeah i know that one
2014-03-03 16:16:31 < Rodeo> - 2 repeating headers before every frame, IIRC (any IRAP should be enough)
2014-03-03 16:17:11 < nevcairiel> if its supposed to work like x264, then it should set it inband when producing Annex B (and additionally in extradata for easier access maybe), and in extradata for MP4 output
2014-03-03 16:17:45 < Rodeo> right
2014-03-03 16:18:14 < Daemon404> hmm
2014-03-03 16:18:16 < Daemon404> ok
2014-03-03 16:18:21 < Rodeo> so the last one, can't remember the condition, in the x2164 wrapper, repeat_headers is turned off
2014-03-03 16:18:36 < Rodeo> in which case, headers should not be written to the bitstream at all
2014-03-03 16:19:02 < Rodeo> OK, same condition
2014-03-03 16:19:04 < Rodeo> if (avctx->flags & CODEC_FLAG_GLOBAL_HEADER)
2014-03-03 16:19:09 < Rodeo> x4->params.b_repeat_headers = 0;
2014-03-03 16:19:14 < Rodeo> -> no headers in bitstream
2014-03-03 16:19:27 < Rodeo> put it in extradata instead
2014-03-03 16:19:35 < Rodeo> otherwise in bitstream, but not in extradata
2014-03-03 16:20:17 < Daemon404> ok
2014-03-03 16:20:22 < Rodeo> and in bitstream, you need to check whether the slice is IRAP in addition to ctx->header != NULL, no need to repeat the headers before every frame
2014-03-03 16:20:27 < Daemon404> gotta see i x265 even has that option
2014-03-03 16:20:31 < Daemon404> if*
2014-03-03 16:20:32 < Rodeo> nope
2014-03-03 16:20:39 < Daemon404> derp
2014-03-03 16:20:42 < Daemon404> that'll be annoying
2014-03-03 16:20:48 < nevcairiel> ask for the option
2014-03-03 16:21:00 < Daemon404> ill poke muggs when he shows up
2014-03-03 16:21:23 < Daemon404> i also need to flush properly
2014-03-03 16:21:25 < Daemon404> so thats #3
2014-03-03 16:21:32 < Daemon404> (thats a nice out of context quote)
2014-03-03 16:21:43 < Rodeo> x264 has repeat_headers (on by default), x265 has no option and you're supposed to get the headers via x265_encoder_headers() and place them accordingly
2014-03-03 16:22:05 < Daemon404> i only call encoder_headers once
2014-03-03 16:22:09 < Rodeo> right
2014-03-03 16:22:27 < Daemon404> so if youre still seeign repeated headers, then its ALSO doing that
2014-03-03 16:22:28 < Rodeo> if we have no support for reconfiguring mid-encode, that should be just fine
2014-03-03 16:22:44 < Daemon404> not yet, no
2014-03-03 16:22:47 < Rodeo> Daemon404: you're calling is once, cpying the headers, and writing them every time, IIC
2014-03-03 16:22:59 < Rodeo> x265 has no support for reconfigure yet anyway
2014-03-03 16:23:29 < Rodeo> oh, nevermind, you're frreing it
2014-03-03 16:23:34 < Rodeo> cool
2014-03-03 16:23:38 < Rodeo> that's one less issue
2014-03-03 16:23:45 < Daemon404> yeah
2014-03-03 16:24:06 < Rodeo> though yeah, if global_header flag is not set, you need to repeat before every IRAP
2014-03-03 16:24:24 < Rodeo> to match what we do for x264, and I bet that's required for correct TS muxing
2014-03-03 16:24:45 < Rodeo> global_header_flag would be MP4/Matroska
2014-03-03 16:24:58 < Daemon404> i already have is_keyframe
2014-03-03 16:25:04 < Daemon404> its trivial to add the extradata in that case
2014-03-03 16:25:34 < Daemon404> or well, irap != keyframe
2014-03-03 16:25:45 < Daemon404> i need to check out when global_header is set
2014-03-03 16:25:59 < Daemon404> (i.e. always, or just on iraps)
2014-03-03 16:27:35 < Rodeo> global_header is a codec context flag
2014-03-03 16:27:46 < Rodeo> if (avctx->flags & CODEC_FLAG_GLOBAL_HEADER)
2014-03-03 16:28:18 < Daemon404> i just saw
2014-03-03 16:28:33 < Daemon404> so i need to only do it hen is_keyframe() is true, afaik
2014-03-03 16:28:36 < Rodeo> what I would do is check that in init, and copy the extradata to the codec context (flag is set) or to ctx->header (flag is not set)
2014-03-03 16:28:42 < Daemon404> yep
2014-03-03 16:28:44 < Rodeo> then check ctx->header in the encode func
2014-03-03 16:28:58 < Daemon404> its not a big change
2014-03-03 16:29:04 < Daemon404> its just making sure i do it right
2014-03-03 16:29:20 < Rodeo> now, I said IRAP, I meant any kind of keyframe, I think
2014-03-03 16:29:35 < Daemon404> is_keyframe checks all the irap types
2014-03-03 16:29:42 < Daemon404> all like, 6 or 7 of them
2014-03-03 16:30:01 < Daemon404> it should be good
2014-03-03 16:30:54 < Rodeo> yeah, IRAP is keyframe, AFAICT
2014-03-03 16:30:58 < Rodeo> "NOTE – An IRAP access unit may be an IDR access unit, a BLA access unit, or a CRA access unit."
2014-03-03 16:31:02 < Daemon404> yeah
2014-03-03 16:31:05 < Daemon404> i check all of those
2014-03-03 16:31:13 < Rodeo> IRAP is keyframe, it's IDR that isn't, if I understand this correctly
2014-03-03 16:31:47  * Daemon404 thinks hevc has too many types
2014-03-03 16:33:29 < nevcairiel> IDR becomes a "key frame" if you put a extradata block in front of it
2014-03-03 16:33:48 < nevcairiel> so that you can start decoding from that point
2014-03-03 16:33:50 < nevcairiel> or something
2014-03-03 16:35:00 < Paranoialmaniac> what is the definition of keyframe? afaik, there is no general definition
2014-03-03 16:35:47 < Rodeo> that's probably true
2014-03-03 16:35:53 < Rodeo> MP4 sync point then?
2014-03-03 16:36:32 < Rodeo> I think repeating headers before any IRAP (in non-global header mode) is the right thing to do though
2014-03-03 16:38:27 < Paranoialmaniac> An MP4 sync point is basically equivalent to a random access point
2014-03-03 16:39:19 < Paranoialmaniac> btw a picture with recovery point sei is also a random access point
2014-03-03 17:38:52 < nevcairiel> official mkvtoolnix with hevc muxing is out now
2014-03-03 17:39:32 < JEEBsv> interesting
2014-03-03 17:39:49 < nevcairiel> http://forum.doom9.org/showthread.php?p=1671693#post1671693
2014-03-03 17:40:05 < nevcairiel> input from ES only so far, but at least the first step
2014-03-03 17:40:14 < JEEBsv> does it still do version entry zero or one?
2014-03-03 17:40:22 < nevcairiel> didnt check
2014-03-03 17:40:32 < JEEBsv> because at this point (FDIS done) 1 should be OK
2014-03-03 17:42:41 < nevcairiel> greping through the code, i cant see where it even sets it
2014-03-03 17:43:00 < nevcairiel> i found where its written into the record, but not where the variable its written from is set <.<
2014-03-03 17:43:10 < JEEBsv> :D
2014-03-03 17:44:15 < nevcairiel> doesnt seem like it is anywhere
2014-03-03 17:44:19 < nevcairiel> probably 0 then
2014-03-03 17:44:30 < JEEBsv> need to note it to him so it can be updated
2014-03-03 17:44:43 < JEEBsv> at least if it matches current 14496-15 FDIS draft
2014-03-03 17:46:07  * koda wonders if https://news.ycombinator.com/item?id=7333625 ever happened to JEEB 
2014-03-03 19:50:52 < Rodeo> JEEBsv: looks like it except is always sets averageFrameRate and constantFrameRate to 0 and marks it as reserved
2014-03-03 19:53:52 < JEEB> Rodeo, better to move the discussion to #matroska then I guess
2014-03-03 19:54:00 < JEEB> since mosu is there
2014-03-03 19:54:03 < Rodeo> doh
2014-03-03 21:18:58 < dtyx265> Hi all, in addition to some vui upgrades, I have merged TEncCfg into Encoder.  It builds and I have encoded a short video with it and it looks good.  Is this something that I should test with what's in source/test before I submit a patch?  I can't find much documentation on testing.
--- Day changed Tue Mar 04 2014
--- Day changed Wed Mar 05 2014
2014-03-05 08:58:58 < JEEB> darkbasic, first of all, there is no such thing as "hi10p" HEVC
2014-03-05 08:59:28 < JEEB> (unsurprising since there's only a main profile in HEVC, eh? It's the "main 10" profile)
2014-03-05 09:01:37 < JEEB> also you might want to post all of the command lines you used for each encoder, since I can at least not see that in your "article"
2014-03-05 09:02:27 < JEEB> (also since both H.264's high 10 profile and HEVC's main 10 profile do support [8-10] bit depths, it might just be simpler to call it "10bit encoding" instead of using the profile's name)
2014-03-05 12:57:56 < funman> https://mailman.videolan.org/pipermail/x265-devel/2014-March/003828.html
2014-03-05 13:37:03 < Daemon404> funman, lol
2014-03-05 13:37:14 < Daemon404> (in fact hg CAN appyl git patches, and muggs does this)
2014-03-05 13:37:57 < funman> it can and it messes up my name
2014-03-05 13:38:10 < nevcairiel> no unicode in hg? :p
2014-03-05 13:38:26 < funman> no although they claim it's supported well
2014-03-05 13:38:38 < funman> git patches are converted to ascii first
2014-03-05 13:38:53 < funman> i have a wip patch but never felt like finishing it
2014-03-05 13:38:57 < funman> ... python
2014-03-05 13:39:47 < nevcairiel> I always wanted to do something in python since on a first glance it looked like an interesting language, but I never found an appropriate project, and sometimes I wonder if it wasn't for the better : p
2014-03-05 13:41:01 < funman> it's nice for toy language IMO
2014-03-05 13:41:13 < funman> but well I'm not used to bigger projects
2014-03-05 13:41:27 < Daemon404> its not bad
2014-03-05 13:41:35 < Daemon404> but it uses exceptions (and doesnt document them all)
2014-03-05 13:41:37 < Daemon404> so it fails
2014-03-05 13:41:42 < darkbasic> JEEB: you can find the exact command line in the screenshot comparator, just select the codec and press the "Info" button
2014-03-05 13:41:54 < nevcairiel> i'm used to java, its exception-country
2014-03-05 13:41:58 < darkbasic> JEEB: I clearly wrote it in the article ;)
2014-03-05 13:43:17 < darkbasic> JEEB: I meant 16bpp, I will fix the article
2014-03-05 13:43:27 < JEEB> HEVC can't do 16bpp
2014-03-05 13:43:31 < JEEB> so you meant 10bit encoding
2014-03-05 13:44:06 < JEEB> I know the configure switch is to have 16bit variables, but that still doesn't mean that you're doing 16bit encoding
2014-03-05 13:44:11 < darkbasic> JEEB: x265 [info]: HEVC encoder version 0.7+259-5e2043f89aa1 x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 16bpp
2014-03-05 13:44:15 < darkbasic> JEEB: what's that?
2014-03-05 13:44:24 < JEEB> 16bit variables
2014-03-05 13:44:40 < JEEB> because you can't fit 10 bits of data into 8bit variables
2014-03-05 13:44:42 < JEEB> :P
2014-03-05 13:45:19 < JEEB> also I just ctrl+F'd for "settings" on http://www.linuxsystems.it/2014/03/new-screenshots-comparator-loads-new-x264-x265-vp8-vp9-tests/
2014-03-05 13:45:34 < JEEB> neither can I see results for "parameters"
2014-03-05 13:45:58 < darkbasic> JEEB: new screenshot comparator which eases the job: use it to find the details about sources, codecs, etc..
2014-03-05 13:46:05 < nevcairiel> I always thought this naming was rather confusing in x265
2014-03-05 13:46:19 < darkbasic> nevcairiel: quite a bit :)
2014-03-05 13:47:47 < JEEB> ok. I recommend you put the encoding settings for each encoder on the main page and don't make one click buttons to get them as MESSAGE BOXES
2014-03-05 13:47:57 < JEEB> do you have any idea of how obnoxious that design is?
2014-03-05 13:48:36 < JEEB> I know most browsers including mine don't show them up as separate windows any more, thank goodness, but it's still "u w0t m8t" level
2014-03-05 13:48:55 < JEEB> as for the settings themselves, you might want to --tune ssim and maximize refs and bframes
2014-03-05 13:49:01 < JEEB> tune ssim enables AQ
2014-03-05 13:49:13 < JEEB> and for whatever reason x265 doesn't maximize refs and bframes usable
2014-03-05 13:49:17 < JEEB> with preset placebo
2014-03-05 13:50:01 < JEEB> (the default psyopts for x265 are for PSNR, so AQ and all that jazz disabled)
2014-03-05 13:50:37 < nevcairiel> why would you default to psnr o.o
2014-03-05 13:50:49 < JEEB> no issue with the x264 line
2014-03-05 13:51:00 < darkbasic> JEEB: do you have any idea how tired I was when doing the final touches on the page? of course, it was the last thing I did yesterday night :)
2014-03-05 13:51:01 < darkbasic> JEEB: I will of course change it with something better
2014-03-05 13:51:08 < nevcairiel> wasnt it established ages ago that psnr is just not a good metric
2014-03-05 13:51:25 < JEEB> also really, if you are going to make a chart of some random metrics
2014-03-05 13:51:31 < JEEB> make sure you're optimizing for it
2014-03-05 13:51:44 < JEEB> otherwise the pretty chart is pretty much null and void
2014-03-05 13:51:48 < darkbasic> JEEB: isn't --tune ssim the default? O_O
2014-03-05 13:51:54 < JEEB> darkbasic, not that I know
2014-03-05 13:52:23 < darkbasic> OMG I can't believe it
2014-03-05 13:52:43 < JEEB> do you still have the terminal log somewhere?
2014-03-05 13:52:49 < JEEB> it should show if nothing else :P
2014-03-05 13:54:01 < darkbasic> JEEB: unfortunately not, but I can easily do the encoding once again. do you suggest something else except --tune ssim?
2014-03-05 13:54:28 < JEEB> anyways, my recommendations would be that you make one set of encodes for x265 (since you can't optimize for "visual quality" for it anyways, so SSIM tuned encode only with placebo plus max'd refs and bframes), and then two sets for x264. One for the visual check, and one for the SSIM chart (although you can make the SSIM encode visible in the visual comparison as well -- sometimes psy-rd doesn't exactly look good with low enough rate
2014-03-05 13:54:29 < JEEB> s)
2014-03-05 13:59:13 < darkbasic> JEEB: one more thing, does CRF help when doing a static comparison (screenshot) or a costant quantizer (-q) is better?
2014-03-05 14:01:24 < JEEB> if an encoder has something like CRF or a 2pass mode (and you can confirm the devs that they're not bugged), you most definitely want to use them instead of const. quant
2014-03-05 14:03:40 < darkbasic> ok, regarding 16bpp: do devs confirm it is bugged? because I get artifacts and an overall terrible quality
2014-03-05 14:05:42 < Daemon404> 16bpp doesnt exist in hevc
2014-03-05 14:05:43 < Daemon404> period
2014-03-05 14:06:07 < darkbasic> Daemon404: I mean "16bit variables"
2014-03-05 14:06:18 < Daemon404> ok high bit depth in general
2014-03-05 14:06:24 < Daemon404> not sure -- it was broken last time i tested 2 weeks ago
2014-03-05 14:09:22 < smarter> darkbasic: if you're interested in VP9/H.264 comparisons see http://exp.martres.me/splitview/
2014-03-05 14:09:43 < darkbasic> smarter: thanks
2014-03-05 14:13:07  * smarter consider adding a warning to libvpx when using --best
2014-03-05 14:15:49 < darkbasic> smarter: I did an encoding test with --best and I calculated about 0.01fps which was acceptably slow for my purposes. unfortunately when doing the real encoding it showed to be MUCH slower.
2014-03-05 14:18:11 < smarter> also,  if you don't specify -p and --pass, it will do a 2-pass encoding by itself in one command
2014-03-05 14:18:37 < smarter> and the output format should be a .webm  not a .vp9 file
2014-03-05 14:19:30 < darkbasic> smarter: you can't do two pass encoding without --pass using pipes :)
2014-03-05 14:20:53 < darkbasic> smarter: because after the first pass ffmpeg doesn't pipe raw video anymore
2014-03-05 14:24:08 < smarter> ah, haven't tried doing that with pipes
2014-03-05 14:26:06 < darkbasic> JEEB: --tune SSIM *IS* the default: https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20March%204%202014.pdf
2014-03-05 14:28:58 < darkbasic> what's --aq-mode 2? is it better than 1 qualitywise?
2014-03-05 14:29:18 < smarter> for what encoder?
2014-03-05 14:31:06 < darkbasic> x265, because I read --tune ssim sets --aqmode 1 while any preset >= medium sets --aq-mode 2 :confused:
2014-03-05 14:31:55 < nevcairiel> last i heard, noone really knew if aq-mode 2 is any better  :p
2014-03-05 14:32:01 < smarter> that's for x264
2014-03-05 14:32:12 < nevcairiel> i think it stole the implementation
2014-03-05 18:15:47 < muggs> Any ffmpeg hackers about?
2014-03-05 18:16:23 < Daemon404> ?
2014-03-05 18:16:27 <@Skyler_> what's the issue?
2014-03-05 18:16:36 < muggs> https://bitbucket.org/multicoreware/x265/issue/35/crash-when-encoding-yuv420p10le
2014-03-05 18:16:56 < Daemon404> probably my bug...
2014-03-05 18:17:56 < muggs> when pic.bitDepth > 8, we expect stride to be a int16_t * offset
2014-03-05 18:18:20 < nevcairiel> so stride always in pixel, not in bytes?
2014-03-05 18:18:54 < Daemon404> wtf?
2014-03-05 18:19:05 < Daemon404> literally everything else in the internets uses bytes
2014-03-05 18:19:30 < nevcairiel> i've seen both tbh
2014-03-05 18:19:44 < Daemon404> ive never seen int16_t offset strides
2014-03-05 18:19:45 < Daemon404> :?
2014-03-05 18:19:47 < Daemon404> :/
2014-03-05 18:20:12 < nevcairiel> i've seen pixel based strides, especially for rgb buffers, where ffmpeg would use 4* the number
2014-03-05 18:21:08 < Daemon404> i guess ill just do >>(av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 > 8)
2014-03-05 18:21:11 < Daemon404> or something
2014-03-05 18:21:22 < muggs> if x264 uses byte strides on input pixels, I don't mind changing ours here
2014-03-05 18:21:42 < muggs> internally stride is always in pixels
2014-03-05 18:23:01 < muggs> yeah, certainly looks like x264 uses bytes
2014-03-05 18:35:43 <@Skyler_> externally it's in bytes because the pointers are byte
2014-03-05 18:35:49 <@Skyler_> since C doesn't have type polymorphism or anything
2014-03-05 18:37:42 < muggs> our pic.plane pointers are void*, but I see the point
2014-03-05 18:39:05 <@Skyler_> it's not necessarily the right hoice, you can do whatever makes sense
2014-03-05 18:42:06 < muggs> our general rule is to follow the x264 public API and CLI as much as possible to avoid confusion
2014-03-05 18:54:24 < muggs> emailed a patch for it.. so does this deserve an X265_BUILD bump?
2014-03-05 18:54:52 < Daemon404> API/ABI change, so yea
2014-03-05 18:57:40 < muggs> ok, amended the commit locally
--- Day changed Thu Mar 06 2014
2014-03-06 15:33:18 < nevcairiel> Daemon404: I wonder if ffmpeg configure should not just depend on an *exact* x265 version until API/ABI stabilizes a bit, right now it seems to only depend on a minimum, which still makes it fail building everytime the version is bumped for incompatible changes
2014-03-06 21:18:02 < funman> https://github.com/frej/fast-export/commit/f2491e83b038a27bc4a64a34b4bccb557734ab3a
2014-03-06 21:18:18 < funman> found why my checkout wasn't being updated
--- Day changed Fri Mar 07 2014
--- Day changed Sat Mar 08 2014
--- Day changed Sun Mar 09 2014
2014-03-09 06:25:47 < tlacatlc6> i cross compiled x265 in linux and did a small rip that went fine but saw some messages from cmake that concerned me.
2014-03-09 06:26:11 < tlacatlc6> here is what it looks like -> http://pastebin.com/7dDB6ScS
2014-03-09 06:28:31 < tlacatlc6> lines 23 and 26 are what i'm concerned about
2014-03-09 20:41:44 < muggs> fwiw: that cmake output looks perfectly normal for MinGW; no features are disabled
2014-03-09 20:42:13 < muggs> I'm not sure where the 'The ASM_YASM compiler identification is unknown' message comes from, but the earlier 'Found Yasm 1.2.0 to build assembly primitives' message is definitive
--- Day changed Mon Mar 10 2014
2014-03-10 09:13:26 < j-b> Morning
--- Day changed Tue Mar 11 2014
--- Day changed Wed Mar 12 2014
--- Day changed Thu Mar 13 2014
--- Day changed Fri Mar 14 2014
--- Day changed Sat Mar 15 2014
2014-03-15 09:13:19 < mankan> Hi all. Are there any plans on introducing a repeat_headers flag like x264 have? Someone working on this?
2014-03-15 17:34:46 < Daemon404>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2014-03-15 17:34:46 < Daemon404> 20326 derek     20   0 13.6g  10g 2704 S 2291.0 11.0   1448:49 x265
2014-03-15 17:34:49 < Daemon404> dat ram usage
2014-03-15 18:04:02 < Easyfab> Daemon404: hi, with some videos I have this error -> http://pastebin.com/yHMXZ1Va  ( ffmpeg version N-61452-g722b48b and latest x265 )
2014-03-15 18:04:06 < Easyfab> Can someone reproduce ? is it a ffmpeg or x265 problem ?
2014-03-15 18:04:55 < Easyfab> with y4m parkjoy it's ok  for example .
2014-03-15 18:07:03 < Daemon404> your y4m has bogus SAR info in it
2014-03-15 18:07:14 < Daemon404> try -x265opts sar=1:1
2014-03-15 18:07:18 < Daemon404> or whatever the option name s
2014-03-15 18:07:19 < Daemon404> is
2014-03-15 18:11:15 < Easyfab> I try -x265-params sar=1:1 but same message error
2014-03-15 18:11:59 < Daemon404> are you sure
2014-03-15 18:12:06 < Daemon404> *exact* same output
2014-03-15 18:12:10 < Daemon404> no additions/removals
2014-03-15 18:13:40 < Easyfab> yes exactly yhe same
2014-03-15 18:14:59 < Rodeo> wouldn't the : act as a separator?
2014-03-15 18:15:13 < Rodeo> maybe sar=1 or sar=1/1 instead
2014-03-15 18:15:13 < Daemon404> hmm
2014-03-15 18:15:21 < Daemon404> im not sure how x264 takes it
2014-03-15 18:15:23 < Easyfab> but with -vf  setsar it's ok
2014-03-15 18:15:25 < Daemon404> but it does check if its vald
2014-03-15 18:15:28 < Daemon404> and prints a warning
2014-03-15 18:17:21 < Rodeo> looks like a possible x265 bug
2014-03-15 18:17:58 < Rodeo> x265 tries %d:%d, but also %d/%d, whereas x265 doesn't
2014-03-15 18:18:40 < Easyfab> And with -vf setsar the file is corrupt :(
2014-03-15 18:26:48 < Daemon404> Easyfab, are you sure the y4m snt just corrupt
2014-03-15 18:27:00 < Daemon404> since it shouldnt have such a broken sar anyway
2014-03-15 18:31:16 < Easyfab> No because others .y4m and all my .wmv have the same problem. I will retry to build a new ffmpeg manually because  my build  has perhaps a problem ( https://github.com/rdp/ffmpeg-windows-build-helpers script )
2014-03-15 18:55:43 < Daemon404> Easyfab, ok
2014-03-15 19:17:18 < Easyfab> Daemon404: If you have windows could you try  a build from http://ffmpeg.zeranoe.com/builds/ it give me exactly the same message + all files encoded with libx265 are corrupt .
2014-03-15 19:33:20 < Easyfab> For information the 13-Mar-2014 version is ok so something breaks since the last 2 days . in x265 ?
2014-03-15 19:35:04 < JEEB> completely unsurprising
2014-03-15 19:35:13 < JEEB> x265 is not developed exactly like x264
2014-03-15 19:35:21 < JEEB> so expect random breakage at all points of development
2014-03-15 19:41:10 < Mandarinka> <JEEB> x265 is pretty fast now, preset placebo and refs/bframes maxed is now ~0.4fps with 720p on a i5 3570K
2014-03-15 19:41:37 < Mandarinka> can I ask what sort of source was used for that (and which bitrate)? Something that would result in a lot of skips?
2014-03-15 19:42:37 < Mandarinka> Because I tried 0.8 build by d404 on a quad phenom (so say half as fast as that Ivy Bridge), and I didn't even reach 0,01 fps (1440x1080 video with grain/motion, bitrate ended up high - 18000kbps)
2014-03-15 19:43:00 < JEEB> crf 32 or so methinks
2014-03-15 19:43:05 < Mandarinka> ah
2014-03-15 19:43:07 < JEEB> and 8bit of course
2014-03-15 19:43:08 < Mandarinka> probably helps
2014-03-15 19:43:12 < Mandarinka> yeah me too
2014-03-15 19:43:16 < JEEB> it was the hyouka op
2014-03-15 19:43:18 < Mandarinka> although I had wpp disabled (utilisation was still high) and bframes not maxed
2014-03-15 19:43:35 < Mandarinka> I guess the difference in bitrate could do a lot
2014-03-15 19:43:44 < JEEB> also 1440x1080 is not really 720p :P
2014-03-15 19:43:56 < Mandarinka> yeah, but still, two orders of magnitude
2014-03-15 19:44:00 < JEEB> also you might as well keep WPP enabled
2014-03-15 19:44:17 < JEEB> probably encodes quicker too, and the loss is so small in general
2014-03-15 19:44:24 < Mandarinka> I was wondering if the absence of ssse3 could critically cripple the performance...
2014-03-15 19:45:10 < Mandarinka> hmm, I guess I should try another encode, but those 450 frames took so long, I sorta don'T feel like repeating it haha
2014-03-15 19:45:44 < Mandarinka> and yeah, 0.4fps would be usable for encoding rips/fansubs.
2014-03-15 19:47:00 < JEEB> yup
2014-03-15 19:54:07 < Daemon404> Mandarinka, i am encoding at 0.02 fps with retardedl slow settings
2014-03-15 19:54:10 < Daemon404> 4k video
2014-03-15 19:54:18 < Daemon404> (on a 24 core xeon)
2014-03-15 19:55:48 < Mandarinka> is the particular hyouka op clip available somewhere for testing?
2014-03-15 19:56:23 < JEEB> I can link you it and the avs script I'm using for sourcing it
2014-03-15 19:56:26 < JEEB> sec
2014-03-15 19:57:21 < JEEB> linked in pm
2014-03-15 19:57:29 < JEEB> then for the avs...
2014-03-15 19:57:31 < Mandarinka> thanks
2014-03-15 19:58:46 < JEEB> LWLibavVideoSource(), Trim(96,2253), Spline36Resize(1280,720)
2014-03-15 19:58:52 < JEEB> that was it for the 8bit encode
2014-03-15 19:59:01 < Mandarinka> ok
2014-03-15 19:59:27 < Mandarinka> I tend to test oldies to see how grain gets wiped out/preserved
2014-03-15 19:59:30 < Daemon404> Easyfab, then x265 broke something
2014-03-15 19:59:46 < Mandarinka> in this case, New Cutie Honey BD.
2014-03-15 19:59:49  * Daemon404 mostly tests real content
2014-03-15 19:59:53 < Daemon404> from users
2014-03-15 20:00:15 < Mandarinka> Anybody interested in a 450 frames long 1440x1080 clip with 18 megabits bitrate, for testing or something?
2014-03-15 20:00:24 < Daemon404> nah
2014-03-15 20:00:28  * Daemon404 has all teh standard clips 
2014-03-15 20:00:47 < Mandarinka> this one is nonstandard with nude transformation sequence.
2014-03-15 20:01:00 < Mandarinka> I guess since it took several days to make, I can upload it somewhere.
2014-03-15 20:01:04 < JEEB> anyways, with 8bit the CRF values I've been interested of so far are 32, 28, 24
2014-03-15 20:01:05 < Daemon404> well... vimeo does allow nudity
2014-03-15 20:01:08 < Daemon404> <.<
2014-03-15 20:01:08 < Daemon404> >.>
2014-03-15 20:01:21 < JEEB> 32 being definitely one that is low enough for artifacts to get shown
2014-03-15 20:01:26 < JEEB> 28 being somewhat better
2014-03-15 20:01:35 < JEEB> and 24 being close to what I usually use for encodes, I guess?
2014-03-15 20:01:38 < Mandarinka> I wasn't sure what to use, and the first number I tried ended up being superhuge :)
2014-03-15 20:01:55 < Mandarinka> I think I picked 18 (based on x264...)
2014-03-15 20:01:56 < Daemon404> im trying a 4k clip with 24
2014-03-15 20:02:01 < Daemon404> well see how it turns out in N hrs
2014-03-15 20:02:13 < JEEB> 18 is way too low to be of use
2014-03-15 20:02:35 < Mandarinka> well, I wanted to see how it does on high bitrates, actually
2014-03-15 20:03:01 < Mandarinka> but like 10-13 would be better (still an usable bitrate for a release...)
2014-03-15 20:03:02 < Daemon404> JEEB, im trying the same clip i tried in x264 vs $proprietary_hevc_encoder
2014-03-15 20:03:17 < JEEB> 24 to 22 is something that I consider relatively high bit rate
2014-03-15 20:03:23 < JEEB> very little visible artifacts if an
2014-03-15 20:03:25 < JEEB> *any
2014-03-15 20:03:33 < Daemon404> maybe for anime
2014-03-15 20:03:38 < Daemon404> because x265 biases towards blur
2014-03-15 20:04:00 < Mandarinka> actually, at that huge bitrate, x265 looked quite transparent in most places
2014-03-15 20:04:00 < JEEB> well, yeah -- I'm talking about blocking artifacts etc
2014-03-15 20:04:06 < Mandarinka> or, almost absolutely
2014-03-15 20:04:27 < Mandarinka> but in certain flat areas, it was washing the texture - curiously, only in some.
2014-03-15 20:04:34 < Mandarinka> well, 18 megabits, so...
2014-03-15 20:05:09 < Daemon404> [25.3%] 152/600 frames, 0.01 fps, 4232.53 kb/s, eta 10:33:39
2014-03-15 20:05:11 < Daemon404> crf 24
2014-03-15 20:05:21 < Daemon404> not that at ~5800, the proprietary encoder shat itself
2014-03-15 20:05:34 < Daemon404> anf x264  hadnoticable facts, but faired MUCH better
2014-03-15 20:05:41 < JEEB> :)
2014-03-15 20:13:28 < Easyfab> I see some psy-rd patch on x265-devel list so perhaps less blur soon
2014-03-15 20:14:26 < Mandarinka> that just a building block I think
2014-03-15 20:14:37 < JEEB> yeah
2014-03-15 20:14:53 < Mandarinka> it might be quite a struggle to make psyrdo behave in x265, give the differences
2014-03-15 20:15:28 < Mandarinka> also, x265 has RDO stuff taken over from HM (iirc?), so that might be a problem perhaps
2014-03-15 20:16:41 < Easyfab> Ok so no psyrdo soon :(
2014-03-15 20:17:51 < Mandarinka> well, it hasn't even been a year since the start of the project, let alone the public launch
2014-03-15 20:21:28 < smarter> Daemon404: are the proprietary hevc encoders any good?
2014-03-15 20:55:48 < Daemon404> lol
2014-03-15 20:55:53 < Daemon404> lol.
2014-03-15 20:56:55  * Mandarinka imagines a dude doing the same job at youtube, evaluating possible encoders for it.
2014-03-15 20:57:02 < Mandarinka> and then they get told to use VP9.
2014-03-15 20:57:46 < Mandarinka> although I guess VP9 could be made useful for youtube levels of "quality", because large portion of their videos are so horrible
2014-03-15 20:58:11 < nevcairiel> VP9 doesn't have bad quality really
2014-03-15 20:58:16 < nevcairiel> its just so extremely terribly slow
2014-03-15 20:58:24 < nevcairiel> (encoding)
2014-03-15 20:58:43 < Mandarinka> yeah, which is why I reckon they are using fast presets
2014-03-15 20:58:48 < nevcairiel> x265 moves like a lightning bolt in comparison
2014-03-15 20:59:15 < Mandarinka> I wonder how long those clips I tried last year took
2014-03-15 20:59:21 < Mandarinka> one was 2400 frames
2014-03-15 20:59:30 < Mandarinka> heh, but at least it was SD.
2014-03-15 20:59:50 < JEEB> youtube just cuts at GOPs and encodes like that so VP9's slowness is a bit less of a problem. But yes, they most definitely are not maxing the encoder out
2014-03-15 21:00:02 < nevcairiel> I got something like 3 fpm on a full HD encode at max quality settings
2014-03-15 21:00:08 < nevcairiel> a couple weeks back
2014-03-15 21:00:50 < JEEB> Mandarinka, grabbed the hyouka sample?
2014-03-15 21:00:51 < nevcairiel> using one core only of course
2014-03-15 21:00:59 < Daemon404> because there' a choice?
2014-03-15 21:01:00 < Daemon404> :P
2014-03-15 21:01:13 < nevcairiel> could employ splitting techniques
2014-03-15 21:01:19 < Daemon404> lol
2014-03-15 21:02:06 < nevcairiel> its not an invalid strategy really,  just a bit complicated to pull off if you don't have a finished setup to run it
2014-03-15 21:02:22 < Mandarinka> JEEB: yeah, it has finished now.
2014-03-15 21:02:24 < JEEB> k
2014-03-15 21:02:47 < JEEB> I have coppelion's opening as well, which has some lulzy amounts of grain
2014-03-15 21:09:00 < Mandarinka> well, I think I will have enough just doing this. I'm really curious what will the performance be like
2014-03-15 21:09:28 < Mandarinka> probably best to start looking for a significantly faster cpu in any case
2014-03-15 21:45:53 < smarter> I think youtube use --cpu-used=1
2014-03-15 22:04:18 < nevcairiel> that parameter still has the weirdest name
2014-03-15 22:05:41 < Daemon404> what does it even do
2014-03-15 22:06:10 < nevcairiel> its the huge quality knob afaik
2014-03-15 22:06:17 < Daemon404> wtf?
2014-03-15 22:06:32 < Daemon404> i guess i get what it "means", but thats pretty. dmb
2014-03-15 22:06:36 < Daemon404> dumb*
2014-03-15 22:09:28 < nevcairiel> the parameter is a bit opaque really, it depends on the mode you used
2014-03-15 22:09:30 < Mandarinka> yeah, I agree
2014-03-15 22:09:48 < nevcairiel> vpx has a realtime encode mode where --cpu-used controls the target cpu usage of the encoder
2014-03-15 22:09:57 < nevcairiel> wonder how crappy it looks in realtime though
2014-03-15 22:10:02 < nevcairiel> or inefficient it is
2014-03-15 22:10:30 < Daemon404> probably uch wore than x264
2014-03-15 22:15:54 < smarter> realtime vp9 has been worked on a lot recently, but I haven't done any test
2014-03-15 22:16:14 < smarter> beating x264 is going to be tough
--- Day changed Sun Mar 16 2014
--- Day changed Mon Mar 17 2014
2014-03-17 12:49:13 < Daemon404> vp9.... 1 frame encoded
2014-03-17 12:49:16 < Daemon404> 40 hrs remaining
2014-03-17 12:49:22 < Daemon404> (probably more liek 80-120)
2014-03-17 12:52:20 < kodapad> Daemon404: Only?
2014-03-17 12:52:25 < Daemon404> lol
2014-03-17 12:52:30 < Daemon404> i dumped teh first keyframe
2014-03-17 12:52:34 < Daemon404> it's looks very very bad
2014-03-17 12:52:41 < Daemon404> (compared to x264 and x265)
2014-03-17 12:52:44 < Daemon404> it*
2014-03-17 12:53:18 < kodapad> Anything looks bad compared to them
2014-03-17 12:53:40 < Daemon404> btw, 4k test using best possible quality settings:
2014-03-17 12:53:41 < Daemon404> https://chromashift.org/samples/x265_crf24.hevc
2014-03-17 12:53:46 < Daemon404> https://chromashift.org/samples/x264_crf.h264
2014-03-17 12:54:00 < Daemon404> former took 19 hrs on a 24-core xeon (4k...)
2014-03-17 12:54:35 < Daemon404> latter was made using brent's method + crf
2014-03-17 18:18:32 < Daemon404> Pass 2/2 frame   57/32    182737B 15553831 ms 0.22 fpm [ETA 77:15:  44]
2014-03-17 18:18:34 < Daemon404> \o/
2014-03-17 23:03:05 < Rodeo> Daemon404: x265 has two-pass now?
2014-03-17 23:20:08 < smarter> Rodeo: that looks more like libvpx output
2014-03-17 23:55:40 < Daemon404> yep
2014-03-17 23:55:52 < Daemon404> besides
2014-03-17 23:56:05 < Daemon404> who needs 2pass when you have brent's method + shitloads of cpu time
2014-03-17 23:56:08 < Daemon404> duh
--- Day changed Tue Mar 18 2014
2014-03-18 01:01:01 < smarter> Daemon404: what's brent's method?
2014-03-18 01:03:49 < Daemon404> smarter, just another way to find a crf for a given bitrate
2014-03-18 01:04:05 < smarter> bisection?
2014-03-18 01:04:32 < Daemon404> "In numerical analysis, Brent's method is a complicated but popular root-finding algorithm combining the bisection method, the secant method and inverse quadratic interpolation."
2014-03-18 01:04:44 < smarter> fancy
2014-03-18 01:04:52 < Daemon404> except i am lazy and use scipy's impl
2014-03-18 01:05:27 < smarter> I might want to use that
2014-03-18 01:07:04 < smarter> though crf seems a bit too coarse-grained for matching bitrates
2014-03-18 01:07:21 < Daemon404> i got witin 2kbit/s last time
2014-03-18 01:07:26 < Daemon404> with 4 or 5 steps
2014-03-18 01:07:40 < smarter> out of how many? :)
2014-03-18 01:07:54 < Daemon404> how many what?
2014-03-18 01:08:10 < smarter> what was the average bitrate
2014-03-18 01:08:24 < Daemon404> 4610
2014-03-18 01:09:26 < smarter> I see, when I did my low-bitrates test I tried very hard to get the smallest differences possible
2014-03-18 01:11:31 < Daemon404> we'll see how vp9's RC does when it finishes in like 75 hrs
2014-03-18 08:30:09 < nevcairiel> does it accept fractional crf values?
2014-03-18 09:15:36 < LigH> Yo, JEEB.
2014-03-18 09:15:45 < LigH> I heard you like low bitrate samples.
2014-03-18 09:15:51 < LigH> So I added a few on MediaFire.
2014-03-18 13:49:04 < Rodeo> looking at https://bitbucket.org/multicoreware/x265/commits/c18a09b9d2d3
2014-03-18 13:49:17 < Rodeo> it seems cmake doesn't create an install manifest here either
2014-03-18 14:44:33 < Mandarinka> M:\avs2yuv -raw "n:\hyouka.avs" -o - | x265-08.50-64.exe - --input-res 1280x720 --fps 24000/1001 --preset placebo -b 16 --ref 16 --crf 32 -o n:\hyouka720p.hevc
2014-03-18 14:44:59 < Mandarinka> hmm, still getting 0,02 fps on AMD A8-3850 (4x 2,9 GHz K10 chip)
2014-03-18 14:45:12  * Mandarinka tries a different build
2014-03-18 14:48:29 < LigH> o?
2014-03-18 14:48:36 < LigH> --preset placebo
2014-03-18 14:48:43 < LigH> Which religion is that?
2014-03-18 14:48:46 < LigH> ;)
2014-03-18 14:48:49 < Mandarinka> it is testing.
2014-03-18 14:48:54 < LigH> OK.
2014-03-18 14:49:23 < Mandarinka> also I wanted to compare against JEEB's result
2014-03-18 14:49:28 < LigH> But here I am not surprised about any speed, or lack of.
2014-03-18 14:49:38 < Mandarinka> "x265 is pretty fast now, preset placebo and refs/bframes maxed is now ~0.4fps with 720p on a i5 3570K"
2014-03-18 14:49:50 < LigH> Will heavily depend on the instruction set.
2014-03-18 14:49:57 < LigH> Does an A8 support SSE4?
2014-03-18 14:50:05 < Mandarinka> yeah, I am wondering if that is the trouble
2014-03-18 14:50:12 < LigH> Very probably.
2014-03-18 14:50:14 < Mandarinka> since it is phenom-like, it onyl supports up to sse2
2014-03-18 14:50:37 < LigH> I have Phenom-II available, they are "slow" without SSE4 or AVX.
2014-03-18 14:50:43 < Mandarinka> based on raw power only, I should be hitting about 50% of his speed
2014-03-18 14:50:59 < Mandarinka> so 0,02 comapred to 0,4 fps is fishy
2014-03-18 14:52:10 < LigH> Let's try another one too. 720p with "insane" options...
2014-03-18 14:52:20 < Mandarinka> ah voilla voilla
2014-03-18 14:52:27 < Mandarinka> I am now trying the ICL build.
2014-03-18 14:52:34 < Mandarinka> speed is totally different
2014-03-18 14:53:03 < Mandarinka> looks like the MSVC builds at http://chromashift.org/x265_builds/ don't use ASM properly
2014-03-18 14:53:14 < LigH> OK ... ICL is famous for great C(++) code optimizing, and there is still a lot in it. Not yet everything is assembler tuned.
2014-03-18 14:53:31 < Mandarinka> nope, ICL won't cause an order of magnitude difference
2014-03-18 14:53:36 < Mandarinka> disabled assembly will
2014-03-18 14:53:42 < Daemon404> it's also famous for miscompiling
2014-03-18 14:53:46 < LigH> You might compare with GCC too.
2014-03-18 14:54:05 < Rodeo> just build your own already :P
2014-03-18 14:54:10 < LigH> https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC
2014-03-18 14:54:12 < Daemon404> [14:49] < Mandarinka> looks like the MSVC builds at http://chromashift.org/x265_builds/ don't use ASM properly
2014-03-18 14:54:15 < Daemon404> those are mine
2014-03-18 14:54:17 < Daemon404> ill check
2014-03-18 14:54:32 < LigH> Rodeo: I do, see ^
2014-03-18 14:55:17 < Mandarinka> I am getting 0,02 fps out of http://chromashift.org/x265_builds/x265-0.8.50-msvc2012-64.7z  and currently ~0,10 fps out of http://chromashift.org/x265_builds/x265-0.8.161-icl14.0-64.7z
2014-03-18 14:55:26 < Mandarinka> but the latter encode has not run long, so not precise
2014-03-18 14:55:39 < Mandarinka> the speed seems to be ~order of magniture higher though
2014-03-18 14:57:20 < Daemon404> [14:46] < LigH> I have Phenom-II available, they are "slow" without SSE4 or AVX.
2014-03-18 14:57:23 < Daemon404> er fail
2014-03-18 14:57:38 < Daemon404> [14:46] < LigH> I have Phenom-II available, they are "slow" without SSE4 or AVX.
2014-03-18 14:57:43 < Daemon404> fuck... sorry
2014-03-18 14:57:46 < Daemon404> clipboard fail over rdp
2014-03-18 14:58:10 < Daemon404> -- Found yasm: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/yasm.exe (found version "1.2.0")
2014-03-18 14:58:13 < Daemon404> -- Found Yasm 1.2.0 to build assembly primitives
2014-03-18 14:58:15 < Daemon404> and it builds the /asm files
2014-03-18 14:59:31 < Daemon404> so it looks like it does indeed link it in
2014-03-18 14:59:55 < Daemon404> x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
2014-03-18 14:59:55 < Daemon404> x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
2014-03-18 15:00:30 < Mandarinka> yeah, it shows it is using the SIMD to me, too
2014-03-18 15:00:43 < LigH> Mandarinka: Encoding LDV "parkrun" 720p50, building the pyramid, started around 0.3 fps but decreasing ...
2014-03-18 15:02:03 < Mandarinka> yeah, it gradually starts checking more references as it moves from the first iframe
2014-03-18 15:02:09 < Mandarinka> or something
2014-03-18 15:03:30 < Mandarinka> I'll try to make some more comparable/controlled results and let you know, Daemon404
2014-03-18 15:04:42 < Daemon404> there are people on that videohelp forum who seem to see it too
2014-03-18 15:06:27 < Daemon404> [14:50] < Daemon404> ill check
2014-03-18 15:06:30 < Daemon404> fff fail
2014-03-18 15:07:12 < Daemon404> Mandarinka, openeing the msvc build in ida pro shows all the asm symbols
2014-03-18 15:07:17 < Daemon404> so theyre linked in.
2014-03-18 15:08:35 < Mandarinka> x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT <--- here too
2014-03-18 15:08:47 < Mandarinka> well, I'll have a look at it later
2014-03-18 15:08:49 < Daemon404> https://www.dropbox.com/s/r6md1mijr8sm7gi/ida.png
2014-03-18 15:09:53 < LigH> Current encoding speed of my GCC 4.8.2 Win64 build (Phenom-II X4 945, SSE2Fast): ~0.08 fps ... but the material is also very hard.
2014-03-18 15:10:51 < Daemon404> someone should just ask
2014-03-18 15:10:53 < Daemon404> muggs
2014-03-18 15:14:37 < LigH> ETA: >1:30h... for 10 seconds material = 500 frames :o
2014-03-18 15:15:11 < LigH> I remember how I calculated fractals with a C=16
2014-03-18 15:15:14 < Daemon404> i encoded a 4k clip of 600 frames with x265 for 18 hrs ;)
2014-03-18 15:15:29 < LigH> Now the climate change has a reason. :P
2014-03-18 15:16:20 < Daemon404> (vp9 is slated to take 88hrs)
2014-03-18 15:16:37 < LigH> :'(
2014-03-18 15:16:46 < Daemon404> i should mention 18 hrs on 24 cores
2014-03-18 15:16:56 < LigH> *greed*
2014-03-18 15:17:13 < LigH> *jealousy*
2014-03-18 15:17:42 < LigH> I tried to encode an 8K test with only 8 GB RAM. Stupid idea.
2014-03-18 15:17:50 < LigH> *swapping*
2014-03-18 15:18:24 < Daemon404>              total       used       free     shared    buffers     cached
2014-03-18 15:18:24 < Daemon404> Mem:      99051988   88500736   10551252          0     334896   80296884
2014-03-18 15:19:26 < Daemon404> theres no sane way i could run these on consumer hw
2014-03-18 15:25:08 < LigH> ProcessExplorer reported nearly 12 GB "Private Bytes" for the process", the "Working set" was close to 7.9 GB.
2014-03-18 15:38:45 < LigH> When does JEEB awake?
2014-03-18 19:13:56 < Daemon404> hey smarter ping
2014-03-18 19:14:06 < smarter> Daemon404: pong
2014-03-18 19:14:15 < Daemon404> you know that comparison thingy you made?
2014-03-18 19:14:26 < Daemon404> can it be adapted to image sequences
2014-03-18 19:14:29 < Daemon404> or is it html5 vid only
2014-03-18 19:15:20 < smarter> Daemon404: you can put images now :)
2014-03-18 19:15:28 < Daemon404> no
2014-03-18 19:15:32 < Daemon404> i mean sequences
2014-03-18 19:15:34 < Daemon404> specifically.
2014-03-18 19:15:37 < Daemon404> seekign etc
2014-03-18 19:15:40 < smarter> ah
2014-03-18 19:15:50 < Daemon404> because i cant compare hevc in it
2014-03-18 19:15:59 < smarter> convert hevc to lossless h264 ?
2014-03-18 19:16:11 < Daemon404> does that even work in chrome
2014-03-18 19:16:16 < smarter> why not?
2014-03-18 19:16:20 < nevcairiel> chrome uses ffh264, so why not?
2014-03-18 19:16:22 < smarter> chrome never stopped supporting h264
2014-03-18 19:16:23 < Daemon404> because chrome uses hwaccel
2014-03-18 19:16:25 < Daemon404> by default
2014-03-18 19:16:25 < smarter> hah
2014-03-18 19:16:27 < Daemon404> not ffh264.
2014-03-18 19:16:30 < smarter> didn't think of that
2014-03-18 19:16:42 < nevcairiel> chrome://flags/ -> turn off?
2014-03-18 19:16:43 < nevcairiel> :D
2014-03-18 19:16:51 < Daemon404> not suitable
2014-03-18 19:16:57 < Daemon404> i wanted to make it easy for my coworkers to compare tsuff
2014-03-18 19:17:08 < smarter> you could adapt it for sequences of images
2014-03-18 19:17:15 < Daemon404> i suck at web dev :P
2014-03-18 19:17:16 < smarter> since you can already put images
2014-03-18 19:17:21 < nevcairiel> maybe chrome is smart and checks profile before trying hwaccel?
2014-03-18 19:17:22  * nevcairiel tests
2014-03-18 19:17:25 < smarter> try lossless VP9? :]
2014-03-18 19:17:29 < Daemon404> smarter, also does it do 3way?
2014-03-18 19:17:34 < nevcairiel> kinky
2014-03-18 19:17:35 < smarter> no
2014-03-18 19:17:37 < Daemon404>  have 2 hevc encoders, and x264
2014-03-18 19:17:41 < Daemon404> (vp9 is still encoding
2014-03-18 19:17:41 < smarter> hmm
2014-03-18 19:18:05 < Daemon404> im noticing the quality varies a LOT between frames
2014-03-18 19:18:12 < smarter> maybe lossless VP9 with fast speed settings would work
2014-03-18 19:18:24 < Daemon404> hmm
2014-03-18 19:18:25 < smarter> don't know how fast that would be :p
2014-03-18 19:18:27 < nevcairiel> hm too bad, chrome isn't smart and non-hw compatible profiles dont play
2014-03-18 19:18:36 < smarter> derp
2014-03-18 19:18:38 < nevcairiel> its not that much work, why are devs always lazy
2014-03-18 19:18:48 < Daemon404> nevcairiel, more like hw supported profiles dont even play half the time
2014-03-18 19:19:04 < smarter> 3-way comparisons sound complicated
2014-03-18 19:19:11 < Daemon404> well
2014-03-18 19:19:18 < Daemon404> i ust want to easily flip between them
2014-03-18 19:19:22 < Daemon404> i guess i coud just use 3 tabs
2014-03-18 19:19:23 < Daemon404> lol.
2014-03-18 19:19:26 < smarter> it's already CSS hell to do 2-way comparisons :p
2014-03-18 19:19:33 < Daemon404> the problem also is that its 4k
2014-03-18 19:19:36 < Daemon404> and nobody has a 4k monitor
2014-03-18 19:19:43 < Daemon404> so i need accurate zooming
2014-03-18 19:20:17 < smarter> isn't everybody using his own zooming interpolation algorithm anyway?
2014-03-18 19:20:25 < Daemon404> no i mean 100%
2014-03-18 19:20:30 < Daemon404> no resizing
2014-03-18 19:20:37 < Daemon404> but sliding between diff parts of the image
2014-03-18 19:20:40 < Daemon404> for all 3
2014-03-18 19:21:08 < nevcairiel> sounds like fun
2014-03-18 19:21:23 < smarter> ah i see
2014-03-18 19:21:53 < Daemon404> nevcairiel, you cant actually compare fuck all on a highdpi monitor in a browser
2014-03-18 19:21:55 < Daemon404> due to scalin
2014-03-18 19:22:02  * Daemon404 reverted back to his craptop
2014-03-18 19:22:19 < nevcairiel> just configure it to default dpi without scaling?
2014-03-18 19:22:30 < Daemon404> true
2014-03-18 19:22:38 < nevcairiel> windows will be tiny, but what can you do
2014-03-18 19:23:50 < Daemon404> do you gusy want the streams or anything
2014-03-18 19:23:56 < Daemon404> one guy viewing always skews
2014-03-18 19:29:06 < Daemon404> looks like x264 more or less stll beats (or ties) the prorietary encoder and x265
2014-03-18 19:29:20 < Daemon404> hpw boring
2014-03-18 19:30:01 < nevcairiel> i read that x265 can beat  x264 on lower bitrates now, but dont think that was on 4k
2014-03-18 19:30:23 < Daemon404> i dont care about lower bitrates
2014-03-18 19:30:28 < Daemon404> rather, vimeo doesnt.
2014-03-18 19:30:43 < nevcairiel> dont streaming sites love using less bandwidth? :d
2014-03-18 19:31:00 < Daemon404> we care more about quality
2014-03-18 19:31:10 < Daemon404> https://chromashift.org/samples/x265_crf24.hevc
2014-03-18 19:31:16 < Daemon404> https://chromashift.org/samples/x264_crf.h264
2014-03-18 19:31:20 < Daemon404> https://chromashift.org/samples/v265.hevc
2014-03-18 19:31:36 < Daemon404> x265 seems to beat x264 on maybe 2-4 frames
2014-03-18 19:31:39 < smarter> meh
2014-03-18 19:32:34 < smarter> how fast is the proprietary encoder?
2014-03-18 19:32:47 < Daemon404> ~90 minutes for that
2014-03-18 19:32:50 < Daemon404> vs x264's 18
2014-03-18 19:32:56 < Daemon404> for that particular stream
2014-03-18 19:34:40 < nevcairiel> i dunno, I can see quite a bit of artifacting on that graffiti wall in the x264 stream which is not present in x265
2014-03-18 19:35:19 < nevcairiel> v265 seems to also have it to a lesser extend
2014-03-18 19:35:31 < nevcairiel> may just be x265s blur, but still
2014-03-18 19:35:51 < Daemon404> i tend to care more about coreground
2014-03-18 19:36:01 < Daemon404> x265 really rapes it in a large chunk of the stream
2014-03-18 19:36:06 < Daemon404> hair especially
2014-03-18 19:36:41 < Daemon404> (im also iclined to prefer artefating to blur)
2014-03-18 19:37:04 < nevcairiel> without the source its hard to say if much has been lost
2014-03-18 19:37:20 < Daemon404> i can pload that if you want
2014-03-18 19:37:44 < nevcairiel> nah, i'll forget about this in an hour anyway
2014-03-18 19:37:47 < Daemon404> lol k
2014-03-18 19:37:53 < Daemon404> teh bangs and eyebrows are pretty hard hit
2014-03-18 19:37:56 < Daemon404> a is the black glove
2014-03-18 19:37:58 < Daemon404> as*
2014-03-18 20:37:14 < Daemon404> muggs, any particular reason why the msvc build is an order of magnitude slower than icl or mingw
2014-03-18 20:59:00 < Mandarinka> actually, from a run of 50 frames (patience was short...), I got 0,02 fps versus 0,06 fps, few hours ago: [ICL] "49 frames in 839.26s (0.06 fps)"  [MSVC] "48 frames in 2721.93s (0.02 fps)"
2014-03-18 20:59:35 < Mandarinka> it was quite a PITA waiting for the results and having the machine unused for them to be accurate, so I didn't make better tests yet.
2014-03-18 20:59:52 < Mandarinka> that was on a SSE2 CPU (AMD Llano)
2014-03-18 21:04:11 < Easyfab> It's probably a problem with msvc 1700, because my build with msvc 1800 is as fast as icl build
2014-03-18 21:12:11 < Easyfab> could you try the speed of msvc 1800 build  http://files.videohelp.com/u/225629/x265.7z
2014-03-18 21:16:55 < Mandarinka> ah, missing dll
2014-03-18 21:17:11 < Mandarinka> which redistributable does it need?
2014-03-18 21:17:17 < nevcairiel> 1800 is 2013
2014-03-18 21:18:04 < Easyfab> http://www.microsoft.com/en-us/download/details.aspx?id=30679
2014-03-18 21:18:30 < Easyfab> oups http://www.microsoft.com/en-us/download/details.aspx?id=40784
2014-03-18 21:18:53 < Mandarinka> ok
2014-03-18 21:19:24 < Mandarinka> yeah, based how fast is it at the first frames, I think this matches the ICL at least
2014-03-18 21:34:27 < Mandarinka> "54 frames in 889.21s (0.06 fps)"
2014-03-18 21:34:36 < Mandarinka> so yes, that matches ICL
2014-03-18 21:36:10 < Daemon404> fun
2014-03-18 21:36:28 < Easyfab> Is  your msvc 1700 version the release or debug version ?
2014-03-18 21:36:29 < Mandarinka> indeed
2014-03-18 21:37:10 < Mandarinka> also, that 1800 build is substantially smaller in filesize
2014-03-18 21:37:28 < Mandarinka> 1,57 versus 2,77 MB
2014-03-18 21:37:40 < Easyfab> That's why I ask about the debug version
2014-03-18 21:38:08 < Mandarinka> Daemon404's ICL is 4,63 MB though
2014-03-18 21:41:24 < Daemon404> i link to the runtime statically.
2014-03-18 21:41:32 < Mandarinka> ah, right
2014-03-18 21:41:43 < Mandarinka> that one disn't occur to me lol
2014-03-18 21:42:07 < Mandarinka> indeed, it didn't require the redistributable, right.
2014-03-18 21:44:07 < muggs> I imagine the /Ob2 always inline flag is pretty brutal for VC
2014-03-18 21:44:33 < muggs> that was added back when we were using the SIMD vector classes, it may not help much any more
2014-03-18 22:40:33 < nevcairiel> Ob2 is default in O2
2014-03-18 22:40:41 < nevcairiel> nothing special really
2014-03-18 22:41:29 < nevcairiel> heck even in O1
2014-03-18 22:42:59 < nevcairiel> ..unless you don't set O2 :p
2014-03-18 22:45:30 < muggs> in that case, I have no idea.
--- Day changed Wed Mar 19 2014
2014-03-19 13:16:01 < Daemon404> Pass 2/2 frame  378/353  1437474B 170466231 ms 0.13 fpm [ETA 33:08:  2]
2014-03-19 13:16:02 < Daemon404> soon
2014-03-19 13:17:01 < JEEB> reminds me of someone wanting to encode vp9 on #ffmpeg today
2014-03-19 13:17:12 < JEEB> thankfully he was already aware of the blazing speeds of libvpx
2014-03-19 14:01:25  * Mandarinka wonders if it does fpd too
2014-03-19 17:21:27 < smarter> Daemon404: what settings are you using?
2014-03-19 17:23:12 < Daemon404> --best
2014-03-19 17:23:18 < Daemon404> --cpu-used=0 was far too crappy
2014-03-19 17:23:21 < Daemon404> visually
2014-03-19 17:23:26 < Daemon404> so i thought i might as well
2014-03-19 17:24:02 < smarter> the quality difference between --best and --good should be minimal, but --best is extremely slow
2014-03-19 17:27:06 < smarter> I think the only difference is the motion search which is slightly better but extremely slower: https://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=b295092b8fcac34fd657df45b15fed54ed89b814
2014-03-19 17:30:07 < smarter> ah and adaptive_rd_thresh=0 too,  so no modes get skipped in the rd loop
2014-03-19 17:47:34 < Daemon404> smarter, in this case, vp9 is underperforming on all the clips i tested with
2014-03-19 17:47:37 < Daemon404> i.e. worse than x264
2014-03-19 17:47:50 < Daemon404> if that is true.
2014-03-19 17:47:53 < smarter> 4K stuff?
2014-03-19 17:47:58 < Daemon404> some
2014-03-19 17:48:05 < Daemon404> and some 1080 and 720
2014-03-19 17:48:30 < smarter> sounds bad
2014-03-19 17:48:31 < nevcairiel> on 1080p we measured at least better SSIMs for vp9 on equal bitrate (ignoring encoding time), visual comparison was inconclusive most of the time
2014-03-19 17:48:58 < smarter> I wonder if it's due to the lack of something similar to b-pyramids
2014-03-19 17:49:32 < Daemon404> i only compared visually
2014-03-19 17:49:39 < Daemon404> vp9 was always blurry/smudgy
2014-03-19 17:50:26 < smarter> are the results of your tests and your samples going to be public?
2014-03-19 17:50:39 < Daemon404> they cant be
2014-03-19 17:50:43 < Daemon404> im testing on user content
2014-03-19 17:50:45 < Daemon404> :P
2014-03-19 17:50:56 < Daemon404> i also dont care about metrics
2014-03-19 17:51:04 < Mandarinka> did VP9 end up substatntially more blurry/washed out than x265?
2014-03-19 17:51:26 < Daemon404> same or woese from my tests
2014-03-19 17:51:39 < Daemon404> and x265 still either tied or lost to x264, except on a few keyframes
2014-03-19 17:52:14 < smarter> all of this is at high bitrates?
2014-03-19 17:52:21 < Daemon404> mid to high
2014-03-19 17:52:28 < Daemon404> i dont care about ridiculously low bitrates
2014-03-19 17:52:48 < Daemon404> although i wouldnt call 4600 kbit/s for 4k "high"
2014-03-19 17:52:51 < Daemon404> its still fugly
2014-03-19 17:54:02 < Daemon404> https://vimeo.com/channels/staffpicks/89093895 <-- currently running on the 100 mbit/s source for this
2014-03-19 17:54:17 < Daemon404> https://vimeo.com/65153479 <-- and source for this video (because it's evil)
2014-03-19 17:57:41 < smarter> looks like a good test of refs handling :]
2014-03-19 17:58:25 < smarter> x265 doesn't have anything like psy-rd yet, right?
2014-03-19 17:58:34 < Daemon404> not yet
2014-03-19 17:58:39 < Daemon404> some psy stuff is tarting to trickle in
2014-03-19 17:58:49 < Daemon404> but theyre just porting x264s hadamard tf as-is
2014-03-19 17:58:53 < Daemon404> which probably wont work
2014-03-19 17:59:02 < Daemon404> due to hevc's larger blocks (iirc)
2014-03-19 17:59:05 < smarter> yeah
2014-03-19 17:59:07 < Nosomy> for me, x265 looks better than x264, saving 15% bitrate, compared to x264 to keep the same quality. the problem is only encode speed, 10 times slower.
2014-03-19 17:59:25 < Daemon404> Nosomy, definitely not at all here
2014-03-19 17:59:31 < Daemon404> unless you prefer blur
2014-03-19 17:59:38 < Daemon404> or have very flat things (newer anime)
2014-03-19 17:59:49 < smarter> the satd stuff already is hacky in x264 (does some kind of average to avoid favoring one size of block), it seems hard to get that right when block sizes vary between 4x4 and 64x64
2014-03-19 17:59:57 < Nosomy> well, my source of test is gameplay....
2014-03-19 18:00:25 < Daemon404> smarter, yes that was my ponint
2014-03-19 18:00:31 < smarter> I'm trying to implement weighted distortion in libvpx, we'll see if that works
2014-03-19 18:00:48 < Daemon404> you cant blindly port x264's like i see on the x265 ml
2014-03-19 18:00:52 < Daemon404> i think Skyler_ pointed it out
2014-03-19 18:01:03 < smarter> I think he suggested weighted dist too
2014-03-19 18:01:33 < Daemon404> Nosomy, interesting
2014-03-19 18:01:48 < Daemon404> smarter, the worsetoff test clips were also high fps btw
2014-03-19 18:01:54 < Daemon404> 50 or 60 fps
2014-03-19 18:02:02 < Daemon404> worst-off*
2014-03-19 18:02:08 < smarter> I don't know what to infer from that :]
2014-03-19 18:02:20 < Daemon404> me neither
2014-03-19 18:02:32 < Daemon404> but quality would vary *wildly* between frames
2014-03-19 18:02:35 < Daemon404> with x265
2014-03-19 18:04:01 < Daemon404> i do also wish x265 would get 2pass -- it would make testing much easier
2014-03-19 18:04:08 < Nosomy> well, my sorce is 1280x720p 30fps gameplay of Portal 1...
2014-03-19 18:04:11 < Daemon404> ... and vpx's 2pass misses the target massively
2014-03-19 18:04:14 < Daemon404> on some occasions
2014-03-19 18:04:27 < Daemon404> Nosomy, lots of flat colors in portal
2014-03-19 18:04:28 < smarter> ratecontrol is hard, let's go shopping
2014-03-19 18:04:34 < Daemon404> bloom effect white iirc
2014-03-19 18:04:52 < Daemon404> smarter, sure but 2-3x off is not acceptable
2014-03-19 18:04:55 < Daemon404> at all.
2014-03-19 18:07:14 < smarter> yeah, there's something seriously wrong in there
2014-03-19 19:37:50 < muggs> our transform sizes go from 32x32 to 4x4, but point taken. stapling x264's approach onto HEVC is not likely to go well
2014-03-19 19:38:58 < muggs> but we have noticed that at the presets that do RDO quant, they tend to pick to encode bigger transforms with few large coeff, leading to blurry blocks
2014-03-19 19:39:48 < smarter> it's a hard problem
2014-03-19 19:45:00 <@Skyler_> psy rd of some sort should help
--- Day changed Thu Mar 20 2014
--- Day changed Fri Mar 21 2014
2014-03-21 09:32:45 < j-b> 'morning
2014-03-21 14:51:39 < Daemon404> ohhhhhhh
2014-03-21 14:51:41 < Daemon404> vp9 finally finished
2014-03-21 15:20:42 < Daemon404> smarter,
2014-03-21 15:20:43 < Daemon404> -rw-r--r-- 1 derek dev 6917311 Mar 16 08:16 ../24.hevc
2014-03-21 15:20:43 < Daemon404> -rw-r--r-- 1 derek dev 6904223 Mar 18 16:15 ../p2.hevc
2014-03-21 15:20:43 < Daemon404> -rw-r--r-- 1 derek dev 2612948 Mar 20 21:55 test.webm
2014-03-21 15:20:43 < Daemon404> -rw-r--r-- 1 derek dev 6918705 Mar 16 17:37 ../x264_crf.h264
2014-03-21 15:20:48 < Daemon404> ^ see what i mean
2014-03-21 15:20:53 < Daemon404> by terrible ratecontrol?
2014-03-21 15:21:07 < Daemon404> one of these 4 encoders is unususable. guess which.
2014-03-21 15:22:17 < JEEB> lol
2014-03-21 15:34:18 < nevcairiel> which mode did you use? 2-pass bitrate target?
2014-03-21 15:35:31 < nevcairiel> when we did a bunch of test encodes a couple weeks ago, vp9 would overshoot the bitrate target on some samples, by a factor of  2 or so
2014-03-21 15:36:21 < Daemon404> nevcairiel, 2pass
2014-03-21 15:36:24 < Daemon404> target bitarte
2014-03-21 15:36:27 < Daemon404> with --best
2014-03-21 15:36:34 < Daemon404> it undershot by a lot
2014-03-21 15:36:51 < nevcairiel> probably depends on the data it gets
2014-03-21 15:36:56 < Daemon404> yeah
2014-03-21 15:37:03 < Daemon404> but no otehr encoder screwed up this much
2014-03-21 15:37:08 < Daemon404> even xvid did better RC-wise
2014-03-21 16:20:10 < smarter> Daemon404: if you care enough you could file a bug report
2014-03-21 16:20:22 < smarter> it seems to be something that only happens with rather long clips
2014-03-21 16:20:28 < Daemon404> uh
2014-03-21 16:20:30 < Daemon404> this is 600 frames
2014-03-21 16:20:44 < smarter> then I don't know :p
2014-03-21 16:22:21 < smarter> is it 4K?
2014-03-21 16:23:36 < Daemon404> 4k
2014-03-21 16:23:37 < Daemon404> 50 fps
2014-03-21 16:29:21 < smarter> and what was the bitrate?
2014-03-21 16:29:28 < Daemon404> 4610
2014-03-21 16:33:20 < smarter> yeah, unless libvpx thought you were encoding at 130fps that doesn't make any sense
2014-03-21 16:35:11 < Daemon404>  ./vpxenc --best --kf-max-dist=250 --aq-mode=1 --target-bitrate=4610 --fps=50/1 --width=3840 --height=2160 -o test.webm --codec=vp9 --passes=2 ../v3.yuv
2014-03-21 16:36:16 < smarter> aq-mode=1 might have an impact, but it shouldn't be anywhere this bad
2014-03-21 16:36:43 < smarter> (also maybe this discusssion should take in place in #vp8 :])
2014-03-21 18:14:13 < Daemon404> smarter, my problem with that channel (and #theora) is that alf the people are freetards
2014-03-21 18:14:17 < Daemon404> with no technical info
2014-03-21 18:14:20  * Daemon404 runs
2014-03-21 22:45:40 < darkbasic> Daemon404: lol, didn't try with 4K but with my 1080p sample it was quite accurate
--- Day changed Sat Mar 22 2014
--- Log closed Sat Mar 22 14:05:01 2014
--- Log opened Sat Mar 22 15:51:40 2014
--- Day changed Sun Mar 23 2014
2014-03-23 18:36:08 < koda> Libav 10 released \o/
2014-03-23 18:36:21 < koda> unfortunately without libx265, but that will be in 11 ;)
2014-03-23 18:36:49 < Daemon404> api is too unstable for a release
--- Day changed Mon Mar 24 2014
2014-03-24 09:43:28 < j-b> 'morning
2014-03-24 15:05:25 < Daemon404> Rodeo, ping
2014-03-24 15:16:00 < Daemon404> hmm nvm
2014-03-24 16:05:51 < Rodeo> Daemon404: pong
2014-03-24 16:05:56 < Rodeo> oh, OK
2014-03-24 16:06:17 < Daemon404> i pushed the patches from yesterday
2014-03-24 16:06:26 < Rodeo> next time use my nick also for the nvm part ;-)
2014-03-24 16:06:31 < Daemon404> lol k
2014-03-24 16:08:24 < Rodeo> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=206d533 :-)
2014-03-24 16:09:07 < Daemon404> id rather keep the files the same between projects
2014-03-24 16:09:23 < Daemon404> and the coding style consistent
2014-03-24 16:11:44 < koda> Daemon404 you just got Diego’d
2014-03-24 16:12:04 < Daemon404> koda, more liek i got mini'd
2014-03-24 21:31:29  * Daemon404 wonders what kalray is
--- Day changed Tue Mar 25 2014
2014-03-25 09:35:34 < j-b> 'morning
2014-03-25 15:28:43 < Zeranoe__> The recent change to drop support for XP is causing havoc in the FFmpeg Windows builds: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889 http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1882 http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=1888
2014-03-25 15:30:16 < Daemon404> Zeranoe__, tell them to use an OS which its own company still supports
2014-03-25 15:31:27 < Daemon404> nobody is going to need hevc encoding on something runnign xp
2014-03-25 15:31:30 < Daemon404> let alone 32-bit xp
2014-03-25 15:33:35 < Zeranoe__> with x265 forcing Vista support it causes all of FFmepg to not work on XP. It isn't just x265 that this effects
2014-03-25 15:34:13 < Daemon404> then dont build with x265 for it?
2014-03-25 15:34:15 < Zeranoe__> I'd rather not patch a local copy of x265 just to include support for XP users
2014-03-25 15:34:52 < Daemon404> it's up to muggs, but i think it will end up with "we dont care"
2014-03-25 15:34:54 < Zeranoe__> There is any way to support XP in the current x265
2014-03-25 15:35:09 < Zeranoe__> ?
2014-03-25 15:35:29 < Daemon404> no
2014-03-25 15:35:35 < Daemon404> i think it was deemed do not care
2014-03-25 15:35:44 < Daemon404> i saw a thread on the ML
2014-03-25 15:35:48 < Daemon404> i can't say i disgree
2014-03-25 15:35:50 < Daemon404> xp is dead.
2014-03-25 15:36:01 < Daemon404> (and 32bit hevc encoding is retarded)
2014-03-25 15:36:30 < Zeranoe__> As much as I agree that users should not be using XP anymore, it seems people still use it and continue to.
2014-03-25 15:36:55 < Daemon404> i remember all the butthurt when ffmpeg dropped win2k support
2014-03-25 15:37:02  * Daemon404 looks forward to it much worse this time
2014-03-25 15:39:12 < Zeranoe__> So if WIN32_WINNT was set to 0x0600, threading would no longer work in x265? It just seems like many other projects have managed to maintain XP support and remain cutting edge
2014-03-25 15:39:51 < Daemon404> because they have ridiuclpus wrappers for everything
2014-03-25 15:39:55 < Daemon404> ridiculous*
2014-03-25 15:40:06 < smarter> do you really need to build ffmpeg with x265 support?
2014-03-25 15:40:21 < Daemon404> his builds have teh kitchen since
2014-03-25 15:40:23 < Daemon404> sink*
2014-03-25 15:40:28 < Daemon404> even things like cavs
2014-03-25 15:40:32 < Zeranoe__> smarter: Yes, there was an uprise when it came out to include it
2014-03-25 15:40:49 < smarter> I see :)
2014-03-25 15:41:07 < smarter> though I doubt people actually use it
2014-03-25 15:41:21 < Daemon404> ... rofl, x264-devel is getting emails about xp support on x265
2014-03-25 15:41:28 < Daemon404> users truly are teh smartest
2014-03-25 15:41:40 < Daemon404> wait... that's a freaking ffmpeg dev
2014-03-25 15:41:43  * Daemon404 facedesks
2014-03-25 15:41:52 < Zeranoe__> Daemon404: I simply haven't dropped support for old libs
2014-03-25 15:42:19 < smarter> I can understand wanting to have one executable that works everywhere
2014-03-25 15:42:24 < Zeranoe__> And yes people use it, forum posts have been appearing as soon as I added support
2014-03-25 15:42:29 < Daemon404> it's really not x265's problem IMO
2014-03-25 15:42:41 < Daemon404> but as i said, its muggs call
2014-03-25 15:42:45 < Zeranoe__> Whos problem is it?
2014-03-25 15:42:54 < Daemon404> yours.
2014-03-25 15:48:03 < Zeranoe__> I admit I have some responsibility, but seeing it's x265 that dropped XP support I hardly think x265 is exempt
2014-03-25 15:48:31 < Daemon404> i think its pretty silly to re-add support for a dead OS for this reason
2014-03-25 15:49:23 < Daemon404> just wait until muggs comes onlien and poke him
2014-03-25 15:52:24 < Zeranoe__> I guess I don't understand the technical side of it, but what would happen if you just redefined WIN32_WINNT for 0x0600
2014-03-25 15:56:50 < Zeranoe__> muggs: How do you feel about adding back in XP support? It's causing FFmpeg as a whole to not work on XP
2014-03-25 15:58:05 < muggs> I wouldn't mind it, it is just a BW issue.  it might be a while before we get to it.
2014-03-25 15:58:23 < muggs> mimicing a condition var on XP is non-trivial
2014-03-25 15:59:09 < j-b> XP is EOL
2014-03-25 15:59:54 < Zeranoe__> Is it as simple as setting WIN32_WINNT to 0x0600?
2014-03-25 16:00:11 < Kovensky> that's vista btw
2014-03-25 16:00:31 < Daemon404> Zeranoe__, no
2014-03-25 16:00:50 < muggs> approach 3.3 here looked like a potential winner:  http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
2014-03-25 16:01:11  * Daemon404 sitll thinks it's pretty pointless to add support for an dead os
2014-03-25 16:02:16 < muggs> Min still prefers to use XP, so I expect this will get fixed once he gets his old XP laptop back from repairs.  Just hard to predict when that will be.
2014-03-25 16:02:30 < Zeranoe__> Daemon404: So you've never had hardware last over 10 years? I have, and while I hate XP sometimes it's the only thing that will run an old machine
2014-03-25 16:02:34 < Daemon404> ... min only JUST upgraded from a nonconforming compiler from 1998, muggs
2014-03-25 16:02:40 < Daemon404> i dont take someone like tha tseriously
2014-03-25 16:02:42 < Daemon404> >_>
2014-03-25 16:02:54 < Kovensky> VC6? o_O
2014-03-25 16:02:59 < Daemon404> yes
2014-03-25 16:03:19 < muggs> lol
2014-03-25 16:03:27 < muggs> some people are habitual
2014-03-25 16:03:41 < Daemon404> that is not conducive of a good programmer
2014-03-25 16:03:57 < Daemon404> in my eyes
2014-03-25 16:04:00 < Daemon404> unwillingness to change etc
2014-03-25 16:04:22 < muggs> I still use vi.. while not exactly dead it's about as old as I am
2014-03-25 16:04:30 < Daemon404> lol
2014-03-25 16:04:32 < Daemon404> at least use vim
2014-03-25 16:04:33  * Kovensky can't stand vi
2014-03-25 16:04:44  * Kovensky can somewhat deal with a customized vim
2014-03-25 16:04:44  * Daemon404 uses vim
2014-03-25 16:04:51 < Daemon404> difference beign vim is maintained
2014-03-25 16:04:56 < Daemon404> whilst vc6 is not
2014-03-25 16:05:17 < Daemon404> anywya, moving on
2014-03-25 16:05:24 < Kovensky> solution: upgrade to vs.net
2014-03-25 16:05:25  * Kovensky runs
2014-03-25 16:05:27 < Daemon404> muggs, ive had several requests from users and devs for a feature in x265
2014-03-25 16:05:36 < Daemon404> er
2014-03-25 16:05:38 < Daemon404> fail
2014-03-25 16:05:45 < Daemon404> something akin to b_repeat_headers in x264
2014-03-25 16:06:03 < muggs> it was quite interesting while the vector functions were being developed; some could compile and run on VC9, were then broken on VC10, and fixed again in a VC11 SP
2014-03-25 16:06:37 < Daemon404> well luckily thats a nonissue now
2014-03-25 16:06:41 < muggs> ah, I was wondering if that was going to be necessary.  I had a request for b_aud as well
2014-03-25 16:06:50 < Daemon404> ive had 2 or 3 people ask
2014-03-25 16:06:57 < Daemon404> and one guy submitted a patch to ffmpeg to do it manually
2014-03-25 16:07:04 < muggs> ouch
2014-03-25 16:07:05 < Daemon404> but everyone thought it ought to be in x265
2014-03-25 16:07:30 < muggs> I agree with them
2014-03-25 16:07:35 < Zeranoe__> muggs: So no time frame on when to except a patch for XP support
2014-03-25 16:08:18 < muggs> no.. with NAB approaching we're focused on fixing bugs and RC and blurriness
2014-03-25 16:09:09 < Zeranoe__> muggs: Any chance you know what commit XP support was dropped? I might revert for now
2014-03-25 16:09:22 < muggs> yes, just a sec
2014-03-25 16:09:36 < Daemon404> muggs, 2pass + details would be awesome
2014-03-25 16:09:49 < Daemon404> right now i have to test everything relative to x265's crf encode
2014-03-25 16:09:57 < Daemon404> which is kind of a pain
2014-03-25 16:10:28 < Mandarinka> details first though :D
2014-03-25 16:10:34 < Daemon404> :P
2014-03-25 16:10:45 < Mandarinka> those are an otherwise un-overcomeable problem
2014-03-25 16:10:50 < Daemon404> yeah
2014-03-25 16:11:00 < Mandarinka> while 2-pass not existing is merely annoyance
2014-03-25 16:11:00 < muggs> (8ac1e112f3ea) threading: use a pthread conditional variable instead of semaphore …
2014-03-25 16:11:27 < Zeranoe__> muggs: much appreciated
2014-03-25 16:11:28 < Daemon404> muggs, one last question: me=3 should only be very margianlly woese than the insanelty slow full me (4), right?
2014-03-25 16:12:04 < muggs> the star search is generally pretty good. I recently fixed some UMH bugs, it should be pretty good now too
2014-03-25 16:12:19 < Daemon404> umh is what?
2014-03-25 16:12:23 < Daemon404> i never saw it listed
2014-03-25 16:12:24 < muggs> x264
2014-03-25 16:12:27 < Daemon404> i mean i nx265
2014-03-25 16:12:29 < Daemon404> me=?
2014-03-25 16:12:35 < muggs> me=2
2014-03-25 16:12:45 < muggs> dia=0, hex, umh, star, full
2014-03-25 16:12:50 < Daemon404> wait, star is higher than umh?
2014-03-25 16:12:59  * Daemon404 must be mistaken about which is which
2014-03-25 16:14:16 < muggs> is b_repeat_headers an MP4 thing?
2014-03-25 16:14:20 < Daemon404> no
2014-03-25 16:14:23 < Daemon404> the opposite
2014-03-25 16:14:42 < Daemon404> for libx264, ffmpeg only uses it when *not* muxing to mkv or mp4
2014-03-25 16:14:53 < Daemon404> because those muxers take it as extradata, so only need it once
2014-03-25 16:15:17 < muggs> what else would you be muxing to at this point?
2014-03-25 16:15:37 < Daemon404> its used for raw hevc streams afaik
2014-03-25 16:15:40 < Daemon404> well rae h264
2014-03-25 16:15:48 < Daemon404> headers at iraps or something
2014-03-25 16:16:00 < Daemon404> rodeo or nevcairiel would know
2014-03-25 16:16:12 < muggs> ok, I'll take a look at x264's implementation
2014-03-25 16:16:27 < Daemon404> you can look at libx264.c in ffmpeg to see how they use  it
2014-03-25 16:16:58 < muggs> ah, so it repeats headers before keyframes
2014-03-25 16:17:08 < muggs> SPS + PPS
2014-03-25 16:17:14 < Daemon404> yea
2014-03-25 16:18:03 < nevcairiel> it basically converts keyframes to full random access points
2014-03-25 16:18:20 < nevcairiel> no good having a keyframe if you dont know the headers =)
2014-03-25 16:18:48 < muggs> should be a two-line patch
2014-03-25 16:19:01 < muggs> hmm.. maybe four
2014-03-25 16:19:32 < Daemon404> everything is one line if you try hard enough
2014-03-25 16:24:35 < muggs> x264 doesn't have a CLI flag for it, it auto-detects based on container format.
2014-03-25 16:24:52 < muggs> should I just let it default to 0?
2014-03-25 16:31:05 < muggs> anyone know if VPS should also be repeated?  it describes the dpb and other details
2014-03-25 16:36:49 < Daemon404> no idea
2014-03-25 16:37:33 < muggs> I figure it can't hurt, so I will
2014-03-25 16:47:22 < muggs> patch emailed
2014-03-25 18:08:17 < muggs> http://x265.readthedocs.org/en/latest/
2014-03-25 18:08:55 < Daemon404> rst?
2014-03-25 18:11:18 < Daemon404> muggs, it would be good if there was a list of option strings and or a func to get them
2014-03-25 18:11:21 < muggs> restructured text, it's a simple markup language used mainly for Python stuff
2014-03-25 18:11:22 < Daemon404> or did you already add that?
2014-03-25 18:11:34 < Daemon404> i keep getting asked what X is for -x265-params in ffmpeg
2014-03-25 18:11:37 < Daemon404> so i grep
2014-03-25 18:12:23 < muggs> the main thing was getting our docs in text format in the repo so they could be maintained with the code
2014-03-25 18:12:46 < muggs> no more PDF or DOCX files to maintain
2014-03-25 18:13:17 < Daemon404> yeah
2014-03-25 18:13:24 < Daemon404> too bad the hg repo is permanently huge
2014-03-25 18:13:29 < Daemon404> from all the binaries in it
2014-03-25 18:15:41 < muggs> huge? hmm, we are about 3x of x264's repo
2014-03-25 18:16:01 < muggs> such is life
2014-03-25 18:17:14 < muggs> I haven't figured out a sane way to expose the strings in x265_param_parse yet
2014-03-25 18:18:11 < Daemon404> linked list? length and a pointer to a static char**?
2014-03-25 18:20:34 < muggs> how would ffmpeg use the table?
2014-03-25 18:21:37 < Daemon404> hmm
2014-03-25 18:22:01 < Daemon404> ideally id like to list it somehow, but ffmpeg uses static structs for options
2014-03-25 18:22:03 < Daemon404> hmm.
2014-03-25 18:22:51 < Daemon404> a doc would be ok too
2014-03-25 18:34:08 < muggs> what would I need to add to make http://x265.readthedocs.org/en/latest/cli.html good enough for that?
2014-03-25 18:34:49 < Daemon404> muggs, mostly just needs to list what cli params map to what
2014-03-25 18:34:54 < Daemon404> iirc there was a bit of difference
2014-03-25 18:35:02 < Daemon404> and some tha tset multiple
2014-03-25 18:36:41 < muggs> yes, there are some CLI options with no param-parse support (--y4m and things related to files)
2014-03-25 18:36:58 < muggs> I could document where the differences were
2014-03-25 18:37:17 < Daemon404> yeah but those would be pretty useless for an  API
2014-03-25 18:37:27 < Daemon404> like, some of teh vui cli options set 3 or 4 things
2014-03-25 18:37:28 < Daemon404> iirc
2014-03-25 18:37:34 < Daemon404> unless those are handled
2014-03-25 18:37:41 < muggs> right, that's why they're handled in the CLI itself
2014-03-25 18:38:20 < Daemon404> if there's no analogue for parse_params, i'd just note what is set
2014-03-25 18:38:32 < muggs> ah, if you enable one of the VUI parts, it enables the flags above it to ensure the part you want is emitted
2014-03-25 18:38:39 < Daemon404> im not sure if this should go in separate docs or not
2014-03-25 18:38:48 < Daemon404> having that stfuf there mayconfused x265 cli users
2014-03-25 18:38:53 < Daemon404> but what do i know... im a dev
2014-03-25 18:38:54 < Daemon404> :V
2014-03-25 18:39:29 < muggs> heh, there's quite a lot of overlap.  for all non-CLI specific options, the params are handled via param_parse
2014-03-25 18:39:44 < Daemon404> yea
2014-03-25 18:39:50 < Daemon404> that was my thought
2014-03-25 18:59:51 < muggs> tweaking the doc setup, now there's:  http://x265.readthedocs.org/en/stable/  and   http://x265.readthedocs.org/en/default/
2014-03-25 20:11:06 < Mandarinka> http://forum.doom9.org/showthread.php?t=170395
2014-03-25 20:11:09 < Mandarinka> whoa
2014-03-25 20:11:58 < Daemon404> https://github.com/lheric/x265/commits/master
2014-03-25 20:12:04 < Daemon404> wow.
2014-03-25 20:12:22 < JEEB> Yet Another X265
2014-03-25 20:12:28 < JEEB> because we totally didn't have enough
2014-03-25 20:12:41 < JEEB> and the second chinese-started
2014-03-25 20:13:11 < Mandarinka> second we know about :)
2014-03-25 20:13:33 <@Skyler_> they should be more creative in their naming
2014-03-25 20:13:36 <@Skyler_> call it y265 or something
2014-03-25 20:14:26 < Mandarinka> x266
2014-03-25 20:15:10 < Daemon404> it uses coe from this x264
2014-03-25 20:15:15 < Daemon404> e.g.
2014-03-25 20:15:15 < Nosomy> lol
2014-03-25 20:15:16 < Daemon404> https://github.com/lheric/x265/blob/master/common/x86/intrapred.inc
2014-03-25 22:04:15 < muggs> http://x265.readthedocs.org/en/default/cli.html
2014-03-25 22:04:38 < muggs> I would appreciate feedback on this, this page should be our canonical source for CLI docs
2014-03-25 22:05:04 < muggs> it's still missing a couple of really new options, but should otherwise be in good shape now
2014-03-25 22:08:46 < muggs> this page is machine generated from doc/reST/cli.rst so it can be updated in any commit that changes the API
2014-03-25 22:10:36 < Daemon404> muggs, some of it isnt very useful
2014-03-25 22:10:56 < muggs> which bits?
2014-03-25 22:11:15 < Daemon404> "Maximum number of merge candidates."
2014-03-25 22:11:18 < Daemon404> "Enable Cbf fast mode."
2014-03-25 22:11:19 < muggs> I assume it needs more detail?
2014-03-25 22:11:25 < Daemon404> these tell me nothing
2014-03-25 22:11:36 < Daemon404> merge candidates could be at various parts of encoding
2014-03-25 22:13:09 < Daemon404> a bunch of them are full of acronyms
2014-03-25 22:13:19 < Daemon404> i may know what they mean, im guessing others might now
2014-03-25 22:14:39 < Daemon404> only other note is that is kind of weird to list unimplemented options
2014-03-25 22:17:23 < muggs> they kind of snuck in when I wasn't looking. I haven't been motivated enough to remove them.
2014-03-25 22:53:30 < kierank> j-b: https://github.com/lheric/x265
2014-03-25 22:56:18 < j-b> kierank: what is it?
2014-03-25 22:56:24 < kierank> seems to be an encoder
2014-03-25 22:56:30 < kierank> possibly translated from c++ x265
2014-03-25 22:56:36 < kierank> but shares some code from x264
2014-03-25 23:02:10 < j-b> weird
2014-03-25 23:04:35 < Daemon404> shares code from x265 as well
2014-03-25 23:04:49 < j-b> pure C?
2014-03-25 23:12:49 <@Skyler_> um.  it's apache-licensed??
2014-03-25 23:12:55 <@Skyler_> wouldn't it have to be GPL if they used x264/x265 code.
2014-03-25 23:13:26 < Daemon404> j-b, intrinsics
2014-03-25 23:13:34 < Daemon404> the code quality seems rather bad to me
2014-03-25 23:13:41 < Daemon404> and the commit log is... :)
2014-03-25 23:14:35 < Mandarinka> well, the dude is so epic he wrote it all at once, in one go.
2014-03-25 23:15:14 < Mandarinka> in other words, take care, it might be Chuck Norris under pseudonym
--- Day changed Wed Mar 26 2014
2014-03-26 14:43:07 < smarter> interesting: https://github.com/lheric/GitlHEVCAnalyzer
2014-03-26 14:43:28 < smarter> "It is released under Apache License 2.0. In addition, it's NOT for commercial use. If you want to use it for commercial purpose, please contact us. If you ares not using it to develop weapons, produce or sell illegal drugs, and if you are not a terrorist, we will give your a commercial version for free." :D
2014-03-26 14:45:51 < Daemon404> smarter, so its incompatible with every license
2014-03-26 14:45:52 < Daemon404> more or less
2014-03-26 14:45:53 < Daemon404> lol
2014-03-26 14:46:09 < Daemon404> but still
2014-03-26 14:46:14 < Daemon404> thats fricking awesome
2014-03-26 14:47:26 < smarter> yeah, I was wondering when someone was going to do a usable free analyzer
2014-03-26 14:47:34 < smarter> I think nobody ever did that for h264
2014-03-26 14:47:45 < Daemon404> yeah
2014-03-26 14:47:57 < Daemon404> the only real option was always elecard's streameye
2014-03-26 15:01:21 < smarter> ok, so it uses a hacked up HM to write various infos to .txt files, then parse them back
2014-03-26 15:03:32 < Daemon404> something something china
2014-03-26 15:06:38 < smarter> that's not a terrible way to do things
2014-03-26 15:07:01 < Daemon404> > write various infos to .txt files, then parse them back
2014-03-26 15:07:02 < smarter> someone motivated could hack up libvpx in a similar way to get VP9 analysis :]
2014-03-26 15:07:03 < Daemon404> yeah
2014-03-26 15:07:03 < Daemon404> it is
2014-03-26 15:07:18 < Daemon404> im referring to teh intermediate txt ;)
2014-03-26 15:07:36 < Daemon404> even if you wanted to pasre its output
2014-03-26 15:07:36 < smarter> the alternative would be tight coupling between the decoder and the analyzer which doesn't sound good
2014-03-26 15:07:39 < Daemon404> you dont need a file
2014-03-26 15:08:07 < Daemon404> you can garb its outptu directly in the app
2014-03-26 15:08:13 < Daemon404> a file is just sily
2014-03-26 15:25:54 < koda> wow that’s a cool project
2014-03-26 15:26:10 < koda> also afaik gpl3 is compatible with apache2
2014-03-26 15:26:22 < JEEB> it's apache2 with extra limitations
2014-03-26 15:26:23 < JEEB> :P
2014-03-26 15:26:25 < nevcairiel> not anymore with the extra restriction
2014-03-26 15:26:26 < JEEB> thus not compatible
--- Day changed Thu Mar 27 2014
2014-03-27 19:11:27 < muggs> is my memory correct?  umh stands for uneven multi-hexagon?
2014-03-27 19:12:46 <@Skyler_> yes
2014-03-27 19:17:23 < muggs> thanks
2014-03-27 22:39:30 < JEEB> hmm
2014-03-27 22:39:34 < JEEB> I wonder how bad this paper is http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6575123&sortType%3Ddesc_p_Publication_Year%26queryText%3Dhevc
--- Day changed Fri Mar 28 2014
2014-03-28 13:40:19 < j-b> good morning!
--- Day changed Sat Mar 29 2014
2014-03-29 10:05:03 < LigH> Greetings.
2014-03-29 10:05:06 < LigH> Anyone awake?
2014-03-29 13:31:58 < LigH> Greetings.
2014-03-29 13:52:38 < LigH> Is anyone here able to help building on Ubuntu 12.04 LTS?
2014-03-29 13:54:12 < JEEB> you will have to build a newer yasm and possibly build/grab a newer cmake, should be rather straightforward after that :P
2014-03-29 13:55:54 < LigH> Yes, that's what I am trying.
2014-03-29 13:56:03 < LigH> yasm 1.2.0 - built and installed.
2014-03-29 13:56:12 < LigH> cmake 2.8.12.2 - built and installed.
2014-03-29 13:56:25 < LigH> Except ... how do I make ccmake (cmake-curses-gui)?
2014-03-29 13:57:07 < JEEB> you don't need that
2014-03-29 13:57:12 < LigH> To enable it in cmake's configure, I may have to have installed an ncurses library.
2014-03-29 13:57:15 < LigH> But which?
2014-03-29 13:57:20 < JEEB> just ignore that
2014-03-29 13:57:31 < JEEB> it's just the curses gui for the options, of which there are not exactly many
2014-03-29 13:58:01 < LigH> Well, the x265 build script calls ccmake, which is still v2.8.7 and fails.
2014-03-29 13:58:09 < JEEB> just don't do that
2014-03-29 13:58:12 < JEEB> you don't /need/ it
2014-03-29 13:58:20 < LigH> Hmm.
2014-03-29 13:59:12 < JEEB> "cmake -G "Unix Makefiles" ../../source" where the last part is the path to the 'source' directory
2014-03-29 13:59:16 < JEEB> this is all you need
2014-03-29 13:59:22 < JEEB> after that the makefiles are already done
2014-03-29 13:59:26 < JEEB> and you can just hit 'make'
2014-03-29 13:59:38 < JEEB> if the configuration/creation passes without problems
2014-03-29 13:59:51 < JEEB> everything you can set in that godawful "interface" you can set with options
2014-03-29 14:01:48 < JEEB> like -DHIGH_BIT_DEPTH=1
2014-03-29 14:02:01 < JEEB> cmake -G "Unix Makefiles" -DHIGH_BIT_DEPTH=1
2014-03-29 14:02:09 < JEEB> and then the source dir's path
2014-03-29 14:02:19 < JEEB> that would enable high bit depth, for example
2014-03-29 14:03:07 < JEEB> this is how you set up cross-compilation for example https://bitbucket.org/multicoreware/x265/wiki/CrossCompile
2014-03-29 14:03:08 < JEEB> :P
2014-03-29 14:10:34 < LigH> It was mostly an excercise in using linux at all.
2014-03-29 14:10:59 < LigH> The problem was a cached state that libncurses5 was not installed earlier.
2014-03-29 14:12:20 < JEEB> still doesn't change the fact that the ncurses faggotry is quite unneeded
2014-03-29 14:12:30 < JEEB> and you can ignore it unless you really really want it
2014-03-29 14:12:34 < LigH> Qt is prettier ... ;)
2014-03-29 14:12:42 < JEEB> and if you want it, this is no longer the right channel to poke about it
2014-03-29 14:12:49 < JEEB> go waste someone else's time :P
2014-03-29 14:13:33 < LigH> I am not so used to the habit that a Linux user must learn all the commands by heart to type them blind, like an anatomy student. :P
2014-03-29 14:13:48 < JEEB> you don't need to "learn them by heart"
2014-03-29 14:14:09 < JEEB> heck, you don't need to fucking type in a single setting in there if you just want x265 built
2014-03-29 14:14:28 < JEEB> also blame cmake for not having a --help thing (at least I think it doesn't have one to let you look through the defines around)
2014-03-29 14:14:28 < LigH> o?
2014-03-29 14:14:54 < JEEB> the documentation might have a listing of the defines, but that's the same as doing "./configure --help" with most projects
2014-03-29 14:15:48 < JEEB> *nix is not about learning all the commands by heart, esp. when compiling things
2014-03-29 14:16:10 < LigH> BTW, I uploaded some low bitrate results to my MediaFire account. Not sure if you read that the last time.
2014-03-29 14:16:13 < JEEB> reading --help and possible INSTALL files as well as other documentation if that has
2014-03-29 14:16:43 < JEEB> I don't give a flying fuck really
2014-03-29 14:18:39 < LigH> You make me feel like being blamed for something I am not responsible for...
2014-03-29 21:42:44 < JEEB> muggs, I admire your generocity towards the unfortunately vocal group of users
2014-03-29 21:52:13 < muggs> I donated a saturday afternoon to the cause
2014-03-29 21:52:41 < muggs> I doubt they feel very grateful
2014-03-29 21:53:17 < JEEB> oh they don't :P after all it's "something that should be" in their opinion
2014-03-29 21:53:31 < JEEB> just like those people who still a year or two ago wanted latest ffmpeg on win2000
2014-03-29 21:54:58 < muggs> in 10 days, Microsoft themselves are giving up on XP
2014-03-29 21:55:37 < JEEB> yup
--- Day changed Sun Mar 30 2014
2014-03-30 02:22:37 < Nosomy> e
2014-03-30 13:45:55  * Daemon404 adds repeat header support to ffmpeg for Rodeo and pals
2014-03-30 13:46:12 < Rodeo> why for me?
2014-03-30 13:47:34 < Daemon404> why not? are you rejecting me? ;-;
2014-03-30 13:47:58 < Daemon404> (also cause i remembered talking about it with you and nev)
2014-03-30 13:49:21 < Rodeo> that's a confusing nickname, as it's also my brother's
2014-03-30 13:49:31 < Rodeo> let's call him Hendrik instead?
2014-03-30 13:49:41 < Rodeo> and no, i'm not rejecting you
2014-03-30 13:49:44 < Daemon404> ;p
2014-03-30 13:50:05 < Daemon404> i dislike real names on irill keep calling him nevcairiel
2014-03-30 13:50:19 < Daemon404> Achievement Unlocked: Merge two sentences by accident.
2014-03-30 14:13:30 < koda> Daemon404: ffmpeg&libav ^^
2014-03-30 14:17:45 < Daemon404> &&
2014-03-30 14:42:40 < nevcairiel> Rodeo: your brothers nickname is nevcairiel or nev? :p
2014-03-30 14:42:47 < Rodeo> nev
2014-03-30 14:43:17 < nevcairiel> just wondering, since nevcairiel is rather unique
2014-03-30 14:44:20 < nevcairiel> Daemon404: some other guy sent a patch to use the new flag to the ML before, btw
2014-03-30 14:44:36 < nevcairiel> dont think it was commited though
2014-03-30 14:47:18 < Daemon404> ah
2014-03-30 14:47:21 < Daemon404> let
2014-03-30 14:47:23 < Daemon404> lets see
2014-03-30 14:48:17 < Daemon404> nevcairiel, i dont see it
2014-03-30 14:48:21 < nevcairiel> [PATCH] Added rap flag to libx265 to insert VPS/SPS/PPS before each key frame.
2014-03-30 14:48:24 < nevcairiel> for ffmpeg
2014-03-30 14:48:53 < Daemon404> thats not it
2014-03-30 14:48:59 < Daemon404> thats the guy who did it manually
2014-03-30 14:49:07 < nevcairiel> look at the end of the thread
2014-03-30 14:49:32 < nevcairiel> he was told to not do it manually and request the flag
2014-03-30 14:49:39 < nevcairiel> so once it showed up, he posted a patch to use it
2014-03-30 14:50:52 < Daemon404> nevcairiel, it is stil incorrect
2014-03-30 14:51:17 < nevcairiel> I never said it was correct, just that it existed
2014-03-30 14:51:28 < Daemon404> olol
2014-03-30 14:52:12 < Daemon404> also
2014-03-30 14:52:14 < Daemon404> i dont get it
2014-03-30 14:52:21 < nevcairiel> I didn't check it in deep detail, but it looked ok'ish on first glance
2014-03-30 14:52:25 < Daemon404> how do people have inconsistent spacing within a 4 line change
2014-03-30 14:52:29 < Daemon404> four spaces, then randomly two
2014-03-30 14:53:22 < Daemon404> and a random newline
2014-03-30 14:53:25 < Daemon404> do they use notepad?
2014-03-30 14:54:20 < Daemon404> nevcairiel, the patch also does retarded stuff
2014-03-30 14:54:28 < Daemon404> like always allocating the header/extradata
2014-03-30 14:54:34 < Daemon404> and freeing it after doing nothing with it
2014-03-30 14:55:44 < nevcairiel> it sounds more like its not removing that
2014-03-30 14:55:48 < nevcairiel> i dont see it adding new allocs
2014-03-30 14:56:20 < Daemon404> yea
2014-03-30 14:56:25 < Daemon404> but thats incorrect in my books
2014-03-30 14:56:42 < nevcairiel> its one alloc during open, isnt it
2014-03-30 14:56:48 < nevcairiel> if it simplifies the code..
2014-03-30 14:56:55 < nevcairiel> but your call
2014-03-30 14:57:28 < Daemon404> im going to fix and resend with a 2nd patch to do something else
2014-03-30 14:57:39 < Daemon404> better than a diego review
2014-03-30 14:58:52 < Daemon404> im also going to bump the build req to 13
2014-03-30 14:58:59 < Daemon404> because it has a crucial bugfix
2014-03-30 14:59:00 < Daemon404> for the api
2014-03-30 14:59:04 < nevcairiel> it was 11 at the time he sent it :D
2014-03-30 14:59:08 < Daemon404> :P
2014-03-30 14:59:55 < Daemon404> anyway, i really dont understand how people manage such inconsistent spacing
2014-03-30 15:00:01 < Daemon404> literally ever editor will do it for you
2014-03-30 15:00:03 < Daemon404> every*
2014-03-30 15:00:06 < Daemon404> more or less
2014-03-30 15:00:14 < nevcairiel> if the editor knows the spacing for such a file
2014-03-30 15:00:28 < Daemon404> even if it didnt
2014-03-30 15:00:32 < Daemon404> it would be consistently incorrect
2014-03-30 15:00:34 < Daemon404> not randomly changing
2014-03-30 15:11:44 < Daemon404> nevcairiel, looks like he was also addign header_size to payload size
2014-03-30 15:28:18 < Daemon404> ... im on drugs
2014-03-30 15:28:24  * Daemon404 tried to send to libav-devel@ffmpeg.org
2014-03-30 15:42:23 < Mandarinka> provoker
2014-03-30 16:08:24 < koda> :D
2014-03-30 16:08:42 < koda> there is a libav@ffmpeg.org for some reason
2014-03-30 23:54:17 < Zeranoe> I think the recent patches to threading.h are causing compile errors: source/common/threading.h:201:42: error: 'InitializeConditionVariable' was not declared in this scope
2014-03-30 23:58:44 < Zeranoe> looks like -DWINXP_SUPPORT=1 fixes it, but without that options it fails
--- Day changed Mon Mar 31 2014
--- Day changed Tue Apr 01 2014
--- Day changed Wed Apr 02 2014
2014-04-02 13:47:47 < j-b> 'morning
2014-04-02 13:58:38 < Daemon404> are you in land of the free?
2014-04-02 13:59:42 < j-b> yes
2014-04-02 13:59:51 < Daemon404> for //BUILD right?
2014-04-02 13:59:58 < j-b> Yep
2014-04-02 14:00:09 < Daemon404> whats on your agenda this time? trollinf for C11?
2014-04-02 14:00:50 < j-b> ye
2014-04-02 14:01:03 < Daemon404> lol
2014-04-02 14:01:28 < j-b> More c99 compatibility, More featuring and support for Open Source apps, Xbox1, legality on Windows Store, and Windows Phone 8.1
2014-04-02 14:01:33 < Daemon404> my friend at MS is still asking me every week when he can run vlc on his surface
2014-04-02 14:01:45 < j-b> Daemon404: that's ^^ the non-trolling  reqsons
2014-04-02 14:02:22 < Daemon404> reminds me to send more patches to jxrlib
2014-04-02 14:03:02 < Daemon404> have fun w/ that.
2014-04-02 14:04:14 < j-b> fun? I doubt
2014-04-02 14:09:56 < koda> good luck with that j-b
--- Day changed Thu Apr 03 2014
2014-04-03 22:47:50 < Daemon404> x265 has official made it
2014-04-03 22:47:55 < Daemon404> people are encoding porn with it
2014-04-03 22:48:01 < Daemon404> officially*
2014-04-03 22:48:25 < Daemon404> only a matter of time until j-b gets bugs filed against said streams
2014-04-03 22:49:52 < Mandarinka> you mean pirates, or actual porn businesses?
--- Day changed Fri Apr 04 2014
2014-04-04 00:21:45 < Rodeo> pirates doing porn… eww
2014-04-04 00:45:53 < Daemon404> Mandarinka, obvusly pirates
2014-04-04 00:57:26 < koda> ninja pirates?
2014-04-04 02:06:53 < muggs> I'm still waiting for the anime junkies to jump on the bandwagon
2014-04-04 02:07:39 < Mandarinka> well, there are several here already
2014-04-04 02:07:46 < Mandarinka> including me
2014-04-04 02:09:15 < Mandarinka> personally I use x264 veryslow to placebo settings, which are hard to beat, and I encode 1980s and 1990s stuff that has grain/texture that I want to preserve
2014-04-04 02:09:38 < Mandarinka> I think I will need to wait at least for psyrdo, then we'll see :)
2014-04-04 02:13:38 <@Skyler_> I think they'll probably wait for 10-bit decoding to be rolled out at least?
2014-04-04 02:13:47 <@Skyler_> since the people who would care about H.265 are probably already on H.264 10-bit
2014-04-04 02:14:36 < koda> apparently broadcasters are too
2014-04-04 02:16:10 < Mandarinka> I'd say that fansubbers gnerally wait for tangible compression gains, but they also often care about speed, so the higher quality presets need to get faster for them to jump on
2014-04-04 02:17:56 < Mandarinka> well, the problem is that x264 has got pretty good :)
2014-04-04 02:18:22 < Mandarinka> if these were the xvid times, we would probably be already migrating (to x264...)
2014-04-04 02:23:00 < muggs> it seems most of the HEVC early adopters are using 10bit
2014-04-04 02:25:42 < Mandarinka> hmm, tbh I wasn't giving 10-bit hevc a thought yet.
2014-04-04 02:25:55 < Mandarinka> I guess I should fix that.
2014-04-04 02:41:06 < muggs> it looks like post-NAB I will be heading to India to meet the dev team and try to improve our rate control
2014-04-04 03:36:52 < Mandarinka> hmm, hi bitdepth builds from chromashift crash few frames into encoding :/
2014-04-04 11:13:57 < Daemon404> [03:12] < Mandarinka> I'd say that fansubbers gnerally wait for tangible compression gains, but they also often care about speed, so the higher quality presets need to get faster for them to jump on
2014-04-04 11:14:02 < Daemon404> i dont think so
2014-04-04 11:14:12  * Daemon404 remembers encoding with x264 at 0.01fps on his athlon xp
2014-04-04 11:14:51 < JEEB> yeah
2014-04-04 11:14:55 < Daemon404> main reason anime folks havent changed is PQ
2014-04-04 11:15:07 < Daemon404> i say this as one of them folk.
2014-04-04 11:15:13 < JEEB> if it gives definite results every time, then it gets used
2014-04-04 11:15:20 < JEEB> and I haven't seen that yet, unfortunately
2014-04-04 11:15:36 < Daemon404> ah damn muggs left
2014-04-04 11:15:42 < Daemon404> he needs a bouncer or something
2014-04-04 11:15:47 < Daemon404> some sort of persistent irc conn
2014-04-04 15:29:02 < Rodeo> was x265 0.9 released yet?
2014-04-04 15:29:56 < nevcairiel> it was tagged yesterday
2014-04-04 15:30:29 < Rodeo> OK
2014-04-04 20:22:13 < GEEGEEGEE> https://www.youtube.com/watch?v=9-ltOVyNYO8
--- Day changed Sat Apr 05 2014
--- Day changed Sun Apr 06 2014
2014-04-06 19:08:40 < Daemon404> hmm
2014-04-06 19:08:51 < Daemon404> i wonder why there's no fprofile/pgo option for x265
2014-04-06 19:08:54 < Daemon404> could be useful.
2014-04-06 19:09:04 < Daemon404> (no ide if lto/ltcg is at all useful tho)
--- Day changed Mon Apr 07 2014
--- Log closed Mon Apr 07 20:09:34 2014
--- Log opened Mon Apr 07 22:38:26 2014
2014-04-07 23:10:17 < kierank> j-b: what's wrong with https://github.com/videolan/x265
2014-04-07 23:10:20 < kierank> hasn't updated for ages
2014-04-07 23:16:05 < j-b> no idea
2014-04-07 23:16:12 < j-b> I did not do that
--- Day changed Tue Apr 08 2014
--- Log closed Tue Apr 08 10:43:42 2014
--- Log opened Tue Apr 08 11:36:25 2014
--- Day changed Wed Apr 09 2014
2014-04-09 18:52:34 < LigH> \o
2014-04-09 18:53:27 < LigH> Which reasons (and solutions) could there be if a MinGW build does not update a version number in the x265.rc? So reported in the doom9 forum.
2014-04-09 18:53:44 < LigH> I hope it is a valid suggestion to try a fresh clone.
--- Day changed Thu Apr 10 2014
--- Log closed Thu Apr 10 01:25:44 2014
--- Log opened Thu Apr 10 01:47:04 2014
--- Day changed Fri Apr 11 2014
--- Day changed Sat Apr 12 2014
2014-04-12 14:08:50 < boiled_sugar_> これ公式だし薄いかどうか…
2014-04-12 14:08:56 < boiled_sugar_> oops
2014-04-12 14:09:00 < boiled_sugar_> wrong channel
2014-04-12 16:38:13 < Daemon404> 30
--- Day changed Sun Apr 13 2014
--- Day changed Mon Apr 14 2014
2014-04-14 05:06:40 < j-b> 'morning
2014-04-14 18:28:34 < muggs> j-b: we could add a couple lines to "Encoder features" on the x265 dev html page
2014-04-14 18:28:44 < j-b> please do!
2014-04-14 18:28:55 < muggs> "Main and Main10 profiles supported"
2014-04-14 18:29:08 < muggs> "i420, i422, and i444 color spaces supported"
2014-04-14 18:29:39 < muggs> should I email things like this?
2014-04-14 18:30:49 < muggs> it would be good to have a link to http://x265.readthedocs.org/en/default/
2014-04-14 18:31:19 < kurosu> can you say you support i422 and i444 when the corresponding profiles aren't "finalized" yet ?
2014-04-14 18:32:42 < muggs> good question; we can leave those off for now.
2014-04-14 18:33:22 < kurosu> things have changed at the last meeting, so I expect this would not be true and your streams wouldn't be actually conformant
2014-04-14 18:33:26 < muggs> the line that mentions weightP should mention we do weighted prediction for P and B slices
2014-04-14 18:34:10 < muggs> which parts changed?
2014-04-14 18:35:32 < kurosu> I just know things changed - but you should check it yourself and that was my point with the profiles not finalized
2014-04-14 18:36:44 < JEEB> IIRC they were supposed to be throwing the amendment towards a ballot soon'ish
2014-04-14 18:39:04 < kurosu> there are meeting notes that should clarify what was added or removed
2014-04-14 18:39:17 < kurosu> but I don't know what x265 implements, so ...
2014-04-14 18:53:55 < JEEB> oh, it seems like 14496-15 3rd ed finally got through FDIS ballot
2014-04-14 18:53:57 < JEEB> http://lucia.itscj.ipsj.or.jp/standard/servlets/DocumentSearch?ID=112&sn=1449601503000000&stp=1&sg=26&st=1&m=1
2014-04-14 18:54:13 < JEEB> now one can finally officially put HEVC into "mp4" \o/
2014-04-14 19:00:03 < Paranoialmaniac> don't forget HEVC-in-TS http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62129
--- Day changed Tue Apr 15 2014
2014-04-15 02:18:28 < koda> wow the hm is unusable from the command line
2014-04-15 11:36:11 < nandaku2> @Skyler_/other x264 devs
2014-04-15 11:36:50 < nandaku2> we have been reviewing our cutree implementation
2014-04-15 11:37:12 < nandaku2> and since most of it is imported straight from mbtree in x264, there were a couple of questions
2014-04-15 11:37:19 < nandaku2> about mbtree
2014-04-15 11:37:56 < nandaku2> Should mbtree/cutree affect slice QP? If so, why?
2014-04-15 11:38:50 < nandaku2> Our original understanding was that mbtree's effect would be through the offsets only.
2014-04-15 11:41:50 < nandaku2> when mbtree is enabled, getQscale removes blurredcomplexity from the initial qscale equation
--- Day changed Wed Apr 16 2014
--- Day changed Thu Apr 17 2014
2014-04-17 18:11:18 < muggs> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6317159
2014-04-17 18:19:25 < JEEB> wonder if this will be the last draft for rexts http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=9096
2014-04-17 18:25:12 < muggs> would be nice, I think it's a small change for the encoder and decoder, with good lossless results
--- Day changed Fri Apr 18 2014
--- Day changed Sat Apr 19 2014
--- Day changed Sun Apr 20 2014
--- Day changed Mon Apr 21 2014
2014-04-21 14:51:27 < j-b> 'morning
2014-04-21 18:51:53 < Daemon404> i really wonder about that chinese guy on the ML...
2014-04-21 18:52:17 < Daemon404> "i found a guy on the internet who gave me an environment to build it"
2014-04-21 18:52:45 < JEEB> 宮村 公男 is actually Japanese as far as I can see :D
2014-04-21 18:52:53 < JEEB> or at least seems to reside there
2014-04-21 18:54:45 < Daemon404> ah
2014-04-21 18:54:58 < JEEB> but it's still kind of durr
2014-04-21 18:55:11 < Daemon404> yes
2014-04-21 18:55:30 < Daemon404> roughly 99% of all the questions i getsee abou that wrapper
2014-04-21 18:55:42 < Daemon404> are a missing c++stdlib
--- Day changed Tue Apr 22 2014
2014-04-22 16:11:32  * Daemon404 just facedesks
--- Day changed Wed Apr 23 2014
2014-04-23 20:52:21 < muggs> We've ported the checkasm stack checks to our asm test bench, and I'm curious about the effects it has on x86_64 builds
2014-04-23 20:53:04 <@Skyler_> ?
2014-04-23 20:53:06 < muggs> when we call our asm functions now we have to manually typecast arguments to the correct size (intptr_t) in the macro call
2014-04-23 20:53:11 <@Skyler_> correct
2014-04-23 20:53:23 <@Skyler_> that's an unfortunate side effect, yeah
2014-04-23 20:53:32 <@Skyler_> but it also forces you to be explicit about things and makes it harder to forget about sizes
2014-04-23 20:53:49 < muggs> ok, I wasn't sure we were covering up potential bugs by doing this
2014-04-23 20:54:10 < muggs> but I guess this is just a side-effect of the way varargs are used to pass arguments
2014-04-23 20:55:04 <@Skyler_> yeah, unfortunately
2014-04-23 20:55:22 <@Skyler_> it only affects checkasm, though, so at least it won't make any real code uglier
2014-04-23 20:55:44 < muggs> right, ok
2014-04-23 20:57:22 < muggs> I'm guessing it would be cleaner to just declare int arguments as properly sized variables, and pass those
2014-04-23 20:58:46 <@Skyler_> I don't know, we just cast in x264
2014-04-23 21:14:30 < muggs> getting the return value from the wrapper is proving to be troublesome in C++
2014-04-23 21:32:46 <@Skyler_> I don't know too much about how the whole thing works, it's a pengvado hack
2014-04-23 21:40:51 < BugMaster> muggs: when we call our asm functions now we have to manually typecast arguments to the correct size (intptr_t) in the macro call <- why? I don't see such constraint in checkasm. if you need it may be you have problems with incorrect assumptions that 32-bit ints are zero-extended in asm
2014-04-23 21:42:20 <@Skyler_> BugMaster: the issue comes up in checkasm in x264
2014-04-23 21:42:27 < muggs> the arguments are being passed to the function via a vararg macro; so the sizes are defined by the macro
2014-04-23 21:42:29 <@Skyler_> if you pass "3" to a function, and the function's argument is inttr_t
2014-04-23 21:42:36 <@Skyler_> it won't get zero-extended even though it should in normal C code
2014-04-23 21:43:44 < BugMaster> oh you mean constants. like (intptr_t)64
2014-04-23 21:45:07 <@Skyler_> yeah
2014-04-23 21:45:11 <@Skyler_> 'I think muggs means that
2014-04-23 21:45:28 < muggs> yes
2014-04-23 21:48:04 < muggs> it seems to be working; I need to test it out against some old known-buggy functions
2014-04-23 22:13:40 < muggs> ssim_end4_t causes crashes when checked, but I'm not sure if it's because we're passing in multi-dimensional arrays
2014-04-23 22:13:51 < muggs> I think we borrowed that function directly from x264
2014-04-23 22:16:50 < BugMaster> look why it crashed. if it unaligned sse than check that sum array you input is aligned
2014-04-23 22:17:24 < muggs> it doesn't appear to be checked in checkasm, just outputs verified and then profiled
2014-04-23 22:18:45 < BugMaster> ? I am not sure I understand what you said
2014-04-23 22:19:38 < muggs> it doesn't appear to be run through x265_checkasm_call
2014-04-23 22:20:11 < muggs> or x264_checkasm_call :)
2014-04-23 22:20:45 < BugMaster> in x264 checkasm: call_a2( pixel_asm.ssim_end4, sums, sums, 4 );
2014-04-23 22:21:41 < BugMaster> dunno what you do in x265
2014-04-23 22:25:01 < muggs> ah, I misread the checkasm macros, pixel_asm.ssim_end4 is stack checked
2014-04-23 22:26:27 < muggs> our arguments are definitely aligned; we'll have to dig into why this one fails
--- Day changed Thu Apr 24 2014
2014-04-24 15:48:01 < Daemon404> what kind of platform doesnt have pow()?
2014-04-24 15:48:19 <@Skyler_> I was wondering that too, it's a standard C function
2014-04-24 15:48:38 <@Skyler_> trying to avoid using pow "for compatibility" sounds like some of openssl's "compatibility" hacks, like support for big-endian x86
2014-04-24 15:48:46 < Daemon404> indeed
--- Day changed Fri Apr 25 2014
2014-04-25 07:32:36 < j-b> good mornin
--- Day changed Sat Apr 26 2014
--- Day changed Sun Apr 27 2014
--- Day changed Mon Apr 28 2014
2014-04-28 04:49:07 < sandeshyapuram> hello world
2014-04-28 04:51:19 < sandeshyapuram> can anyone tell me how I can start contrubuting?
2014-04-28 04:51:36 < sandeshyapuram> I have built the latest version on my Ubuntu 13.10
2014-04-28 08:08:04 < j-b> good morning
--- Day changed Tue Apr 29 2014
2014-04-29 02:37:03 < muggs> http://www.f265.org/
2014-04-29 02:38:36 < muggs> Vantrix has released their HEVC encoder as BSD source
2014-04-29 07:26:24 < smarter> that is pretty cool: http://www.f265.org/f265/static/txt/h265_companion.html
2014-04-29 09:03:38 < j-b> Morning
2014-04-29 12:31:41 < Daemon404> smarter, indeed
2014-04-29 12:34:15 < j-b> wow
2014-04-29 12:34:19 < j-b> that's a long one
2014-04-29 12:45:49 < Daemon404> its a good primer
2014-04-29 12:45:53 < Daemon404> + more
2014-04-29 18:00:44 < muggs> http://www.f265.org/f265/static/txt/h265_companion.html
2014-04-29 18:00:52 < muggs> I got a good laugh at their rant
2014-04-29 20:40:44 < kierank> muggs: it's a bit unfair but mpeg documents are annoying in that they make you jump around
2014-04-29 20:40:59 < Daemon404> kierank, so get 3 more monitors
2014-04-29 20:41:02 < Daemon404> problem solved
2014-04-29 20:41:02  * Daemon404 runs
2014-04-29 20:41:10 < kierank> I have 3 monitors
2014-04-29 20:41:19 < kierank> one is a tv screen though so the colourimetry is wrong
2014-04-29 20:41:38 < nevcairiel> i have 3 actual PC monitors, that doesnt help reading the spec
2014-04-29 20:41:56 < Daemon404> clickable references would help
2014-04-29 20:42:02 < Daemon404> and a history of where you were
2014-04-29 20:47:27 < kierank> I've added my own small index to the ts spec
2014-04-29 20:48:20 < Daemon404> thats not very german of oyu
2014-04-29 20:48:43 < kierank> lol
2014-04-29 20:49:49 < muggs> I usually prepare for digging though the spec by having a couple of irish coffees and then banging my head against the wall.  Gets me in the right frame of mind.
2014-04-29 20:51:20 < Daemon404> and if its vp8/9 you sacrifice 6 goats and hope you can summon a spec to actually exist
2014-04-29 20:51:28 < kierank> the mpeg2 spec is quite readable
2014-04-29 20:51:36 < kierank> h264 less so and hevc totally nuts
2014-04-29 20:52:02  * Daemon404 ikes the older specs like jpeg which use ibm flow charts instead of code
--- Day changed Wed Apr 30 2014
2014-04-30 20:39:17 < muggs> Daemon404: profile guided optimizations are on my TODO list (I'm reading back through the recent chat history)
2014-04-30 20:42:29 < Daemon404> lol i said that like 10 days ago
2014-04-30 20:44:00 < muggs> yeah, it might be on the TODO list for a while
2014-04-30 20:45:21 < muggs> LigH was asking about x265.rc being updated; the answer there is you don't need to reclone you just need to 'touch source/CMakeLists.txt' and force cmake to rerun
2014-04-30 20:46:15 < nevcairiel> wonder if you can tell cmake to always rebuild certain things, like the version info
2014-04-30 20:48:18 < muggs> most of those things only need to be built once
--- Day changed Thu May 01 2014
2014-05-01 06:28:25 < Easyfab> https://www.youtube.com/watch?v=A3_w5qWwYc8
2014-05-01 06:45:30 < BugMaster> looks like old video from APU13
2014-05-01 06:55:26 < Easyfab> yes right APU13
--- Day changed Fri May 02 2014
2014-05-02 20:17:37 < muggs> 1.0 has been tagged
--- Day changed Sat May 03 2014
--- Day changed Sun May 04 2014
--- Day changed Mon May 05 2014
2014-05-05 18:36:03 < muggs> JEEB: are you responsible for the "extended" y4m format in ffmpeg / x264?
2014-05-05 18:36:23 < JEEB> I'm only responsible for the x264 support for it
2014-05-05 18:36:50 < Daemon404> git blam
2014-05-05 18:36:52 < Daemon404> e
2014-05-05 18:41:24 < muggs> I'm having some fun debugging support for this in x265; I noticed VLC shows the same weirdness that I get from x265
2014-05-05 18:41:42 < muggs> but I don't know if VLC understands the extended Y4M header
2014-05-05 19:08:22 < muggs> Anyone know what this is about?  https://bitbucket.org/multicoreware/x265/issue/51/no-working-exe-and-lib-under-msys2
2014-05-05 19:08:54 < Daemon404> nope.
2014-05-05 19:21:13 < Easyfab> muggs: I think he try to make a windows batchscript -> https://github.com/jb-alvarado/media-autobuild_suite
2014-05-05 19:21:44 < Easyfab> and about x265 -> https://github.com/jb-alvarado/media-autobuild_suite/commit/a234f974a46668c58dda8eea1395310403f98acf
2014-05-05 19:31:06 < muggs> is the support for >8 bit Y4M something that ffmpeg invented?
2014-05-05 19:31:21 < JEEB> yeah
2014-05-05 19:31:36 < muggs> just for passing high bit video to x264?
2014-05-05 19:37:12 < JEEB> seemingly in general
2014-05-05 19:37:55 < JEEB> I would guess it was simpler for other applications to implement than implementing a NUT parser for raw video/audio
2014-05-05 19:38:19 < muggs> explicit is usually better
2014-05-05 21:11:15 < muggs> hah; it seems VLC can't parse these extended Y4M files correctly and Gitl_HEVC_Analyzer can't display Main10 outputs correctly and they fail in similar ways
2014-05-05 21:11:49 < JEEB> :D
2014-05-05 21:16:35 < muggs> I've pushed the extended Y4M patch
--- Day changed Tue May 06 2014
--- Day changed Wed May 07 2014
2014-05-07 18:09:51 < muggs> http://www.commitstrip.com/en/2014/05/07/the-truth-behind-open-source-apps/
2014-05-07 18:10:21 < muggs> Anyone around to talk about two-pass encoding?
2014-05-07 18:13:23 < muggs> in particular; what data should we be preserving, and what short-cuts are ok to take in the first pass?
2014-05-07 18:31:01 < Daemon404> muggs, check what --slow-firstpass enables in x264
2014-05-07 18:31:04 <@Skyler_> you'll need to save the mbtree data like x264 does unless you wanna do it again
2014-05-07 18:31:12 <@Skyler_> very fast analysis options are likely fine
2014-05-07 18:31:27 <@Skyler_> x264 uses SATD not SAD in first pass, except with very fast settings
2014-05-07 18:32:24 < Daemon404> bframe decisions are re-used too
2014-05-07 18:32:26 < Daemon404> arent they
2014-05-07 18:32:36 < Daemon404> wait.. that was stupidly obvious.
2014-05-07 18:32:41 < JEEB> frame type decisions are re-used yes
2014-05-07 18:32:43  * Daemon404 vanishes
2014-05-07 18:33:35 < muggs> so the primary outputs of the first pass are "real" bit costs at some resolution (row?) and mbtree offsets?
2014-05-07 18:33:43 < muggs> and slicetype decisions
2014-05-07 18:34:29 <@Skyler_> the real bit costs are at frame resolution
2014-05-07 18:34:33 <@Skyler_> row costs are recalculated in the second pass
2014-05-07 18:34:39 <@Skyler_> however, you could choose to do it differently and save the bit costs per row
2014-05-07 18:34:54 <@Skyler_> if you're doing it from scratch, that might be better; it'd make second pass VBV more accurate, I'd imagine
2014-05-07 18:35:09 <@Skyler_> it'd also mean you wouldn't have to rcalculate row costs in the second pass.
2014-05-07 18:35:15 < muggs> how are they recalculated in the second pass?
2014-05-07 18:35:25 <@Skyler_> by running the lookahead (albeit without making any decisions)
2014-05-07 18:35:41 < muggs> so using satd cost ratios?
2014-05-07 18:35:52 <@Skyler_> yes
2014-05-07 18:35:57 < muggs> interesting, ok
2014-05-07 18:37:28 < muggs> does the second pass RC need the entire stream state all at once? or could we run the two passes together some number of pictures apart?
2014-05-07 18:38:20 <@Skyler_> it needs the entire stream state
2014-05-07 18:38:26 <@Skyler_> that's the entire point of 2-pass
2014-05-07 18:38:43 <@Skyler_> 2-pass ABR is mathematically impossible without the first pass stats, i.e. so you can perform bit allocation across the entire video
2014-05-07 18:39:05 < muggs> ok
2014-05-07 18:39:43 <@Skyler_> using an entire separate encoder as a lookahead is indeed a thing
2014-05-07 18:39:50 <@Skyler_> and some encoders do it (e.g. ateme)
2014-05-07 18:39:56 <@Skyler_> but that just can be used to improve VBV, etc
2014-05-07 18:39:59 <@Skyler_> it's not a solution to the ABR problem.
2014-05-07 18:40:33 < muggs> should the first pass use the same RC config as the second pass?
2014-05-07 18:40:58 <@Skyler_> it doesn't technically have to.
2014-05-07 18:41:06 <@Skyler_> for example, you can do a CRF first pass, then an ABR second pass
2014-05-07 18:41:11 <@Skyler_> example usage: capped-size CRF
2014-05-07 18:41:18  * Daemon404 does this at work
2014-05-07 18:41:22 <@Skyler_> "I want a constant quality video, but no larger than X size, so drop the quality on the second pass if it's too big"
2014-05-07 18:41:34 < muggs> cool
2014-05-07 18:41:59 <@Skyler_> being able to mix ratecontrol modes beteen passes and such adds flexibility like that
2014-05-07 18:42:04 <@Skyler_> or a single first pass for multiple second pass bitrates
2014-05-07 18:42:20 <@Skyler_> it's not ideal, and can give slightly lower quality, but often it isn't a big deal.
2014-05-07 18:42:22 < muggs> right
2014-05-07 18:43:03 < muggs> x264 stores some config data in the log file, correct? to identify mismatched runs?
2014-05-07 18:43:31 < muggs> I guess you have to make sure the lookahead config is the same, at least
2014-05-07 18:45:28 <@Skyler_> yeah, it stores the whole config at the top, I think
2014-05-07 18:45:31 <@Skyler_> and compares various things
2014-05-07 18:45:40 <@Skyler_> so that it does the right thing, or at least fails
2014-05-07 18:46:05 < muggs> ok
2014-05-07 18:46:48 <@Skyler_> x264 supports changing resolutions too but I would suggest not prioritizing such a feature ;-)
2014-05-07 18:47:00 <@Skyler_> I don't think it's too useful and it breaks nice things like row bits in the pass file like I suggetsed
2014-05-07 18:48:19 < muggs> yes, I can see that. No-one is asking for it yet, thankfully
2014-05-07 18:49:06 < muggs> in qpfile, I see available frame types as: I,i,P,B,b.   What is the difference between I and i?
2014-05-07 18:49:36 < JEEB> just intra versus IDR IIRC
2014-05-07 18:49:39 <@Skyler_> keyframe vs intra
2014-05-07 18:49:42 <@Skyler_> I think
2014-05-07 18:50:05 < JEEB> I think there's also K which was IDR with closed gop and otherwise a random access point?
2014-05-07 18:50:06 <@Skyler_> note x264's format only supports single-level b-pyramid since it only has twotypes of b
2014-05-07 18:50:10 <@Skyler_> ah
2014-05-07 18:51:36 < muggs> the difference between keyframe and intra is the breaking of references?
2014-05-07 18:51:59 <@Skyler_> yeah
2014-05-07 18:52:14 < muggs> ok; thanks. that's always been fuzzy to me
2014-05-07 18:53:16 < muggs> I'm going to be visiting India next week to meet with the dev team to talk about 2-pass and other rate control bits
2014-05-07 18:53:44 < Daemon404> whatever happened to psy, muggs?
2014-05-07 18:53:49 < muggs> on the way I plan to write up a bunch more documentation for the API and for various use cases
2014-05-07 18:54:29 < muggs> Daemon404: I'd like to discuss that two; the girl who is looking at it is not grokking it well
2014-05-07 18:54:36 < Daemon404> ok
2014-05-07 18:54:51 < Daemon404> im sitll having issues with detail retention at mid-to-high bitrate
2014-05-07 18:54:52 < muggs> I'd like for you guys to review those docs before I post them
2014-05-07 18:54:53 < Daemon404> or well
2014-05-07 18:54:56 < Daemon404> "detail"
2014-05-07 18:54:59 < Daemon404> since it is psy after all
2014-05-07 18:55:44 < muggs> yeah, this is tops on my list right now; since we've finally fixed the all the known bugs in analysis (that cost wrap problem was a bitch)
2014-05-07 18:56:10 < Daemon404> cool
2014-05-07 18:56:29 < Daemon404> fwiw, x265 is doing better than the proprietary hevc encoder ive tested
2014-05-07 18:56:39 < Daemon404> ... though that really isnt saying much yet
2014-05-07 18:56:55 < muggs> that's the general feedback we've been getting.  we're the best of a weak showing
2014-05-07 18:57:03 < Daemon404> yep
2014-05-07 18:57:12 < Daemon404> theyve also been very hard to work with
2014-05-07 18:57:22 < Daemon404> they actually told me to use a lowr bitrate
2014-05-07 18:57:25 < Daemon404> so they culd beat x264
2014-05-07 18:57:26 < Daemon404> :D
2014-05-07 18:57:30 < muggs> heh
2014-05-07 18:57:49 < Daemon404> they even have "psy-rd"
2014-05-07 18:58:03 < Daemon404> not that it makes any difference
2014-05-07 18:58:21 < Daemon404> i recommended we hedge our bets on 265.
2014-05-07 18:58:22 < Daemon404> x*
2014-05-07 18:58:56 < muggs> so, speaking of which.  Can someone describe it to me in simple terms? this is not a part of the encoder I'm very familiar with.
2014-05-07 18:59:16 < muggs> type slowly to the idiot
2014-05-07 18:59:45 < Daemon404> psy?
2014-05-07 19:00:25 < Daemon404> http://forum.doom9.org/showthread.php?t=138293
2014-05-07 19:00:40 < Daemon404> oh thats not very technical
2014-05-07 19:00:42 < Daemon404> meh
2014-05-07 19:07:30 < BugMaster> psy-rd is modification of rate distortion metric use during RDO. it tries to keep energy of source even if it gives somehow large distortion
2014-05-07 19:08:54 < muggs> yes, we want some of that :)
2014-05-07 19:09:39 < JEEB> also it's interesting how the old FGO is still alive
2014-05-07 19:09:44 < JEEB> as a patch
2014-05-07 19:09:46 < JEEB> with x264
2014-05-07 19:10:08 < BugMaster> i.e. it use as metric not only SSD + bits * lambda but also energy difference where energy calculated as weighted satd + sa8d values
2014-05-07 19:10:38 < JEEB> http://x264dev.multimedia.cx/archives/25 (psy-rd in the end took the place of psy-opts in x264)
2014-05-07 19:10:54 < muggs> energy of residual or recon?
2014-05-07 19:11:06 < BugMaster> eh. FGO was another psy metric which used not energy but noise ssd
2014-05-07 19:11:18 < JEEB> yeah
2014-05-07 19:11:26 < JEEB> I just meant that in the end psy-rd got merged
2014-05-07 19:11:30 < JEEB> and FGO didn't :)
2014-05-07 19:11:48 < BugMaster> muggs: difference between energy of source and reconstruced
2014-05-07 19:11:59 < muggs> film grain, yes. we have lots of people asking for a --tune film
2014-05-07 19:12:01 < BugMaster> absolute difference
2014-05-07 19:12:03 <@Skyler_> fgo is basically psy-rd for the sum of all frequencies instead ofjust hf
2014-05-07 19:13:10 < muggs> ok, so you measure the energy lost between source and reconstructed blocks and just add that to the RD cost?
2014-05-07 19:13:50 <@Skyler_> basically, with a weight
2014-05-07 19:13:52 <@Skyler_> it's a total hack
2014-05-07 19:14:01 <@Skyler_> but it biases towards keeping the same reconstructed energy as the source
2014-05-07 19:16:17 < muggs> and satd + sa8d was chosen because it seemed to work ok?
2014-05-07 19:16:18 < BugMaster> this results in lower objective metrics because we bork math distortion (ssd) but gives better visual quality (at least we hope so)
2014-05-07 19:16:51 < muggs> yes, I can see you would want this disabled if you were measuring metrics
2014-05-07 19:16:52 < BugMaster> average of satd and sa8d was used not to bias to one of the transforms (4x4 vs 8x8)
2014-05-07 19:17:17 < muggs> ah.. we have 16x16 and 32x32 as well
2014-05-07 19:18:31 < BugMaster> you can use only satd but this will create bias to smaller transforms (but still should give visual effect)
2014-05-07 19:18:56 <@Skyler_> and you can come up with other ways of measuring energy; ours is just one
2014-05-07 19:18:58 <@Skyler_> it's not necessarily the best
2014-05-07 19:19:04 <@Skyler_> note I tend to think L1 energy is probably better than L2.
2014-05-07 19:21:48 < BugMaster> the downside of psy-rd is that very low bitrates it can cause not visually pleaseant artefacts when we already have blocking. also at middle bitrates it increase ringing
2014-05-07 19:34:41 < muggs> that was fun; lost internet phone and tv all at once
2014-05-07 19:39:03 <@Skyler_> 05:14 <@Skyler_> and you can come up with other ways of measuring energy; ours is just one
2014-05-07 19:39:07 <@Skyler_> 05:14 <@Skyler_> it's not necessarily the best
2014-05-07 19:39:09 <@Skyler_> 05:14 <@Skyler_> note I tend to think L1 energy is probably better than L2.
2014-05-07 19:39:14 <@Skyler_> 05:17 < BugMaster> the downside of psy-rd is that very low bitrates it can cause not visually pleaseant artefacts when we already have
2014-05-07 19:39:17 <@Skyler_>                    blocking. also at middle bitrates it increase ringing
2014-05-07 19:39:29 < muggs> thanks
2014-05-07 19:40:25 < muggs> how is psy-rd configurable in x264? just a float for the weight?
2014-05-07 19:42:10 < muggs> Skyler_: what is L1 and L2? is that a calculus thing?
2014-05-07 19:43:24 <@Skyler_> L1 == sum of abs(dct coefficients)
2014-05-07 19:43:29 <@Skyler_> L2 = sum of squares
2014-05-07 19:43:38 <@Skyler_> you can have powers in between of course too
2014-05-07 19:43:50 <@Skyler_> retaining L2 energy would be /easier/ in a number of ways
2014-05-07 19:43:55 <@Skyler_> but in mye xperience it wasn't nearly as good
2014-05-07 19:44:03 <@Skyler_> e.g. it weighted single large coefficients over totals
2014-05-07 19:44:10 <@Skyler_> but in theory some other exponent might also be beter
2014-05-07 19:46:38 < muggs> ok
2014-05-07 19:49:52 < muggs> we need to train a neural network to analyze video for psy-rd artifacts, then just go crazy trying different things
2014-05-07 19:50:02 < muggs> sounds like fun
2014-05-07 19:51:02 < muggs> I expect, for HEVC, that we'll want to adjust the weight by block size; for 64x64 we really want to retain energy (big gray blocks really stand out)
2014-05-07 19:54:18 <@Skyler_> I don't think that'll be necessary; it should happen naturally
2014-05-07 19:54:31 <@Skyler_> i.e. because it's a large block, the pain of losing energy will be larger numerically
2014-05-07 19:54:38 <@Skyler_> thus psy rd will hit pretty hard
2014-05-07 19:54:43 <@Skyler_> note, here is an important disclaimer about psy rd
2014-05-07 19:55:01 <@Skyler_> in order to get it to work as well as it does, the weight is set pretty high.  high enough, in fact, that if you take QNS and allow it to optimize freely for psy rd, it will generate blocks that look /awful/
2014-05-07 19:55:12 <@Skyler_> in other words, the weight is "so high that freely optimizing for it produces bad results in many cases"
2014-05-07 19:55:20 <@Skyler_> so it's very much not a perfect metric
2014-05-07 19:55:32 <@Skyler_> IMO the idea is good and very sound in many ways, but the implementation/method of going for the idea is a hack
2014-05-07 20:02:49 < muggs> interesting
2014-05-07 20:04:42 <@Skyler_> also, psy-trellis and psy-rd should be part of the same thing
2014-05-07 20:04:57 <@Skyler_> i.e. it's all one concept of "retain energy well, for a good psy-wise definition of energy"
2014-05-07 20:05:40 <@Skyler_> but this is more research than anything else
2014-05-07 20:07:32 < muggs> right, psy-rd would pick a prediction that has similar energy as the source, and psy-trellis would try to avoid quantizing it all away?
2014-05-07 20:08:47 <@Skyler_> yeah, and also like, an example of that
2014-05-07 20:09:06 <@Skyler_> let's say your predicted coefficient is 2.7
2014-05-07 20:09:13 <@Skyler_> and the source coefficient is 1.9
2014-05-07 20:09:23 <@Skyler_> so your unquantized coefficient is -0.8
2014-05-07 20:09:29 <@Skyler_> quantized, that's either 0 or -1, probably
2014-05-07 20:09:41 <@Skyler_> if we round up to -1, we're spending bits to reduce our energy
2014-05-07 20:10:01 <@Skyler_> so in this case, we'd want to bias towards having 0 instead of -1, because that would increase the reconstructed energy
2014-05-07 20:10:13 <@Skyler_> this is why maintaining reconstructed energy is *NOT* the same as retaining quantized energy
2014-05-07 20:10:37 < muggs> I see
2014-05-07 20:12:13 <@Skyler_> which is why psy-rd runs in the reconstructed domain
2014-05-07 20:12:21 <@Skyler_> effectively, psy-rd biases towards mode decisions that give better energy
2014-05-07 20:12:27 <@Skyler_> in practice,this usually means inter
2014-05-07 20:12:29 <@Skyler_> though not always
2014-05-07 20:12:35 <@Skyler_> it also means it picks qpel positions that give better energy
2014-05-07 20:12:47 <@Skyler_> which means it biases towards hpel instead of qpel (I have statistically confirmed it does this)
2014-05-07 20:12:58 <@Skyler_> obviously the effects may not be the same in h265 which has things like, less dumb subpel filters xD
2014-05-07 20:13:10 < muggs> it's used during qpel refine?
2014-05-07 20:13:30 <@Skyler_> during qpel RD, yes
2014-05-07 20:13:32 <@Skyler_> all RD uses psy-RD
2014-05-07 20:13:42 <@Skyler_> (so, subme >= 8)
2014-05-07 20:14:59 < muggs> yeah, our qpel filters have the same length as hpel, so they should have similar energy I suppose
2014-05-07 20:15:36 <@Skyler_> yeah, that is likely one way in which psy-rd helped before that it will thankfully not help now xD
2014-05-07 20:17:28 < muggs> I'm a bit confused about your example using predicted coefficient and source coefficient.  I must have missed a step.
2014-05-07 20:18:55 < muggs> these energy measurements are using transformed source and prediction blocks?
2014-05-07 20:22:54 <@Skyler_> this is just an example of a single coefficient post-transform
2014-05-07 20:23:19 <@Skyler_> of both source, and reconstructed, and predicted blocks
2014-05-07 20:25:58 < muggs> I'm trying to picture how psy-trellis would work; you want to bias the rounding towards less residual? that doesn't sound right
2014-05-07 20:27:06 <@Skyler_> you want to bias rounding towards higher reconstructed energy
2014-05-07 20:27:43 <@Skyler_> an -example- of this happening, in a more extreme case, is a case where lower /coded residual/ result in /higher reconstructed residual/
2014-05-07 20:28:03 <@Skyler_> e.g. the residual of "-1" is larger than "0" (absolute value wise) but results in a lower (absolute value wise) reconstructed residual
2014-05-07 20:29:31 < muggs> is a larger coeff always more energy? or do we need to do the inverse transform to measure it?
2014-05-07 20:30:07 < muggs> energy(idct + prediction)
2014-05-07 20:31:22 <@Skyler_> you don't need to do the inverse transform technically, but you do if you want tomeasure how we do it (i.e. multiple transform sizes)
2014-05-07 20:31:59 <@Skyler_> I mean, in theory you could add the dequantized coefficients to the transformed prediction
2014-05-07 20:32:03 <@Skyler_> but that's a bit silly too.
2014-05-07 20:36:04 < muggs> ok; I think I follow that much.
2014-05-07 20:37:26 < muggs> back to qpel RD.. can you describe how this is used during analysis? are all inter options analyzed with qpel RD?
2014-05-07 20:38:01 < muggs> right now we don't have any such thing
2014-05-07 20:38:18 <@Skyler_> ot
2014-05-07 20:38:25 <@Skyler_> it's part of a final refinement step on slower settings
2014-05-07 20:38:33 <@Skyler_> in intra mode, it uses RD to pick the best prediction mode
2014-05-07 20:38:47 <@Skyler_> previously, it used SATD to pick the best, then RD to pick the best size (i4x4, i8x8, i16x16)
2014-05-07 20:39:05 <@Skyler_> and in RD refinement, it goes back and looks through the intra pred mode options, doing SATD-thresholded RD to re-pick the best one
2014-05-07 20:39:06 < muggs> that much we have
2014-05-07 20:39:09 <@Skyler_> but sticking with the same size
2014-05-07 20:39:20 <@Skyler_> in inter mode, instead of doing that, it does a hex qpel search with SATD-thresholded RD
2014-05-07 20:40:00 < muggs> so top N satd options get more QPEL steps using RD cost?
2014-05-07 20:41:15 <@Skyler_> it's thresholded in x264 by "no more than X% more than the best SATD score" instead of top N
2014-05-07 20:41:20 <@Skyler_> but that's not the only option
2014-05-07 20:41:28 < muggs> I see
2014-05-07 20:41:32 <@Skyler_> what it does is: it does RD on 6 hex positions and does a normal hex motion search
2014-05-07 20:41:38 <@Skyler_> except that it omits those with SATD scores too bad to bother RDing
2014-05-07 20:41:46 < muggs> simpler than keeping a top N list, for certain
2014-05-07 20:41:58 <@Skyler_> and it doesn't save SATDs from anywhere, it recalculates them for the purposes of this
2014-05-07 20:42:11 <@Skyler_> this helps at least 1% PSNR wise, I think
2014-05-07 20:42:15 < muggs> I see
2014-05-07 20:42:26 <@Skyler_> it's pretty significant
2014-05-07 20:43:21 < muggs> starting from the MV found during the SATD search? or from MVP?
2014-05-07 20:43:27 <@Skyler_> the former
2014-05-07 20:43:35 <@Skyler_> it's refinement, so it assumes the partitions/refs found by SATD and chosen by RD
2014-05-07 20:43:39 <@Skyler_> and the mvs
2014-05-07 20:43:42 <@Skyler_> and refines the mvs
2014-05-07 20:43:48 < muggs> ok
2014-05-07 20:45:01 < muggs> and the RD is plain RD, without RD quant?
2014-05-07 20:46:08 < muggs> (during mv refinement)
2014-05-07 20:49:08 <@Skyler_> if trellis = 1, RD quant is never used except in actual encoding
2014-05-07 20:49:12 <@Skyler_> if trellis = 2, it's used everywhere
2014-05-07 20:49:21 <@Skyler_> you can't really use it in only some places because then your RD scores won't be comparable
2014-05-07 20:49:25 <@Skyler_> since some will be higher from not having it
2014-05-07 20:49:41 < muggs> ok, thanks.
2014-05-07 20:49:57 <@Skyler_> trellis=2, unfortunately, helps a decent bit when you have tons of RD
2014-05-07 20:50:06 <@Skyler_> so making it fast is important
2014-05-07 20:50:21  * muggs shakes his head wondering how much slower --preset veryslow will become
2014-05-07 20:50:35 <@Skyler_> probably not too much
2014-05-07 20:50:40 <@Skyler_> it's a refinement step, so it only runs on the winning modes
2014-05-07 20:51:01 <@Skyler_> and you probably used more RD to select the winning modes (by a large margin) than to do qpel
2014-05-07 20:51:05 < muggs> ah, only *the* winning mode?
2014-05-07 20:51:13 <@Skyler_> yes
2014-05-07 20:51:19 <@Skyler_> you could refine all the modes before selecting the winner
2014-05-07 20:51:25 <@Skyler_> but I imagine that would be incredibly costly for not that much more benefit
2014-05-07 20:51:33 < muggs> ok
2014-05-07 20:52:38 < muggs> our RDOQ is pretty bad, perf wise.  we've been unable to kill it
2014-05-07 20:54:42 < muggs> mainly because I don't think anyone really understands it completely, except perhaps the HM coder who wrote it
2014-05-07 21:01:58 <@Skyler_> yeah, trellis is extremely hard to understand
2014-05-07 21:02:06 <@Skyler_> it was the last part of x264 I understood
2014-05-07 21:02:11 <@Skyler_> it might be better to try to write one from scratch and "do it right"
2014-05-07 21:02:16 <@Skyler_> or at least try to understand the currfent one, then do that
2014-05-07 21:02:31 <@Skyler_> but it's extremely dependent on how cabac coefficient coding works
2014-05-07 21:10:13 < muggs> say, what's pengvado up to these days :)
2014-05-07 21:11:34 <@Skyler_> I have no idea
2014-05-07 21:24:29 < muggs> btw: what is the difference between VBV and HRD?
2014-05-07 21:29:58 <@Skyler_> HRD is how the spec defines VBV, and writes information about it in headers
2014-05-07 21:30:06 <@Skyler_> it's reuqired for certain playback targets, e.g. blu-ray
2014-05-07 21:31:21 < muggs> ok, that was my impression.  it's about explicit signaling of the parameters?
2014-05-07 21:32:38 < Daemon404> [22:05] < muggs> say, what's pengvado up to these days :) <-- lounging around being a millionaire probably
2014-05-07 21:32:41  * Daemon404 runs
2014-05-07 21:33:32 < muggs> well if he gets bored doing that he can come talk to me
2014-05-07 22:14:51 < muggs> anyone have any interest in cqmfile?
2014-05-07 22:15:47 < JEEB> I'd only use one to force IRAPs at certain points
2014-05-07 22:15:53 < JEEB> like chapter points
2014-05-07 22:16:15 < muggs> I just added qpfile, which should be sufficient
2014-05-07 22:16:33 < muggs> cqmfile would be for custom quant matrices
2014-05-07 22:17:43 < JEEB> oh, right
2014-05-07 22:17:47 < JEEB> brainfart
2014-05-07 22:27:26 <@Skyler_> what profiles is it allowed in?
2014-05-07 22:37:14 < muggs> custom matrices? I don't know
2014-05-07 22:39:01 < muggs> I don't remember seeing a mention of them in Annex A, where the profiles are described
2014-05-07 22:39:32 <@Skyler_> in h264 they were high only
2014-05-07 22:40:12 < muggs> oh.  we only have Main and Main10
--- Day changed Thu May 08 2014
2014-05-08 00:08:03 < Zyrill> hi guys
2014-05-08 00:08:54 < Zyrill> I was hoping somebody could point me in the right direction how to cross compile x265 on Ubuntu 64bit for Windows...
2014-05-08 06:06:05 < Easyfab> Zyrill: https://bitbucket.org/multicoreware/x265/wiki/CrossCompile
2014-05-08 07:09:21 < Zyrill> thank you Easyfab
2014-05-08 09:38:58 < Zyrill> did anybody try to build the binary using static linking? I added set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static") to my  cross-toolchain.cmake but that doesn't help...
2014-05-08 10:12:43 < Zyrill> alright, I figured out which options are needed - can I update the guide somehow?
2014-05-08 10:19:02 < Zyrill> nm, figured it out
--- Log closed Thu May 08 10:55:29 2014
--- Log opened Thu May 08 11:19:34 2014
2014-05-08 12:13:15 < Zyrill> one more question: how to build for bit-depths > 8?
2014-05-08 19:41:06 < Daemon404> is satoshi employed by MCW?
2014-05-08 19:41:13 < Daemon404> or is he just a crazy guy submitting patches?
2014-05-08 19:41:13 < JEEB> nah
2014-05-08 19:41:21 < JEEB> he probably is getting paid for the work though
2014-05-08 19:41:26 < JEEB> look at his domain
2014-05-08 19:41:50 < JEEB> > oki.com
2014-05-08 19:42:00 < Daemon404> i had never heard of oki until now
2014-05-08 19:42:09 < Daemon404> servers must be in japan
2014-05-08 19:42:12 < Daemon404> slow servers are slow
2014-05-08 19:50:24 < phc> some of those east asian networks don't "interface" well
2014-05-08 20:02:52 < muggs> he doesn't work for MCW; but I think his employer is using x265
2014-05-08 20:04:14 < muggs> Santhoshini, on the other hand, is one of ours (and is a girl)
2014-05-08 22:21:29 < kierank> Daemon404: oki are a big company
--- Day changed Fri May 09 2014
2014-05-09 03:26:42 < pengvado> muggs: want me to write a trellis?
2014-05-09 03:28:04 < muggs> Hi pengvado. I would love to be able to replace rdoq from the HM with something more like the trellis in x264
2014-05-09 03:33:15 < muggs> my hunch is it would require a bit of carnage to the functions around it
2014-05-09 11:53:43 < Daemon404> exciting!
2014-05-09 22:42:07 < Rodeo> any known x265 1.0 crashes?
--- Day changed Sat May 10 2014
--- Day changed Sun May 11 2014
--- Day changed Mon May 12 2014
2014-05-12 13:54:34 < Daemon404> are that many people using abr that it requires so much development?
--- Day changed Tue May 13 2014
2014-05-13 05:11:16 < muggs> is anyone awake at this hour?
2014-05-13 08:10:37 <@Skyler_> muggs: I am
2014-05-13 08:11:02 < muggs> Hi Skyler_; what timezone are you in?
2014-05-13 08:11:40 <@Skyler_> PDT
2014-05-13 08:12:05 < muggs> ah, just normal insomnia then :)
2014-05-13 08:12:15 <@Skyler_> I don't have the most consistent sleep schedule -_-;
2014-05-13 08:13:08 < muggs> did you have any chance to look at my psy-rd patch?
2014-05-13 08:13:51 <@Skyler_> I'm curious how it affects transform size decision
2014-05-13 08:14:13 <@Skyler_> a totally guessy heuristic of mine would be "if it significantly skews the transform size decision, something might be wrong"
2014-05-13 08:14:33 <@Skyler_> I'd also put it off by default at first until there's been some testing, I think
2014-05-13 08:14:40 <@Skyler_> since right now you're adapting an algorithm that hasn't yet been tested in h265 yet
2014-05-13 08:15:03 < muggs> it is missing some pieces, for sure, so its just in RFC mode
2014-05-13 08:15:18 < muggs> I was mostly curious I was measuring "energy" in a sane fashion
2014-05-13 08:15:47 <@Skyler_> is your energy the same as x264's, or is it different?
2014-05-13 08:16:34 < muggs> as I understood it, x264 measures sa8d and satd and averages the cost.  we're just using sa8d at present
2014-05-13 08:16:53 <@Skyler_> ah, okay.
2014-05-13 08:17:01 <@Skyler_> that's a start at least
2014-05-13 08:17:14 <@Skyler_> oh.  you need to remove the DC coefficient from your sa8d-with-zero
2014-05-13 08:17:22 < muggs> just a basic thing though, it is measuring sa8d of a block to an all-zero block
2014-05-13 08:17:32 <@Skyler_> we want just the AC energy, since DC isn't energy
2014-05-13 08:17:53 < muggs> ok.. that's what I thought I was missing
2014-05-13 08:18:04 <@Skyler_> since this would bias in favor of blocks with higher average pixel value
2014-05-13 08:18:57 < muggs> hmm; does x264 have a cref for sa8d_ac?
2014-05-13 08:19:41 < muggs> I see a hadamard_ac
2014-05-13 08:20:23 <@Skyler_> hadamard_ac is that, it averages satd and sa8d
2014-05-13 08:20:37 <@Skyler_> for removing the DC, you can cheat, e.g. by subtracting SAD-with-zero afterwards with the right multiplicative factor
2014-05-13 08:20:48 <@Skyler_> I think that's what x264 did before hadamard_ac existed, though I don't know whether that was committed
2014-05-13 08:21:25 < muggs> oh, interesting
2014-05-13 08:21:33 <@Skyler_> it's suboptimal but works as a hack
2014-05-13 08:21:37 <@Skyler_> and I mean, isn't that much slower
2014-05-13 08:22:03 < muggs> slower than doing it in one-pass somehow?
2014-05-13 08:24:42 < muggs> oh, dc is just the corner coeff of each 8x8?
2014-05-13 08:26:31 <@Skyler_> yeah
2014-05-13 08:26:41 <@Skyler_> it represents the average pixel value of the block
2014-05-13 08:27:10 < muggs> ok
2014-05-13 08:27:58 < muggs> thus sad-with-zero / w*h
2014-05-13 08:28:09 <@Skyler_> not quite, since there's a multiplicative factor
2014-05-13 08:28:17 <@Skyler_> because SATD is scaled
2014-05-13 08:28:52 <@Skyler_> i.e. SATD(block of all X, 0) = SAD(block of all X, 0) * Y
2014-05-13 08:28:58 <@Skyler_> for a constant block of all value X
2014-05-13 08:29:03 <@Skyler_> Y is a power of 2
2014-05-13 08:29:45 <@Skyler_> I'm... not actually sure what the scaling factor is.  I think in x264 it might be done inside the satd functions (the /= 2 at the end) to make SAD match up to SATD but pengvado would know this
2014-05-13 08:29:53 <@Skyler_> but you could experiment to figure it out, for sure
2014-05-13 08:30:12 < muggs> right; I think that's plan A
2014-05-13 08:31:48 < muggs> so you're saying that if sa8d is not a good enough energy measurement on it's own, you would expect the transform sizes to be affected when psyrd is enabled?
2014-05-13 08:34:31 <@Skyler_> my main worry of only using a single transform size for energy (e.g. the reason for averaging) was the fear it would bias in favor of the other transform size
2014-05-13 08:34:41 <@Skyler_> e.g. 4x4 transform blocking artifacts will make 8x8 look more energetic
2014-05-13 08:34:48 <@Skyler_> and 8x8 transform artifacts will make 4x4 look better
2014-05-13 08:34:56 <@Skyler_> so if I used either one alone, it would bias in favor of the other
2014-05-13 08:35:11 <@Skyler_> I don't know if a bias is necessarily -wrong-, but it felt iffy so I erred on the side of caution and used an average.
2014-05-13 08:37:02 < muggs> do you think we should get psy-trellis implemented before we look at those kinds of effects, and debug them together?
2014-05-13 08:38:21 <@Skyler_> I don't think so, starting with RD should be simple enough
2014-05-13 08:38:31 <@Skyler_> psy-trellis is more of a mess and was even -less- of a solved problem
2014-05-13 08:38:34 <@Skyler_> anyways *sleep*
2014-05-13 08:38:55 < muggs> good luck with that :)
--- Day changed Wed May 14 2014
--- Day changed Thu May 15 2014
2014-05-15 02:41:43 < muggs> anyone around?
2014-05-15 02:42:44 <@Skyler_> meow?
2014-05-15 02:45:02 < muggs> heh
2014-05-15 02:45:52 < muggs> someone pointed out that x265_encoder_open() could modify the param structure passed in; and that seems like possibly a bad thing
2014-05-15 02:46:16 <@Skyler_> that does seem bad.  I think x264's copies it in.
2014-05-15 02:46:36 <@Skyler_>     memcpy( &h->param, param, sizeof(x264_param_t) );
2014-05-15 02:46:54 < muggs> we do make a copy, but probably after some of these modifications
2014-05-15 02:47:12 <@Skyler_> x264 makes the copy at the start of the function
2014-05-15 02:47:23 < muggs> is there an API function to get the modified copy?
2014-05-15 02:47:44 <@Skyler_> yes; x264_encoder_param
2014-05-15 02:47:54 <@Skyler_> er, x264_encoder_parameters
2014-05-15 02:48:06 < muggs> yeah, I see it now. don't know how I missed it earlier
2014-05-15 02:48:07 <@Skyler_> * x264_encoder_parameters: *      copies the current internal set of parameters to the pointer provided *      by the caller.  useful when the calling application needs to know *      how x264_encoder_open has changed the parameters, or the current state *      of the encoder after multiple x264_encoder_reconfig calls.
2014-05-15 03:09:49 < muggs> patch mailed
2014-05-15 03:10:45 < muggs> does AQ try to be bitrate neutral at all?
2014-05-15 04:18:01 <@Skyler_> muggs: I tuned it to try to be bitrate neutral over a large corpus
2014-05-15 04:18:06 <@Skyler_> (that's what the arbitrary constants are for)
2014-05-15 04:18:19 <@Skyler_> but on any given file it can be massively not-bitrate-neutral, which is expected
2014-05-15 04:18:31 <@Skyler_> since it changes the definition of quality.
2014-05-15 04:21:01 < muggs> it seems to depend a lot on the general complexity of the video; if it has a lot of detail, bitrate reduces
2014-05-15 04:21:53 <@Skyler_> yes, that's expected
2014-05-15 04:22:01 <@Skyler_> higher detail videos get "too much bitrate" without AQ, at a given CRF
2014-05-15 04:22:04 <@Skyler_> and vice versa for low bitrate.
2014-05-15 04:22:38 < muggs> right, that makes sense
2014-05-15 04:24:10 < muggs> unrelated question: I want to allow the user to specify a minimum decoder req level, but it doesn't seem like there is much we can actually do to enforce a level
2014-05-15 04:24:24 < muggs> ie: we can reduce references and reduce bitrate, but that's about i
2014-05-15 04:24:26 < muggs> t
2014-05-15 04:24:45 <@Skyler_> you can fail if the user asks for an impossible level
2014-05-15 04:25:10 < muggs> ok
2014-05-15 04:25:39 <@Skyler_> or warn, like x264 does
2014-05-15 04:25:56 < muggs> and if the level is already lower than requested? Would it be expected to do nothing?
2014-05-15 04:26:22 <@Skyler_> x264 just applies whatever level flag you ask for, and warns if the result doesn't match
2014-05-15 04:26:33 <@Skyler_> it should be okay for the user to ask for a higher level flag than is needed.
2014-05-15 04:27:00 < muggs> if the min req is already 4.0 and they ask for 5.1, you just mark the video as 5.1?
2014-05-15 04:27:12 <@Skyler_> yeah, though you could probably leave it as 4.0 unless there's some really good reason not to
2014-05-15 04:27:15 <@Skyler_> either's okay, I'd think
2014-05-15 04:27:18 < muggs> ok
2014-05-15 04:27:44 < muggs> thanks
--- Day changed Fri May 16 2014
--- Day changed Sat May 17 2014
2014-05-17 18:21:43 < JEEB> oh, psy-rd got merged
2014-05-17 18:21:45 < JEEB> lessee
2014-05-17 19:09:10 < Daemon404> d9 posts indicate it causes massive artefacting
--- Day changed Sun May 18 2014
2014-05-18 09:51:33 < j-b> 'morning
2014-05-18 22:49:35 < phc_office> moanin'
--- Day changed Mon May 19 2014
2014-05-19 14:22:10 < Daemon404> i need to convince muggs to get a bnc
2014-05-19 14:22:12 < Daemon404> or irssi
2014-05-19 14:22:14 < Daemon404> or something
2014-05-19 19:12:39 < ksam> Hi,
2014-05-19 19:20:00 < ksam> 1.In x264 the vui parameter, i_time_scale is calculated as sps->vui.i_time_scale = param->i_timebase_den * 2 (where i_timebase_den is the denom of fps). Why timebase_den is multiplied by 2? Is it related to interlace scanning?
2014-05-19 19:30:28 < ksam> 2. The rate control parameter, rc->hrd_multiply_denom = 180000 / num, where num is the reduced fraction of num=180000. Why is the value of num set to 180000 ?
2014-05-19 19:31:21 <@Skyler_> it's multiplied by 2 because h264 defines timebase in fields instead of frames
2014-05-19 19:31:27 <@Skyler_> 180000 = 90000 * 2
2014-05-19 19:36:57 < ksam> what does the value 90000 denote?
2014-05-19 19:40:36 < ksam> 3. x264 has calculated cpb removal time, dpb output time in ratecontrol_end function. x264 does not output these values anywhere. why are they calculated?
2014-05-19 19:45:10 < ksam> 4. H265 spec has specified initialAltCpbRemovalDelay and offset parameters in buffering period sei messages. What are these parameters used for ? How should their values be set?
2014-05-19 19:45:50 <@Skyler_> it's a thing from the spec, probably inherited from mpeg-2 ts
2014-05-19 19:45:59 <@Skyler_> they're calculated for HRD, I think
2014-05-19 19:46:04 <@Skyler_> kierank knows more, I think
2014-05-19 19:46:55 < ksam> ok, thank you
2014-05-19 19:47:21 < kierank> ksam: they are output in a hrd_timing struct
2014-05-19 19:47:39 < kierank> 90khz is a convention from mpegts, yes
2014-05-19 19:47:49  * kierank afk
2014-05-19 19:54:05 < ksam> @kierank: yes, as you said the cpb removal time and dpb output time are part of hrd_timing struct. But i did not get the purpose of these parameters being calculated at the encoder side, since we neither write them into the bitstream nor check these parameters for conformance
2014-05-19 20:07:11 < kierank> they are useful for ts muxing
2014-05-19 20:08:20 < ksam> thank you
--- Day changed Tue May 20 2014
2014-05-20 14:45:28 < muggs> g'morning
2014-05-20 14:54:38 < Daemon404> hey muggs
2014-05-20 14:54:49 < Daemon404> have you considered havign a persistent irc client?
2014-05-20 14:54:54 < Daemon404> youre never around when i wanna poke you =p
2014-05-20 15:04:28 < muggs> I haven't found a unix machine with sufficient uptime; everything we have reboots at least once a week because we're constantly swapping hardware
2014-05-20 15:05:19 < Daemon404> has to be at MCW?
2014-05-20 15:05:29 < Daemon404> (also how are there no servers with uptime? lol)
2014-05-20 15:05:30 < muggs> it doesn't have to be
2014-05-20 15:05:50 < muggs> with uptimes more than 2 days
2014-05-20 15:05:59 < Daemon404> thats pretty lul
2014-05-20 15:06:46 < muggs> yeah, we generally don't use any servers for typical server things; we only use them for development.
2014-05-20 15:06:53 < muggs> all our "services" are web hosted
2014-05-20 15:07:45 < kierank> muggs: do you want me to invite you to irccloud
2014-05-20 15:08:42 < muggs> kierank: that would be quite helpful, thanks
2014-05-20 15:08:48 < kierank> muggs: what email?
2014-05-20 15:09:21 < muggs> I guess my personal email would be better:  steve@borho.org
2014-05-20 15:09:47 < Daemon404> muggs, has tom pointed you at the tests on d9?
2014-05-20 15:09:53 < Daemon404> lots of artifacting with psy
2014-05-20 15:09:57 < Daemon404> like, in a bad way
2014-05-20 15:10:33 < muggs> the initial commit had several bugs; some have been fixed; one I'm testing now and will push shortly
2014-05-20 15:10:42 < Daemon404> cool
2014-05-20 15:10:44 < muggs> sa8d was borked hard
2014-05-20 15:11:05 < kierank> muggs: sent
2014-05-20 15:11:12 < muggs> thanks
2014-05-20 15:11:22 < Daemon404> sa8d == 'sum of absolute <???> differences' ?
2014-05-20 15:11:27 < Daemon404> 8bit? 8x8?
2014-05-20 15:12:03 < muggs> like satd but for 8x8 blocks
2014-05-20 15:12:21 < Daemon404> hadamard?\
2014-05-20 15:12:32 < muggs> ok, the fix has been pushed
2014-05-20 15:12:56 < muggs> I think so
2014-05-20 15:13:28 < Daemon404> shoudlnt hevc need something greater than 8x8
2014-05-20 15:13:58 < muggs> possibly, but even the HM didn't use anything bigger than sa8d
2014-05-20 15:15:56 < Daemon404> yeah but why does HM do anything
2014-05-20 15:15:57 < smarter> HM has psyrd?
2014-05-20 15:15:58 < Daemon404> nobody knows
2014-05-20 15:16:11 < smarter> the guy who wrote the code probably knows
2014-05-20 15:16:17 < Daemon404> smarter, he means for RDO probably
2014-05-20 15:16:30 < muggs> HM doesn't have psy-rd, but it does have AQ
2014-05-20 15:16:34 < Daemon404> ah
2014-05-20 15:16:35 < Daemon404> ok
2014-05-20 15:17:14 < muggs> the HM uses sa8d to do non-RDO mode decisions
2014-05-20 15:18:24 < muggs> brb
2014-05-20 15:26:09 <@muggs> ok, logged in through irccloud
--- Day changed Wed May 21 2014
2014-05-21 17:03:30 < JEEB> hmm
2014-05-21 17:03:39 < JEEB> weightb is now disabled even in preset placebo?
2014-05-21 17:32:28 <@muggs> yeah, weightb results are pretty disappointing
2014-05-21 17:35:53 <@Skyler_> it never helped much in h264, but it was basicaly free performance wise so we left it on
2014-05-21 18:27:33 < Daemon404> [17:59] < JEEB> weightb is now disabled even in preset placebo?
2014-05-21 18:27:42 < Daemon404> i always thought x265 isnt using that preset right
2014-05-21 18:27:48 < Daemon404> it's called "placebo" for a reason
2014-05-21 18:27:55 < Daemon404> i.e. enabble all the hilariously slow things that ake no difference
2014-05-21 18:28:01 < Daemon404> make*
2014-05-21 18:31:16 < JEEB> oh
2014-05-21 18:31:23 < JEEB> I tried psy-rd and I got a nice crash it seems
2014-05-21 18:39:56 < JEEB> aand... windows didn't let me attach a debugger
2014-05-21 18:39:57 < JEEB> welp
2014-05-21 19:21:42 <@muggs> doh
2014-05-21 19:21:51 <@muggs> was that with a recent build?
2014-05-21 19:26:07 <@muggs> I just reduced the memory footprint by about 10%
2014-05-21 19:39:26 < JEEB> 6905:a1c87ac
2014-05-21 19:39:46 < JEEB> aand
2014-05-21 19:39:49 < JEEB> now it finished properly
2014-05-21 19:39:50 < JEEB> \o/
2014-05-21 19:40:32 < JEEB> wow
2014-05-21 19:40:33 < JEEB> yeah
2014-05-21 19:40:37 < JEEB> artifacts, ho
2014-05-21 19:41:02 <@muggs> something is still borked, the crash is proof enough of that.
2014-05-21 19:41:19 < JEEB> too bad I couldn't replicate
2014-05-21 19:41:32 <@muggs> valgrind should find it
2014-05-21 19:42:36 < JEEB> --preset placebo --crf 32 --bframes 16 --ref 16 --weightb --rc-lookahead 90 --psy-rd 0.8 is a general gist of what I used
2014-05-21 19:43:04 < JEEB> I'll see if I'm able to replicate it later on
2014-05-21 19:46:04 <@muggs> what resolution?
2014-05-21 19:46:46 < JEEB> 1280x720
2014-05-21 19:46:54 < JEEB> 4:2:0, 8bit build
2014-05-21 20:17:57 <@muggs> the thing about weightb is it often causes compression loss, and I couldn't understand why - thus it's not enabled at any preset yet
2014-05-21 20:18:39 <@muggs> it's on my backlog to figure out what the hell it's actually doing
2014-05-21 20:20:07 < Daemon404> thats strange indeed
--- Day changed Thu May 22 2014
--- Day changed Fri May 23 2014
2014-05-23 02:44:09 < muggs> two more psy-rd fixes pushed
2014-05-23 13:30:01 < Daemon404> [18:08] < meow> x265 is damn impressive, I hadn't realised until right now
2014-05-23 13:30:10 < Daemon404> spotted on #daala yesterday
2014-05-23 13:51:22 < muggs> we've come a long way in one year, for sure
2014-05-23 13:52:03 < muggs> but I know where all the bodies are hidden in the code, so I don't have that high of an opinion on the whole thing
2014-05-23 13:52:16 < nevcairiel> lol
2014-05-23 13:55:36 < Daemon404> lul
2014-05-23 14:25:00 < phc> HP to cut up to 16K jobs:  http://www.reuters.com/article/2014/05/22/us-hp-results-idUSBREA4L12T20140522
2014-05-23 14:35:56 < muggs> ouch
2014-05-23 14:43:47 < muggs> has anyone tried psy-rd since the fixes from last evening?
2014-05-23 15:03:40 < Daemon404> i dont see any on d9
2014-05-23 16:26:11 < Easyfab> about psy-rd testing : from which presets exactly  >slow, >slower ? or medium + --rd 5 ?
2014-05-23 16:40:00 < muggs> slower and below
2014-05-23 16:41:08 < muggs> running a long encode locally; I've been informed artifacts are still present
2014-05-23 16:42:13  * Mandarinka runs a short encode but on placebo...
2014-05-23 16:43:09 < Mandarinka> damn, next time I will borrow the notebook with Sandy Bridge dualcore, SSE2-only AMD really sucks for this
2014-05-23 16:43:24 < Easyfab> Yes still present mainly with forman ( preset slower )
2014-05-23 16:46:04 < Easyfab> *foreman
2014-05-23 17:48:26 < muggs> perhaps we need use default to a lower psy-rd strength; I'd like to experiment with that
2014-05-23 18:02:20 < muggs> Mandarinka: you really want SSE4 with x265
2014-05-23 18:04:06 < Mandarinka> indeed
2014-05-23 18:07:17 < Daemon404> in other fun news, daala claims to be as good as x264 for still images right now
2014-05-23 18:07:20 < Daemon404> no idea wrt x265
2014-05-23 18:09:27 < Mandarinka> but being years from finalization and who knows how it lands in the end :(
2014-05-23 18:10:38 < Mandarinka> wasn't their milestone for Q2 "beating HEVC/VP9 motion compensation"? They are still on intra ATM it seems
2014-05-23 18:10:40 < Daemon404> you know why i have my doubts about daala, Mandarinka
2014-05-23 18:10:54 < Mandarinka> yeah, I know (I agree)
2014-05-23 18:12:26 < Daemon404> muggs, ive been putting off my next round of testing until x265 psyrd is usable btw :P
2014-05-23 18:12:33  * Daemon404 is an anxious child
2014-05-23 18:29:04 < muggs> no pressure, eh?
2014-05-23 18:32:09 < Daemon404> technically no
2014-05-23 18:32:15 < Daemon404> since its just for fun right now
2014-05-23 18:32:24 < Daemon404> for me anyway
2014-05-23 19:07:16 < muggs> roughly: it's picking merge when it should be picking inter. need to figure out why
2014-05-23 19:18:26 < muggs> best guess is there are some calcRdCost() calls that need to be calcPsyRdCost()
2014-05-23 19:22:57 <@Skyler_> muggs: you should make it so that -all- RD cost calls include psy, or none do
2014-05-23 19:23:05 <@Skyler_> at least, I don't think you need two functions
2014-05-23 19:23:11 <@Skyler_> since RD needs to be all the same or it won't work
2014-05-23 19:23:40 < muggs> right
2014-05-23 19:30:00 < muggs> recon isn't always available though, at various levels of the analysis
2014-05-23 19:30:38 < muggs> but I agree any costs that get compared need to be all psy-costs or all non-psy-costs
2014-05-23 19:34:28 <@Skyler_> how can you do RD without recon though?
2014-05-23 19:34:41 <@Skyler_> I mean, recon isn't always available, but when it's not, you can't really do RD at all.
2014-05-23 19:48:51 < muggs> it appears recon is generated into shorts and distortion is measured from those; a bit deeper down the call stack
2014-05-23 19:53:40 < muggs> calcrecon is generating short and pixel versions of the recon. I don't know why the short version is used to measure distortion
2014-05-23 20:08:23 < muggs> it might be finally time for me to tear into the mode decision code; long overdue
2014-05-23 21:34:08 < Mandarinka> aw, I forgot psyrd was not on by default lol
2014-05-23 21:36:00 < Mandarinka> I might have missed it, but on x265.org, there should really be a link for the online documentation I'd say - possibly for the wiki on bitbucket too
--- Day changed Sat May 24 2014
2014-05-24 14:57:10 < Mandarinka> test encode with psyrdo from yesterday (chromashift 64-bit build 1.0.111 msvc). Sadly the artefacting is there and the grain reproduction with psy-rd=1.0 isn't good either, there is visible denoising effect (although without psy, everything seems to be smoothing even more, the flat areas get totally wiped and suffer banding):
2014-05-24 14:57:12 < Mandarinka> http://screenshotcomparison.com/comparison/76107
2014-05-24 14:57:19 < Mandarinka> http://screenshotcomparison.com/comparison/76106
2014-05-24 14:57:30 < Mandarinka> http://screenshotcomparison.com/comparison/76108
2014-05-24 14:57:34 < Daemon404> build hasnt run today
2014-05-24 14:57:36 < Daemon404> chromashift is me
2014-05-24 14:57:45  * Daemon404 runs
2014-05-24 14:57:54 < Mandarinka> (sorry, these sites break with loading more than two pairs at once)
2014-05-24 14:58:59 < Mandarinka> I don't know if the look of the artifacts  suggests something, but curiously
2014-05-24 14:59:19 < Mandarinka> I didn't find artifacts in a scene that has a static image with a pan
2014-05-24 14:59:31 < Mandarinka> at least so far, got to look at more frames
2014-05-24 15:00:15 < Daemon404> that site is insanely slow
2014-05-24 15:01:14 < Mandarinka> although I think the artifacts only appear in some frames in other shots too, so that might be an accident
2014-05-24 15:01:19 < Mandarinka> *coincidence
2014-05-24 15:01:32 < Daemon404> i still notice a lot of grain being nuked
2014-05-24 15:02:26 < Daemon404> also builds for .114 being built/uled
2014-05-24 15:03:29 < Mandarinka> yeah, grain gets washed basically. On the upside, without psyrdo, it ended up even worse
2014-05-24 15:04:04 < Mandarinka> all thsoe solid areas were totally wiped, even with banding appearing
2014-05-24 15:04:27 < Mandarinka> it is high motion scene, so even 7 megabits is probably too low
2014-05-24 15:04:35 < Mandarinka> will try crf 18 later :)
2014-05-24 15:04:56 < Daemon404> im really only interested vs x264 current :P
2014-05-24 15:05:02 < Daemon404> currently*
2014-05-24 15:10:53 < Mandarinka> let's see
2014-05-24 15:12:28 < Mandarinka> ah wait, I'll compare it with x265 using psy-rd=2.0
2014-05-24 15:14:12 < Daemon404> 2.0 seems pretty high... in x264 terms anyway
2014-05-24 15:14:16 < Daemon404> x265 might have a weird default
2014-05-24 15:15:27 < Mandarinka> yeah, but the effect looks weak in x265 in terms of grain retention, so I want to try that (I used 1.0 in that encode)
2014-05-24 15:17:07 < Daemon404> it's a shame x265 doesnt let you play with deadzones
2014-05-24 15:17:24 < Daemon404> pre-psy-rd that was how i made x264 not nuke stuff
2014-05-24 15:19:41 < Mandarinka> also no qpmax
2014-05-24 15:20:38 < Daemon404> ive never messed with that
2014-05-24 15:20:50 < Daemon404> just qpmin, since quicktime cant handle qp <5
2014-05-24 15:34:25 < Mandarinka> I set qpmin=0 one I found out about that
2014-05-24 15:34:46 < Mandarinka> or maybe I did it primarily since it couldn't harm, not sure now
2014-05-24 15:35:10 < Mandarinka> quicktime can't do 10bit anyway (speaking about fansubs/anime here)
2014-05-24 15:37:31 < Daemon404> default in x264 is qpmin=0
2014-05-24 15:37:36 < Daemon404> thats how you noticed.
2014-05-24 15:38:21 < JEEB> yeah, it was modified a few years back when the x264 rate control no longer needed to keep lowest QPs out
2014-05-24 15:38:33 < JEEB> (I guess earlier in development it would uselessly use lower QPs)
2014-05-24 17:24:32 < Mandarinka> ah, damn, I again forgot to check the avs file and encoded an interleave() used for comparing :/
2014-05-24 17:24:52 < Mandarinka> didn't notice avs2yuv reporting 48000/1001 fps :(
2014-05-24 19:12:23 < Daemon404> i could test x265...
2014-05-24 19:12:28 < Daemon404> but connecting to vpn is :effort:
2014-05-24 19:12:34 < Daemon404> for a saturday
2014-05-24 22:02:36 < Mandarinka> hmm, psy-rd=2.0 didn't really result in decent grain retention (although it used higher bitrate, 7915 kbps for 1440x1080)
2014-05-24 22:10:27 < Mandarinka> it makes another sort o fartifats stronger: displaced ghost oulines of objects - see the concrete block's halo on top left and the circles caused by the lamp on mid left
2014-05-24 22:10:31 < Mandarinka> http://screenshotcomparison.com/comparison/76167
2014-05-24 22:11:37 < Mandarinka> hmm, also, in many of these tests, I saw that x265 used a large flat (solid color) block as a reference that had almost the same content as that block in source frame, except for the corners
2014-05-24 22:11:56 < Mandarinka> so you get almost right motion compensation, but the corner pixels are wrong
2014-05-24 22:13:04 < Mandarinka> see the black dots appearing in the car's dark grey back, above the bumper/license plate
2014-05-24 22:13:27 < Mandarinka> without psyrdo, that thing doesn't happen.
2014-05-24 22:16:16 < Mandarinka> (actually, I see that I upped jpegs instead of png, but I now checked and they seem visually lossless)
2014-05-24 22:18:21 < Mandarinka> http://screenshotcomparison.com/comparison/76169  --- here with png
--- Day changed Sun May 25 2014
2014-05-25 15:05:33 < Daemon404> Mandarinka, thats funky
2014-05-25 17:01:17 < Mandarinka> indeed, ghastly encode
2014-05-25 17:02:07 < Mandarinka> reminds me of Snow or Dirac or whcih encoder it was with such distortion behaviour
2014-05-25 17:02:23 < Mandarinka> I'll try higher bitrate (and 114) now
--- Day changed Mon May 26 2014
2014-05-26 01:41:12 < Mandarinka> hmmm, with higher bitrate (14574 kbps, 1440x1080@24fps), you get less artifacts (but I still see some of those signs of improper motion-compensation), but still no grain preservation like x264 can do
2014-05-26 05:30:59 < kurosu> Mandarinka, have you tried disabling sao ?
2014-05-26 05:31:37 < Mandarinka> nope, didn't occur to me it would be destructive.
2014-05-26 05:31:42 < Mandarinka> maybe next time...
2014-05-26 06:32:00 < quaz0r> http://youtu.be/JZNQq7XBLwc
2014-05-26 09:10:08 < shion_chk2> POWERRRRRRRRRRRRR
--- Day changed Tue May 27 2014
2014-05-27 17:35:26 < thebombzen> I've got a quick question: what's the difference between the hg repositories http://hg.videolan.org/x265 and https://bitbucket.org/multicoreware/x265
2014-05-27 17:36:18 < Daemon404> the former is a mirror
2014-05-27 17:36:20 < Daemon404> the latter is source
2014-05-27 17:38:44 < muggs> I push to both; sometimes there a lag, but they're generally in sync
2014-05-27 17:39:15 < muggs> there was talk of automating that; I think funman wanted the videolan repo to be git
2014-05-27 17:39:59 < muggs> new psy-rd patches pushed
2014-05-27 17:44:36 < thebombzen> Is there any practical difference which one I pull from? Is one of them faster or less stressed, etc.?
2014-05-27 18:15:33 < muggs> bitbucket might be more up to date, videolan is probably less stressed.  it might depend on geography
--- Day changed Wed May 28 2014
2014-05-28 19:10:38 <@muggs> anyone interested in x265 contract work?
2014-05-28 19:13:22 < dtyx265> yes...
2014-05-28 19:17:48 < LordRPI> how much are you going to pay me? :)
2014-05-28 19:18:04 < LordRPI> Sorry that's rude. I'm often an idiot.
2014-05-28 19:18:33 <@muggs> it's the logical first question; the answer is it depends
2014-05-28 19:19:11 <@muggs> we have a number of needs, and wouldn't mind having others work on them
2014-05-28 19:19:43 <@muggs> 1. psy-opts (debugging and improving psy-rd, adding psy-trellis)
2014-05-28 19:19:49 <@muggs> 2. two-pass encode
2014-05-28 19:19:49 < dtyx265> "it depends..." is the answer to many software questions
2014-05-28 19:20:21 <@muggs> 3. performance optimizations in mode-decision (general cleanup in that area)
2014-05-28 19:21:15 <@muggs> 4. improving CBR mode of VBV
2014-05-28 19:23:05 <@muggs> the rate would be based on how many hours we thought it would take, and the difficulty involved
2014-05-28 19:24:08 < LordRPI> honestly I wish I were smart enough to do all those things
2014-05-28 19:24:19 < LordRPI> Admittedly I've played around very little with x265
2014-05-28 19:24:28 < dtyx265> I haven't been able to devote as much time as wanted to it but I am still working on replacing the HM h265 classes of TComSlice.h.  It's going to be a big patch...
2014-05-28 19:25:16 < dtyx265> but if you have something of higher priority, I could work on that instead.
2014-05-28 19:25:39 < BugMaster> if only it wasn't in C++ and I had time. dreams, dreams
2014-05-28 19:25:50 < LordRPI> C++ isn't that bad...
2014-05-28 19:31:07 < fionag> hi.  I just met with the mcs ceo
2014-05-28 19:31:29 <@muggs> hi fionag, how did that go?
2014-05-28 19:31:35 < fionag> fine!
2014-05-28 19:31:44 < LordRPI> muggs isn't the CEO?
2014-05-28 19:32:12 <@muggs> no, that would require having money
2014-05-28 19:32:27 <@muggs> I'm kind of the lead grunt
2014-05-28 19:36:14 <@muggs> dtyx265: Satoshi is kind of setting the standard for what a "big" patch is :)
2014-05-28 19:38:31 < dtyx265> big in terms of lines of code but not too big in terms of affecting functionality.  Though I am improving readability and maintainability of the code.
2014-05-28 19:38:53 < dtyx265> the HM code is kind of ugly in some spots
2014-05-28 19:39:05 <@muggs> s/kind of//
2014-05-28 19:40:12 <@muggs> if I ever get two spare days together, I plan on taking a hack-saw to TEncSearch and TEncCU
2014-05-28 19:49:27 < LordRPI> I haven't been looking lately, but is x265 moving to more C (vs C++)?
2014-05-28 19:54:46 <@muggs> not much, thus far
2014-05-28 20:03:13 < Daemon404> [20:21] < LordRPI> C++ isn't that bad...
2014-05-28 20:03:22 < Daemon404> just try and write exception-safe code
2014-05-28 20:03:24 < Daemon404> i dare you.
2014-05-28 20:09:39 < LordRPI> RAAI is your friend in that case, but yeah. I've seen stupid, stupid stupid things done with exceptions...
2014-05-28 20:10:33 < LordRPI> actually, I think I misunderstood that statement. point taken.
2014-05-28 20:12:16 <@muggs> what does exception safe C look like?
2014-05-28 20:14:44 < LordRPI> You don't throw exceptions in C
2014-05-28 20:15:19 < Daemon404> well C doesnt have exceptions
2014-05-28 20:15:23 < Daemon404> so all C is exception safe
2014-05-28 20:15:31 < JEEB> yeah, it's all return values until someone dereferences a null pointer
2014-05-28 20:15:36 < JEEB> and then you go have a beer
2014-05-28 20:15:36 < LordRPI> In C, if you call malloc and it fails, it returns NULL and sets errno. In C++, if new fails, it throws an exception... for example
2014-05-28 20:15:54 < JEEB> yeah... man, I love no-one actually checking for new failing
2014-05-28 20:16:00 < JEEB> even if it allocates a lot of memory
2014-05-28 20:16:05 < JEEB> (HI THERE MPC-HC)
2014-05-28 20:16:18 < Daemon404> http://stackoverflow.com/questions/1853243/c-do-you-really-write-exception-safe-code
2014-05-28 20:16:24 < Daemon404> read the top answer here
2014-05-28 20:16:25 < Daemon404> for what i mean
2014-05-28 20:16:44 < LordRPI> We had one guy print the call stack on every throw. There were trivial exceptions thrown all over the place. Our disks got full because of logs.
2014-05-28 20:19:00  * Daemon404 doesnt like exceptions in any lang, full stop
2014-05-28 20:27:13 <@muggs> it's not so bad in Python
2014-05-28 20:27:50 < Daemon404> muggs, yes it is
2014-05-28 20:27:59 < Daemon404> the stdlib does not properly document what exceptions each call can throw
2014-05-28 20:28:07 < Daemon404> so youll inevitably get a rando stack dump
2014-05-28 20:28:27 < Daemon404> and 3rd party libs? far worse.
2014-05-28 20:28:42 < Daemon404> (im looking at you, boto.)
2014-05-28 20:29:10 < Daemon404> at least msdn and the c++ standard documents what throws
--- Day changed Thu May 29 2014
2014-05-29 00:00:53  * muggs plays with homebrew recipes for x265 and ffmpeg
2014-05-29 00:08:03 <@muggs> brew install x265 --HEAD && brew install ffmpeg --with-x265
2014-05-29 00:14:54 <@muggs> ? ffmpeg by default configures x265 for ABR?
--- Day changed Fri May 30 2014
2014-05-30 10:03:46 < vbn> http://vk.com/away.php?to=http%3A%2F%2Fhaxxjp.net
2014-05-30 10:04:15 < vbn> https://zhovner.com/tmp/killwebkit.html hack for TELE
2014-05-30 10:06:22 < vbn> http://vk.com/club43237732
2014-05-30 10:06:57 < vbn> paludis/monkey/arachnist ddos
2014-05-30 10:08:36 < vbn> http://vk.com/videos-43237732?z=video-43237732_168162885%2Fclub43237732
2014-05-30 10:08:40 < vbn> H@h@H@H@Hh2
2014-05-30 10:08:43 < vbn> porno
2014-05-30 11:09:49 < vbn> porno
2014-05-30 11:09:52 < vbn> porno
--- Day changed Sat May 31 2014
--- Day changed Sun Jun 01 2014
--- Day changed Mon Jun 02 2014
2014-06-02 10:14:04 < j-b> Good morning
2014-06-02 15:55:51 <@muggs> is ffmpeg configuring ABR for x265 by default?
2014-06-02 15:56:23 < Daemon404> it uses whatever RC the lib uses by default
2014-06-02 15:56:46 < Daemon404> it is setting ABR though if a bitrate is given
2014-06-02 15:56:53 < Daemon404> since crf+bitrate makes no sense
2014-06-02 15:58:00 < Daemon404> http://www.ffmpeg.org/doxygen/trunk/libx265_8c_source.html#l00143
2014-06-02 15:58:18 <@muggs> I built ffmpeg on my mac last week and did a basic transcode with no args and it used ABR 200kbps
2014-06-02 15:58:46 < Daemon404> thats the default bitrate for ffmpeg
2014-06-02 15:58:48 < Daemon404> globally
2014-06-02 15:58:49 < Daemon404> for all encoders
2014-06-02 15:58:52 < Daemon404> its stupid, but not my doing
2014-06-02 15:59:15 < Daemon404> libx264 works the same way iirc
2014-06-02 15:59:18 < Daemon404> in ffmpeg
2014-06-02 15:59:31 <@muggs> I see, ok
2014-06-02 15:59:33 < JEEB> libx264 has the default overridden in one way or another
2014-06-02 15:59:39 < JEEB> to the libx264's default
2014-06-02 16:00:04 < Daemon404> oh
2014-06-02 16:00:20 < Daemon404> its still abr though isnt it?
2014-06-02 16:00:22 < Daemon404> or is it crf18?
2014-06-02 16:00:26 < JEEB> CRF 23
2014-06-02 16:00:29 < JEEB> the default in libx264
2014-06-02 16:00:30 < Daemon404> ah
2014-06-02 16:00:48 < Daemon404> at the time i wrote the x265 wrapper crf wasnt in x265 iirc
2014-06-02 16:00:53 < Daemon404> back in october
2014-06-02 16:01:57 <@muggs> right, it arrived a bit later
2014-06-02 16:02:18 < Daemon404> the wrapper still has one known issue fwiw
2014-06-02 16:02:28 < Daemon404> if it is passed less frames than teh delay it writes 0 bytes
2014-06-02 16:02:42  * Daemon404 is so lazy
2014-06-02 17:34:50  * muggs prepares --lossless patch
2014-06-02 20:25:47 <@muggs> lossless support and further psy-rd changes pushed
2014-06-02 20:26:18 <@muggs> medium and faster presets have been changed, making them faster
2014-06-02 20:26:56 <@muggs> and single-pass ABR has been greatly improved, particularly the first 2 seconds
2014-06-02 22:07:24 < Zanzibar_1> what is best x265 encoder
2014-06-02 22:07:59 < Zanzibar_1> what is best h265 encoder
2014-06-02 23:18:34 < Daemon404> O________o
2014-06-02 23:18:43 < Daemon404> patch from a raisin company???
2014-06-02 23:20:32 < Daemon404> net admin at sunmaid... interesting!
--- Day changed Tue Jun 03 2014
2014-06-03 00:29:27 <@muggs> we take all comers :)
2014-06-03 20:53:36 <@muggs> 1.1 tag pushed; writing release notes
2014-06-03 20:54:22 < Rodeo> does it have psy-rd, and has anyone come up with comparisons yet?
2014-06-03 20:54:38 < Daemon404> psy-rd is still brokenish
2014-06-03 20:54:44 < Daemon404> according to doom9 people
2014-06-03 20:54:50 < Rodeo> heh
2014-06-03 20:54:57 < Daemon404> tom seems to agree
2014-06-03 20:55:34 < Rodeo> what's Skyler_ doing? Skyler_ should be fixing those things :P
2014-06-03 20:55:49 < Daemon404> Skyler_ is fionag
2014-06-03 20:56:58 <@muggs> psy-rd improved a lot yesterday; tom's much happier with it
2014-06-03 20:57:08 <@muggs> but we're still improving it
2014-06-03 20:57:10 < Daemon404> his reply is from a few minuteshours ago
2014-06-03 20:57:12 < Rodeo> and are the improvements in 1.1 yet?
2014-06-03 20:57:17 <@muggs> and it's not on by fdefault
2014-06-03 20:57:35 < Daemon404> around 1.5 hrs ago
2014-06-03 20:57:52 <@muggs> errr, ok
2014-06-03 20:58:02 < Daemon404> http://forum.doom9.org/showthread.php?p=1682811#post1682811
2014-06-03 20:58:40 <@muggs> he's suggesting --psy-rd 0.4 or 0.5 for now
2014-06-03 20:58:52 < Daemon404> yes
2014-06-03 20:59:06 < Daemon404> is it worth testng against x264 yet
2014-06-03 20:59:12 < Daemon404> or do i need to worry about this 'wobbly' effect
2014-06-03 20:59:23 <@muggs> I dunno
2014-06-03 20:59:32 < Rodeo> OK what's up with that, you need the veryslow preset for psy-rd?
2014-06-03 20:59:42 < Daemon404> it needs RD
2014-06-03 20:59:45 < Daemon404> obviously
2014-06-03 21:00:14 < Daemon404> 5 or 6 iirc
2014-06-03 21:00:15 <@muggs> you could use --preset medium --rd 5 --psy-rd 0.5
2014-06-03 21:00:38 < Rodeo> yeah but, it's an important psy optimization, if it can work as well as the x264 one
2014-06-03 21:01:02 < Rodeo> the fact that RD is only enabled in such a slow preset seems really weird
2014-06-03 21:02:02 <@muggs> let's get it working correctly, then we can look at which presets to use it on
2014-06-03 21:02:03 < Rodeo> I understand it's not 100% ready yet, but once it is, it sounds like something most people will want to use
2014-06-03 21:03:58 < fionag> I'd imagine it's a speed thing?
2014-06-03 21:04:47 < Daemon404> spped isnt useful if x264 produces better quality at the same speed.
2014-06-03 21:05:52 < fionag> I just meant, that the presets are balanced by quality-per-speed, so if RD is super slow, it'll only end up on the slower presets...?
2014-06-03 21:05:59 < fionag> but I'll leave it to muggs...
2014-06-03 21:06:18 < Daemon404> yeah i know
2014-06-03 21:06:25  * Daemon404 was just thinking in practical terms
2014-06-03 21:06:56 <@muggs> right now RD isn't fine grained enough, it's either mostly off or fully on
2014-06-03 21:07:06 < Daemon404> HM remnant?
2014-06-03 21:07:16 <@muggs> mostly
2014-06-03 21:08:18 <@muggs> a lot of focus will be moving to this part of the code soon,  mode decision and two-pass
2014-06-03 21:09:11 < Daemon404> right
2014-06-03 21:11:10 <@muggs> back to release notes
2014-06-03 21:17:27 <@muggs> http://x265.readthedocs.org/en/1.1/
2014-06-03 22:29:16 < Mandarinka> <Rodeo> the fact that RD is only enabled in such a slow preset seems really weird --- the problem is probably that x265 RD is slow
2014-06-03 22:29:25 < Mandarinka> taken over from HM iirc.
2014-06-03 22:29:43 < Rodeo> yeah I guess that makes sense, but it shouldn't be :P
2014-06-03 22:29:50 < Mandarinka> so you can't really push it into 'fast' presets
2014-06-03 22:30:22 < Mandarinka> well yeah, in the roadmap, iirc there were plans to port over stuff from x264 for RDO, so hopefully that helps if it gets done
2014-06-03 22:31:28 < Mandarinka> oh actually, I see I missed it, but it pretty much was already said 90 minutes ago :)
--- Day changed Wed Jun 04 2014
2014-06-04 05:58:43 < Mandarinka> hmm, psyrdo really starts to look good (tried x265-1.0.156-msvc2012-64.exe with --rd 6 --psy-rd 0.3). A bit washed still, but it definitely starts to retain grain.
2014-06-04 05:59:39 < Mandarinka> however, in flashing scenes, the frames before the flash are often wiped completely flat
2014-06-04 06:00:07 < Mandarinka> hmm, perhaps I should see if disabling cutree helps in that o)
2014-06-04 06:01:25 < Mandarinka> hmm, the grain retention is a hit or miss thing, there are frames with wast areas of grain texture totally wiped off
2014-06-04 06:01:44 < Mandarinka> (speaking about a sample from a cel anime bluray)
2014-06-04 06:05:52 < Mandarinka> hmm, at 1440x1080p24 / 13 megabits, x264 still rules completely (basically, it looks transparent everywhere with grainy look)
2014-06-04 06:30:12 < greenfountain> quick question :in x264,  if i set vbv busize , vbv maxrate and bitrate to same value , does the VBV guarantee that one second moving average encoded bits will not exceed the set bitrate?
2014-06-04 15:11:17 < funman> muggs: will you be in Mountain View friday?
2014-06-04 15:38:11 <@muggs> funman: I work from my home in St Louis.. two time zones away. Are you in the Bay area today?
2014-06-04 15:38:49 < funman> muggs: yes, I just saw MCW will be there for the VP9 technical summit
2014-06-04 15:38:53 < funman> presenting GPU decoding
2014-06-04 15:39:07 <@muggs> I see
--- Day changed Thu Jun 05 2014
--- Day changed Fri Jun 06 2014
--- Day changed Sat Jun 07 2014
--- Day changed Sun Jun 08 2014
--- Day changed Mon Jun 09 2014
2014-06-09 08:58:23 < j-b> 'morning
2014-06-09 19:17:30 < Daemon404> latet testing with psy-rd 0.5 + placebo + r=16 + b=16... not great yet.
2014-06-09 19:17:33 < Daemon404> latest*
--- Day changed Tue Jun 10 2014
2014-06-10 16:56:31 <@muggs> Daemon404: so that's a solid: meh ?
2014-06-10 16:58:01 < Daemon404> detail is still noticably worse than x264+psy for me
2014-06-10 16:58:11 < Daemon404> and one clip (in a car) has a lot of blocking on the bg
2014-06-10 16:58:26 < Daemon404> sec
2014-06-10 17:00:01 < Daemon404> https://www.dropbox.com/s/h4nskdj60rxb1yw/window.png
2014-06-10 17:00:04 < Daemon404> check out the bg/window
2014-06-10 18:09:17 <@muggs> I wish I knew whether this was still a psy-rd issue, or whether we need psy-quant, or whether this is a more general mode-decision problem
2014-06-10 18:10:30 < quaz0r> this is the same dilemma your mother faced at your birth
2014-06-10 18:17:04 < Daemon404> wat
2014-06-10 19:26:51 < Daemon404> muggs, fo you need a clip to repro it?
2014-06-10 19:26:54 < Daemon404> do*
2014-06-10 19:28:26 <@muggs> an encoded bitstream would be helpful.  I suspect RDOQuant is nuking residual before psy-rd has any chance to enter into the discussion
2014-06-10 19:28:51 < Daemon404> https://chromashift.org/samples/clip_88251170_crf22_psy0.5.hevc
2014-06-10 19:28:56 < Daemon404> ^
2014-06-10 19:29:02 <@muggs> thanks
2014-06-10 19:33:37 < Daemon404> muggs, aside from the weird artefact, im mostly seeing fine detail/grain being smoothed out cmpare t x65
2014-06-10 19:33:40 < Daemon404> x264*
2014-06-10 19:33:53 < Daemon404> kinda like: http://forum.doom9.org/showthread.php?p=1683511#post1683511
2014-06-10 19:34:14 < Daemon404> (although the movie he is using sucks... even Cranston couldnt save it)
--- Day changed Wed Jun 11 2014
2014-06-11 17:54:58 <@muggs> we're finding that RDOQ is at least partly the culprit for the lost detail
2014-06-11 17:55:55 < j-b> ah, that's a good news
2014-06-11 17:56:06 < Daemon404> was that the bit from HM?
2014-06-11 17:58:29 <@muggs> yes
2014-06-11 17:59:34 <@muggs> turning it off improves detail; I imagine making it psy-aware will be even more effective
2014-06-11 18:00:12 <@muggs> turning it off currently requires patching the encoder.cpp
2014-06-11 18:00:49 < Daemon404> fun
2014-06-11 18:01:35 <@muggs> around line 1276:  m_bEnableRDOQ = 0; // p->rdLevel >= 4;
2014-06-11 18:01:47 <@muggs> (in case anyone wanted to try this at home)
2014-06-11 18:02:05 < Daemon404> didnt fionag basically say psy must be all or nothing
2014-06-11 18:02:09 < Daemon404> and that that's the point?
2014-06-11 18:02:17 < Daemon404> i.e. why wouldnt RDOQ be aware
2014-06-11 18:03:56 <@muggs> we need it to be; but it won't happen today
2014-06-11 18:04:19 < Daemon404> i was pretty sure fionag said psy-rd wouldnt even work without all RD steps being aware
2014-06-11 18:05:16 <@muggs> it's certainly less optimal because you're discarding what could be better choices, psy-wise
2014-06-11 18:09:43 <@muggs> RDOQ is definitely tuning towards SSE cost (PSNR), which sucks
2014-06-11 18:11:18 < Daemon404> woah
2014-06-11 18:11:25 < Daemon404> i didnt thing any real encoders used SSE
2014-06-11 18:11:35 < Daemon404> i like, i thought it was a "you only see this in textbooks" thing
2014-06-11 18:11:54 < nevcairiel> its from the reference encoder, thats kinda like a textbook
2014-06-11 18:11:58 < Daemon404> lol
2014-06-11 18:11:59 < Daemon404> true
2014-06-11 18:14:05 <@muggs> afaik, (non-psy) RDO works the same way in x264.  MIN(lambda2 * bits + SSE)
2014-06-11 18:14:25 < Daemon404> oic
2014-06-11 18:15:14 <@muggs> psy rd is just  MIN(lambda2 * bits + energy-diff * lambda * psy-weight + SSE)
2014-06-11 18:15:29 < Daemon404> i was probably thinking of using SSE for something else
2014-06-11 18:15:38 < Daemon404> maybe ME
2014-06-11 19:23:23 < fionag> muggs: trellis tunes towards SSD in x264 too, though, so I wonder if it would be any different
2014-06-11 19:24:49 < Daemon404> does x265 have trellis at all?
2014-06-11 19:25:07 < Daemon404> it could use it internally, but no such options are exposed
2014-06-11 19:25:43 <@muggs> rdoq is vaguely equivalent to trellis
2014-06-11 19:26:43 < Daemon404> im not going to lie, im still not entirely clear on what the trellis algo is
2014-06-11 19:26:55 < Daemon404> i seem to rememeber it bering viterbi?
2014-06-11 19:27:04 < Daemon404> mst google results point to x264
2014-06-11 19:27:13 < Daemon404> or lorens directory of things (tm)
2014-06-11 19:40:20 <@muggs> apparently our tip code, when used in ffmpeg, can no longer mux to MP4
2014-06-11 19:40:32 < Daemon404> oh?
2014-06-11 19:40:45 < Daemon404> i encoded with tip yesterday, but i output to raw
2014-06-11 19:41:06 < Daemon404> muggs, did anything change recently to cause it?
2014-06-11 19:41:14 < Daemon404> it at least *builds* ok
2014-06-11 19:41:21 < fionag> trellis is a way of using viterbi to optimize quantization for minimum RD score
2014-06-11 19:41:30 < fionag> (bits * lambda2 + SSD)
2014-06-11 19:41:42 < Daemon404> fionag, where did the name come from? did loren make it up?
2014-06-11 19:41:48 < Daemon404> google points to loren
2014-06-11 19:41:51 < fionag> I think trellis has existed as a name for a long time?  it's in the literature and stuff
2014-06-11 19:42:09 <@muggs> nothing intentional changed.  sorry, I was wrong about ffmpeg, the problem is in mp4box
2014-06-11 19:42:13 < fionag> "trellis" refers to the shape of the graph used by the viterbi, I think?
2014-06-11 19:42:15 < Daemon404> iirc the wiki page was even created by... you fionag
2014-06-11 19:42:18 < Daemon404> iirc, anyway
2014-06-11 19:42:20 < fionag> http://en.wikipedia.org/wiki/Trellis_diagram#Trellis_diagram
2014-06-11 19:42:41 < fionag> it's been a thing in the literature long before x264 existed, at least, I think?
2014-06-11 19:42:52 < fionag> at the very least Michael made one for libavcodec before x264's.
2014-06-11 19:42:56 < fionag> Xvid had one too
2014-06-11 19:43:00 < Daemon404> in terms of quantization?
2014-06-11 19:43:09 < fionag> yeah
2014-06-11 19:43:28 < fionag> CABAC is actually kinda easier to trellis than MPEG-2/MPEG-4-alikes, I think?
2014-06-11 19:43:35 < Daemon404> (cur | prev) 06:09, 9 June 2007‎ Dark Shikari (talk | contribs)‎ . . (1,075 bytes) (+1,075)‎ . . (new article)
2014-06-11 19:43:40 < Daemon404> for the wiki page on trellis quant
2014-06-11 19:43:41 < Daemon404> :P
2014-06-11 19:43:46 < fionag> yeah, I know, that's just wikipedia though ^^;
2014-06-11 19:44:01 < Daemon404> ive always known it as viterbi
2014-06-11 19:44:03  * Daemon404 shrugs
2014-06-11 19:44:59 < Daemon404> muggs, ah ok
2014-06-11 19:45:15 < Daemon404> we dont use mp4box at work (or lavf for that matter)
2014-06-11 19:45:22 < Daemon404> probably why i didnt notice
2014-06-11 19:45:44 < Daemon404> l-smash handles it fine
2014-06-11 19:46:27 <@muggs> http://pastie.org/9281039
2014-06-11 19:46:46 < Daemon404> i see
2014-06-11 19:46:50 <@muggs> I've been mucking with the output bitstream classes, trying to remove mallocs and memcopies
2014-06-11 19:46:56 < Daemon404> i cant offer any ideas
2014-06-11 19:47:00 <@muggs> but our CLI output bitstreams haven't changed
2014-06-11 19:47:09 < Daemon404> im not exactly fond of GPAC :)
2014-06-11 19:47:30 <@muggs> something wrong with GPAC?
2014-06-11 19:47:36 < Daemon404> the entity? lots.
2014-06-11 19:47:41 < Daemon404> but thats not relevant here
2014-06-11 19:47:50 <@muggs> ok
2014-06-11 19:47:56 < Daemon404> libx265.c should be pretty clear if you want to look
2014-06-11 19:48:05 < Daemon404> i havent needed to change it since build 1
2014-06-11 19:48:06 < Daemon404> 13
2014-06-11 19:48:15 < Daemon404> so its not some new change to break stuff
2014-06-11 19:49:11 < Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx265.c
2014-06-11 19:50:19 <@muggs> shouldn't X265_API_IMPORTS be defined before including x265.h?
2014-06-11 19:50:31 < Daemon404> fff yes
2014-06-11 19:50:36 < Daemon404> who moved that
2014-06-11 19:50:53 < Daemon404> oh right.
2014-06-11 19:51:04 < Daemon404> i was told to move it there during "review"
2014-06-11 19:51:11 < Daemon404> by you-know-who
2014-06-11 19:51:13 < Daemon404> ill fix that
2014-06-11 19:54:08 <@muggs> 127::130 can go away, but they're harmless
2014-06-11 19:54:28 < Daemon404> they used to be needed iirc
2014-06-11 19:54:35 < Daemon404> i'd have to bump the required build #
2014-06-11 19:55:04 <@muggs> we support 4:2:0 now
2014-06-11 19:55:07 < Daemon404> and before you say, im aware it doesnt properly flush frames when it is fed less frams than delay
2014-06-11 19:55:15 < Daemon404> huh?
2014-06-11 19:55:23 < Daemon404> 420 support is right there
2014-06-11 19:55:42 < Daemon404> do you mean 422?
2014-06-11 19:56:36 <@muggs> sorry, yes
2014-06-11 19:58:12 < Daemon404> is it final in the hevc standard yt
2014-06-11 19:58:22 < Daemon404> or do i need to put it under experimental like i do for 444
2014-06-11 19:59:48 <@muggs> same boat as 444
2014-06-11 19:59:57 < Daemon404> ok
2014-06-11 20:00:26 < Daemon404> is there a build # it was introduced
2014-06-11 20:00:35 <@muggs> would is_keyframe() work better if we added a keyframe flag to the output picture?
2014-06-11 20:01:08 < Daemon404> if you added such a flag id just get rid of is_keyframe on the next version bump
2014-06-11 20:02:00 <@muggs> build 17
2014-06-11 20:05:04 < Daemon404> ok
2014-06-11 20:06:46 < Daemon404> [20:49] <@muggs> 127::130 can go away, but they're harmless <-- safe for 17 too?
2014-06-11 20:07:23 <@muggs> safe, but could be removed. x265_default_preset() initializes them to the only valid value
2014-06-11 20:07:50 < Daemon404> well i meant safe to remove
2014-06-11 20:07:58 <@muggs> yep
2014-06-11 20:08:03 < Daemon404> cool
2014-06-11 20:19:02 < Daemon404> muggs, so nothing obviously wrong?
2014-06-11 20:19:32 <@muggs> no; I suspect an issue in the way gpac is being used in this case
2014-06-11 20:19:40 <@muggs> trying to verify
2014-06-11 20:20:05 < Daemon404> ok
2014-06-11 20:31:10 <@muggs> yep, it was user error in this case. mp4box is very particular about file extensions
2014-06-11 20:31:23 < Daemon404> lol.
2014-06-11 20:32:47 < Daemon404> anyway i made the changes you recommended
2014-06-11 20:32:53 < Daemon404> patches in their respective MLs
2014-06-11 20:35:40  * JEEB will probably run a test tomorrow without RDOQ
2014-06-11 20:36:18 < Daemon404> hmmm doom9 is sitll down
2014-06-11 20:36:21 < Daemon404> bet they got hacked again
2014-06-11 20:36:28 < Daemon404> or the server in that dudes basement died
2014-06-11 20:36:31 < Daemon404> inb4 no backups
--- Day changed Thu Jun 12 2014
--- Day changed Fri Jun 13 2014
2014-06-13 14:15:06 < Daemon404> so, Tom gets the only +1 from me hell get, for using a WIlly Wonka clip
2014-06-13 22:54:03 < panthere> hi
2014-06-13 22:55:06 <@muggs> hello
2014-06-13 22:56:45 < panthere> the last tests about the codec are good ?
2014-06-13 22:59:36 <@muggs> in what context? you mean recent automated tests?
2014-06-13 23:01:24 < panthere> i'm just curious about the progress
2014-06-13 23:01:49 < panthere> the subjective feeling appreciation is the most important thing
2014-06-13 23:02:05 < panthere> more than technical data
2014-06-13 23:02:22 <@muggs> I'm not aware of any public encoder shoot-outs; most other HEVC encoders keep their results very private
2014-06-13 23:03:06 < panthere> so i wondered if we can divide by 2 the weight of video
2014-06-13 23:03:08 <@muggs> I think x265 is decent, but it still has a tendency to blur too much when bit constrained. that's where most of our focus is at today
2014-06-13 23:03:15 < panthere> as they say
2014-06-13 23:03:51 <@muggs> the larger the video, the more reduction is possible. 2x is sometimes feasible
2014-06-13 23:04:22 < panthere> we all hope and thx to u for all the work
2014-06-13 23:08:26 < panthere> not many hardware decoders for the moment   it will take several years to be adopted ?
2014-06-13 23:08:55 < Daemon404> some TVs have them
2014-06-13 23:08:56 < panthere> they wait a very good optimization of the codec  to design the circuit
2014-06-13 23:09:01 < Daemon404> most new high end smart tvs
2014-06-13 23:09:05 < Daemon404> but thats it so far
2014-06-13 23:09:07 < Daemon404> afaik
2014-06-13 23:09:40 < panthere> and the results Daemon404 ?
2014-06-13 23:09:43 < Daemon404> ?
2014-06-13 23:09:53 < Daemon404> WHO IS NUMBER ON
2014-06-13 23:09:53 < Daemon404> E
2014-06-13 23:09:58 < panthere> lol
2014-06-13 23:10:07 < panthere> it's the same
2014-06-13 23:10:12 < panthere> i suppose ?
2014-06-13 23:10:30 < panthere> just the colorimetry is different
2014-06-13 23:10:37 < panthere> and contrast
2014-06-13 23:10:42 < Daemon404> i guess nobody knows The Prisoner anymore
2014-06-13 23:10:51  * Daemon404 's witty references go to waste
2014-06-13 23:10:56 < Daemon404> well "witty"
2014-06-13 23:11:09 < panthere> i know "the prisoner"
2014-06-13 23:11:13 < panthere> bonjour chez vous
2014-06-13 23:11:34 < Daemon404> ;)
2014-06-13 23:11:46 < Daemon404> why would colorimetry be different?
2014-06-13 23:12:59 < panthere> the codec is just independant from the screen hardware
2014-06-13 23:13:59 < Daemon404> yes but im failing to follow your train of thouht
2014-06-13 23:14:01 < Daemon404> thought*
2014-06-13 23:14:14 < Daemon404> newer smart tvs do indeed have hevc decoders
2014-06-13 23:14:16 < panthere> I am not a number, I AM A FREE MAN!
2014-06-13 23:14:23 < Daemon404> and indeed support the 'new' colerimetry
2014-06-13 23:14:25 < Daemon404> i.e. bt2020
2014-06-13 23:14:50 < panthere> yes
2014-06-13 23:15:08 < panthere> but the even if the standard are the same
2014-06-13 23:15:38 < panthere> the tension applied to control the pixel
2014-06-13 23:16:00 < panthere> is not identical from a screen to another
2014-06-13 23:16:58 < panthere> just analogic nature of life againt the digital model for the simulation
2014-06-13 23:17:11 < panthere> against
2014-06-13 23:18:10 < panthere> i was clear ?
2014-06-13 23:18:56 < Daemon404> sort of
2014-06-13 23:19:04 < Daemon404> in a philosophical sort of way
2014-06-13 23:19:27 < Daemon404> (i get what youre getting at, but dont think its terrible relevant
2014-06-13 23:19:58 < Daemon404> muggs, you didnt have anything to do with the vp9 stuff did you?
2014-06-13 23:21:01 <@muggs> vp9 stuff?
2014-06-13 23:21:09 < Daemon404> the gpu crap
2014-06-13 23:21:10 < Daemon404> it was MCW
2014-06-13 23:21:12 < panthere> it's just the beauty of digital information
2014-06-13 23:21:43 <@muggs> no; that was a different team
2014-06-13 23:21:46 < Daemon404> ok
2014-06-13 23:21:50 < Daemon404> i didnt think so.
2014-06-13 23:21:59 < Daemon404> it's a ... mess to put it lightly.
2014-06-13 23:22:12 < Daemon404> readme is barely comprehensible, and references non-existed files
2014-06-13 23:22:16  * Daemon404 just failed to build it
2014-06-13 23:22:28 <@muggs> sigh
2014-06-13 23:22:53 < Daemon404> vp9 summit had me inspired to troll^Wtry vp9 gpu
2014-06-13 23:23:53 <@muggs> I get asked *all the time* why x265 doesn't have gpu support yet
2014-06-13 23:24:27 < Daemon404> muggs, last VDD, thierry (youtube guy) and I thought maybe it was a good idea to make a canonical page about *gpu encoding*
2014-06-13 23:24:38 < Daemon404> that we could blanket-paste to every single OMG GPU ENCODING email
2014-06-13 23:24:42 < Daemon404> we get
2014-06-13 23:24:45 < Daemon404> too bad im so lazy
2014-06-13 23:24:55 < Daemon404> (fyi vp9 is gpu *decoding*)
2014-06-13 23:25:19 < Daemon404> libvpx cant even multithread their encoder, good look GPU encoding
2014-06-13 23:25:26 < LigH> Hello
2014-06-13 23:25:27 <@muggs> yeah, decoders are a tad more GPU friendly; but still hard
2014-06-13 23:26:15 < Daemon404> its almost as if not every algorithm is embarassingly parallel
2014-06-13 23:26:19 < Daemon404> hard concept.
2014-06-13 23:27:52 <@muggs> I'd like to make CPU performance not suck before adding all the GPU complexity
2014-06-13 23:28:33 < Daemon404> youre doing better now than vanguard was when i tested (before i told them to take a hike)
2014-06-13 23:28:36 < Daemon404> speed-wise
2014-06-13 23:28:45 < Daemon404> not including the highest ME
2014-06-13 23:28:51 <@muggs> which preset?
2014-06-13 23:29:03 < LigH> Daemon404: Interested in a lost post?
2014-06-13 23:29:12 < Daemon404> LigH, no im the one who saw it already
2014-06-13 23:29:17 < LigH> OK.
2014-06-13 23:29:18 < LigH> GN8
2014-06-13 23:29:18 < Daemon404> also TheFluff already showed me your paste
2014-06-13 23:29:23 < LigH> :)
2014-06-13 23:29:30 <@muggs> I'm just now getting around to removing obviously wasteful things from the control flow
2014-06-13 23:29:38 < koda> Daemon404, well libvpx is sortof the reference encoder
2014-06-13 23:29:43 < koda> makes sense not to be threaded :p
2014-06-13 23:29:49 < Daemon404> the only encoder
2014-06-13 23:29:50 < Daemon404> and the spec
2014-06-13 23:29:53 < Daemon404> bug-for-bug
2014-06-13 23:29:59 < Daemon404> ffvp9 has // match bug in libvpx
2014-06-13 23:30:14 < Daemon404> muggs, slow and placebo
2014-06-13 23:30:15 < koda> oh there _is_ a spec then :D
2014-06-13 23:30:27 < Daemon404> that said, vanguard had a max of 4 or 5 refs and 4 bframes
2014-06-13 23:30:41 < koda> panthere, also 10 bit is going to be more popular and that should be nice indeed
2014-06-13 23:30:42 < Daemon404> koda, just like there is a .ass/.ssa spec
2014-06-13 23:30:44 < Daemon404> just read the code!
2014-06-13 23:31:02 < Daemon404> koda, supposedly tvs have main10 support
2014-06-13 23:31:27 < koda> yes it's a dvb/ebu  thing, i hope the us market will adopt it too
2014-06-13 23:31:36 <@muggs> many TVs can at least emulate 10bit depth with dithering
2014-06-13 23:31:42 < koda> instead of complaining about lack of interlace
2014-06-13 23:31:59 < Daemon404> muggs, remember also that most consumers have shitty 6-bit TN panels
2014-06-13 23:32:00 < Daemon404> for monitors
2014-06-13 23:32:01 < Daemon404> :D
2014-06-13 23:33:13 < koda> ugh
2014-06-13 23:34:43 <@muggs> it would be sweet to have 10bit 4k 60Hz (or 120Hz!) broadcast TV.  I'm not holding my breath for it
2014-06-13 23:35:18 < Daemon404> muggs, as if theyd ever drop the... drop framerates
2014-06-13 23:35:23 < Daemon404> 120/1.001!
2014-06-13 23:35:28 <@muggs> lol
2014-06-13 23:35:31 < panthere> yes 10 bits for the color i know  koda
2014-06-13 23:35:49 < panthere> for the 264 too
2014-06-13 23:35:55 < koda> Daemon404, they tried
2014-06-13 23:36:08 <@muggs> it might be a good excuse to make a new DVD format
2014-06-13 23:36:09 < Daemon404> koda, cool story: i have a real 24 fps blu-ray
2014-06-13 23:36:17 < Daemon404> as in produced at an integer framerate
2014-06-13 23:36:36 < koda> :O
2014-06-13 23:36:58  * koda wants it
2014-06-13 23:36:59 < Daemon404> made in japan
2014-06-13 23:37:07 < Daemon404> i had to order it through a address forwarding service
2014-06-13 23:37:16 < Daemon404> because they dont ship to filthy foriegn addresses
2014-06-13 23:38:42 < koda> i hope the bd content is good too :p
2014-06-13 23:39:18 < Daemon404> its interesting
2014-06-13 23:39:24 <@muggs> slightly more on-topic: I'm trying to get icpc to target a haswell PC; I build with -xCORE-AVX2 but the executable complains AVX2 or other haswell features are not supported.
2014-06-13 23:39:30 < panthere> but it doesn't change the pb for the output when the digital signal is translated into analog
2014-06-13 23:39:39  * koda waves
2014-06-13 23:39:41 <@muggs> do you need a "new" Linux kernel for AVX2 support?
2014-06-13 23:39:55 < Daemon404> as new as haswell maybe?
2014-06-13 23:40:06 < panthere> only good electronics will make the difference
2014-06-13 23:40:24 < Mandarinka> avx2 shoul donly require avx (ymm registers), no?
2014-06-13 23:40:26 <@muggs> this is Ubuntu LTS 12.04
2014-06-13 23:41:26 <@muggs> http://pastie.org/9287971
2014-06-13 23:41:36 <@muggs> I was curious if anyone else ran into this
2014-06-13 23:41:50 < Daemon404> koda, its a independent ova called hoshi ni negai wo
2014-06-13 23:41:57 < Daemon404> its trippy at times.
2014-06-13 23:42:21 < Mandarinka> oh, that's why.
2014-06-13 23:43:22 < Mandarinka> although there are also independent OAVs on DVD with clipped PC levels and bt709 (oh and gross haloing and fucked scaling that leads to all the lines being grossly aliased)
2014-06-13 23:43:29 < Mandarinka> :)
2014-06-13 23:43:31 <@muggs> x264 and x265 will use AVX2 assembly just fine, but icpc's binary balks
2014-06-13 23:43:32 <@muggs> Please verify that both the operating system and the processor support Intel(R) AVX2, BMI, LZCNT, HLE, RTM and FMA instructions.
2014-06-13 23:44:54 < Daemon404> muggs, dont intels tools generally come for specific distro versions
2014-06-13 23:44:57 < Daemon404> they usually have a list
2014-06-13 23:44:59 < Mandarinka> RTM - that is the transactional memory thing? That might need extra support.
2014-06-13 23:45:02 < Mandarinka> I would say
2014-06-13 23:45:26 <@muggs> yeah; might be RTM hanging it up
2014-06-13 23:45:43  * Mandarinka wonders why does it have a different name when all the prerelease docs called it TSX
2014-06-13 23:45:51 < panthere> someone tried the intel encoder for h265 ?
2014-06-13 23:52:10 < Mandarinka> Skylake next year is supposed to have a HW decoding/encoding for h.265 btw
2014-06-13 23:55:31 <@muggs> yeah
2014-06-13 23:58:41 < Mandarinka> oh, not news for you guys I guess
--- Day changed Sat Jun 14 2014
2014-06-14 00:01:26 <@muggs> QuckSync wasn't fatal to x264 in any sense but it does close a couple doors for MCW
2014-06-14 00:03:55 < Mandarinka> it helps though that Xeons don't have and many cut-down consumer cpus don't either
2014-06-14 00:04:41  * Mandarinka goes to bed
2014-06-14 00:04:43 < Mandarinka> gnight
2014-06-14 01:13:51 <@muggs> anyone interesting in scripting PGO for gcc/icpc for x265?
2014-06-14 01:33:19 < Daemon404> the only hard part is getting a set of x265 cli commands to run
2014-06-14 01:33:35 < Daemon404> other thanthat it just a matter of -fprofile-generate and -fprofile-us
2014-06-14 01:33:36 < Daemon404> e
2014-06-14 13:51:35 < shion_chk2> POWERRRRRRRRRR
--- Day changed Sun Jun 15 2014
2014-06-15 13:20:06  * muggs closes his LinkedIn account
2014-06-15 13:22:46 < Daemon404> muggs, too much spam?
2014-06-15 13:23:30 <@muggs> apparently friends of mine were getting "link requests" from me constantly, and I was never aware of it
2014-06-15 13:23:51 <@muggs> seems to be a deliberate policy: http://www.engadget.com/2014/06/13/linkedin-lawsuit-email-contacts/
2014-06-15 13:30:41 <@muggs>  LinkedIn's legal defense is apparently: it's not our fault users don't read the EULA
2014-06-15 13:31:04 < Daemon404> they are indeed pretty creepy
2014-06-15 13:36:34 < Mandarinka> silk road should have had an eula
2014-06-15 14:04:05 < Daemon404> man, this "Mapping of CRF between x265 and x264?" thread
2014-06-15 14:04:21 < Daemon404> does nobody understand simple analsysis methods
2014-06-15 14:04:31 < Daemon404> or basic statistics
2014-06-15 15:29:25 <@muggs> I admit I avoid d9 mostly to preserve my blood pressure
2014-06-15 15:32:54 < Daemon404> muggs, good choice
2014-06-15 15:33:07 < Daemon404> d9 occasionally spawns some good stuff
2014-06-15 15:33:12 < Daemon404> the rest of the time: deskface
2014-06-15 18:41:10 < Daemon404> muggs, i cant help but feel slightly insulted by tom's latest d9 post
2014-06-15 18:41:16  * Daemon404 wonders if he thinks people are that dumb
2014-06-15 18:48:19 < Daemon404> not insulted... just :V
--- Day changed Mon Jun 16 2014
2014-06-16 07:30:00 < j-b> 'morning
2014-06-16 17:18:55 < phc> good morning
2014-06-16 18:20:17 < Daemon404> +1 no hungarian
2014-06-16 18:23:45 < BugMaster> do you prefer camelCase?
2014-06-16 18:24:46 < Daemon404> i think 'psz' is pretty dumb in C.
2014-06-16 21:38:51 <@muggs> any french speakers still awake? http://linuxfr.org/users/elyotna/journaux/hevc-h-265-et-x265-mes-premiers-tests
2014-06-16 21:41:06 < Daemon404> i can motly read it
2014-06-16 21:41:13 < Daemon404> nothing interesting at all in it
2014-06-16 21:41:30 < Daemon404> unless you mean the comments
2014-06-16 21:42:03 < smarter> seems mostly positive
2014-06-16 21:42:19 < smarter> for x265 I mean :)
2014-06-16 21:42:29  * koda frowns at 720p24fps
2014-06-16 21:43:17 <@muggs> ok, thanks
2014-06-16 21:43:42 < Daemon404> lol the comments
2014-06-16 21:43:47 < Daemon404> someone mentions ogg tarkin
2014-06-16 21:43:49 < smarter> though subjective tests comparing different encoders at different bitrates doesn't mean much in general
2014-06-16 21:43:49 < Daemon404> and dirac
2014-06-16 21:44:05 < Daemon404> smarter, i think you mean "at all"
2014-06-16 21:44:25 < Daemon404> there's one guy on d9 doing something similar, and he Just Doesn't Get It
2014-06-16 21:45:09 < smarter> for the claim "2x smaller at the same quality!" it helps :p
2014-06-16 21:45:23 < smarter> even though x264 can be 2x smaller than itself at the ~same quality too
2014-06-16 21:45:51 < Daemon404> smarter, vp9 guys tried to sell us that too btw
2014-06-16 21:45:58 < Daemon404> as in the vp9 team.
2014-06-16 21:46:15 < Daemon404> ~marketing`
2014-06-16 21:46:17 < Daemon404> ~
--- Day changed Tue Jun 17 2014
--- Day changed Wed Jun 18 2014
2014-06-18 05:45:22  * muggs just reduced x265 memory consumption by about 40%
2014-06-18 06:14:50 < fionag> gosh, how does that work
2014-06-18 06:16:09 <@muggs> it was allocating a large data structure for every picture in the encoder, but it only really needed it when it was encoding or when it was a reference.
2014-06-18 06:16:28 <@muggs> so I made a small pool for them, voila
2014-06-18 06:17:28 <@muggs> another 10-15% will be trimmed next week, by using thread local storage
2014-06-18 06:20:18 < fionag> that sounds like what x264 did with 'fenc' and 'fdec' pictures
2014-06-18 06:20:28 < fionag> fenc being input/lookahead, fdec being reconstructed
2014-06-18 06:21:04 <@muggs> yeah, roughly.  I sum this up as: stop being as stupid as the HM
2014-06-18 06:21:27 <@muggs> we have a ways to go on that front
2014-06-18 06:23:57 < fionag> (note: x264 used to do the exact same terrible wasteful thing)
2014-06-18 06:40:55 <@muggs> hmm; we could do the same trick to the recon buffer
2014-06-18 06:41:24 < fionag> x264 keeps two separate pools, one of fdec pictures, one of fenc
2014-06-18 06:41:28 < fionag> since they have kinda totally different data structures
2014-06-18 06:49:27 <@muggs> that saved another 80MB for HD at medium; now an even 50%
2014-06-18 06:54:00 <@muggs> we have one pool for the main pic struct, then this second pool for the encode data that is attached to the pic while it is encoding
2014-06-18 16:37:22 < Daemon404> was anyone ever able to even run that hevc analyzer (the gitl one)
2014-06-18 16:41:43 < kierank> kept crashing on me
2014-06-18 16:50:40 < Daemon404> same
2014-06-18 16:51:37 < Daemon404> ended uo using the trial of elecard's thing
2014-06-18 21:13:07 <@muggs> I got it to work on Mac, sort of. It kept filling my hard-drive.  You can only use it on small clips
2014-06-18 21:20:04 < Daemon404> wow
2014-06-18 22:26:37 < kierank> I have not got anything to decode the 4K stream I got from someone
2014-06-18 22:26:45 < kierank> muggs: btw did you meet the parabola guy at ibc?
2014-06-18 22:26:58 < kierank> probably not because i remember he came late
2014-06-18 22:27:09 < kierank> tim did but I don't think you did
2014-06-18 22:27:09 <@muggs> no, I don't remember meeting him
2014-06-18 22:27:18 < kierank> nice chap
2014-06-18 22:28:00 <@muggs> the last day I could hardly walk anymore
2014-06-18 22:29:25 < kierank> Daemon404: let that be a warning to you if you end up going ^
2014-06-18 22:36:27 <@muggs> begging for money is hard work
2014-06-18 22:36:52 <@muggs> and IBC is gigantic
2014-06-18 23:03:16 < Daemon404> well..
2014-06-18 23:03:23 < Daemon404> time fr out of context quotes:
2014-06-18 23:03:29 < Daemon404> [23:21] < kierank> probably not because i remember he came late
2014-06-18 23:03:33 < Daemon404> [23:22] <@muggs> the last day I could hardly walk anymore
2014-06-18 23:03:40 < Daemon404> [23:31] <@muggs> begging for money is hard work
2014-06-18 23:04:42 < kierank> muggs: ah didn't know you had to do sales calls
--- Day changed Thu Jun 19 2014
2014-06-19 10:35:35 < kierank> http://www.enterprisetech.com/2014/06/18/intel-mates-fpga-future-xeon-server-chip/
2014-06-19 11:39:56 < smarter> interesting, shame that FPGA tools still suck though
2014-06-19 17:56:33 <@muggs> curious
--- Day changed Fri Jun 20 2014
2014-06-20 18:50:30 <@muggs> FYI: I will be on vacation all next week.
2014-06-20 22:12:22 <@muggs> is there a particular profile or level you're supposed to use for lossless coding?
2014-06-20 22:14:10 < Mandarinka> in H.264, yes, but since HEVC has that regular transform bypass, no idea
2014-06-20 23:19:31 < Daemon404> muggs, do you intend to apply satoshi's flush patch?
2014-06-20 23:19:40 < Daemon404> i am happy to fix it on the ffmpeg side
--- Day changed Sat Jun 21 2014
2014-06-21 01:15:34 <@muggs> Daemon404: already did; I suspect he needed the fix for however he uses libx265
2014-06-21 04:08:24 < panthere> hi
2014-06-21 11:24:41 < Daemon404> muggs, well he specifically mentioned ffmpeg ;)
2014-06-21 15:54:20 <@muggs> true, but I also thought his patch was cleaner than the flush mechanism already in the code
2014-06-21 19:05:45 < panthere> muggs
2014-06-21 19:06:55 < panthere> when will we have a good support with chips which physically decode h265 ?
2014-06-21 19:07:33 < Daemon404> i dont see why muggs would know about other companies plans
2014-06-21 19:08:38 < panthere> because
2014-06-21 19:08:47 < panthere> i ask an opinion
2014-06-21 19:08:56 < panthere> and not a truth
2014-06-21 19:09:11 < Daemon404> that wasnt clear from the wording
2014-06-21 19:10:09 < panthere> i just hope
2014-06-21 19:10:19 < Daemon404> fyi some smart tvs have h264 hw decoders
2014-06-21 19:10:51 < panthere> we have decoders on hardware cards or phones fastly
2014-06-21 20:10:04 < nevcairiel> Some new TVs for Japan already have H265 decoding because they want to broadcast it there soonish, but will be a while before it spreads globally
2014-06-21 20:10:54 < Daemon404> US tvs too
2014-06-21 20:10:56 < Daemon404> for netflix!
2014-06-21 20:11:00 < Daemon404> ~marketing`
2014-06-21 20:16:40 < panthere> sony as a main diffusor haven't yet implemented the solution in their hardware
2014-06-21 20:19:05 < Daemon404> samsung has i think
2014-06-21 20:19:27 < nevcairiel> Yeah
2014-06-21 20:19:32 < nevcairiel> And LG I think
2014-06-21 20:19:32 < Daemon404> although fun fact: 4k hevc on ther smartvs -- the power draw is in kilowatts
2014-06-21 20:19:37 < Daemon404> dats a lot of electricity
2014-06-21 20:19:58 < nevcairiel> Sounds like a software decoder
2014-06-21 20:20:04 < Daemon404> maybe
2014-06-21 20:20:08 < Daemon404> but thats still pretty big
2014-06-21 20:20:14 < Daemon404> hefty power bill
2014-06-21 21:32:46 < kurosu> samsung tvs were supposed to use an "evolution kit" but that was 1 year ago, so maybe the latest models have it now internal
2014-06-21 22:29:43 < panthere> [22:14] <Daemon404> although fun fact: 4k hevc on ther smartvs -- the power draw is in kilowatts
2014-06-21 22:29:51 < panthere> r u sure  Daemon404 ?
2014-06-21 22:30:08 < panthere> or is it just a joke ?
--- Day changed Sun Jun 22 2014
2014-06-22 10:24:29 < Mandarinka> <panthere> when will we have a good support with chips which physically decode h265 ? --- Intel Skylake will have decoding support, reportedly first chips are coming mid-2015
2014-06-22 10:24:51 < Mandarinka> those will be desktop processors, dunno about notebooks
2014-06-22 21:41:45 < phc> im going to south korea for a couple months
2014-06-22 21:41:55 < phc> ill be around
2014-06-22 21:42:09 < phc> meet w samsung n lg
--- Day changed Mon Jun 23 2014
2014-06-23 15:53:23 < JEEB> a bit old, but it seems like Range Extensions are getting finished \o/
2014-06-23 15:53:24 < JEEB> The proposed final draft of the range extensions text has been uploaded to
2014-06-23 15:53:24 < JEEB> the document repository as Q1005_v8:
2014-06-23 15:53:24 < JEEB>   http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=9096
--- Day changed Tue Jun 24 2014
--- Day changed Wed Jun 25 2014
--- Day changed Thu Jun 26 2014
2014-06-26 12:35:38 < Daemon404> oh lord
2014-06-26 12:35:44 < Daemon404> ipratio and pbratio are returning
2014-06-26 12:35:53 < Daemon404> i thought they finallied died
2014-06-26 12:37:05 < Mandarinka> why would they?
2014-06-26 12:37:25 < Mandarinka> x264 even uses them in some tunes IIRC
2014-06-26 12:38:30 < Daemon404> mostly cause of terriblt cargo culting
2014-06-26 12:42:16 < Mandarinka> that doesn't mean they should be disabled just due to that
2014-06-26 12:42:55 < Mandarinka> I think people cargocult other things anyway
2014-06-26 12:43:17 < Daemon404> ofc
2014-06-26 12:43:26 < Mandarinka> I've seen people that thought 1-pass ABR ended up looking better for their encodes
2014-06-26 12:43:28 < Mandarinka> for example
2014-06-26 12:43:34 < Daemon404> you must read doom9
2014-06-26 12:43:57 < Mandarinka> nope, that was in some random conversation
2014-06-26 12:44:29 < Daemon404> woosh.
--- Day changed Fri Jun 27 2014
2014-06-27 17:56:32 < oinooob> I think I have found a quite small sample file that displays "issues" with x265 severely and intermittently blurring unchanged areas. 1) is this a known issue, and 2) would there be any interest in such a sample file (~10MB MP42 AVI)?
2014-06-27 17:57:37 < oinooob> The "intermittent" part suggests a bug to me.
2014-06-27 21:10:40 < JEEB> hmm
2014-06-27 21:11:02 < JEEB> it seems like the cmake scripts aren't making the commit be rechecked
2014-06-27 21:12:03 < JEEB> I'm on 32aa6cc yet the build scripts think that b5fbe9e2a10a is fine as-is
--- Day changed Sat Jun 28 2014
2014-06-28 20:02:31 < Nosomy> testing x265 1.1+209
2014-06-28 20:02:40  * Nosomy »» Encoding »» ·x265· Progress..::5.5%::.. Speed..::6.07fps::.. Frames..::291/5302::.. Bitrate..::953.35kbps::.. Estimated..::0:13:44::..
2014-06-28 20:02:54 < Nosomy> default sets.
2014-06-28 20:20:44 < Baked_Cake> im pretty satified with the encodes im getting from ffmpeg
2014-06-28 20:21:05 < Nosomy> peak 6.35fps.
2014-06-28 20:21:16 < Nosomy> my cpu...
2014-06-28 20:21:23 < Nosomy> moo: cpu: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (x64) at 2501MHz (3% Load)
2014-06-28 20:21:36 < Nosomy> encoded finished.
2014-06-28 20:21:47 < Baked_Cake> i can do 3 fps on slow preset for 1080p
2014-06-28 20:22:17 < Nosomy> the samples is 1280x720p 30fps.
2014-06-28 20:22:26 < JEEB> I dunno about the faster presets, but I guess x265 is slowly getting better http://fushizen.eu/samples/hevc/hyouka/2014-06-28/
2014-06-28 20:22:45 < JEEB> it has some funky artifacts in some places, though. Not sure which is better, blocking or them
2014-06-28 20:23:53 < Baked_Cake> do i need to update something to see that other vid
2014-06-28 20:24:09 < JEEB> anything you play videos with? :P
2014-06-28 20:24:18 < JEEB> it's HEVC in mp4
2014-06-28 20:24:31 < JEEB> (now actually in the official way because the spec got finally released)
2014-06-28 20:24:34 < Baked_Cake> oh ya save link as
2014-06-28 20:25:53 < Nosomy> JEEB, official containers for hevc, which will it be?
2014-06-28 20:26:44 < JEEB> well MPEG-TS was the first to get standardized, and is now widely'ishly used for broadcast, 14496-15 3rd ed finally got finished and now we have HEVC in mp4, and HEVC in matroska pretty much copies the latter
2014-06-28 20:27:24 < Baked_Cake> didnt u say you 2-pass'd the x264 vid
2014-06-28 20:27:28 < Nosomy> thanks.
2014-06-28 20:27:47 < JEEB> Baked_Cake, to match the bit rate? standard procedure
2014-06-28 20:28:13 < Baked_Cake> wouldnt it be better to try to fine tune the crf
2014-06-28 20:28:24 < JEEB> shouldn't have a real effect to be quite honest
2014-06-28 20:29:04 < JEEB> there are some cases of very short high-res clips with high frame rate fucking up x264 rate control, but this doesn't really fit that bill now does it
2014-06-28 20:30:45 < Baked_Cake> u seem to have got about the same result i did when i tested but i adjust x264 crf to be a bit high bit rate
2014-06-28 20:31:38 < Baked_Cake> im pretty bad at spotting quality loss unless i pause and screenshot it
2014-06-28 20:33:52 < Baked_Cake> i was doing a reencode for the test tho
--- Day changed Sun Jun 29 2014
2014-06-29 00:02:39 < Baked_Cake> something im kinda crious on
2014-06-29 00:03:08 < Baked_Cake> when i encode a file with 9000 video bitrate at crf 23 it cuts it to an average of 10% the original
2014-06-29 00:03:36 < Baked_Cake> but when im doing a file at about 3000 bit rate it actually ends up larger
2014-06-29 00:04:13 < BugMaster> crf encoding do not know anything about what bitrate was your source
2014-06-29 00:05:06 < Baked_Cake> so it just based on the complexity of the video ?
2014-06-29 00:05:11 < BugMaster> you shouldn't compare bitrate of encoded sample with original compressed source. you better compare with decompressed source
2014-06-29 00:05:26 < BugMaster> yes. just complexity of video
2014-06-29 00:05:46 < Baked_Cake> ok makes sense now
--- Day changed Mon Jun 30 2014
2014-06-30 16:44:14 < muggs> JEEB: the version number recorded in the binary is only updated when cmake runs. it hasn't been enough of a problem yet for me to try and fix it.
2014-06-30 16:44:49 < JEEB> yeh, and the check that is done to check if it should be run doesn't check the hash I guess
2014-06-30 16:46:44 < muggs> yeah, it doesn't know it's out of date
2014-06-30 16:48:45 < JEEB> as you say, it's not much of a problem
--- Day changed Tue Jul 01 2014
2014-07-01 14:13:31 < Daemon404> muggs, some people claiming tip suddenly looks terrible
2014-07-01 14:20:16 < Daemon404> oh nvm, its the 1.1 rel
2014-07-01 15:47:03 < muggs> terrible relative to recent versions, or something else?
2014-07-01 16:45:56 < Daemon404> muggs, yeah
2014-07-01 16:46:00 < Daemon404> compared to 1.0
2014-07-01 16:47:28 < muggs> they might be finding the bug that was fixed on stable the day after release. dunno without more detail.
2014-07-01 16:47:40 < muggs> I hope to cut 1.2 by the end of this week
--- Day changed Wed Jul 02 2014
2014-07-02 08:32:07 < wh-hw> hi, how to set bit-depth to 8bit ?
2014-07-02 13:52:05 < j-b> 'morning
2014-07-02 18:36:03 < Daemon404> http://forum.doom9.org/showthread.php?t=170830
2014-07-02 18:36:41 < JEEB> interesting
2014-07-02 18:37:35 < nevcairiel> personally i think he is too optimistic about stuff being used as-is, at least ffmpeg/libav on the decoder side will never go for it (well, libav definitely not), and even if they would, more like copy-paste than integrate the lib
2014-07-02 18:37:55 < JEEB> ye
2014-07-02 18:39:29 < Daemon404> ofc
2014-07-02 18:44:55 < smarter> not sure how much stuff you can share really
2014-07-02 18:47:02 < smarter> unless everybody can agree on an interface
2014-07-02 18:47:55 < nevcairiel> well thats one of their assumptions, that many of the primitives would have a similar-enough interface anyway
2014-07-02 18:50:32 < smarter> well if you look at https://github.com/lu-zero/libav/commit/4ccd222243b22383c7a447f94c5a35af2f71868e for example, the MC dsp functions changed a lot
2014-07-02 18:51:02 < smarter> (I think mraulet told me the change was supposed to help with neon asm)
2014-07-02 18:51:50 < smarter> I doubt every other decoder/encoder use this particular design
2014-07-02 20:10:34 < muggs> we would need x264's permission to contribute our functions, since much of ours are based on their routines
2014-07-02 22:40:29  * muggs posts --lambda-file hack
--- Day changed Thu Jul 03 2014
2014-07-03 12:19:59 < wh-hw> hi, all, anybody build x265 success for android ?
2014-07-03 12:21:28 < Daemon404> is your aim to encode one frame in 4 days?
2014-07-03 16:31:47 < muggs> I did spend a bit of time to try to build x265 for raspbery-pi but its gcc would just crash on some files
2014-07-03 16:32:18 < muggs> didn't have time to build new cross-compilers
2014-07-03 23:37:30  * Daemon404 is having trouble seeing where muggs replied
2014-07-03 23:37:47 < Daemon404> garbled email
2014-07-03 23:37:48 < muggs> still?
2014-07-03 23:37:59 < muggs> I saw min's reply to me was a mess
2014-07-03 23:38:34 < Daemon404> your latest reply was... well i didnt see anything from you besides your footer
2014-07-03 23:38:47 < muggs> to Ashok's patch?
2014-07-03 23:38:53 < Daemon404> min's
2014-07-03 23:39:16 < Daemon404> https://mailman.videolan.org/pipermail/x265-devel/2014-July/004749.html
2014-07-03 23:40:06 < muggs> yeah, a mess.  my response was: "at some depths, it would be an up-shift, at others it would be a down-shift"
2014-07-03 23:40:21 < muggs> gmail, ftl
2014-07-03 23:41:01 < Daemon404> on that was in your previous reply
2014-07-03 23:41:13 < Daemon404> i dont know what min uses, but it mangles mails
2014-07-03 23:41:18 < Daemon404> insters replies in the quoted part
2014-07-03 23:41:23 < Daemon404> inserts*
2014-07-03 23:41:50 < muggs> I think he uses the Chinese front end to gmail, even though he's in the US now :)
2014-07-03 23:42:01 < Daemon404> nah...
2014-07-03 23:42:07 < Daemon404> it's 163.com's inhouse thing
2014-07-03 23:42:25 < Daemon404> X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140422(26738.6344) Copyright (c) 2002-2014 www.mailtech.cn 163com
2014-07-03 23:42:34 < muggs> nothing at all would surprise me
2014-07-03 23:42:51 < Daemon404> netcat server.com
2014-07-03 23:42:52 < Daemon404> HELO
2014-07-03 23:42:54 < Daemon404> ;)
2014-07-03 23:43:04 < muggs> heh
--- Day changed Fri Jul 04 2014
--- Day changed Sat Jul 05 2014
--- Day changed Sun Jul 06 2014
--- Day changed Mon Jul 07 2014
2014-07-07 18:28:35 < kierank> fionag_: what does this mcw guy want?
2014-07-07 18:29:07 < kierank> AGK Karunakaran
2014-07-07 18:45:43 < kierank> ah he wants to talk about x262
2014-07-07 18:46:20 < j-b> haha
2014-07-07 19:42:17 < kierank> ah these guys are x265
2014-07-07 19:42:18 < kierank> http://www.bbright.com/
2014-07-07 19:42:49 < j-b> x265?
2014-07-07 19:43:00 < kierank> using x265
2014-07-07 19:43:03 < j-b> oh, you mean they rewrite?
2014-07-07 19:43:07 < j-b> oh, rebox
2014-07-07 19:43:08 < kierank> http://x265.org/members.html
2014-07-07 19:52:21 < fionag> kierank: I think MCW wants to license x262 or something
2014-07-07 19:52:50 < fionag> they were bugging me to let them license x264 as well but I'm slightly nervous about that
2014-07-07 19:53:10 < fionag> plus it feels like a bad idea to let two companies compete in the same market for licensing the same software
2014-07-07 19:56:44 < kierank> Why is it a bad idea
2014-07-07 20:02:40 < fionag> it means that customers will probably call up both and try to see which gives them the lower price
2014-07-07 20:03:46 < kierank> But you set the price and profit margin
2014-07-07 20:04:10 < kierank> And then they compete
2014-07-07 20:04:13 < fionag> actually I kinda let corecodec set the prices
2014-07-07 20:05:28 < fionag> I'm not exactly a saleswoman so I don't think I'm really qualified to negotiate deals and prices and stuff
2014-07-07 20:07:29 < kierank> Is there any news about the dodgy marketing that corecodec were going to address
2014-07-07 20:08:35 < fionag> I think there was a followup a few weeks ago?   I'm really not sure, I haven't been keeping track of it all >_<
2014-07-07 20:09:23 < fionag> I thought that was at least partially resolved but I'm not sure
--- Day changed Tue Jul 08 2014
2014-07-08 02:45:01 < Baked_Cake> https://www.youtube.com/watch?v=E-8VI5rYqZo
2014-07-08 06:36:23 < mleise> I have a CoreDuo and while I heard that x265 is "impractically slow" I didn't know that means that x264 on veryslow with all features enabled, ref=16, bframes=16, rc-lookahead=101, me=umh is still 4x faster than x265 on medium. *g*
2014-07-08 06:37:15 < mleise> I guess that is mainly due to the explosion of options that have to be analyzed?
2014-07-08 06:39:53 < mleise> Oh and something I was wondering about: I heard that motion vectors can be encoded more efficiently in H.265. How was that achieved and does that mean for H.264, that using the correct motion vectors is often more costly than just directly coding a block?
2014-07-08 08:12:00 < fionag> mleise: it's that and lack of optimization; there's probably quite a lot to be gained with more efficient algorithms, asm, and so on!
2014-07-08 08:12:09 < fionag> x264 used to be quite a lot slower too.
2014-07-08 08:12:36 < fionag> motion vectors wise, I think mainly the prediction is a bit better?  I haven't looked at how h265 codes them exactly though
2014-07-08 08:17:00 < mleise> I think optimizations can improve speed a bit (maybe 10-20%), but the real benefits probably come from early-out heuristics.
2014-07-08 08:23:02 < mleise> Still, I'd like to know if someone found a clever trick to save on bits for motion vectors. Some earlier attempts like full-scene motion more or less weren't worth their complexity. Xvid seems to use the movement of three points in the video to recreate full screen pan, rotate and skew. I never tried that one though and now the tech is somewhat behind. Everytime I see flat static background move like jelly I know it is Xvid.
2014-07-08 08:27:41 < fionag> the warp-point-based GMC xvid used didn't turn out to be very good from what I recall
2014-07-08 08:28:14 < fionag> I remember hearing that the main benefit came from the fact that mpeg-4 part 2 didn't have a very good skip mode, and 1 warp mode was enough to sorta-compensate in scenes with a global motion vector
2014-07-08 08:28:30 < fionag> but that adding in a proper skip mode in h264 made the benefit go away?
2014-07-08 08:30:08 < fionag> looking at the code, h265 seems to do sorta a combination of things different from h264, if I'm reading it right
2014-07-08 08:30:49 < fionag> the mvp-generating function generates multiple predictors and has a cabac flag to pick between the two best ones
2014-07-08 08:31:22 < fionag> it also has the merge flags, which I think are basically "use the same mv as left/top partition"?
2014-07-08 08:31:40 < mleise> fionag: wasn't that part of H.264 already?
2014-07-08 08:31:46 < fionag> which bit?
2014-07-08 08:31:52 < mleise> using spacial or temporal mvs
2014-07-08 08:32:06 < mleise> based on either top/left or previous frame, but same position
2014-07-08 08:32:12 < fionag> that's for b-frame direct/skip mode, not all MVs
2014-07-08 08:32:37 < fionag> direct/skip mode didn't actually affect MV prediction, it only affected the MV chosen for skip blocks, I think
2014-07-08 08:33:04 < fionag> it also looks like mv deltas are coded kinda simply, basically just a flag for "is the delta 0, 1, or bigger, and the rest gets bypassed
2014-07-08 08:34:15 < mleise> maybe that 0 or 1 special casing is the benefit h265 has over h264 :p
2014-07-08 08:34:44 < fionag> h264 has that and more ^^;
2014-07-08 08:35:24 < mleise> ok, so motion vectors are really coded the same way
2014-07-08 08:35:59 < fionag> yeah, the actual deltas are coded similarly. I remember reading that h265 was trying to cut down on the number of cabac contexts for some reason, and they found that certain things could be bypassed entirely with a low enough compression loss that they could get away wit it?
2014-07-08 08:36:05 < fionag> and I think mvs were one of those things
2014-07-08 08:37:03 < fionag> so I totally wouldn't be surprised if cabac was actually worse for some things in h265, albeit not by huge margins
2014-07-08 08:39:41 < mleise> thx, for clearing that up for me. now i can't spread ignorant fud about x265 any more
2014-07-08 08:40:04 < fionag> but like, more prediction options can totally be a big gain. I guess I'd normally consider that "more interesting" than messing with the delta coding
2014-07-08 08:40:18 < fionag> so I wouldn't say "h265 doesn't have better mv coding than h264" at all!
2014-07-08 08:46:23 < fionag> (and gosh, they probably tested it quite well, I don't doubt it's better)
2014-07-08 15:59:49 <@muggs> as far as I know, mvd coding hasn't changed, but the subpel interpolation changed a lot
2014-07-08 16:00:23 <@muggs> and there are fewer cabac contexts - the reason I heard was to simplify hardware
2014-07-08 16:00:37 < Daemon404> hardware is why we cant have nice things
2014-07-08 16:09:30 <@muggs> I think the main reason for the performance difference is the quad-tree; there's just a lot more ways to code each block that have to be evaluated, particularly at the slow presets which use no early outs.
2014-07-08 16:16:31 <@muggs> intra/inter/merge(skip) decisions have to be made for every CU at every depth from 64x64 to 8x8, then 8x8 intra might chose to use 4x4 intra PUs.  Then after making coding/prediction (cu QT) decisions you have to make residual quad-tree decisions, to possibly further split the RQT beyond the cu QT depth to pick smaller transform units (recursively)
2014-07-08 16:34:06 <@muggs> http://www.telestream.net/pdfs/whitepapers/wp-HEVC.pdf  (just posted this morning, I had no hand in it)
2014-07-08 16:47:28 < kierank> "This approach was used extensively in Telestream’s
2014-07-08 16:47:28 < kierank> implementation of the x264 codec.
2014-07-08 16:47:29 < kierank> lol
2014-07-08 16:52:22 < Daemon404> :telestream:
2014-07-08 17:00:03 <@muggs> they can't help themselves.. notice MCW isn't mentioned either, heh
2014-07-08 17:30:48 < mleise> hmm, is this a company that blows up its importance on x264?
2014-07-08 17:31:34 < mleise> 50% reduction in bit rate every ten years? good luck :p
2014-07-08 17:33:05 < mleise> H.264: 8 search directions... do they refer to predictors? because with "tesa" the search directions are unbounded, right?
2014-07-08 17:35:59 < mleise> hmm, they refer to intra frames, so I'm likely just ignorant to how the codecs work. actually my knowledge stops after MJPEG.
2014-07-08 17:41:41 < kierank> they call intra a "search"
2014-07-08 17:41:43 < kierank> mleise: yes
2014-07-08 17:44:35 < mleise> kierank: Do you know what mb-tree means? I see they check where a macroblock is reused in subsequent frames, but why the tree structure instead of a list?
2014-07-08 17:44:55 < kierank> fionag wrote a paper about it once
2014-07-08 17:50:42 < mleise> Damn the open source community has been "utilized"!
2014-07-08 17:52:34 < mleise> In all fairness though, it is good to have company backing. I see that with programming languages. D is evolving slowly and steadily but as soon as Apple mentions they create a new language it is all the hype.
2014-07-08 18:04:12 < Daemon404> D shot itself in the foot multiple times
2014-07-08 18:04:18 < Daemon404> by making more than one stdlib
2014-07-08 18:04:20 < Daemon404> some with GC
2014-07-08 18:04:22 < Daemon404> some without GC
2014-07-08 18:04:35 < Daemon404> (also its community is a tad stuck up its own butt)
2014-07-08 18:51:25 < mleise> Daemon404: stuck up its own butt, eh? how do you mean that? i think there was always a GC involved in both "Tango" and "Phobos". It has been solved by extracting a basic runtime so Tango can be used on top of the official Phobos library. but people who have been with D for a long time have bad memories of the split, you are right.
2014-07-08 18:55:57 < Daemon404> mleise, the vocal bit of people who will not shutup about how Great and Amazing and Productive D is
2014-07-08 18:57:35 < mleise> ah, I call them enthusiasts
2014-07-08 18:57:56 < Daemon404> i call them the mormons of programming
2014-07-08 18:58:13 < Daemon404> do you have a moment to talk about jesus christ^W^WD?
2014-07-08 19:00:54 < mleise> well, there are now companies making millions with a code base in that programming language. it sorely lacks good GUI options though, so the commercial adoptions are usually in the backend computation area.
2014-07-08 19:12:18 < fionag> mleise: I can try to explain mbtree-ish stuff if you need
2014-07-08 19:15:00 < mleise> No I don't need that info. I'm just trying to educate myself a bit about the different flags, that I can enable in the command-line.
2014-07-08 19:15:29 < mleise> I still wonder why --aq-strength=1.6 --psy-rd=1:6 works so well, but that's another story :p
2014-07-08 19:15:32 < Daemon404> mleise, i am personally enjoying Go at work.
2014-07-08 19:15:36 < Daemon404> with its FFI
2014-07-08 19:15:44 < p0nce> Daemon404: I'm exactly as you describe, guilty as charged. However, D really is amazing and make your skin healthier :)
2014-07-08 19:16:12 < Daemon404> is tooling still terrible
2014-07-08 19:16:28 < Daemon404> docs too
2014-07-08 19:16:57 < p0nce> if you come from Java or Go it's less good, if you come from C++ it's similar
2014-07-08 19:17:08 < Daemon404> im a C guy
2014-07-08 19:17:32 < p0nce> well I'm not aware of the state of C
2014-07-08 19:17:49 < Daemon404> It Depends On The OS
2014-07-08 19:18:15 < Daemon404> my only gripe about go is the authors weird crusade against syntax hilighting
2014-07-08 19:18:23 < Daemon404> and love of ACME
2014-07-08 19:19:00 < Daemon404> they privde syntax stuff for vim, and thats enough for me i guess
--- Day changed Wed Jul 09 2014
2014-07-09 02:28:37 <@muggs> what does one use as a mega debugger when valgrind crashes?
2014-07-09 02:40:20 < fionag> prayer, I think
2014-07-09 02:46:30 <@muggs> awesome
2014-07-09 02:47:03 <@muggs> does yelling at the ceiling count?
2014-07-09 02:48:47 < fionag> if valgrind is crashing on good code (i.e. before it gets to the bad code), I'm not sure what to do
2014-07-09 02:49:00 < fionag> if it's crashing on stuff related to the thing you're trying to solve, you could try using the valgrind.h header to explicitly check things manually
2014-07-09 02:49:05 < fionag> like, to try to get some results printed out before it explodes
2014-07-09 02:50:39 <@muggs> I have a repro case that takes 17k frames to cause a crash, I've normal debug builds - no problems found, I've tried clang -fsanitize=address and it finds no problems
2014-07-09 02:51:04 < fionag> it's consistent though, right?  does it require threads or anything?
2014-07-09 02:51:06 <@muggs> I run valgrind, it goes 13 frames, then aborts with an internal error before reporting any problems
2014-07-09 02:51:24 < fionag> is it an error related to a particular instruction set or something?  or is it just like a generic kaboom
2014-07-09 02:51:33 <@muggs> I've never actually caused it to crash myself, I just received a couple of core dumps
2014-07-09 02:52:00 <@muggs> it appears to be a stack corruption which leads to an invalid pointer and SIGSEGV
2014-07-09 02:52:37 < fionag> does it still crash with asm off?
2014-07-09 02:52:43 <@muggs> the folks who reported it are sending me an HD with the clip
2014-07-09 02:53:01 <@muggs> they're testing that now.. told me it would be done in about another day from now
2014-07-09 02:53:12 <@muggs> :)
2014-07-09 02:53:14 < fionag> eeeesh
2014-07-09 02:53:26 < fionag> that sounds possibly worse than the worst long-time-to-error x264 bugs I've had to go after
2014-07-09 02:53:48 < fionag> like the heisenbug that almost never happened except with a certain number of threads on a certain windows machine, in which case it deadlocked
2014-07-09 02:54:17 <@muggs> I had high hopes for clang, but it found nothing
2014-07-09 02:55:30 <@muggs> heisenbugs are my favorite.
2014-07-09 02:56:08 < fionag> (the problem was accidentally accessing a single value outside of a mutex)
2014-07-09 02:56:25 <@muggs> I can tell we have some sort of a bug somewhere, about once a week we'll get a report of non-determinism from our automated tests... all outputs are valid, but something is changing
2014-07-09 02:56:38 < fionag> yeah, those can be incredibly hard to find >_<
2014-07-09 02:56:41 <@muggs> ugh
2014-07-09 02:57:49 <@muggs> earlier, all the really crazy bugs were Windows only.  Now the really interesting ones are Mac or Linux only
2014-07-09 03:02:28 <@muggs> oh yeah, I tried gcc -fmudflap as well but sadly its C++ support is almost nonexistant
2014-07-09 10:12:02 < smarter> muggs: depending on how desperate you are, you might give http://rr-project.org/ a try
2014-07-09 11:29:46 < Daemon404> intels thread thing is pretty good too
2014-07-09 11:30:28 < Daemon404> tsan maybe too?
2014-07-09 14:57:51 < kierank> smarter: gdb also has record
2014-07-09 15:05:06 < smarter> yeah but that's unusably slow
2014-07-09 15:05:14 < Daemon404> ... and rr isnt?
2014-07-09 15:05:19 < Daemon404> rr is just unusable
2014-07-09 15:05:20 < Daemon404> =p
2014-07-09 15:05:25 < smarter> well it was developed for Firefox
2014-07-09 15:05:39 < Daemon404> mozilla isnt known for their user-friendly dev tooling
2014-07-09 15:05:40 < smarter> it looks hard to use yeah
2014-07-09 15:05:43 < Daemon404> building firefox is lulz
2014-07-09 17:36:01 < kierank> smarter: i have used record in the past for small sections
2014-07-09 17:55:14 <@muggs> well, apparently with --no-asm run crashed in roughly the same place; so that rules out one class of problem
--- Day changed Thu Jul 10 2014
2014-07-10 09:13:43 < BugMaster> muggs: wrong mailing list for x265 1.2 released anouncement
2014-07-10 15:17:52 < j-b> good morning
2014-07-10 17:49:52 <@muggs> BugMaster: doh!
2014-07-10 17:53:25 <@muggs> it's time to get my glasses checked
--- Day changed Fri Jul 11 2014
2014-07-11 10:44:04 < jocadel> When running "make install" under msys (Win, mingw), libx265.dll is NOT installed into bin/ and has to be copied manually. Is this a known bug?
2014-07-11 17:15:49 <@muggs> too bad jocadel left - I wanted to ask if he was building from a tar ball
2014-07-11 18:19:53 <@muggs> I've got an interesting problem, curious about opinions
2014-07-11 18:20:40 <@muggs> when you're encoding at near lossless bitrates, you get gigantic increases in SSIM by enabling --cu-lossless (almost 2x SSIM in some cases)
2014-07-11 18:21:10 <@muggs> --cu-lossess makes the encoder evaluate trans-quant bypass modes
2014-07-11 18:21:40 <@muggs> if you're not in near-lossless bitrates, it makes the encoder ~2x slower for no benefit
2014-07-11 18:21:44 < Daemon405> not sure what "trans-quant bypass modes" is
2014-07-11 18:21:49 < Daemon405> is that like PCM blocks?
2014-07-11 18:21:58  * Daemon405 should read spec
2014-07-11 18:22:02 <@muggs> PCM but with residual not source
2014-07-11 18:22:25 < Daemon404> ah ok
2014-07-11 18:22:26 <@muggs> so you do intra/inter/merge predictions, get residual, then code that without DCT or quant
2014-07-11 18:23:18 <@muggs> when --cu-lossless is enabled, we can get nice bitrate/ssim curves that get right up to the --lossless results
2014-07-11 18:23:24 < Daemon404> i always thought PCM blocks were weird like that
2014-07-11 18:23:49 < Daemon404> (as in my not pred it)
2014-07-11 18:23:49 <@muggs> we've ripped out PCM support from x265 since they're mostly usless
2014-07-11 18:24:14 < Daemon404> did h264 even have such a block?
2014-07-11 18:24:17 < Daemon404> i dont recall one
2014-07-11 18:24:23 < JEEB> yes
2014-07-11 18:24:27 < JEEB> PCM coding was in AVC as well
2014-07-11 18:25:02 <@muggs> anyway; my problem is that I would like to make --cu-lossless "automatic" for slow presets (maybe medium and below). so it would turn itself on if slice QP was less than some threshold
2014-07-11 18:25:33 < Daemon404> JEEB, no not what i meant
2014-07-11 18:25:43 < Daemon404> i meant h264 didnt have a predicted version
2014-07-11 18:25:47 < Daemon404> PCM is not predicted
2014-07-11 18:26:11 < Daemon404> muggs, should it be based on bitrate too
2014-07-11 18:26:14 < Daemon404> or crf val
2014-07-11 18:26:16 < Daemon404> shouldnt*
2014-07-11 18:26:29 <@muggs> my understanding was that AVC had trans-quant bypass, but it was global
2014-07-11 18:26:54 <@muggs> I think x264 --qp 0 turned it on
2014-07-11 18:27:59 < kurosu> I'd think --qp 0 turned on PCM, while lossless coding is another AVC profile altogether
2014-07-11 18:28:15 < JEEB> uhh
2014-07-11 18:28:18 < kurosu> transform bypass is mostly meant for non-natural content (ie strong residual)
2014-07-11 18:28:27 < JEEB> qp 0 _is_ lossless with x264
2014-07-11 18:28:33 < kurosu> ok
2014-07-11 18:28:34 < JEEB> and no, I don't think it can even code PCM blocks
2014-07-11 18:28:41 < JEEB> because they're so useless
2014-07-11 18:29:03 <@muggs> the problem with automatic --cu-lossless is that "trans-quant bypass" must be enabled in the PPS before this flag can be signaled in the CU.
2014-07-11 18:29:10 < Daemon404> JEEB, x264 does have pcm blocks
2014-07-11 18:29:17 < JEEB> orly?
2014-07-11 18:29:45 <@muggs> and having it enabled when --cu-lossless is in auto mode is wasteful if the encode is not near-lossless.
2014-07-11 18:29:57 < Daemon404> JEEB, yes.
2014-07-11 18:32:48 <@muggs> so I either need to emit new PPS each time "auto" enables or disables --cu-lossless eval based on the slice QP; or I need to make a guess right at the beginning about whether to have it enabled in PPS or not. or I punt and just document this
2014-07-11 18:33:25 < Daemon404> wouldnt the new pps make some containers kind of annoying to use (if at all)
2014-07-11 18:36:18 <@muggs> possibly; we could probably only change it on keyframes if at all
2014-07-11 18:37:07 <@muggs> that's kind of what I'm curious about, is it generally kosher to change stream headers ourselves?
2014-07-11 18:37:23 < nevcairiel> the answer is "depends"
2014-07-11 18:39:49 <@muggs> if the answer is "not always" then I should just avoid this whole train of thought
2014-07-11 18:39:55 < fionag_> muggs: ah, trans-quant bypass wastes bits if it isn't used, unlike h264?
2014-07-11 18:40:28 <@muggs> the PPS trans-quant flag enables per-CU signaling of the mode
2014-07-11 18:41:37 < fionag> ah
2014-07-11 18:41:42 < fionag> so it's not like "let's make it qp 0" in h264
2014-07-11 18:41:51 <@muggs> SSIMs can jump from mid-30s to mid-60s when it's enabled
2014-07-11 18:42:04 <@muggs> at 1/2 the encode speed )
2014-07-11 18:42:24 < fionag> x264 didn't support mixed lossy/lossless -- does it help in x265 at sane bitrates?
2014-07-11 18:42:38 <@muggs> fionag: right, in order to make it full lossless, you have to then code every CU (with residual) with this flag set to 1
2014-07-11 18:42:59 < kurosu> transform bypass helps for screen content
2014-07-11 18:43:15 <@muggs> it only helps in x265 at pretty low QPs (less than 8)
2014-07-11 18:43:34 < Daemon404> kurosu, wouldnt PCM help just as much for screen content (flat blocks)
2014-07-11 18:43:52 < kurosu> pcm aren't quantized by definition?
2014-07-11 18:43:57 < kurosu> *pcm blocks
2014-07-11 18:43:58 <@muggs> there is a separate transform-skip for 4x4 intra blocks that doesn't have to be enabled in PPS
2014-07-11 18:44:17 < Daemon404> i idnt think transquant-bypass was quantizedd for some reason
2014-07-11 18:44:23 < kurosu> yes
2014-07-11 18:44:25 <@muggs> that's our --tskip option
2014-07-11 18:44:43 < kurosu> but transform bypass/skip and transquant bypass are 2 separate things
2014-07-11 18:45:02 < Daemon404> with terrible names
2014-07-11 18:45:31 <@muggs> btw: apparently in HEVC only --qp 4 is actually lossless quant
2014-07-11 18:45:33 < nevcairiel> transquant bypass sounds like scifi
2014-07-11 18:47:52 < kurosu> I wonder how transquant bypass fares on touhou-like sequences
2014-07-11 18:48:04 < kurosu> *transform skip
2014-07-11 18:48:11 < kurosu> gah, I'm also getting confused myself
2014-07-11 18:48:57 <@muggs> you have to use a preset that tends to code intra blocks that small - otherwise tskip is rarely used
2014-07-11 18:49:36 < kurosu> fionag, does x264's --qp 0 uses a lossless profile or is it only for some chroma formats like 4:4:4 (can't recall) ?
2014-07-11 18:50:09 < kurosu> muggs, transform skip is a waste of time most of the time
2014-07-11 18:50:14 < kurosu> for natural content at least
2014-07-11 18:50:30 < kurosu> but I was wondering for more CGI or graphical content like games
2014-07-11 18:50:59 < kurosu> *muggs, I agree, transform skip is a...
2014-07-11 18:55:46 < fionag> it uses a lossless profile
2014-07-11 19:01:47 <@muggs> HEVC doesn't have a lossless profile, that I know of
2014-07-11 19:03:13 <@muggs> is trans-quant bypass signaled by the lossless profile, in AVC?
2014-07-11 19:07:45 < fionag> it's signalled by *three* things, actually
2014-07-11 19:07:59 < fionag> 1) the main thing, setting the header bit, means "qp 0 means lossless"
2014-07-11 19:08:10 < fionag> so setting that bit turns all "qp 0" blocks into lossless blocks
2014-07-11 19:08:40 < fionag> 2) that bit cannot be set without a compatible profile (otherwise it's illegal), so you need the profile to be set to a compatible one.  most don't support it.
2014-07-11 19:08:56 < fionag> 3) of course, the final part, setting the qp of the blocks you care about to 0!
2014-07-11 19:19:17  * muggs reviews two-pass patches
2014-07-11 19:25:54 <@muggs> is there a particular reason x264's param2string uses underscores and param_parse converts them to dashes?
2014-07-11 19:27:47 < fionag> I have noooo idea.  it was definitely like that when I first looked at the code
2014-07-11 19:28:00 < fionag> it's quite possible it's like that because it was like that.
2014-07-11 19:28:02 < fionag> with no good reason
2014-07-11 19:28:22 < fionag> maybe check the git history?
2014-07-11 19:33:55 <@muggs> I thought the _ to - conversion would make option passing in ffmpeg less dangerous, but I see nothing useful in making param2string use _
2014-07-11 20:10:44 <@muggs> someone on doom9 pointed out we're not emitting our encode parameters or identifying ourselves in an SEI.  How relatively important is that?
2014-07-11 20:11:50 < fionag> in my experience it's -super- convenient for debugging and tech support
2014-07-11 20:11:59 < fionag> plus it's nice to have an easy way to spot x265 streams
2014-07-11 20:12:07 < fionag> I'd highly recommend it
2014-07-11 20:14:01 <@muggs> we currently don't have anything equivalent to 'configure --disable-gpl' because there is nothing GPL to disable. I imagine we'd need to add something to detect commercial licensees if we emit this SEI?
2014-07-11 20:14:44 < fionag> you don't -have- to, but it's an option
2014-07-11 20:15:07 < fionag> x264 doing that was mostly an excuse to write code that looked like 'GPL?"left":"right"'
2014-07-11 20:15:17 <@muggs> lol
2014-07-11 20:15:50 <@muggs> I thought it was a backwards way to ensure your licensees were building it appropriately
2014-07-11 20:16:10 < fionag> basically someone (I forgot who?) showed me that code and I couldn't help but commit it
2014-07-11 20:18:46 <@muggs> ok
2014-07-11 20:19:27 < fionag> basically I suggest putting anything remotely useful for tech support in the SEI because it's -so nice- to be able to figure out what someone is doing from the output stream
2014-07-11 20:19:40 < fionag> since a) asking people is extra work b) those people might be mistaken about what they're doing
2014-07-11 20:19:46 < fionag> e.g. their code calling x265 is broken
2014-07-11 20:20:01 < fionag> a super common case is the parameters they're actually using -aren't- what they think they're using, which makes debugging and support hard
2014-07-11 20:20:10 < fionag> but the SEI magically tells you what's actually happening.
2014-07-11 20:23:51 <@muggs> right.. moving that up on my TODO list
2014-07-11 20:29:25 < fionag> I'd note the one case an SEI doesn't save you is when they're making heavy use of encoder reconfiguring
2014-07-11 20:30:06 < fionag> relatedly -- if you think it's a good idea, you could try to sneak in a watermark like x264's, assuming H.265 lets you get away with the same kind of thing
2014-07-11 20:30:40 < JEEB> I don't think that part changed
2014-07-11 20:30:44 < JEEB> if it's what I think it is
2014-07-11 20:30:53 < JEEB> (the thing that is brought up on doom9/ML every now and then)
2014-07-11 20:31:13 < JEEB> so it should be possible to do the same thing
2014-07-11 20:40:58 < fionag> it's what you think it is ^^
2014-07-11 20:41:39 < JEEB> ( ^_^)b
2014-07-11 20:43:39  * koda <3 SEIs
2014-07-11 21:08:37 <@muggs> the watermark is also on my TODO list
2014-07-11 21:10:50 <@muggs> if I was smart, I would have snuck it in in that last CABAC refactor
2014-07-11 21:32:19 < fionag> also, since H.265 doesn't have CAVLC (right?), the watermark won't be able to be turned off
2014-07-11 22:07:47 <@muggs> right, no CAVLC
2014-07-11 22:08:45 <@muggs> http://forum.doom9.org/archive/index.php/t-161694.html
2014-07-11 22:09:04 <@muggs> the 'user data SEI' in HEVC has this guid field
2014-07-11 22:09:13 <@muggs> should I make one up for x265?
2014-07-11 22:11:24 < fionag> I think so?  I remember pengvado saying he made one up according to the GUID guidelines
2014-07-11 22:11:37 <@muggs> createguid.com?
2014-07-11 22:12:38 < fionag> I think it's just a randomly generated 128-bit field?  I'm not sure
2014-07-11 22:12:55 < Daemon404> "Be creative. Tweet this GUID."
2014-07-11 22:12:59 < Daemon404> really?
2014-07-11 22:13:16 <@muggs> someone was bored
2014-07-11 22:14:04 <@muggs> ah, I see it in x264_sei_version_write
2014-07-11 22:14:07 < koda> maybe h266 will have tweets instead of SEIs
2014-07-11 22:14:17 < fionag> (presuming it's the same as in H.264)
2014-07-11 22:15:37 <@muggs> yeah, it looks like it is
--- Day changed Sat Jul 12 2014
