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

[burek]

[16:02:57 CET] <GuiToris> hi, I split a video to png images and I've checked the original file and mediainfo says: Frame rate mode : Variable
[16:03:05 CET] <GuiToris> what should I do?
[16:04:22 CET] <JEEB> there are a lot of reasons why mediainfo would say that
[16:04:32 CET] <JEEB> so by itself that flag specifically says nada about anything
[16:04:33 CET] <GuiToris> framerate 15.325, minimum framerate 4.785, maximum 24.390
[16:05:12 CET] <GuiToris> should I use 15.325?
[16:05:16 CET] <JEEB> ok, that sounds like fun. what is the reason for the PNG'ification and can you put that into a container to keep those timestamps if it indeed looks like VFR?
[16:05:39 CET] <JEEB> and if you cannot keep the stuff in a container, then I recommend you name the images with their decoded PTS
[16:05:56 CET] <JEEB> although that already means that you will have to be making some scripting or coding yourself
[16:07:39 CET] <GuiToris> I usually don't use this phone to make videos but I didn't have any other choice, and I save videos as PNGs with blender
[16:07:50 CET] <GuiToris> I just wanted to combine them
[16:08:00 CET] <GuiToris> I don't know what to do
[16:08:17 CET] <GuiToris> is this a garbage now?
[16:12:47 CET] <JEEB> so Blender wrote your PNGs?
[16:12:54 CET] <JEEB> in that case check if it does any frame rate conversions
[16:15:13 CET] <GuiToris> I started with blender then I used a couple of other applications like darktable etc... so I doubt if I still have anything usable data :(
[16:15:48 CET] <GuiToris> I've never worked with variable framerate and it just surprised me
[16:16:17 CET] <GuiToris> I'll test it with the average rate, it may not be that wrong
[16:16:30 CET] <GuiToris> hopefully the other values were just momentary
[16:16:45 CET] <JEEB> I'd just go with some standard rate like 24 or 30 or so
[16:16:55 CET] <JEEB> if I were to convert to a stable frame rate :P
[16:17:41 CET] <GuiToris> dolphin - the filemanager - says they are 15
[16:17:58 CET] <GuiToris> I'll try using that
[16:20:56 CET] <GuiToris> JEEB, 15 almost right, my exported audio is 1:49 and this became 1:47
[17:42:54 CET] <DmanT> hi al
[17:42:56 CET] <DmanT> hi all
[17:48:51 CET] <DmanT> is it possible with ffmpeg to merge two streams and then make a watermark on it? stream one should always be generated. if then a signal on stream two comes this with a transparent background over the stream one to be laid. Finally, a watermark over the entire picture. does ffmpeg get it?
[18:57:19 CET] <ddubya>  DmanT, what do you mean by "merge" ? Two parallel streams or concatenation
[18:57:33 CET] <DmanT> two srs streams
[18:57:41 CET] <DmanT> rmtp
[18:57:53 CET] <ddubya> so like different camera angles?
[18:59:16 CET] <ddubya> It sounds like you want them side-by-side
[19:01:04 CET] <ddubya> you can use a filter graph for watermarking. I believe all inputs must be available at the start
[19:06:45 CET] <DmanT> ddubya, there was the problem....
[19:07:03 CET] <DmanT> stream one is available constant.. but stream 2 not
[19:09:06 CET] <JEEB> you need your own API client for that logic
[19:09:27 CET] <JEEB> where you feed a black frame to the filter chain until an input is avialable
[19:09:37 CET] <JEEB> then when it dies you start feeding black stuff again
[19:11:27 CET] <DmanT> oa
[19:11:28 CET] <DmanT> oha
[19:14:01 CET] <DmanT> how do I do something like that?
[19:20:38 CET] <JEEB> DmanT: there are basic examples under doc/examples regarding opening inputs and decoding etc
[19:20:48 CET] <JEEB> then you would have to make the logic on when input is dead and when not etc
[20:30:03 CET] <DmanT> How can I make a watermark so that it is always the same size? depending on the input video is my logo times bigger times smaller. what am I doing wrong?
[20:30:58 CET] <DmanT> ffmpeg -i "$DATEI" -re -i "$LOGO" -filter_complex "overlay=20:20" -c:v libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv rtmp://$IP:1935/app/live # > /dev/null 2>&1
[20:33:18 CET] <JEEB> scale your overlay according to the primary input's size :P (don't think there's an option for that in the overlay filter, although I recommend checking)
[20:35:36 CET] <DmanT> well, super ... no idea how to calculate it
[20:43:48 CET] <friendofafriend> DmanT: Probably find the input resolution of $DATEI with ffprobe and scale the logo with imagemagick.
[20:44:26 CET] <DmanT> yes but how are the dimension?
[21:03:18 CET] <relaxed> DmanT: you can scale the logo earlier in the filter chain, but you'll have to script getting the video frame size and what % the size of the logo should be beforehand
[21:03:42 CET] <DmanT> it my first work with ffmpeg and only problems :(
[21:06:17 CET] <DmanT> tsfix: transport stream H264, DTS discontinuity. DTS = 0, last = 19519200
[21:06:25 CET] <DmanT> what he want from me?
[21:14:29 CET] <relaxed> it would be nice if scale could query other stream's iw and ih
[21:15:42 CET] <DmanT> ok, everything after another. is there a possibility that ffmpeg sends just as fast as the video? So if a video is 3 min then ffmpeg also needs 3 minutes for it?
[21:17:01 CET] <relaxed> move -re before all the inputs
[21:18:53 CET] <DmanT> thanks
[21:32:52 CET] <nadermx> When using the -headers how I send multiple items? I read that I had to use \r\n but when I run a command, like ffmpeg -headers "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7'\r\n'Accept-Language: en-us,en;q=0.5" it shows the \r\n in the reciving server
[21:33:14 CET] <DmanT> yes.. nice
[21:33:37 CET] <DmanT> ok.. that runs...
[21:33:54 CET] <DmanT> now i must read, how i can add text.. egp data
[21:34:23 CET] <relaxed> nadermx: try removing the single quotes from around newline and return
[21:36:07 CET] <nadermx> so like, "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\nAccept-Language: en-us,en;q=0.5"?
[21:36:36 CET] <relaxed> yes
[21:37:21 CET] <relaxed> you might try single quoting the whole string
[21:39:07 CET] <nadermx> Doesn't seem to work, still sends it with \r\n
[21:41:58 CET] <relaxed> nadermx: -headers "$(printf '%s\r\n' 'Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7' 'Accept-Language: en-us,en;q=0.5')"
[21:42:24 CET] <relaxed> er, '%s\r\n%s'
[21:43:02 CET] <nadermx> That did it
[21:43:13 CET] <nadermx> Thank you
[21:43:24 CET] <relaxed> you're welcome
[21:47:01 CET] <DmanT> av_interleaved_write_frame(): Broken pipe
[21:47:04 CET] <DmanT> whats now?
[21:58:30 CET] <Abbott> I'm trying to compile ffmpeg for cygwin and I got linking errors after `./configure --enable-libmp3lame` then `make`: http://dpaste.com/3G9R9JV.txt
[21:58:47 CET] <Abbott> looks like a bunch of av stuff isn't defined, does that have to do with libavcodec?
[21:59:15 CET] <JEEB> sounds like something's awfully borked
[21:59:26 CET] <JEEB> since it can't link against symbols it just should have built
[21:59:53 CET] <JEEB> I'm not sure if anyone tests on cygwin, btw
[22:00:00 CET] <JEEB> as in, building *for* cygwin
[22:00:09 CET] <JEEB> mingw-w64 that is native windows for 32bit and 64bit is of course tested
[22:00:19 CET] <JEEB> (those can be found in the interface of http://fate.ffmpeg.org/ )
[22:01:04 CET] <JEEB> ah, there are actually cygwin machines
[22:01:20 CET] <JEEB> so yes, cygwin should actually work
[22:01:35 CET] <JEEB> latest cygwin gcc 8 build http://fate.ffmpeg.org/report.cgi?time=20190119062030&slot=x86_32-cygwin-gcc-8
[22:02:17 CET] <JEEB> and then 64bit cygwin
[22:02:18 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20190119042012&slot=x86_64-cygwin-gcc-8
[22:03:10 CET] <Abbott> so I should try configuring with some or all of those options, then?
[22:03:18 CET] <JEEB> no
[22:03:27 CET] <JEEB> check your ffbuild/config.log
[22:03:36 CET] <JEEB> is your system found to be cygwin?
[22:03:39 CET] <JEEB> and stuff like that
[22:18:10 CET] <Abbott> MACHTYPE=x86_64-unknown-cygwin OSTYPE=cygwin
[22:18:20 CET] <Abbott> host and target are cygwin as well
[22:19:17 CET] <Abbott> I didn't do a git clean since my last build, but that shouldn't cause problems, right?
[22:19:25 CET] <Abbott> make should know what to rebuild and what not to
[22:19:50 CET] <JEEB> in theory yes. that isn't perfect of course. also stuff like you see often can happen if you've built for something else first
[22:20:33 CET] <keglevich> ffmpeg -re -i 1.mp4 -r 25 -c:v libx264 -x264opts nal-hrd=cbr -b:v 8000k -minrate 8000k -maxrate 8000k -bufsize 320k -muxrate 8500k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.10.10.10:10000?pkt_size=1316"
[22:20:35 CET] <JEEB> long story short, I like to have separate build roots (which can be within the project root if you want to - like "lunix_build" or "mingw_build" etc), and then if I have issues my first reaction is to nuke that build directory and re-create it & configure && build
[22:20:39 CET] <BtbN> I'm using ffmpeg on cygwin constantly. Build and works just fine for me.
[22:21:19 CET] <keglevich> I'm using this command to create UDP CBR stream.... but, this is not near true CBR which can DVB-T muxer create...simple question...is it even possible to make "true" CBR mp4 libx264 with ffmpeg?!
[22:21:51 CET] <JEEB> libx264 can do CBR CBR which does dumb things like byte stuffing
[22:22:00 CET] <BtbN> h264 is never "true cbr". If it can be done in less, it will.
[22:22:03 CET] <JEEB> you need specific parameters for it of course, since generally people don't want it
[22:22:08 CET] <BtbN> x264 just fills it up with null bytes if in doubt
[22:22:11 CET] <JEEB> yes
[22:22:16 CET] <JEEB> nal-hrd:cbr
[22:22:21 CET] <JEEB> s/:/=/
[22:22:22 CET] <keglevich> yes...it does byte stuffing, but it does it really bad...it jumps +-10% or more all the time
[22:22:46 CET] <JEEB> are you sure that's the encoder and not the muxer?
[22:22:47 CET] <BtbN> depends on how long of a timeframe you look at
[22:22:56 CET] <BtbN> it aims to keep the size of each gop fixed
[22:22:59 CET] <JEEB> also do you actually look into if it follows your VBV constraints or not :P
[22:23:14 CET] <JEEB> no, I'm not sure if it cares about GOPs
[22:23:31 CET] <BtbN> So if you have 10 second GOPs, but only look at one second of data, you might see fluctuations, yes
[22:23:34 CET] <JEEB> I mean, a new IDR will do some things, but generally speaking you're just keeping rate control within maxrate over bufsize
[22:23:46 CET] <keglevich> I'm just checking and comparing the streams with mpegts analyzer...what hw.muxer produces is real straight line (true CBR)...what ffmpeg produces is someking of jumpy line (saw) with jumps +-10%
[22:23:51 CET] <keglevich> tried all possible commands
[22:23:57 CET] <JEEB> is it the muxer or the encoder
[22:24:06 CET] <JEEB> like seriously, separate the two
[22:24:23 CET] <BtbN> It has to decide for _some_ interval to keep the bitrate constant over.
[22:24:33 CET] <keglevich> btbn: you're right....if you take "10secs" interval, it is CBR....but all the time it isn't
[22:25:16 CET] <keglevich> BtbN: is it possible to simulate then somehow real true CBR (like hw encoders) so CBR would be all the time, each moment?
[22:25:25 CET] <JEEB> anyways, please figure out if you're having an issue with the muxer or the encoder
[22:25:29 CET] <JEEB> pretty goddamn please
[22:25:49 CET] <JEEB> because those are two very distinct things, and libx264 is *very* good at doing VBV/HRD
[22:25:54 CET] <BtbN> How should it do that? If you fill up early to reach bitrate constaints, and second later a super complex frame comes in, what are you gonna do?
[22:26:03 CET] <BtbN> Only solution would be to buffer a whole lot of frames
[22:26:09 CET] <keglevich> straight line -----------------, not like -.-'-.'.-.'-'.-'-.'-. which is ffmpeg now
[22:26:10 CET] <JEEB> that's a separate issue
[22:26:22 CET] <JEEB> keglevich: please just goddamnit verify which is it that you're having an issue with
[22:26:26 CET] <JEEB> the encoder or the muxer
[22:27:10 CET] <keglevich> JEEB: I'm using that same command with mpeg2video as well and there works pretty well... almost 99% true CBR
[22:27:14 CET] <keglevich> but not with libx264
[22:27:40 CET] <keglevich> about muxer...I'm not sure what you're suggesting... I'm just using -muxrate which is about 10%+bitrate
[22:28:15 CET] <JEEB> yea, I want you to actually look if your issue is how the thing's muxed (because after all what you really want is a CBR mux for DVB or so, right?)
[22:28:18 CET] <keglevich> if you have any kind of suggestions to improve my command above, I'd be more than happy to test
[22:28:30 CET] <JEEB> no, I'm just wanting you to be precise on what your problem is
[22:28:38 CET] <keglevich> JEEB: right...I need to send CBR UDP out
[22:28:55 CET] <JEEB> yes, that is pretty obvious that you require a CBR mux
[22:29:16 CET] <keglevich> can ffmpeg do CBR mux?
[22:29:27 CET] <JEEB> I don't know, but I don't know if your problem is the mux or the video encoder
[22:29:32 CET] <JEEB> I'm trying to figure it out and ask you to check
[22:29:35 CET] <JEEB> for christ's sake
[22:30:02 CET] <keglevich> I can check anything, just please tell me what to do with input
[22:30:03 CET] <JEEB> you should be able to check with any software that you're checking the mux with
[22:30:21 CET] <JEEB> because even the open source thing called DVB Inspector has a graph for the mux
[22:30:42 CET] <JEEB> so if you are using a lolexpensive analyzer thing, that should also have such a simple feature
[22:30:45 CET] <JEEB> :P
[22:31:03 CET] <keglevich> hmm...I'm using MpegTS Analyzer...it shows good PCR's, good stream, no packet loses, etc....but the stream bitrate isn't "true" CBR, but it fluctuates all the time up and down
[22:31:14 CET] <keglevich> the same shows VLC or any other player which can show input stream
[22:31:17 CET] <BtbN> define true CBR
[22:31:19 CET] <JEEB> jesus christ
[22:31:41 CET] <JEEB> I'm trying to help you by telling you exactly what you need to check.
[22:31:45 CET] <keglevich> ----------- true CBR,  -.-'-.'.-.'-'.-'-.'-. ffmpeg
[22:31:49 CET] <BtbN> Bitrate is only ever constant over a given interval.
[22:32:27 CET] <keglevich> oh, come on, I'll do two screenshots with one "true CBR" stream...and with one which ffmpeg generates, one minute...
[22:32:41 CET] <BtbN> I feel like you don't want to understand...
[22:32:48 CET] <JEEB> keglevich: just check with DVB inspector if the mux is CBR or not
[22:32:58 CET] <JEEB> if your lolexpensive thing doesn't know how to show that
[22:33:22 CET] <JEEB> it should have a graph of how the packets of the mux are then set (what % is stuffing, what % is video etc)
[22:33:26 CET] <JEEB> it's not a hard concept, right?
[22:33:32 CET] <JEEB> and I'm not trying to be an asshole
[22:33:53 CET] <keglevich> that's exactly what I'm doing now for you, just a moment...
[22:34:05 CET] <JEEB> also what BtbN is trying to say is that a lot of software just ignores stuff like VBV/HRD when calculating "bit rate" for video tracks
[22:34:19 CET] <JEEB> also
[22:35:00 CET] <JEEB> you have not enabled nal-hrd stuff in x264. it doesn't affect the rate control, but it does affect the fact that your HRD stuff is not signaled in the headers
[22:35:34 CET] <JEEB> it has an option to also stuff the video track, but I want to first see if your problem is that the muxer doesn't do its job properly
[22:35:41 CET] <BtbN> That's not what I'm trying to say. I'm saying that both x264 and the mpegts muxer with muxrate will only ever aim for that rate over a certain interval. "At all times" is just not possible
[22:36:03 CET] <JEEB> yes, thus the calculation needs to be correctly made according to your parameters.
[22:36:19 CET] <JEEB> which unfortunately for video tracks a lot of things don't do correctly :<
[22:36:29 CET] <BtbN> Also, if your streams are just plain larger than what you set as muxrate, it also can't do magic
[22:37:21 CET] <keglevich> https://imgur.com/a/3dkxiCr
[22:37:35 CET] <keglevich> that's the best that ffmpeg can generate with libx264....
[22:37:52 CET] <JEEB> keglevich: now guess which part that graph misses
[22:37:53 CET] <keglevich> but, hw-encoders we have on the other side create a perfect straight line a 8500k as set
[22:38:18 CET] <keglevich> I don't know which part it misses...the only thing important here is that's different from what we need
[22:38:30 CET] <BtbN> The one you were asked about multiple times...
[22:38:39 CET] <keglevich> we need straigth line...and all I'm asking is if it's possible to do it with ffmpeg or not?
[22:39:02 CET] <keglevich> as far all answers I got through the last two years say simple answer "no, with ffmpeg this isn't possible"
[22:39:28 CET] <keglevich> I don't know what you're asking me really....
[22:39:40 CET] <JEEB> seeing the bit rate allocation within the mux
[22:39:47 CET] <JEEB> aka "is the muxer doing its job properly"
[22:39:58 CET] <keglevich> ok, how can I check this?
[22:40:16 CET] <JEEB> DVBinspector is one thing that does a bit rate graph properly (not sure about VBV/HRD but at least you see a nice mux graph)
[22:40:40 CET] <JEEB> you let it index a dump of the MPEG-TS stream and it will show you padding packets and each of the PES streams etc
[22:40:54 CET] <JEEB> because I'm OK with giving you a workaround if you show me that the muxer is not doing its job well
[22:41:05 CET] <JEEB> I'm less OK with giving you that if you don't even produce that sort of info
[22:41:10 CET] <Abbott> okay, after a git clean -fdx then reconfiguring and building, it worked
[22:41:20 CET] <Abbott> so there must have been some stale build files that messed with the compilati9on
[22:41:29 CET] <Abbott> thanks for the feedback JEEB
[22:41:32 CET] <JEEB> Abbott: np
[22:41:48 CET] <keglevich> can I use DVBinspector directly with UDP stream or do I need to create an output file (output.ts for example) and examine that one?
[22:41:59 CET] <JEEB> I just said that, but it only takes file input unfortunately
[22:42:09 CET] <JEEB> so grab like 100MiB of the input or so and check with that
[22:42:19 CET] <JEEB> well output in your case
[22:42:36 CET] <keglevich> so what do I have to check then there actually?
[22:43:03 CET] <JEEB> there's a tab that shows you the mux over the time with all the streams and other packets all contained in it
[22:43:18 CET] <JEEB> it's like your graph but it actually shows what is contained how much in it :P
[22:44:10 CET] <JEEB> also the muxer at least does have > insert_null_packet
[22:44:22 CET] <JEEB> so in theory if the mpegts muxer is written correctly it should be able to do CBR
[22:44:25 CET] <JEEB> (mux)
[22:44:59 CET] <JEEB> ok, it has some calculation based on the PES packets' DTS
[22:45:22 CET] <JEEB> which means that in theory to some amount it should be able to do CBR if mux rate is set
[22:45:34 CET] <JEEB> I am not too into this stuff so I can't confirm it, though, unfortunately :P
[22:45:46 CET] <BtbN> It uses the max_delay option to determine over which interval
[22:45:57 CET] <keglevich> muxrate has to be set so the parameter pcr_period comes in effect....for DVB muxers pcr-period should be 40ns or smaller
[22:46:03 CET] <keglevich> so only with muxrate you're able to do this
[22:46:11 CET] <JEEB> yes, and you need muxrate anyways
[22:46:23 CET] <keglevich> and as far as I udnerstand muxrate has to be video+audio bitrate + 10% or something...
[22:46:28 CET] <keglevich> that's all you can do with ffmpeg
[22:46:35 CET] <JEEB> (dts - get_pcr(ts, s->pb) / 300) > delay)
[22:46:37 CET] <JEEB> that's the math
[22:46:58 CET] <JEEB> oh wait, it also has a write_pcr thing there then
[22:47:04 CET] <JEEB> which only inserts PCR at that point
[22:47:23 CET] <JEEB> anyways, let's see the mux and you'll be able to see :P
[22:47:40 CET] <JEEB> keglevich: ~10% overhead required by MPEG-TS is what most people ballpark yes
[22:47:45 CET] <JEEB> not much to do with FFmpeg specifically
[22:47:45 CET] <JEEB> :P
[22:48:37 CET] <BtbN> Yeah... with your parameters you have 8192kbps of raw codec bitrate already
[22:48:48 CET] <keglevich> btbn: true
[22:48:50 CET] <BtbN> With mpegts overhead, that will most likely just be more than your limit of 8500
[22:49:07 CET] <keglevich> so I set muxrate to around 8500k otherwise I get dts < pcr errors
[22:49:36 CET] <BtbN> Set it to 10M or so and see if that holds stable
[22:49:40 CET] <keglevich> it can also be set to 8800k or more, doesn't matter...everything above 8500k runs fine
[22:50:08 CET] <keglevich> I setup dvbinspector and I loaded the recorded output.ts file...about 5min file... what should I record now for you?
[22:50:16 CET] <keglevich> I mean which screenshot would you need?
[22:50:37 CET] <JEEB> see the tab that has the graph over time with the bit rate of the mux with all the streams colored separately
[22:52:08 CET] <JEEB> yea, it's the BitRate view
[22:52:09 CET] <JEEB> :P
[22:53:14 CET] <keglevich> https://imgur.com/a/FYw6gqM
[22:53:43 CET] <JEEB> btw, are you producing this stream on linux or windows?
[22:53:57 CET] <keglevich> ok, this is strange now....that recorded output.ts file is almost perfect CBR...I used the same command, only I piped the output to .ts file instaed to UDP URL directly....
[22:53:57 CET] <JEEB> since IIRC the windows UDP code was not as good as the linux stuff
[22:54:03 CET] <keglevich> why such a difference?
[22:54:10 CET] <JEEB> ok, so you were making it on windows?
[22:54:27 CET] <keglevich> I tried both, linux and windows, it's almost the same results...
[22:55:25 CET] <JEEB> but you didn't set the bitrate option for the UDP protocol itseems
[22:55:29 CET] <keglevich> but that's something I don't really understand now...I also tried to play that output.ts in VLC directly, also clear CBR stream... so that command seems to produce nice CBR stream if you pipe it directly to output.ts file....but if you pipe it to UDP, you get lots of fluctuations along the line...why so?
[22:55:50 CET] <BtbN> It's not packet loss, is it?
[22:55:58 CET] <keglevich> JEEB: that's something that can't be set with ordinardy ffmpeg builds...only with pthreads enabled it works....
[22:55:59 CET] <JEEB> probably just UDP output timing :P
[22:56:16 CET] <keglevich> I also tried to build ffmpeg with ptrheads-enabled, but it was totally unstable
[22:56:17 CET] <JEEB> keglevich: because it's pthreads only yes, thankfully not windows is pthreads by default
[22:56:22 CET] <BtbN> For UDP output, you want to very carefully select the packet size
[22:56:29 CET] <JEEB> packet size he already set
[22:56:34 CET] <JEEB> he didn't have bit rate set tho
[22:56:38 CET] <keglevich> 1316 has to be for hw muxers
[22:56:59 CET] <keglevich> is there a workaround without pthreads?
[22:57:02 CET] <JEEB> no
[22:57:10 CET] <JEEB> other than paying someone to develop proper support for the threaded UDP
[22:57:12 CET] <JEEB> in windows
[22:57:15 CET] <keglevich> because with pthreads (tried on linux and windows) ffmpeg crashes constantly
[22:57:15 CET] <BtbN> It has the be a multiple of 144 bytes, and has to be smaller than the smallest MTU on the path
[22:57:40 CET] <keglevich> 7x144 = 1316
[22:57:41 CET] <JEEB> keglevich: if it crashes on modern linux then that's a bug of course
[22:57:49 CET] <BtbN> *188
[22:57:55 CET] <BtbN> size of a single mpeg-ts packet
[22:57:56 CET] <keglevich> yes, sorry 188
[22:58:26 CET] <JEEB> keglevich: anyways file a bug but I don't think threaded UDP on windows will get much love without someone paying for it as it's usually used in professional places
[22:58:44 CET] <JEEB> also for the crashes, use --disable-stripping and file a bug for that with a gdb backtrace
[22:58:55 CET] <BtbN> That fluctuation in that graph might very well just be network buffering
[22:58:56 CET] <JEEB> on linux preferably since I don't know about the windows traces
[22:59:15 CET] <BtbN> Since it over all always has a spike down for every spike up
[22:59:24 CET] <JEEB> BtbN: well we already found out that it could just be the UDP thing sending data too fast for a moment
[22:59:32 CET] <JEEB> since he's not using the bitrate option in the UDP protocol
[22:59:45 CET] <keglevich> BtbN: true...is there a way maybe to do some kind of output buffer and send out just CBR all the time?
[23:00:01 CET] <BtbN> JEEB is telling you about that since a couple minutes.
[23:00:35 CET] <keglevich> yes I know about pthreads, tried that, doesn't work...filled reports, no answers, abandoned it
[23:00:42 CET] <JEEB> did you really?
[23:00:42 CET] <BtbN> not that
[23:00:45 CET] <JEEB> did you have a backtrace?
[23:01:05 CET] <BtbN> I'm also pretty sure if pthreads on Linux would be crashing, we'd have heard about that
[23:01:10 CET] <JEEB> ^
[23:01:16 CET] <keglevich> a while ago I filed a report, without backtrace, just with error output line
[23:01:20 CET] <JEEB> ok
[23:01:21 CET] <JEEB> yea
[23:01:27 CET] <JEEB> that is not going to get you much help unfortunately
[23:01:48 CET] <JEEB> if you have a linux box somewhere it's not hard to get a backtrace :P
[23:02:07 CET] <JEEB> install gdb, run the ffmpeg_g binary instead of the ffmpeg one (or use --disable-stripping during configure)
[23:02:18 CET] <JEEB> run as in `gdb ./ffmpeg_g`
[23:02:25 CET] <JEEB> then wait for it to tell you it has loaded the symbols
[23:02:29 CET] <keglevich> where would I be able to get ffmpeg_g?
[23:02:35 CET] <JEEB> it is built
[23:02:40 CET] <JEEB> together with the one without prefix
[23:02:42 CET] <BtbN> It falls out of the build process, right next to normal ffmpeg
[23:02:53 CET] <JEEB> uhh, suffix I mean
[23:02:59 CET] <JEEB> it's getting late :P
[23:03:11 CET] <JEEB> and then after you have confirmed that symbols have been loaded
[23:03:23 CET] <JEEB> you do `run -your -parameters -lol`
[23:03:27 CET] <JEEB> and wait for the crash
[23:03:34 CET] <keglevich> ok, I'll try to do this as well
[23:03:36 CET] <JEEB> then when you get crash you do `bt full`
[23:03:42 CET] <JEEB> and that should give you a nice full backtrace
[23:03:45 CET] <BtbN> You can also just do gdb --args ./ffmpeg_g your normal args
[23:03:55 CET] <BtbN> and then hit run once gdb is done starting
[23:04:06 CET] <JEEB> ok, that's another way yes
[23:04:14 CET] <JEEB> to pre-define the arguments
[23:04:21 CET] <BtbN> Usually more shell-history friendly
[23:04:26 CET] <JEEB> yes
[23:04:53 CET] <JEEB> keglevich: but you did find out that it was not the encoder nor the muxer that was your problem :P
[23:04:56 CET] <keglevich> so without setting UDP output bitrate, there's no simple option to have CBR UDP stream?
[23:05:10 CET] <BtbN> Well, it is CBR, over a short interval
[23:05:14 CET] <JEEB> no, because it is going to use whatever timing or blocking there is to run the UDP output
[23:05:24 CET] <BtbN> A bit of input buffering on the receiving end should fix any fluctuations
[23:06:07 CET] <keglevich> ok, about the receiving side...but would I be able to do the same on my (sender) side...I mean, create a simple output buffer, and send out clear CBR without fluctuations?
[23:06:30 CET] <BtbN> Isn't that exactly what the bitrate option for the UDP output does?
[23:06:32 CET] <JEEB> sure, but if you don't want to use FFmpeg's UDP output then you'll have to make your own
[23:07:01 CET] <keglevich> I understand...I'll try to do that gdb thing then and see what happens
[23:07:16 CET] <BtbN> Does it actually crash, as in seg fault. Or just throws an error at you?
[23:08:57 CET] <keglevich> the true issue with bitrate output parameter with ffmpeg was also that it didn't even output the whole bitrate...for instance if muxrate was 8500k and I set the bitrate=8500000 to ffmpeg output, it did really output only about 1.8mbit/s...
[23:09:28 CET] <keglevich> then when I started some other services (for instance VNC TCP service) it went up to 8.5mbit/s... no logical explanation here I know
[23:09:38 CET] <keglevich> I tried on different machines, windows and linux
[23:09:44 CET] <keglevich> really strange issues
[23:10:22 CET] <keglevich> and also crashes after a while...but I can't recall the crashing error...I guess it was something about "av_interleaved frames"...
[23:11:26 CET] <keglevich> but again...I still have that binaries, I'll run it now, a moment...
[23:16:50 CET] <keglevich> btw...should output "bitrate" parameter be exactly the same as muxrate or should it be a bit bigger, smaller?
[23:17:26 CET] <JEEB> unfortunately I have no idea
[23:17:33 CET] <JEEB> just that there is a feature to control the UDP rate
[23:19:10 CET] <keglevich> https://imgur.com/a/wJK6Mby
[23:19:22 CET] <keglevich> that's what I get with bitrate output...it's better, but far from perfect
[23:19:28 CET] <keglevich> and it crashes
[23:20:19 CET] <keglevich> https://imgur.com/a/ZQIZHNF
[23:21:00 CET] <keglevich> this one is even more obivous...not much fluctuations along the line, but when they happen, they're a lot bigger then without bitrate output parameter where they're constant, but small
[23:21:16 CET] <JEEB> if it *crashes* please get a backtrace. we have already told you how to get one
[23:21:48 CET] <JEEB> (also I'm wondering if the -re is part of your problem but I'd first like to see the crash)
[23:21:56 CET] <keglevich> yes I'll do that as well... but again, even without a crash, you can see that's not what we're looking for, it's even worse than without bitrate output parameter
[23:22:09 CET] <keglevich> as long as the line is stable, is good....but when is jumps, it jumps a lot
[23:22:23 CET] <keglevich> and that happens 2 times a minute as I can see now
[23:22:27 CET] <keglevich> or more
[23:23:05 CET] <JEEB> well at least you know what your problem now is :P
[23:23:07 CET] <JEEB> it's not the encoder
[23:23:09 CET] <JEEB> it's not the muxer
[23:23:21 CET] <JEEB> it's the I/O output to UDP
[23:23:26 CET] <keglevich> yes, it's UDP output I aware of that
[23:24:58 CET] <keglevich> av_interleaved_write_frame(): Cannot allocate memory0:59.79 bitrate=8462.4kbits/s speed=   1x Error writing trailer of udp://239.10.10.10:10000?pkt_size=1316&bitrate=8500000: Cannot allocate memory
[23:25:07 CET] <keglevich> this is the error I get when I crashes....
[23:25:11 CET] <JEEB> huh
[23:25:14 CET] <JEEB> it runs out of RAM?
[23:25:43 CET] <JEEB> keglevich: does it actually crash or just exit out?
[23:25:57 CET] <keglevich> and as strange as it may sound, it happens exactly when I stop tightVNC service...until then it runs at 8.5mbit/s as it should...when tightVNC is stopped it goes down to 1.3mbit/s and then crashes 10secs later
[23:26:11 CET] <keglevich> what connection does running tightvnc service has with this anyway?
[23:26:24 CET] <JEEB> I have no idea, sounds like weird OS network stack stuff
[23:26:25 CET] <keglevich> I just coincidently find that out as I had it installed on some PC's
[23:26:36 CET] <JEEB> because what FFmpeg does does not change
[23:26:41 CET] <keglevich> tightvnc runs on 5900 tcp
[23:26:46 CET] <JEEB> yes, FFmpeg doesn't care
[23:26:50 CET] <JEEB> it does the same things in the UDP module
[23:27:04 CET] <keglevich> that's really strange, but that's exactly what happens
[23:27:19 CET] <keglevich> I can post binaries with pthreads if you want to test them
[23:27:29 CET] <keglevich> 4.0.2 builds for windows
[23:27:29 CET] <JEEB> no, I don't. I can do them myself
[23:27:50 CET] <keglevich> is it possible a compilation issue?
[23:27:53 CET] <JEEB> no
[23:27:59 CET] <JEEB> it sounds like an OS network stack or so thing
[23:28:05 CET] <keglevich> I tried this with multiple versions, always same result
[23:28:16 CET] <keglevich> tried on win7, win10, different versions, always the same
[23:28:24 CET] <keglevich> also different NIC's, different PC's
[23:28:26 CET] <JEEB> anyways, can you try with an actual realtime input without using -re ?
[23:28:35 CET] <JEEB> yes, it sounds like an OS network stack or firewall issue
[23:28:56 CET] <JEEB> I can't say jack about network internals of windows, sorry
[23:28:57 CET] <keglevich> on linux is the same
[23:29:06 CET] <keglevich> tried on ubuntu
[23:29:23 CET] <JEEB> then it's something that happens to happen similarly
[23:29:47 CET] <JEEB> anyways, can you try removing -re and using a live UDP or so input ?
[23:29:57 CET] <keglevich> ok, a moment
[23:30:10 CET] <JEEB> mostly because -re does sleep() and while the thread is different I'm interested in how that goes
[23:33:02 CET] <keglevich> it's the same...I tried to catch another UDP output as input
[23:33:38 CET] <JEEB> alright. sorry then, I have no idea which part is crapping you over other than it has to do with the UDP output timing
[23:33:48 CET] <JEEB> (or the timing you receive those output packets)
[23:34:06 CET] <JEEB> you would have to do some serious debugging to even figure out if it's FFmpeg (libavformat) or not at fault
[23:34:24 CET] <keglevich> and that's way over my head
[23:34:32 CET] <keglevich> and my knowledge
[23:35:08 CET] <nadermx> If I'm using the -headers function in ffmpeg, and I want to send a cookie, can I use both -headers and -cookies or do I have to put the cookie in the -headers?
[23:35:59 CET] <JEEB> nadermx: I would think that cookies and headers are separate
[23:36:14 CET] <JEEB> even though cookies are passed as headers at the end I think?
[23:36:57 CET] <nadermx> right, that's why I think the -headers might be squashing the -cookies
[23:47:06 CET] <nadermx> The output when I run a -v trace with a cookie and header shows this, https://pastebin.com/mZ2YZwze
[23:47:40 CET] <nadermx> But it still shows a [http @ 0x561322cda660] No trailing CRLF found in HTTP header., not sure if that's on the local server, since I don't have a input file, or if it's because it's not sending the cookie
[23:49:19 CET] <JEEB> nadermx: well at least it isn't overwriting but appending it seems looking at http_connect in general
[23:49:23 CET] <JEEB> (in libavformat/http.c)
[23:51:52 CET] <nadermx> so why would it show the "No trailing CRLF found in HTTP header" warning
[23:51:56 CET] <JEEB> yea, it actually checks if the headers string doesn't have "\r\nCookie: "
[23:52:07 CET] <JEEB> and if it doesn't, it should call get_cookies
[23:52:19 CET] <JEEB> !has_header(s->headers, "\r\nCookie: ") && s->cookies
[23:52:32 CET] <JEEB> so no Cookies: part in headers, and s->cookies is set
[23:52:48 CET] <JEEB> which I guess is the thing that gets the cookies AVOption's contents
[23:52:59 CET] <JEEB> nadermx: what's your muxer btw
[23:53:18 CET] <JEEB> ok, it's a GET
[23:53:48 CET] <nadermx> I was just trying the trace before I tried putting a file on the server, wanted to make sure I had the config correct
[23:54:43 CET] <JEEB> anyways, the logic in that function where that message comes from with the request dumped
[23:54:46 CET] <JEEB> seems sound
[23:55:11 CET] <JEEB> the documentation for cookies is `use newline delimited Set-Cookie HTTP field value syntax`
[23:55:37 CET] <JEEB> and I don't think I see endlines there
[23:55:44 CET] <JEEB> so that might be it
[23:57:41 CET] <nadermx> so adding a \r\n after each cookie? or the final one?
[23:57:56 CET] <JEEB> well it says to *delimit* with newlines
[23:58:11 CET] <JEEB> whatever the Set-Cookie HTTP field value syntax is supposed to be :P
[23:58:19 CET] <tdr> newline is \n  not \r
[23:58:45 CET] <nadermx> my bad, let me try it
[23:59:26 CET] <tdr> the \r is line feed/carriage return (windows uses that).  the \n is newline
[00:00:00 CET] --- Sun Jan 20 2019