January 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190120
by burek 21 Jan '19

21 Jan '19

[01:04:10 CET] <cone-170> ffmpeg 03Shiyou Yin 07master:32421602dfb1: avcodec/mips: [loongson] optimize put_hevc_pel_bi_pixels_8 with mmi. [17:16:26 CET] <durandal_1707> Compn: how you managed to play ARBC? [17:22:16 CET] <Compn> durandal_1707 : that .drv file is 16bit [17:22:21 CET] <Compn> only works win95/win98 [17:22:26 CET] <Compn> have to have virtual machine [17:24:00 CET] <durandal_1707> Compn: but how you played it? [17:26:09 CET] <Compn> thats only way to play it [17:26:16 CET] <Compn> win95 virtual machine [17:27:35 CET] <durandal_1707> Compn: so plain win95 will play file if i just copy .drv? [17:35:32 CET] <Compn> no [17:35:34 CET] <Compn> theres setup file durandal_1707 [17:35:37 CET] <Compn> one min i'll zip it [17:42:01 CET] <Compn> durandal_1707 : http://samples.ffmpeg.org/V-codecs/ARBC/arbc-setup.zip [17:42:42 CET] <Compn> durandal_1707 : full disc here with setup files and samples https://archive.org/details/LIONKINGA [22:22:50 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:12b1338be376: avutil/mem: Optimize fill32() by unrolling and using 64bit [22:22:50 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:f64c0dffa13e: avutil/imgutils: Optimize memset_bytes() by using av_memcpy_backptr() [22:22:50 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:ec28a85107cc: avcodec/tiff: Check for 12bit gray fax [22:22:50 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:d3b76c999323: avcodec/prosumer: Simplify code slightly in decompress() [22:22:50 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:f0d48ac41f7a: avcodec/prosumer: Reduce lut size [22:22:51 CET] <cone-351> ffmpeg 03Michael Niedermayer 07master:62f8d27ef199: avcodec/prosumer: Error out if decompress() stops reading data [00:00:00 CET] --- Mon Jan 21 2019

1 0

ffmpeg.log.20190120
by burek 21 Jan '19

21 Jan '19

[00:00:04 CET] <JEEB> the headers I think have that standardized and the header parsing code expects that [00:00:20 CET] <JEEB> but I think the cookie option wants a simpler thing because it's supposed to be jsut some endline-delimited thing [00:00:26 CET] <JEEB> and it internally handles the cookie part [00:00:31 CET] <pink_mist> tdr: the \r is carriage return, the \n is linefeed ... aka newline [00:00:32 CET] <JEEB> uhh, header creation part I mean [00:00:32 CET] <tdr> ick. if thats what it uses, then stick with it tho [00:00:39 CET] <JEEB> tdr: the header thing that is [00:00:41 CET] <JEEB> which is raw headers [00:00:44 CET] <JEEB> as far as I can see :P [00:00:48 CET] <JEEB> there's a separate cookie option [00:00:52 CET] <tdr> pink_mist, whatever the names, \n is unix-y and \r is windows [00:00:56 CET] <JEEB> which is just endline delimited as far as I can tell [00:01:07 CET] <pink_mist> tdr: windows needs both \r and \n [00:01:18 CET] <JEEB> and it creates the header format from the cookie format [00:02:30 CET] <nadermx> it's not in windows, but even if I try -cookies "GPS=1; PREF=f1=50000000&hl=en; VISITOR_INFO1_LIVE=YYVg5wZlZM4; YSC=nqFTzbjynHk; s_gl=1d69aac621b2f9c0a25dade722d6e24bcwIAAABVUw==;\n" it still shows me the no CRLF warning [00:02:42 CET] <JEEB> nadermx: DELIMITED [00:02:57 CET] <JEEB> the docs say it pretty clearly [00:03:57 CET] <keglevich> JEEB: I found out if I set burst_bits parameter as well the output bitrate is OK....now the issue is I don't know what kind of value that burst_bits should really have? [00:04:18 CET] <JEEB> keglevich: no idea, I've never had to tweak those things [00:04:30 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&burst_bits=1000000&bitrate=8500000" [00:04:44 CET] <keglevich> that's what I have so far...it somehow works...not 100% ok, but at least it works [00:05:15 CET] <keglevich> I tried to look for more info regarding this parameter, nowhere a single mention of the preferred values [00:05:44 CET] <JEEB> the docs just say "When using bitrate this specifies the maximum number of bits in packet bursts. " [00:05:57 CET] <JEEB> so it probably controls how much is sent out max [00:06:00 CET] <JEEB> at a single send() [00:06:09 CET] <JEEB> or no idea really [00:07:41 CET] <keglevich> yes, that's the only thing I found as well...is there a way to find out the preferred values somehow, without jus try&error method? [00:07:55 CET] <JEEB> reading the logic from the code [00:08:03 CET] <JEEB> and matching that against your use case [00:08:14 CET] <keglevich> and that's something I'm really good at ;) [01:41:21 CET] <raytiley> Are there any parameters required for h264_qsv? [01:41:48 CET] <raytiley> Trying a simple ffmpeg command and get tons of "incompatible video parameters" warnings [01:42:10 CET] <raytiley> https://www.irccloud.com/pastebin/t8orRYyB/h264_qsv-log.txt [01:44:13 CET] <BtbN> Is this Linux? [01:44:24 CET] <BtbN> You really don't want to be using QSV on Linux, use libva instead [01:45:00 CET] <raytiley> windows [09:28:01 CET] <johnjay> question about mp4 files [09:28:13 CET] <johnjay> is it possible to cut a portion from the start or middle without reencoding it? [09:28:18 CET] <johnjay> or is that not possible in general [09:44:55 CET] <fella> johnjay: depends on your INPUT. and even if it does work you might run into problems afterwards. from wrong timestamps to standalone players refusing to play those files at all, so please keep that in mind when you try something like: ffmpeg -ss 00:10:00.00 -i INPUT -t 00:01:00.00 -c copy OUTPUT [09:46:38 CET] <fella> skip 10min from the beginning (-ss) and cut out 1min (-t) [12:33:41 CET] <saucecode> Hello, I'm trying to compile ffmpeg 4.1 on ubuntu 16.04. configure is telling me "ERROR: libnpp not found". I compiled ffmpeg 3.4.1 with these configuration options, so I'm not sure what's going on. Am I missing something? [12:33:54 CET] <saucecode> https://pastebin.com/raw/1WWnNWz5 here's what I'm passing to ./configure [12:35:02 CET] <JEEB> ffbuild/config.log [12:35:05 CET] <JEEB> is what you want to look at [12:35:09 CET] <JEEB> it should contain the actual error :P [12:40:06 CET] <saucecode> thanks! I think I see what I'm missing now [14:04:21 CET] <Jeen_> Hey [14:04:45 CET] <Guest31128> What is the webm equivalent of libx264? [14:04:54 CET] <Guest31128> libwebm doesn't works. [14:06:23 CET] <Mavrik> webm is a container [14:06:35 CET] <Mavrik> And it's supported natively by ffmpeg [14:06:59 CET] <Mavrik> You probably mean VP8 or VP9 which are usually put inside webm. The encoding library is called libvpx [14:07:48 CET] <Guest31128> Mavrik: Thank you. [18:57:10 CET] <shfil> hi, I'm getting a lot of `Invalid return value 0 for stream protocol`, I guess it's caused by this commit https://github.com/FFmpeg/FFmpeg/commit/a606f27f4c610708fa96e35eed7b7537d3d… [18:57:10 CET] <shfil> What can cause that read_packet returns 0? [18:58:53 CET] <shfil> when there's no EOF? [18:59:54 CET] <shfil> my code: https://github.com/rwengine/openrw/blob/master/rwengine/src/audio/SoundSour… [19:00:30 CET] <shfil> everything goes in `void SoundSource::loadSfx(LoaderSDT& sdt, size_t index, bool asWave)` [22:29:07 CET] <g1itch> I'm attempting to use ffmpeg to capture a clip from a live rtsp stream and i get the following output. it looks like it's connecting successfully but getting a bad response code? https://paste.w00t.cloud/hunayadoxe.bash [00:00:00 CET] --- Mon Jan 21 2019

1 0

ffmpeg-devel.log.20190119
by burek 20 Jan '19

20 Jan '19

[01:26:19 CET] <Compn> i'll upload the other arbc samples for durandal , but its all the same source [02:22:28 CET] <UukGoblin> hello, I was thinking to add a filter that could buffer decoded frames in order to smooth out playback (this is when software-decoding 10-bit HEVC on an Atom processor - it works most of the time, but has short periods where the codec is so intensive it eats up 100% CPU and frames get dropped) [02:23:17 CET] <UukGoblin> I started off looking at vf_random.c, as it has a buffer and does quite a similar job (or at least so I thought) [02:25:15 CET] <UukGoblin> but now I'm quite baffled whether I can do this at all: in particular, I'm wondering when filter_frame and request_frame get called... is it even possible that filter_frame will get called more often than request_frame? [02:26:12 CET] <UukGoblin> as in, during times when CPU would not normally be utilized at 100%, will filter_frame be called as often as possible, thus filling CPU back to 100%? [02:26:40 CET] <UukGoblin> or is mpv the only place where such buffering could be done? [03:16:07 CET] <cone-953> ffmpeg 03Jun Zhao 07master:32fb83e43188: lavc/hls: Cosmetics: Fix indentation for free_segment_list [03:50:59 CET] <Compn> UukGoblin : you know mpv has its own channel right ? [03:51:08 CET] <Compn> atom wasnt built for 10bit hevc methinks :D [03:52:46 CET] <UukGoblin> Compn, yeah, I know, but I suspect this kind of buffering should rather be done in ffmpeg. Someone there recommended writing a filter for it. [03:53:30 CET] <UukGoblin> Compn, Atom Z8350 software-decodes 10-bit HEVC almost-fine for me :-) and when increasing the thread count to 32, it's actually smooth on this test video I'm using [03:54:14 CET] <UukGoblin> the thread count increase seems to also increase the decoded-frame cache size, which does exactly what I want. I'm actually now searching whether it's possible to increase this thread via some option I've not yet found [03:54:21 CET] <Compn> hmm [03:54:31 CET] <UukGoblin> s/this thread/this cache/ [03:54:41 CET] <Compn> probably because the threads split up the frames against more buffrs [03:54:46 CET] <UukGoblin> yup [03:55:46 CET] <UukGoblin> extra_hw_frames doesn't seem to do it [03:56:10 CET] <UukGoblin> (probably because it's for hwdec) [07:39:01 CET] <rcombs> so I've been putting together checkasm for yadif [07:39:19 CET] <rcombs> and it turns out the existing ASM functions are not consistent with the C [07:40:07 CET] <rcombs> at least for 10- and 16-bit [07:41:31 CET] <rcombs> and the existing tests are broken [07:42:29 CET] <rcombs> FATE uses "-pix_fmt [format]", which converts _after_ the filter, so it doesn't actually test the 10- and 16-bit cases [07:44:15 CET] <rcombs> the SSE4 routine for 16-bit is actually fine, but the SSE2 version isn't, because it uses the PMINSD macro, which is lossy on SSE2 [07:47:39 CET] <rcombs> which should be no surprise, since it converts from 32-bit int to 32-bit float and back [10:47:14 CET] <nevcairiel> rcombs: interesting findings, but luckily high-bit-depth interlaced material is quite rare in consumer space :) [10:47:37 CET] <rcombs> yeah it's not a huge deal, just making these test cases very frustrating to implement [10:47:50 CET] <rcombs> in the field of "bigger deals", turns out VLC downloads updates over plaintext HTTP [10:48:00 CET] <rcombs> and verifies them against a PGP key that it also downloads over plaintext HTTP [10:48:46 CET] <nevcairiel> i dont suppose we have existing bitexact flags for filters eh [10:48:58 CET] <nevcairiel> probably not [10:50:21 CET] <rcombs> I'm just changing that particular macro to make the inexact path conditional on the caller requesting it [10:50:29 CET] <rcombs> it only has 2 callers (yadif and swscale) [10:50:52 CET] <nevcairiel> does it have an exact sse2 path even? [10:50:53 CET] <rcombs> maybe swscale doesn't use any values that don't round-trip through float losslessly, idk [10:51:13 CET] <rcombs> the SSE2 path is the inexact one; the MMX one is exact [10:51:26 CET] <nevcairiel> that sounds weird [10:51:31 CET] <nevcairiel> what did mmx have that sse2 didnt [10:51:36 CET] <rcombs> and only a couple instructions longer [10:51:50 CET] <rcombs> nothing, the SSE2 path just saves a couple instructions by being inexact [10:52:04 CET] <rcombs> see PMINSD in x86util [10:52:06 CET] <nevcairiel> i see [10:52:16 CET] <nevcairiel> the "mmx" path is also valid sse2, just longer [10:52:20 CET] <rcombs> yup [10:52:52 CET] <rcombs> (I think that's true of most cases where there's an MMX path and an SSE2 path, just, usually the SSE2 path is also exact) [10:53:02 CET] <rcombs> I'm kinda curious if it's actually even faster [10:53:14 CET] <rcombs> since it involves a floating-point transition [10:55:03 CET] <nevcairiel> looks like it was blindly stolen from swscale and put into the generic macro at some point, possibly without too much consideration of the limitations swscale might have on the code in the first place [10:55:29 CET] <rcombs> yup [10:55:37 CET] <rcombs> (I did look through the blame) [10:56:05 CET] <rcombs> I'm still trying to work out a problem with the 10-bit variant, which is being really weird [10:56:26 CET] <rcombs> the FATE test is passing whether I enable the ASM via -cpuflags or not [10:56:39 CET] <rcombs> but my checkasm pass isn't, and I can't figure out why [10:56:57 CET] <rcombs> the 8-bit variant was always fine, and the 16-bit variant is fine after fixing PMINSD [10:57:36 CET] <atomnuker> I kinda doubt that on modern CPUs you save much at all by going inexact [10:57:37 CET] <nevcairiel> I assume you fixed the fate pixfmt thing for that test [10:59:47 CET] <rcombs> yeah [11:00:18 CET] <rcombs> atomnuker: it's not so much saving by being inexact as saving by having a dedicated MIN instruction, instead of doing a compare and then some bitwise ops [11:00:49 CET] <rcombs> but my guess would be that the compare and bitwise ops would be cheaper (at least on modern CPUs) than converting to float, doing the MIN, and converting back [11:00:51 CET] <nevcairiel> I doubt it was even intentional to be inexact here [11:00:53 CET] <rcombs> even if it's more instructions [11:01:13 CET] <nevcairiel> just a lack of full understanding of the code [11:01:35 CET] <rcombs> if it actually mattered, I don't think FATE tests depending on that swscale code would pass [11:01:39 CET] <rcombs> (assuming there are any) [11:02:07 CET] <rcombs> like, if the inputs are always representable exactly as floats then it doesn't matter [11:02:21 CET] <rcombs> maybe that's true in the 1 place this is used in swscale, idk [11:02:42 CET] <nevcairiel> just have to keep the absolute value below 24-bit and its fine [11:02:50 CET] <rcombs> yeah [11:03:16 CET] <nevcairiel> when does sws deal with numbers over that, individual components typically end up 16-bit or lower in the end [11:03:23 CET] <nevcairiel> so maybe the error also just rounds out eventually [11:03:25 CET] <rcombs> probably never [11:03:30 CET] <rcombs> I'm not actually sure why yadif _does_ [11:03:41 CET] <atomnuker> maybe we ought to fix yadif to make it bitexact [11:03:57 CET] <rcombs> yes I'm working on that [11:04:00 CET] <nevcairiel> it is, if it doesnt use this "broken" instruction emulation [11:04:10 CET] <rcombs> well, for 16-bit [11:04:14 CET] <rcombs> still not sure what's wrong with 10-bit [11:04:26 CET] <nevcairiel> i would think 10-bit is just 16-bit with more zeros [11:04:38 CET] <nevcairiel> but maybe there is some extra magic to speed it up [11:04:39 CET] <rcombs> it's a whole different implementation [11:05:06 CET] <rcombs> I'd imagine one's derived from the other but it's in a separate .asm [11:05:36 CET] <rcombs> as opposed to just being macroized [11:19:11 CET] <kurosu__> regarding swscale discussion on sse2 vs mmx, one thing is that sse2 is actually the extension of mmxext [11:19:52 CET] <kurosu__> pavg(us)b needs several instructions and unpacking to be properly emulated [11:20:03 CET] <kurosu__> so maybe the mmx takes some shortcuts [11:20:32 CET] <kurosu__> no idea beyond that, I haven't looked at the rest of the discussion [00:00:00 CET] --- Sun Jan 20 2019

1 0

ffmpeg.log.20190119
by burek 20 Jan '19

20 Jan '19

[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-gc… [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-gc… [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

1 0

ffmpeg-devel.log.20190118
by burek 19 Jan '19

19 Jan '19

[01:50:09 CET] <rcombs> looking for additional feedback on my "enable TLS peer verification by default" patch [01:52:40 CET] <rcombs> actually come to think of it, I should probably only make that the default for client mode [01:52:45 CET] <rcombs> (what's server mode even for) [12:34:41 CET] <cone-096> ffmpeg 03Carl Eugen Hoyos 07master:399c8e860f48: lavu/frame: Fix typo. [14:59:28 CET] <j-b> 'morning [15:38:54 CET] <kierank> https://github.com/google/oss-fuzz/issues/2095 [16:25:36 CET] <Compn> j-b : how many codecs are known to exist? [16:26:11 CET] <Compn> i wonder if microsoft keeps its riff list up to date (just not publically) [16:49:48 CET] <kurosu__> (26+10)^4? [16:52:03 CET] <Compn> way to spoil the fun :P [16:56:17 CET] <funman> is CARL codec registered yet ? [16:59:05 CET] <durandal_1707> no, but CEH is [16:59:54 CET] <kurosu__> Compn, would an appropriate sed/awk/... line on libavformat/riff.c be funnier ? [17:00:50 CET] <kurosu__> oh, it could be case sensitive, so (2*26+10)^4 + (2*26+10)^2, counting audio codecs ? [17:14:21 CET] <Compn> kurosu : no, exist, not in ffmpeg [17:14:50 CET] <j-b> Compn: 10000 [17:14:58 CET] <Compn> in theory i want full exist - ffmpeg = codecs to find and document :P [17:15:26 CET] <durandal_1707> /KB Compn [17:18:31 CET] <durandal_1707> that .drv is using VFW or? [17:27:08 CET] <durandal_1707> Compn: have more ARBC files? [20:13:28 CET] <BBB> michaelni: I think the generic idea of a "decoding deadline" (in seconds or %) or "corruption threshold" (in % or pixels) is useful,but I think putting it in individual decoders may not be a great starting point [20:13:41 CET] <BBB> michaelni: how about making it more generic? [20:15:11 CET] <BBB> make it a real interface, and make it configurable [20:15:35 CET] <BBB> I think it's totally worth it, and the reason people dislike it is not b/c it's a bad idea, but because your current approach is arbitrary [20:15:47 CET] <BBB> why 5%? why start at that decoder? [21:03:13 CET] <atomnuker> I think the deadline for decoders should be based on the number of samples/pixels [21:04:21 CET] <atomnuker> 5% is quite a low amount imo considering a bitstream with an unoptimized coding tool could set it off probably [21:19:00 CET] <michaelni> BBB, I can make it configurable. Happy to do so if that makes more people happy. [21:19:48 CET] <BBB> don't make me happy; do it because you agree it's right[TM] [21:20:17 CET] <BBB> my happiness is not affected by this much [21:21:38 CET] <michaelni> i agree its slightly better to have it configurable, in reality i doubt that parameter will be used much [00:00:00 CET] --- Sat Jan 19 2019

1 0

ffmpeg.log.20190118
by burek 19 Jan '19

19 Jan '19

[00:07:04 CET] <dostoyevsky> Hi. I am trying to cut out a part of a mkv video like -ss 60 -t 2 <- but when I look at the resulting video in VLC it seems not to display anything for a while and then suddenly I see 2-3 frames, followed by a freeze. at the same time I can hear the audio working well. It seems to me as if the mkv has some buffer sections and I cannot simply go whereever I like with -ss and -t [01:23:26 CET] <dostoyevsky> I can get over the freezes if I decrease -ss by 5 seconds and raise -t... then the video will start to unfreeze at about where I want. I am wondering if maybe I should convert the video to another format so I can do more a more precise cut out and then convert the resulting video back to mkv [01:24:37 CET] <furq> dostoyevsky: you generally can't cut videos precisely with -c copy [01:24:44 CET] <furq> unless you happen to want the cut to be exactly on a keyframe [01:25:02 CET] <kevinnn> JEEB: hey are you still around? [01:25:11 CET] <furq> if you reencode the video while cutting it should be fine [01:25:18 CET] <furq> just the video, no need to touch the audio [01:26:08 CET] <dostoyevsky> furq: thank you! [01:32:06 CET] <dostoyevsky> furq: works now :) [02:40:10 CET] <termos> I have an issue where i push data to av_interleaved_write_frame, where it buffers up enough data to create a ts segment. The problem is if my http endpoint goes down, a whole segment can be lost as I avio_close the input and re-open it. Is there a best practice way to avoid losing packets/segment here? [02:40:28 CET] <termos> s/input/output [02:56:00 CET] <termos> it could be that i'm using a custom hls_start_number_source and when one output goes down, the other one keeps on counting on it's own [08:53:34 CET] <zyme> Any chance you guys know anything about ffdshow video decoder? [08:54:45 CET] <JEEB> I did work on it briefly in 2011 or so, but soon after that it became more or less unneeded. it's a thing that uses its internal copy of FFmpeg and is barely maintained by clsid nowadays (since I don't think even he uses it any more) [08:54:51 CET] <zyme> I just don't get why it shows up in my system tray along with LAV when LAV is configured to do all the decoding.. [08:55:23 CET] <zyme> https://usercontent.irccloud-cdn.com/file/YntkN2sb/sys-tray.png [08:56:11 CET] <JEEB> it does filtering as well so it's really simple for it to catch up into the filter chain :P [08:56:21 CET] <JEEB> have fun checking your player or DShow config for why that is the case [08:56:41 CET] <JEEB> unfortunately, has pretty much nadda to do with FFmpeg itself [08:59:06 CET] <zyme> I have mpc-hc+mpc-be atm, mpc-be likes to force ffdshow to be used exclusively and has this rediculous interface on the add+config plugins page, though I'm not sure that page does anything at all lol.. [09:00:42 CET] <JEEB> yea, have fun with that :P I'd just unregister ffdshow-tryouts (original ffdshow died in like 2008 or so?) if you don't use it [09:00:44 CET] <zyme> but generally I wonder if it's adding another conversion layer or even just making the output not as nice as LAV.. which I mostly just use because of the hardware gpu/CUVID support [09:01:48 CET] <zyme> hmm... hopefully my apps are smart enough to not just crash on attempting to play if I were to uninstall it.. [09:03:38 CET] <zyme> I tried playing around with enabling the filters, and while I love the "apply only to right half" that's only because it makes it obvious that anything I try turning on makes the video look worse =) [09:25:47 CET] <cluelessperson_> ptx0: You banned me because your communciation skills are shit and you're blaming me for YOUR misunderstanding and assumptions. [09:26:13 CET] <cluelessperson_> ptx0: stop being a shithead. [09:26:29 CET] <cluelessperson_> You sat there and mocked me, gave me roundabout responses, and made assumptions [09:26:41 CET] <cluelessperson_> You were WRONG at every turn. [09:26:58 CET] <cluelessperson_> and if I'd listened to you outright, I'd have wasted money on hardware. [09:27:03 CET] <cluelessperson_> You're the one not listening. [09:27:49 CET] <ivki> Hello [09:28:12 CET] <ivki> I'm trying to convert png files to a webm/vp8 video with ffmpeg version 3.4.5 on centos7. [09:28:29 CET] <cluelessperson_> like, individual frames? [09:29:31 CET] <ivki> I use this command and I have this error : https://paste.frsag.net/fAw6C [09:29:46 CET] <ivki> cluelessperson_ yes [09:30:23 CET] <ivki> It was working with the version 2.6.9 [09:41:51 CET] <pink_mist> cluelessperson_: while I agree that ptx0's communiction skills are sometimes lacking, yours were bleeding atrocious. also this is not the right place to drag your disagreement with him into. [09:43:24 CET] <cluelessperson_> pink_mist: I think you came in halfway through the conversation and didn't see the obvious context I gave, repeatedly. He banned me without reason so I cannot plead my case. [09:43:55 CET] <pink_mist> I've seen your conversations since sometime in december I think [09:44:36 CET] <cluelessperson_> pink_mist: I'm not the best people person, but I absolutely methodically and logically laid out the syptomes and problems I ran into and the context. They just chanted "buy more ram" and they were absolutely wrong. [09:45:10 CET] <pink_mist> and yes. he's an op. he gets to ban people. it's part of the prerogatives of an op. whether you get to appeal or not depends competely on the channel in question, and you just haveto live with it. [09:53:46 CET] <cluelessperson_> pink_mist: or, I can ignore dumb power tripping mods that ban people for no reason. [09:54:44 CET] <furq> you can ignore them by starting a fight with them in another channel [10:06:58 CET] <cluelessperson_> sorry for annoying this channel, you're right. [17:06:21 CET] <ddubya> any ideas how I can repair mkv with read errors? Now I'm trying to use -c copy and seek over the bad part but no dice [17:06:25 CET] <_Vi> Can I use formulas in noise bsf parameters? E.g. specify "amount" depending on time? [17:07:04 CET] <_Vi> ddubya, Try mkvmerge or try my tool like mkv2xml+xml2mkv or HsMkv's transmux. [17:08:14 CET] <ddubya> hmm [17:08:25 CET] <ddubya> can it skip over corruptions? [17:08:33 CET] <ddubya> or excise them [17:08:39 CET] <ddubya> the data is definitely corrupted [17:10:36 CET] <ddubya> or do you mean use mkvmerge to split it manually? [17:18:22 CET] <ddubya> _Vi, thanks. I tried mkvmerge but it chokes when it hits the corruption. There is no option to skip over it [17:21:51 CET] <_Vi> ddubya, My program mkv2xml tries to resync to some nearest cluster on corruption. [17:22:25 CET] <ddubya> mkvmerged tries to rsync and fails, seems to read out to EOF and gives up [17:22:42 CET] <_Vi> ddubya, But I also expect FFmpeg to also resync on corruption. Are you sure there is any useful content in the file after first corruption point? [17:23:06 CET] <_Vi> ddubya, If the file is small and non-sensitive, you can just publish it and give a link. [17:23:13 CET] <ddubya> yeah, I'm rechecking that. I assumed it would play in vlc but maybe not [17:24:12 CET] <_Vi> ddubya, No report about success or failure of this: https://github.com/vi/mkvparse [17:26:00 CET] <ddubya> well, thanks for your help, but I'm an idiot it seems. I could have sworn I watched this movie in vlc before, now it will not seek over the corruption [17:26:42 CET] <_Vi> ddubya, You can post the last megabyte of the file somewhere, and we'll see if it seems to contain anything resembling mkv data or not. [17:27:44 CET] <_Vi> ddubya, Maybe storage drive is degrading and more and more of content getting lost? [17:28:24 CET] <ddubya> yeah I considered bitrot so I verified the checksum in my backups [17:30:18 CET] <ddubya> well I think I learned something anyways, thanks for the help [17:37:01 CET] <Aerroon> what would be the fastest way out of common encoders to encode a video of a static image (to lower filesize)? [17:37:14 CET] <Aerroon> doesn't have to be good, but simply fast encoding [17:37:45 CET] <Aerroon> right now its that same static image just copied over and over and over again [17:41:19 CET] <Aerroon> or alternatively, is it possible to do something like [17:41:54 CET] <Aerroon> ffmpeg -stream_loop -1 -i image.png -i audio.m4a -shortest etc [17:42:12 CET] <Aerroon> without ffmpeg trying to decode the image on every single loop again? [17:55:14 CET] <BtbN> Try setting a ridiculously low fps [18:59:32 CET] <Aerroon> BtbN, thanks! [19:00:04 CET] <Aerroon> although i feel it doesn't work quite as i expected [19:00:40 CET] <Aerroon> just to clarify [19:00:42 CET] <Aerroon> -r[:stream_specifier] fps (input/output,per-stream) [19:00:56 CET] <Aerroon> how would i set the (input/output) part [19:01:17 CET] <BtbN> what? [19:01:36 CET] <Aerroon> as in, how would i specify whether it should be for input only [19:01:41 CET] <BtbN> That's not a parameter, it just tells you it's a per-stream option for both input and output streams. [19:01:47 CET] <Aerroon> oh [19:02:02 CET] <BtbN> Its positioning on the commandline determines which stream it affects [19:03:09 CET] <Aerroon> cause when i run [19:03:33 CET] <Aerroon> ffmpeg -r 1/100 -stream_loop -1 -i image.png -i audio.mp3 -shortest -c:v libx264 -c:a copy -r output.mkv [19:03:49 CET] <Aerroon> it doesn't quite work since the resulting video's playback seems to start like an hour and 30 minutes in [19:04:09 CET] <BtbN> try setting it on the output stream [19:04:46 CET] <BtbN> even though it should carry over. Can also just try on both at the same time [19:17:46 CET] <BtbN> Another idea would be -r 0.0000001 on the input, and normal -r 30 on the output. That should make it duplicate the decoded frame. [19:18:24 CET] <BtbN> And you want to set a very long GOP for this kind of static "video" [19:25:47 CET] <Aerroon> ohh, that last one might've worked [19:26:02 CET] <Aerroon> i don't know anything about GOP, i'll look into it later, but if this just works even then i'll be happy [19:26:24 CET] <BtbN> Why do you even care about decoding the input frame a lot? Decoding a png image should be fairly quick [19:26:43 CET] <Aerroon> because last time i asked about it i was told that [19:26:55 CET] <Aerroon> ffmpeg -stream_loop -1 -i image.png -i audio.mp3 -shortest -c:v libx264 -c:a copy -r output.mkv [19:27:03 CET] <Aerroon> this decodes image.png every frame [19:27:18 CET] <BtbN> Yeah, it does. But why is that a problem? Is it that slow? [19:27:24 CET] <Aerroon> and this means that how long it takes to actually put this together is basically entirely dependent on how quickly it decodes [19:27:50 CET] <BtbN> I'd expect it to be limited by the encoder in either case [19:28:03 CET] <TheAMM> You might be able to use some sort of lavfi-complex for the looping [19:28:08 CET] <Aerroon> libx264 -preset slowest goes at the same speed as h264_nvenc [19:28:13 CET] <TheAMM> Like overlay will stick with the latest frame [19:28:25 CET] <TheAMM> So you'd only decode once and then buffer it [19:28:28 CET] <Aerroon> i don't know what that means, sorry [19:28:35 CET] <Aerroon> but videos are not decoded multiple times though! [19:28:38 CET] <Aerroon> so if i went with [19:28:46 CET] <BtbN> duplicating it a ton via the fps trick should achive the same [19:29:00 CET] <Aerroon> ffmpeg -stream_loop -1 -i video.mp4 -i audio.mp3 -shortest -c:v libx264 -c:a copy output.mkv [19:29:03 CET] <Aerroon> it's fine [19:29:34 CET] <BtbN> I don't think it will behave differently depending on the container of the input video [19:29:41 CET] <BtbN> a .png is just a special case of a video for ffmpeg [19:30:06 CET] <Aerroon> it does [19:31:54 CET] <Aerroon> even with just libx264 it's a difference of several times in speed [19:32:01 CET] <Aerroon> and if i use h264_nvenc it's even greater [19:33:11 CET] <Aerroon> but the solution you suggested with a low input framerate and a normal output framerate is even better [19:33:22 CET] <BtbN> Ah, there seems to be a special case for then the image on disk is actually constantly refreshed, so an actual video in a weird sense [19:33:32 CET] <BtbN> that's why it's re-decoding it every access [19:34:02 CET] <Aerroon> i'll see what youtube says about the one that you suggested [19:34:22 CET] <Aerroon> the problem with that version is that mpchc didn't run it at all (but VLC did!), but VLC didn't let me seek [19:34:33 CET] <Aerroon> but all i need it for is to upload to youtube anyway so it doesn't matter if those don't work properly [19:34:43 CET] <BtbN> The resulting video should be a normal 30 fps video [19:34:51 CET] <BtbN> If some player refuses to play it, something went wrong [19:36:49 CET] <Aerroon> okay, so audio track is 1:23:41, but the resulting video is 1:33:20 [19:36:54 CET] <Aerroon> i guess the quest continues! [19:38:09 CET] <Aerroon> it's a rather interesting problem, becuase you'd think this would be a really easy thing to do [19:38:43 CET] <Aerroon> the wrong audio duration might be due to some audio stuff though [19:42:28 CET] <BtbN> Have you tried using loop instead of stream_loop? [19:43:49 CET] <Aerroon> i have not [19:44:35 CET] <Aerroon> all the docs say is [19:44:44 CET] <Aerroon> >Repeatedly loop output for formats that support looping such as animated GIF (0 will loop the output infinitely). This option is deprecated, use -loop. [19:44:53 CET] <Aerroon> it doesn't give me anything else on what -loop does so i have no idea how to use it [19:45:41 CET] <BtbN> https://trac.ffmpeg.org/wiki/Slideshow#Singleimage [19:45:55 CET] <Aerroon> oh, i looked over here https://ffmpeg.org/ffmpeg.html [19:45:57 CET] <Aerroon> thanks [20:11:11 CET] <ossifrage> Huh, the i-frame only version of this encode came out smaller then IPPPPPI at the same crf. [22:23:52 CET] <GTest1989> Hello, anyone here to assist? [22:24:24 CET] <GTest1989> I have a Black Magic DeckLink device I can't get to work. Getting an I/O error. [22:28:59 CET] <friendofafriend> GTest1989: Post the error to a paste site, like http://paste.debian.net [00:00:00 CET] --- Sat Jan 19 2019

1 0

ffmpeg-devel.log.20190117
by burek 18 Jan '19

18 Jan '19

[01:17:31 CET] <Compn> what [09:35:47 CET] <ubitux> thardin: ah mmh interesting the gif fix [09:35:57 CET] <ubitux> i'm going to look at this [11:12:02 CET] <thardin> ubitux: you can just download the files off my webzone and run the script to see the differences [11:13:29 CET] <ubitux> why do you tell me this? what script? [11:13:39 CET] <ubitux> took me a while but i noticed the black dots [11:14:45 CET] <thardin> yeah you need to zoom [11:15:03 CET] <thardin> it's more noticable on the say 32 or 16 color sample that's in the same directory on my server [11:15:31 CET] <thardin> the dithering turns everything into chaos tho [11:15:45 CET] <ubitux> :) [11:17:09 CET] <thardin> it's rather crappy that the best way to get a small looping video working in every browser is still a gif [11:17:52 CET] <thardin> firefox is a bit better now tho and doesn't block muted looping videos by default [11:22:18 CET] <nevcairiel> unless i'm mistaken, but why would you make 32 or 64 color gifs? afaik it either has a 16 color palette, or a 256 color palette, using any intermediates seems wasteful? [11:23:51 CET] <ubitux> it probably improve the lzw after that [11:24:17 CET] <ubitux> zipping a limited range of value might compress more, but i dunno [11:24:30 CET] <ubitux> also, palette filter speed maybe? [11:24:45 CET] <ubitux> last one, "style" [11:26:51 CET] <ubitux> output-fixed-64.gif 1.7M [11:26:52 CET] <ubitux> output-fixed-128.gif 1.9M [11:26:54 CET] <ubitux> output-fixed-256.gif 2.1M [11:27:53 CET] <thardin> yeah for size [11:28:05 CET] <thardin> this goes out to 200k readers or so [11:29:17 CET] <nevcairiel> i would think the reduction in dithering noise might offset some of the smaller-number gains, but perhaps not enough [11:31:16 CET] <JEEB> hmm, I wonder if anyone can hint to me what I'm doing wrong with my subtitle decoder [11:31:30 CET] <JEEB> https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff [11:31:43 CET] <thardin> nevcairiel: output-fixed-32.gif is larger than output-fixed-64.gif so it's certainly a factor [11:31:46 CET] <JEEB> currently it's a minimal thing just that grabs the basic "all the text without styling" [11:31:52 CET] <ubitux> JEEB: do you have a full readable diff? [11:32:25 CET] <JEEB> new file so https://github.com/jeeb/ffmpeg/blob/673dea189ba3e4b7f81f3beeb937b1617ded464… [11:32:33 CET] <thardin> it also struck me that a zopfli-type effort for lzw might be good [11:32:33 CET] <JEEB> in MPEG-TS I just set the AVCodec ID [11:32:40 CET] <nevcairiel> thardin: ah, but the a dvantage of course dissipates as you get more colors already [11:32:54 CET] <JEEB> (and profile and AVCodec type) [11:32:55 CET] <JEEB> https://kuroko.fushizen.eu/videos/arib_captions_colors_positioning_ruby_sub… [11:32:59 CET] <JEEB> sample file [11:33:07 CET] <thardin> nevcairiel: yes there's a sweet spot in this case [11:33:11 CET] <ubitux> JEEB: btw, i hope you will add a fate test, cause im breaking shit currently [11:33:16 CET] <JEEB> yes, I will [11:33:22 CET] <thardin> with fixed dither it's a different story [11:33:32 CET] <thardin> then you typically always get smaller files the fewer colors you have [11:33:57 CET] <nevcairiel> but also ugly ugly results [11:33:57 CET] <nevcairiel> :D [11:34:01 CET] <thardin> yeah :) [11:34:02 CET] <JEEB> ubitux: with `ffprobe -show_frames` for that stream I'm getting valid-looking stuff, and `ffmpeg -fix_sub_duration -i input.ts -map "0#0x114" -c:s ass out.ass` seems to work [11:34:05 CET] <JEEB> *but* [11:34:13 CET] <JEEB> for whatever reason mpv doesn't show the subs [11:34:20 CET] <JEEB> so either mpv is bugged or my code is bugged [11:34:24 CET] <JEEB> (or does something different) [11:37:43 CET] <ubitux> what decoder did you use as reference? does the one you used as reference work for mpv? [11:38:07 CET] <ubitux> if it does, compare the demuxers and check if pts/duration are set similarly [11:38:10 CET] <JEEB> I checked what things libzvbi and webvtt do [11:38:25 CET] <ubitux> does libzvbi works with mpv? [11:38:57 CET] <JEEB> I /think/ it does, I've seen the text spam from the time when it set the subtitle duration to 30 sec by default [11:39:21 CET] <ubitux> i'd compare the demuxers [11:39:23 CET] <JEEB> but yea, mostly it's if I'm forgetting to set some value somewhere, that's why I started looking at webvtt etc [11:39:25 CET] <ubitux> debug the packets with ffprobe [11:39:49 CET] <JEEB> libzvbi and this are both from MPEG-TS so there's that at least [11:39:49 CET] <ubitux> also, check the decoder flags, and check if mpv has exception wrt ccaption [11:40:23 CET] <JEEB> but yea, the AVSubtitles at least seem to have sane'ish PTS and duration. [11:40:30 CET] <JEEB> AVPacket I will have to double-check [11:40:42 CET] <JEEB> but since AVSubtitle probably gets init from the AVPacket [11:40:53 CET] <ubitux> in my current work i have a lot of trouble with ccaption and their delay [11:41:53 CET] <ubitux> sorry, no other hint for now, i don't have time to debug it right now [11:42:31 CET] <JEEB> ok, but at least it's positive that I'm getting semi-sane values from ffprobe's -show_frames, and .ass output seems to be OK [11:42:47 CET] <JEEB> (just needs -fix_frame_duration for the AVSubtitles where your duration is INT32_MAX) [11:43:44 CET] <cone-288> ffmpeg 03Gyan Doshi 07master:f60fdbc96074: avfilter/extractplanes: add support for 12-bit YUVA formats [11:51:22 CET] <thardin> hm right fate needs updating for the palettegen patch [11:56:34 CET] <kurosu> thardin: "that a zopfli-type effort for lzw might be good" <- aren't there some better GIF encoders around, which are bound to have better LZW engines [11:57:18 CET] <thardin> I'd say it's likely [11:58:10 CET] <kurosu> gifsicle iirc, but I don't know if the source code is available/split in nice modules/libs [11:58:42 CET] <kurosu> oh, I skimmed a bit fast, it is about gif [11:59:01 CET] <kurosu> I thought it was only about subtitles [12:02:33 CET] <thardin> hm maybe it can be run as a secondary stage [12:06:56 CET] <thardin> uhm running gifsicle with --optimize made the result larger [12:08:53 CET] <thardin> ah -O3 got the size down [12:10:00 CET] <thardin> 1970455 -> 1934731 bytes [12:11:37 CET] <glynd> Hi [12:12:30 CET] <durandal_1707> thardin: is hash same? [12:13:34 CET] <glynd> Think I've found / identified / fixed a minor bug in ffmpeg options processing - trying to identify the correct process to verify the fix doesn't break anything [12:14:14 CET] <thardin> durandal_1707: what before and after optimizing? no? [12:14:23 CET] <thardin> or of the raw frames maybe. hmm [12:14:56 CET] <durandal_1707> raw frames [12:15:37 CET] <thardin> yep! [12:15:48 CET] <thardin> tested like so: ffmpeg -i output-fixed-128.gif -f rawvideo - | sha1sum [12:16:14 CET] <durandal_1707> thardin: ffmpeg have own hash muxer [12:16:34 CET] <thardin> so I suspected [12:17:01 CET] <kurosu> -f framecrc ? [16:21:49 CET] <jamrial> ubitux: can i also get a review for my paletteuse patch? :p [16:51:49 CET] <ubitux> jamrial: done [16:52:06 CET] <jamrial> ubitux: thanks! [16:52:08 CET] <ubitux> jamrial: i suppose you didn't expect nor observe any perf gain? [16:53:03 CET] <ubitux> just curious, how did you come across this code? grep or while casually looking around? [16:54:53 CET] <jamrial> didn't bench it, just made sure the fate tests didn't fail [16:54:57 CET] <jamrial> there's going to be a gain but it's probably negligible [16:55:13 CET] <jamrial> and yeah, grep for av_frame stuff out of curiosity :p [17:27:05 CET] <cone-288> ffmpeg 03James Almer 07master:af05070ddf8e: avfilter/vf_paletteuse: don't constantly free and realloc internal frames [22:54:18 CET] <cone-360> ffmpeg 03Guo, Yejun 07master:1ef4828276e4: avutil: add ROI (Region Of Interest) data struct and bump version [22:54:18 CET] <cone-360> ffmpeg 03Guo, Yejun 07master:aceb9131c169: avcodec/libx264: add support for ROI-based encoding [00:00:00 CET] --- Fri Jan 18 2019

1 0

ffmpeg.log.20190117
by burek 18 Jan '19

18 Jan '19

[00:04:41 CET] <DHE> Most C structures are fair game for direct editing, especially if the doxygen docs describe them as such. av_opt_* (and by extension, av_dict_*) are intended for options set externally (like the ffmpeg commandline) or codec-specific values that are not expressed in the standard structures. [00:11:44 CET] <zerodefect> Sorry, just seen response. [00:11:45 CET] <zerodefect> Ok. Thanks for clarification. This is something that has concerned me, so I've explored it a bit more. You have brought me some relief :D [00:13:20 CET] <zerodefect> @DHE - so do you ever use av_opt_set_xxx options other than to set codec-specific values? [00:38:18 CET] <DHE> zerodefect: no. and even then I use AVDictionary instead [00:39:25 CET] <zerodefect> Not considered using AVDictionary. What advantage does it give you? Easier somehow? [00:40:27 CET] <DHE> it's just how I started doing it. All the avcodec and avformat "open" functions taken an AVDictionray so when I learned how to use the API that was the route I started down first. [00:44:22 CET] <zerodefect> Makes sense. [01:17:06 CET] <semeion> I am trying to run this command: http://ix.io/1yv7 [01:19:23 CET] <semeion> but have something wrong, because it return an error: http://ix.io/1yv9 [01:19:56 CET] <semeion> " Unsupported input format: bgr0" [01:21:34 CET] <semeion> so, changing the filter to -filter:v format=nv12,hwupload_cuda,scale_npp=w=1280:h=720:format=nv12:interp_algo=lanczos,hwdownload,format=nv12 it work, but i donŽt take the advantage of gpu conversion between the bgr0 to nv12 [01:22:36 CET] <semeion> i tried -filter:v hwupload_cuda,scale_npp=w=1280:h=720:format=bgr0:interp_algo=lanczos,hwdownload,format=nv12 it could work, but donŽt [01:23:30 CET] <semeion> can someone help me? [01:23:40 CET] <semeion> please [01:24:04 CET] <fling> [nut @ 0x5583d85a76c0] frame size > 2max_distance and no checksum [01:24:12 CET] <fling> What does this mean? ^ I'm getting these a lot [01:28:30 CET] <semeion> seems like i need convert from bgr0 to nv12 before start the scale_npp filter, but how to convert it using the GPU/CUDA? [01:29:02 CET] <semeion> and/or how to make the scale_npp convert it? [01:33:01 CET] <Hello71> fling: what version [01:48:40 CET] <fling> Hello71: 4.1 [03:23:34 CET] <Zexaron> hello [03:23:59 CET] <Zexaron> is it possible to software transform 170 wide eyefish lens video into more standar looking ? [03:24:06 CET] <Zexaron> and to be a playable video [03:35:17 CET] <friendofafriend> goog [03:35:22 CET] <friendofafriend> Sorry. [03:53:31 CET] <Zexaron> ah, later, sleeptime [04:00:49 CET] <lovetruth> hello people :) [04:01:11 CET] <lovetruth> do you know if it's possible to compile ffmpeg with NDI and nvenc?... [05:23:47 CET] <friendofafriend> Howdy, all. I'm using ffmpeg to encode opus with the "-application voip" flag. How can I find out what options are actually being used? [06:01:12 CET] <N0BOX> Would it be outside the scope of this channel to ask how to use fmmpeg to fix broken/missing metadata in a flac file? [06:04:27 CET] <fling> N0BOX: there is -metadata in manual but there are much better apps for tagging like beets [06:05:53 CET] <N0BOX> Yeah, I would probably be lazy use a GUI app on windows to actually fix the metadata if it is possible, but the problem is that the flac file is not showing its bitrate or duration [06:06:24 CET] <N0BOX> at least, those two specs don't show in foobar2000 [06:07:14 CET] <N0BOX> some apps simply won't play the file, and none of the converters I have tried will convert it to some other format [06:07:59 CET] <N0BOX> foobar2k and vlc don't mind playing it on windows and Onkyo HFPlayer will play it on Android, but I really want it to play in HiBy Music on android [06:08:56 CET] <N0BOX> so, I was hopin there might be some way of having ffmpeg analyse the file and come up with its proper duration and bitrate for me to somehow re-tag those bits with some other app [06:09:05 CET] <N0BOX> hoping* [06:09:12 CET] <fling> N0BOX: try repackaging it with `ffmpeg -i bad.flac -c copy fixed.flac` [06:09:30 CET] <fling> N0BOX: it would be good idea to redownload the file if it will not get fixed. [06:10:49 CET] <fling> N0BOX: you should really look at beets if you are into tagging or music library etc [06:10:51 CET] <N0BOX> interesting: size= 26526kB time=00:03:10.95 bitrate=1138.0kbits/s speed=1.61e+03x [06:11:13 CET] <N0BOX> but the 'fixed' flac still lacks the duration and bitrate xD [06:11:23 CET] <N0BOX> but that at least told me the info I needed to know [06:11:33 CET] <fling> N0BOX: then set it by hand or let beets set it for you haha :D [06:11:40 CET] <N0BOX> yep :D [06:11:48 CET] <fling> N0BOX: are we talking about two certain tags right? [06:12:01 CET] <fling> N0BOX: they are missing in the file but you want them to be there? [06:12:42 CET] <N0BOX> I assume they are metadata tags, but basically in foobar2000 in my playlist window each song has a bitrate and a duration except for this one song that has trouble in other players [06:12:55 CET] <furq> neither of those are metadata tags [06:13:16 CET] <furq> it sounds like the streaminfo block is broken [06:13:21 CET] <N0BOX> ahh, I was kinda afraid of that [06:13:24 CET] <furq> try ffmpeg again without -c copy [06:14:31 CET] <N0BOX> ahh, nice, the 'fixed' flac has those bits, now [06:15:15 CET] <fling> furq: thanks! [06:15:30 CET] Action: fling reads on streaminfo [06:20:08 CET] <N0BOX> and, the verdict is in: "It Works!" [06:20:43 CET] <N0BOX> Thanks for the help, I doubt I would have figured it out on my own with Google telling me all the incorrect answers [06:21:41 CET] <fling> 60% of time I'm incorrect all the time. [06:23:09 CET] <N0BOX> haha [06:23:53 CET] <N0BOX> man, dunno what I bumped on my mouse to cause irssi to drop the window :P [06:24:29 CET] <N0BOX> oh, one of my buttons is bound to F4, which I have set to close windows :P [07:14:05 CET] <ossifrage> Getting the right magic order for -threads can be interesting. I'm finally getting it to use more of the available cpu [07:16:11 CET] <ossifrage> It would be nice if ffmpeg named its threads so you knew who was doing what [07:17:44 CET] <ossifrage> (it is kinda annoying that linux limits the thread name to 16 chars) [10:29:54 CET] <TheWild> hello [10:31:01 CET] <cousin_luigi> [5~ [10:33:42 CET] <TheWild> I have a video and I would like to put a program-generated overlay on it. How I see it: ffmpeg decodes the frame and sends it as a image to my program, preferably with time. My program then puts overlay on it, returns the modified image and ffmpeg encodes it into new video. [10:33:47 CET] <TheWild> and I have no idea where to go [10:34:30 CET] <TheWild> I don't want run ffmpeg thousands of times, everytime specifying which frame to extract [10:45:55 CET] <kurosu> maybe programmatically (what you say seems to imply shell script, invoking the ffmpeg binary) [10:46:49 CET] <kurosu> TheWild: also, https://ffmpeg.org/ffmpeg-filters.html#select maybe if you can somehow instead pass everything to ffmpeg [10:47:47 CET] <kurosu> ffmpeg can't do accurate seeks in a lot of cases without a lot of setup, so there may be some issue in your approach [10:49:36 CET] <TheWild> so that's why I want to do it frame-by-frame. I think every frame has a timestamp. [10:51:02 CET] <furq> the simplest format for piping to/from your program that has timestamps is probably yuv4mpeg [10:51:20 CET] <furq> assuming your video is yuv [10:51:44 CET] <TheWild> I think the stuff I want to do is too specific for ffmpeg to handle on its own. I could just decode a video into a set of pictures, but it just unnecessarily takes up space when it could really get pipelined. [10:51:51 CET] <furq> https://wiki.multimedia.cx/index.php/YUV4MPEG2 [10:52:22 CET] <pink_mist> TheWild: ffmpeg can put an overlay on a video just fine [10:54:07 CET] <TheWild> YUV4MPEG2? Wow, not RGB but a quick read makes me think it will serve. And even format is documented. [10:54:12 CET] <TheWild> thanks furq [10:57:53 CET] <kurosu> I suspect TheWild use case is that the overlay depends on the frame and its timestamp, and is thus generated on the fly according to his needs [10:58:14 CET] <kurosu> obviously one could use ffmpeg various filters to generate said overlay obviously [10:58:19 CET] <TheWild> ^ yup, exactly [10:58:35 CET] <kurosu> if not too complicated, but that would not fit his need [10:59:08 CET] <TheWild> the animations and whatever - I want to have control over every pixel in every frame [10:59:36 CET] <kurosu> so, yeah, I don't think you can do that by just invoking ffmpeg binary, you'll have to do that programatically [11:01:10 CET] <kurosu> open input/encoded stream and output stream (setting encoder parameters and so on), decode some or all frames, get pixels and timestamps, do your overlaying, send frames to encoder then to the output stream [11:01:33 CET] <kurosu> you probably have to decode all of the frames, though, modifying one requires encoding most of the following ones [11:01:39 CET] <kurosu> (usually) [11:01:54 CET] <kurosu> *re-encoding [11:03:00 CET] <TheWild> let's see a thing in hex editor first [11:03:00 CET] <TheWild> ffmpeg -i output.mkv -f yuv4mpeg2 output.y4m [11:03:00 CET] <TheWild> ffmpeg -i output.mkv -vcodec yuv4mpeg2 output.y4m [11:03:08 CET] <TheWild> meh, I'm doing something wrong [11:03:34 CET] <kurosu> or, furq approach, write to an output pipe the yuv4mpeg data, read it by your program, modify it, write the output to a pipe for input to another ffmpeg instance [11:03:50 CET] <furq> TheWild: -f yuv4mpegpipe [11:04:12 CET] <furq> you don't need it if the output ends in .y4m though [11:04:41 CET] <TheWild> that worked, thanks [11:04:46 CET] <TheWild> yikes! bitrate=1492993.5kbits/s [11:04:53 CET] <furq> yeah it's rawvideo [11:13:46 CET] <kurosu> that's what you want to pipe it also [11:18:55 CET] <TheWild> do we have compressed but lossless *RGB* format? [11:19:47 CET] <TheWild> hmm... libx264rgb [11:44:03 CET] <TheWild> yuv444p12 means 4:4:4 and 12-bit precision, right? [13:18:59 CET] <Mavrik> yp [14:22:04 CET] <wallbroken> hi [14:22:20 CET] <wallbroken> i want to record my cctv in loop over a limited amount of my hd [14:23:41 CET] <DHE> well the super simple answer is the muxer called "segment" [14:23:53 CET] <DHE> https://ffmpeg.org/ffmpeg-formats.html#segment [14:24:32 CET] <wallbroken> yes but i want to set an hard disk quota [14:24:49 CET] <wallbroken> for example for cctv i want to set 10 gb of my hd [14:25:24 CET] <wallbroken> if the recording fill the quota, it must overwrite [14:26:02 CET] <DHE> so there is a -segment_wrap parameter which might do that. I'd experiment first [14:26:50 CET] <DHE> alternatively you can try the "hls" muxer, which is a specific format but also largely similar in terms of splitting, and it has an explicit option to delete old files. just keep in mind that it keeps 2x the number of files you ask for the list size [14:27:19 CET] <wallbroken> DHE is present on enigma2? [14:27:33 CET] <DHE> wat? [14:27:44 CET] <wallbroken> enigma2 is an OS for video [14:27:58 CET] <DHE> I have no idea [14:29:28 CET] <wallbroken> and what if i restart the command? [14:29:36 CET] <wallbroken> it overwrite the entire file? [14:31:42 CET] <DHE> it makes multiple files, and will restart from #1 (or zero?) at startup. while running hls will grow indefinitely but delete old files. segment will restart back at #1 when it hits your wrap target [14:35:45 CET] <wallbroken> so if i reboot the machine, and when i reboot, it reached #4 [14:35:58 CET] <wallbroken> ffmpeg at next reboot will continue from 4? [14:36:03 CET] <wallbroken> or will overwrite from 1? [14:36:23 CET] <wallbroken> if the second, it's a proble [14:36:24 CET] <wallbroken> m [14:36:49 CET] <wallbroken> so if i reboot the machine, and when i reboot, it reached #4 [14:36:57 CET] <wallbroken> ffmpeg at next reboot will continue from 4? [14:37:02 CET] <wallbroken> or will overwrite from 1? [14:38:52 CET] <wallbroken> so if i reboot the machine, and when i reboot, it reached #4 [14:38:57 CET] <wallbroken> sorry for repeating [14:39:36 CET] <DHE> ffmpeg itself doesn't check these things. it'll be on you to check how far it got and request it start at #5 in this case (don't want to overwrite an incomplete #4) [14:43:36 CET] <wallbroken> in my case i want to continue writing the next file [14:43:43 CET] <wallbroken> for example if i reboot on #4 [14:43:52 CET] <wallbroken> ffmpeg should write on #5 [16:26:35 CET] <eject_ck> Hi guys, I'm trying to watch IPTV using my linux PC instead of dummy tvbox, I sniffed UDP address of steam which iptvbox uses to access it. when I connected to the same "network hub" aka bridge I was able to watch that stream from linux pc, when I changed mac address, IP address on my linux pc to match IPTV box settings (I had suspicious that provider filters by ip/mac) I see that stream is not coming. [16:27:10 CET] <eject_ck> I also found that IGMP packets my box sends are different from packets which ffmpeg sends [16:27:55 CET] <eject_ck> ffmpeg -i udp://225.0.0.11:5000 [16:28:50 CET] <DHE> IGMP version mismatch? [16:28:57 CET] <eject_ck> i see that my box was sending IGMPv2 to 224.0.0.1 [IGMP Version: 2] Type: Membership Query (0x11) [16:29:52 CET] <eject_ck> When I used ffmpeg it sends to 224.0.0.22: igmp v3 report, 1 group record(s) [16:30:48 CET] <eject_ck> so I see it's using v2 on box and v3 on linux machine, also different addresses [16:31:02 CET] <eject_ck> I tried to force linux pc to use igmpv3 [16:31:15 CET] <eject_ck> echo 2 > /proc/sys/net/ipv4/conf/ens224/force_igmp_version [16:32:19 CET] <eject_ck> sorry, v2 I meant, it uses v2, but still sending membership to not 224.0.0.1 [16:32:23 CET] <eject_ck> 225.0.11.63: igmp v2 report 225.0.11.63 [16:32:58 CET] <eject_ck> Is this ok, or can I change that using ffmpeg options or linux settings ? [16:33:28 CET] <eject_ck> thank you all in advice [16:33:30 CET] <eject_ck> in dvance [16:33:34 CET] <eject_ck> in advance [16:39:21 CET] <eject_ck> https://www.thegeekdiary.com/how-to-configure-multicast-on-an-ip-address-in… [17:11:41 CET] <tombb> hi all, would like to pick your brain for a bit.. I got an xdcam file that was created by rhozet carbon coder. for some reason it will automatically create it as an mxf with 1 stream and 4 audio channels, (I'm aware of MONO/STEREO/SURROUND, never seen 4 channels in a single stream) [17:11:41 CET] <aristaware> Hi [17:12:23 CET] <tombb> considering tomorrow carbon might product a file with 3 channel in the same track, what would be the right way to split all channels to mono streams, regardless of the amount of channels in a single stream? [17:14:28 CET] <aristaware> I'm trying to join several little clips from my webcam (Yi home). Each clip last 1 minute. The problem here is that the camera has motion detection and stops recording till it detects new movement. So I have several <=1' clips and for some minutes there's no video. What I would want is to join them all, but fill the gaps with the last frame of the video preceding the gap. [18:51:15 CET] <seanrdev> Hello hope everyone is ok today. I have a question about the ability to pull multiple rtsp streams and does the quality start to degrade if there are too many attempted streams pulled at once. [18:53:11 CET] <seanrdev> I noticed 5 streams are ok however when attempting to pull 30 streams they come in very bad. Sometimes completely green. I've tested to verify if this was in fact the camera by requesting the stream from another system and the stream is perfect. Is there perhaps any documentation on the limitations of ffmpeg and input streams? [18:59:13 CET] <friendofafriend> seanrdev: Are you sure that isn't a limitation of your NIC, or something else? [19:02:34 CET] <seanrdev> The calculations suggest 300Mbps and everything is connected on 1Gbps. NIC, Switch and router. [19:04:44 CET] <seanrdev> friendofafriend: Oh you know what.... I do have a 10/100 switch with a good amount of cameras connected I apologize. I'll switch that out and try again. [19:10:23 CET] <friendofafriend> Very glad to hear, seanrdev. I've had the same problems with lots of video streams. Good luck. [20:52:20 CET] <kevinnn> for recording the desktop does anyone know if there is a performance difference between gdigrab and dshow? [20:56:19 CET] <kepstin> gdigrab can be pretty slow depending on graphics drivers, etc. [20:56:44 CET] <kepstin> dshow capture depends entirely on what software you have installed that implements the dshow device (this isn't provided by ffmpeg) [20:58:18 CET] <kevinnn> kepstin: oh... what backends are available for dshow? [20:59:38 CET] <kepstin> windows doesn't include any directshow screen grab stuff, so none unless you install one [20:59:53 CET] <kepstin> (dshow on a stock windows install will only do cameras) [21:01:04 CET] <kevinnn> kepstin: after doing much research i came across this: [21:01:07 CET] <kevinnn> https://github.com/rdp/screen-capture-recorder-to-video-windows-free [21:01:16 CET] <kevinnn> This is a backend for dshow right? [21:01:25 CET] <kevinnn> would this be faster than gdigrab? [21:01:53 CET] <kevinnn> just to let you in on my use case I want to create a basic screen recording program [21:02:17 CET] <kevinnn> needs to record a minimum of 30fps [21:02:22 CET] <kepstin> kevinnn: use obs [21:02:36 CET] <kevinnn> I took the source code for gdigrab.c and implemented it [21:02:43 CET] <kevinnn> and it was way slower than 30 fps [21:02:46 CET] <kevinnn> obs... [21:02:59 CET] <kevinnn> never considered that, is the source code readable? [21:03:16 CET] <kevinnn> ffmpeg's gdigrab.c was actually fairly easy to read [21:03:25 CET] <kepstin> rather than write your own screen capture app, OBS is an existing app that implements high performance screen capture for fullscreen (capable of gaming, etc.) [21:03:56 CET] <kevinnn> kepstin: for my particular use case it must be written by hand [21:03:58 CET] Action: kepstin wrote a substantial amount of the code for gdigrab, so he's happy to hear that it's readable, tho :) [21:04:26 CET] <JEEB> if you are interested in the low-level stuff, the virtualdub.org blog entry from 2011 about DXGI 1.2 is I think a nice guide into screen capture on windows https://web.archive.org/web/20170615115053/http://www.virtualdub.org/blog/p… [21:05:39 CET] <kevinnn> JEEB: thank you for that article, I will read through it [21:06:03 CET] <kevinnn> kepstin: for obs, have you worked with it at all? any pointers as to where in the source I should start? [21:07:13 CET] <kevinnn> JEEB: hey I [21:07:25 CET] <kevinnn> i've actually come across desktop duplication [21:07:35 CET] <kevinnn> which is what the article is talking about [21:07:44 CET] <kevinnn> but for some reason it doesn't work on my machine [21:07:47 CET] <kepstin> I'm not familiar with the OBS source, so I can't really help you there. I think that in fullscreen mode it does use the desktop duplication apis. [21:08:13 CET] <kevinnn> JEEB: my /usr/include/w32api/dxgi1_2.h file doesn't include any references to IDXGIOutputDuplication [21:08:39 CET] <kevinnn> I have no idea how that is possible and how to update as the duplication api should be available on windows 8+ [21:08:48 CET] <kevinnn> and I am on windows 10 with cygwin [21:08:55 CET] <kevinnn> JEEB: any pointers? [21:09:15 CET] <kevinnn> kepstin: that's what I figured too! [21:09:17 CET] <kepstin> might just be out of date headers :/ [21:09:22 CET] <kevinnn> refer to my comments to JEEB [21:09:25 CET] <kevinnn> hmm [21:09:35 CET] <kevinnn> how is that possible? And how can I fix this [21:11:40 CET] <kepstin> some options I can think of are to compile with an MS dev environment (visual studio) or to try using a newer mingw64 or msys2 release rather than cygwin [21:11:59 CET] <JEEB> kevinnn: newer mingw-w64 [21:12:08 CET] <JEEB> you can build just the CRT and headers [21:12:29 CET] <JEEB> of course if you're already on mingw-w64 version 6.x [21:14:45 CET] <kevinnn> JEEB: any package in specific from mingw? [21:15:05 CET] <friendofafriend> I'm trying to encode USB webcam video with h264_omx on a Raspberry Pi and stream to icecast in an MPEG-TS container. It's working intermittantly. Does anyone have a working command line for h264_omx encoding they could share? [21:15:07 CET] <JEEB> well headers and CRT is what you need [21:15:17 CET] <kevinnn> cygwin shows a million options for mingw64-x86_64* [21:15:53 CET] <JEEB> well check the version of the actual headers and crt, the package names I think should contain those words :P [21:15:53 CET] <kevinnn> I'm not seeing crt as an option [21:16:01 CET] <JEEB> since that's the parts of the project :P [21:16:28 CET] <JEEB> anyways, if your cygwin mingw-w64 cross-toolchain doesn't have them then I don't think you'll find it in that package manager :P [21:16:41 CET] <kevinnn> a search for crt in cygwin doesn't show any results! [21:17:03 CET] <JEEB> mingw-w64-crt and mingw-w64-headers are the directories within mingw-w64 :P [21:17:21 CET] <JEEB> kevinnn: if you already have mingw-w64 installed from cygwin then if the stuff's not there it's not new enough :P [21:17:51 CET] <kepstin> the mingw-w64 downloads page says cygwin includes mingw-w64 v5.0.2, fwiw, but i don't know if that's up to date. [21:18:25 CET] <JEEB> 6.0.x is current release [21:18:39 CET] <JEEB> at least when I last checked [21:19:47 CET] <kevinnn> god why can't programming in windows be as easy as it is in linux... [21:20:02 CET] <kepstin> it's all reverse-engineered/reimplemented tho, so I wouldn't be surprised if some apis are still missing in 6.0.0 [21:20:35 CET] <kevinnn> kepstin: if that's the case maybe I should just use visualc++? [21:20:50 CET] <kepstin> kevinnn: I wouldn't be surprised if windows devs who initially started with the vs IDE would say the same thing about linux :) [21:20:52 CET] <JEEB> a lot of the APIs are just windows DLL end points tho, so you just need the header entries (some of which are even on MSDN), and then exporting the library end points [21:20:58 CET] <kevinnn> that would have the original version of desktop duplication [21:21:30 CET] Action: kepstin did most of the dev + testing of the gdigrab.c in Wine, fwiw [21:21:46 CET] <kepstin> i was really surprised when i tried it on intel drivers in win7 and it was *way* slower than in wine [21:22:20 CET] <kevinnn> is there anyway I can find out what version of mingw I need to have the desktop duplication API? [21:22:34 CET] <JEEB> also mingw-w64 6.x seems to have IDXGIOutputDuplication [21:22:43 CET] <kevinnn> do you think OBS uses the reverese engineered desktop duplication that mingw uses? [21:22:44 CET] <JEEB> I just grepped my installed headers [21:22:58 CET] <kevinnn> like will it be as efficient? [21:23:11 CET] <kevinnn> okay I am just going to download mingw manually [21:23:25 CET] <JEEB> the implementation is the same, reverse engineering is a heavy word when you just need to get the header definitions and the library end points :P [21:23:28 CET] <JEEB> exports that is [21:23:41 CET] <JEEB> and the header stuff is often find'able in MSDN :P [21:23:46 CET] <JEEB> like, on the documentation page [21:24:04 CET] <kevinnn> right, okay, let me install mingw and see if I can get this all working [21:24:10 CET] <kevinnn> thanks for the help JEEB [21:24:17 CET] <kepstin> looks like the OBS build instructions for windows say to use visual studio, so they're not using mingw-w64 fwiw. [21:25:06 CET] <JEEB> the build process for mingw-w64 headers & CRT isn't too hard [21:25:07 CET] <kevinnn> kepstin: hmm, do you think the people over at mingw did a good job? [21:25:25 CET] <JEEB> just do the headers first, and then CRT [21:25:33 CET] <kevinnn> okay I will [21:25:47 CET] <JEEB> (and configure --host to your cross-compiler + --prefix to your mingw-w64 prefix [21:26:01 CET] <JEEB> you probably want to --enable-sdk=all --enable-secure-api for headers, too [21:26:24 CET] <JEEB> latter enables the """secure""" APIs that windows has [21:26:39 CET] <kepstin> kevinnn: in general? yeah. it's possible to build a pretty wide variety of windows apps using mingw-w64, even cross-compiling from linux. [21:26:58 CET] <kepstin> without needing to worry about licensing of header files or copying them from a real windows box or we [22:31:46 CET] <GuiToris> hey I got this message: Filtergraph 'transpose=1' was specified through the -vf/-af/-filter option for output stream 0:0, which is fed from a complex filtergraph -vf/-af/-filter and -filter_complex cannot be used together for the same stream [22:31:54 CET] <GuiToris> do I have to create intermediate files? [22:33:03 CET] <Mavrik> No. [22:33:20 CET] <Mavrik> You should just stop mixing filter_complex and vf parameters. [22:33:23 CET] <Mavrik> As the message says. [22:34:52 CET] <GuiToris> Mavrik, it's really difficult to change anything since I have no idea what's going on in the filter_complex, I just copied from the Internet [22:35:08 CET] <Mavrik> Not sure what do you want me to say. [22:35:19 CET] <GuiToris> -vf "transpose=1" -lavfi '[0:v]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][0:v]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16' [22:35:23 CET] <Mavrik> Read documentation to understand what you're running on your computer? :P [22:35:30 CET] <GuiToris> that's what I've tried [22:35:45 CET] <Mavrik> What are you trying to transpose exactly? [22:36:20 CET] <Mavrik> In other words - what are you actually trying to do? :P [22:36:29 CET] <GuiToris> I have a vertical footage video and I'd like to stretch a blurred copy in the background [22:36:37 CET] <Mavrik> ok [22:36:44 CET] <GuiToris> the filter complex does a good job [22:36:51 CET] <GuiToris> except I also need to rotate the video [22:37:04 CET] <GuiToris> that's the problem [22:37:23 CET] <Mavrik> Do you need to rotate both the blurred version and the normal version? [22:37:51 CET] <GuiToris> the blurred background will be created by the original one, won't it? [22:38:05 CET] <GuiToris> if I rotate the main video, i'll be rotated as well [22:38:08 CET] <GuiToris> right? [22:38:30 CET] <Mavrik> well, depends on where the transposition is done [22:38:48 CET] <GuiToris> in the first place [22:38:56 CET] <Mavrik> That's why I'm asking - you can rotate the video at the start (thus rotating everything) or just part of it. [22:39:25 CET] <Mavrik> So what your complex filter is doing is it's taking the first video input (called [0:v]), doing the whole blur thing and then outputing that as output named [bs] [22:39:29 CET] <Mavrik> *[bg] [22:39:42 CET] <Mavrik> It then takes [bg] and [0:v] and combines them together [22:40:44 CET] <GuiToris> then I think I should rotate it first [22:40:48 CET] <Mavrik> -lavfi '[0:v]transpose=1[transposed];[transposed]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][transposed]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16' [22:41:02 CET] <Mavrik> Something like that [22:42:07 CET] <GuiToris> matches no streams [22:42:14 CET] <GuiToris> did I mess up something [22:42:15 CET] <GuiToris> ? [22:42:37 CET] <Mavrik> Hard to tell ;) [22:42:43 CET] <GuiToris> Stream specifier 'transposed' [22:42:51 CET] <GuiToris> I forgot to copy the beginning [22:44:31 CET] <GuiToris> Stream specifier 'transposed' in filtergraph description [0:v]transpose=1[transposed];[transposed]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][transposed]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16 matches no streams [22:45:24 CET] <Mavrik> Can you pastebin everything you've typed and your full output? [22:46:45 CET] <GuiToris> there isn't much that you haven't seen: ffmpeg -i input -lavfi '[0:v]transpose=1[transposed];[transposed]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][transposed]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16' -frames 1 output.png [22:51:14 CET] <GuiToris> does you script work for you? [22:58:41 CET] <furq> GuiToris: [0:v]split,transpose=1[s0][s1];[s0]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][s1]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16 [22:58:55 CET] <furq> sorry, transpose=1,split [23:00:51 CET] <GuiToris> furq, thanks a lot, it's working now [00:00:00 CET] --- Fri Jan 18 2019

1 0

ffmpeg-devel.log.20190116
by burek 17 Jan '19

17 Jan '19

[00:09:55 CET] <cone-418> ffmpeg 03Carl Eugen Hoyos 07master:06f65a17a38a: lavf/rtpproto: Use the correct patch when including poll.h [00:14:29 CET] <cone-418> ffmpeg 03Carl Eugen Hoyos 07master:70c68e654d14: lavd/iec61883: Fix the include path for poll.h. [00:50:43 CET] <nevcairiel> anyone know what audio files starting with "MEM0" are supposed to be? [00:55:08 CET] <jamrial> nevcairiel: not really. did you check wiki.multimedia.cx? [00:55:44 CET] <nevcairiel> I think these files are just random data garbage at this point [00:56:38 CET] <jamrial> did a user submit one? [00:57:14 CET] <nevcairiel> yeah all files i got from a user [00:57:20 CET] <nevcairiel> but my guess is they got corrutped somehow [01:12:11 CET] <jamrial> JEEB: does https://pastebin.com/3gECMfyV fix it? [01:25:52 CET] <Compn> nevcairiel : sounds like voice memo , probably from a personal pen recorder or somethin [01:26:03 CET] <Compn> i dont have any formats, just a guess [01:26:54 CET] <Compn> some horrible 8kz mono codec no doubt [01:31:22 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:19dc5cdaa7c4: avcodec/lzw: Check for end of input [01:31:23 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:6dde65d7c0ac: avcodec/ac3dec: Optimize frame start search [01:31:24 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:6ed3d0e01c20: avcodec/diracdec: Propagate errors from dirac_get_arith_uint() [01:31:25 CET] <cone-418> ffmpeg 03Michael Niedermayer 07master:51978aefe807: avcodec/dirac_arith: Treat overread as error [02:25:38 CET] <Compn> mov wrapped wmv3 reminds me so much of avi wrapped ogm/ogg [02:25:52 CET] <Compn> e.g. unplayable everyone ignores it [10:29:36 CET] <cone-033> ffmpeg 03Paul B Mahol 07master:282a4718576d: avformat/hcom: check probe buffer size [12:47:40 CET] <thardin> hrm, palettegen is behaving wrong [12:48:27 CET] <durandal_1707> thardin: how so? [12:48:33 CET] <thardin> the combination of palettegen and paletteuse makes encoding gif use too much pure black [12:48:39 CET] <thardin> when doing say 64 colors [12:48:48 CET] <thardin> because palettegen fills the image with black rather than the last color [12:49:38 CET] <thardin> so I get a whole bunch of black specks that shouldn't be there [12:50:38 CET] <durandal_1707> full uncut ffmpeg output missing [12:50:57 CET] <thardin> myeah this isn't that kind of bug :) [12:51:27 CET] <durandal_1707> can not reproduce, issue closed [12:51:46 CET] <thardin> I'll see if I can come up with a patch and submit it to the list with an accompanying ticket [12:54:31 CET] <thardin> hah, one-line change [12:54:33 CET] <JEEB> :) [12:54:50 CET] <thardin> - pal[x] = 0xff000000; // pad with black [12:54:50 CET] <thardin> + pal[x] = last_color; // pad with last color [12:55:03 CET] <JEEB> meanwhile, I have learned how "fun" it is when a library doesn't tell you if it successfully went through the data or if it failed [12:55:19 CET] <durandal_1707> thardin: can't be [12:55:25 CET] <JEEB> basically a library has a parse() function, which is void :D [12:55:59 CET] <JEEB> and then you can receive data from the parser, which can return nullptr - but it also returns nullptr when alles gut :) [12:56:13 CET] <JEEB> (as in, successfully parsed but nothing came out) [12:56:22 CET] <JEEB> *nothing to output [12:57:14 CET] <thardin> woop, it works [12:58:19 CET] <durandal_1707> how changing unused palette colors fix anything? [12:58:37 CET] <thardin> because the paletteuse + gif encoder combo doesn't seem to have a concept of number of colors used [12:58:57 CET] <thardin> to work properly the "I want 64 colors" intent needs to be passed along [12:59:05 CET] <durandal_1707> yes [12:59:25 CET] <thardin> the generated palette has 65 unique colors (despite what the stats say) [12:59:33 CET] <thardin> since it's filled with black [13:00:10 CET] <thardin> compare http://www.härdin.se/output-64-sierra4.gif and http://www.härdin.se/output-64-sierra2-patched.gif [20:59:55 CET] <BBB> let's have a fast_memcpy function also [21:00:01 CET] <BBB> then rename ourselves to mplayer [21:00:04 CET] <BBB> and live will be good :) [21:00:35 CET] <durandal_1707> this is memset_bytes function for shorts [21:01:03 CET] <durandal_1707> and any serious project have own memcpy under fancy name [21:01:38 CET] <nevcairiel> the only memcpy you need is for gpu mapped memory [21:01:41 CET] <nevcairiel> anything else is just silly [21:01:54 CET] <nevcairiel> (or you need a better libc) [22:02:51 CET] <atomnuker1> damn, no deal brexit is getting likelier [22:03:39 CET] <atomnuker1> 2 months to go but thankfully the pound hasn't tanked yet [00:00:00 CET] --- Thu Jan 17 2019

1 0

ffmpeg.log.20190116
by burek 17 Jan '19

17 Jan '19

[02:17:14 CET] <KombuchaKip> Is there a way to use the ffmpeg API to detect if an audio file is corrupted? I know there is no way to do this if the container doesn't contain a checksum, but for when there is I am assuming there is a way to do this? [02:24:54 CET] <DHE> I think you just have to decode the audio (assuming it's compressed) and look for errors in the decompressor [03:15:46 CET] <Hello71> if you want to try harder you can calculate the SNR [03:16:09 CET] <Hello71> I would assume there there is something for this somewhere in ffmpeg [04:55:00 CET] <inflex> Hello all. Is there a way to analyse a H264 (or other) file and make a log of activity per unit of time (ie, per second)? I'm after the opposite of what most DVR/security people want, I'm actually looking for points where there's no/low activity over a period of a few seconds or more [05:08:39 CET] <friendofafriend> inflex: When you say "a lot of activity per unit of time", what activity do you mean? [05:15:19 CET] <inflex> The difference between frames, though I supposed in terms of visuals, motion / change of scene [05:16:45 CET] <inflex> What happens is that I have a recording of my work, and there are times within a given job where I get up and go do other things, and the scene remains static, I'd like to find those low-activity periods so I can cut them out in the NLVE. [05:26:58 CET] <furq> if you just want to cut them out then look at the mpdecimate filter [05:27:09 CET] <furq> i don't know of any filter that exports that information though [05:39:25 CET] <inflex> np, appreciate the pointer, thanks [06:14:31 CET] <KombuchaKip> DHE & Hello71: Thank you. [12:24:26 CET] <zerodefect> Firstly, I'm using C-API interface to FFmpeg. Now Ubuntu 18.04 has FFmpeg 3.4.4 installed by default. Since it's an older version, I went away and pulled down and then built v4.1 of FFmpeg. Unfortunately, when I rewind back to 3.4.4, I cannot now find the H264 encoder when calling 'avcodec_find_encode(AV_CODEC_ID_H264)'. So I feel like I've butchered something :S. [12:25:06 CET] <zerodefect> If I run `ffmpeg -encoders | grep x264`, I get: [12:25:26 CET] <zerodefect> V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264) [12:26:10 CET] <JEEB> I generally recommend requesting encoders by their name. also I hope you have re-compiled and linked your thing against the older ubuntu version + that the ubuntu version installed is one with libx264 enabled. [12:26:32 CET] <JEEB> because requesting an encoder with the codec_id can give you literally any encoder doing that stuff :) [12:26:42 CET] <zerodefect> Tried to retrieve by name too but to no avail. [12:26:52 CET] <zerodefect> "libx264" ? [12:26:53 CET] <JEEB> (and verify that the ffmpeg.c you're poking is built against the same FFmpeg that you're linking against [12:27:01 CET] <JEEB> yes, libx264 or the rgb variant depending on things [12:28:03 CET] <zerodefect> So I've actually gone a step further than what you suggest and completely deleted the 4.1 source and builds so that I don't trip over myself. [12:29:32 CET] <JEEB> the source shouldn't matter as long as you no longer have the prefix around :) [12:30:00 CET] <JEEB> (always set --prefix when building and then use PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR to guide pkg-config to a specific thing) [12:53:30 CET] <zerodefect> I wonder if during my install of 4.1, I corrupted something. I don't think I did install with `sudo` [15:56:54 CET] <zerodefect> @JEEB, I got it to find encoder by name "libx264", but it won't find the encoder by id. I find that quite interesting and unexpected. [16:43:04 CET] <meiamsome> Hello, is there a limit to the amount of HTTP connections that can be made out of an FFMpeg process during its lifetime? [16:45:57 CET] <pzy> I'm gonna go with... 65536 [16:46:32 CET] <kepstin> like, there's nothing hardcoded in ffmpeg itself [16:52:48 CET] <meiamsome> We have a server nginx rtmp in docker that uses exec to run ffmpeg that takes the RTMP stream in and produces a HLS output to a URL of a Node server. It works but when we load test it (with 10 simultaneously) we discovered a pattern that the streams stop working after 6 minutes. It also seems to scale inversely with the number of streams, so maybe it's a limit on connections or something? [17:06:43 CET] <pzy> you should be able to see that in your tests, right? [19:51:28 CET] <tolszak> Hi, is it possible to decode single jpeg image using ffmpeg? E.g. to YUV? I google but I don't see any example [19:53:05 CET] <tolszak> Ok seems I found something: https://shrex999.wordpress.com/2013/08/01/ffmpeg-yuv-to-jpeg-and-jpeg-to-yu… [19:53:43 CET] <JEEB> the usual examples under doc/examples should also be around :P [19:53:59 CET] <JEEB> decoding JPEG is not any different from any other format in FFmpeg APIs [19:54:29 CET] <DHE> or do you mean the CLI? that's what the example contains [19:59:18 CET] <tolszak> JEEB: Yeah cli, I would like to test Intel HW decoder, and that's seems like a simplest solution [20:50:58 CET] <nadermx> Hi, I'm having a issue trying to figure out how to send a cookie with ffmpeg input, I posted the question on superuser, https://superuser.com/questions/1394742/send-cookie-with-ffmpeg-input [20:54:06 CET] <c_14> I believe you take the last 2 fields and separate them with an = [20:57:25 CET] <nadermx> I'm not understanding, so you are saying I would do something along the lines of "-cookies .youtube.com TRUE / FALSE 1547252593 GPS 1=.youtube.com TRUE / FALSE 1552434792 PREF f1=50000000&hl=en" but only the last 2 lines? [20:57:41 CET] <c_14> no [20:57:47 CET] <c_14> you can throw away everything except for the last 2 fields [20:58:23 CET] <c_14> so it'd be GPS=1; PREF=f1=50000000&hl=en etc [21:00:47 CET] <nadermx> Ok, even when the there isn't a consitancy and the last two lines have a 0? ".youtube.com TRUE / FALSE 0 YSC 9U9ILYfJDyA" There I would still only do last 2 fields? [21:01:05 CET] <nadermx> ie, YSC 9U9ILYfJDyA [21:01:41 CET] <c_14> yeah [21:02:26 CET] <c_14> first field is just the domain, you don't need that for ffmpeg (since it just hits that on everything), 2nd, 3rd and 4th I don't know, the 3rd is just a timestamp don't need that [21:02:32 CET] <c_14> and the rest is the interesting bits [21:03:10 CET] <nadermx> Thank you c_14, I will try this [22:04:43 CET] <velix> I'm trying this: "-f segment -segment_time 7200 -start_number 1" "blah %03d.mp3", but %03d still starts at 0000 [22:05:05 CET] <velix> Can I also reply the last seconds after segmentising? [22:05:37 CET] <c_14> start_number only works on input afaik [22:06:17 CET] <velix> ppph segment_start_number ! [22:06:21 CET] <velix> oooh* [22:07:00 CET] <velix> c_14: Thanks, works! [22:08:23 CET] <velix> Perhaps segment_time_delta does rewinding? [22:08:28 CET] <velix> let's try [22:09:01 CET] <velix> ffmpeg is sooo grown up. [22:10:13 CET] <velix> nope, that was wrong [22:10:33 CET] <c_14> do you want an overlap between segments? [22:10:52 CET] <velix> c_14: yeah [22:11:06 CET] <c_14> don't think that's supported. not without really complex filtergraphs anyway [22:11:40 CET] <velix> c_14: Actually, I could do it manually then. [22:11:46 CET] <velix> segment_filename,segment_start_time,segment_end_time [22:13:49 CET] <velix> c_14: maybe this one? https://stackoverflow.com/a/41812275 [22:15:00 CET] <velix> Man... Google search for "overlap" returns "overlay" all the time. [22:16:33 CET] <c_14> that could work if you change the naming for the 2 instances to test_%d-1 and test_%d-2, that way it should sort correctly I think. You'd have to merge the m3u8s manually though [22:16:47 CET] <velix> nah... then I'll go for the csv. [22:16:52 CET] <velix> small bash script and done. [22:17:00 CET] <velix> or even Excel :D [22:22:19 CET] <velix> ah damn, it GENERATES a list. [22:24:58 CET] <velix> seems like I need to do it oldschool: -ss 00:03:00 -t 00:03:10 [22:26:28 CET] <velix> but sure, this doesn't seem to accept pure seconds :D [22:27:07 CET] <c_14> -ss ? it should accept seconds just fine [22:27:11 CET] <c_14> I do that all the time [22:27:49 CET] <velix> c_14: oh, didn't find it. thanks. let me try [22:28:07 CET] <Mortir> Hi [22:29:06 CET] <Mortir> Anybody knows about a detailed tutorial on how to embed subtitles to a webm video? [22:29:33 CET] <c_14> embed how, just convert to vtt? [22:31:05 CET] <Mortir> Permanently sticking them. [22:31:16 CET] <velix> c_14: It works. And that way, I also can do parallel processing in a queue. [22:31:39 CET] <c_14> Mortir: https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo ? [22:35:11 CET] <poutine> Mortir, do you mean embed them in the video stream, like in the x264 SEI NALU as embedded 608/708, or do you mean burn in? [22:35:47 CET] <poutine> I guess you did say webm, so you probably mean the latter [22:46:49 CET] <velix> c_14: Yeah, good old "xargs" and -ss / -tt is way better than -segmentize. [22:46:56 CET] <velix> c_14: I'm runing 8 parts in parallel [22:47:12 CET] <Mortir> In such a way that conversion to other formats keeps them intact. [22:47:13 CET] <velix> oldschool is always better [22:47:16 CET] <velix> OIAB [22:48:16 CET] <Mortir> c_14: I had found that link before but didn't try 'cause the example was with an avi. Thanks [23:03:59 CET] <velix> Wow. 16 Threads also works on my i7 :D [23:04:05 CET] <velix> More... Mooore. Moooore! [23:10:21 CET] <fling> ffplay -pixel_format h264 -vcodec h264 -video_size 1920x1080 -i /dev/video3 [23:10:22 CET] <fling> [swscaler @ 0x7fc43cc1b820] deprecated pixel format used, make sure you did set range correctly [23:10:32 CET] <fling> Which pixel format to use? ^ [23:12:09 CET] <velix> Can ffmpeg handle this crazy new 4K format from Sony Alpha cameras? [23:38:39 CET] <fling> velix: how many cores? [23:39:17 CET] <velix> fling: 16 (it's a virtual machine on a blade) [23:39:29 CET] <velix> It's equal to i7 cores [23:39:35 CET] <velix> about the same performance [23:53:05 CET] <zerodefect> For members of structs in the C-API like AVCodecContext::codec_id, must they too be set with av_opt_set_xxx too? [00:00:00 CET] --- Thu Jan 17 2019

1 0