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

[burek]

[00:47:08 CET] <cone-401> ffmpeg 03Timo Rothenpieler 07master:15b019e40adb: avcodec/nvenc: fix double defined GUID on cygwin
[00:47:09 CET] <cone-401> ffmpeg 03Timo Rothenpieler 07master:4e93f00b06d9: avcodec/nvenc: check pop_context return value
[01:20:16 CET] <cone-401> ffmpeg 03Carl Eugen Hoyos 07master:f3af34f9ebd2: lavc/dnxhddata: Improve help output, mention yuv444p10 and gbrp10.
[03:13:49 CET] <liuzceecs> it seems that ffmpeg can't parse or download MPEG dash(.mpd) file now? Will it be a new feature? I'd like to do some work about that
[03:29:16 CET] <philipl> BtbN: do you mind looking at the mpeg2 hwaccel on the mailing list?
[11:59:13 CET] <cone-262> ffmpeg 03Michael Niedermayer 07master:65e0a7c473f2: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()
[11:59:13 CET] <cone-262> ffmpeg 03Michael Niedermayer 07master:73964680d7bc: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0()
[11:59:13 CET] <cone-262> ffmpeg 03Michael Niedermayer 07master:2ab9568a2c33: avcodec/zmbv: Check that the buffer is large enough for mvec
[11:59:13 CET] <cone-262> ffmpeg 03Michael Niedermayer 07master:4f7f70738e8d: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()
[11:59:13 CET] <cone-262> ffmpeg 03Dale Curtis 07master:d073be2291e4: Fix leak of frame_duration_buffer in mov_fix_index().
[11:59:13 CET] <cone-262> ffmpeg 03Dale Curtis 07master:5eaaffaf64d1: Use ff_thread_once for fixed, float table init.
[11:59:13 CET] <cone-262> ffmpeg 03John Stebbins 07master:20c38f2e7085: lavf/mov: don't read outside frag_index bounds
[11:59:14 CET] <cone-262> ffmpeg 03Jim DeLaHunt 07master:fb791d28766b: Ignore libavcodec/tests/mpeg12framerate, a test program
[13:18:50 CET] <durandal_1707> this guy is living cancer
[14:13:44 CET] <liuzceecs> hello, guys
[14:14:58 CET] <liuzceecs> I find that ffmpeg maybe cannot play .mpd file now, will that become a new feature in future? I'd like to do some work about that
[14:30:49 CET] <durandal_1707> liuzceecs: whats mpd?
[14:44:44 CET] <BtbN> dash xml stuff
[14:45:04 CET] <BtbN> Last time that came up nobody could decide on how to parse xml, so nothing happened
[14:46:38 CET] <JEEB> it got merged :D
[14:46:49 CET] <JEEB> we now have dash "demuxer"
[14:46:54 CET] <JEEB> and it uses libxml2
[14:53:33 CET] <BtbN> ah, missed that
[15:04:24 CET] <liuzceecs> thx :)
[15:18:03 CET] <kierank> can we get rid of these stupid mpeg1 non bitexact dequant?
[15:19:58 CET] <kierank> in fact why does bitexact need to be turned on explicitly
[15:20:08 CET] <JEEB> that sounds weird
[15:20:15 CET] <JEEB> for that kind of stuff
[15:21:43 CET] <kierank> for the encoder apparently
[15:21:44 CET] <kierank> thankfully
[15:55:34 CET] <JEEB> hmm
[15:55:40 CET] <JEEB> https://github.com/mpv-player/ffmpeg-mpv/commit/94e5432e6124192fb81893fc5fd40e26f3e09df4
[15:55:45 CET] <JEEB> should we do this, too :P
[16:06:20 CET] <durandal_1707> probably not, ask BBB 
[16:59:01 CET] <BBB> kierank: our testing framework for non-audio stuff only checks md5s, not picture exactness
[16:59:13 CET] <BBB> kierank: for whatever reason, some very old mmx optimizations round differently for speed reasons
[16:59:29 CET] <BBB> (some arm optimizations may have done that too at one point or another)
[16:59:30 CET] <JEEB> ah yes, guessed some old optimizations were the reason :)
[16:59:40 CET] <BBB> I dont believe arm does that anymore
[16:59:42 CET] <BBB> and ppc is dead
[16:59:44 CET] <BBB> but mmx still lives on
[16:59:53 CET] <BBB> so for fate reasons, we use -flags bitexact
[17:00:04 CET] <BBB> but normal runtime uses untested (by fate) but enabled-by-default mmx routines
[17:00:11 CET] <JEEB> yea, I have once broke FATE with the ut video encoder because swscale was somehow related
[17:00:20 CET] <BBB> yes, swscale has those optimizations also
[17:00:24 CET] <BBB> its old cruft
[17:00:36 CET] <JEEB> and mans told me to "remove flags that you don't know" :D back in ye olden 2012
[17:00:51 CET] Action: JEEB copied some params from other encoder tests
[17:01:37 CET] <JEEB> and then I had to make a separate commit for the -flags bitexact be put back
[17:01:42 CET] <JEEB> good times
[17:01:56 CET] <JEEB> BBB: and yes, it's funny how the actual used stuff is untested :)
[17:06:21 CET] <BBB> in defense of the current system, Im not sure how you would test it in a generic way
[17:06:30 CET] <BBB> I mean, I understand the use a reference, calculate psnr"
[17:06:39 CET] <JEEB> yea
[17:06:43 CET] <BBB> but I dont think thats great, because it allows bugs to creep in
[17:06:47 CET] <JEEB> then you have to define what is "good enough"
[17:06:49 CET] <JEEB> yup
[17:06:53 CET] <BBB> for audio, the differences are tiny, here the diffs are quite big
[17:06:57 CET] <BBB> (relatively speaking)
[17:07:05 CET] <BBB> so its not really easily tested anymore
[17:07:06 CET] <BBB> ...
[17:07:10 CET] <BBB> its a difficult question
[17:07:23 CET] <BBB> obviously not testing isnt any better
[17:07:29 CET] <BBB> but there is no great solution
[17:07:54 CET] <nevcairiel> dont we do psnr/maxdiff tests for some video things
[17:08:33 CET] <BBB> thats encoder/decoder round-trip tests
[17:08:43 CET] <BBB> not individual dsp function tests
[17:10:07 CET] <kierank> BBB: are you able to explain this extra_shift business that prores idct does?
[17:10:18 CET] <kierank> I'm guessing it stores coefficients with fractional components and you need to shift them away
[17:10:24 CET] <kierank> fractional LSBs
[17:11:08 CET] <BBB> yes
[17:11:19 CET] <BBB> or, alternatively, the internal format is 12 bits/component but we output 10
[17:11:26 CET] <BBB> you can look at it in multiple ways
[17:11:43 CET] <kierank> yeah
[17:12:03 CET] <BBB> I think by the time we wrote prores, 12 bits/c didnt exist so much yet
[17:12:09 CET] <BBB> nowadays we have 1000 pix_fmts
[17:12:17 CET] <kierank> I have 17-bi coefficients in mpeg-4 ssp, not sure whether to do the dct in full or cheat and do a simpler one with 32-bit intermediates
[17:12:18 CET] <BBB> back then we had only a few, so this was an easy way to wrap it in
[17:12:24 CET] <kierank> 17-bit*
[17:12:32 CET] <BBB> vp9 does 64bit itnermediates
[17:12:36 CET] <BBB> its not so difficult
[17:13:19 CET] <kierank> I'd have to add more templating to simple_idct first
[17:13:45 CET] <BBB> yuck
[17:13:50 CET] <BBB> ohwell
[17:14:09 CET] <nevcairiel> not_so_simple_idct?
[17:18:48 CET] <JEEB> BBB: btw can I get a comment on if I should post https://github.com/mpv-player/ffmpeg-mpv/commit/94e5432e6124192fb81893fc5fd40e26f3e09df4 on the ML?
[17:19:14 CET] <cone-747> ffmpeg 03Philip Langdale 07master:5a0f6b099f3e: avcodec: Fix reference data type for nvdec vc1 hwaccel
[17:19:14 CET] <cone-747> ffmpeg 03Philip Langdale 07master:7c9f739d864c: avcodec: Implement mpeg2 nvdec hwaccel
[17:21:29 CET] <JEEB> of course with the micro going back to 100 instead of staying at 102
[17:21:55 CET] <BBB> uhm...
[17:22:13 CET] <BBB> if you use a parser, you dont need the bsd
[17:22:15 CET] <BBB> bsf*
[17:22:24 CET] <BBB> so, this depends on whether we still auto-insert parsers in lavf
[17:22:31 CET] <BBB> if not, then yes you need this and its ok
[17:22:37 CET] <BBB> if still, this isnt really necessary
[17:22:54 CET] <JEEB> should find a way to check then I guess :V
[17:22:54 CET] <BBB> Im not against it, just saying that parser+bsf is redundant
[17:22:58 CET] <JEEB> yea
[17:22:58 CET] <nevcairiel> wasnt the plan to replace the parser
[17:23:14 CET] <nevcairiel> so you can do streamcopy without the silly re-assembly dance
[17:23:21 CET] <BBB> is the split bsf reviewed by someone who understands vp9?
[17:25:09 CET] <JEEB> not sure of the state of that
[17:25:09 CET] <BBB> yes that was the plan, but I dont know the status
[17:28:57 CET] <BBB> I just noticed if (defined(MACRO)) doesnt work in the same way as if (MACRO)
[17:30:18 CET] <nevcairiel> well they are not the same? :d
[17:41:00 CET] <cone-747> ffmpeg 03Carl Eugen Hoyos 07master:c3b5ea753017: lavf/tcp: Fix the type of the optlen argument to getsockopt().
[17:43:30 CET] <jamrial_> that commit was added at the same time as https://github.com/mpv-player/mpv/commit/cd6f964b567d77c01971277a908824e3b01db86f in mpv
[17:43:46 CET] <jamrial_> he apparently doesn't use lavf, at least not for matroska
[17:45:02 CET] <jamrial_> so enabling the bsf in the decoder allowed him to disable parsing in his demuxer
[17:45:27 CET] <JEEB> yea
[17:46:58 CET] <jamrial_> i'm not sure if the commit jeeb posted is correct/complete if lavf auto inserts the vp9 parser
[17:47:38 CET] <jamrial_> whichever runs first wins and gets to split the bitstream, maybe? :p
[17:48:05 CET] <JEEB> probably
[17:48:38 CET] <nevcairiel> thats how it works, which basically is always the parser
[17:49:01 CET] <nevcairiel> a bsf has some better tools to properly set timestamps though, a parser in the current design is rather limited there
[18:02:24 CET] Action: kierank takes plunge and starts ripping out mpegencctx from mpeg4video/h263
[18:14:15 CET] <rcombs> one day I should finish the matroska edition support
[18:14:22 CET] <rcombs> so mpv can get rid of its internal demuxer
[18:14:37 CET] <atomnuker> kierank: keep in mind using 32 bit inters for dcts and templating will halve simd bandwith
[18:14:43 CET] <atomnuker> so if you can you can try to use pmulhrsw
[18:15:06 CET] <kierank> the coefficients are 32-bit
[18:15:09 CET] <atomnuker> which does 32 bit mults on words but rounds and shifts down, so you don't have to halve bandwidth
[18:15:09 CET] <kierank> not 16
[18:15:11 CET] <atomnuker> oh
[18:15:13 CET] <atomnuker> ok
[18:15:28 CET] <kierank> well they are 17-bit actually with 3 fractional bits
[18:15:50 CET] <kierank> not sure how many bits the dct needs but could cheat and squeeze into 16/32
[18:16:23 CET] <atomnuker> that's nasty, was this how the spec described the coeffs after dequant?
[18:16:57 CET] <kierank> yep
[18:16:58 CET] <kierank> https://usercontent.irccloud-cdn.com/file/PxtUrPw5/image.png
[18:18:34 CET] <kierank> atomnuker: do you know how many bits the dct needs
[18:18:39 CET] <kierank> i've only got it working with float dct at the moment
[18:20:35 CET] <kierank> I would assume coeff * coeff
[18:20:42 CET] <kierank> so 34 bits in my case
[18:22:58 CET] <kierank> hmm maybe not
[18:25:46 CET] <durandal_1707> why "devs" which do no serious work at all are allowed to go to various summits stealing our money in process?
[18:26:28 CET] <atomnuker> because no one else wants to go?
[18:30:07 CET] <kierank> I thought google pay for gsoc summit
[18:30:28 CET] <atomnuker> yep, they do
[18:36:36 CET] <kierank> michaelni: why is ff_print_debug_info2 in mpegvideo.c and not in utils.c or wherever?
[18:39:36 CET] <jamrial_> kierank: it was probably written for mpeg, then shared with other codecs but not moved
[18:40:32 CET] <kierank> will send a patch to move it I guess, it's the first piece of breakage I have 
[18:40:43 CET] <kierank> h264dec depends on mpeg4video.h (!) to pull it in
[18:41:47 CET] <kierank> jamrial_: any thoughts on the best header to put the definition in though?
[18:42:27 CET] <kierank> mpegutils.c/h apparently
[18:43:21 CET] <jamrial_> that or utils.c is fine
[18:57:47 CET] <atomnuker> mpegutils is best I think
[18:58:38 CET] <atomnuker> would also be nice if you renamed it to something like ff_print_mpeg_dbg_info2
[19:01:30 CET] <kierank> really?
[19:03:39 CET] <atomnuker> well, yeah, its pretty much only for mpeg codecs
[19:03:45 CET] <kierank> nope
[19:03:47 CET] <kierank> dirac uses it iirc
[19:03:54 CET] <kierank> or soemrhing
[19:04:13 CET] <atomnuker> no, I'm only seeing it used in h264dec.c and mpegvideo.c
[19:04:15 CET] <kierank> ah no dirac depends on mpegvideo for some reason
[19:04:56 CET] <atomnuker> yeah, dirac needs the dsp stuff for edge padding
[19:17:38 CET] <kierank> damn ML only accepting one of my emails
[19:20:20 CET] <atomnuker> jamrial_: rejoice, +11000 lines of aarch64 code to review
[19:22:56 CET] <atomnuker> looks clean though
[19:24:02 CET] <jamrial_> it's not like i can review or test aarch64 asm...
[19:25:36 CET] <jamrial_> kierank: fix the "No newline at end of file" part of your patch
[19:28:35 CET] <atomnuker> I thought you wrote some for aac (or was that ubitux)
[19:29:08 CET] <jamrial_> it was him, yes
[19:44:22 CET] <kierank> jamrial_: i don't understand, does h264 not pull in mpegutils.c?
[19:44:36 CET] <jamrial_> kierank: no
[19:44:40 CET] <kierank> oh
[19:45:05 CET] <jamrial_> mpegutils.c and mpegvideo.c are only built if "mpegvideo" is enabled in configure, and h264 decoder does not enable it as it doesn't need it
[19:46:03 CET] <jamrial_> hence the CONFIG_MPEGVIDEO check. if mpegvideo was enabled, then h264 decoder it will use that debug function
[19:50:08 CET] <jkqxz> philipl:  VP8 hwaccel hooks for you.
[19:54:58 CET] <jamrial_> jkqxz: feel free to push the opencl stuff whenever you want
[19:57:26 CET] <jamrial_> jkqxz: also, i thought the cuvid hwaccels were "fake" as well?
[19:57:42 CET] <jamrial_> not the nvdec ones, which are called cuvid in libav
[19:57:58 CET] <jkqxz> They are, they are removed.
[19:58:25 CET] <jkqxz> Oh.  I missed the ones in the actual files.  All references to them are removed...
[19:59:29 CET] <jamrial_> ah, nevermind. somehow missed the lines in patch 6
[20:00:01 CET] <jkqxz> No, you're right.  The actual structures haven't gone.
[20:00:40 CET] <jkqxz> Wrt opencl, does that count as a review?  Were you able to test it?
[20:02:08 CET] <jamrial_> no, couldn't get any command line i tried to work :p
[20:02:23 CET] <jamrial_> they all complained about something missing in the filter chain
[20:02:48 CET] <atomnuker> I'll test it tonight
[20:03:17 CET] <atomnuker> after I complete the ritual to summon beignet
[20:03:54 CET] <atomnuker> huh, I already had it installed for hashcat, nvm
[20:05:06 CET] <jkqxz> jamrial_:  Um, it really shouldn't be that bad.  If you're using it in isolation then hwupload/hwdownload around all hardware filters should be sufficient (maybe with a format after the hwdownload if the output format isn't going to match).
[20:05:37 CET] <jamrial_> it's mostly that i don't usually use filters and the syntax can get confusing
[20:10:13 CET] <jkqxz> Fair.  Hardware filters are a pretty huge pain because the negotiation doesn't work properly for them.
[20:12:07 CET] <nevcairiel> so are you telling me i should not work on a d3d11 vpp filter? =p
[20:14:22 CET] <jkqxz> Filter for what?  The builtin processing stuff (deinterlacing in particular) is definitely useful.  Dunno about things as HLSL shaders, though.
[20:15:56 CET] <nevcairiel> yeah deint and scaling
[20:15:57 CET] <nevcairiel> not shaders
[20:19:23 CET] <philipl> jkqxz: yay!
[20:22:18 CET] <jkqxz> I should just do MJPEG as well.  It's silly that we don't have it.
[20:22:41 CET] <philipl> That's the spirit!
[20:24:19 CET] <nevcairiel> dxva specs define a vp8 hwaccel, but i dont know if any gpus expose that. nvidia certainly doesnt, despite having vp8 support through nvdec
[20:25:47 CET] <jkqxz> Surely Intel does?
[20:26:47 CET] <jkqxz> Hmm.  Having demoted my desktop Skylake to windows duty I should actually be able to test that now.
[20:27:32 CET] <jkqxz> I might have a look.  I need to go through AMF again on that machine.
[20:28:46 CET] <atomnuker> jkqxz: how do you specify an opencl device (since hwupload needs it)
[20:32:28 CET] <jkqxz> Needs both -init_hw_device and -filter_hw_device at the moment, unfortunately.  "-init_hw_device opencl=foo:,device_version=Beignet -filter_hw_device foo"
[20:32:45 CET] <jkqxz> I need to write more docs for that.
[20:32:59 CET] <jkqxz> Maybe add an "-opencl_device" option which combines them like "-vaapi_device" does.
[20:34:23 CET] <nevcairiel> does it automatically pass through the device already if you have a decode->filtering->encode chain all on the same device?
[20:34:33 CET] <jkqxz> Yes.
[20:35:09 CET] <jkqxz> That gets carried by hw_frames_ctx.  It's only if you need a source inside the filtergraph (hwupload/hwmap) that you need the extra option.
[20:36:17 CET] <nevcairiel> And I suppose a filter that needs to change the frames ctx (ie. to resize them) also works transparently already? i think we have that for qsv and cuda filtering already..
[20:37:28 CET] <jkqxz> Yeah, those ones make a new frames context for output on the same device as the one they get on input.
[20:38:00 CET] <nevcairiel> Seems like only lazyness stopping me from writing this filter then
[20:38:18 CET] <jkqxz> Yep :P
[20:40:58 CET] <atomnuker> jkqxz: it works!
[20:41:05 CET] <atomnuker> even the vaapi interop works
[20:41:57 CET] <atomnuker> 18% cpu with unsharp_opencl + vaapi
[20:42:03 CET] <jkqxz> You don't need to sound so surprised...
[20:42:42 CET] <atomnuker> its beignet and opencl, the pair go as well together as goat blood and pentagrams :)
[20:43:28 CET] <nevcairiel> so very well?
[20:43:45 CET] <atomnuker> depends on how well versed you're in latin
[20:44:01 CET] <atomnuker> speed is erm... 1/2 of what full CPU decoding and filtering does
[20:44:52 CET] <jkqxz> Heh.  CPU use is lower, though!
[20:45:05 CET] <atomnuker> I guess its useful for people with spare discrete GPUs
[20:45:11 CET] <nevcairiel> in many cases the main advantage is to get the c pu free for something else
[20:45:14 CET] <nevcairiel> not necessarily speed
[20:45:35 CET] <atomnuker> loads of them now though since bch displaced eth
[20:46:28 CET] <jkqxz> Yeah, absolute speed on fast machines isn't really the intent at all here.
[20:50:40 CET] <atomnuker> patches look good to me so feel free to apply all 13 (see, there's evil at work here) of them
[20:50:47 CET] <atomnuker> would be nice to have opencl_device though
[20:51:22 CET] <atomnuker> and add changelog entries for opencl and the filters
[20:51:50 CET] <durandal_1707> what other filter is not reimplemented?
[20:54:18 CET] <jamrial_> tiltshift?
[20:55:44 CET] <durandal_1707> wrong name, deshake
[20:56:15 CET] <durandal_1707> what was quality of that one?
[20:57:41 CET] <durandal_1707> iive: you have nothing to say?
[20:58:19 CET] <jamrial_> tilt shift is not deshake. it's a dof effect
[21:00:18 CET] <durandal_1707> are we talking about same thing? the soon to be removed opencl deshake filter
[21:01:08 CET] <jamrial> ah, then no, we're not talking about the same thing then
[21:01:19 CET] <iive> never used deshake, isn't that a filter that stabilizes picture, using an external library?
[21:08:12 CET] <jkqxz> The filter itself is not being removed.  Only the standalone OpenCL code in it is being removed.
[21:09:54 CET] <durandal_1707> yes...
[21:29:59 CET] <iive> why?
[21:33:23 CET] <iive> what is the problem with it?
[21:34:14 CET] <jkqxz> The opencl deshake code?  It's the only user of the abandoned external API and global state in libavutil.
[21:38:27 CET] <iive> that does sound bad.
[22:35:35 CET] <atomnuker> Gramner: how long does it take for underclocking to stop after an avx512 instruction?
[22:38:23 CET] <Gramner> atomnuker: I don't have those figures, but assuming it's similar to the previous power saving implementation for the upper halves of ymm registers it should be in the order of a few million clock cycles
[22:46:36 CET] <philipl> BtbN: mpeg1 hwaccel sent to list. I forgot that there's a distinct decoder type even though the params struct is shared with mpeg2. Silly.
[22:46:40 CET] <atomnuker> damn, avx512 seems mostly useless for anything to do with encoding
[22:47:08 CET] <atomnuker> because suppose that you avx512 your dcts, your quant code will still be C or if that isn't C your entropy coding code will be
[22:54:35 CET] <jamrial> philipl: because mpeg1 absolutely needs a gpu to decode :p
[22:56:21 CET] <SortaCore> when should HAVE_MMX_INLINE be defined?
[22:56:38 CET] <sfan5> that sounds like something configure finds out and places in config.h
[22:56:38 CET] <nevcairiel> when you build for x86 and the compiler supports that
[22:57:18 CET] <SortaCore> I'm compiling for x86 windows using mingw + msvc toolchain, from windows 10 x64, and it's not defined
[22:57:44 CET] <JEEB> 64bit MSVC doesn't have inline asm, IIRC?
[22:57:53 CET] <jamrial> that's normal, msvc doesn't support inline asm
[22:57:54 CET] <JEEB> also it is MMX so don't worry about it
[22:58:01 CET] <JEEB> jamrial: IIRC 32bit does
[22:58:08 CET] <JEEB> since al ot of legacy stuff has plenty of it
[22:58:11 CET] <JEEB> like avisynth filters
[22:58:31 CET] <SortaCore> and the yuv->rgb accelerated converter >.<
[22:58:45 CET] <Gramner> atomnuker: the current implementation of avx-512 has quite significant limitations, yes. hopefully later implementations on more advanced process nodes will be better
[22:58:47 CET] <jamrial> i'm fairly sure msvc regardless of arch doesn't support gcc style inline asm...
[22:59:09 CET] <SortaCore> it does support some form of inline asm with __asm though?
[22:59:14 CET] <jamrial> but i may be wrong
[22:59:30 CET] <JEEB> yea I'm not sure which style it supports but I *do* know we have plenty of legacy MSVC stuff that has inline asm
[22:59:42 CET] <JEEB> just look at tritical's filters for avisynth
[22:59:47 CET] <JEEB> or avisynth itself
[22:59:54 CET] <nevcairiel> JEEB: it only supports its own syntax, not the one we use, and yeah they axed that in 64-bit
[23:00:01 CET] <nevcairiel> which is probably a good idea =p
[23:00:03 CET] <JEEB> yes
[23:00:08 CET] <JEEB> it totally was
[23:02:15 CET] <SortaCore> so is that warning about missing accelerated conversion basically defunct?
[23:03:02 CET] <SortaCore> all of the x86 code depends on inline mmx define + 6 registers
[23:03:26 CET] <SortaCore> in ff_yuv2rgb_init_x86
[23:05:06 CET] <nevcairiel> swscale is kinda terrible in that
[23:05:13 CET] <nevcairiel> plenty inline asm
[23:23:17 CET] <SortaCore> so best alternative is some snazzy cross-platform C code with no asm?
[23:23:43 CET] <jdarnley> Our inline assembly is GNU style inline.  MSVC has its own style which isn't stuffed into a giant string.
[23:24:01 CET] <JEEB> if the swscale thing is fast enough, then you can just ignore the warning
[23:24:06 CET] <JEEB> it probably is
[23:24:11 CET] <JEEB> I mean, we're talking about MMX asm :P
[23:24:17 CET] <JEEB> and you're building x86_64
[23:24:22 CET] <JEEB> which is SSE2 by minimum
[23:24:36 CET] <jdarnley> But not all mmx has an sse2 equivalent function.
[23:24:43 CET] <JEEB> true
[23:25:24 CET] <JEEB> but swscale is highly likely to be fast enough even without the MXX
[23:25:25 CET] <JEEB> *MMX
[23:26:01 CET] <jdarnley> Does it assume that disabling MMX means all other SIMD is also disabled (like the rest of FFmpeg)?
[23:26:22 CET] <JEEB> just warns that optimized code paths are disabled
[23:27:29 CET] <nevcairiel> i wouldnt say that, pure C is likely quite slow
[23:29:03 CET] <JEEB> oh well, something like zimg then with libp2p (because of course the guy had to troll with the library name for planar2packed)
[23:29:15 CET] <jdarnley> hah
[23:29:51 CET] <nevcairiel> someone should contribute neon for zimg
[23:31:21 CET] <SortaCore> pure C is slower than... whatever it's using now?
[23:31:48 CET] <JEEB> well that's what it's using right now :P
[23:33:26 CET] <c3r1c3-Win> jamrial: Back in the day people had MPEG1 hardware decoders in their computers (usually attached to their CD-ROM drive). I mention this because there exists hardware out there (yes, new and being sold) that is as weak as those Pentium/486 computers (or even weaker)
[23:34:13 CET] <nevcairiel> such hardware doesnt have those hardware accelerators either tho =p
[23:36:25 CET] <c3r1c3-Win> True, but some do and if you remember earlier GPU also had MPEG-1 & 2 decoders
[23:36:32 CET] <c3r1c3-Win> *GPUs
[23:37:38 CET] <atomnuker> I think the sega-cd had an mpeg-1 decoder, the sega saturn had one as a module (not sure if it was released) and the PS1 had one built-in
[23:40:38 CET] <atomnuker> turns out the sega cd didn't, and the saturn's module was released and used
[23:42:35 CET] <atomnuker> and the ps1 needed a separate device to play them too
[23:43:25 CET] <JEEB> yea, I remember people selling those VCD players for PS1
[23:43:35 CET] <JEEB> (in Russia)
[23:45:43 CET] <c3r1c3-Win> I"m not trying to say anything about code or how FFMPEG should by developed, just something of note about the history of this stuff.
[23:46:02 CET] <nevcairiel> we do develop stuff for today, not 20 years ago, so yeah =p
[23:48:05 CET] <SortaCore> welp I better put that on the memo for the previous time-traveller's meeting
[23:53:02 CET] <c3r1c3-Win> LOL
[00:00:00 CET] --- Sun Nov 19 2017