[00:48:49 CET] <atomnuker> FUCK avconfig.h [00:48:53 CET] <atomnuker> FUCK IT WELL [00:49:00 CET] <atomnuker> who thought this was a good idea [00:49:08 CET] <JEEB> \o/ [00:49:25 CET] <atomnuker> lets have a second configure file [00:49:32 CET] <atomnuker> for each fucking library [00:49:46 CET] <nevcairiel> the big difference is that its installed [00:49:48 CET] <atomnuker> which contains the same fucking things as the main one [00:49:54 CET] <nevcairiel> many projects have an installed version file or something [00:50:03 CET] <nevcairiel> and it contains hardly the same things [00:50:09 CET] <nevcairiel> avconfig.h has only a handful of lines [00:50:18 CET] <atomnuker> yes, but they're all from config.h [00:51:08 CET] <nevcairiel> the point is its hardly special to have an installed version/build info file [00:52:45 CET] <atomnuker> why does gcc not error out when libavutil/avconfig.h doesn't exist in any way, shape or form but if I do #include "I_DONT_EXIST.h" it does [00:53:58 CET] <atomnuker> oh god its using the system installed header [00:57:25 CET] <iive> is avconfig.h a new thing? i don't remember seeing it. [00:57:36 CET] <iive> is it ffmpeg thing, or merged? [00:58:02 CET] <nevcairiel> it exists since forever and on both sides long before the split [00:58:43 CET] <iive> hum... [00:59:24 CET] <JEEB> yup [00:59:33 CET] <JEEB> avconfig.h has been there in different libs for quite a while [00:59:56 CET] <JEEB> or well, it's included from avutil generally [01:00:31 CET] <iive> so there is one avconfig.h for all libraries? [01:00:57 CET] <iive> ops [01:01:27 CET] <iive> not separate different one for each library? [01:01:34 CET] <nevcairiel> yes libavutil/libavconfig.h, its global for all of them [01:01:59 CET] <nevcairiel> it contains a few system-dependent defines needed by public headers [01:02:00 CET] <iive> ok, then it's just a config.h, changed to be installed [01:05:03 CET] <atomnuker> yay, it works, I can now fully compile lavu and enable/disable options [01:06:10 CET] <atomnuker> I'll need to do an ugly fucking hack and move avtime.h (the renamed time.h) to time.h when installing though [01:07:39 CET] <atomnuker> how is deprecation going to work? keep 2 copies (avtime.h and time.h) around? [01:07:54 CET] <nevcairiel> shit worked before, why cant you make it work again [01:08:13 CET] <nevcairiel> clearly compilers can figure it out given the proper options [01:12:34 CET] <atomnuker> yeah, I guess I can copy the system time.h heder to the build directory [01:14:08 CET] <atomnuker> nope, guess not [01:47:07 CET] <atomnuker> pushed to exp_meson on my repo, someone else can take a look at it if they want to [01:47:54 CET] <atomnuker> reported a bug to meson but I bet you they'll say "not our bug, its ninja's fault" and then that'll go nowhere because that's google's turf [01:48:09 CET] <JEEB> yea, that's the worst case with google projects [01:48:36 CET] <JEEB> might take a look later since it seems like it could be quite useful for systems like windows not having configure times of 10min :P [01:48:53 CET] <atomnuker> it'll still take a while though [01:49:17 CET] <atomnuker> a lot of the time is spent compiling over and over again for each individual math function [01:49:52 CET] <atomnuker> so erf, erf2, erf2f, log10f, cosf, powf, llrint, llrintf, rintf, and so on [01:50:08 CET] <rcombs> nevcairiel: atomnuker: at least it's not pyconfig.h [01:50:21 CET] <nevcairiel> the endless forking of sub bash processes is whats really making it slow on windows, not the compile tests [01:50:39 CET] <rcombs> which is literally python's config.h, but installed [01:50:58 CET] <atomnuker> I thought it was the forking for the compiling tests, but oh well [01:51:23 CET] <atomnuker> in total there's exactly 45 tests done just for lavu [01:51:29 CET] <rcombs> it defines _GNU_SOURCE and _XOPEN_SOURCE and such [01:51:31 CET] <JEEB> that's not too fast enough, but the bash stuff is the really bad stuff [01:52:03 CET] <JEEB> and yes, I am under no illusion that it is usable yet :) [01:52:05 CET] <rcombs> unconditionally, too, so if you define them to the correct values before including it, you get redefinition errors [01:52:21 CET] <JEEB> the configure system in FFmpeg is just so complex :P [01:52:58 CET] <rcombs> and oh boy, are we replacing configure in ffmpeg [01:53:03 CET] <rcombs> that'll be fun for me [01:53:08 CET] <atomnuker> why? [01:53:35 CET] <rcombs> I have a lot of configure patches in my fork [01:53:56 CET] <rcombs> most notably the concept of external components [01:53:59 CET] <JEEB> don't worry, the script isn't going anywhere any time soon [01:54:07 CET] <JEEB> given its size/features [01:54:22 CET] <JEEB> I think this is closer to "let's see if this makes any sense" [01:54:28 CET] <JEEB> PoC in a sense [01:54:43 CET] <rcombs> I made every codec a tri-state, with external being "built, but not included in the main lib, and instead emitted as a separate .so" [01:55:11 CET] <rcombs> so you can imagine my chagrin when runtime codec registration vanished [01:55:22 CET] <nevcairiel> that sounds like a weird concept [01:56:00 CET] <rcombs> patents are bad, news at 11 [01:56:28 CET] <JEEB> right, so you could have an all-enabled build with things build as separate libs [01:56:36 CET] <JEEB> and then distro parts of those [01:56:40 CET] <rcombs> yup [01:56:56 CET] <rcombs> and only pay for what users actually end up using [01:57:01 CET] <rcombs> much safer [01:58:45 CET] <atomnuker> I know rcombs has to encode files by feeding them into a binary encoder one chunk (as a wav file) at a time and then reading the written wave files [01:59:01 CET] <rcombs> yeah and it makes me hate myself [01:59:22 CET] <JEEB> reminds me of aac2wav [05:44:32 CET] <cone-779> ffmpeg 03James Almer 07master:f4709f1b7b90: configure: add missing audio_frame_queue dependency to vorbis encoder [11:48:45 CET] <durandal_170> is it me, or this year students are extremly impatient and lazy? [12:22:28 CET] <SortaCore> isn't that all students durandal [12:32:51 CET] <J_Darnley> Can someone explain how a parser works in ffmpeg? [12:33:17 CET] <J_Darnley> I need to add features to the dirac parser. [12:33:39 CET] <wm4> like a BSF, except they can also access a weird dummy AVCodecContext to set parameters parsed from the packet data [12:33:43 CET] <J_Darnley> But I don't know a thing about them. [12:34:03 CET] <J_Darnley> I don't know thosework either. [12:34:36 CET] <J_Darnley> How does it signal to everything else what bytes should be grouped into one frame? [12:34:59 CET] <nevcairiel> it buffers that internally [12:35:19 CET] <wm4> well it returns 1 packet at once [12:35:48 CET] <wm4> so if you're feeding it parts of a packet, it'll buffer that as nevcairiel said, and return it all once it knows there's a packet boundary [12:36:17 CET] <wm4> though sometimes it might expect that you feed it complete packets, based on the settings [12:36:20 CET] <nevcairiel> basically you call ff_combine_frame from within the parser with the appropriate parameters [12:36:56 CET] <nevcairiel> best to just look at one of the existing ones [12:37:43 CET] <J_Darnley> The dirac one does exist so maybe I need to ask atomnuker about the specifics of it. [12:38:06 CET] <J_Darnley> I notice that it doesn't call ff_combine_frame [12:38:31 CET] <nevcairiel> yeah it seems to do some complicated nonsense [12:38:38 CET] <nevcairiel> either dirac is a terrible format, or someone was naughty [12:38:51 CET] <J_Darnley> "complicated nonsense" is just dirac all over. [12:39:14 CET] <wm4> some parsers are only used to "analyze" the data [12:39:26 CET] <wm4> so libavformat can export all codec parameters or whatever [12:39:45 CET] <wm4> so this kind of parser would just take a packet and return it as is [12:40:56 CET] <atomnuker> J_Darnley: if the container or lavf or whatever supports PARSER_FLAG_COMPLETE_FRAMES then the parser is essentially bypassed and the frames are assumed to be unfragmented [12:41:03 CET] <J_Darnley> Oh wait, there is also the dirac demuxer. [12:41:17 CET] <atomnuker> so if you demux dirac in mkv that's what you'll get [12:41:36 CET] <atomnuker> otherwise it'll buffer and attempt to find something that looks like a frame [12:41:48 CET] <atomnuker> and once it does it'll splice parts together to make a packet [12:41:56 CET] <atomnuker> inefficient [12:42:17 CET] <atomnuker> I assume you want to modify it so that it accepts 2 fields as 0's, right? [12:42:29 CET] <atomnuker> (its the only reason why anyone would want to look at it anyway) [12:42:36 CET] <J_Darnley> Not yet. [12:42:45 CET] <J_Darnley> I need to add fragment support to it. [12:43:39 CET] <J_Darnley> And fragment means something in a dirac stream. (to those unfamiliar with it) [12:47:22 CET] <J_Darnley> Oh thank god. The dirac demuxer doesn't actually do anything. It is just a "wrapper" on top of a raw demuxer [12:49:00 CET] <atomnuker> from what I can see the parser scans each fragment for whether it contains something that looks like an end, and if not it'll append it to a growing buffer until it does find an end [12:49:32 CET] <atomnuker> if it does find something like an end it'll do some checking to see if the offset matches to the size specified in the start of a frame [12:49:44 CET] <atomnuker> and if it does, it outputs the packet, else it keeps buffering [12:50:49 CET] <atomnuker> not sure how it would work with slices (dirac fragments) [12:50:52 CET] <wm4> yeah, for raw demuxers like this you always need a packet splitting parser [12:51:01 CET] <atomnuker> maybe you should look at the h264 parser [12:51:24 CET] <nevcairiel> h264 is easy, it has clear start codes and frame/slice boundaries [12:51:36 CET] <nevcairiel> from looking at the dirac parser, either the author was insane, or the format is [12:51:53 CET] <wm4> maybe both? [12:54:51 CET] <atomnuker> well consider this: the identifier for all boundaries is 'BBCD', 32 bits, and packets are usually huge and golomb coded [12:55:49 CET] <nevcairiel> aliasing protection? [12:56:15 CET] <nevcairiel> thats the only thing that saves h264, the startcode can never be aliased in the data anywhere [12:56:30 CET] <J_Darnley> None, as far as I know. [12:56:45 CET] <atomnuker> the only protection is that there's a 32 bits for the previous unit offset, and 32 bits for the next unit offset [12:56:46 CET] <J_Darnley> There is more in the header that you sould use as a sanity check [12:57:08 CET] <atomnuker> so if the start <next> offset matches the end <previous> offset, they match [12:57:20 CET] <atomnuker> but here's the thing: they're both allowed to be 0 [12:57:34 CET] <atomnuker> if its a stream without an end [12:58:22 CET] <J_Darnley> And that is despite the spec saying this "The encoded stream forms a doubly-linked list with each picture header indicating an offset to the previous and next picture" [12:59:19 CET] <nevcairiel> ie. its not really designed for random bitstream access? [12:59:35 CET] <atomnuker> and its not like 32bits of 'BBCD', then 64 bits of 0s is uncommon since slices are padded (by huge amoutns) and aligned to the nearest byte [13:01:44 CET] <nevcairiel> i mean its fine if its not, not all codecs are, its only a problem if you try to use it in a manner where this would be required. vp9 would be really hard to re-packetize if you saved it as a raw stream, so people just dont do that [13:03:43 CET] <SortaCore> https://trac.ffmpeg.org/ticket/6996 what's going on with this ticket [13:17:22 CET] <jdarnley> I need to read more but I am getting the impression that the parser expects a Picture data unit (which spans many buffer lengths) to be followed by an End Sequence. [13:18:14 CET] <jdarnley> Whereas a stream with Picture Fragments will have many small data units [13:19:31 CET] <atomnuker> yep, that's what the parser expects [13:19:55 CET] <atomnuker> what does the decoder expect? slices or full frames? [13:21:07 CET] <jdarnley> My hacked up branch supports a single slice. [13:21:21 CET] <jdarnley> But my hacked up branch is unreliable. [13:22:09 CET] <atomnuker> JEEB: yay, its not a ninja bug - https://github.com/mesonbuild/meson/pull/3142 [13:22:30 CET] <atomnuker> though I don't know how many compilers support -idirafter [13:24:01 CET] <atomnuker> icc/gcc/clang all do but meson apparently supports msvc 2015 [13:25:38 CET] <JEEB> atomnuker: cool [13:56:56 CET] <nevcairiel> atomnuker: how does the current makefiles set this up so this is never a problem, and why cant this just be the same way? [13:58:04 CET] <atomnuker> not sure, I don't think it includes -I ../libavutil (if building to a separate directory inside the repo) and I can't change or remove cflags included by the build system [13:59:05 CET] <atomnuker> nope, apparently not even building outside the repo will work [14:02:29 CET] <nevcairiel> there is implicit_include_directories (boolean) which sounds like you might be able to suppress that include [14:09:50 CET] <wbs> atomnuker: the normal build system never adds the libav* directories to the include path, only the base dirctory [14:10:07 CET] <wbs> so everywhere you need to include it by libavutil/time.h to actually get that file [14:10:18 CET] <atomnuker> except in lavu itself [14:10:29 CET] <wbs> yes, but there you can distinguish with <time.h> vs "time.h" [14:12:02 CET] <atomnuker> nevcairiel: wow, that worked, thanks [14:14:44 CET] <nevcairiel> that particular flag requires meson 0.42, in case you are keeping track of a minimal version [21:41:14 CET] <vrd> hi can anyone direct me towards how to read in an image in ffmpeg? Thanks in advance! [21:41:40 CET] <JEEB> that's for the users' channel [21:42:06 CET] <wm4> same as videos, but yeah what JEEB said [21:43:31 CET] <vrd> Okay, but I'm trying to implement a filter, and wanted to know how to use my filter inside ffmpeg for an image [21:44:37 CET] <JEEB> well testing your libavfilter filter should be possible with just the ffmpeg.c application [21:44:41 CET] <JEEB> no need to make your own API client for it [21:45:17 CET] <BBB> what have you tried? if the question is more specifically about AVFrame, maybe its OK to ask [21:45:29 CET] <vrd> Okay ,Thanks :D [21:46:00 CET] <vrd> Yeah , its more of the AVFilterContext,AVFrame jargon [21:46:11 CET] <JEEB> ok [21:46:40 CET] <JEEB> I think I linked this somewhere as a random libavfilter filter that isn't too long [21:46:43 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_chromakey.c;h=... [21:46:52 CET] <JEEB> it has the basic struct at the end [21:47:10 CET] <JEEB> and the basic functions that the function pointers in the struct point to [21:49:48 CET] <vrd> Getting it a little,Thanks! [23:23:09 CET] <greentea> Can I ask about help with configuring and building FFmpeg for windows x64 using msvc? (also with libvorbis, libogg) [00:00:00 CET] --- Tue Feb 27 2018