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

[burek]

[00:05:44 CEST] <iive> why on the topic of ryzen - http://i.imgur.com/KPE7E0s.jpg
[00:06:37 CEST] <iive> while
[00:06:52 CEST] <Compn> lol that graph
[00:07:00 CEST] <Compn> such a big difference for 1 fps more LOLOLOL
[00:07:07 CEST] <iive> :}
[00:07:14 CEST] <jamrial> is that a parody?
[00:07:18 CEST] <Compn> who made that, hilarious
[00:07:18 CEST] <iive> no
[00:07:26 CEST] <Compn> fractional fps hahahaha
[00:07:31 CEST] <TD-Linux> I'm really interested to see some windows vs linux benchmarks of threadripper. the one I was able to find makes threadripper look a little better https://www.computerbase.de/2017-08/amd-ryzen-threadripper-test-1950x-1920x/3/#diagramm-gesamtrating-linux
[00:07:33 CEST] <jamrial> someone published that as part of a review?
[00:07:49 CEST] <TD-Linux> I suspect it's going to be heavily reliant on the NUMA scheudler
[00:07:55 CEST] <iive> it's from Techradar article, and they have changed it already.
[00:08:45 CEST] <nevcairiel> thats what happens if you let your tools generate the images for you :p
[00:26:37 CEST] <rcombs> iive: Compn: gdi truncated bar graphs ought to be illegal
[00:27:05 CEST] <iive> yeh
[00:27:33 CEST] <rcombs> at the very least ones without an indication of the truncation
[00:27:48 CEST] <rcombs> you know the thing I'm talking about, the wavy-line mark on the graph axis near the bottom
[00:27:53 CEST] <nevcairiel> that one has the range clearly mentioned!
[00:28:16 CEST] <rcombs> in text, though, not graphically
[00:28:59 CEST] <iive> some time ago there was an article, that showed all kinds of graph tricks. not starting from zero, or using 2 different scales in the same image...
[00:29:21 CEST] <iive> all things to mislead the eye, before the brain can get the raw data.
[04:30:30 CEST] <cone-065> ffmpeg 03Davinder Singh 07master:1939b9030642: avcodec/mjpegenc: disable unused code with AMV
[04:30:30 CEST] <cone-065> ffmpeg 03Davinder Singh 07master:4116b2b136f5: avcodec/mjpegenc: cosmetic changes
[11:01:05 CEST] <JEEB> interesting
[11:01:14 CEST] <JEEB> so AVFrame doesn't have AVMEDIA_TYPE set to it?
[11:01:20 CEST] <JEEB> you have to find it out from the context?
[11:05:26 CEST] <nevcairiel> usually AVFrames don't really mix in the same API so you should really always know
[11:06:47 CEST] <nevcairiel> avutil checks width/height for video frames, a nd nb_samples for audio frames
[11:06:56 CEST] <nevcairiel> if you really want some rule to check =p
[11:09:58 CEST] <JEEB> :D
[11:10:06 CEST] <JEEB> thankfully I have the AVCodecContext around
[11:10:10 CEST] <JEEB> or well, nearby
[11:11:57 CEST] <wm4> av_frame functions "infer" the media type by checking certain fields
[11:12:21 CEST] <wm4> see av_frame_get_buffer()
[11:12:56 CEST] <wm4> but yeah, that's slightly annoying... media type and the time base would probably be the only fields that are missing for truly independent AVFrames
[11:13:11 CEST] <JEEB> right, it misses that one as well :)
[11:19:54 CEST] <BtbN> well, I'm not getting a replacement CPU until AMD confirms the defect on mine. Have to somehow wait 4-6 weeks without a CPU in my PC
[11:20:18 CEST] <nevcairiel> time for a vacation
[11:20:45 CEST] <wm4> should have bought Intel
[11:23:51 CEST] <BtbN> I'm just gonna buy a replacement R5
[11:24:01 CEST] <BtbN> R3 is on backorder, so can't do that -_-
[11:29:20 CEST] <BtbN> Ordered an R5 1500X. Guess I have better chances to re-sell those anyway
[13:06:26 CEST] <kurosu_> Are people in here actually experiencing the ryzen crashes?
[13:07:04 CEST] <kurosu_> Not the phoronix one(s) (conftest for PHP build), but on actual work
[13:07:16 CEST] <BtbN> kurosu_, yes.
[13:07:21 CEST] <BtbN> My 1800X is affected
[13:07:44 CEST] <BtbN> Just building gcc is pretty much guaranteed to crash
[13:07:57 CEST] <kurosu_> what does it crash on then? ffmpeg compilation/running?
[13:08:00 CEST] <BtbN> gcc
[13:09:31 CEST] <BtbN> sometimes bash, it's not deterministic at all
[13:09:38 CEST] <BtbN> But mostly gcc just segfaults
[13:09:39 CEST] <kurosu_> ok
[13:10:21 CEST] <kurosu_> that sounds far worse then, but then the platform seems rushed (cf memory issues)
[13:11:22 CEST] <wm4> and the underlying cause is unknown? does amd at least claim that it's fixed on newer revs?
[13:11:34 CEST] <JEEB> yes
[13:11:48 CEST] <JEEB> it claims TR/Epyc and possibly even newer lot Ryzens are unaffected
[13:12:03 CEST] <BtbN> Pretty much only the people who bought Ryzen on day one are affected
[13:12:24 CEST] <BtbN> chips with a UA date after week 25 of 2017 have not been found to be affected
[13:12:43 CEST] <BtbN> It's not even a new stepping. Just the same one, manufactured later
[13:13:19 CEST] <kurosu_> the situation is quite muddy
[13:13:46 CEST] <kurosu_> BtbN case on the other hand is far more concerning, at it's nowhere near artificial
[13:14:01 CEST] <kurosu_> not like I was planning to upgrade anyway
[13:14:13 CEST] <BtbN> To me it seems like AMD knows they fucked up, as they agree to RMA with anyone who asks. But do not publicly announce it, which would cause thousands of CPUs to come back at them
[13:20:06 CEST] <kurosu_> the issue is that the bug is likely companded with generic instability issues due to the platform (motherboard+voltage+memory)
[13:20:26 CEST] <BtbN> The system is not unstable at all
[13:20:38 CEST] <BtbN> I can run Prime95 and other stresstests for hours on end without a single failure
[13:20:57 CEST] <BtbN> And I can also compile huge things like webkit or libreoffice without a single failure
[13:21:05 CEST] <BtbN> it's just a selected few packages that fail reliably
[13:21:15 CEST] <BtbN> most prominently gcc and mesa
[13:21:33 CEST] <kurosu_> yeah, but those are artificial: even if it indicates possible realword issues, if you're not affected... you have issues with compilation, that's no good at all
[13:21:48 CEST] <kurosu_> those = prime&co
[13:21:59 CEST] <BtbN> I can imagine certain games to be affected as well
[13:22:18 CEST] <BtbN> the Benchmark of Ashes of Singularity crashes as well. So the game itself likely does as well when enough is going on
[13:23:02 CEST] <kurosu_> btw, why 1800X? no wish to fiddle with o/c to get the same performance level, or attempt at higher quality cpu sample ?
[13:24:02 CEST] <kurosu_> (i5820k @ conservative 4.1GHz here)
[13:24:04 CEST] <BtbN> best binning, and no point in OCing that for 200~300 extra MHz
[13:24:22 CEST] <BtbN> It runs at 3.7GHz pretty much all the time
[13:24:30 CEST] <BtbN> and Ryzen caps out at around 4GHz
[13:24:58 CEST] <kurosu_> yeah, but I mean the 1700 is the same physical cpu, except for the clock
[13:25:08 CEST] <BtbN> But a lower quality die
[13:25:16 CEST] <kurosu_> so 1700 oc ~ 1800X (oc or not)
[13:25:32 CEST] <BtbN> And I'd have to OC it, don't feel like fiddling with that just to void my waranty on things
[13:26:11 CEST] <kurosu_> yeah, my point (oc'ing can be a hassle), but then warranty issues seems unlikely if you are conservative
[13:27:47 CEST] <kurosu_> anyway, were I at a point I wanted to renew my cpu, I'd still go with AMD (even as a ricer that cares about that avx2 performance)
[13:28:48 CEST] <BtbN> avx2 on Ryzen is not that much slower than on Intel
[13:28:57 CEST] <BtbN> as it doesn't have to underclock itself to run it
[13:29:23 CEST] <kurosu_> yeah, if you are not oc'ing/not overriding power usage limitations
[13:30:23 CEST] <kurosu_> I'm just thinking of the architectural limitations, eg avx2 has half the ressources compared to intel newest chips (aka 2x128, like sse in the old k7 days)
[13:30:43 CEST] <nevcairiel> if you don't OC in the first place, then desktop intels dont really need to downclock for avx2
[13:30:58 CEST] <nevcairiel> there is plenty headroom to use
[13:31:15 CEST] <nevcairiel> servers typically do because they adhere to rather strict standards
[13:31:29 CEST] <kurosu_> they still do? like voltage and clocks are forced to be reduced ?
[13:31:52 CEST] <kurosu_> (whatever the clock. I mean enforced offsets, unless edited)
[13:32:18 CEST] <nevcairiel> in desktop space it mostly depends what your mainboard comes with as a default
[13:33:18 CEST] <nevcairiel> but its no problem to just disable that, makes temps go slightly up, but desktop platforms have plenty headroom for that
[13:35:42 CEST] <kurosu_> anyway, that's an interesting point with avx512 arriving but also increasing the power usage - I'm not completely sure architecture is nowadays the limit, rather than power usage (~ OC frequency reachable within a stability margin)
[13:36:27 CEST] <nevcairiel> avx512 is a lot more demanding, cant really do that without downclocking
[13:36:56 CEST] <nevcairiel> but doubling the throughput again also gives a lot of FLOPS
[13:37:03 CEST] <kurosu_> ryzen seems really spec'ed like haswell, and so the architectural benefits (10-20% more instruction per cycle for 7/8th gen over ryzen?) seem almost completely offset by "more cores"
[13:37:26 CEST] <kurosu_> yeah, my point is the combination is not such a huge improvement
[13:37:52 CEST] <nevcairiel> if the algorithm scales well, then 10-15% less clock still yields a huge improvement
[13:37:57 CEST] <kurosu_> (offset within comparable power usage)
[13:38:31 CEST] <nevcairiel> and recent cpus can change their clock quite rapidly
[13:40:48 CEST] <kurosu_> btw, gb seems to have completely fallen off the radar - I know intel at France got a pretty rough downsizing but that seemed more "intense" than that
[13:43:10 CEST] <atomnuker> kurosu_: intel cpus have 2 256 bit units capable of addition and multiplication, amd has 4 128bit of them (though IIRC 2 of them handled multiplication and 2 did addition)
[13:43:13 CEST] <atomnuker> at least for FPU
[13:43:28 CEST] <atomnuker> *floats
[13:44:06 CEST] <kurosu_> yeah, FMA with avx2 has twice the throughput on intel compared to amd
[13:44:11 CEST] <atomnuker> so its not that different but you still need to avoid doing the standard thing when writing code to not stack 2 256bit identical ops
[13:44:30 CEST] <kurosu_> avx512 seems segmented though in intel hedt (10+ vs below)
[13:55:05 CEST] <wm4> kurosu_: gb?
[14:18:21 CEST] <kurosu_> Gwenole
[14:19:24 CEST] <kurosu_> we had a discussion, I and BBB, around some of those avx2 insn "shortcomings", but he's more a gpu guy
[14:19:32 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:86cbffdc4db2: avcodec/tests/dct: Add peak mean error check
[14:19:33 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:84786e928f9e: avcodec/tests/dct: Add Mean square error test
[14:19:34 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:511e10f673a6: avformat/avidec: Move packet skip after prefix and related checks
[14:19:35 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:7735ed29741d: avcodec/mpeg4videodec: Clear mcsel before decoding an image
[14:20:07 CEST] <kurosu_> *a discussion with him
[14:20:07 CEST] <wm4> kurosu_: AFAIK he stopped working at Intel a long time ago
[14:21:10 CEST] <kurosu_> ok, basically what I was expecting, but with a lot less silence
[14:21:51 CEST] <kurosu_> (privately or not)
[15:19:38 CEST] <kierank> kurosu_: wb
[15:20:42 CEST] <kurosu_> not really back (if that's the meaning), just on holidays at home :)
[15:20:57 CEST] <kierank> ok
[15:39:03 CEST] <ZeroWalker> hmm, when interpolating YUV2 (422), you are supposed to interpolate the first and second UV with the second Y right? so, YUVY YUVY ,  would be (Y+UV), (Y + (UV + UV /2)).  Okay horrible math, not sure why i tried showing it like that -_-
[15:56:37 CEST] <iive> ZeroWalker: you mean  (Y1, (U0+U1)/2, (V0+V1)/2) ? 
[15:57:27 CEST] <ZeroWalker> yeah, is that how the interpolation is supposed to be, and if so, what happens on the last pixel of the line?
[15:59:53 CEST] <iive> just use the same value
[16:01:43 CEST] <ZeroWalker> so the last pixel does no interpolation basically?
[16:03:42 CEST] <iive> what choice do you have :D
[16:04:11 CEST] <J_Darnley> extrapolation!
[16:04:33 CEST] <ZeroWalker> yeah i duno xD. But i haven't there been said something like "center interpolation" or maybe it was Chroma offset/position etc? so didn't know if that had something to do with it
[16:04:49 CEST] <ZeroWalker> haha yeah, ultrapolation is the next step
[16:34:24 CEST] <JEEB> so what was the current plan with the getters and setters for a lot of the values in AVFrames?
[16:34:46 CEST] <JEEB> like av_frame_get_color_range()
[16:35:45 CEST] <nevcairiel> basically dont use them
[16:36:14 CEST] <JEEB> yea, that was what I had gathered before
[16:36:34 CEST] <JEEB> I just wanted to double-check as I happened to look at the AVFrame documentation :)
[16:37:14 CEST] <wm4> we changed it so that you don't need to use them anymore
[20:35:54 CEST] <J_Darnley> LOL.  The people flipping ThreadRippers have appeared.
[20:36:55 CEST] <BtbN> hm?
[20:37:20 CEST] <JEEB> J_Darnley: it also got some boogs_
[20:37:20 CEST] <JEEB> ?
[20:37:24 CEST] <J_Darnley> I'm seeing "second hand" ones being put up for sale.
[20:37:36 CEST] <JEEB> oh, in that sense
[20:37:38 CEST] <JEEB> gotcha
[00:00:00 CEST] --- Sat Aug 12 2017