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

[burek]

[01:05:24 CEST] <cone-256> ffmpeg 03James Almer 07master:27b7800ba907: avformat/matroskaenc: also write tags when output is WebM
[01:43:10 CEST] <atomnuker> michaelni: could you remove all if (res_bits >= RSIZE_BITS) checking in dirac_vlc and instead change N ## _bits to 64 bits and AND it in append residue
[01:43:41 CEST] <atomnuker> so its never larger than 64 bits
[01:45:59 CEST] <atomnuker> that function must run very fast and I'm not sure what those extra jumps do for branch prediction
[02:13:59 CEST] <michaelni> atomnuker, will check if that works once i figure out why building the fuzzer is really slow now
[02:17:13 CEST] <atomnuker> ok, tnx
[02:33:38 CEST] <cone-256> ffmpeg 03Steven Liu 07master:96d70694aea6: avformat/dashdec: add dash demuxer base version
[02:34:27 CEST] <atomnuker> RiCON^^
[02:35:40 CEST] <cone-256> ffmpeg 03Steven Liu 07master:ab96e2ca81d7: avformat/dashdec: free resource allocated by xml
[02:43:55 CEST] <jamrial> oh boy, libxml2 finally made it to ffmpeg
[02:44:53 CEST] <atomnuker> its only an external library
[02:45:58 CEST] <J_Darnley> I am saddened that nobody NIH their own.
[02:46:02 CEST] <jamrial> i know, and i remember people fighting tooth and nail against implementing any xml library whatsoever
[02:46:04 CEST] <J_Darnley> It is only xml
[02:46:16 CEST] <J_Darnley> :)
[02:47:22 CEST] <J_Darnley> Oh god!  Why did the entire changelog of the patch get commited?
[03:48:36 CEST] <michaelni> libavcodec/vp9.c:1631: undefined reference to `ff_slice_thread_execute_with_mainfunc'
[03:51:53 CEST] <michaelni> thats with --disable-pthreads
[03:53:57 CEST] <michaelni> need to go to bed otherwise id fix it
[12:08:32 CEST] <cone-105> ffmpeg 03Petri Hintukainen 07master:7a6bd541528b: Add SUP/PGS subtitle muxer
[12:32:13 CEST] <cone-105> ffmpeg 03Jun Zhao 07master:a918f16f7ccc: lavc/vaapi_encode_mpeg2: fix frame rate calc error when use time_base.
[13:49:22 CEST] <rcombs> oh, a SUP muxer, nice
[16:41:20 CEST] <jkqxz> Hmm.  Apparently Odroid XU4 wasn't such a good choice to test V4L2 - it hard reboots under nontrivial load.  (Pretty much instantly with libx264 on all threads, parallel make gets it after a while.)
[17:12:37 CEST] <cone-129> ffmpeg 03Paul B Mahol 07master:4d41db7a31db: avfilter: add generic FFT video convolve filter
[17:16:03 CEST] <RiCON> atomnuker: nice
[17:24:22 CEST] <jamrial> jkqxz: temp related?
[17:28:29 CEST] <jkqxz> Probably?  (But unclear, because there is no feedback whatsoever.)
[17:29:47 CEST] <atomnuker> michaelni: doesn't N ## _bits  = (N ## _bits + (M ## _bits)) & 63 only limit to 63 dec? e.g. the lowest 6 bits?
[17:29:48 CEST] <nevcairiel> if its heat, you might be able to help that
[17:30:30 CEST] <jkqxz> It dies a bit too quickly and consistently for me to blame heat immediately.
[17:31:18 CEST] <jkqxz> Like, doing H.264 -> libx264 with all default settings dies after ~five frames.
[17:33:28 CEST] <jkqxz> Power draw is also a possibility, but I'm using their default 5V*4A supply, so it seems unlikely.
[17:33:32 CEST] <michaelni> atomnuker, yes, i thought thats what you want me to do
[17:35:25 CEST] <jkqxz> Just trying again with a cold boot after letting it cool down it managed 60 frames on that test before dying, and the heatsink is not yet warm.
[17:36:01 CEST] <jkqxz> Maybe the heatsink isn't attached properly.
[17:36:54 CEST] <atomnuker> michaelni: no, this limits golomb codes to 7 bits, it probably won't even pass fate, you need to limit it to the largest number such that no underfined behaviour will happen
[17:37:40 CEST] <atomnuker> the max number of bits each APPEND_RESIDUE will append is 8 beucause the function reads bytes
[17:39:34 CEST] <atomnuker> if you AND it with ((1 << 63) - 1) it should guarantee that the shift amount will never be larger than the type
[17:40:21 CEST] <atomnuker> wait, nevermind everything
[17:41:17 CEST] <atomnuker> michaelni: patch looks good to me, feel free to push
[17:42:30 CEST] <jkqxz> Hmm, it seems ok for a while with the CPU speed manually turned right down with cpufreq.  I thought that was meant to happen automatically, though.
[17:45:17 CEST] <michaelni> atomnuker, you are confusing me ;) but ill push after quick retest
[17:53:54 CEST] <atomnuker> michaelni: I got confused because I never think of using AND to limit to a decimal number
[17:55:27 CEST] <atomnuker> in 99.9% of asm you use and as a bitmask and in dirac_vlc I only deal with raw bits
[17:55:40 CEST] <BtbN> jkqxz, nothing surprises me on those boards anymore. Even the RPi has proven to be very unreliable to me
[17:56:12 CEST] <BtbN> Like, the oney I still use all have a cronjob that reboots them every day. As they tend to hard-freeze if they are up for too long
[17:56:22 CEST] <atomnuker> michaelni: if the 63 was in hex form I wouldn't have been confused, could you make it hex before you push it?
[17:57:12 CEST] <jamrial> the odriod and similar boards were most likely mainly tested to make sure video playback worked fine using the gpu
[17:57:15 CEST] <jamrial> i wouldn't find it odd if they never stress tested the cpu like you're doing
[17:57:17 CEST] <BtbN> for a 64 bit number, the 63 seems more naturl to me than the same in hex?
[18:01:39 CEST] <atomnuker> BtbN: 63 is 00111111, hex makes more sense to me when its limiting to a given number of bits
[18:01:58 CEST] <BtbN> but it's 1 << 63
[18:02:17 CEST] <atomnuker> numbers only work when they're exactly a power of two - 1
[18:02:45 CEST] <BtbN> but that's what the (1 << x) - 1 is for?
[18:03:07 CEST] <atomnuker> I don't get it, what are you referring to?
[18:07:03 CEST] <michaelni> atomnuker, i can make it anything you want, just say how it should look
[18:08:50 CEST] <atomnuker> just make it hex
[18:10:04 CEST] <michaelni> ok
[18:14:24 CEST] <jkqxz> I wasn't meaning to stress test the CPU.  It just died instantly when I accidentally encoded with libx264 the first time.
[18:15:09 CEST] <jkqxz> In comparison, the Rockchip I have has been fine.  (It slows down quite a bit at load because it can't get rid of all the heat, but nothing ever dies.)
[19:09:25 CEST] <cone-129> ffmpeg 03Michael Niedermayer 07master:d98d29a775d6: avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE()
[22:49:41 CEST] <jkqxz> gh0st__:  <https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-VP9-GSoC-Faster>
[22:57:39 CEST] <gh0st__> jkqxz: Oh god, wut? I didn't expect this much attention. )
[22:59:22 CEST] <gh0st__> The main AVX2 optimizations are still to come, particularly the for loopfilter and the rest of the ipred functions that are left.
[22:59:43 CEST] <nevcairiel> tile threading doesnt really make it faster for the majority of users, does it. most people are going to stick to frame threading, which from what I understand is still faster?
[23:00:42 CEST] <JEEB> yea, frame threading generally tends to be faster in various formats. I had a similar experience with ut video which is why I think that didn't get merged in 2012
[23:00:48 CEST] <gh0st__> nevcairiel: More benchmarking is needed to state this fact for sure.
[23:01:14 CEST] <gh0st__> But yes, from what I see frame threading is faster.
[23:01:47 CEST] <nevcairiel> for hevc some people had the idea to combine both, tile and frame, so that the "expensive" I frames could be decoded faster and therefor increasing the scaling of frame threading as well
[23:01:56 CEST] <nevcairiel> i wonder how horrible that would be in code
[23:02:10 CEST] <JEEB> would have to have two pools of threads then I guess?
[23:02:32 CEST] <iive> how is tile different from slice?
[23:02:50 CEST] <nevcairiel> its the same thing, some codecs just call it tiles, some slices
[23:03:05 CEST] <nevcairiel> tiles and slices might be organized differently
[23:03:19 CEST] <nevcairiel> slices are typically full-width and limited height, while tiles are limited in both directions i believe
[23:03:28 CEST] <jkqxz> And H.265 has both, of course.
[23:03:36 CEST] <JEEB> yup
[23:03:55 CEST] <jkqxz> Because why wouldn't you add more features?
[23:04:24 CEST] <JEEB> the MPEG next-gen R&D guy at NHK was already talking about diminishing returns with regards to a lot of features
[23:04:28 CEST] <JEEB> which is kind of telling
[23:05:07 CEST] <nevcairiel> well, the main problem with those codecs is that there isnt a good way to determine if a feature really helps, other then trying it and seeing if its smaller
[23:05:10 CEST] <jamrial> mpeg ng?
[23:05:19 CEST] <nevcairiel> so costs increase exponentially w ith every feature, more or less
[23:05:26 CEST] <iive> h267
[23:05:34 CEST] <JEEB> ugh, stop using the ITU-T names
[23:05:39 CEST] <nevcairiel> isnt 266 next
[23:05:41 CEST] <JEEB> because they're not given to the format until it's ready
[23:05:42 CEST] <JEEB> and yes
[23:05:57 CEST] <nevcairiel> noone uses mpeg names anymore
[23:05:59 CEST] <JEEB> I mean, people were calling HEVC H.265 before it got the name officially
[23:06:02 CEST] <iive> i like itu names
[23:06:02 CEST] <jamrial> any tentative non itu name for it yet?
[23:06:06 CEST] <iive> nevcairiel: because of mpeg4
[23:06:17 CEST] <nevcairiel> MPEG-H Part 8, who uses that
[23:06:21 CEST] <nevcairiel> H.265 is much nicer =p
[23:06:27 CEST] <JEEB> you mean part 2
[23:06:28 CEST] <nevcairiel> actually Part 2
[23:06:29 CEST] <nevcairiel> got confused
[23:06:36 CEST] <JEEB> also HEVC is still valid, no?
[23:06:39 CEST] <jamrial> HEVC is much nicer :p
[23:06:54 CEST] <JEEB> it's not me disliking the ITU-T names, but just that they're not set yet. f.ex. ITU-T switched H.whatever to H.265 in like late 2013 officially
[23:07:05 CEST] <JEEB> (it's of course obvious'ish what the next name will be but still)
[23:07:11 CEST] <jkqxz> H.265 is much nicer, because the free specification you can download is called that.
[23:07:58 CEST] <nevcairiel> indeed, ITU doesnt rip you off as much =p
[23:08:08 CEST] <JEEB> yea
[23:08:13 CEST] <nevcairiel> mpeg still tries to sell you the same spec
[23:08:15 CEST] <jkqxz> (I wonder how many people have ever paid for ISO/IEC 23008-2.)
[23:08:33 CEST] <iive> companies probably
[23:09:45 CEST] <JEEB> yea that's really weird how ISO wants CHF 198 for effectively the same document
[23:26:47 CEST] <kierank> bureaucrats will be bureaucrats
[23:45:36 CEST] <BBB> nevcairiel: is fairly easy; horizontal synchronization already exists for the loopfilter, so if you do the signaling for the frame thread progress in the loopfilter thread, that would work
[23:46:22 CEST] <BBB> nevcairiel: I dont think its useful since vp9 decoding is so ridiculously fast that only a calculator would need it for realtime decoding - anything else already does realtime vp9 decoding wiht a single threading type
[23:53:46 CEST] <hanna> judging by https://www.youtube.com/watch?v=aT-oXygGf24 the minterpolate video filter produces some pretty convincing results; could anybody provide a brief description of the algorithm?
[23:53:50 CEST] <hanna> would be interesting to try and implement it on the GPU
[23:54:28 CEST] <hanna> seems like that was done using mode obmc, which does a block motion search?
[23:55:11 CEST] <hanna> What's the bottleneck in this code? the block search or the actual pixel interpolation?
[23:55:25 CEST] <JEEB> perf should able to tell I guess?
[23:56:52 CEST] <durandal_1707> hanna: it have artifacts
[23:57:07 CEST] <JEEB> yes, all such things have artifacts
[23:59:32 CEST] <atomnuker> hanna: there's no SIM at all
[23:59:37 CEST] <atomnuker> *SIMD
[00:00:00 CEST] --- Sun Sep 10 2017