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

[burek]

[00:06:15 CET] <feliwir_> What would be the proper name for a struct shared between Vp3DecodeContext and Vp3EncodeContext? Vp3State seems a little bit weird
[00:12:19 CET] <BradleyS> Vp3SharedContext ?
[00:12:33 CET] <feliwir_> seems good
[00:13:51 CET] <BradleyS> the two most difficult things in computer science: cache invalidation and naming things and off-by-one errors
[00:14:17 CET] <atomnuker> feliwir_: Vp3Context
[00:15:57 CET] <BradleyS> Vp3StructSharedWithVp3EncodeDecodeContexts
[00:16:07 CET] Action: BradleyS runs
[00:16:31 CET] <J_Darnley> are you missing some factory contructors there?
[00:18:21 CET] <BtbN> At least it's not a BoundTreeRewriterWithStackGuardWithoutRecursionOnTheLeftOfBinaryOperator 
[00:19:58 CET] <BradleyS> struct Kevin
[01:03:34 CET] <JEEB> me gets eaten by wchar_t
[01:03:46 CET] <JEEB> why on earth did someone decide to use wchar_t
[04:49:36 CET] <rcombs> JEEB: was it within a #ifdef _WIN32
[05:08:03 CET] <rcombs> wow the lack of PTS generation code in the VC1 parser is kicking my ass
[09:05:04 CET] <JEEB> rcombs: no
[09:05:18 CET] <JEEB> it was probably code that would have only been tested on *nix
[09:05:24 CET] <rcombs> was it wcwidth or wcswidth
[09:05:25 CET] <JEEB> which made it all that much "wut"
[09:05:38 CET] <JEEB> no
[09:05:46 CET] <rcombs> okay I'm fresh out of legitimate reasons to use wchar_t then
[09:06:05 CET] <JEEB> looking at the value it was defined to it looked like either uint16_t or uint32_t
[09:06:12 CET] <JEEB> I think it was 16bit value
[09:06:29 CET] <JEEB> (or 32bit, I was getting tired at that point)
[09:06:58 CET] <rcombs> mmm, 16-bit values in 32-bit arrays(?) for no reason
[09:08:27 CET] <rcombs> I love how wchar_t having implementation-defined size makes it so useless that C(++)11 added char16_t and char32_t
[09:08:43 CET] <rcombs> (which are also mostly useless but at least char32_t's good for some obscure C++ stuff)
[09:11:20 CET] <nevcairiel_> I've only ever used wchar_t in windows code, because you have to. Anywhere else I would gladly stick to UTF8
[09:11:37 CET] <rcombs> on most platforms wchar_t is UTF-32
[09:12:09 CET] <rcombs> which is sometimes useful (like, if you're actually trying to render text), but there you just use int because wchar_t is something completely different on windows
[09:12:33 CET] <rcombs> (and also because there's really no need for a dedicated C type for that)
[09:17:13 CET] <rcombs> it's actually literally defined to be the same as int_least32_t
[09:17:51 CET] <rcombs> erm, char32_t is
[09:18:12 CET] <rcombs> and it's just useless because int32_t exists
[09:18:39 CET] <rcombs> (at least in C++ one could _vaguely_ imagine wanting some sort of overload for char32_t that's distinct from int, since char32_t is explicitly meant for UTF-32, but I can't really think of anything specific)
[09:33:11 CET] <JEEB> rcombs: do you remember if the US closed captions in digital broadcast had language codes?
[09:33:25 CET] <JEEB> or is it just caption slot XYZ
[09:34:17 CET] <rcombs> I don't _think_ they do but I'm not positive
[09:34:34 CET] <feliwir> Btw i saw there is an open ticket for DICOM support in FFmpeg. I work at a company that has a lot to do with DICOM and i've done some DICOM stuff myself. What kind support is wanted there?
[09:35:03 CET] <thardin> feliwir: I'd ask in the ticket
[09:35:19 CET] <rcombs> if they exist, neither VLC nor MediaInfo shows them
[09:35:21 CET] <feliwir> I don't have a ticket login :D
[09:35:33 CET] <JEEB> rcombs: ok, that's what I expect
[09:35:40 CET] <JEEB> thanks for semi-confirming :)
[09:35:46 CET] <thardin> ah. maybe an admin can help :)
[09:36:18 CET] <feliwir> Ah, nvm i'll register
[09:37:17 CET] <thardin> it has open registrations? couldn't find such a form
[09:37:28 CET] <feliwir> In the top right i was able to register
[09:38:30 CET] <JEEB> do tell if you also have issues getting the e-mail. someone else on #ffmpeg noted that their e-mail server never got the confirmation e-mail
[09:43:48 CET] <feliwir> I'd be suprised if someone answers actually
[09:44:05 CET] <feliwir> I saw that this was written our for GSoC sometime, but seems like noone took it
[09:46:09 CET] <JEEB> ah
[09:46:21 CET] <JEEB> does it at least note who wrote that originally?
[09:48:43 CET] <feliwir> ami_stuff
[09:48:54 CET] <feliwir> Which is a user that doesn't really exist 
[13:33:31 CET] <BtbN> perflab1 at nvidia does not sound like a good author
[13:39:22 CET] <JEEB> nope
[13:39:27 CET] <cone-034> ffmpeg 03Timo Rothenpieler 07master:15c639013909: avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
[13:39:28 CET] <JEEB> sounds like missing git configuration
[13:39:28 CET] <cone-034> ffmpeg 03Roman Arzumanyan 07master:f1f66df6a204: avcodec/nvenc: add b_as_ref support for HEVC
[00:00:00 CET] --- Fri Feb 15 2019