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

[burek]

[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