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

[burek]

[04:16:57 CET] <lf94> Hey, for some reason av_find_decoder is failing when trying to find h264. Now I have no idea why it would fail because all sources point to me having this format is built in / available
[04:17:18 CET] <lf94> I'm guessig that maybe the code I'm looking at doesn't call some function to fill what codecs are available
[04:17:35 CET] <lf94> https://www.ffmpeg.org/doxygen/2.7/libavcodec_2utils_8c_source.html <- here I see first_avcodec starts as NULL, but I can't find where it gets initialized.
[04:26:01 CET] <lf94> Ah ha!!
[04:26:10 CET] <lf94> avcodec_register_all();
[11:47:07 CET] <BtbN> lf94, register_all is deprecated, unless you are using a really old version, it does nothing.
[12:03:28 CET] <j-b> Isn't the new codec missing version.h bump?
[12:04:04 CET] <durandal_1707> j-b: that is added as last step before pushing
[12:05:42 CET] <Lynne> can agree, the vulkan patchset carries the version bump along with it and every pull I have to fix conflicts
[12:31:58 CET] <kurosu> regarding the cached bitstream reader (or whatever implementation, either libav or ffmpeg), I did see speed improvements on both x86_32 and x86_64, although the former could have further optimization (like, peeking at 32 bits when < 16 is probaly sufficient - dunno about malformed bitstreams)
[12:34:08 CET] <Lynne> I don't understand how it isn't always faster, even in the worst case it should save instructions
[12:36:57 CET] <kurosu> current implementation is 64bits cache, which requires compiler being smart in its emulation
[12:37:24 CET] <kurosu> but most such codecs (lossless or near lossless) indeed should see such a benefit
[12:39:58 CET] <Lynne> it shouldn't be difficult to make it a 32 bit cache though
[12:40:20 CET] <kurosu> Yes, just need someone having a reason to do it
[12:40:53 CET] <kurosu> Also done in dav1d, but which one is used is unconditional
[12:41:17 CET] <JEEB> does the unregistered sei UUID 162,229,107,0,67,99,70,214,162,70,210,91,146,163,98,89 strike anyone as familiar?
[12:41:28 CET] <kurosu> *to do it, or publish his patches :D
[12:41:31 CET] <JEEB> it's some dolby thing and I am guesstimating it's the dynamic metadata
[12:42:29 CET] <JEEB> I have ST.2094-1 and -10 but conveniently neither of them seem to define the SEI message ID
[16:19:59 CET] <JEEB> alright. any opinions on where to stick non-ITU AVColorspace entries? either over 255 because the ITU enum is 8bit (currently) or negative (but we already have things indexing with the enum values)
[16:20:18 CET] <JEEB> zimg took the negative value approach apparently
[16:28:37 CET] <durandal_1707> JEEB: +666
[16:30:05 CET] <JEEB> durandal_1707: I like your positive attitude. noted
[16:31:28 CET] <durandal_1707> JEEB: if starting from +666 is to evil to you, use 1707 number
[20:16:54 CET] <durandal_1707> Compn: you still awake?
[22:50:05 CET] <cone-895> ffmpeg 03Andreas Rheinhardt 07master:4470ab1e0ee1: avformat/matroskaenc: Fix potential leak of cached packet
[22:50:05 CET] <cone-895> ffmpeg 03Andreas Rheinhardt 07master:6eb88daed105: avformat/matroskaenc: Remove outdated comment
[00:00:00 CET] --- Mon Nov 25 2019