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

[burek]

[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=88414783bc8001bb39f7f53e02aa6731dae403ab;hb=HEAD
[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