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

[burek]

[00:54:18 CET] <pi-> pink_mist: https://unix.stackexchange.com/questions/28803/how-can-i-reduce-a-videos-size-with-ffmpeg
[00:55:59 CET] <pink_mist> pi-: you have two -vcodec arguments though
[00:56:05 CET] <pink_mist> pi-: it doesn't make sense
[00:57:05 CET] <pi-> my bad
[00:57:11 CET] <pi-> It seems the second one overrides
[00:57:17 CET] <pi-> tho
[05:07:17 CET] <utack> what the hell is going on with webp...lossless animated webp comes out 250kb, "quality 50" webp comes out at 1mb and looks totally blurred
[05:09:17 CET] <kepstin> iirc, the lossless mode in webp is basically a completely different format from the lossy mode. That sort of difference isn't really surprising if you're doing something like pixel art.
[05:09:47 CET] Action: kepstin would probably recommend a vp9 webm, possibly in lossless mode, instead of webp for animations.
[05:12:15 CET] <utack> kepstin that is exactly what i tried yeah, pixel art. i suspected it works well as webp animated
[08:32:02 CET] <fling> Can I somehow add rtc data to a stream?
[08:32:13 CET] <fling> I want to know the exact time of the stream capture start.
[14:56:04 CET] <danieel> any tip how to merge all the dash segments i have downloaded?
[14:56:13 CET] <danieel> got separate audio and video streams
[14:59:54 CET] <pink_mist> I just let youtube-dl do it for me
[15:01:12 CET] <danieel> will youtube-dl work for our ad-equpped local/nation TV website?
[15:03:22 CET] <danieel> well.. its doing something
[15:06:10 CET] <pink_mist> usually
[15:06:45 CET] <pink_mist> https://rg3.github.io/youtube-dl/supportedsites.html it supports quite a number of sites
[15:08:00 CET] <danieel> thanks! was not aware of that
[16:25:59 CET] <th3_v0ice> How is ffmpeg handling the timestamp wrap around? I guess 32bit timestamps will run out pretty quickly, what happens then?
[16:26:52 CET] <th3_v0ice> For example if a timebase is 1/90000
[16:27:22 CET] <Mavrik> IIRC internally timestamps are 64-bit
[16:27:50 CET] <Mavrik> And there are wraparound handling modes for some demuxers which try to do the smart thing when expanding timestamps to 64-bit
[16:28:05 CET] <Mavrik> But generally ffmpeg handles timestamp wraps and jumps rather poorly :)
[16:38:04 CET] <JEEB> lavf has wrap-around handling but for MPEG-TS for some reason it onl works once
[16:38:30 CET] <JEEB> after that if you're using ffmpeg.c the left-over wrapping logic there will instead attempt at doing things
[16:38:56 CET] <JEEB> which is less than perfect since that thing only checks if the intra timestamps went more than 5 or 10 seconds forwards/backwards
[16:39:47 CET] <JEEB> if I had time I'd check what the lavf wrap-around logic is herping a derp with
[16:39:59 CET] <JEEB> because it's a weird feeling when the first case gets handled "for free"
[16:40:08 CET] <JEEB> but then suddenly the API consumer has to care afterwards
[16:44:33 CET] <Mavrik> Yeah, I had to patch a few things to get MPEG-TS working reliably
[16:44:37 CET] <Mavrik> There's also things like vs
[16:44:45 CET] <Mavrik> vf_fps not considering the wrap-around case
[16:44:49 CET] <Mavrik> And some other filters as well
[16:45:01 CET] <JEEB> at the point of the filter there really should not be wrap-arounds
[16:45:11 CET] <JEEB> if any wrap-arounds get to that point something's failed
[16:45:49 CET] <Mavrik> It
[16:45:55 CET] <Mavrik> Eh, sorry, broken keyboard.
[16:46:07 CET] <Mavrik> Anyway, non-linear PTS/DTS are a thing in most TV live streams I've seen
[16:46:12 CET] <Mavrik> Which are a similar case :)
[16:46:50 CET] <JEEB> you mean there being a reason for a timestamp jump? which is mostly some seconds forwards or so?
[16:47:08 CET] <Mavrik> I've seen jumps all over the place since the providers spliced streams together
[16:47:35 CET] <JEEB> yes, that I see mostly with subtitle tracks and  you generally can fix that by adding "drop subtitle packets until PCR has been received"
[16:47:55 CET] <Mavrik> I've seen it with all tracks - e.g. local video providers splicing in localized commercials
[16:48:12 CET] <Mavrik> So you get a PTS/DTS jump (which is unrelated to previous stream) for a few minutes in your stream
[16:48:20 CET] <Mavrik> On all streams not just the subtitles
[16:48:39 CET] <Mavrik> Or jumps only on audio track for no apparent reason
[16:48:58 CET] <JEEB> yea, the subtitle stuff I mostly see when some people decide it's a good idea to mux in dvb subs or teletext from another version of the channel
[16:49:06 CET] <JEEB> and not fixing PTS
[16:49:24 CET] <JEEB> so until you receive PCR lavf will blindly output completely bonkers values
[16:49:29 CET] <Mavrik> Of course in hindsight I should probably handle all of that in demuxing layer and never output non-linear PTS on that project
[16:49:31 CET] <JEEB> there's a separate logic for when PCR is around
[16:49:36 CET] <Mavrik> But I was yound and stupid when starting out :D
[16:50:16 CET] <JEEB> so I've been just thinking of looking up if the behavior can just be fixed by dropping "untrusted" streams' packets until PCR is received
[16:50:24 CET] <JEEB> which is usually subtitle/teletext
[16:50:44 CET] <JEEB> then there's of course random DTS/PTS jumps due to splicing
[16:51:02 CET] <JEEB> most receivers just look at the PCR and attempt to fix it up
[16:51:17 CET] <JEEB> or receipt time
[16:51:26 CET] <JEEB> which is what upipe also saves in its packets
[16:51:47 CET] <JEEB> a lot of stuff gets simpler if you know you're supposed to be running live :P
[16:52:16 CET] <JEEB> "timestamps jumped by amount X but this packet I received was within the space for X Hz"
[16:52:37 CET] <Mavrik> Yeah, I had a case where receivers weren't on the same machine but the input was received via UDP from somewhere else
[16:52:43 CET] <Mavrik> So that data was out of whack to
[16:52:55 CET] <Mavrik> But at least the FPS and audio samplerate was constant
[16:54:15 CET] <JEEB> well with live inputs, even if not the receiver, you can get your app's receipt time
[16:56:40 CET] <durandal_1707> is this reported as bug on trac?
[16:56:52 CET] <JEEB> which thing?
[16:58:20 CET] <durandal_1707> pts issues
[17:00:05 CET] <JEEB> there's two bugs that I know in lavf or the mpegts demuxer that I have just discussed:  1) the wrap-around handling only seems to work once (so you're going to have to let the client handle it suddenly as it happens the second time) - I would have reported this if I had a sample, I'm just really lazy to make a low low bit rate sample with like 26*N hours of content
[17:00:19 CET] <JEEB> and 2) is that lavf trusts untrustworthy PTS
[17:00:53 CET] <JEEB> (it processes possibly untrustworthy tracks before PCR is received - although in theory you *always* have to wait for PCR)
[17:01:36 CET] <JEEB> I have a sample for 2) but I'm not sure if I made a ticket, I might have linked the sample on -devel at least
[17:01:51 CET] <JEEB> because it's mostly a timing issue
[17:02:04 CET] <durandal_1707> cant one for 1) just modify pts via lavfi and store it in file as is?
[17:02:46 CET] <JEEB> well, to replicate you have to use a demuxer that's set to utilize the internal wrap-around logic
[17:03:24 CET] <JEEB> see ff_read_packet
[17:03:42 CET] <JEEB> it has update_wrap_reference and wrap_timestamp calls
[17:03:57 CET] <JEEB> that seems to only work once
[17:16:04 CET] <th3_v0ice> Mavrik, JEEB, thanks for the info!
[17:46:35 CET] <skyroveRR> Hey guys, I'm trying to compile ffmpeg *on* the raspberry pi 3, using GCC 8.2.0. When I run "./configure --prefix=/usr", I get this error: http://termbin.com/zeui . Here's the ffbuild/config.log: http://termbin.com/pj5j4 ... to summarize, the configure script fails with "cc1: error: -mfloat-abi=hard: selected processor lacks an FPU. C compiler test failed."
[17:46:44 CET] <skyroveRR> Any way to fix this?
[17:55:15 CET] <skyroveRR> Oh, and this: gcc -march=armv5te -c -o /tmp/ffconf.VOX6I1FW/test.o /tmp/ffconf.VOX6I1FW/test.c
[17:59:49 CET] <pink_mist> does https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi give you any new insight?
[18:01:06 CET] <skyroveRR> Nope, they haven't been helpful.
[18:01:13 CET] <skyroveRR> And I'm not cross-compiling.
[18:01:48 CET] <pink_mist> maybe you should
[18:01:57 CET] <skyroveRR> Nope.
[18:03:17 CET] <pink_mist> either way, that page shows some configure flags you might want to try
[18:03:23 CET] <skyroveRR> I did try.
[18:03:29 CET] <skyroveRR> They aren't working.
[18:03:30 CET] <pink_mist> you only showed --prefix=/usr
[18:03:37 CET] <skyroveRR> One sec.
[18:05:58 CET] <skyroveRR> http://termbin.com/0rmjb
[18:09:11 CET] <pink_mist> the page I linked showed --arch=armel which you don't have
[18:09:25 CET] <skyroveRR> My toolchain is armhf.
[18:10:48 CET] <skyroveRR> Same output with --arch=armel.
[18:11:03 CET] <TheRock> can i compile ffmpeg with openssl 1.1.1
[18:11:07 CET] <TheRock> or only 1.0.x
[18:28:51 CET] <TheRock> ffmpeg config tests ask for error C2065: 'SSL_library_init': undeclared identifier
[18:28:58 CET] <TheRock> but thats not exported by openssl 1.1.1
[18:29:13 CET] <skyroveRR> There's no mention of "armv7l" anywhere in the configure script. Most other ARM architectures are listed though. Here's my uname -a: Linux darkstar 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
[19:08:55 CET] <TheRock> is openssl 1.1. supported by ffmpeg?
[19:09:08 CET] <TheRock> cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_WIN32_WINNT=0x0600 -nologo -c -Fo./ffconf.vFbwzGpS/test.o ./ffconf.vFbwzGpS/test.c
[19:09:08 CET] <TheRock> test.c
[19:09:08 CET] <TheRock> ./ffconf.vFbwzGpS/test.c(3): error C2065: 'SSL_library_init': undeclared identifier
[19:09:25 CET] <TheRock> that function does only exist in 1.0.x
[19:11:11 CET] <JEEB> which version of FFmpeg are you building?
[19:11:21 CET] <JEEB> if it's master, then make a ticket on trac about it
[19:21:01 CET] <trashPanda_> Hello, using code (not command line) ffmpeg, and im trying to reduce the latency in my pipeline.  I'm outputting as a mpeg2ts and it appears that the "av_interleaved_write_frame()" call buffers frames for about 8 seconds before outputting them.
[19:21:08 CET] <trashPanda_> Is there a way to reduce this latency?
[19:21:39 CET] <trashPanda_> I'm assuming there is some buffer that you can adjust, but I am unsure where to find the commands for it/how to give it.
[19:28:43 CET] <JEEB> trashPanda_: first of all, I am extremely sorry for the function's naming even though I had no part in naming it back in the day (takes in AVPackets, is named "write_frame")
[19:29:18 CET] <JEEB> second of all, I guess you've already made sure your latency in other parts of the flow is OK, and that it's just the muxing/protocol writing that has the latency
[19:31:10 CET] <trashPanda_> Yeah, it seems to be in the write call exclusively.  Everything runs through the pipeline as its read, and gets to the write call within a second.  However, if I try to watch the output, it takes a solid 8 seconds or so to show up.
[19:31:27 CET] <trashPanda_> Then holds that latency throughout its running.
[19:31:50 CET] <JEEB> well that time-to-start can be just no random access points for a while, though?
[19:32:19 CET] <JEEB> (also time-to-start and overall latency should be two separate things IMHO)
[19:32:29 CET] <JEEB> you can have 10 seconds of time-to-start (of playback)
[19:32:37 CET] <JEEB> but still sub-second latency of the whole stream
[19:33:05 CET] <trashPanda_> I was unaware of that difference
[19:34:05 CET] <JEEB> well f.ex. x264 by default does a random access point at ~240 frames, which is close to 10 seconds on many common frame rates
[19:34:18 CET] <JEEB> or was it 250, I quite honestly don't remember 8)
[19:34:35 CET] <JEEB> but the point is, your client can be om nom noming the stream, which by itself is relatively low latency
[19:34:42 CET] <JEEB> but you will only get your first video frame decoded
[19:34:48 CET] <JEEB> after the first random access point you receive
[19:34:53 CET] <JEEB> so yes, those two are 100% separate :)
[19:34:59 CET] <trashPanda_> Is that different than an I-frame?
[19:35:11 CET] <JEEB> yes
[19:35:18 CET] <JEEB> I frame is just a single frame that is intra-only
[19:35:36 CET] <trashPanda_> I was under the assumption that with mpeg2ts it would start decoding once an Iframe was received
[19:35:58 CET] <JEEB> in H.264 a random access point was either an IDR frame, or an I frame with a special open GOP random access SEI prepended
[19:36:25 CET] <JEEB> in HEVC/H.265 they actually standardized the stuff into separate NAL units which specifically fell under the "IRAP" naming
[19:36:33 CET] <JEEB> (intra random access point)
[19:36:54 CET] <JEEB> additionally you then need the headers/initialization data
[19:37:41 CET] <JEEB> so your first decode'able frame is <I got the headers/initialization data> + <I got my first intra-only frame> , *but* since it's not a random access point necessarily generally that's not the first frame where decoders start giving you output
[19:37:59 CET] <JEEB> that is generally limited to <I got the headers/initialization data> + <I got my first random access point frame>
[19:38:12 CET] <JEEB> in the FFmpeg API "keyframe" does tend to mean "random access point"
[19:38:18 CET] <JEEB> and that is another thing I am terribly sorry for
[19:38:26 CET] <JEEB> even though I had nothing to do with that naming choice in the early 2000s
[19:38:27 CET] <JEEB> :)
[19:38:39 CET] <JEEB> (I mean the AVPacket key_frame or keyframe field this is)
[19:38:55 CET] <JEEB> that field is indeed meant to represent a random access point... usually?
[19:39:26 CET] <trashPanda_> Wow thank you for all that knowledge.  So you're saying that if I set the keyframe value to "true" it will generate a random access point?
[19:39:45 CET] <JEEB> no, don't change what you got from the encoder
[19:40:54 CET] <JEEB> what I'm saying is: "keep in mind that time-to-start is dependent on your random access point positioning"
[19:41:04 CET] <JEEB> so you configure your encoder according to your requirements regarding that
[19:41:30 CET] <JEEB> f.ex. if you never want x264 to make longer GOPs than 25 frames, you set the AVCodecContext's gop length thing to 25
[19:41:55 CET] <JEEB> also the mpeg-ts muxer has options regarding when it outputs some stuff
[19:42:03 CET] <JEEB> check out the AVOptions in the mpeg-ts muxer :)
[19:42:08 CET] <trashPanda_> ok, I think that is what I'm looking for
[19:43:04 CET] <trashPanda_> what command would display that?
[19:43:46 CET] <JEEB> for me generally I just open up the relevant libavformat/libavcodec file, but ffmpeg.c (the command line app) can also output the AVOptions of a component with the help option
[19:43:52 CET] <JEEB> that said, I never remember the parameters for that
[19:43:53 CET] <JEEB> soo
[19:44:00 CET] <JEEB> > off to actual code digging for me
[19:44:23 CET] <JEEB> ok, I remembered it correctly
[19:44:26 CET] <JEEB> -h muxer=mpegts
[19:44:44 CET] <JEEB> that gives you all the AVOptions you can set for the mpegts muxer
[19:44:57 CET] <JEEB> also I'm pretty sure your protocol also has some buffering
[19:45:15 CET] <JEEB> aww, too bad that doesn't work with protocols :P
[19:45:21 CET] <JEEB> -h protocol=file is what I tested
[19:46:31 CET] <trashPanda_> I've looked at the options but I don't see anything that would affect latency, unless I'm not reading them correctly.
[19:46:49 CET] <Trel> Quick question -vcodec and -c:v are the same thing, right?
[19:47:12 CET] <JEEB> vcodec is the old thing, and -codec or -c is the new thing, which you can then limit to specific streams
[19:47:22 CET] <JEEB> for example -c:v:2 libx264
[19:48:31 CET] <Trel> Ok, that's even better, since I've been using -c:v over -vcodec, so if that's the newer one anyway, I'm happy!
[19:48:33 CET] <Trel> Thanks!
[19:48:36 CET] <JEEB> which means that the 3rd video stream encoder (or decoder if before -i) is set tolibx264
[19:48:53 CET] <Trel> 0 indexed, right?
[19:49:03 CET] <JEEB> yup
[19:49:11 CET] <Trel> Cool cool, thanks again
[19:49:53 CET] <trashPanda_> JEEB, do you think the issue could be, not in the mpeg2ts muxer, but the "interleaved" buffer inside of the actual av_interlaved_write_frame call?
[19:50:00 CET] <trashPanda_> Is there a way to reduce the buffer?
[19:51:19 CET] <JEEB> sure, but so far it sounded like your largest thing was the time-to-start but it could of course be output buffering if your rates are low enough
[19:51:43 CET] <trashPanda_> Well, I think I explained my "time-to-start" badly.
[19:52:17 CET] <trashPanda_> What I meant was, when I initially start the pipeline there is a long time for something listening on the output to see the stream
[19:52:31 CET] <trashPanda_> and that 8-10 second delay is present in the stream no matter when you tune into it.
[19:52:43 CET] <trashPanda_> The "time-to-start" is next to nothing once the stream has already been running.
[19:54:07 CET] <trashPanda_> So I think the issues lie more in the buffer than it holds while it correctly interleaves the output, and I was wondering if there was a way to reduce that
[20:02:58 CET] <trashPanda_> JEEB, Do you know of any way to mess with that stuff?
[20:03:16 CET] <JEEB> it can be either muxer side or AVIO side
[20:03:51 CET] <trashPanda_> Is there a command to reduce the buffer inside of the av_interleaved_write_frame call for me to test?
[20:05:01 CET] <JEEB> can't straight out say, I've mostly just poked around with custom IO callbacks
[20:09:13 CET] <trashPanda_> any idea where to start looking?
[20:36:57 CET] <TheRock> im back
[20:37:08 CET] <TheRock> did anyone answer my question? Is openssl 1.1.1 possible with ffmpeg 4.1?
[20:37:54 CET] <JEEB> 20:11 < JEEB> which version of FFmpeg are you building?
[20:37:55 CET] <JEEB> 20:11 < JEEB> if it's master, then make a ticket on trac about it
[20:38:10 CET] <TheRock> FFMPEG 4.1.0
[20:38:31 CET] <TheRock> Looks to me, that it isnt a bug
[20:38:54 CET] <JEEB> test current master, if it still fails then it still has to be fixed (probably, if we want to keep openssl support) and then back-ported to anything that makes sense
[20:39:01 CET] <JEEB> otherwise just back-ported if master works :P
[20:39:10 CET] <TheRock> https://pastebin.com/NcB133D6
[20:39:27 CET] <TheRock> the config tests clearly ask for SSL_library_init
[20:39:31 CET] <TheRock> which is not in 1.1 available
[20:40:16 CET] <TheRock> ./ffconf.vFbwzGpS/test.c(3)
[20:40:20 CET] <TheRock> i don't know where to find this file
[20:40:47 CET] <JEEB> that's a temporary file
[20:40:55 CET] <JEEB> you can find the contents of the file in ffbuild/config.log
[20:41:04 CET] <TheRock> i would like to verify the source-code
[20:41:08 CET] <TheRock> if there is an if else statement
[20:41:20 CET] <TheRock> because my enviroment could be wrong
[20:41:23 CET] <JEEB> you can see it in hte configure file as well as ffbuild/configure.log
[20:41:37 CET] <TheRock> ah, ok
[20:41:38 CET] <JEEB> <build_dir>/ffbuild/configure.log is where all that is
[20:41:52 CET] <TheRock> ye, just saw it
[20:42:01 CET] <TheRock> thus, openssl 1.1. is not supported currently
[20:43:23 CET] <JEEB> most people making redistributed binaries use GnuTLS or on embedded stuff the other TLS library by ARM
[20:43:38 CET] <JEEB> because openssl's older license at least was not GPL-compatible
[20:44:53 CET] <TheRock> well, i use ffmpeg as backend. if ffmpeg uses 1.0.2u for example, and my other code 1.1., i have to ship two different openssl versions
[20:45:26 CET] <JEEB> yes, then open up a ticket about it or fix it yourself and post a patch fixing it on the mailing list
[20:45:40 CET] <TheRock> i'll just swtich back to 1.0.2
[20:45:43 CET] <TheRock> it will be easier
[20:45:47 CET] <JEEB> also...
[20:46:23 CET] <JEEB> openssl is EXTERNAL_LIBRARY_NONFREE_LIST
[20:46:32 CET] <JEEB> that's not supposed to be redistributable :P
[20:47:09 CET] <JEEB> gnutls or mbedtls would be
[20:47:18 CET] <JEEB> so you specifically are having to enable --enable-nonfree
[20:47:19 CET] <JEEB> for openssl
[20:47:29 CET] <JEEB> which also specifically in the binaries says "not redistributable"
[20:47:51 CET] <TheRock> i have compiled ffmpeg successful without that switch
[20:47:56 CET] <TheRock> for 1.0.x
[20:48:20 CET] <TheRock> and the module was listed in the overview
[20:48:34 CET] <JEEB> that's weird because it *is* under the nonfree list
[20:49:07 CET] <TheRock> yes. ot
[20:49:09 CET] <TheRock> it's weird
[20:49:26 CET] <TheRock> actually i have compiled many versions including 3.4+, before with openssl
[20:49:45 CET] Action: JEEB waits for git blame to work out when each line was changed
[20:49:56 CET] <TheRock> but for 4.1, i wanted to swtich to 1.1
[20:50:16 CET] <JEEB> yae, that's 2016
[20:50:24 CET] <JEEB> so it definitely has been under enable-nonfree :P
[20:50:27 CET] <JEEB> for quite a while now
[20:51:30 CET] <JEEB> and before that in 2011 "die_license_disabled nonfree openssl"
[20:52:58 CET] <TheRock> most SO posts also just say --enable-openssl
[20:53:01 CET] <TheRock> from >2015
[20:53:41 CET] <TheRock> your define might be there, but it's not included :P
[20:54:50 CET] <JEEB> there's nothing to include, really :P
[20:54:56 CET] <JEEB> it's within the configure script
[20:55:34 CET] <JEEB> but yes, there were some that only got fired when you enabled GPL
[20:56:41 CET] <JEEB> yea it smells like the nonfree things was originally added for GPL-incompatibilities
[20:56:45 CET] <JEEB> because of "enabled gpl && map "die_license_disabled_gpl nonfree" $EXTERNAL_LIBRARY_NONFREE_LIST"
[20:56:54 CET] <JEEB> so if you haven't enabled GPL that won't get hit
[20:57:04 CET] <JEEB> which is correct in some cases of nonfree, but not all
[20:57:11 CET] <JEEB> (jesus christ this is a mess)
[20:57:13 CET] <TheRock> check_lib openssl openssl/ssl.h SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
[20:57:25 CET] <JEEB> yea, that's the primary configure check which comes out before
[20:57:55 CET] <TheRock> libeay32 and ssleay32
[20:57:59 CET] <TheRock> is correct for 1.0.x
[20:58:10 CET] <TheRock> at least the git clone from openssl build the libraries with that names
[20:58:19 CET] <TheRock> and from > 1.0, they are called ssl, crypto
[20:58:23 CET] <JEEB> yes, anyways - make a ticket for that if you don't want to fix 1.1 compatibility yourself :)
[20:59:13 CET] <TheRock> i'll go with the old version
[21:00:09 CET] <JEEB> also openssl got re-licensed under Apache version 2 for newer versions so technically if you limit yourself to version3 in the future those newer versions would be buildable without enable-nonfree with GPL
[21:01:01 CET] <JEEB> but yea, I /think/ current license and LGPL specifically is kosher, which is what the nonfree check covers
[21:02:47 CET] <TheRock> i just need it for https
[21:03:26 CET] <TheRock> which sucks, because i need to include all the libraries
[21:08:34 CET] <trashPanda_> JEEB, I switched the av_interleaved_write_frame with just av_write_frame and the 10 sec lag went away completely. Its sub .5seconds now.  So it definitely is an issue with the interleaved buffer size.  Would you suggest just writing my own mixer?
[21:09:17 CET] <JEEB> no
[21:09:23 CET] <JEEB> unless you specifically need it for something
[21:09:41 CET] <JEEB> there's some way of controlling how much whatever part is buffering there
[21:09:49 CET] <JEEB> but I can't you tell it out of thin air for you
[21:10:12 CET] <trashPanda_> I would imagine there was, I just don't know how to find it.  Google is not helping atm.
[21:10:51 CET] <TheRock> Compiling now with OpenSSL1.0.2q
[22:38:43 CET] <trashPanda_> JEEB, thanks for helping point me in the right direction.  I found the option, its an actual field in the avformatcontext, it can also be set with avoptionset, "max_interleave_delta"
[22:39:44 CET] <trashPanda_> it was apparently defaulting pretty high for me, I hard set it to a quarter second and now things have next to no latency.
[00:00:00 CET] --- Tue Dec 11 2018