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

[burek]

[00:16:07 CET] <BtbN> I still prefer cygwin
[00:16:10 CET] <BtbN> it integrates better
[00:25:44 CET] <nevcairiel> wm4: i can build with a vista level defined on the command line right now, how does the configure pollfd thing exhibit itself?
[00:27:44 CET] <Chloe> BtbN: I thought you could only run cygwin stuff inside of cygwin?
[00:27:55 CET] <Chloe> Why does it integrate better?
[00:28:10 CET] <BtbN> Because you can properly run win32 stuff inside of cygwin
[00:28:28 CET] <BtbN> and you can run a cygwin built binary outside of cygwin, as long as its dependency dlls are there
[00:28:42 CET] <nevcairiel> i've had cygwin mess up my filesystem persmissions before, so i dont touch it again
[00:29:44 CET] <wm4> nevcairiel: if you define it on the command line, the check for pollfd will detect its presence and it works
[00:30:12 CET] <wm4> nevcairiel: it only fails when the w32thread check raises the OS version (after all those checks including pollfd )
[00:30:56 CET] <nevcairiel> on that, isnt that probe_libc thing already raising the version before the w32thread thing?
[00:33:03 CET] <wm4> I remember modifying this
[00:33:19 CET] <wm4> maybe it's because _WIN32_WINNT wasn't set at all
[00:33:37 CET] <nevcairiel> i would think including windows.h would always have it set to something
[00:33:42 CET] <wm4> should it just set the API level even if it's undefined?
[00:34:13 CET] <wm4> it's mysterious to me how that is set in the first place
[00:46:20 CET] <cone-395> ffmpeg 03Karthick J 07master:93a0e478768e: avformat/hlsenc: set EXT-X-TARGETDURATION use lrint(EXTINF)
[00:46:21 CET] <cone-395> ffmpeg 03Karthick J 07master:e3b2c8502b33: avformat/dashenc: avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification
[01:21:31 CET] <jamrial> nevcairiel: on mingw-w64 it's set to 0x502 by default (winxp/2003). on msvc it's apparently set to 0x601 (win7)
[01:26:13 CET] <wm4> yeah that would explain the behavior I've seen
[01:29:54 CET] <jamrial> and mingw32 (old i think dead project) to win98 :p
[01:32:51 CET] <Chloe> jdarnley: yep, configure seems to run really fast in WSL
[01:33:28 CET] <Chloe> This should lessen the pain of making changes to it now, it only takes 5 min (down from ~30 min previously)
[05:18:45 CET] <mistym> When I was looking at adding a new feature, I found a patch for it on trac: https://trac.ffmpeg.org/ticket/3233 I've submitted an improvement, but I was wondering what the best way would be for me to get feedback and help push this over the finish line so the patches can be accepted.
[05:20:39 CET] <wm4> mistym: you pretty much need to send patches to the mailing list
[05:21:20 CET] <mistym> wm4: Ah, okay. Thanks! I'll send them there.
[05:25:16 CET] <mistym> I was also hoping to get advice on the best way to handle writing a header format for a muxer I'm working on.
[05:25:56 CET] <mistym> The format includes a sample table with an entry for every video or audio chunk in the file, located as a part of the header at the beginning of the file. I'm not sure how to reserve enough space though, because the number of video/audio chunks isn't provided up front in libavformat.
[05:28:06 CET] <wm4> yeah, if you really need to know exactly, you'd probably have to buffer all data upfront
[05:29:04 CET] <mistym> Is there a good example for something that does this I could use as a reference?
[07:53:19 CET] <lrusak> jkqxz: is there a way to get a drmprime output for sw decode?
[08:09:33 CET] <wm4> lrusak: what would that even mean?
[08:09:50 CET] <lrusak> it's a moot point
[08:10:38 CET] <lrusak> was just wondering if we could get a drmprime encapsulated buffer from sw decode
[08:11:12 CET] <wm4> you can use get_buffer2, which is designed for using a user provided buffer
[08:11:33 CET] <lrusak> ok interesting
[08:11:52 CET] <lrusak> I'm just wondering how we can fall back if the hw decoder doesn't support decoding a certain format
[08:12:08 CET] <lrusak> say on v4l2, but the driver doesn't support vp9
[08:12:39 CET] <lrusak> can we use the same renderer to set the drm plane directly from the output of ffmpeg sw decode
[08:14:48 CET] <wm4> this could probably be made simple by adding frames allocation to hwcontext_drm, and mapping that for get_buffer2 (but not sure if such a contraption would work out nicer than doing it manually)
[08:15:33 CET] <lrusak> hmm ok :)
[08:15:42 CET] <wm4> hm that assumes drm can use yuv420p, which it probably can't
[08:15:51 CET] <wm4> (likely would use nv12 only or so)
[08:15:57 CET] <wm4> ah whatever
[08:15:59 CET] <lrusak> yes nv12 is typically
[08:16:04 CET] <lrusak> used
[08:16:10 CET] <wm4> so you'd need to copy/repack the data anyway
[08:16:19 CET] <wm4> (and preferably not with libswscale, which is slooow)
[08:16:51 CET] <wm4> sometimes I wonder what (dis)advantages adding nv12 support to sw decoding would have
[08:17:22 CET] <wm4> obviously x264 thought it was worth doing (it accepts nv12 input for encoding)
[08:18:17 CET] <nevcairiel> in the past people have said it might be 1-2% faster, but obviously it would require a lot of work
[10:02:28 CET] <wm4> wbs: I wonder what are our chances to get rid of avformat_network_init()?
[10:03:19 CET] <wbs> wm4: it depends on whether you can do a threadsafe global init of all the supported tls libraries
[10:03:48 CET] <wbs> iirc gnutls should be fine these days, as long as you don't support 2.x versions I think
[10:03:53 CET] <wbs> openssl I dunno
[10:04:46 CET] <wm4> and WSA?
[10:05:19 CET] <wbs> the winsock init itself should be threadsafe and atomically refcounted
[10:05:51 CET] <wbs> i.e. fine to stick in the startup of tcp/udp protocols
[10:06:49 CET] <wm4> for openssl we still use this weird external mutex stuff
[10:07:43 CET] <wbs> yes, that's one thing - I think that can be skipped in modern versions (but do check before removing), but the other question is whether it's safe to run e.g. SSL_library_init from multiple threads at the same time
[10:09:53 CET] <wm4> openssl is such a mess
[10:10:55 CET] <wbs> yup, but at least some of it should be possible to clean up if you drop support for older versions (back when I wrote that in 2011 or so, supporting such old versions were more of a must)
[10:58:13 CET] <jkqxz> lrusak:  It very much depends on what you want to do with the buffers afterwards.
[10:59:03 CET] <jkqxz> If you only want output to scanout on a KMS device, then you can allocate dumb buffers in a common way (I wrote some code for this in <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212547.html>).
[10:59:54 CET] <jkqxz> But, that does still need to know the format, which will involved querying the output device - many things do not support NV12 output.
[11:02:09 CET] <jkqxz> If you want to use the buffers for something else then it quickly becomes system-specific.  You pretty much need to know how allocation works with GEM per-DRM-driver.
[11:05:45 CET] <jkqxz> For some cases you may be able to get GBM to do it, but that is really meant for render targets rather than sources.
[12:32:48 CET] <durandal_1707> can i get fast review of my lut patch?
[12:39:16 CET] <BtbN> wm4, doesn't x264 natively use nv12, and "normal" I420 was added for convenience?
[12:39:49 CET] <wbs> BtbN: yes, but iirc it originally used I420 and they switched the internals at some point
[12:41:43 CET] <jdarnley> durandal_1707: is that "add support for gray formats"?
[12:46:21 CET] <durandal_1707> yes
[12:51:41 CET] <jdarnley> :) not much to it but it looks good to me (I also sent an email)
[13:58:49 CET] <cone-216> ffmpeg 03Paul B Mahol 07master:d2a2bc9a9f30: avfilter/vf_lut: add support for gray formats
[14:09:35 CET] <kierank> rcombs: wm4: can you make ps4 plex play at native refresh rate
[14:09:37 CET] <kierank> kthx
[14:16:08 CET] <durandal_17> what happened to register filter patch set?
[14:23:22 CET] <atomnuker> Chloe's gonna do it as soon as he finishes the lavc one
[14:23:58 CET] <atomnuker> (or me if he can't, I have the gcc/sed hackery to convert REGISTER_FILTER to extern)
[14:29:42 CET] <durandal_1707> Chloe is wasting time by playing games
[14:30:31 CET] <atomnuker> wasn't that called "self-improvement"?
[14:34:01 CET] <iive> atomnuker: btw, what happened with that systemd error? did you fixed it, or you reinstalled?
[14:34:42 CET] <atomnuker> lost my usb flash, got a new one yesterday, wondering what to install, I think I'll go with arch
[14:36:10 CET] <atomnuker> btw is there a filesystem that both linux and mac suppor that has support for more than 4gb files?
[14:36:43 CET] <atomnuker> I got a 128gb flash because it was cheap but I'm not going to make it useless by formatting the whole as fat32, maybe 16gb
[14:45:41 CET] <nevcairiel> ExFAT probably
[14:46:14 CET] <nevcairiel> its the default filesystem for bigger SD cards now
[14:46:44 CET] <Chloe> How have people setup WSL for building ffmpeg? I figured a mingw compiler then: `./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --host-os=mingw32` but then fate doesnt pick up any of the binaries cause they're all .exe
[14:49:54 CET] <durandal_1707> why? use linux
[14:50:10 CET] <Chloe> I cant run VMs, my computer is too slow
[14:50:54 CET] <durandal_1707> Chloe: ask for some ffmpeg sponsoring
[14:54:17 CET] <Chloe> seems a bit excessive just to be able to build ffmpeg, surely someone here is using WSL
[14:56:21 CET] <atomnuker> nevcairiel: exfat works on macs?
[14:56:40 CET] <nevcairiel> if not, you should sue apple for being dumb fucks :)
[14:57:25 CET] <Chloe> atomnuker: afair it does
[14:57:47 CET] <Chloe> Though last I tested it was previous macOS version, my mac has since packed up.
[15:16:52 CET] <RiCOM> atomnuker: it should, that was kinda the point of making it
[15:19:46 CET] <wm4> kierank: I can't make anything at plex anymore, lol
[15:20:11 CET] <kierank> wm4: did you leave?
[15:36:24 CET] <kierank> BBB: http://obe.tv/about-us/obe-blog/item/50-avx-512-what-s-useful-for-us
[15:36:29 CET] <kierank> and others I guess
[15:36:47 CET] <BBB> put it on hackernews :-p
[15:37:07 CET] <kierank> jdarnley needs to check it first
[15:37:10 CET] <mistym> Well, messing up `git send-email` probably wasn't the best first mailing list impression.
[15:37:11 CET] <kierank> and other simd geeks
[15:37:47 CET] <BBB> `pcmpgtq; pand; pandn; por` <- the r is not in a code style
[15:38:03 CET] <kierank> ah
[15:38:03 CET] <kierank> hmm
[15:38:05 CET] <BBB> in the Maximum and minimum of packed signed quadwords can be emulated with `pcmpgtq; pand; pandn; por` and a spare register. paragraph
[15:39:49 CET] <kierank> BBB: ?
[15:39:59 CET] <mistym> For future reference: what's the best etiquette for sending a set of multiple patches as a part of a change? git send-email sent one email for each patch, along with the cover letter, which I'm assuming was bad form on my part.
[15:40:28 CET] <BBB> the code fragment ocurs a few times, wanted to make sure which one I meant
[15:40:37 CET] <BBB> so ignore if you knew what I meant in th sentence before it
[15:40:48 CET] <atomnuker> holy shit opmasks
[15:41:28 CET] <Chloe> mistym: you can get git send-mail to send multiple just by selecting multiple
[15:42:04 CET] <unknowguy> Hi all, I just know a little bit of C and i am thinking to contribute To Ffmpeg , but i am not sure where to start.. https://www.ffmpeg.org/developer.html this page only describes Coding Rules and other stuff....Is there any place i can learn can have a look at overview description of FFMpeg codebase and also i think i need to learn some other things about video encoding,codec etc. any 
[15:42:05 CET] <unknowguy> guide would be appreciated . Thanks
[15:42:58 CET] <durandal_1707> unknowguy: first spell FFmpeg 1000 times
[15:44:01 CET] <unknowguy> :O ? my spelling of FFmpeg is correct
[15:44:13 CET] <atomnuker> unknowguy: not really, I suggest just going into the file of whatever codec you find interesting and playing with it
[15:44:29 CET] <mistym> Chloe: Thanks! What I meant was, was one email per patch fine? Or did I accidentally spam the list? :b
[15:46:23 CET] <Chloe> mistym: what's your patch?
[15:46:52 CET] <mistym> Chloe: Looks like it didn't get posted (might have forgotten to confirm my list membership before sending), but it was the "Sony MPEG with ATRAC-3 audio support" thread
[15:47:32 CET] <Chloe> dont have to be on the list to send to it I think
[15:47:42 CET] <Chloe> your mail setup is probably just broken
[15:48:26 CET] <BBB> unknowguy: most people would suggest finding a feature thats missing and that youre personally interested in, or finding a bug on trac.ffmpeg.org, or something like that
[15:48:28 CET] <mistym> It's a moderated list, got a message about being held since it was from a non-member.
[15:50:52 CET] <Chloe> Compn: ^
[15:51:18 CET] <kierank> jdarnley: do you have HN?
[15:51:21 CET] <kierank> can you post that link
[15:51:30 CET] Action: kierank has to wait 60 minutes
[15:51:42 CET] <BBB> I can post
[15:51:52 CET] <jdarnley> no
[15:52:11 CET] <jdarnley> i was banned for being too negative
[15:52:11 CET] <BBB> nomepost?
[15:52:27 CET] <BBB> https://news.ycombinator.com/item?id=15987796
[15:52:52 CET] <kierank> jdarnley: loooool
[15:53:58 CET] <BBB> what cpus support the new xmm/ymm instructions?
[15:54:10 CET] <BBB> skylake-x also?
[15:55:17 CET] <jdarnley> i think all the cpus  currently support all the not-phi features
[15:56:29 CET] <jdarnley> if that makes sense
[15:57:19 CET] <jdarnley> Gramner has linked to a venn diagram in the past i will try to find it
[15:58:37 CET] <jdarnley> https://twitter.com/InstLatX64/status/870285161979682818
[16:01:24 CET] <kierank> https://www.reddit.com/r/programming/comments/7lhv11/avx512_whats_useful_for_us/
[16:01:28 CET] <kierank> people keep downvoting :(
[16:08:21 CET] <kierank> durandal_17: right, holidays start now, gonna finish ripping out mpegencctx from mpeg4video
[16:12:49 CET] <Chloe> `./configure --samples=fate --arch=x86_64 --target-os=mingw64 --host-os=mingw64 --cross-prefix=x86_64-w64-mingw32-` on WSL leads to `make fate` not adding .exe for tests somehow
[16:20:53 CET] <nevcairiel> try using --target-exec
[16:24:04 CET] <kierank> jdarnley: congrats, hn front page
[16:29:23 CET] <Chloe> nevcairiel: and write a wrapper to tack on .exe?
[16:30:08 CET] <Chloe> no that wouldnt work
[16:38:14 CET] <funman> atomnuker: how did you test rtpdec_rfc4175.c ? I don't see how ffmpeg or ffplay handle SDPs
[16:41:04 CET] <funman> looks like my sdp was incomplete
[16:44:04 CET] <funman> well it crashes imediately
[16:45:27 CET] <funman> doesn't like timestamps fixed at 0 it seems
[17:00:02 CET] <Gramner> BBB / jdarnley: https://twitter.com/InstLatX64/status/918796987352408064 is more up-to-date (with ICL and KNM added)
[17:00:29 CET] <jdarnley> thanks
[17:01:16 CET] <Gramner> with another hundred flags because why not
[17:01:35 CET] <BBB> I feel like I cant keep up with technology anymore
[17:01:41 CET] <BBB> am I an old useless fart now?
[17:02:27 CET] <BBB> maybe I should turn myself in a suit and use expensive empty words
[17:02:37 CET] <Gramner> I guess the old naming scheme of increasing a number and grouping together all new instructions of a new µarch was too simple
[17:03:15 CET] <Gramner> need more things to add as bullet points on powerpoint presentationd
[17:03:26 CET] <BBB> hm& powerpoint
[17:03:58 CET] <jdarnley> they'll make a budget processor that only supports a very limited set, like a pentium not supporting avx
[17:04:40 CET] <kierank> jdarnley: those budget pentiums are not bad
[17:04:46 CET] <Gramner> except intels own guidelines even recommends grouping together flags as baselines
[17:04:53 CET] <Gramner> which is funny
[17:05:01 CET] <kierank> jdarnley: we started shipping those
[17:05:41 CET] <Gramner> no idea how we even should name all the avx512 stuff, because grouping together stuff is required to maintain sanity
[17:08:07 CET] <jdarnley> yeah the pentiums are very nice
[17:09:08 CET] <jdarnley> Gramner: we will cross that bride when we need to
[17:10:43 CET] <Gramner> "whereas vpsraq is 1, 4, or 8 cycles, depending on the precise form used". it's 4 cycles when using a scalar shift value in xmm, otherwise it's 1 cycle. unless you count the latency from memory when using memory operands
[17:11:54 CET] <Gramner> and there's vpsravq if you want variable shifts (instead of using scalar in xmm) which is often more useful and also 1 cycle
[17:12:27 CET] <jdarnley> i thought i read 8 cycles if it had a memory operand
[17:13:27 CET] <jamrial> holy shit, they keep adding extensions
[17:13:43 CET] <jamrial> back in my day we had f, bw, dq, vl, and we liked it
[17:13:44 CET] <Gramner> counting latency of memory operands is kind of iffy because it depends on where in the memory hierarchy your'e reading from and if any caches or memory buses are overloaded with other loads/stores
[17:14:32 CET] <Gramner> maybe it's swapped to slow disk, with a billion cycle latency
[17:14:34 CET] <jdarnley> true but i would guess that 8 is a best case
[17:14:49 CET] <atomnuker> funman: I haven't tested it
[18:24:33 CET] <wm4> Gramner: so no CPU supports all of AVX?
[18:24:44 CET] <Gramner> correct
[18:25:04 CET] <wm4> I'm sure that's great for development...
[18:25:15 CET] <nevcairiel> the phi and consumer sets are quite distinct in usage
[18:42:35 CET] <Chloe> jdarnley: did you setup ffmpeg on WSL?
[18:53:28 CET] <jamrial> wm4: a bunch of those extensions are useless for multimedia anyway
[18:55:19 CET] <jdarnley> Chloe: no i dont use win 10
[19:39:37 CET] <kierank>  not found eval: wmv3_vdpau_hwaccel
[19:39:39 CET] <kierank> what does that mean
[19:43:36 CET] <jamrial> where did you get that?
[19:43:57 CET] <kierank> trying to compile ffmpeg edited on windows using a linux guest vm
[19:44:05 CET] <kierank> in configure
[20:09:05 CET] <wm4> there doesn't seem to be anything unusual about that symbol
[20:09:32 CET] <wm4> hm except that it's somehow messed into the vc1 code
[20:13:24 CET] <jamrial> wmv3_vdpau_hwaccel implies (aka, enables) vc1_vdpau_hwaccel in configure
[20:14:45 CET] <wm4> as it should be
[21:39:07 CET] <wm4> nevcairiel, jamrial: is this ok for the windows thread configure changes? https://0x0.st/s8b8.bin
[21:39:21 CET] <wm4> I'm not liking that redundancy much
[21:41:45 CET] <jamrial> i don't think that check at the end of probe_libc is needed
[21:42:44 CET] <jamrial> you're already forcing _WIN32_WINNT to be at least 0x600 on mingw32, mingw-w64 and msvc
[21:43:17 CET] <jamrial> i don't think it's possible for that check to succeed and call die()
[21:44:54 CET] <wm4> I can drop it
[21:45:34 CET] <jamrial> that'd be best
[21:45:47 CET] <wm4> https://0x0.st/s8bc.diff
[21:45:55 CET] <wm4> (paste should have a correct mime type now)
[21:46:41 CET] <wm4> time to actually test this
[21:46:50 CET] <wm4> which will take ~30 minutes (blergh)
[21:59:39 CET] <kierank> wm4: how do I make s->avctx->hwaccel->decode_mb(s); not take MpegEncContext?
[22:03:01 CET] <wm4> I think xvmc is the only thing that uses this
[22:03:29 CET] <wm4> mpegvideo_xvmc.c
[22:04:36 CET] <wm4> so either argue for removing that (will probably fail on iive), or refucktor it
[22:06:40 CET] <wm4> iive: is that still needed?
[22:46:26 CET] <jamrial> kierank: make decode_mb() pass an avcodeccontext instead?
[22:47:00 CET] <kierank> ok, it's one of the many changes i need to make
[22:47:11 CET] <wm4> it'd still need to access lots of internal mpegvideo state
[22:47:15 CET] <wm4> and it's hard to test
[22:47:25 CET] <wm4> I mean how do you even run xvmc, even if you have a linux machine
[22:55:40 CET] <Chloe> Is there any real benefit to xvmc over stuff like VA-API and VDPAU?
[22:57:09 CET] <wm4> if you have really really old hardware
[22:57:10 CET] <wm4> (???)
[22:58:54 CET] <Chloe> I mean, we're dropping XP support, xvmc shouldnt be too dissimilar
[23:05:13 CET] <wm4> I wouldn't have a problem with dropping it
[23:08:50 CET] <Chloe> I doubt there would be much opposition, I reckon just submit a patch
[23:10:20 CET] <wm4> iive is the maintainer of it, so I suppose it depends on his consent
[23:10:57 CET] <iive> is there any reason to drop xvmc? AFIR there was some reason to drop XP support.
[23:11:16 CET] <iive> It is working and I do maintain it.
[23:11:20 CET] <wm4> kierank wants to unmess mpegvideo
[23:11:38 CET] <wm4> because currently it's one monolithic big thing that can't be extended
[23:11:44 CET] <iive> well, then unmess it.
[23:12:01 CET] <wm4> nobody can test xvmc exceot you
[23:12:04 CET] <wm4> *except
[23:12:11 CET] <wm4> you're probably the only user too
[23:14:27 CET] <iive> it doesn't requre anything special. standard mplayer, radeon with mesa3d or nvidia with binary drivers (last time they still provided it).
[23:15:15 CET] <iive> i had some bugreports from intel drivers, no idea if they still provide it, i guess mesa3d too.
[23:15:54 CET] <wm4> and just what is this still useful for
[23:16:05 CET] <wm4> nvidia binary drivers provide no less than 2 better APIs
[23:16:12 CET] <wm4> so do mesa and intel
[23:17:00 CET] <iive> as I said, if kierank wants to unmess mpegvideo, then he could feel free to break xvmc
[23:17:27 CET] <iive> I'll try to fix if possible, and if not possible then feel free to scrap it.
[23:17:51 CET] <wm4> kierank: ^
[23:18:02 CET] <wm4> that sounds reasonable
[23:26:57 CET] <kierank> there's going to have to be a lot of templating it seems
[23:30:30 CET] <iive> this doesn't sound good. i just hope you are not going to baloon the generated code.
[23:34:05 CET] <kierank> definitely will
[23:34:14 CET] <kierank> it's the only way to get 10-bit mpeg-4 in 
[23:36:05 CET] <iive> i doubt that.
[23:36:15 CET] <kierank> it is
[23:36:29 CET] <kierank> let me know how you're going to get 10-bit video into mpegvideo.c
[23:36:41 CET] <kierank> without ugly hacks
[23:38:23 CET] <iive> are there any other differences than the size of the block elements?
[23:39:44 CET] <iive> pixel buffers and MC stuff.
[23:40:11 CET] <kierank> coefficients
[23:40:22 CET] <kierank> a pcm mode
[23:41:44 CET] <iive> well, coefficients are stored in block elements.
[23:43:11 CET] <kierank> the coefficients are larger than the native data type
[23:43:18 CET] <kierank> coefficients are 17-bit
[23:43:33 CET] <iive> sure
[23:44:00 CET] <iive> i guess you use int[64] instead of short[64] for blocks
[23:45:50 CET] <kierank> easy to say
[23:46:08 CET] <Compn> reddit is a terrible place to have a discussion
[23:46:21 CET] <Compn> since people think downvotes are a disagreement button heh
[23:46:37 CET] <iive> Compn: it is, no matter what the instructions say :D
[23:47:02 CET] <Compn> :P
[23:49:27 CET] <kierank> wm4: might give up for the second time, mpegencctx affects so much code
[23:50:14 CET] <wm4> write a new decoder (possibly using old parts), make it pass fate, remove the old decoder from mpegcrap
[23:50:19 CET] <iive> kierank: you should try to use mpegencctx instead. e.g. decode_mb() is function pointer
[23:50:21 CET] <wm4> not sure if that's doable
[23:50:32 CET] <kierank> not possibble
[23:50:42 CET] <iive> it means that it can have decode_mpeg4_8bit and decode_mb_mpeg4_16bit functions
[23:50:48 CET] <wm4> too many weird corner cases in fate?
[23:50:54 CET] <kierank> too many weird codecs
[23:51:00 CET] <iive> MC is already in function pointers
[23:51:08 CET] <wm4> hey they managed with h264 too
[23:51:53 CET] <kierank> wm4: yeah but there's no h264 encoders
[23:51:57 CET] <kierank> of dozens of variants
[23:52:02 CET] <kierank> that's why it's doable
[23:52:16 CET] <kierank> iive: int (*decode_mb)(struct MpegEncContext *s, int16_t block[6][64])
[23:53:35 CET] <wm4> encoders? also why the shit is MpegEncContext used by decoders
[23:53:44 CET] <iive> kierank: you can replace the second one with a single pointer. e.g. xvmc uses pblocks that is just pointers to the block structure.
[23:54:13 CET] <kierank> wm4: tens of thousands of lines of code reuse
[23:56:11 CET] <iive> there was a time when int16_t was DCTelem or something like that.
[23:57:09 CET] <iive> kierank: if we make int32_t block[][] for all codecs, how much more code will you need to implement 10bit mpeg4 decoding?
[23:57:22 CET] <kierank> pcm blocks
[23:57:31 CET] <kierank> how do you decode in-place without a dct
[23:58:00 CET] <iive> dct that does nothing?
[23:58:31 CET] <iive> i already do that for xvmc, since I need the raw coefficients.
[23:58:39 CET] <kierank> not possible without memcpy
[23:58:54 CET] <iive> pblocks
[23:59:21 CET] <kierank> completely undocumented
[00:00:00 CET] --- Sat Dec 23 2017