[00:00:00 CEST] --- Thu Aug 1 2019 [02:26:25 CEST] <mkver> Does anybody know why h264_mp4toannexb parses IDR slices itself in order to detect whether this is the first slice of a new IDR picture? Is this a remnant from the age when the bsf api didn't use AVPackets? [02:46:44 CEST] <jamrial> mkver: it's possible. git blame for that line might help [02:48:20 CEST] <mkver> Has been introduced in bf428bb3145c4f0eef32f8ef00de0ee222b3e414; it has been done in order to support multiple IDR pictures directly after each other (so that all of them would get extradata). [02:49:30 CEST] <mkver> But why are these variables (new_idr, idr_sps_seen, idr_pps_seen) kept in the context at all? [02:50:08 CEST] <mkver> This would only make sense if one tries to support situations in which the input the bsf gets is not an access unit. [02:52:03 CEST] <mkver> (And the current implementation has interesting side effects: Think of something like ... PPS non-IDR pic IDR pic. The non-IDR pic will get a SPS, too, and the idr_s/pps_seen variables will be set to 1. Therefore the IDR pic won't get extradata even when it needs it. Have I already said that the naming of idr_s/pps_seen is suboptimal?) [03:04:27 CEST] <mkver> Did the old bitstream filter API actually send data from several packets at once or partial packets? Then everything would make sense. [03:10:14 CEST] <cmptr> The config.h include in fftools/ffmpeg.c, that is created when ./configure is ran, correct? [03:11:02 CEST] <cmptr> Or is it refering to compat/avisynth/avs/config.h? [03:17:02 CEST] <jamrial> the autogenerated by configure, yes [04:55:50 CEST] <tmm1> i'm trin gto figure out where in the vaapi encoding pipeline is the best place to extract AV_FRAME_DATA_A53_CC [11:12:25 CEST] <durandal_1707> kierank: Nicolas finally agrees with me in something! [13:26:09 CEST] <cone-231> ffmpeg 03Steven Liu 07master:46b97c0527ed: FATE: add hls single file mode test case [13:34:21 CEST] <kierank> durandal_1707: wow [15:01:58 CEST] <durandal_1707> some guy wrote much better prores encoder (ffmpeg binary provided with no source) [15:02:08 CEST] <durandal_1707> our both encoders sucks big time [15:04:52 CEST] <JEEB> durandal_1707: are you sure it's not just a wrapper over the apple stuff? I think they released something semi-recently? [15:13:23 CEST] <durandal_1707> JEEB: it appears to be proresenc_amcdx from same company and one ukraine guy [15:30:57 CEST] <durandal_1707> i have just edited apple prores wikipedia page, where it shits on open source decoder [15:59:50 CEST] <cehoyos> durandal_1707: Do you want me to test? [16:00:11 CEST] <durandal_1707> cehoyos: sure, it should be faster now [16:05:15 CEST] <cehoyos> Please point me to a sample input file [16:05:31 CEST] <durandal_1707> you removed old one? [16:06:32 CEST] <cehoyos> Isn't this now another codec? [16:06:38 CEST] <cehoyos> Sorry if I misunderstand... [16:07:01 CEST] <durandal_1707> cehoyos: no it is same, dsddec patch [16:07:35 CEST] <durandal_1707> dstdec is also there be its not worth comparing as its very slow in another code [16:07:50 CEST] <durandal_1707> http://www.lindberg.no/hires/test/2L-145/2L-145_mch_DSF_2822k_1b_01.dsf [16:08:00 CEST] <durandal_1707> that is file [16:08:22 CEST] <durandal_1707> 5.1 DSD 64 [16:09:44 CEST] <durandal_1707> and long dstdec files are not available that freely [17:04:18 CEST] <durandal_1707> kierank: please apply msrle patch if you can, it is very trivial [17:30:35 CEST] <durandal_1707> cehoyos: how it goes? [18:34:59 CEST] <cehoyos> Sorry for the delay: For two threads, time is a little slower, for six and more threads, it also gets slower, only for four threads do I see a small speed improvement, in all cases at the cost of a huge increase of cpu cycles [18:36:03 CEST] <cehoyos> Given that it's 17x realtime on a ppc core (which is much slower than an Intel core), I am not convinced this patch is worth the effort [18:36:10 CEST] <cehoyos> on one ppc core... [18:37:45 CEST] <durandal_1707> cehoyos: what? it gives better speed on old celeron cpu, on what hw have you tested it? [18:38:18 CEST] <durandal_1707> you need to look at speex= X report from ffmpeg [18:38:23 CEST] <durandal_1707> *speed [18:38:50 CEST] <cehoyos> Intel E3-1230 V2 and POWER7 altivec [18:39:04 CEST] <cehoyos> Thank you for explaining how to do an FFmpeg performance test... [18:40:08 CEST] <cehoyos> I don't think speed is the ideal testtool though: It doesn't tell you anything about the cost of the speedup. [18:40:47 CEST] <durandal_1707> this is not about cost of speedup, more about speedup alone [18:41:18 CEST] <cehoyos> You would accept a 10% speedup by default if it doubles cpu load? [18:41:35 CEST] <durandal_1707> it would not double cpu load [18:41:43 CEST] <cehoyos> No, it triples it;-) [18:42:27 CEST] <durandal_1707> use correct tool, and not time :) [18:42:50 CEST] <cehoyos> (for threads=2, cpu load gets doubled, but on both very different systems, decoding gets slower) [18:43:33 CEST] <durandal_1707> on which system decoding is slower? [18:44:13 CEST] <durandal_1707> i get 50% more speed on very shitty cpu [18:44:28 CEST] <durandal_1707> perhaps you test on even older hw [18:44:50 CEST] <durandal_1707> test with modern CPU if you can [18:46:09 CEST] <cehoyos> On both systems [18:49:56 CEST] <cehoyos> Which of the patches do I have to appy to do the tests? [18:50:42 CEST] <durandal11707> cehoyos: what you applied? [18:50:57 CEST] <cehoyos> I originally only tested 0002 [18:52:01 CEST] <durandal11707> cehoyos: from new thread? [18:52:26 CEST] <cehoyos> yes, I get different results than with the test I did last time [18:54:56 CEST] <cehoyos> Applying also the libavformat patch makes threads=4 also slower on my Intel [18:58:41 CEST] <durandal11707> cehoyos: what slower means exactly? [18:59:37 CEST] <durandal11707> libavformat patch should not make a difference at all, it just forces demuxer to set timestamp instead of ffmpeg [19:01:05 CEST] <cehoyos> 10-20% [19:01:19 CEST] <cehoyos> I thought the same, but I can reproduce the difference applying and reverting the lavf patch. [19:05:48 CEST] <durandal11707> cehoyos: how much RAM you have? [19:06:03 CEST] <cehoyos> infinite on ppc, 8G on Intel [19:06:21 CEST] <cehoyos> no, only 64G [19:06:36 CEST] <cehoyos> (The other ppc systems have much more iirc) [19:07:16 CEST] <cehoyos> maxrss reports 12M iiuc [19:07:28 CEST] <cehoyos> 20 on ppc [19:10:23 CEST] <cone-868> ffmpeg 03Andriy Gelman 07master:f60b1211b2aa: lavfi/zmq: Avoid mem copy past the end of input buffer [19:11:02 CEST] <durandal11707> whats up with fflogger, its in very poor state [19:11:45 CEST] <durandal11707> cehoyos: the demuxer behaves strangely, -f null - is more slow than -f framecrc -, which is illogical [19:13:11 CEST] <cehoyos> I used crc for my tests [19:13:22 CEST] <cehoyos> As said, this is just not worth your valuable time [19:15:21 CEST] <durandal11707> i strongly disagree [19:16:14 CEST] <durandal11707> with dsf patch disabled its approx same speed [19:16:54 CEST] <cehoyos> What does "dsf patch disabled" mean? [19:17:43 CEST] <durandal11707> reverted [19:18:14 CEST] <durandal11707> on this shitty CPU ffmpeg ld on ffmpeg takes eons [19:19:10 CEST] <durandal11707> also in my case using more threads does not hurt much [19:19:47 CEST] <cehoyos> You mean since you only have two cores, the cpu load is never bigger than twice the cpu load with threads=1 ? [19:29:43 CEST] <durandal11707> cehoyos: test with -vn [19:29:56 CEST] <cehoyos> I used -vn for all tests (did not test without it) [19:32:05 CEST] <durandal11707> cehoyos: what speed up you get with flac decoding? [19:32:19 CEST] <durandal11707> using threads 1 and more? [19:34:57 CEST] <durandal11707> i wonder how that dsfdec libavformat patch could slow down things for you? previously it would pick wrong 90k TB [19:35:08 CEST] <durandal11707> now it picks correct one [19:39:45 CEST] <durandal11707> cehoyos: what you think is useful load, is max possible load from multithreading, that is scales exactly with number of cores, linearly - thats never possible [19:44:20 CEST] <nevcairiel> 90% per core up to number of channels might be reasonable [19:49:30 CEST] <durandal11707> isn't his CPU older than mine anyway? [19:49:37 CEST] <cehoyos> I can only say that the current patch shows no clear speedup at very high costs, I have to leave soon and will not be able to test until Wednesday [19:51:21 CEST] <durandal11707> cehoyos: if you see no gain there, do you see at least gain with frame decoding and flac? [19:51:53 CEST] <durandal11707> or any other threading feature in whole ffmpeg codebase? [19:52:36 CEST] <durandal11707> because if not, your cpus are ready for recycle [19:56:37 CEST] <durandal11707> who have modern CPU generation? [19:59:55 CEST] <durandal11707> nobody? what a shame... [20:04:34 CEST] <durandal11707> looks like nobody gives shit about DSD, and patches in general [20:05:52 CEST] <cehoyos> I can test current cpus next week but I doubt that the results will be completely different [20:07:28 CEST] <cehoyos> I seee a *massive [20:07:48 CEST] <cehoyos> I seee a *massive* speedup with multi-threaded flac decoding, it may even scale [20:12:48 CEST] <cehoyos> bye [20:26:28 CEST] <Lynne> >a graph would merge the L/R to build a dolbyE stream that the filter could decode [20:27:10 CEST] <Lynne> next up: base64 encoding! in umm, old binary excel documents! sent as attamchments to a special email server [20:28:50 CEST] <Lynne> but its fine, its standardized. besides, everyone can easily hook in an excel decoder in their pipeline [20:28:50 CEST] <durandal_1707> i will pay 100$ for someone to test patches on modern CPU [20:29:09 CEST] <Lynne> are you that desparate? send me a sample [20:29:12 CEST] <J_Darnley> Oh money? [20:29:26 CEST] <J_Darnley> I have a Ryzen 2200 I can use [20:29:54 CEST] <durandal_1707> i will pay only if i get positive results :) [20:30:25 CEST] <durandal_1707> Lynne: what CPU do you have? [20:32:12 CEST] <Lynne> core i7 6600 [20:49:55 CEST] <BradleyS> i can probably test intel e5 in the coming days [20:53:12 CEST] <rcombs> durandal_1707: wonder if you'd get better improvements with SIMD [20:53:47 CEST] <nevcairiel> dsd is hard to impossible to simd, every single bit depends on the one before it [20:54:36 CEST] <nevcairiel> the only hope is that channel are entirely independent, so you could thread them, but apparently no scaling [20:54:57 CEST] <rcombs> yeah, I meant on channels [20:56:00 CEST] <durandal_1707> there is scaling, ignore cehoyos and 5year old cpus [20:56:25 CEST] <nevcairiel> 5 year old CPUs are still quite similar to those today, stuff hasnt moved much =p [20:57:04 CEST] <durandal_1707> yes, thats why get with 2 cores, %50 speedup [20:58:52 CEST] <J_Darnley> Is this the DSD patch(es) you're testing? If so where can I get a reasonable length file to decode? [20:59:06 CEST] <Lynne> durandal_1707: 1 thread - 53x realtime, 2 threads - 59x realtime, 4 threads - 47x realtime [20:59:24 CEST] <Lynne> for the long dsf file [20:59:26 CEST] <durandal_1707> J_Darnley: or any from last column links: http://www.2l.no/hires/index.html [21:00:13 CEST] <durandal_1707> Lynne: huh, how many cores is that? [21:00:56 CEST] <Lynne> 2 cores, 4 threads [21:02:03 CEST] <durandal_1707> well, in my case, main issue was that other channels/jobs would get misaligned buf[] [21:02:53 CEST] <durandal_1707> perhaps they are still not aligned properly, causing unaligned access [21:03:24 CEST] <Lynne> could always make it output planar, I think [21:03:38 CEST] <nevcairiel> definitely use planar for threading [21:04:00 CEST] <durandal_1707> planar? [21:04:15 CEST] <nevcairiel> one seperate buf for each channel [21:04:21 CEST] <J_Darnley> like video [21:04:33 CEST] <durandal_1707> and not DECLARE_ALIGNED ? [21:04:53 CEST] <J_Darnley> make -sj4 [21:05:03 CEST] <nevcairiel> buffers are always aligned [21:05:25 CEST] <nevcairiel> apparently dsddec already uses FLTP tho [21:05:49 CEST] <durandal_1707> i'm talking about buf in dsd2pcm [21:06:21 CEST] <durandal_1707> its buf[16]* number of channels [21:08:00 CEST] <durandal_1707> actually i forgot there is unsigned pos after buf, causing misaligned access, DECLARE_ALIGNED fixed it to me [21:08:24 CEST] <durandal_1707> but perhaps that is not good fix [21:08:47 CEST] <durandal_1707> because 4 threads should decode faster for 6ch file [21:43:12 CEST] <J_Darnley> oh bloody hell, why does -benchmark use av_log? [21:45:50 CEST] <jamrial> what did you want it to do instead? [21:45:56 CEST] <J_Darnley> printdf [21:46:02 CEST] <J_Darnley> *printf [21:47:45 CEST] <jamrial> that's the default for av_log [21:48:30 CEST] <J_Darnley> yeah, but I can't do -loglevel quiet and -benchmark [21:57:11 CEST] <J_Darnley> Oh well he left. [21:57:24 CEST] <J_Darnley> Anyway I get sppeds of 74 [21:57:28 CEST] <J_Darnley> .uh [21:57:51 CEST] <J_Darnley> Anyway I get speeds of 74.1 101.7 120.4 128.4 [21:59:20 CEST] <J_Darnley> thread counts 1-4 [22:43:14 CEST] <extrowerk> Hi Guys, i am with the HaikjuPorts team here. [22:44:29 CEST] <extrowerk> We have an annoying bug with the Haiku's MediaPlayer, it crashing randomly at opening mjusic files with embedded cover art. As MediaPlayer based on ffmpeg, i came here to ask: is it possible to disable the cover-art support at compile time? [22:44:50 CEST] <J_Darnley> no [22:45:12 CEST] <J_Darnley> the files will present you with a video stream [22:45:17 CEST] <extrowerk> MediaPlayer doesn't handles it correctly, and as i can't fix it (well over my skills), i tojught maybe it would be possible to just disable it. [22:46:16 CEST] <J_Darnley> It is a poor design choice to represent this binary data attachment as a stream of any sort. [22:47:26 CEST] <J_Darnley> But that choice was made an now we must all suffer with it [22:47:40 CEST] <extrowerk> J_Darnley: yep, i know it is a video stream, in some case MediaPlayer handles it well, like in this case: http://0x0.st/zfG4.png [22:48:05 CEST] <J_Darnley> If this is a *music* player then maybe you can disable all the video codecs. [22:48:21 CEST] <extrowerk> but in many othjer cases it just crashes. Stripping the cover art solves the problem, so we are almost sure, thje cujlprit is the embedded cover art. [22:48:39 CEST] <extrowerk> So there is no way to disable it? [22:48:53 CEST] <J_Darnley> If you have an example file, try decoding it with ffmpeg and see if it crashes [22:49:00 CEST] <J_Darnley> maybe there's just a bug [22:49:54 CEST] <extrowerk> every other ffmpeg based player plays it just fine, just MediaPlayer crashes, so it is a known and acknowledged bug in Haikju's MediaPlayer, but currently nobody got time to fix it, and i have not enough skills to do it. [22:50:26 CEST] <extrowerk> but i can build ffmpeg and try to disable it, so we can fix the MediaPlayer code later... [22:50:32 CEST] <extrowerk> at least thats my plan [22:50:43 CEST] <J_Darnley> oh okay [22:53:06 CEST] <extrowerk> Does ffmpeg uses libid3tag for the cover art? [22:54:39 CEST] <J_Darnley> almost certainly not [22:54:52 CEST] <kepstin> no, ffmpeg's mp3 & id3 reader don't use external libraries. [22:55:19 CEST] <kepstin> does this only affect mp3 files? or multiple file formats? [22:55:58 CEST] <extrowerk> i have seen crashes only with mp3 diles so far [22:56:04 CEST] <extrowerk> *files [22:56:46 CEST] <extrowerk> here is an example crashlog: http://0x0.st/zfGm.report [23:00:01 CEST] <J_Darnley> _DecodeVideodoesn't look like one of our functions [23:00:37 CEST] <extrowerk> i can't give you more info sadly. [23:00:58 CEST] <J_Darnley> How about the source code of the player? Is that public somewhere? [23:02:56 CEST] <extrowerk> yes, of course [23:03:19 CEST] <extrowerk> https://github.com/haiku/haiku/tree/master/src/apps/mediaplayer [23:10:09 CEST] <J_Darnley> :vs [23:17:54 CEST] <J_Darnley> "This function MUST be called after _DeinterlaceAndColorConvertVideoFrame()" [23:18:10 CEST] <J_Darnley> look, it's being called before [23:18:51 CEST] <J_Darnley> no my bad, wonf function [23:20:59 CEST] <J_Darnley> No actually, do have a look at _HandleNewVideoFrameAndUpdateSystemState [23:23:37 CEST] <J_Darnley> but I don't see what that only breaks covers [23:24:59 CEST] <J_Darnley> *why that [23:26:32 CEST] <extrowerk> J_Darnley: as i stated before i am not in the shape to fix it, but thjanks for looking it, your finding is noted. [23:26:46 CEST] <J_Darnley> you're welcome [23:27:07 CEST] <J_Darnley> sorry I couldn't give you what you're looking for [23:27:59 CEST] <extrowerk> maybe i will just write a bash script to strip all the cover arts. [23:28:08 CEST] <extrowerk> the problem is, i like them showing up nicely. [23:28:21 CEST] <extrowerk> so, yeah, i still have to use mpd on haiku :( [23:28:37 CEST] <extrowerk> that doesn't have this problem :) [23:28:49 CEST] <J_Darnley> My argument is that there should be 1 file (cover.jpg or similar) in the directory [23:29:14 CEST] <J_Darnley> folder.jpg if you're on Windows [23:46:21 CEST] <extrowerk> J_Darnley: thanks again. [23:46:26 CEST] <extrowerk> good night andbye! [23:47:54 CEST] <J_Darnley> good night [00:00:00 CEST] --- Fri Aug 2 2019