Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2017

1 participants
62 discussions

ffmpeg-devel.log.20171020
by burek 21 Oct '17

21 Oct '17

[05:57:57 CEST] <rcombs> can someone add http://www.mpgedit.org/mpgedit/testdata/mpeg1/layer1/fl4.mp1 to fate samples [05:58:08 CEST] <rcombs> (we don't have an mp1 encoder) [05:59:36 CEST] <atomnuker> was that a dare? [06:00:42 CEST] <rcombs> &it was not intended as one [06:01:01 CEST] <rcombs> I'm not complaining; I can't think of a use for an MP1 encoder [06:01:18 CEST] <rcombs> I just need fate to have a test sample for the demuxer and muxer [06:03:12 CEST] <atomnuker> hey rcombs [06:03:44 CEST] <atomnuker> I WANT THE FLAC COVERART PATCH [06:04:31 CEST] <atomnuker> I've been waiting months for the bloody thing, I want to make a cyanrip release but I can't because it wouldn't be feature complete without this [20:21:25 CEST] <wbs> JEEB: jamrial: on the topic of hevc arm; there are some hevc idct optimizations further ahead in the merge log that you might want to merge before having others contribute more [20:21:50 CEST] <JEEB> k, I just happened to notice the post and gave some generic hints [20:22:43 CEST] <wbs> JEEB: jamrial: the stuff from libav unfortunately overlaps something that you already have, but I think I've benchmarked that the libav ones are equal or faster for all cases. some of the functions I have a feeling that I'd like to rewrite from scratch to see if I could get them better structured etc, but they should be pretty ok performance wise I think [20:23:36 CEST] <jamrial> wbs: there's a lot of overlap in hevc asm, including x86 [20:23:57 CEST] <wbs> ah, yeah, those as well. I don't deal that much with x86 asm :P [20:23:58 CEST] <jamrial> MC was written from scratch for libav instead of using the OpenHEVC patches, for example [20:25:34 CEST] <jamrial> I took the SAO work OpenHEVC left unfinished, extended and optimized it a bit before merging it into ffmpeg [20:25:58 CEST] <JEEB> -12 [20:26:05 CEST] <jamrial> tried to do the same for libav, but there was just too much previous stuff that hadn't been committed there [20:26:10 CEST] <BBB> at some point Im hoping all_this will get people excited about merging [20:26:20 CEST] <jamrial> like, hevc_filter.c looked like a different file :p [20:26:20 CEST] <BBB> but I guess NotYetEnoughPain [20:26:29 CEST] <BBB> -ENEEDMOREPAIN [22:07:13 CEST] <atomnuker> durandal_1707: are you up for writing a filter which expands a video to a given aspect ratio and fills in the border with a zoomed in blurred part of the video? [22:08:56 CEST] <J_Darnley> Like every news network nes it? [22:09:10 CEST] <durandal_1707> atomnuker: use already available filters [22:09:21 CEST] <durandal_1707> its doable [22:13:58 CEST] <Compn> with geq ? [22:14:05 CEST] <Compn> geqqqqqqqqq [22:14:27 CEST] <ubitux> scale, blur, overlay [22:16:28 CEST] <jamrial> michaelni: did you have time to look at the merge i mentioned wednesday? [22:17:57 CEST] <ubitux> atomnuker: ffplay -f lavfi -i "movie=$HOME/samples/GoneNutty.avi,split[a][b]; [a]scale=iw+50:ih+50,boxblur=lr=5[blur]; [blur][b] overlay=x=25:y=25 [out]" [22:18:11 CEST] <ubitux> you can probably use eval variables in overlay but you get the idea [22:20:08 CEST] <atomnuker> I was thinking of using zoompan [22:20:20 CEST] <atomnuker> but zoompan seems incorrectly designed [22:20:27 CEST] <atomnuker> why does it modify the duration and the fps as well? [22:20:33 CEST] <JEEB> huh? :D [22:22:06 CEST] <atomnuker> well it does [22:22:30 CEST] <atomnuker> and its broken too, output fps is definitely not 25 fps [22:22:39 CEST] <atomnuker> (the default) [22:22:54 CEST] <atomnuker> I think it should be removed [22:28:12 CEST] <michaelni> jamrial, yes, i didnt find a case it breaks, iam undecided if i like the change [22:28:45 CEST] <jamrial> anything wrong with it? usually, bytestream2 api is better than manually playing with pointers [22:30:12 CEST] <michaelni> if it was written as a change to bytestream2 on top of our code it would be fine. Its the replacement of code that has no known issues by a different implementation that makes me feel a bit undecided [22:32:43 CEST] <michaelni> thats no objection or anything like that [22:32:52 CEST] <jamrial> i basically had to rewrite portions of it since it didn't really apply cleanly. i made sure it's functionally the same than pre commit, like keeping checks libav didn't have (or at least that was the attempt) [22:33:13 CEST] <michaelni> ahh, then it sounds good, thanks [22:33:42 CEST] <jamrial> worst case scenario we can revert it. we're too far from branching a new release after all [22:34:33 CEST] <jamrial> and thanks again for testing [22:38:08 CEST] <durandal_1707> atomnuker: if you dont want zoompan to change fps set right param to 1 [22:40:39 CEST] <durandal_1707> atomnuker: zoompan is designed primarly to zoom and pan slideshows, not movies [22:42:33 CEST] <jamrial> michaelni: http://coverage.ffmpeg.org/libavcodec/h2645_parse.c.gcov.html if you happen to have samples that trigger the currently untested non-failure paths of the function to make fate tests then it would be great as well [23:23:07 CEST] <durandal_1707> Compn: geq is michaelni gpl pet, slow as hell [23:25:52 CEST] <Compn> its not slow for people with quantom computers [23:26:54 CEST] <durandal_1707> ah, so you have one? [23:43:26 CEST] <jamrial> durandal_1707: a lot of filters are slow as hell until you write some simd for them [23:47:46 CEST] <durandal_1707> jamrial: really?, you should not buy potato next time [23:53:51 CEST] <atomnuker> kierank: have you seen the new xps laptops? http://www.dell.com/en-uk/shop/laptop-and-2-in-1-pcs/xps-15/spd/xps-15-9560… [23:54:14 CEST] <JEEB> they upgraded them again? even the last time I checked recently they looked good [23:54:21 CEST] <atomnuker> none have a 4k screen now, none but the most expensive one have 16gb of ram, 2 of them have a cheaper cpu [23:54:26 CEST] <atomnuker> and they're more expensive [23:54:33 CEST] <JEEB> wat [23:54:33 CEST] <kierank> atomnuker: what does it do that the old ones doesn't [23:54:41 CEST] <kierank> I have the xps15 [23:54:44 CEST] <kierank> With 4k [23:54:49 CEST] <atomnuker> so a 9550? [23:55:03 CEST] <durandal_1707> kierank: my is 8k [23:55:04 CEST] <kierank> 9650 our [23:55:07 CEST] <kierank> Iirc [23:55:22 CEST] <kierank> durandal_1707: meh, you live on a different that's well known [23:55:25 CEST] <atomnuker> I guess they removed all 4k display options but incresed the price [23:55:45 CEST] <JEEB> at least the 13" screen res seems same [23:55:47 CEST] <JEEB> 3200x1800 [23:55:50 CEST] <kierank> 13 seems sane [23:56:17 CEST] <JEEB> I really kind of want the xps 13 :/ [23:56:30 CEST] <atomnuker> too small for general use [23:56:41 CEST] <JEEB> I've used 14 and 12 inchers and I've been OK [23:56:56 CEST] <JEEB> unless they got the keyboard extremely small [23:57:10 CEST] <JEEB> my coworker has one and it seemed alright [23:58:46 CEST] <JEEB> oh, right 13 still hasn't got the 8th gen I series upgrade [23:58:47 CEST] <JEEB> meh [23:59:40 CEST] <jkqxz> Nice, you can pay 450GBP for the extra 16GB of the memory to get the top model. Sounds like a good deal! [00:00:00 CEST] --- Sat Oct 21 2017

1 0

ffmpeg.log.20171020
by burek 21 Oct '17

21 Oct '17

[02:24:13 CEST] <chrisjunkie> @rcombs Chris A has mentioned you might be able to help me with a weird TS issue Im having? :-) [02:24:32 CEST] <rcombs> possibly; if not, this is the right channel [02:24:51 CEST] <chrisjunkie> Perfect thank you. Ill try and describe as clear as I can what Im trying to do [02:26:57 CEST] <chrisjunkie> I have a "live" HLS playlist, that has up to 360 segments in the playlist, all at 10 seconds each. What I'm trying to do is regenerate, from a certain starting point in the playlist, new, lower bitrate and framerate segments and clean the input up a bit. What I'm seeing is that the seek isn't accurate for the HLS TS segments, meaning my transcoded segments are out by anywhere from 10-15 seconds from where they should be [02:27:32 CEST] <chrisjunkie> Ive compiled ffmpeg from the 3.4 branch [02:28:03 CEST] <rcombs> generally you'll want to be on master for support here (though I don't think anything relevant has changed since 3.4) [02:28:40 CEST] <rcombs> you'll probably also want to post a sample [02:31:07 CEST] <chrisjunkie> Yeah sorry I did compile from master but it was literally just as the 3.4 branch was being sliced which is why I mentioned it [02:31:33 CEST] <chrisjunkie> https://pastebin.com/TjjHSwA5 [02:31:52 CEST] <chrisjunkie> I get this message when FFMPEG tries to seek: segments_original/stream.m3u8: could not seek to position 3811.628 [02:32:54 CEST] <chrisjunkie> And then the starting timestamp of the first segment of my output is 3823.666667 [02:33:11 CEST] <chrisjunkie> 12 and a bit seconds out [02:35:39 CEST] <chrisjunkie> I think that this ticket is relevant https://trac.ffmpeg.org/ticket/5093#comment:10 [02:39:38 CEST] <Johnjay_> test 1 2 3 test 1 2 3 [02:39:43 CEST] <Johnjay_> can you hear me can you hear me over roger over [02:41:03 CEST] <chrisjunkie> Yes [02:41:11 CEST] <Johnjay> YES thank you [02:41:53 CEST] <tdr> i can only read the text, turn your mic up [02:42:45 CEST] <Johnjay> haha [02:45:14 CEST] <tdr> more ... its still really faint [03:13:50 CEST] <chrisjunkie> Hmmm I might be getting somewhere - ffmpeg doesnt use `hls_read_seek` for sliding window playlists [04:11:46 CEST] <maxofs2d> Hello! I'm using relaxed 's static builds ( https://johnvansickle.com/ffmpeg/ ) on a Raspberry Pi 3, on Raspbian Jessie. [04:11:53 CEST] <maxofs2d> I'm doing RTMP transcoding of an input RTMP stream with it. The armel build works fine, but quite slowly. [04:12:00 CEST] <maxofs2d> I'm trying to use the armhf build since that's what enables hardware floating point, which, to my understanding, should dramatically speed up x264. [04:12:05 CEST] <maxofs2d> However, any attempt at doing anything with the armhf build throws up a bus error after it prints the input's stats. Here's a screenshot of the output. https://i.imgur.com/P3a8A51.png [04:12:24 CEST] <maxofs2d> I could barely find anything about "bus errors" besides one ticket in the ffmpeg tracker from 8 months ago, and I don't believe it's relevant. [04:14:03 CEST] <maxofs2d> The bus error happens even by just stripping down the output to merely audio (which is what you see in my screenshot) [04:15:16 CEST] <maxofs2d> I would appreciate any pointers (no pun intended) you may have if this rings a bell with any of you :P [04:42:26 CEST] <chrisjunkie> So it turns out that the HLS demuxer doesnt seek accurately if its a live playlist [04:42:45 CEST] <chrisjunkie> So Ive added a fix around that, so the output is visually the same [04:43:15 CEST] <chrisjunkie> BUT, what Im seeing is that the segment muxer times are out by 10seconds which is my segment length [07:51:49 CEST] <IOException> Hi all! Somebody here? [07:52:46 CEST] <IOException> How to stretch/scale showspectrum vertical? [08:29:36 CEST] <kepstin> IOException: the vertical scaling is based on the sample rate of the input audio [08:30:02 CEST] <kepstin> so resample to adjust it. [08:30:12 CEST] <IOException> kepstin I would like to multiply it by some variable to make output more "friendly" [08:30:31 CEST] <IOException> currently because of low freq 80% of height is "black" [08:32:04 CEST] <IOException> kepstin sample video > https://pasteboard.co/GPLsRx1.png [08:32:59 CEST] <kepstin> the high freq, you mean? what's the sample rate of the audio? [08:33:06 CEST] <IOException> I will appreciate workaround based on showcqt, but I don't know how to remove "spikes" axis from output [08:33:36 CEST] <IOException> kepstin it is low freq [10-2400 HZ] [08:34:18 CEST] <IOException> I would like to fill half of frame with "orange" dots. Currently there are "blue" space [08:35:25 CEST] <kepstin> IOException: the vertical scale of the showspectrum filter is from 0 (bottom) to 1/2 of sample rate (top). To change the scale, resample the audio before putting it into the filter. [08:36:05 CEST] <IOException> :) can ffmpeg resample audio? [08:36:41 CEST] <IOException> Just googled it. Seems it can [08:36:42 CEST] <kepstin> of course. https://ffmpeg.org/ffmpeg-filters.html#aresample-1 [08:39:44 CEST] <IOException> Original command: https://gist.github.com/shmutalov/fa28d06919a12517f5f90a4cff5f8ceb [09:13:36 CEST] <IOException> How to scale video without changing resolution? [09:14:31 CEST] <Nacht> That's an odd question. [09:14:58 CEST] <Nacht> Scaling implies making it larger or smaller, thus changing the resolution [09:15:15 CEST] <IOException> say, my video is 640x480, I want to scale all frames, but don't change original resolution [09:15:25 CEST] <IOException> with croping [09:15:38 CEST] <Nacht> So you want to crop it, but keep the original resolution [09:15:44 CEST] <IOException> yes [09:16:52 CEST] <Nacht> I recon with a filter, cropping first, then scaling it afterwards [09:17:36 CEST] <IOException> Nacht can you help me with filtering without scale? [09:18:35 CEST] <IOException> Nacht > https://pasteboard.co/GPLsRx1.png I would like to scale spectrum to remove empty space [09:18:53 CEST] <IOException> empty blue space [09:26:01 CEST] <Nacht> IOException: So it should be something like: -vf "crop=<your input>, scale=640:480,setdar=4:3" [09:27:02 CEST] <IOException> Nacht kepstin aresample did the trick. But spectrum decreased in length [09:27:36 CEST] <IOException> https://pasteboard.co/GPLPwEw.png [09:27:43 CEST] <Nacht> judging from your image, it should be -vf "crop=640:240:0:0, scale=640:480,setdar=4:3" [09:28:05 CEST] <Nacht> judging from your image, it should be -vf "crop=640:240:0:0, scale=320:480,setdar=4:3" [09:28:14 CEST] <Nacht> slight brainfart there [09:28:32 CEST] <Nacht> argh [09:28:37 CEST] <Nacht> Right, its way too early [09:28:51 CEST] <Nacht> -vf "crop=320:480:0:0, scale=640:480,setdar=4:3" [09:29:25 CEST] <Nacht> it will crop a 320x480 image from the top left corner, and stretch it to 640x480 with an aspact ratio of 4:3 [09:30:12 CEST] <IOException> Nacht croping will decrease quality [09:30:33 CEST] <IOException> so I am not using it [09:33:13 CEST] <Nacht> Scaling will decrease quality, not cropping [09:38:01 CEST] <blap> can you crop without reencoding? [09:39:39 CEST] <Nacht> Whenever you change the actual pixels, you need re-encoding [09:41:16 CEST] <IOException> Result video: https://drive.google.com/file/d/0B2AoR3-Umz1Pd0pVb3F4a05RclE/view?usp=shari… [09:42:08 CEST] <IOException> now I need to stretch the spectrum in length [09:43:51 CEST] <blap> THen cropping will decrease quality. [09:45:27 CEST] <IOException> blap I am not familar with ffmpeg... :'( All I want to map audio source to video spectrum, where spectrum will be fill the full frame at the end of video [09:45:49 CEST] <IOException> if I crop it then scale it again I will lose pixels [09:46:10 CEST] <blap> what with a fft? [09:46:16 CEST] <IOException> what is it? [09:46:22 CEST] <blap> fast fourier transform [09:46:32 CEST] <blap> or you want an oscilloscope display? [09:47:11 CEST] <IOException> I want an oscilloscope display [09:47:40 CEST] <IOException> I think I can do reverse algo (as Nacht and kepstin wrote) [09:48:00 CEST] <IOException> render video with big resolution and crop it [09:50:36 CEST] <blap> ah i didn't know you could do that [09:51:19 CEST] <IOException> my brain will explode :) [09:51:36 CEST] <IOException> it works, but it shows spectrum very small [10:19:57 CEST] <IOException> Nacht scaling after the crop doesn't work [10:20:33 CEST] <IOException> oh I forgot setsar [10:20:37 CEST] <IOException> *setdar [11:20:51 CEST] <luc4> Hello! I see that ffplay is using direct3d by default. Any idea how to disable it and use only the CPU? [11:44:40 CEST] <IOException> another problem. How to sync video duration with audio [12:30:34 CEST] <IOException> how to use -vsync parameter? Documentation is not clear [12:32:58 CEST] <jojva> Hi. When encoding an H264 stream, should the SPS be present before each PPS? [13:25:43 CEST] <IOException> kepstin Nacht blap there is result: https://www.youtube.com/watch?v=oaZWR61HVe0 [14:54:51 CEST] <charly> Hello, I'm using libavformat/libavcodec on a xeon E5-1660 v4 (8 cores, 16 threads) to decode hight quality HEVC/H264 TS streams with high bitrate (>100Mbps) in real-time. [14:55:09 CEST] <charly> It works well but I need to set the thread number at 100 to be real-time, with the warning "Application has requested 100 threads. Using a thread count greater than 16 is not recommended". The problem is that the latency is huge and memory concumption huge too with this number of threads. [14:55:19 CEST] <charly> How can I use a resonable amount of threads (16 ? 32 ?) to decrease the latancy/memory while being real-time ? [14:56:42 CEST] <BtbN> Using as many threads as the machine has threads is the default. [14:57:22 CEST] <BtbN> And going beyond that doesn't have benefits usually [14:57:26 CEST] <IOException> using 100 threads (while your processor gives you 16) is meaningless [14:57:43 CEST] <IOException> also each thread will consume memory + context change cost [14:57:57 CEST] <charly> yes but i have about 43fps when i use default threads config [14:58:41 CEST] <charly> ~ 52fps with 50 threads, and ~ 63fps with 100 threads [15:01:39 CEST] <charly> i know this is non logic and this is why i ask how to fix this [15:03:18 CEST] <BtbN> Depending on what you're encoding and with what settings, 8 cores just aren't enough for HEVC [15:06:16 CEST] <charly> i don't know how exactly it was encoded, but result is: hevc (Main 10) ([36][0][0][0] / 0x0024), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps [15:07:16 CEST] <charly> so it's an HEVC 10bits HLG stream at 105Mbps [15:09:20 CEST] <charly> 8 cores (16threads) seems to be enough because it works with 100 decoding threads [15:11:05 CEST] <BtbN> probably because it degrades in quality enough. [15:12:40 CEST] <charly> i didn't notice any quality reduction but maybe [15:37:22 CEST] <JEEB> charly: the HEVC decoder is not given much optimization love in SIMD which should be able to help you. mostly because nobody had a use case / requirement. if you have one you could think about sponsoring some HEVC SIMD work [15:37:32 CEST] <JEEB> (or doing it yourself of course if you like to get your hands dirty) [15:38:41 CEST] <DHE> sadly the CPU scheduler for threads doesn't aggressively migrate threads between CPUs. if you have a CPU idle and another CPU with 2 jobs trying to run on it, the idle CPU may remain idle for an extended period before the system really does anything about it [15:39:00 CEST] <DHE> bringing the number of threads way up helps hide this in the noise of running threads [15:40:57 CEST] <charly> JEEB, I understand that the decoder is not fully optimized and permomances can probably be better but my problem is that the number of threads must be huge to decode my stream, so the performances are sufficient for my application [15:42:00 CEST] <JEEB> yes, you're working around the thing not being fast enough by spawning enough buffer (and latency) [15:42:17 CEST] <charly> DHE, any tips to optimize the core distribution ? [15:42:31 CEST] <JEEB> numactl lets you control on which core(s) an app can go [15:42:38 CEST] <JEEB> but not sure how much that will help you [15:42:54 CEST] <JEEB> s/cores/NUMA nodes/ [15:43:00 CEST] <charly> I already use it, also with nice [15:43:41 CEST] <JEEB> yup [15:43:41 CEST] <charly> but if i understand well, the problem is inside the hevc decoder, not the application itself [15:44:13 CEST] <JEEB> yes, the HEVC decoder is just not fast enough. when you create umpteen frame threads you create enough buffer for any speed fluctuations to possibly be non-problematic [15:44:23 CEST] <DHE> an E5-1660 isn't going to be multicore, so no numa involved [15:44:26 CEST] <DHE> err, multisocket [15:44:36 CEST] <JEEB> because with frame threads each thread is decoding its own image [15:44:49 CEST] <JEEB> (and that's why you have obscene memory usage) [15:45:04 CEST] <DHE> quick question. are all memory channels populated? [15:45:27 CEST] <DHE> eg: if there are 3 off-coloured RAM slots, you have a memory stick in all 3 of them [15:46:33 CEST] <JEEB> not sure if that would help too much even if the memory bandwidth was working fully :P [15:46:37 CEST] <charly> i' using 4 channels slots with 8 available [15:47:16 CEST] <charly> 4*4GB at 2400MHz [15:47:17 CEST] <JEEB> basically what I see is that some frames take longer to decode than others, and unless you have a very large buffer it isn't averaging out fast enough [15:47:25 CEST] <DHE> JEEB: on a personal note, I once had a server built and the manufacturer was a fscking moron. only 1 stick in the quad-channel controller. [15:47:32 CEST] <JEEB> sure [15:47:47 CEST] <JEEB> this is just a case of "HEVC is slow, and yes you can work around by using frame threading as a buffer" [15:48:18 CEST] <DHE> put in a 2nd stick for testing, +30% performance boost [15:48:23 CEST] <JEEB> so yes, while from threading perspective 100 threads just ain't making sense [15:48:33 CEST] <JEEB> when you have a not-always-fast-enough decoder [15:48:44 CEST] <JEEB> the added latency buffer due to frame threading helps average things out [15:48:55 CEST] <JEEB> so that the larger intra frames which take longer etc don't drop the average [15:49:13 CEST] <JEEB> at least that's how I see this [15:50:12 CEST] <JEEB> so the two ways to work around this without a huge amount of threads is to have a separate buffer of images to be fed to the user, which of course also takes memory [15:50:25 CEST] <JEEB> or just optimizing the HEVC decoder [15:50:28 CEST] <DHE> wonder if you could use an external app like mbuffer or pv to buffer the source material... [15:51:57 CEST] <JEEB> charly: anyways congratulations on being the first person around here that cares about HEVC content that makes the lavc decoder derp :P [15:52:07 CEST] <charly> i already use the first work around, but the 16G of memory are a little bit just [15:52:24 CEST] <JEEB> charly: btw if you want to test out some patches that would require rewriting to get into upstream [15:52:31 CEST] <JEEB> but have been noted as helping people [15:52:50 CEST] <JEEB> http://git.1f0.de/gitweb?p=ffmpeg.git;a=shortlog;js=1 [15:52:59 CEST] <JEEB> the two OpenHEVC related ports [15:53:07 CEST] <JEEB> and the x86/hevc things after that [15:53:18 CEST] <JEEB> that might speed it up a bit [15:53:30 CEST] <JEEB> (they are intrinsics which upstream FFmpeg doesn't accept) [15:55:11 CEST] <charly> so http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=61b83379ef8c19117427cfe3ca… and http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=cbcae719f8d03273b9c3e481c5… ? [15:55:32 CEST] <JEEB> yes [15:55:49 CEST] <JEEB> and then there's two x86/hevc ones [15:56:04 CEST] <JEEB> the DECLARE_ALIGNED and correctly mark as SSE4 ones [15:56:33 CEST] <JEEB> you're not building with MSVC most likely so the last hevc SIMD related thing isn't required I think (which also disables one of the optimization paths) [15:57:01 CEST] <charly> ok [16:09:24 CEST] <Johnjay> are you guys talking about mingw again? [16:09:46 CEST] <JEEB> no [16:10:01 CEST] <Johnjay> damn I thought for sure when you said he wasn't building with MSVC [16:24:34 CEST] <Johnjay> ee [16:24:48 CEST] <Johnjay> *ffmpeg I managed to compile with mingw [16:24:58 CEST] <Johnjay> which i still find very cool [17:00:57 CEST] <chamath> Hi Guys, I have a problem with zooming in to a video. I need to zoom in to a video, but not as a zoom animation. Just keep the zoom level constant during the video play time. This is the ffmpeg command I'm trying. [17:01:00 CEST] <chamath> https://pastebin.com/6sUDSnCJ [17:01:36 CEST] <chamath> But it increases the output video duration to twise the input video duration. [17:02:07 CEST] <chamath> Any idea about that? Is there any other way that I can get this done? [17:02:13 CEST] <Johnjay> wow. that's a single command? [17:02:58 CEST] <chamath> yea [17:04:42 CEST] <c_14> try getting rid of the setpts? [17:05:20 CEST] <c_14> or if you thin it's the zoompan filter just crop,scale [17:51:28 CEST] <ricci> if i encode a file multiple times (from the same input), i get outputs' hash is different every time. why? [17:52:38 CEST] <BtbN> Because the metadata includes the date and other stuff that changes. [17:53:13 CEST] <ricci> how do i get creation time with ffprobe? [17:53:25 CEST] <BtbN> ffprobile myfile.something [17:53:30 CEST] <BtbN> -il [17:55:15 CEST] <furq> ricci: you can use the hash muxer if you just want to compare the hashes of the actual streams [17:55:22 CEST] <furq> !muxer hash @ricci [17:55:22 CEST] <nfobot> ricci: http://ffmpeg.org/ffmpeg-formats.html#hash-1 [17:56:18 CEST] <ricci> BtbN: ffprobe doesn't shows creation time, just duration and other metadata [17:59:06 CEST] <furq> ricci: -show_format [18:01:13 CEST] <ricci> creation time is not listed [18:01:54 CEST] <ricci> encoder is libopus, format is ogg [18:02:10 CEST] <DHE> there's also a bitexact option that strips out much of that metadata and produces something more consistent between runs or even versions of ffmpeg [18:05:46 CEST] <ricci> i don't know how to get creation time, but my main question is answered. i just wanted to know if audio streams are different. thanks to all [18:24:21 CEST] <lagzilla> is it possible to bring 2 audio steams in as mono on the fly like ffmpeg -i foo.mp3 -ac1 -i bar.mp3 -ac 1 -filter_complex "[0:a][1:a]amerge=inputs=2[aout]" -map "[aout]" output.mp3 [18:30:56 CEST] <JEEB> lagzilla: "on the fly"? [18:32:12 CEST] <lagzilla> yeah so the source audio stream is sterio id like to bring it into ffmpeg as mono [18:32:43 CEST] <JEEB> I still don't understand the "on the fly" part? how dynamic does the solution need to be? [18:33:26 CEST] <JEEB> or do you just need to separate the left/right of one input and similarly for the second input and get that somehow? [18:33:34 CEST] <JEEB> please explain what exactly it is that you want to do [18:35:15 CEST] <lagzilla> So I need to have audiofile1.mp3 play only on the right side, then audiofile2.mp3 play on the left side [18:37:15 CEST] <JEEB> yes [18:37:29 CEST] <JEEB> you can select left from the other and right from the other [18:37:37 CEST] <JEEB> it's all in https://www.ffmpeg.org/ffmpeg-all.html [23:37:26 CEST] <AlRaquish> I asked something similar yesterday, is it possible to make iterative/recursive filters? I am trying to delay certain pixels by some frames depending on their position. Is it possible to achieve that without using too much bash? My script is working, but I assume it would be faster if it was pure ffmpeg. [23:41:04 CEST] <durandal_1707> AlRaquish: hmm, how you do it? [23:41:32 CEST] <AlRaquish> https://pastebin.com/MSGNcw63 here is the script, which is rather ugly [23:41:46 CEST] <AlRaquish> I specifically want to delay columns/ rows so it's not too hard [23:42:01 CEST] <AlRaquish> I split it into n videos cropped and delayed, and then stack them back [23:43:11 CEST] <AlRaquish> I know that I don't have to split first and then merge. I could split one column, delay it, and then stack it to the output video. My way is faster though because it's generally dealing with small and similar-sized videos. [23:46:28 CEST] <AlRaquish> durandal_1707: I am wondering if I can construct some kind of complex filter that would do the same job, or that I could run repeatedly on the video to get more subdivisions. Maybe I could construct a huge filter pipeline as a string in bash and then give it to ffmpeg? [23:50:25 CEST] <durandal_1707> if movie filter supported seeking you could do that [23:50:56 CEST] <durandal_1707> but otherwise its not currently possible [23:51:51 CEST] <AlRaquish> Hmm yeah, I wonder if an advanced filter scripting language could be made for ffmpeg [23:52:23 CEST] <AlRaquish> Is there generally need for such a thing? [23:54:03 CEST] <durandal_1707> it is.... [23:55:17 CEST] <AlRaquish> Yeah, it is already very functional, but maybe being able to do everything from inside ffmpeg would make it possible for scripts to be cross-platform [23:55:57 CEST] <durandal_1707> they are already [23:56:14 CEST] <durandal_1707> so not shure what you mean [23:56:27 CEST] <AlRaquish> Well, in my case I had to use bash to get the final result [23:57:06 CEST] <AlRaquish> If there was some way to implement loops/recursion in ffmpeg filters, I don't think there would be any need for outside scripting [00:00:00 CEST] --- Sat Oct 21 2017

1 0

ffmpeg-devel.log.20171019
by burek 20 Oct '17

20 Oct '17

[00:25:07 CEST] <Zeranoe> Any particular reason this hasn't been committed? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217977.html [00:26:39 CEST] <jamrial> Zeranoe: nobody noticed it in the ml, i guess [00:26:41 CEST] <jamrial> i'll push it [00:28:29 CEST] <Zeranoe> Oh wow, ffmpeg.org is participating in battleforthenet [00:29:12 CEST] <Zeranoe> jamrial: Appreciate it [00:33:46 CEST] <jamrial> Zeranoe: done [00:34:00 CEST] <jamrial> looks kinda ugly, though [00:35:38 CEST] <Zeranoe> I figured the strong placement was for what made it unique from the others? [00:35:59 CEST] <Zeranoe> but yeah, I don't know why we're using any strong elements [10:15:22 CEST] <JEEB> rcombs: hmm, how was mpeg-1 audio defined in ISOBMFF? [10:15:34 CEST] <JEEB> I remember having some herps and derps about that [10:15:41 CEST] <rcombs> dunno, I've never seen that [10:15:46 CEST] <JEEB> ok [10:15:53 CEST] <rcombs> just mp2 [10:16:00 CEST] <JEEB> oh right, the file is called "mp3 parsed as mp1" lol [10:16:03 CEST] <JEEB> so it was the other way [10:16:11 CEST] <JEEB> lavf flagged it as mp1 audio [10:16:22 CEST] <JEEB> and then lavc would of course eat it [10:16:33 CEST] <JEEB> but if you were in DShow you could get the MS MPEG-1 audio decoder [10:16:36 CEST] <JEEB> which would just derp [10:17:16 CEST] <JEEB> seems to have been http://www.cccp-project.net/beta/test_files/mp3_parsed_as_mp1.mp4 [10:20:05 CEST] <JEEB> LGTM'd the movdec related stuff [10:21:10 CEST] <rcombs> michaelni had an issue with a file from trac, I think, but I wasn't able to reproduce [10:21:21 CEST] <rcombs> not sure if that means I fixed it since I last sent this series, or if it's something else [10:27:23 CEST] <rcombs> JEEB: meanwhile, lol @ shitty platform decoders forcing differentiation between MPEG audio layers [10:27:34 CEST] <JEEB> yes [10:27:57 CEST] <rcombs> I can't think of a reason for this [10:28:17 CEST] <JEEB> well the fourccs are different and the built-in mpeg-1 audio decoder is the ancient one [10:28:24 CEST] <JEEB> while the one for mp3 is a newer one [10:28:28 CEST] <JEEB> (Ž4@) [10:28:40 CEST] <JEEB> or actually not sure, might be the same one but the FourCC controls it or something [10:28:51 CEST] <JEEB> at this point I'm not even sure [10:29:04 CEST] Action: JEEB kind of has moved away from DShow being his daily driver [10:29:10 CEST] <rcombs> smart man [10:29:43 CEST] <JEEB> as soon as the opengl stuff in mpv worked well enough under windows I jumped over with no regrets [10:29:51 CEST] <JEEB> since I didn't need the mpc-hc ui [10:30:13 CEST] <JEEB> (since the WASAPI audio renderer got done first I remember and thus that wasn't a problem) [10:32:36 CEST] <ubitux> JEEB: i often use concat demuxer, and actually i have it in production [10:32:43 CEST] <ubitux> it's useful when you're splitting encode typically [10:32:49 CEST] <ubitux> (and then chunk remux everything at the end) [10:33:04 CEST] <ubitux> it's not a "random stupid usecase" [10:33:28 CEST] <JEEB> I'm pretty sure I didn't use the word "stupid" [10:33:36 CEST] <ubitux> sure, i did ;) [10:33:45 CEST] <JEEB> and yes, I noted it will work for specific use cases [10:33:52 CEST] <ubitux> also, when you have a stack with a relatively high risk of failure [10:33:59 CEST] <ubitux> you actually want to do multiple encodes [10:34:05 CEST] <ubitux> even if it's not in parallel [10:34:16 CEST] <ubitux> then you can start again the encode later etc [10:34:22 CEST] <JEEB> the problems happen when people try to use it outside those working use cases [10:34:23 CEST] <ubitux> the final step being a concat demux/remux [10:34:45 CEST] <ubitux> well, the concat demuxer has constraints on the input [10:34:57 CEST] <ubitux> it errors if not met, i don't think that's a bad thing [10:35:03 CEST] <JEEB> definitely not [10:35:20 CEST] <ubitux> really, the concat demuxer helps a lot of people [10:35:24 CEST] <JEEB> it does [10:36:14 CEST] <ubitux> and i don't think it's more a hack than hls & friends [10:36:23 CEST] <ubitux> it's exactly the same principle behind [10:36:39 CEST] <ubitux> anyway, i should probably tell that to wm4 [10:36:52 CEST] <ubitux> but i think he's salty enough currently [10:37:08 CEST] <JEEB> for example just now someone was complaining about a/v desynch with it on #ffmpeg and I can't really help with that :P [10:37:23 CEST] <JEEB> it could have been the guy's splitting or concat [10:37:27 CEST] <JEEB> or both augmented [10:37:32 CEST] <JEEB> E_NO_IDEA [10:37:56 CEST] <ubitux> :) [11:56:16 CEST] <memeka> hi ... where can i find the code that copies a buffer *after decoding* to the output device? [11:57:19 CEST] <memeka> is it av_memcpy_backptr ? [11:59:59 CEST] <nevcairiel> without context, we can't answer that. [12:04:49 CEST] <memeka> nevcairiel: i am trying to find out the bottleneck on my system when running ffmpeg (i don't have perf enabled) [12:05:23 CEST] <memeka> hw decoding is fast - if i do -f null - => I get >100fps on 1080p video [12:05:45 CEST] <memeka> but playing video is slow (even with opengl) => there is no zero-copy, there is a slow memcpy [12:06:15 CEST] <nevcairiel> ffmpeg by itself is not a very optimized player [12:06:15 CEST] <memeka> i have a faster memcpy implementation, and i would like to replace the default memcpy from ffmpeg with that implementation :) [12:06:40 CEST] <memeka> nevcairiel: i'm using mpv; even ffmpeg with fbdev output has the same results :) [12:06:42 CEST] <nevcairiel> you should use an actual player if you want playback [12:06:51 CEST] <memeka> of sdl output => same results :P [12:07:00 CEST] <memeka> yup using mpv :) [12:07:27 CEST] <memeka> but like i said ... same results everywhere ... memcpy is slow on 1080p videos => they max out a core @ 100% [12:07:37 CEST] <ubitux> > faster memcpy implementation [12:07:38 CEST] <jkqxz> Is this a mapping-uncached-memory thing? [12:07:48 CEST] <ubitux> what kind of faster memcpy? [12:07:56 CEST] <jkqxz> (If yes, don't do that. Get the GPU to do the copy for you.) [12:08:10 CEST] <memeka> ubitux: i have some NEON optimized memcpy (i on arm) [12:08:18 CEST] <ubitux> ok, don't do that then [12:08:23 CEST] <ubitux> that's up to your libc [12:08:33 CEST] <nevcairiel> any decent libc will already provide that [12:09:03 CEST] <memeka> the imp i have is from android... anw... it's worth a try ... [12:09:18 CEST] <memeka> so is there a place where i can replace memcpy? :) [12:09:28 CEST] <jkqxz> LD_PRELOAD [12:09:54 CEST] <JEEB> oh, bionic [12:09:58 CEST] <memeka> jkqxz: it's actually got another name the function ... should i rename it to memcpy and use LD_PRELOAD? [12:09:58 CEST] <JEEB> is it really that bad? [12:10:10 CEST] <JEEB> I mean, for memcpy [12:10:30 CEST] <memeka> JEEB: timed in gstreamer, decode 1080p frame = 19ms, memcpy = 24ms :) [12:10:45 CEST] <JEEB> is that decoding or decoding+copy? [12:10:57 CEST] <memeka> just decode = 19ms, just copy = 24ms :P [12:11:03 CEST] <memeka> total = the sum :) [12:11:09 CEST] <JEEB> ok [12:11:26 CEST] <JEEB> are you using mediacodec in which mode? [12:11:37 CEST] <JEEB> the surface or the other way? [12:11:39 CEST] <memeka> JEEB: not mediacodec, the new v4l2 [12:11:42 CEST] <JEEB> oh [12:11:50 CEST] <JEEB> so that stuff actually works? [12:11:59 CEST] <memeka> yes :) [12:12:03 CEST] <nevcairiel> apparently super slow [12:12:14 CEST] <nevcairiel> wasnt one point of that thing to have zero-copy with all its complexity [12:12:23 CEST] <JEEB> I think so? [12:12:26 CEST] <memeka> nevcairiel: just decode (output to null) => 130fps on 1080p video [12:12:43 CEST] <memeka> the rest of the stuff to output is not in v4l2 :P [12:12:44 CEST] <JEEB> memeka: how limited is hw support btw? [12:12:56 CEST] <JEEB> is it still just that one thing? [12:13:07 CEST] <memeka> what do you mean? [12:13:08 CEST] <nevcairiel> just decode is pointless to measure, as you always need to get to the image in some way [12:13:25 CEST] <nevcairiel> and much hardware has serious issues delivering it efficiently [12:13:49 CEST] <JEEB> memeka: IIRC the v4l hwaccel only worked with some things [12:14:10 CEST] <JEEB> like, if I have my oneplus one, would it work? (some qualcomm with adreno) [12:14:11 CEST] <memeka> yeah well like i said, just wanna try another memcpy :) worst case => it's as slow as libc memcpy :P [12:14:28 CEST] <memeka> JEEB: the v4l2 stuff was done on qualcomm on linux :) [12:14:33 CEST] <memeka> and apparently is fast :P [12:14:48 CEST] <memeka> (probably some zero-copy available or a better output format) [12:15:05 CEST] <memeka> i know if works on some other vendor too [12:15:12 CEST] <memeka> and works on mine too - exynos MFC [12:15:48 CEST] <memeka> so far only qualcomm one is fast - my exynos decoder outputs NV21/NV21 which i guess is hard to convert [12:16:13 CEST] <memeka> there's a HW converter, but v4l2 filters have not been implemented yet :P [12:16:16 CEST] <memeka> anw .... :) [12:16:34 CEST] <JEEB> yea, but does it require kernel newer than X and all that jazz :P [12:16:50 CEST] <memeka> can I do LD_PRELOAD from .o ? [12:16:52 CEST] <JEEB> as in, is it worth trying it out with mpv-android compared to just plain old mediacodec :P [12:19:03 CEST] <memeka> dunno android :) it was made on linux [12:19:17 CEST] <jkqxz> memeka: For LD_PRELOAD you want to make a shared object (.so) containing just "memcpy" as an external symbol. The linker should be able to make that directly from a relocatable object (.o). [12:20:24 CEST] <jkqxz> On hardware support for V4L2, it's meant to be common. But, like OpenMAX (which it is basically an in-kernel copy of), the implementations are all subtly different. [12:20:59 CEST] <jkqxz> It does work on multiple so far, but I certainly wouldn't rely on it working on a random implementation without testing it pretty carefully. [12:25:47 CEST] <JEEB> yea, mediacodec at least gets some testing on android 5+ [12:26:17 CEST] <memeka> jkqxz: thanks [12:26:35 CEST] <memeka> so there's exactly no change :( not even sure it got memcpy from there :( [12:26:46 CEST] <memeka> does ffmpeg implements its own? [12:27:15 CEST] <jkqxz> No, it uses the libc one. (Hence you can override it with ELF interposition via LD_PRELOAD.) [12:27:40 CEST] <memeka> libavutil/mem.c [12:28:00 CEST] <nevcairiel> mem.c is allocation, not copy [12:29:57 CEST] <memeka> https://www.irccloud.com/pastebin/y9vrmwaI/ [12:30:11 CEST] <memeka> this exports memcpy correctly, right? [12:40:01 CEST] <memeka> i changed stuff in the ASM code of the function, and it works the same :) so clearly it's not using it :D [15:32:34 CEST] <jya> BBB: ping [15:34:49 CEST] <BBB> jya: hi! [16:01:42 CEST] <captainmurphy> Hi everyone! Could someone point at functions (in libav* sources) that take care of handling RTMP/RTSP input? Thank you. [16:03:02 CEST] <jkqxz> libavformat/rt[ms]p* [16:04:08 CEST] <captainmurphy> thnx [16:16:10 CEST] <BtbN> Those aren't function you can use yourself though. You juse use them a normal protocol of libavformat. [16:17:15 CEST] <JEEB> he asked that question on #ffmpeg and I just auto-answered him on how to utilize it with the API :P [16:17:26 CEST] <JEEB> didn't even notice he was looking for the actual implementation details [16:17:42 CEST] <JEEB> (esp. since he replied with "Great! Thanks" [16:41:11 CEST] <durandal_1707> lol [16:41:31 CEST] <JEEB> git is hard, let's go shopping [16:43:41 CEST] <thardin> more like "please do our work for us" [16:44:07 CEST] <thardin> you'll do all the work and our bosses will make all the money [17:42:46 CEST] <yooyo3d> i think i have found very rare bug... in libavformat/mux.c in finction av_write_trailer add following [17:42:52 CEST] <yooyo3d> s->internal->nb_interleaved_streams = 0; [17:42:59 CEST] <yooyo3d> this prevents reusing AVFormatContext [17:43:05 CEST] <yooyo3d> after closing file [18:31:33 CEST] <nevcairiel> Don't think a context is meant to be reusable [18:52:58 CEST] <yooyo3d> Im trying to make live recording (with transcoding) and I want to write A/V to file.. but after some time (like 10 min) i want to close that file and start new one, without releasing AV* stuff. [18:53:53 CEST] <yooyo3d> regular way is to write trailes, call avio close and then start all over (alloc context, open codec, avio_open, write header, write packets...) [18:56:43 CEST] <yooyo3d> with above change (s->internal->nb_interleaved_streams = 0;) and with some AVPacket.pts changes its possible to write_trailes, then call avio_close, then call avio_open, clean some AVStream fields write_header and start writing packets [18:57:14 CEST] <yooyo3d> *trailer [22:13:24 CEST] <cone-669> ffmpeg 03Daniel Kucera 07master:858db4b01fa2: libavformat: not treat 0 as EOF [00:00:00 CEST] --- Fri Oct 20 2017

1 0

ffmpeg.log.20171019
by burek 20 Oct '17

20 Oct '17

[01:25:09 CEST] <Mista_D> any fast frame accurate range selection/splicing recomnedations for MP4 and TS files with MPEG2/H.264 please? [01:28:04 CEST] <wyth> Does anyone have any resource they can point me to for adding libraw support to my ffmpeg installation? [01:29:49 CEST] <wyth> I'm hoping to figure out a way to wrap a dng sequence to mov without re-encoding. Is it impossible? [01:31:13 CEST] <DHE> might be doable as long as mov supports the codec. there are limits. I don't konw what dng is so I can't comment [01:32:16 CEST] <g0n> Im trying to decode avpackets and I got frames, but when I print them they look weird, with no color and triple image (no, im not drunk) [01:32:49 CEST] <g0n> anyone knows what the problem could be? [01:32:53 CEST] <wyth> dng is a raw format that comes out of cameras, like those from blackmagicdesign specifically is what I'm working with [01:33:48 CEST] <klaxa> g0n: are you getting YUV planes maybe? [01:33:52 CEST] <DHE> sounds like you've got red,green,blue or YUV planes [01:34:35 CEST] <g0n> I dont really know im a noob concerning ffmpeg on c [01:34:50 CEST] <g0n> Took me 3 days to get frames... [01:35:44 CEST] <g0n> That has something to do with pix_fmt? [01:36:08 CEST] <klaxa> probably [01:36:27 CEST] <klaxa> a YUV frame is stored as 3 planes, first all Y values, then all U values then all V values [01:36:37 CEST] <klaxa> to get one pixel color you have to combine the three planes [01:37:04 CEST] <klaxa> for yuv420 for example, you take 4 Y pixels and 1 U and 1 V pixel to create one 2x2 pixelblock [01:37:25 CEST] <g0n> Ahh, ok, so then Ill look on that... [01:37:37 CEST] <klaxa> but i'm sure there is an easier way to do that in the library? [01:37:37 CEST] <g0n> Thanks for the explanation [01:37:39 CEST] <klaxa> not sure [01:38:12 CEST] <g0n> Know that i know the name and what it is Ill be easier to find [01:38:27 CEST] <g0n> Thanks :) [01:38:40 CEST] <DHE> you can use a filter or swscale to convert to another format, like rgb [01:41:51 CEST] <g0n> I found an answer [01:41:54 CEST] <g0n> AVFrame can be interpreted as an AVPicture to fill the data and linesize fields. The easiest way to fill these field is to the use the avpicture_fill function. [01:42:05 CEST] <g0n> :) [01:45:21 CEST] <wyth> Hm.. all I can see is requests to support DNG, so I guess it's looking like I'm out of luck? :-\ [04:13:13 CEST] <Toba> hey yall... this is going to sound like a dumb question but what is a lavfi [04:13:31 CEST] <Toba> what does that string refer to - it's tossed out all over online as a -f option, but I have no clue what it does and it isn't very google-able [04:20:16 CEST] <Toba> aha it's technically a virtual input device, i see http://ffmpeg.org/ffmpeg-devices.html#lavfi [08:57:36 CEST] <cowai> Hello all, [08:58:16 CEST] <cowai> Has anybody here any experience with distributed encoding (splitting source file into segments and rendering separately on different hosts) ? [09:00:15 CEST] <cowai> I want to segment the file with -f segment without audio, and render the audio separately. Then after all the segments are rendered I want to concat then along with audio. I have done tried this, and I always end up with lipsync problems. [09:01:06 CEST] <blap> nice idea [09:10:54 CEST] <JEEB> cowai: many here have experience with that, but that's generally the part where people write solutions on top of the APIs and those tend to be (C) YourDayJob and not publicly available [09:11:21 CEST] <JEEB> I mean, every darn VOD video site on the internet is doing it :P [09:13:11 CEST] <Nacht> Netflix wrote a nice bit about it on their techblog [09:19:50 CEST] <JEEB> the general details are not exactly secret, yes [09:19:58 CEST] <JEEB> it's just that nobody is just going to publish their code [09:20:20 CEST] <Nacht> Yeah I can imagine that. Although, in the age of open source, you occasionally get a kind soul :) [09:21:34 CEST] <Nacht> I haven't tried it myself, as I haven't had the need for it yet. [09:23:57 CEST] <JEEB> basically the issue is that at that point you're publishing a workflow than just a tool in your workflow. for VOD it's pretty simple generally since there's stuff like ffms2 which lets you index and frame-exactly access content. audio in my opinion I'm not even sure is worth encoding in separate chunks :P [09:24:14 CEST] <JEEB> (you can always fragment it according to your video fragment lengths) [09:24:15 CEST] <Nacht> https://medium.com/netflix-techblog/high-quality-video-encoding-at-scale-d1… [09:25:00 CEST] <JEEB> also don't remind me of the XML mess that is IMF... :| [09:27:05 CEST] <cowai> Does netflix split the source into chunks before rendering? [09:27:35 CEST] <Nacht> Ofcourse they do, read the article [09:28:25 CEST] <JEEB> although tbh there's multiple ways around that problem, and the problem depends on if you're taking in files of the size of hundreds of gigabytes or not [09:28:27 CEST] <Nacht> If you're rendering a movie of 2 hours in the highest bitrate and your process stalls, you just threw away allot of encoding. If you chunk it before, you only miss a tiny part [09:28:35 CEST] <JEEB> uhh [09:28:49 CEST] <JEEB> that has nothing to do with chunking the input (file) [09:29:02 CEST] <JEEB> that's just chunked decoding/encoding [09:29:13 CEST] <Nacht> That's one of the reasons Netflix mentioned as why they cut up the encoding [09:30:15 CEST] <cowai> In my project the input can be any format, any framerate and any resolution. Do I have a chance with simple scripting and ffmpeg ? [09:30:21 CEST] <JEEB> no [09:30:30 CEST] <Nacht> Also the fact that you can run allot of encoding parallel, so the process takes shorter [09:34:21 CEST] <cowai> I have a working example where I split the source into segments in the "master node" and render the audio to the end format in the same process. I then render each segment with the end video format and -c:a copy. I then concat it and it works. [09:34:21 CEST] <cowai> But this way is not efficient if I need 5 different renditions. The segments should have no audio, and the audio should be encoded separately and merged back in in the last step. But this results in out of sync issues most of the time. [10:19:32 CEST] <Nacht> Anyone got a good recommendation on a hardware encoder brand ? [10:19:50 CEST] <Nacht> Been looking at Harmonic and Ericsson(Envivio) [10:20:19 CEST] <Nacht> But judging from the website of Ericsson it's almost as they don't want people to know they even sell the things [10:26:27 CEST] <ChocolateArmpits> Nacht, maybe they are discontinued [10:26:56 CEST] <JEEB> Nacht: pretty sure people here either make their own solutions or buy solutions based on open source (there are vendors selling such boxes, even for broadcast use) [10:40:30 CEST] <Nacht> Can never hurt to ask [10:53:35 CEST] <lethalwp> hello; mpv --hwdec=vdpau shows me this: [vd] Pixel formats supported by decoder: vaapi_vld yuv420p10le [10:53:35 CEST] <lethalwp> [vd] Codec profile: Main 10 (0x2) [10:53:35 CEST] <lethalwp> [vd] Requesting pixfmt 'yuv420p10le' from decoder. [10:53:35 CEST] <lethalwp> [vd] Falling back to software decoding. [10:53:44 CEST] <lethalwp> but it should work: vdpauinfo shows: HEVC_MAIN 186 65536 4096 4096 [10:53:44 CEST] <lethalwp> HEVC_MAIN_10 186 65536 4096 4096 [10:54:00 CEST] <lethalwp> any idea why libavcodec is refusing the vpdau ? [11:00:13 CEST] <lethalwp> mm if i try ffmpeg -hwaccel vdpau -i samefile to otherone i get;: [AVHWDeviceContext @ 0x560fcd6825a0] Successfully created a VDPAU device (G3DVL VDPAU Driver Shared Library version 1.0) on X11 display :0 [11:00:13 CEST] <lethalwp> So i guess it should work [11:14:23 CEST] <JEEB> lethalwp: vdpau as far as I know has no 10bit output support [11:14:39 CEST] <JEEB> you could get it with cuvid I think? [11:15:12 CEST] <lethalwp> JEEB, even if vdpauinfo shows it's supported? [11:15:18 CEST] <lethalwp> it's an rx480 [11:15:25 CEST] <JEEB> then use vaapi [11:15:37 CEST] <JEEB> also yes, even if the PROFILE is supported it doesn't mean it can output 10bit [11:15:43 CEST] <JEEB> vdpau doesn't specify 10bit YCbCr surfaces [11:15:44 CEST] <lethalwp> ok doesn't work either; but will dig more ino that [11:15:59 CEST] <JEEB> vaapi should be the preferred way for AMD/Intel [11:16:10 CEST] <JEEB> and it does have a 10bit surface thing [11:16:14 CEST] <JEEB> if I recall correclty [11:16:42 CEST] <lethalwp> JEEB, i was hoping to use my rx480 to decode hevc_10bits even if it's display on a fullhd-nonhdr screen. But failing to do it. Do you know if some geforce1030 could do it?: read the 10bits content, decode, but display it as normal fullhd ? [11:17:35 CEST] <JEEB> well display is anyways up to your video renderer (which with mpv would be the opengl renderer) [11:18:25 CEST] <lethalwp> atm mpv always fallback to software decoding, whatever i choose. (my next step was kodi, but it doesn't even render x264 in hw, so even worse..) [11:19:12 CEST] <JEEB> it only falls back when something in the chain doesn't support the thing :P [11:19:57 CEST] <JEEB> I don't see how something else would be able to hwdec something unless you've failed to build or configure the other thing properly or something [11:20:04 CEST] <JEEB> also this is more related to #mpv to be honest [11:20:10 CEST] <JEEB> just move there :P [11:21:12 CEST] <lethalwp> still a little bit ;) just rebuilded mpv from git (with ffmpeg from git, mesa from up to date ppa); when decoding vaapi and rendering vaapi i get: [ffmpeg] AVHWFramesContext: Failed to create surface: 14 (the requested RT Format is not supported). [11:21:42 CEST] <JEEB> just fucking move to #mpv , ok? [11:21:48 CEST] <lethalwp> ok nvmd [11:21:50 CEST] <lethalwp> thx anyway [11:21:52 CEST] <JEEB> more people relevant to this discussion there [11:28:53 CEST] <orzel> Hello. I'm extracting quite some very useful ("metadata") information from video files using ffprobe json output. Though there's one information I'm not able to get, which is called "Scan type". Typically mediainfo would display it under this name, but i can't make ffprobe output it [11:29:50 CEST] <orzel> do you have any idea how to achieve this ? On a typical *.mov file i would get from mediainfo "Scan type" : interlaced, progressive, interleaved, .... [11:30:28 CEST] <orzel> i kinda have some hint when using -show_frames, but the output is very huge, and it's not exactly what i want [11:30:54 CEST] <JEEB> yea, show_frames and if you only care about what the first frame gives you can limit it to the first frame [11:31:03 CEST] <JEEB> because it's something that can change [11:31:10 CEST] <JEEB> like, it actually does in broadcast etc [11:31:22 CEST] <JEEB> top first/bottom first and all that jazz [11:31:31 CEST] <JEEB> and of course it only contains the information on the *coding* of the content [11:31:35 CEST] <JEEB> not the actual content itself [11:31:47 CEST] <JEEB> there are cases where interlaced coding is used for progressive content and vice versa [11:32:01 CEST] <JEEB> which are mistakes more or less but just to note that you can only know as much :) [11:34:10 CEST] <ChocolateArmpits> I usually skip 5 seconds and only then grab frame related information, makes it more safe I guess [11:35:16 CEST] <willhunt> I want to record images captured from a high speed frame buffer into video format, I need the exact timestamp of each frame, how can I do that, any suggestion? [11:36:22 CEST] <JEEB> what is your time line? does the frame buffer API come with a timestamp or is it just "you have to call some proper time API when getting stuff from the frame buffer"? [11:39:53 CEST] <willhunt> I call some API to capture the image, and when I got the image I know the timestamp, I just don't know how to encoding the image to video and how to save the timestamp of each frame? [11:40:58 CEST] <JEEB> in the FFmpeg libraries a raw image is an AVFrame, so you will have to create an AVFrame and utilize/create+copy buffers and set the PTS etc values [11:41:08 CEST] <JEEB> (and of course stuff like the pixel format etc) [11:41:58 CEST] <JEEB> there are helper functions for you to first get an AVFrame, and if you have to move your image to a more aligned memory buffer there's also one to allocate you that buffer with proper alignment as well [11:42:11 CEST] <JEEB> then the AVFrame can be fed to video encoders [11:42:14 CEST] <JEEB> then you get AVPackets [11:42:23 CEST] <JEEB> and those can be written by libavformat [11:42:31 CEST] <JEEB> I think that sounds relatively straightforward :P [11:43:20 CEST] <orzel> JEEB: i noticed that "scan type" can be about encoding and also about storing. That's it ? [11:43:38 CEST] <willhunt> is the timestamp information saved into the video? [11:44:02 CEST] <JEEB> willhunt: if you set the timestamp (PTS) correctly in the AVFrame [11:44:34 CEST] <willhunt> when I am decoding the video, what can I got? [11:44:36 CEST] <JEEB> and know what your time base is, and rescale the timestamps accordingly where needed it should go through the workflow a-ok [11:44:53 CEST] <JEEB> willhunt: if you are using the decoding APIs AVFrame's pts field will have the pts :P [11:45:08 CEST] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#a0452833e3ab6ddd7acbf82… [11:45:47 CEST] <JEEB> (the time base generally is the stream's time base which comes out of the demuxer, or is otherwise known) [11:46:02 CEST] <JEEB> I am kind of lobbying for AVFrame to have its own time_base field [11:46:10 CEST] <JEEB> but it has to be actually done [11:50:32 CEST] <willhunt> when decoding the video, what information can I got? I want to know the total image frame numbers of the video, and the original image frame data and its timestamp by its frame number [11:52:17 CEST] <JEEB> willhunt: to absolutely know how many frames a thing has you need to parse all packets first, image is a "d'uh, yes" and timestamps have nothing to do with frame numbers? if you need frame-exact access and indexing under a simpler API take a look at ffms2 [11:52:23 CEST] <orzel> JEEB: any idea which 'scan type' mediainfo actually display ? encoding or storage ? [11:52:38 CEST] <JEEB> ffms2 has frame-exactness and indexing of input done on top of FFmpeg's APIs [11:52:54 CEST] <JEEB> and it does give you the original YCbCr or RGB or whatever images [11:53:20 CEST] <JEEB> orzel: generally it's the coding type. Although if you can have the metadata in the container that is also exported [11:54:09 CEST] <JEEB> if I just run as a test on a random interlaced MOV sample I have around [11:54:30 CEST] <JEEB> http://up-cat.net/p/a2118527 [11:54:50 CEST] <JEEB> so all that information is available to you through the json output as well [11:55:24 CEST] <JEEB> the "bottom coded first" part is the interlacism part [11:56:09 CEST] <JEEB> it could be in the container for that track, or it could be in the video track itself; personally I don't care as long as I get the information :) [11:57:48 CEST] <willhunt> How fast should I encoding the video, the capturing frame rate is about 100 FPS [11:59:48 CEST] <JEEB> that depends on so many variables. how fast is your PC hardware, how much filtering is needed and if that is going to be a bottleneck if libavfilter is used [11:59:51 CEST] <JEEB> etc etc [12:00:02 CEST] <orzel> JEEB, ChocolateArmpits: is there any way to ask for ffprobe -show_frames to display only one (or few) frames, starting at 5S for example ? [12:00:08 CEST] <JEEB> yes [12:00:21 CEST] <JEEB> and you can even limit it to a specific stream after you've done -show_streams [12:00:22 CEST] <orzel> /frame in man ffprobe only reports -show_frames [12:00:54 CEST] <ChocolateArmpits> the documentation has frame limit syntax [12:01:47 CEST] <orzel> yop, ok https://stackoverflow.com/questions/35043972/how-to-limit-the-number-of-fra… [12:01:53 CEST] <orzel> so is such a good doc :) [12:02:33 CEST] <JEEB> that's actually documented https://ffmpeg.org/ffprobe.html [12:02:46 CEST] <JEEB> and this is generated from the man page [12:02:54 CEST] <JEEB> if you look for "read_intervals" there [12:03:51 CEST] <JEEB> willhunt: anyways you'd have to first find out the input parameters (pixel format etc), and then find out what your required output is [12:04:02 CEST] <JEEB> and then one could start looking into possible bottlenecks [12:14:02 CEST] <willhunt> the captured image is 1024x1024 and grayscale, the capturing frame is 100 FPS, if I want to record the images into video with their capturing timestamps, what should I learn? could you give me some concrete help? [12:15:18 CEST] <orzel> JEEB: yes, thanks [12:53:38 CEST] <mushy> hey [12:54:14 CEST] <mushy> Is anybody in this chat? [12:55:08 CEST] <blap> maybe [12:55:50 CEST] <mushy> Awesome, Im new to ffmpeg (and not a very good linux user either) [12:56:06 CEST] <mushy> Im currently trying to compile FFMPEG from source so that i can use it in a c++ program [12:56:28 CEST] <mushy> do you think you'd be able to offer any help with this@? [12:58:11 CEST] <cowai> is high average psnr good or bad? [12:59:34 CEST] <mushy> Does anyone have a deecent up to date guide on installing & using FFMPEG in c++ for a beginner? [13:00:52 CEST] <blap> i don't know [13:01:12 CEST] <blap> i mean you can use a system call mushy [13:01:22 CEST] <blap> and pass parameters to ffmpeg [13:01:28 CEST] <blap> but maybe there's an api too [13:01:56 CEST] <mushy> Yeah i know, but id like to use the API as i will be eventually cross compiling and using it from NDK on android [13:02:09 CEST] <mushy> so i felt it would be worth while getting familiar with the api [13:02:36 CEST] <JEEB> mushy: docs/examples has quite a few examples [13:02:56 CEST] <JEEB> and there's the documents that you can find in doxygen comments which can also be browsed on teh web [13:03:12 CEST] <mushy> JEEB thanks, ill check them out.. currently feeling a little bit demotivated as i have hit hiccups even with the compilation guide... [13:03:13 CEST] <JEEB> stuff like https://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html [13:04:04 CEST] <JEEB> mushy: don't follow a guide with all the bells and whistles. keep in mind that 99% of all things for decoding are enabled within FFmpeg by default and need no external libraries. for encoding libraries are more often required but you must have a specific requirement so focus on that [13:04:07 CEST] <mushy> JEEB brilliant - https://ffmpeg.org/doxygen/trunk/encode_video_8c-example.html - that gives me something to work on [13:04:53 CEST] <mushy> Sure, this time i have encoded without : [13:04:54 CEST] <mushy> --enable-libfdk_aac \ --enable-libfreetype \ --enable-libmp3lame \ --enable-libopus \ --enable-libvorbis \ --enable-libvpx \ --enable-libx264 \ --enable-libx265 \ [13:05:17 CEST] <JEEB> basically start with a plain ./configure [13:05:25 CEST] <JEEB> and then add things you *require* [13:05:44 CEST] <JEEB> if you don't even require libx264 for H.264 encoding then it is highly likely that you don't need a lot of stuff you're enabling [13:06:19 CEST] <JEEB> also most compilation guides focus on static dependencies and just getting the ffmpeg.c command line tool [13:06:42 CEST] <JEEB> which might not be what you want when you're building your stuff [13:07:00 CEST] <JEEB> so yea, find what you actually require [13:08:07 CEST] <mushy> for now my goal is to write a very basic c++ program which will take frames from a grayscale image (i get the data from a fingerprint scanner) and save the frames into an AVI container [13:08:33 CEST] <JEEB> if it's just images you might as well initially just write out PNG files? [13:08:44 CEST] <JEEB> (you need zlib for that) [13:09:23 CEST] <mushy> The program i am talking about building is purely an example for me to use to learn [13:09:26 CEST] <JEEB> so yea, configure --prefix=/your/prefix --enable-zlib gives you static FFmpeg libraries, and add `--disable-static --enable-shared` to get shared libraries [13:09:32 CEST] <JEEB> yes, the flow is the same [13:09:59 CEST] <mushy> JEEB perfect, so will those flags allow me to link the librarys i need and have a self contained program [13:10:19 CEST] <JEEB> mushy: you get required flags from the pc (pkg-config) files [13:11:09 CEST] <JEEB> PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig pkg-config --libs libavcodec [13:11:11 CEST] <JEEB> for example [13:11:26 CEST] <JEEB> many build systems have support for it and it's the standard way to convey "which flags do I need for this library" [13:12:33 CEST] <mushy> Okay, i think ill have to do a little bit of reading up on pkg-config before starting [13:12:52 CEST] <JEEB> the pc files get installed into the prefix when make install is ran [13:13:09 CEST] <JEEB> for example I have my ARMv7 prefix in /home/jeeb/ownapps/armv7_prefix/ [13:13:15 CEST] <mushy> make & make install seems to have just ran fine. [13:13:25 CEST] <JEEB> http://up-cat.net/p/97b74014 [13:13:34 CEST] <mushy> ill try to find where mine [13:13:35 CEST] <mushy> are [13:13:36 CEST] <JEEB> (PKG_CONFIG_LIBDIR completely overrides) [13:13:45 CEST] <JEEB> PKG_CONFIG_PATH appends to the default search path [13:13:56 CEST] <JEEB> in my case since I have built for ARM I don't want my local x86 stuff there ;) [13:14:22 CEST] <JEEB> same for cflags, they're also there [13:15:09 CEST] <mushy> would the command echo $PKG_CONFIG_PATH show me what is in mine? [13:17:21 CEST] <JEEB> mushy: no since it's not around by default [13:17:34 CEST] <JEEB> even though it's "SOMETHING_PATH" it's *appending* to the default locations [13:17:42 CEST] <JEEB> which is kind of misleading, yes [13:17:50 CEST] <JEEB> mushy: they always go under what you set as --prefix [13:18:01 CEST] <JEEB> <prefix>/lib/pkgconfig [13:18:41 CEST] <mushy> Right its a little confusing right now. i think ill go and find some basic resources that describe it [13:19:04 CEST] <mushy> do you know if it has anything to do with the error messages im getting trying to compile some of the sample code? [13:19:05 CEST] <mushy> In file included from /usr/local/include/libavutil/mem.h:34:0, from /usr/local/include/libavutil/common.h:464, from /usr/local/include/libavutil/avutil.h:296, from /usr/local/include/libavutil/samplefmt.h:24, from /usr/local/include/libavcodec/avcodec.h:31, from main.cpp:31: main.cpp: In function int main(int, char**): main.cpp:112:55: error: tak [13:19:36 CEST] <mushy> formatted [13:19:36 CEST] <mushy> https://pastebin.com/p48VHRNR [13:20:07 CEST] <JEEB> because it's not C++ [13:20:13 CEST] <JEEB> there's a thing about that in the docs [13:20:30 CEST] <JEEB> https://trac.ffmpeg.org/wiki/Including%20FFmpeg%20headers%20in%20a%20C%2B%2… [13:20:40 CEST] <JEEB> it's in the actual docs as well, but this popped up on top on google :P [13:22:18 CEST] <mushy> Strange still getting the error when i try and compile. Should i be using any flags or will g++ main.cpp suffice? [13:23:55 CEST] <JEEB> they're not C++ if you're talking about the examples [13:24:25 CEST] <JEEB> I mean, it's not *that* different to make them into valid C++, but just for the record they're not made with that in mind [13:24:44 CEST] <mushy> Ahhhh makes sense [13:24:46 CEST] <JEEB> also I have never built the examples, I just have looked at how they're built at times [13:25:02 CEST] <JEEB> but I would bet they'd require the linker and cflags [13:25:03 CEST] <JEEB> :P [13:25:07 CEST] <JEEB> which you can get from pkg-config [13:25:45 CEST] <mushy> I think ive found exactly what i need... https://trac.ffmpeg.org/wiki/CompilationGuide/Generic [13:26:24 CEST] <mushy> Thanks for the help so far though JEEB [13:26:55 CEST] <JEEB> no problem [13:38:14 CEST] <mushy> If i were to make install with the prefix set to /opt/ffmpeg on Fedora would uninstallation just be a case of deleting that directory? [13:39:06 CEST] <JEEB> mushy: yes, but for quick development purposes I would just be utilizing a local prefix under /home [13:39:26 CEST] <JEEB> that way no sudo is needed during make install, either [13:40:02 CEST] <mushy> Okay thanks for the tip. I wasn't aware of what a prifix even was until just now so my previous installation is to /usr/local/ [13:40:22 CEST] <JEEB> so you just without thought did sudo make install? :P [13:41:01 CEST] <JEEB> thankfully /usr/local should be relatively empty so you can double-check if there's anything that wasn't installed today and then clean that directory just in case [13:44:27 CEST] <JEEB> mushy: think of prefix as the "installation location" [13:44:53 CEST] <JEEB> that can have stuff under it like bin/ , lib/ , include/ to mention the most technically needed ones [13:45:36 CEST] <JEEB> (which is the standard *nix directory structure) [13:46:13 CEST] <JEEB> that way if you have two or more libraries required for a thing, you can install them all into a single prefix, and then use that prefix during configuration of the build of whatever you're finally trying to build [13:46:45 CEST] <mushy> Ahhh makes sense! [13:47:27 CEST] <mushy> do you reccomend i clean out ffmpeg from my /bin /include /lib and /include and re install with a prefix set to my home directory? [13:48:00 CEST] <JEEB> during development usually I prefer a prefix that doesn't require root access to write to [13:48:05 CEST] <JEEB> so I can easily and quickly make changes [13:48:29 CEST] <mushy> Fair enough, i mean i am currently working in a VM so i dont really mind mucking about [13:48:48 CEST] <JEEB> you can keep your prefix at /usr/local (since that's usually not utilized by the package management) [13:48:52 CEST] <JEEB> if you want to [13:49:02 CEST] <JEEB> just that it requires root to access it [13:49:19 CEST] <JEEB> positive side is that /usr/local/lib usually is in your default shared library search path [13:58:03 CEST] <yooyo> Need help from developers... Is it possible to call avio_open(...) then avformat_write_header(...) then write some packets, then av_write_trailer(..) then avio_close, AND change filename and start all over again.. avio_open, avformat_write_header, write packets, av_write_trailer(..), avio_close? [13:58:43 CEST] <JEEB> sounds like simpler for you to make your own AVIO thing [13:58:51 CEST] <yooyo> without touching codec context, streams, etc... just want to start writing file on different location [13:59:35 CEST] <JEEB> so you provide C functions for read/seek/write (the required ones) [13:59:44 CEST] <JEEB> and then tell avformat "use these functions" [13:59:51 CEST] <JEEB> and you can handle all of your custom logic in that stuff of yours [14:00:30 CEST] <JEEB> and then your lavf code would call the usual lavf APIs as required [14:00:44 CEST] <JEEB> but all that "not pretty" custom I/O logic could be pushed somewhere else [14:01:06 CEST] <JEEB> I made something for reading and seeking in 2013, and while the APIs in general have changed, I think this hasn't too much :P [14:01:09 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper… [14:02:14 CEST] <yooyo> I'll check that [14:02:22 CEST] <JEEB> see https://ffmpeg.org/doxygen/trunk/structAVIOContext.html [14:03:28 CEST] <yooyo> I cant simply reopen files on lower level... old file hast to be properly closed, and new one properly open [14:04:30 CEST] <yooyo> seems that avio_close or av_write_trailer mess with muxer [14:04:31 CEST] <JEEB> well, I thought you had your logic for that stuff? although yes, if lavf is using multiple threads (to write stuff) that can be fun, but I'm not sure it does [14:04:46 CEST] <JEEB> yooyo: yes, those are higher level things that you call from lavf [14:04:55 CEST] <JEEB> those then cause it to call the write function [14:05:09 CEST] <JEEB> avio_close is AVIO stuff and you can override it with your AVIO context [14:05:11 CEST] <yooyo> and I cant find a way to "reset" muxer [14:05:30 CEST] <JEEB> I'm still not sure WTF you're doing, I'm just giving you examples of how to write the different packets into different files [14:05:39 CEST] <JEEB> because that's what it seemed to be what you're doing [14:05:43 CEST] <JEEB> by your short explanation [14:05:59 CEST] <JEEB> in which case you put your custom logic into the AVIO wrapper you have which decides which packets or whatever go where [14:06:12 CEST] <JEEB> or well, at that point, which bytes [14:07:10 CEST] <JEEB> and yes, if you were trying to do it with a single muxer instance that wouldn't work because that instance would be "done" with after you write the trailer/close [14:07:22 CEST] <JEEB> so either you want to ignore the lavf level and just receive bytes [14:07:28 CEST] <JEEB> in which case you have the AVIO level [14:07:37 CEST] <JEEB> you receive bytes from lavf and you write them wherever the hell you want [14:07:41 CEST] <JEEB> files are not even a thing at that point [14:07:42 CEST] <yooyo> Im recording live stream and I want to record to a file and after say 10min close file and continue recording in new file [14:08:02 CEST] <JEEB> ok, then there's the segment muxing capabilities of things [14:08:07 CEST] <yooyo> so.. after 10 min close current file, open new one and loop [14:08:43 CEST] <JEEB> you can do it by making new muxers of course, which is that I think the segment muxer is doing [14:09:03 CEST] <yooyo> i can do it by freeing everything and creating context and codec etc.. but I would like to avoid that step [14:09:16 CEST] <JEEB> you can just partially push it into lavf itself as I said :P [14:09:23 CEST] <JEEB> it has the segment muxer [14:09:39 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c… [14:10:29 CEST] <mushy> Am i doing something wrong? Im compiling this super simple code https://pastebin.com/v8dERt8M with the command "g++ main.cpp -L /usr/local/lib -I /usr/local/include" And getting the error https://pastebin.com/PD9NWgeS [14:11:13 CEST] <JEEB> mushy: yes you need the required linker flags too [14:11:34 CEST] <JEEB> PKG_CONFIG_PATH=/usr/local/lib/pkgconfig pkg-config --libs libavcodec for libavcodec for example [14:11:36 CEST] <mushy> g++ main.cpp -L/usr/local/lib -lavutil -lavformat -I/usr/local/include [14:12:22 CEST] <yooyo> OK.. I'll check segment_stream code.. there should be some trick [14:12:44 CEST] <JEEB> mushy: just call pkg-config in your build process. in the worst case something like $(pkg-config --libs libavcodec) [14:12:51 CEST] <JEEB> and cflags for the C flags [14:13:13 CEST] <JEEB> so when you get some reference you cannot find, look up in which library it is and add that to your dependencies [14:14:44 CEST] <mushy> Thanks JEEB, Im having a little trouble with the syntax but im sure ill figure it out [14:14:54 CEST] <mushy> g++ main.cpp -L/usr/local/lib -lavutil -lavformat -I/usr/local/include pkg-config '--libs libavcodec libavformat' [14:15:26 CEST] <JEEB> yea the singular quotes there might be a problem :P [14:15:39 CEST] <JEEB> because they make '--libs libavcodec [14:15:53 CEST] <JEEB> blah be a single parameter to g++ :P [14:16:04 CEST] <mushy> right so it thinks its a file [14:16:20 CEST] <JEEB> or just a parameter to itself, how it interprets that is separate :P [14:16:44 CEST] <JEEB> I would recommend you to either make a Makefile quickly or poke something like meson or cmake. since your thing only needs the C++ compiler and pkg-config it should be pretty simple [14:17:26 CEST] <JEEB> check if meson for example is available in your installed version of fedora [14:17:36 CEST] <JEEB> and check making something like this quickly for your test thing http://mesonbuild.com/Tutorial.html [14:17:50 CEST] <JEEB> then you don't have to make the long commands manually all the time :P [14:18:37 CEST] <mushy> im a little familiar with cmake. is there any reason to use meson instead? [14:19:02 CEST] <JEEB> not really. it seems more promising but if you already know of cmake that should be fine as well [14:19:22 CEST] <mushy> Okay ill see what i can come up with, thanks for the direction again! [14:19:25 CEST] <JEEB> np [14:23:17 CEST] <cowai> is there a preset with better quality than "slow" on h264_nvenc ? [14:23:49 CEST] <cowai> slow@h264_nvenc is worse quality than ultrafast@x264 at the roughly the same speed. [14:23:54 CEST] <cowai> using a gtx 770 [14:24:15 CEST] <JEEB> don't expect good compression capabilities from hw encoders [14:24:29 CEST] <JEEB> they're purely there for the speed + "no CPU usage" [14:26:14 CEST] <cowai> Do you know if paid solutions like aws elastics encoder use gpu or x264? [14:26:43 CEST] <JEEB> if they're cloud they're generally something based on FFmpeg or similar [14:27:09 CEST] <JEEB> I just can't see dedicated server GPUs at any point being as price-performant as CPU-based encoders [14:27:27 CEST] <JEEB> even with the fact that the server GPUs can give you some extra streams [14:27:30 CEST] <cowai> aws delivers nvidia gpus with ec2 [14:27:47 CEST] <JEEB> yes, and I really wonder how the fuck people select those. is it that pure CPU pricing is just crazy there? [14:28:00 CEST] <cowai> no idea. [14:28:39 CEST] <JEEB> but yea, in very specific use cases I can see GPU ASIC encoding being useful [14:29:00 CEST] <JEEB> but if the "box" is just going to be doing video streaming... [14:29:15 CEST] <JEEB> (or vod transcoding or whatever) [14:30:09 CEST] <cowai> I can see them using gpus and now doing the slow preset, and just do not care about the quality [14:30:24 CEST] <JEEB> yea, but you're paying how much for the GPU per month? [14:30:35 CEST] <JEEB> and how many streams at the same time [14:30:36 CEST] <cowai> i mean with their encoding service. [14:30:51 CEST] <JEEB> I'd be surprised if that was GPU based for anything else than marketing [14:30:56 CEST] <JEEB> it just doesn't make sense [14:31:06 CEST] <cowai> if they can encode twice as fast with lets say 20% worse quality, then for aws its maybe worth it [14:31:47 CEST] <JEEB> even if it's less fast you can stick more streams on it, since you're usually not maximizing the CPU utilization with a single stream [14:31:48 CEST] <cowai> quality for speed makes sense when the audience do not know what x264 is and all they want is an api. [14:32:32 CEST] <JEEB> basically, given the extra costs for the GPUs and the fact that they have a very good system for putting CPU loads around I don't think there's *any* reason to use GPUs for encoding [14:32:38 CEST] <JEEB> not to mention that most of that GPU would be idle doing nothing [14:32:44 CEST] <JEEB> after all, it's not the actual GPU doing the encoding [14:32:46 CEST] <JEEB> it's the ASIC on it [14:32:57 CEST] <cowai> right now I am rending at 700fps with my gtx [14:33:17 CEST] <cowai> *rendering. [14:33:31 CEST] <JEEB> if you're actually rendering stuff that's actual GPU GPU usage [14:33:46 CEST] <JEEB> the encoding has nothing to do with the GPU GPU parts [14:34:07 CEST] <cowai> makes sense [14:34:30 CEST] <JEEB> + the ASICs are limited by the amount of streams they can take in [14:34:48 CEST] <JEEB> so while on a server you can put ~30 live streams [14:34:55 CEST] <cowai> i have read that utilizing cuda for scaling as well has some benefits. But I think it all depens if one must have the cpu ready for other things or not. [14:35:08 CEST] <JEEB> I'm not sure if you can put that amount of streaming on a GPU, or then you start needing multiple GPUs [14:35:28 CEST] <JEEB> yes, you can do some filtering on the card as well [14:35:41 CEST] <JEEB> but seriously, if you cannot feed the ASIC encoder enough streams then what's the point [14:35:47 CEST] <cowai> the aws service I am talking about is for VOD, not live. [14:36:15 CEST] <JEEB> and for VOD you can splice and encode separately, you don't care about absolutely fastest yet crappiest encoder [14:36:29 CEST] <JEEB> and you can really put that load onto umpteen things [14:36:42 CEST] <JEEB> even for VOD it really doesn't make sense on a scale [14:37:03 CEST] <JEEB> because even if you don't split you most likely have more than one thing that you want to encode in a system like that (or well, your customers want to encode) [14:37:36 CEST] <JEEB> I see the use case for GPU encoding being where you don't want to use the CPU for it for some reason, like gaming [14:37:50 CEST] <JEEB> I've used my GPU's ASIC for encoding lossless H.264 game capture [14:37:51 CEST] <cowai> and for marketing purposes ;) [14:37:52 CEST] <JEEB> completely valid use case [14:37:57 CEST] <JEEB> yes, of course [14:38:54 CEST] <JEEB> but I've actually seen people on this channel pick GPU encoding for their solution, and it seems to somehow be viable. I haven't looked at the "cloud" providers' prices too much but are the proper CPU-based things actually priced that much higher than the GPU-included ones, that suddenly that starts making sense? [14:39:12 CEST] <JEEB> in which case goddamn, someone should start looking at rented dedicated servers [14:40:07 CEST] <JEEB> although to be honest, such selections probably have over 9000 non-technical reasons there [14:45:30 CEST] <cowai> Does anybody see anything fundamentally wrong with this approach? https://gist.github.com/cowai/bc6ef0a9b12f6a0d44a6d73d74ca8947 [14:45:50 CEST] <cowai> Its an example of chunked encoding [14:46:13 CEST] <cowai> It works. But I havent tested with more than one file right now. [14:55:48 CEST] <mushy> Its working!! [14:56:13 CEST] <JEEB> with the segment muxer I guess [15:22:35 CEST] <paveldimow> Hi, I want to use the overlay feature but I would like to dynamically change the input stream. Is this possible? [15:24:55 CEST] <JEEB> paveldimow: with the API *you* define what gets fed, but with the cli ffmpeg.c most likely not [15:44:05 CEST] <captainmurphy> Hi everyone! Could someone point at functions (in libav* sources) that take care of handling RTMP/RTSP input? Thank you. [15:45:04 CEST] <JEEB> a) make sure those protocols are enabled in libavformat b) open the thing as usual with the rtmp or rtsp url [15:45:11 CEST] <JEEB> I don't think there's much more special to them than that [15:45:47 CEST] <captainmurphy> Great. Thanks! [15:46:35 CEST] <JEEB> setting any additional parameters to the protocol or demux is the same as usual as well, in case additional things are needed [15:55:38 CEST] <paveldimow> tnx JEEB ! [16:10:40 CEST] <blap> jeeb's a helpful person [17:35:19 CEST] <yooyo> i think i have found very rare bug... in libavformat/mux.c in finction av_write_trailer add following [17:35:21 CEST] <yooyo> s->internal->nb_interleaved_streams = 0; [17:35:49 CEST] <yooyo> this prevents reusing AVFormatContext [17:35:57 CEST] <yooyo> after closing file [17:36:20 CEST] <JEEB> you should pose that question on the -devel channel [18:02:32 CEST] <BtbN> yooyo, reusing a context is not supported [18:03:00 CEST] <jbreeden> Hello all. I am working on developing an ffmpeg codec that takes advantage of a proprietary static library (*.a) that I have licensed. When building ffmpeg, where is the appropriate place to link this library? [18:03:28 CEST] <BtbN> I am pretty sure that highly violates both GPL and LGPL [18:03:58 CEST] <Johnjay> BtbN: code that that uses proprietary code violates the GPL? [18:04:14 CEST] <jkqxz> Only if you then distribute it. [18:04:25 CEST] <BtbN> statically linking to a completely non-free library is [18:04:51 CEST] <Johnjay> oh ok that makes sense [18:05:03 CEST] <Johnjay> he said "takes advantage of" linstead of "statically links to" and I got thrown off [18:05:32 CEST] <Johnjay> The last time I fussed with the GPL i was building python aexecutables on windows [18:05:46 CEST] <BtbN> It's not forbidden to do so, but you can never distribute that [18:05:47 CEST] <Johnjay> And it had an option to make a stand alone exe file to distribute. wasn't sure if that was GPL friendly or not [18:06:25 CEST] <jbreeden> Hmmm okay. FFmpeg doesn't have any mechanism of dynamically linking plugins, does it? [18:07:49 CEST] <thebombzen> not at the moment [18:07:51 CEST] <thebombzen> or rather [18:07:55 CEST] <thebombzen> it can dynamically link [18:07:58 CEST] <thebombzen> but it can't load at runtime [18:09:31 CEST] <Johnjay> would there be any benefit to that? [18:09:34 CEST] <thebombzen> which means you can't make your version of FFmpeg search for your proprietary library and load it at runtime only if it's found, unless you do the hard work of making that happen [18:09:59 CEST] <thebombzen> however, you can link dynamic libraries at compile-time to ffmpeg. that's very common and expected (I mean how else are you supposed to link libc?) [18:10:30 CEST] <Johnjay> thebombzen: you can even link to dlls on windows with mingw! amazing [18:10:34 CEST] <BtbN> You cannot dynamically load a static library [18:11:01 CEST] <thebombzen> not sure why you'd want a static library anyway tbh [18:11:04 CEST] <JEEB> well, on mingw-w64 .dll.a files are actually stubs for shared linking [18:11:04 CEST] <BtbN> And even if you dlopen something proprietary, that does not clean up the license situation. Only makes it even more complicated. [18:11:50 CEST] <JEEB> but with shared linking you're still way against GPL and just somewhat problematic wrt LGPL (since you're supposed to be able to replace the LGPL part with your own build with the same things) [18:12:17 CEST] <thebombzen> well with LGPL isn't it fairly simple? isn't the point of LGPL that you can link components together and the LGPL doesn't interfere? [18:13:02 CEST] <JEEB> well, the point in LGPL is that the user can replace the library if he or she so wants from the same sources [18:13:20 CEST] <JEEB> now the problem when you link FFmpeg itself against a proprietary thing [18:13:30 CEST] <JEEB> is that you'd have to provide the lib and headers for that [18:13:40 CEST] <JEEB> so that it could be linked successfully [18:15:34 CEST] <JEEB> basically it's problematic but not impossible (IANAL though) [18:15:52 CEST] <thebombzen> man being in the EU must make this a lot easier tho [18:16:01 CEST] <thebombzen> IP law in the US is a pain [18:16:54 CEST] <JEEB> well the LGPL really doesn't differ [18:17:44 CEST] <BtbN> The EU just doesn't have idiotic software patents [18:18:35 CEST] <thebombzen> god I hate those [18:22:31 CEST] <blap> the average german gets 8.83 liters / 100km (bier consumption) [18:23:20 CEST] <JEEB> &32 [18:39:12 CEST] <jbreeden> Alright, so [18:39:27 CEST] <jbreeden> I see this company makes an FFmpeg plugin that presumably is proprietary: http://beamr.com/h264-hevc-encoder-codec-software-development-kits/ [18:39:54 CEST] <jbreeden> I don't see how they'd be able to do this if there weren't some way around the licensing. [18:45:26 CEST] <jkqxz> I imagine they supply you with a proprietary static library and a set of source code patches to ffmpeg. [18:45:32 CEST] <JEEB> those services don't usually distribute their stuff, even if they use it [18:45:40 CEST] <jkqxz> You can then build the modified source and link it with the static library, and use it yourself. [18:45:43 CEST] <JEEB> yes [18:45:45 CEST] <jkqxz> You can't distribute it to anyone else. [18:46:04 CEST] <JEEB> because you yourself can do your own non-free builds just fine [18:46:16 CEST] <JEEB> also lol, man that marketingtalk [18:46:23 CEST] <Johnjay> JEEB: do you use mingw much? [18:46:35 CEST] <JEEB> Johnjay: every now and then [18:47:02 CEST] <Johnjay> TIL that mingw targets all the windows subsystems VC targets.. except one. Boot-Application [18:47:24 CEST] <JEEB> is that the UEFI stuff? [18:47:38 CEST] <jbreeden> Okay, thanks for the feedback. [18:47:45 CEST] <Johnjay> idk [18:47:48 CEST] <Johnjay> just noticed it [18:48:01 CEST] <Johnjay> something about BCD [18:48:01 CEST] <JEEB> jbreeden: so basically if you were planning on doing anything you distribute - that's a no go [18:49:24 CEST] <JEEB> Johnjay: ok so it's something for the windows bootloader post-UEFI it seems [18:49:31 CEST] <JEEB> at least that's how it looks like [18:49:46 CEST] <JEEB> so in theory it's closer to windows, but not really [18:49:59 CEST] <JEEB> a rather limited target if I may say [18:50:00 CEST] <Johnjay> JEEB: is that significant, being after UEFI in this context? [18:50:37 CEST] <JEEB> yes, since UEFI is completely separate from the OS. the bootloader binary loaded by the UEFI system then is closer to your OS (as it's provided by it) [18:50:41 CEST] <marlenka> hi [18:51:14 CEST] <jbreeden> So if I were to make an LGPL codec that used dlopen to access a proprietary shared library that was distributed separately, would that be in violation to your knowledge? [18:51:15 CEST] <Johnjay> ohh ok lol [18:51:23 CEST] <Johnjay> i thought you meant historically, as in after the advent of UEFI [18:53:43 CEST] <JEEB> jbreeden: IANAL, with LGPL the base thing is that the source code for the LGPL thing is given out (in this case it would be FFmpeg) and that the user can rebuild the whole thing to replace the LGPL component with his own if he wishes (not that you need to support it, it just needs to be technically possible) [18:55:46 CEST] <JEEB> jbreeden: also to be honest I'm not sure how much you'd be losing at that point by just having your proprietary thing using the FFmpeg APIs having its own encode API for that encoder, that way just not using FFmpeg for that and making it a simpler LGPL case :P [18:56:44 CEST] <JEEB> since "just linking LGPL FFmpeg to a proprietary app" is something that's pretty common and OK as long as you a) provide sources to the LGPL part and b) enable the replacement of the binary by the user (technically) [18:58:12 CEST] <Johnjay> JEEB: is that replacement of the binary thing part of the LGPL? [18:58:17 CEST] <Johnjay> the wikipedia page mentions it too [18:59:12 CEST] <JEEB> yes, although stuff like DRM can still stop the user from actually doing it, but if the user does it correctly he should be able to compile the binary as well. [18:59:24 CEST] <JEEB> that's why people generally don't do LGPL with static linking [18:59:36 CEST] <JEEB> because then you'd have to provide all your object files for the proprietary stuff :P [18:59:47 CEST] <JEEB> (as the f.ex. FFmpeg gets linked to it statically) [19:00:14 CEST] <JEEB> but as I said, this is all IANAL and generally from my history of looking at how things sit [19:00:38 CEST] <JEEB> the most general failure with people who don't want to release their sources is that they pack in an FFmpeg binary with GPL features enabled :P [19:00:49 CEST] <JEEB> and then complain "I just copied my configuration from <project X>" [19:01:14 CEST] <Johnjay> it says on the ffmpeg webpage not to use --enable-gpl or --enable-nonfreee [19:01:30 CEST] <JEEB> enable-nonfree makes an FFmpeg binary non-distributable [19:01:37 CEST] <JEEB> enable-gpl enables GPL features in the configuration [19:01:41 CEST] <jbreeden> Yeah, this is useful feedback. I have no issue releasing source for the wrapper plugin, but I have no control over the proprietary licensing. So, navigating this is a pita. [19:02:31 CEST] <JEEB> do first check if whatever you're trying to utilize is actually worth it. I mean, x265 isn't great but if you're looking for HEVC it's pretty much one of the least retarded alternatives [19:03:18 CEST] <JEEB> (it is GPL though, although it's under dual licensing if you find it actually useful) [19:03:20 CEST] <Johnjay> i'm still confused about this providing object files thing [19:03:36 CEST] <JEEB> Johnjay: it's specific to static linking of an LGPL library [19:03:53 CEST] <JEEB> now you have a proprietary app X that utilizes an LGPL FFmpeg, built into static libraries [19:03:59 CEST] <JEEB> it all goes into a single binary [19:04:14 CEST] <jbreeden> Yeah, in lieu of providing source you can compile your propietary pieces but just provide the *.o so others can rebuild LGPL portions and statically link [19:04:15 CEST] <Johnjay> ok that's what confused me, in the wiki page it only talks about the LGPL as relevant for dynamic linking [19:04:27 CEST] <JEEB> yea, technically you can do it with static [19:04:34 CEST] <JEEB> but it's really not generally what you want to do [19:04:36 CEST] <JEEB> it's messy :P [19:04:45 CEST] <JEEB> (and you have to release the object files which most people don't want to do) [19:05:07 CEST] <Johnjay> because of the requirement to be able to compile with a new version of the LGPL library? [19:05:13 CEST] <JEEB> not a new version [19:05:34 CEST] <JEEB> you just have to be able to replicate the same thing with the sources provided by the vendor [19:05:44 CEST] <Johnjay> >Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. [19:05:48 CEST] <jbreeden> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic [19:06:12 CEST] <JEEB> Johnjay: that's bullshit, there's no requirement for a vendor to support a newer version of a thing that he's never heard of [19:06:36 CEST] <JEEB> or well, newer micro version without API changes sure - that could be possible. but the vendor doesn't have to do that updating or anything for you [19:06:48 CEST] <JEEB> in the sense that you can do your hacks and update stuff - sure [19:06:51 CEST] <JEEB> that has to be possible [19:06:58 CEST] <Johnjay> oh ok that page on gnu.org makes sense [19:07:24 CEST] <JEEB> but the vendor doesn't have to add any support for things they didn't distribute [19:08:17 CEST] <Johnjay> right. this is all basically trying to make up a legal tool to allow distributing GPL libraries with proprietary code [19:08:23 CEST] <Johnjay> hence why ffmpeg is LGPL [19:08:30 CEST] <jbreeden> I think the meaning isn't that the vendor needs to provide future-proof support, it's that if they provide objects or a dynamic library, the end user can theoretically make changes to maintain compatibility [19:08:45 CEST] <Johnjay> so in the case of static linking you couldn't update the library or change it or whatever without the obj files [19:09:04 CEST] <Johnjay> right it's trying to preserve the "4 freedoms" of the GPL [19:09:06 CEST] <JEEB> they're not GPL libraries, they're LGPL if LGPL applies :P [19:09:08 CEST] <Johnjay> i.e. the right to modify [19:09:28 CEST] <JEEB> just a project generating libraries doesn't make it LGPL [19:09:36 CEST] <JEEB> a GPL library is still a GPL library :P [19:09:52 CEST] <JEEB> but yes, that is why FFmpeg is by default LGPL and most of the internals are LGPL [19:10:17 CEST] <Johnjay> so if a library was GPL'd, could you dynamically link to it with your proprietary app? [19:10:30 CEST] <Johnjay> static linking would violate the GPL ofc [19:10:48 CEST] <jbreeden> https://en.wikipedia.org/wiki/GPL_linking_exception [19:12:38 CEST] <Johnjay> that page just says the idea of what I said is not suppoted by legal evidence [19:12:42 CEST] <JEEB> IANAL, but GPL and linking generally is generally noted as the same thing. even if you make the library dload'd if the software doesn't work in meaningful ways without the library it's pretty obvious (also if you're distributing that GPL library) [19:13:03 CEST] <JEEB> if you start wanting to piss off open source developers there's plenty of ways of course [19:13:12 CEST] <JEEB> not that I recommend them :P [19:14:24 CEST] <Johnjay> it says dynamically linking to GPL libraries makes it covered by GPL [19:14:44 CEST] <Johnjay> but how is that different than me calling say gcc from the command line? [19:14:50 CEST] <JEEB> that is my understanding. be it static or dynamic - it's linking [19:16:22 CEST] <JEEB> Johnjay: I'm too tired to go through the details of what the exact thing you're comparing to is and how it is different from making an application that links against a GPL library... [19:16:45 CEST] <JEEB> and under certain circuimstances I'd say that yes, it's very similar if your app is just a layer that calls ffmpeg.c configured with GPL [19:16:55 CEST] <JEEB> and you distribute that GPL ffmpeg.c [19:17:57 CEST] <JEEB> but IANAL [19:18:01 CEST] <Johnjay> yes [19:18:05 CEST] <Johnjay> i'm tired too, gonna go eat now [19:18:11 CEST] <jbreeden> If there's one thing that we can all agree on, it is that none of us are lawyers [19:18:16 CEST] <JEEB> yes [19:18:23 CEST] <Johnjay> lol [19:18:28 CEST] <jbreeden> Thanks for the help, people [19:18:39 CEST] <JEEB> np [19:18:50 CEST] <Johnjay> stallman isn't either, but apparently to him static vs dynamic doesn't matter when it's the GPL: https://softwareengineering.stackexchange.com/questions/167773/how-does-the… [19:19:51 CEST] <JEEB> yes, and I agree with that as far as I know :P the idea of the GPL after all is that if you make a derivative work your work is also GPL (not limited to, but *also*) [19:21:19 CEST] <JEEB> there's a lot of stuff under more permissive licenses for a lot of stuff, if your needs do not match that specific project you have two different ways [19:21:29 CEST] <JEEB> - you explain yourself and possibly start a project of re-licensing [19:21:39 CEST] <JEEB> - you change the GPL dependency to something else [19:21:55 CEST] <JEEB> mpv got to the point where they have the libmpv core licensed to LGPL [19:22:00 CEST] <Johnjay> here's another discussion of the mattera: https://softwareengineering.stackexchange.com/questions/158789/can-i-link-t… [19:22:09 CEST] <JEEB> I know there's a lot of discussion about it [19:22:37 CEST] <JEEB> but what I'm noting is the understanding of it that most people around here (most likely) have. and as I've said countless times, IANAL [19:22:39 CEST] <Johnjay> JEEB: the second link goes into more detail, because there's a lot of ambiguous cases between "calling ffmpeg from an open shell" and "statically linking it into your program" [19:23:21 CEST] <JEEB> well FFmpeg is available as LGPL so it doesn't even have the GPL problem unless you specifically selected GPL as the license [19:23:39 CEST] <JEEB> and yes I know there are more cases but they are basically in three things [19:24:05 CEST] <JEEB> 1) statically linked lib 2) shared linked lib 3) shared library and dload [19:24:41 CEST] <JEEB> first two with GPL are pretty obviously having you as a thing because you're using it [19:25:12 CEST] <JEEB> third one I'd say you're trying to skirt the GPL unless it's something like a framework for something and you have plugins you have no control over [19:25:30 CEST] <JEEB> and someone completely different made a GPL plugin not knowing that GPL for proprietary stuff doesn't exactly work [19:26:01 CEST] <JEEB> so of course in that case even if you load that plugin you have no control over it since you're not distributing it, you're not installing it and you have no connection to it whatsoever [19:26:38 CEST] <JEEB> this all is IANAL just to note it once again [19:34:21 CEST] <JEEB> in the end, if it gets far enough it's not technical people who will decide it but judges based on "the letter and the *spirit* of the law" and "the spirit in which something was done". and if you have to start asking you're already playing with wanting to go against the common understanding of the spirit of what GPL is. and at that point I would already be looking for alternatives since I gain much more in [19:34:27 CEST] <JEEB> the long term by not pissing off OSS developers [19:39:16 CEST] <jbreeden> Sounds reasonable [19:47:30 CEST] <JEEB> jbreeden: btw regarding your case it's usually simpler licensing wise if you just have the encoding part in your own thing part of your thing, and that you don't then need to poke additions into FFmpeg itself for it. that way the LGPL case is simple. but I'd really make sure you've tested the vendor's solution properly before skipping on x264 or x265 (both of which also have non-GPL licensing options if you [19:47:36 CEST] <JEEB> pay) [19:48:15 CEST] <JEEB> although you still might make something similar because the x264/5 modules in libavcodec are generally under GPL configuration only [19:49:13 CEST] <jbreeden> Unfortunately x264/5 don't provide the codec I'm trying to use, which is Annex G of the h264 spec (Scalable Video Coding) [19:49:18 CEST] <JEEB> oh [19:49:24 CEST] <JEEB> interesting, someone actually trying that [19:50:17 CEST] <DHE> oh that's cool... would make grooming very easy [19:50:27 CEST] <JEEB> I think there might have been a patch for that at some point, but I'm not sure. could have been MVC only. [19:50:48 CEST] <JEEB> SVC IIRC was only used by some cisco stuff if I recall correctly [19:51:23 CEST] <jbreeden> It is really neat stuff, after seeing how well it works, it's kinda bewildering that it didn't gain more traction [19:51:47 CEST] <JEEB> I think people generally either add adaptive rate control to their video call stuff [19:51:58 CEST] <JEEB> as in, it adapts according to the connection quality [19:52:18 CEST] <JEEB> or just have multiple alternative video streams of different bit rates / qualities [19:52:23 CEST] <JEEB> (or resolutions) [19:52:41 CEST] <jbreeden> Yeah, but all that HLS/DASH stuff requires quite a bit of technical overhead to do all the switching [19:52:42 CEST] <JEEB> I think part of the problem also was that not a whole lot of things supported decoding it, either [19:53:01 CEST] <JEEB> well yea, they're not really a streaming protocol :P [19:53:13 CEST] <JEEB> it's all due to a) wanting to use the existing HTTP stack b) browsers [19:53:13 CEST] <jbreeden> :D [19:53:21 CEST] <Johnjay> so jbreeden has some nifty codec that is proprietary related to x265 and wanted to make a version of ffmpeg with it statically compiled in and distribute it? [19:53:32 CEST] <JEEB> no [19:53:44 CEST] <JEEB> he wanted to use it somehow and we've discussed alternatives [19:54:11 CEST] <JEEB> I've noted what in my opinion is the simplest way if he requires LGPL FFmpeg features [19:54:14 CEST] <jbreeden> Yeah, I'm trying to make sure I'm conforming to the licensing before digging in deep [19:55:32 CEST] <JEEB> jbreeden: have you made sure that whatever you're planning on suporting actually supports SVC :P [19:55:39 CEST] <JEEB> the support for it after all is not that common [19:55:43 CEST] <jbreeden> lol yes [19:56:04 CEST] <jbreeden> It's an end-to-end solution [19:56:32 CEST] <JEEB> yea, it's just that on mobile etc HW decoding is much more important [19:56:44 CEST] <JEEB> and if that hw decoder doesn't support MVC then that doesn't help :) [20:00:28 CEST] <Johnjay> he also said ffmpeg doesn't provide some x265 codecs [20:00:39 CEST] <Johnjay> is adding codec support a large part of updates to ffmpeg? [20:00:44 CEST] <Johnjay> i would guess it would have to be [20:01:33 CEST] <BtbN> "doesn't provide some x265 codecs"? Last time I checked x265 only supported exactly one codec. [20:01:35 CEST] <JEEB> ok, let's start fixing the incorrectencies which I decided not to go first because jbreeden seemed to know what he was talking about and just using the wrong bocabulary [20:01:41 CEST] <JEEB> s/x265 codecs/HEVC features/ [20:02:13 CEST] <JEEB> and it doesn't support them because those features are not supported in the x265 encoder library. they are not supported because they are no widely seen as anything that brings good gains. [20:02:30 CEST] <JEEB> in this case, it was the scalable video extensions [20:02:57 CEST] <JEEB> which I am honestly surprised someone is trying to sell because of the lack fo support :P [20:07:15 CEST] <furq> does hevc even have svc [20:07:18 CEST] <furq> i thought that was an avc thing [20:07:29 CEST] <JEEB> I think it has it under a slightly different name [20:07:54 CEST] <JEEB> yes, SHVC [20:11:19 CEST] <JEEB> anyways, I've basically over the years discussed things with multiple people from various major video sites - people who do test out proprietary solutions, but so far pretty much only EVE (and maybe Ateme?) have been anywhere near the open source alternatives. SVC wasn't utilized because of most things just not supporting it. [20:12:35 CEST] <JEEB> but I think now Ateme is fully hardware only aiming for the broadcast market [20:13:20 CEST] <JEEB> I have myself only tested a few along the years, although if I had more free time i do have a few lying around :P [20:13:32 CEST] <Johnjay> JEEB: quick question, if I want to split up a file using -f segment but also add silence from anullsrc at the end, how would I do that? [20:14:06 CEST] <JEEB> no idea how to append silence at the end of your input so that video and audio lengths match :) [20:14:14 CEST] <JEEB> (it should be irrelevant to -f segment) [20:14:14 CEST] <Johnjay> it's just audio [20:14:45 CEST] <JEEB> I know how I'd do it with the API, but no idea with the cli [20:15:06 CEST] <Johnjay> yeah i haven't learned how to combine filters yet [20:15:15 CEST] <Johnjay> so i assumed filter_complex does it somehow [20:15:41 CEST] <JEEB> although have you just tried to set -t longer than your actual duration? [20:15:57 CEST] <JEEB> I wonder if there's a way to append stuff... no idea, sorry [20:16:05 CEST] <ChocolateArmpits> there's a concat filter [20:16:28 CEST] <JEEB> yea but this is a "append until X duration" kind of case I guess? for the last segment? [20:16:31 CEST] <JEEB> no idea [20:16:59 CEST] <Johnjay> i just want 10 seconds of silence at the end [20:17:06 CEST] <Johnjay> i've been manually doing it with a file called 10secsilence.mp3 [20:17:15 CEST] <ChocolateArmpits> https://ffmpeg.org/ffmpeg-filters.html#concat [20:17:24 CEST] <JEEB> with the API you could just open the filter chain with anullsrc and get enough samples [20:17:26 CEST] <Johnjay> but i'm not sure how to combine segment and anullsrc filters [20:17:43 CEST] <JEEB> segment is not a filter :) [20:20:00 CEST] <Johnjay> sorry yes it's a muxer [20:20:25 CEST] <JEEB> but yes, if you always need a static amount of stuff then ChocolateArmpits's thing could be useful [20:20:33 CEST] <JEEB> by just concatenating it in all of your workchains [20:20:39 CEST] <JEEB> that way you always get +10 seconds [20:32:05 CEST] <Johnjay> well i'll figure it out later [20:38:18 CEST] <Alina-malina> can i set a download speed from internet with ffmpeg? [20:39:13 CEST] <Alina-malina> i mean set the bitrate of downloading [20:39:18 CEST] <Alina-malina> throttle downl the downloading [20:42:11 CEST] <JEEB> not that I know [20:43:39 CEST] <Alina-malina> :-/ [21:18:46 CEST] <utack> and of course ffmpeg supports opus in whatever this "caf" is...amazing how fast you enabled that after iOs added support for it :D [21:19:12 CEST] <BtbN> It's not officially documented yet [21:19:26 CEST] <BtbN> So can be broken or wrong. [21:19:30 CEST] <utack> i have no idea if it works, but i sent a file to someone with an iphone and they will let me know [21:21:15 CEST] <JEEB> the thing seems to work on QT but seems to blatantly go the wrong way compared to how QT does it [21:21:33 CEST] <JEEB> "I don't know what this thing contains exactly so I'll just not write it" [21:21:40 CEST] <utack> i tried to send it via whatsapp. it got a fancy headphone icon, but then something crashed whatsapp :D [21:21:41 CEST] <JEEB> and it got merged even if more research was requested [21:21:46 CEST] <utack> luckily i managed to delete the message [21:22:01 CEST] <BtbN> It was just pushed without review in the first place. [21:22:04 CEST] <BtbN> I think? [21:22:21 CEST] <JEEB> oh? the discussion looked like it happened before the push [21:22:38 CEST] <BtbN> It was a reply to cvslog iirc [21:27:37 CEST] <JEEB> ah [22:49:30 CEST] <agrantgreen> Can someone help me to understand the error "Failed to inject frame into filter network: Cannot allocate memory Conversion failed!"? Google results are all over the place and refer to issues with flags we don't use. [22:49:37 CEST] <agrantgreen> Exact command incoming... [22:50:15 CEST] <agrantgreen> https://gist.github.com/adamjgrant/3bb5b9a36c0309c3f05e0e9f7153e022 [22:50:37 CEST] <agrantgreen> Essentially we are trying to stitch together a set of images into a video. [23:10:11 CEST] <mbr__> ffplay has the -fflag nobuffer option. Is there a way to specify the buffer size? I think I need just a tiny buffer for a nearest real-time stream [23:20:29 CEST] <AlRaquish> Hello everyone, I have written a script in bash that uses ffmpeg to create a rather complicated effect, and I am wondering if I can do it in pure ffmpeg (or as little bash as possible) [23:20:49 CEST] <mbr__> what is the effect? [23:21:07 CEST] <AlRaquish> So what I want to get is split the video into columns of a given width and have column i have i frames delay [23:21:41 CEST] <AlRaquish> You can see this effect here https://youtu.be/Dw9hjeQhDMY (with rows) [23:22:04 CEST] <AlRaquish> I already have a working script, so I can provide that as well (it is rather ugly though) [23:22:54 CEST] <AlRaquish> Here is my script https://pastebin.com/MSGNcw63 [23:23:55 CEST] <AlRaquish> I essentially cut it into n videos with the given delay, and then stack them back [00:00:00 CEST] --- Fri Oct 20 2017

1 0

ffmpeg-devel.log.20171018
by burek 19 Oct '17

19 Oct '17

[00:01:06 CEST] <Compn> anyways, good email, jamrial :) [00:01:49 CEST] <Compn> nevcairiel : the wild west of software. if its not broke dont fix it. if it is broken, make a new one. [00:05:20 CEST] <cone-250> ffmpeg 03wm4 07master:8a60bba0aef7: avcodec: clarify some decoding/encoding API details [00:05:22 CEST] <cone-250> ffmpeg 03James Almer 07master:a41a5733d1a4: Merge commit '8a60bba0aef77015111570058d5a72f0428dc748' [00:07:27 CEST] <durandal_1707> Compn: on what are you working on? [00:07:36 CEST] <jamrial> BtbN: what do you think of libav commit f6790b5e10? [00:08:14 CEST] <jamrial> mmh, wait, looks like we already have it [00:08:22 CEST] <Compn> durandal_1707 : investing in stock market :) [00:08:35 CEST] <Compn> so i can retire before i hit 35 :P [00:08:37 CEST] <BtbN> jamrial, I'm pretty sure they merged that from us? [00:08:46 CEST] <BtbN> But I'd need to check [00:08:49 CEST] <jamrial> yeah, but it's a bit different [00:09:13 CEST] <durandal_1707> Compn: what exactly? [00:09:33 CEST] <Compn> durandal_1707 : research on stocks and when to buy/sell [00:09:47 CEST] <BtbN> jamrial, 5f44a4a0a97e802479e6ce689d719e5277267f22 is the ffmpeg commit. [00:09:59 CEST] <BtbN> They pretty much merged the logic after that commit [00:10:04 CEST] <jkqxz> Does anything use lavf to mux H.265 to MPEG-TS? [00:10:13 CEST] <durandal_1707> Compn: but you are old, over 50 [00:10:23 CEST] <jamrial> BtbN: ok, will noop it then [00:10:27 CEST] <Compn> durandal_1707 : ?? i'm under 35 :) [00:10:43 CEST] <Compn> durandal_1707 : maybe you confuse me with someone else :) [00:11:14 CEST] <BtbN> jamrial, their logic seems to be very slightly different, but it looks just like style-changes to me [00:11:38 CEST] <durandal_1707> Compn: hmm, maybe i shifted into different universe [00:12:42 CEST] <Compn> my long beard makes me look like an ancient wizard , yes [00:14:01 CEST] <cone-250> ffmpeg 03Konda Raju 07master:f6790b5e1075: add initial QP value options [00:14:02 CEST] <cone-250> ffmpeg 03James Almer 07master:8f2cc2f1e9ef: Merge commit 'f6790b5e1075133ee39be91105f1135db7afd259' [00:23:28 CEST] <nevcairiel> libav commit messages seem to go down in quality as well? =p [00:26:33 CEST] <jamrial> CineformHD decoder commit. it's so heavily refactored the diff is as big as the c file... [00:27:06 CEST] <nevcairiel> better skip it or kierank is going to murder you [00:27:20 CEST] <kierank> if you want all samples to break, yeah merge it [00:27:42 CEST] <jamrial> kierank: so you say i should noop it? [00:28:07 CEST] <kierank> the refactoring isn't too bad but they of course changed a lot of stuff too [00:28:11 CEST] <kierank> and broke tons of samples [00:28:55 CEST] <jamrial> guess i'll merge things like this enum replacing magic numbers, function names and whitespace stuff, then [00:57:05 CEST] <Emerica> kierank Murder? nah..... [01:32:08 CEST] <rcombs> stabbing? [01:47:23 CEST] <cone-250> ffmpeg 03Kieran Kunhya 07master:5f794aa1653a: Add Cineform HD Decoder [01:47:24 CEST] <cone-250> ffmpeg 03James Almer 07master:6007f7d4665e: Merge commit '5f794aa1653aa04c1da7397e9ccacad947fadf5f' [01:48:24 CEST] <jamrial> kierank: merged only some cosmetics, but maybe check your samples to be sure they still work [01:48:53 CEST] <kierank> iirc the definitely hardcoded some values [01:48:54 CEST] <kierank> they [01:49:39 CEST] <jamrial> i skipped the whole refactoring of the main decode function, since finding what they broke there would be too much work [01:50:24 CEST] <kierank> they have hardcoded a coded_format, not sure ffmpeg did that before [01:51:13 CEST] <jamrial> no, i think not [01:51:25 CEST] <kierank> oh it did [01:56:20 CEST] <jamrial> kierank: next commit is a bunch of fate tests. three samples [01:56:33 CEST] <kierank> iirc some of those samples are not even supported [01:56:42 CEST] <jamrial> all three decode here [01:56:45 CEST] <jamrial> with ffplay [01:56:49 CEST] <kierank> ok they changed it then [01:56:57 CEST] <kierank> but there was definitely one they pushed that never actually worked [01:56:59 CEST] <kierank> (lol) [01:57:05 CEST] <jamrial> two are yuv422p10le, one is gbrp12le [01:59:08 CEST] <jamrial> michaelni: can you upload the cfhd folder from libav's fate suite to ours? [01:59:57 CEST] <jamrial> kierank: the one called cfhd_odd.mov might not be working 100%, to be honest [02:00:13 CEST] <jamrial> seems to be a screen capture of a web browser [02:00:31 CEST] <jamrial> but the last row of pixels is blurry [02:01:33 CEST] <kierank> some cropping thing iirc [02:02:38 CEST] <jamrial> yeah, they do seem to have some cropping code i skipped [02:02:54 CEST] <jamrial> you may want to look at it :p [02:20:41 CEST] <jamrial> kierank: https://pastebin.com/9CwN1Bi8 that's a rough "port" of the cropping code in libav's version [02:21:00 CEST] <kierank> looks good [02:46:06 CEST] <michaelni> jamrial, uploaded [02:46:17 CEST] <jamrial> michaelni: thank you [02:49:51 CEST] <cone-250> ffmpeg 03Gyan Doshi 07master:df45ea45df18: doc/filters: add note on flite thread safety and update URL [15:18:48 CEST] <durandal_1707> michaelni: are you happy now? you caused another ffmpeg fork [15:22:28 CEST] <Compn> remember durandal_1707 , we do not all share this sense of jokery. the stresses on some developers are more than other devs and poking people in the eye like this isnt warranted [15:29:26 CEST] <jamrial> JEEB: you should have reminded me you didn't have push rights [15:29:40 CEST] <JEEB> I am just not sure what the procedure is [15:29:54 CEST] <JEEB> I have the pubkey I could give out [15:31:01 CEST] <jamrial> JEEB: you show up in the "has git access" list in maintainers... [15:31:10 CEST] <jamrial> did you send you pubkey to michaelni? [15:31:23 CEST] <JEEB> yea, that's the part which I was unsure of [15:31:36 CEST] <JEEB> so the workflow is to send michaelni the key? [15:32:12 CEST] <jamrial> yes, send him the key, then add the push url to your local git repo [15:33:11 CEST] <JEEB> well, that part is the obvious part :) [15:37:08 CEST] <atomnuker> durandal_1707: its wm4s fault for failing to understand how development works [15:39:50 CEST] <JEEB> alright, got that part rolling [15:43:18 CEST] <durandal_1707> Compn: are you saying that michaelni is most valuable ffmpeg dev? [15:43:32 CEST] <Compn> no [15:43:49 CEST] <Compn> i am saying that singling out developers is not good policy , and goes against the COC [15:44:08 CEST] <jamrial> stop trolling, durandal_1707 [15:44:44 CEST] <Compn> wm4 and michaelni could make some kind of compromise. ideally a 3rd party comes in to fix the issues stated [15:45:06 CEST] <durandal_1707> jamrial: now you are offending me [15:45:23 CEST] <jamrial> i've been calling for third parties on this issue for a while. two showed up but nothing came out of it [15:45:48 CEST] <jamrial> wm4 should send a new thread with a more eye catching subject to get the attention of more people [15:46:42 CEST] <jamrial> "merge cuvid stuff" is not an eye catching subject for it, especially when the issue is about AVFrame usage [15:46:47 CEST] <Compn> we should bribe thilo [15:46:50 CEST] <jamrial> plenty of people ignored it [15:51:10 CEST] <BBB> new fork? [15:51:11 CEST] <Compn> atomnuker : i'm more curious on why someone would send a patch and ignore the review [15:52:04 CEST] <Compn> and then threaten to commit anyways [15:52:09 CEST] <Compn> why not just commit in the first place ... [15:52:28 CEST] <Compn> unimportant i guess [15:52:43 CEST] <BBB> five years ago that was the modus operandi, remember? :D [15:53:01 CEST] <BBB> oh, how things have improved & & ? ... [15:53:06 CEST] <BBB> yikes [15:53:14 CEST] <atomnuker> BBB: wm4 is threatening to have an mpv-ffmpeg [15:53:45 CEST] <BBB> is this the avframe opaque_ref thing? [15:53:49 CEST] <atomnuker> yep [15:53:56 CEST] <Compn> maybe BBB can massage said patch [15:53:57 CEST] <Compn> :P [15:53:58 CEST] <BBB> Ive ignored it, I hate the discussion as its happening there [15:54:18 CEST] <BBB> michaelni: youre acting like a child (and so is wm4) [15:54:26 CEST] <BBB> in that discussion [15:54:30 CEST] <BBB> shame on both of you [15:54:37 CEST] <BBB> blegh [15:55:10 CEST] <Compn> i think its more probable that the pleasantries of english are lost in non-native speakers [15:56:03 CEST] <BBB> I think its up to the speaker to take a conservative approach in responding if english isnt your native language [15:56:10 CEST] <BBB> neither of them is doing that right now [15:56:46 CEST] <thardin> text, vagaries of language hard to communicate, etc [15:57:17 CEST] <Compn> i wouldnt shame anyone in the discussion because they havent really done anything wrong [15:57:28 CEST] <Compn> just two differing opinions [15:58:10 CEST] <Compn> devs could be less emotional, but of course, there is no rule about being emotional :) [15:59:00 CEST] <Compn> devs could do some extra work and work together to solve a problem, that would be nice [15:59:10 CEST] <Compn> but that rarely happens [16:15:37 CEST] <cone-594> ffmpeg 03Diego Biurrun 07master:b57a95d0147b: cfhd: Add FATE tests [16:15:38 CEST] <cone-594> ffmpeg 03James Almer 07master:d2917501c252: avcodec/cfhd: support cropped height tag [16:15:39 CEST] <cone-594> ffmpeg 03James Almer 07master:7293248239c4: Merge commit 'b57a95d0147beae746db1c1223d100447f42dced' [16:20:07 CEST] <cone-594> ffmpeg 03Martin Storsjö 07master:98ee855ae0cc: arm: vp9itxfm: Template the quarter/half idct32 function [16:20:08 CEST] <cone-594> ffmpeg 03Martin Storsjö 07master:3a0d5e206d24: arm/aarch64: vp9itxfm: Skip loading the min_eob pointer when it won't be used [16:20:09 CEST] <cone-594> ffmpeg 03James Almer 07master:60aa56fdf0b1: Merge commit '3a0d5e206d24d41d87a25ba16a79b2ea04c39d4c' [16:38:56 CEST] <cone-594> ffmpeg 03Jan Ekström 07master:247281e80511: configure: add pkg-config check for alsa [16:39:01 CEST] <JEEB> there [16:39:06 CEST] <JEEB> one random user on #ffmpeg made happy [16:39:21 CEST] <JEEB> jamrial: also added comments about static linking (although using pkg-config in general is good (TM)) [16:43:53 CEST] <relaxed> maybe there should be a fate instance where ffmpeg is built statically with the most common external libs [16:47:53 CEST] <jamrial> ubitux had one like that, i think [16:48:13 CEST] <ubitux> yes, but it's a shared one :p [16:48:30 CEST] <jamrial> ah right, archlinux lacks static libraries for most packages :p [16:48:46 CEST] <JEEB> relaxed: I don't disagree. the problem is that currently to build, say, x265, you have to come up that you need libraries that aren't in the pkg-config file (c++ stdlib, math and thread libraries). and then when you start adding additional parameters you might miss breakage [16:48:55 CEST] <JEEB> although the math library is going to be added as global :| [16:49:00 CEST] <JEEB> because so many things miss that one [16:49:03 CEST] <BBB> Compn: I disagree that theyve done nothing wrong, I think for once we should all be able to agree that if the only result of a discussion was that you pissed off the other side, that YES you did something wrong - both sides are guilty of that in this discussion [16:49:30 CEST] <BBB> Compn: one of the goals of any mature, reasonable discussion should always be to not annoy the other side. were all grown-ups here, right? [16:50:15 CEST] <JEEB> jamrial: which reminds me, you had that global math lib patch lying around which I LGTM'd? [16:50:24 CEST] <JEEB> that should fix LAME I think [16:50:27 CEST] <JEEB> "fix" [16:50:32 CEST] <JEEB> that thing doesn't even have a pc file q_q [16:50:37 CEST] <jamrial> JEEB: i'm waiting a bit before applying that [16:50:40 CEST] <JEEB> k [17:44:55 CEST] <winegums> not sure if this is relevant but if I build on macOS 10.12 and I get everything to static link (which I have finally done woo!) it still dynamically links to .frameworks files that seem to be OS based, making it not work when testing on a lesser macOS (such as 10.9) [17:45:02 CEST] <winegums> @JEEB [17:45:35 CEST] <JEEB> well d'uh. if there's something needed from the system then that can't exactly be statically linked can it? [17:45:52 CEST] <JEEB> for macs usually the thing was to build with an older SDK and then use those on newer things as well [17:46:27 CEST] <winegums> yeah i guess building with older SDK makes sense and is what I am trying to do next [17:46:32 CEST] <winegums> but why does it need this: [17:46:37 CEST] <winegums> `/System/Library/Frameworks/CoreImage.framework` [17:46:58 CEST] <winegums> and security.framework [17:50:55 CEST] <JEEB> those should pop up in ffbuild/config.log [17:51:11 CEST] <JEEB> also if they're something uses that is autodetected, you can do --disable-autodetect [17:51:18 CEST] <JEEB> (that's an option nowadays) [17:51:27 CEST] <JEEB> also this ia question for #ffmpeg, not -devel [18:05:04 CEST] <nevcairiel> you can't static link the frameworks, obviously. If you want to target a lower OSX version, you should pass something like --extra-cflags="-mmacosx-version-min=10.9", and the --disable-autodetect option can also get rid of all of them, and allow you to selective re-enable those you want to use [18:23:10 CEST] <winegums> @JEEB ok thanks, and yeah i will move to that channel, sorry I was trying to build for edits made on my end [18:35:21 CEST] <winegums> @nevcairtiel thanks!!!!!!! [19:53:08 CEST] <Compn> BBB : eh, my expectations have been lowered about discorse over these past 2 years in USA history... it certainly does not look like the flamewars of the past [19:53:37 CEST] <BBB> hah [19:53:55 CEST] <BBB> but ignore the country for a bit, we can be a professional bunch of folks, right? [19:57:57 CEST] <Compn> we are all human [19:58:10 CEST] <Compn> thats about all i'm going to commit to. [19:58:10 CEST] <BBB> yes, we are [19:58:15 CEST] <BBB> :-p [19:58:16 CEST] <BBB> o [19:58:17 CEST] <BBB> ok [20:48:02 CEST] <jbreeden> Hello all. I'm interested in developing RTP/RTSP support for H264 Scalable Video Codec(Annex G). Looking for guidance on whether I should modify existing h264 support to include Annex G, or add a new rtpdec module. [20:50:06 CEST] <jkqxz> Are you also intending to write a decoder for it? [20:50:54 CEST] <jkqxz> IIRC the RTP format is quite different to normal H.264, so a separate module is probably right. [20:55:00 CEST] <jbreeden> Unfortunately no, I'm not expert enough to write a decoder. Currently using a licensed, proprietary decoder. Would like to contribute back the pieces that I can, though. [20:59:03 CEST] <jbreeden> RTP for SVC is very much additive to the format for AVC. There are a couple of additional NAL types to handle, but few(if any) changes to handling of existing NALs [21:02:26 CEST] <jkqxz> There are more different packetisation formats, and also the PASCI things. [21:02:45 CEST] <jkqxz> (I should actually go back read it before saying more stuff in case I'm totally wrong...) [21:05:00 CEST] <jbreeden> To my knowledge you are correct, but my point is that they are all represented by additional NALs that are left reserved in RFC3984/6184, rather than modifying the handling of existing types, unless I am mistaken. [21:06:35 CEST] <wbs> I would suggest trying to implement it in the existing depacketizer, and if it doesn't turn out to sensible, try doing it separately [21:09:17 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:624d4739dbfc: cbs_h264: Fix writing streams with auxiliary pictures [21:09:18 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:d792613badfe: h264_metadata: Fix clearing SEI payload in error case [21:09:19 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:41272e112b38: cbs_h264: Fix memory leak in error case [21:09:20 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:03b1470088e6: vaapi_h264: Add missing return value check [21:09:21 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:32a618a948c2: vaapi_h264: Do not use deprecated header type [21:09:22 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:242d8c8763d8: opusenc: Fix double-declaration of variable [21:09:23 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:c37de519202a: vorbis: Reorder conditions to avoid possible overread [21:10:48 CEST] <jbreeden> And another related question- Given that the SVC base stream is compatible with AVC, does it make more sense to add a new codec id for SVC, or to wrangle it into AC_CODEC_ID_H264 with some other mechanism of identifying the difference? [21:11:11 CEST] <jbreeden> *AV_CODEC_ID_H264 [21:18:34 CEST] <jkqxz> Right, looking at that RFC again it probably is right to do it with the same code if possible. (I remember more weird stuff in it for some reason...) [21:24:35 CEST] <jkqxz> Can someone look at CID 1419837 and tell me whether I'm being stupid? [21:26:28 CEST] <jkqxz> "32. assignment: Assigning: crop_unit_y = 1 + (sps->chroma_format_idc < 2). The value of crop_unit_y is now 0." <- Uhh, no. crop_unit_y is definitely either 1 or 2 after that assignment, regardless of the value of sps->chroma_format_idc. [21:26:58 CEST] <BtbN> boolean true is -1 in some variants I think? [21:28:00 CEST] <jkqxz> No. C11 says: "Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.". [21:29:12 CEST] <jkqxz> Some CPU instructions do give you -1 (really, all-ones), but the compiler would know that. [21:43:32 CEST] Action: JEEB wonders how the s302m "decoder" works [21:43:41 CEST] <JEEB> it has an option for "decode if possible else passthrough" [21:43:52 CEST] <JEEB> but I don't see it calling any other decoders or setting formats [21:44:12 CEST] <JEEB> it was just mentioned on a -devel thread regarding compressed audio in PCM [21:44:40 CEST] <JEEB> which is something one of the formats I have been working on happens to have (due to capture card roots) [21:45:32 CEST] <JEEB> so if there's already something that handles the whole "identify compressed format and call decoder" that'd be cool [21:45:42 CEST] <JEEB> or not even call decoder, just note what it is [21:45:51 CEST] <JEEB> so that the API client can then create the proper decoder :V [21:48:30 CEST] <durandal_1707> JEEB: with ffmpeg : no [21:48:38 CEST] <durandal_1707> with api: yes [21:49:27 CEST] <JEEB> well yea, the idea would be that my demuxer would be calling that one or something [21:49:44 CEST] <JEEB> to probe WTF is in the "PCM" stream (AAC or PCM basically) [21:49:49 CEST] <durandal_1707> you need to manually decripple audio in stream [21:50:13 CEST] <JEEB> well as far as I got was demuxing the audio packets and feeding them to the AAC decoder with the "Full" parser [21:50:18 CEST] <JEEB> forcing that worked [21:50:35 CEST] <JEEB> so I will guess that if the s302m "decoder" does its thing that should work [21:50:36 CEST] <cone-505> ffmpeg 03Dave Rice 07master:89cc48551bbe: avdevice/decklink_dec: 32 bit audio support [21:51:22 CEST] <durandal_1707> JEEB: s302m decoder only does pcm stuff [21:51:43 CEST] <JEEB> it has an option [21:51:44 CEST] <JEEB> "decode_copy" , "Decode if possible else passthrough" [21:51:50 CEST] <JEEB> so it doesn't do that? [21:52:07 CEST] <durandal_1707> it cant decode dolby shit [21:52:21 CEST] <JEEB> thankfully I only care about AAC and raw PCM in PCM [21:52:35 CEST] <JEEB> although I guess someone's PS2 captures could have AC3 in PCM [21:52:42 CEST] <jbreeden> @jkqxz and @wbs thanks for the advice, will work on modifying existing rtpdec_h264 [21:52:50 CEST] <JEEB> and yes, I didn't expect it to decode it for me, just tell me "this is X, here's your packet" [21:53:31 CEST] <JEEB> and then I would feed it to the X decoder [21:53:52 CEST] <JEEB> I'm just looking at the code and I don't see it actually doing anything else than parsing some of the stuff in the PCM [21:54:01 CEST] <JEEB> not even setting codec ids [21:54:31 CEST] <JEEB> or wait [21:55:13 CEST] <JEEB> nope [21:55:34 CEST] <JEEB> ... so if s302m is supposed to be for compressed stuff in PCM I am thoroughly confused [21:55:46 CEST] <JEEB> unless you're supposed to then probe the buffer yourself [21:56:35 CEST] <nevcairiel> we have a dolby-e decoder now, but since s302m is a decoder by itself, you would need to chain two decoders, which is not something we can currently do automatically [21:56:46 CEST] <JEEB> I'm fine with that [21:57:06 CEST] <JEEB> also I'm mostly thinking of SPDIF AAC or just raw PCM being the two main use cases right now [21:57:25 CEST] <JEEB> as I want to finish this capture format demuxing with at least audio first. [21:57:38 CEST] <nevcairiel> personally i've only ever seen pcm or dolby-e in s302m [21:57:47 CEST] <JEEB> ok, so s302m is something else [21:57:51 CEST] <JEEB> never mind then [21:58:03 CEST] <JEEB> just noticed it mentioned on -devel regarding compressed audio in PCM [21:58:08 CEST] <JEEB> so I got hopeful :P [21:58:47 CEST] <nevcairiel> i guess there can also be something else in there [21:58:52 CEST] <nevcairiel> but its a rather special format [21:59:15 CEST] <JEEB> I just thought it was the fancy name for SPDIF-like bit streaming [21:59:22 CEST] <JEEB> over raw PCM [21:59:34 CEST] <nevcairiel> isnt SPDIF the name for that =p [21:59:49 CEST] <JEEB> there was some SMPTE spec name for it I think [21:59:54 CEST] <JEEB> and s302m reminded me of that [22:05:04 CEST] <cone-505> ffmpeg 03Marton Balint 07master:f4090940bd30: ffmpeg: always init output stream before reaping filters [22:20:09 CEST] <jamrial> jkqxz: wont you add cbs tests for the hevc rext samples? [22:20:30 CEST] <jamrial> one per type should be enough to increase coverage [22:57:09 CEST] <jkqxz> Yeah. Need to go through and pick some, I'll try to do it soonish. [23:34:17 CEST] <jamrial> michaelni: could you test the merge in https://github.com/jamrial/FFmpeg/commits/mergework? it touches h264/hevc nalu splitting, so even if fate passes I'd rather have some more testing as well [00:00:00 CEST] --- Thu Oct 19 2017

1 0

ffmpeg.log.20171018
by burek 19 Oct '17

19 Oct '17

[00:14:07 CEST] <kepstin> squarecircle: what player, what video codec, what pixel format? [00:14:44 CEST] <kepstin> squarecircle: if this is sampling from your final mp4 file, that's gone through an rgb-yuv conversion, lossy compression, then yuv-rgb conversion in the player, so it's really no surprise... [00:30:39 CEST] <squarecircle> alexpigment: kepstin: http://paste.ubuntu.com/25761768/ [00:33:02 CEST] <alexpigment> squarecircle: the original question still stands, I believe [00:33:12 CEST] <alexpigment> kepstin appears to have the same thought as me [00:33:21 CEST] <squarecircle> alexpigment: about how I'm getting the RGB values? [00:33:25 CEST] <alexpigment> yeah [00:33:27 CEST] <alexpigment> the resultant ones [00:33:33 CEST] <alexpigment> are you playing it in a player and then getting it from that? [00:33:46 CEST] <alexpigment> if so, there are *a lot* of factors that can cause the color to be off [00:34:01 CEST] <alexpigment> i can think of at least 3 that are very common [00:34:06 CEST] <squarecircle> I pipe the raw decoded data in RGB888 Format into a C program [00:34:52 CEST] <alexpigment> gotcha [00:35:00 CEST] <alexpigment> does the C program access the graphics driver at all? [00:35:08 CEST] <alexpigment> in order to read the decoded data? [00:35:16 CEST] <squarecircle> no [00:35:29 CEST] <squarecircle> what do you mean by graphics driver? [00:35:57 CEST] <alexpigment> well, most drivers are set to use either limited or full range of colors [00:36:04 CEST] <alexpigment> 0-255 or 16-235 [00:36:17 CEST] <squarecircle> the c program itself just reads from stdin wich is piped from ffmpeg [00:36:19 CEST] <alexpigment> most of the time when someone says the colors in a video look "off", it's because their driver needs to be changed to display videos as full range [00:36:22 CEST] <alexpigment> k [00:36:23 CEST] <squarecircle> no graphics driver [00:36:31 CEST] <alexpigment> I'm not sure then. I just figured I'd ask [00:36:36 CEST] <squarecircle> no image or graphics stuff [00:36:44 CEST] <squarecircle> just plain mathematics [00:36:53 CEST] <alexpigment> kepstin might have some info about the rgb-yuv conversion that could explain it [00:37:09 CEST] <squarecircle> yeah [00:37:32 CEST] <squarecircle> I guess there will be ever a small offset from the "true" colours [00:37:41 CEST] <squarecircle> if I want to display it as RGB [00:38:00 CEST] <squarecircle> I could also write the C code to read yuv too [00:38:06 CEST] <squarecircle> and save the data as yuv [00:38:34 CEST] <kepstin> well, if you want to preserve colours exactly, then use an rgb codec rather than yuv (e.g. specify 'libx264rgb' when making the video) and consider using a lossless mode [00:39:25 CEST] <squarecircle> and later, if I need it in RGB, I can convert it [00:39:32 CEST] <kepstin> you'll never get exact colours out of an rgb->yuv->rgb conversion in 8bit because the ranges are just different, and if you use a lossy codec there's no reason it has to preserve exact values, it just has to look close enough. [00:39:40 CEST] <squarecircle> kepstin: so I need accuracy for testing purposes [00:40:23 CEST] <squarecircle> I want to create some cases where I can "prove" that my algorithm and the whole program works [00:40:27 CEST] <kepstin> squarecircle: if you need accuracy, use "-c:v libx264rgb -qp 0" when encoding the video. It'll be way larger, but it'll preserve the values exactly. [00:40:39 CEST] <squarecircle> kepstin: thank you very much [00:41:10 CEST] <squarecircle> what does -qp 0 do? [00:41:24 CEST] <kepstin> sets the libx264 encoder to lossless mode instead of lossy mode. [00:41:33 CEST] <squarecircle> great! [00:42:11 CEST] <squarecircle> do you have a estimation for me about how much the conversion will be off? [00:42:22 CEST] <squarecircle> like 5%, 10%, 15%? [00:42:47 CEST] <kepstin> do you mean - how big of an effect the rgb to yuv to rgb conversion would have? [00:42:52 CEST] <squarecircle> so thats "important" later, because I like to have a clue about the error margin [00:42:56 CEST] <squarecircle> kepstin: no [00:43:28 CEST] <squarecircle> kepstin: I have a lot of "raw" data, mp4, mkv, avi and so on files in dozens of awkward codecs [00:43:35 CEST] <squarecircle> kepstin: I convert them all to RGB [00:43:43 CEST] <squarecircle> for comparison reasons [00:43:52 CEST] <squarecircle> but can I even do this? [00:44:12 CEST] <kepstin> squarecircle: unless you have the original source that the video was encoded from, how could you possibly know how far it is off? [00:44:25 CEST] <squarecircle> good point [00:44:46 CEST] <squarecircle> so RGB is just fine :] [00:45:10 CEST] <squarecircle> is there a "finer" colour model? [00:45:20 CEST] <squarecircle> that has a better "resolution"? [00:45:27 CEST] <squarecircle> then RGB888? [00:46:09 CEST] <kepstin> the main thing to do is avoid conversion whenever possible. If you have two random videos, they might both be in yuv420p for example - in that case, you want to compare them in that colour space rather than converting to a different one. [00:46:40 CEST] <squarecircle> kepstin: so keeping the colour space is the best idea [00:46:55 CEST] <kepstin> as far as a higher-precision format, you could use e.g. a 16bit per component rgb or something. [00:47:04 CEST] <kepstin> probably won't really provide much benefit [00:47:08 CEST] <squarecircle> ok [00:47:14 CEST] <squarecircle> thanks a lot [00:48:30 CEST] <kepstin> but if you need to compare across a really wide range of videos, rgb isn't that bad - at least if you use ffmpeg to convert all the videos, it'll do the conversion in the same way on all of them. [00:50:44 CEST] <squarecircle> kepstin: the most part should be yup420p as it is x264 encoded [00:50:48 CEST] <squarecircle> in mp4 containers [00:51:16 CEST] <squarecircle> the probabillity, that it is not yuv420p is quite low, isn't it? [00:54:53 CEST] <squarecircle> kepstin: ? [00:55:32 CEST] <kepstin> yeah, in that case it should all be yuv420p or something isomorphic. [00:57:00 CEST] <squarecircle> is there a way to output the raw data in the respective colour format? [00:58:00 CEST] <squarecircle> "-codec:v", "rawvideo", should print it as raw pixel values, correct? [00:58:36 CEST] <squarecircle> "-pix_fmt", "rgb24", should be replaced with "orginal" or? [00:59:04 CEST] <squarecircle> and what "-f", "rawvideo", does, I have no clue [00:59:06 CEST] <squarecircle> :/ [01:17:20 CEST] <squarecircle> oh yeah [01:19:27 CEST] <squarecircle> if I take "+" as a -pix_fmt value, it takes the sources colour space [01:19:33 CEST] <squarecircle> and theres no conversion [01:23:49 CEST] <squarecircle> alexpigment: https://git.computerwerk.hg.tu-darmstadt.de/goto/chromatography [01:24:01 CEST] <squarecircle> alexpigment: thats the full program [01:29:39 CEST] <Cracki> what's the purpose of that [01:32:38 CEST] <Cracki> it's certainly not that: https://en.wikipedia.org/wiki/Chromatography [01:36:18 CEST] <squarecircle> Cracki: no the name is only borrowed [01:36:53 CEST] <squarecircle> Cracki: it creates a hash based on the average colours of a video [01:42:02 CEST] <squarecircle> I'm off [01:42:12 CEST] <squarecircle> many thanks again! [02:54:15 CEST] <ulf`> Hi [02:55:25 CEST] <ulf`> I have a USB 2.0 webcam as a source for the following raw pixel format: [video4linux2,v4l2 @ 0x960d1e0] Raw : yuyv422 : YUV 4:2:2 (YUYV) : 640x480 352x288 320x240 176x144 160x120 [02:55:48 CEST] <ulf`> Any idea how I can use ffserver to produce an RTP feed ZoneMinder will understand in its monitor configuration? [02:57:23 CEST] <ulf`> Or I should say: How I can produce an RTP feed any media player will understand. So far no luck. [05:39:15 CEST] <mozzarella> guys [07:31:04 CEST] <blap> you need kobaciky mozzarella [07:45:41 CEST] <mozzarella> blap: who's that? [07:46:17 CEST] <blap> it's a form of mozzarella invented in slovakia - pulled into strings and sometimes smoked [07:49:22 CEST] <Xogium> great, now I feel like eating pizza a 2 am XD [07:49:27 CEST] <Xogium> at [07:52:00 CEST] Action: blap decides to make pizza at 7:51 AM. so THERE [07:52:05 CEST] <mozzarella> blap: how can I put a limit on ffmpeg's cpu usage [07:52:50 CEST] <blap> cpulimit [07:55:07 CEST] <mozzarella> blap: how do I use it? [07:56:55 CEST] <blap> i don't know [07:57:01 CEST] <blap> cpulimit ffmpeg bla bla [08:00:34 CEST] Action: blap puts a frozen pizza in the oven and strikes a Power Rangers pose [08:28:10 CEST] <squarecircle> blap: is this stuff also turning into rubber, like the polish smoked cheese? [08:29:20 CEST] <blap> it is rubbery [08:29:31 CEST] <squarecircle> Oscypek [08:29:53 CEST] <squarecircle> :D [08:30:36 CEST] <mozzarella> how can I tell ffmpeg how many threads to use [08:31:11 CEST] <squarecircle> If I choose raw_video as output and yuv420p as pix_fmt, do I get constant 12bits/pixel? [08:31:32 CEST] <furq> mozzarella: you can't set a global limit, but you can set -threads for the decoder and encoder [08:31:48 CEST] <furq> but some encoders will use more threads, plus any filters you use will use additional threads [08:31:51 CEST] <furq> squarecircle: yes [08:34:36 CEST] <squarecircle> furq: thanks [08:34:37 CEST] <mozzarella> furq: how [08:34:50 CEST] <mozzarella> when I use -threads 1 it still uses more than one thread [08:35:31 CEST] <furq> set -threads 1 before -i as well [08:35:51 CEST] <furq> that will still use more than two threads with x264 though unless you turn lookahead off [08:35:53 CEST] <mozzarella> I set it twice? [08:35:56 CEST] <furq> yes [08:36:00 CEST] <furq> once for the decoder, once for the encoder [08:36:12 CEST] <furq> like i said it'll still use more than two threads [08:36:45 CEST] <mozzarella> ffmpeg -threads 1 -i sleep.mp4 sleep_compressed.mp4 -threads 1 [08:36:47 CEST] <mozzarella> like that? [08:37:08 CEST] <furq> output options go before the output file [08:37:29 CEST] <mozzarella> this is so confusing [08:38:42 CEST] <squarecircle> [ACK] [08:38:43 CEST] <squarecircle> :) [08:40:29 CEST] <mozzarella> alright [08:40:33 CEST] <mozzarella> cpulimit seems to work [08:40:35 CEST] <mozzarella> I like it [08:40:38 CEST] <squarecircle> mozzarella: I think its great to remember it like this: ffmpeg [input options] -i input [output options] -o output [08:40:46 CEST] <furq> except without -o [08:40:57 CEST] <squarecircle> furq: ok, why no "-o"? [08:41:07 CEST] <squarecircle> that confuses me since several years now [08:41:14 CEST] <furq> because you can have multiple output files [08:41:26 CEST] <squarecircle> ok [08:41:38 CEST] <furq> it's probably easier to think of it as ffmpeg (input options) -i input (output1 options) output1 [(output2 options) output2]... [08:42:28 CEST] <furq> but yeah, -threads just signals to the decoder/encoder how many threads to use [08:42:35 CEST] <squarecircle> ok [08:42:46 CEST] <furq> ffmpeg is just marshalling those together so it can't really put a global limit on how many threads are used [08:43:19 CEST] <squarecircle> so Wikipedia tells me: YUV420p 6 bytes per 4 pixels, reordered [08:43:22 CEST] <furq> with that said usually the vast majority of your cpu usage comes from the encoder [08:43:49 CEST] <squarecircle> what happens with a 3x3 video? [08:43:58 CEST] <furq> you can't have a 3x3 video with yuv420p [08:44:02 CEST] <furq> both dimensions have to be mod2 [08:44:05 CEST] <squarecircle> ok [08:44:33 CEST] <squarecircle> so its save to read 6 bytes, and get the values for four pixels and go on? [08:44:43 CEST] <furq> right [08:44:56 CEST] <squarecircle> ok, thank you [08:45:59 CEST] <furq> actually, having read the question again, no [08:46:07 CEST] <furq> that would work for a packed pixel format, but yuv420p is planar [08:46:27 CEST] <furq> so it depends what the decoder actually gives you [08:46:42 CEST] <squarecircle> ? [08:47:16 CEST] <furq> if the decoder outputs yuv420p then you get all the Y values for the entire frame, then all U, then all V [08:47:38 CEST] <squarecircle> oh [08:47:48 CEST] <squarecircle> you sure? [08:48:52 CEST] <squarecircle> ok, just read: Y2UV420p is a planar format, meaning that the Y2, U, and V values are grouped together instead of interspersed. [08:48:57 CEST] <furq> right [08:49:06 CEST] <furq> any pixel format in ffmpeg with p on the end is planar [08:49:14 CEST] <squarecircle> ok [08:49:21 CEST] <furq> i don't know if there is a packed 4:2:0 format [08:49:32 CEST] <furq> there are some you might encounter for 4:2:2 [08:49:51 CEST] <squarecircle> later I'll write a script that scans all my raw video data for the pixel formats [08:50:15 CEST] <squarecircle> I guess most stuff is yuv420p [08:50:20 CEST] <furq> probably [08:51:05 CEST] <furq> if you're just reading it from a file then ignore that stuff i said about the decoder [08:51:51 CEST] <squarecircle> ? [08:52:06 CEST] <furq> that would only matter if you were reading the data in flight [08:52:29 CEST] <squarecircle> no, I'm using ffmpeg to convert the encoded video to RAW [08:52:37 CEST] <squarecircle> furq: thats in flight [08:52:56 CEST] <squarecircle> because else I would need to write a container parser and a decoder too [08:53:25 CEST] <furq> you're reading it after it gets written to a file though, right [08:53:33 CEST] <squarecircle> no [08:54:12 CEST] <squarecircle> furq: http://paste.ubuntu.com/25764179/ [08:54:16 CEST] <squarecircle> thats my command [08:54:25 CEST] <furq> yeah that's still more or less the same thing [08:54:38 CEST] <furq> once it's left ffmpeg it'll be the pix_fmt you requested [08:56:17 CEST] <squarecircle> furq: I don't want to converse any pix_fmt, because of information loss [08:57:02 CEST] <squarecircle> furq: so if the source will be a yuv420p file, then I want to have raw yuv420p output [09:06:03 CEST] <squarecircle> furq: ? [09:06:15 CEST] <furq> yeah that's all fine. like i said, ignore what i said [09:06:27 CEST] <squarecircle> what should I ignore? [09:08:28 CEST] <furq> 07:46:27 ( furq) so it depends what the decoder actually gives you [09:08:29 CEST] <furq> just that [09:14:23 CEST] <squarecircle> ok [09:14:24 CEST] <squarecircle> :D [09:14:53 CEST] <squarecircle> thanks you [09:15:16 CEST] <squarecircle> I'll have to work, but I'll care about the project later ;) [09:57:08 CEST] <mozzarella> guys [09:57:28 CEST] <mozzarella> https://i.imgur.com/pAz9gND.png [09:57:31 CEST] <mozzarella> what is this? [09:58:03 CEST] <mozzarella> why does it say suspended [09:58:15 CEST] <rabbe> how do i achive smooth motion with decent quality using rtsp on a local network? gopro -> magewell capturecard -> ffmpeg -> wifi -> vlc on iphone. is there any default settings that work well? [09:59:57 CEST] <rabbe> oh, and i'm also using this: https://github.com/revmischa/rtsp-server [10:00:15 CEST] <furq> mozzarella: i'm guessing that's cpulimit output [10:00:34 CEST] <JEEB> RTSP can be either TCP or UDP, UDP is likely to work less well over various networks [10:00:37 CEST] <JEEB> esp. wireless [10:00:50 CEST] <rabbe> ah, okay [10:01:02 CEST] <rabbe> is rtps over tcp better than rtmp? [10:01:07 CEST] <mozzarella> furq: no, I ran it separately [10:01:14 CEST] <mozzarella> and gave it the pid of the process [10:01:15 CEST] <JEEB> I'd say yes because RTSP at least is standardized :P [10:01:57 CEST] <mozzarella> it's like it has suspended itself but it's still printing to the terminal [10:04:49 CEST] <rabbe> so basically use -rtsp_transport tcp in ffmpeg? [10:05:53 CEST] <Nacht> Hmmm. That new XVC codec sounds nice [10:06:02 CEST] <rabbe> whoa, that made the rtsp server console window go apeshit [10:08:33 CEST] <rabbe> maybe tcp is not supported by that rtsp server [10:08:43 CEST] <stevenliu> HSV HSL which one is used by vf_hue.c ? JEEB [10:08:51 CEST] <JEEB> E_NO_IDEA [10:22:20 CEST] <rabbe> any good free rtsp-over-tcp server suggestions? [11:13:59 CEST] <rabbe> setting an h264 profile.. does that affect any other ffmpeg-parameters, which i will not need to set anymore? [11:14:27 CEST] <JEEB> generally no, other components handle any sort of singaling automagically. [11:15:42 CEST] <rabbe> ok [11:27:01 CEST] <rabbe> does VLC suck on IOS? :) [11:27:15 CEST] <rabbe> (iphone) [11:27:20 CEST] <JEEB> no idea :P [12:00:02 CEST] <flok420> any ideas why this happens: https://i.sigio.nl/961d941ea603e55a6649ef986ebf2fde.jpg I mean the colorfull garbage at the lower half. this is an rtsp stream. it also happens with vlc but not with the original windows software. it is supposed to be a regular h.264 stream. [12:00:29 CEST] <flok420> another example: https://i.sigio.nl/c6fa01a6acba6682160f48b9ec91cd37.png [12:44:08 CEST] <libertas> Hi, from the manual, I try: ffmpeg -i output.mp4 -map 0 -c:v libx264 -c:a copy output_f.mp4 but returns an error saying Unrecognized option 'c:v' and Failed to set value 'libx264' for option 'c:v' [12:44:57 CEST] <libertas> ffmpeg version 0.8.7, Copyright (c) 2000-2013 the Libav developers [12:44:58 CEST] <libertas> built on Oct 10 2017 15:21:15 with gcc 6.3.0 [12:45:25 CEST] <libertas> libav seems to have been deprecated but this is a recent package from my distro, Void Linux [12:45:52 CEST] <libertas> how can I convert the video? [12:50:23 CEST] <JEEB> libertas: most likely the avconv binary would do the job for you, but man that is an old version of either :P [12:50:37 CEST] <JEEB> so I'd just recommend building a newer FFmpeg [12:52:11 CEST] <Fyr> guys, I get: [12:52:11 CEST] <Fyr> >>Application provided invalid, non monotonically increasing dts to muxer in stream 4 [12:52:12 CEST] <Fyr> how do I make FFMPEG convert? [12:53:51 CEST] <JEEB> I remember ffmpeg.c trying to fix the weirdness in MPEG-TS and stuff so you'd need some context about that :P also depending on the output format that is not an error but just a warning [12:54:19 CEST] <Fyr> JEEB, FFMPEG wrote: [12:54:21 CEST] <Fyr> av_interleaved_write_frame(): Invalid argument [12:54:30 CEST] <Fyr> Conversion failed! [12:54:38 CEST] <JEEB> ok, so in your case it was a failure [12:54:41 CEST] <libertas> thanks JEEB [12:55:04 CEST] <JEEB> anyways, I can't say anything about anything generically so if you're not providing info then you might as well go back and herp a derp how FFmpeg is such awful software [12:55:59 CEST] <JEEB> and that you should have bought this big harmonics box instead [12:57:00 CEST] <Fyr> JEEB, https://pastebin.com/rBbfhUSe [12:57:31 CEST] <JEEB> thank you [12:58:06 CEST] <Fyr> the command was: [12:58:06 CEST] <Fyr> ffmpeg -i bob.mkv -map 0 -c:v libx264 -crf 24 -preset:v veryslow -profile:v high -level:v 4.1 -c:a aac -b:a 256k -ac 2 -c:s copy -threads 4 bob-conv.mkv [13:01:50 CEST] <JEEB> I recommend using -v verbose -debug_ts with this thing, but I have a hunch that the input file is borked. [13:02:11 CEST] <JEEB> that should basically give you the timestamps demuxed and then pushed into the muxer [13:02:30 CEST] <Fyr> JEEB, does -report include sufficient verbosity? [13:02:36 CEST] <JEEB> no idea [13:02:44 CEST] <JEEB> I usually just use 2> stuff.log [13:02:55 CEST] <JEEB> which redirects stderr to a file [13:03:22 CEST] <Nacht> Oh man, that -debug_ts option. I love it [13:03:51 CEST] <JEEB> it will spam you but at least you will know at which point timestamps went derp [13:04:08 CEST] <JEEB> Fyr: also you can limit to just the subtitle track that fails if you wish [13:04:30 CEST] <JEEB> since the other tracks are largely unrelated [13:05:36 CEST] <Xogium> erm... So I setup srtp last evening and I left the stream on for a while in my music player before connecting to something else for the night. This morning I try to play the sdp file I got from that other box last evening and I get this despite the fact the stream never stopped: hmac mismatch [13:06:59 CEST] <Xogium> still same size as yesterday, same time for last modified, nothing seems to alterate the sdp file [13:07:51 CEST] <Xogium> if I re-grab the same file from the box it works [13:08:07 CEST] <JEEB> no idea about SRTP [13:08:22 CEST] <JEEB> some sort of authentication fialure [13:08:45 CEST] <Xogium> yep, it compares the hmac of what I got ot its and says it's not good. The file never changed [13:09:10 CEST] <JEEB> well, if there's some time-based message there [13:09:13 CEST] <JEEB> or something else [13:09:15 CEST] <JEEB> I have no idea [13:09:19 CEST] Action: JEEB never has used SRTP [13:09:53 CEST] <Xogium> heh.. Maybe others know what I do wrong [13:12:07 CEST] <Fyr> JEEB, https://gist.github.com/anonymous/b3c56d69c8467eecde6022768c6e7c91 [13:12:12 CEST] <Fyr> full report log [13:13:17 CEST] <Fyr> oh, it's not full. [13:13:24 CEST] <Xogium> nvm, my player now refuses to take that file, but ffmpeg didn't modify it either [13:13:51 CEST] <Xogium> so there must be some time for validity or whatever.. [13:14:22 CEST] <Xogium> if someone who knows about srtp and how it's handled in ffmpeg could explain that would be nice :D [13:19:29 CEST] <Fyr> JEEB, the complete output: [13:19:29 CEST] <Fyr> https://www.dropbox.com/s/mw78fki7y5mi5gs/ffmpeg-20171018-180259.log?dl=0 [13:22:37 CEST] <JEEB> Fyr: becomes shorter if you just map that subtitle stream and only copy it [13:23:06 CEST] <Fyr> I wrote -c:s copy. [13:23:20 CEST] <JEEB> yea but you are handling all the streams :P [13:23:26 CEST] <JEEB> we're only interested in that one subtitle stream [13:23:42 CEST] <Fyr> JEEB, what command do you recommend? [13:23:58 CEST] <JEEB> -map 0:4 -c:s copy? [13:24:07 CEST] <JEEB> *-c copy since you don't map anything else [13:24:41 CEST] <Fyr> why does the first command not work? [13:24:58 CEST] <JEEB> it does, but I won't download 10 megs of logs :P [13:25:45 CEST] <Inge-> I would like to convert still images to video, on an rPi. trying to get ffmpeg to work with GPU hw accelleration on the Pi. Running ffmpeg 3.2.5-1. it contains h264_omx, but complains: libOMX_Core.so not found. Trying to compile from source, I get different complaint: ERROR: OMX_Core.h header not found Tips? [13:49:54 CEST] <berz3rk> can you please help me? I try to use a simple filter with ffmpeg, but when I do it makes the quality of the video worse, halfs the bitrate :( [13:50:05 CEST] <berz3rk> I just want to convert from right to left sbs to left to right sbs [13:50:39 CEST] <JEEB> many video encoders have the libavcodec default of 200kbps or so [13:50:47 CEST] <berz3rk> I used this command : ffmpeg -i 'input.mp4' -map 0:0 -map 0:1 -c:a aac -b:a 320k -vf stereo3d=sbsr:sbsl 'output.mp4' [13:51:11 CEST] <JEEB> check the stderr for which encoder got used [13:51:19 CEST] <berz3rk> my output file has half the video bitrate.. [13:51:39 CEST] <JEEB> the input bit rate really doesn't matter so let's ignore that. [13:51:46 CEST] <berz3rk> ffmpeg -i 'input.mp4' -map 0:0 -map 0:1 -c:a aac -b:a 320k -vf stereo3d=sbsr:sbsl 'output.mp4' [13:51:48 CEST] <berz3rk> oups [13:51:50 CEST] <berz3rk> Lavf57.56.101 [13:51:54 CEST] <berz3rk> is this the encover? [13:51:55 CEST] <JEEB> no [13:52:02 CEST] <JEEB> just post your full stderr in a pastebin.com or similar [13:52:04 CEST] <JEEB> and link here [13:53:11 CEST] <berz3rk> https://pastebin.com/tBdn3yAK [13:53:57 CEST] <JEEB> thank you [13:54:03 CEST] <JEEB> ok, so x264 is used [13:54:14 CEST] <JEEB> in that case the default crf is 23, you can control it with -crf XX [13:54:26 CEST] <berz3rk> what is the highest value for me here [13:55:02 CEST] <berz3rk> ah 0 [13:55:02 CEST] <berz3rk> ok [13:55:04 CEST] <JEEB> no [13:55:07 CEST] <JEEB> wait a moment there [13:55:16 CEST] <JEEB> let me finish what I was writing [13:55:32 CEST] <JEEB> use -vframes 2500 after -i INPUT and -ss SECONDS before -i INPUT to find a spot where you have content and encode about 2500 frames [13:55:38 CEST] <JEEB> start with say crf 21 [13:55:48 CEST] <JEEB> then if that looks good, remove those two and encode the full movie [13:56:05 CEST] <Inge-> In my case, it configred fine if I omitted omx and only included omx-rpi [13:56:14 CEST] <Inge-> now seeing if it will compile [13:56:30 CEST] <JEEB> CRF zero with 8bit is lossless, and that you generally don't want if you want any sort of hardware decoding [13:56:31 CEST] <berz3rk> its a 3d movie so its hard to look if it looks good ;D [13:56:49 CEST] <JEEB> well you were able to tell if it looked bad [14:07:52 CEST] <Xogium> well dang, I guess I'll just have to restart streaming [14:11:57 CEST] <Xogium> been streaming for 13 hours, so I guess the only possibility is a validity time for the hmac but then again I suppose ffmpeg would have written new info into the sdp_file which it didn't [14:18:58 CEST] <paveldimow> Hi, I need a little help to find out am I blind or stupid [14:19:09 CEST] <paveldimow> ffmpeg -i Downloads/sample.mp4 -force_key_frames "expr:gte(t,n_forced*1)" -filter_complex " [0:v] setpts=PTS-STARTPTS [main]; [1:v] movie="Downloads/sample.mp4", scale=iw/3:ih/3, setpts=PTS-STARTPTS [cohost]; [main][cohost] overlay=shortest=1; [0:a][1:a]amix " -c:a aac -c:v libx264 -strict -2 -f mpegts udp://230.0.0.1:5000 [14:19:27 CEST] <paveldimow> [AVFilterGraph @ 0x56306bffbfe0] Too many inputs specified for the "movie" filter. [14:20:36 CEST] <paveldimow> any help highly appreciated [14:32:10 CEST] <Xogium> okaaaay... Just plain weird [14:32:24 CEST] <Xogium> if I restart the stream, it works [14:32:45 CEST] <Xogium> I don't even have to get the new file, the file from last evening works magically [14:33:26 CEST] <Xogium> soooo question is why tell me there's an issue with the hmac after some time if it doesn't change ? [14:35:15 CEST] <blap> who knows something about X and glx [14:37:09 CEST] <blap> answer or the duck gets it! [14:40:38 CEST] <luc4> Hello! Im debugging a weird situation in my player and I notice that after av_seek_frame Im getting AV_NOPTS_VALUES as cur_dts. Is this normal? [14:41:14 CEST] <luc4> *AV_NOPTS_VALUE [14:47:44 CEST] <rabbe> do i need a signaling/stun/turn server to broadcast one-way over LAN? [14:52:21 CEST] <BtbN> what? [14:52:29 CEST] <BtbN> broadcast one-way? [14:52:44 CEST] <rabbe> one cam - many clients [14:53:01 CEST] <BtbN> I'm not aware of any protocol using actual broadcast [14:53:16 CEST] <BtbN> it's always just a simple connection or UDP communication [14:53:25 CEST] <BtbN> There are some that use multicast, but getting that working is annoying [14:53:47 CEST] <rabbe> well, call it whatever. sending video to many clients [14:54:02 CEST] <BtbN> Just setup any streaming server, and connect your clients there. [14:54:12 CEST] <BtbN> The data will go over the wire multiple times though. [14:55:13 CEST] <rabbe> will i need a stun/turn server? [14:55:29 CEST] <rabbe> i'm talking webRTC, sorry.. [14:56:41 CEST] <BtbN> You have a NAT inside of your LAN? oO [14:57:03 CEST] <BtbN> And WebRTC for local streaming is highly unusual and hard to do [14:57:07 CEST] <Xogium> double natting is baaaaad [14:57:13 CEST] <BtbN> It's practically only implemented in Browsers. [14:57:56 CEST] <rabbe> dont know, don't think so.. but the terms come up when u try to learn webrtc [14:58:17 CEST] <rabbe> just think a wireless router to connect a bunch of computers [14:59:07 CEST] <Xogium> if you have a router behind a router then you are indeed doing double nat (unless you turned off nat into that second router) [14:59:14 CEST] <rabbe> "highly unusual and hard to do". u have a better way to stream to an iphone realtime? [14:59:57 CEST] <rabbe> "realtime" = as fast as possible [15:00:38 CEST] <JEEB> fast or low latency? [15:00:45 CEST] <JEEB> those are two distinct things [15:01:16 CEST] <BtbN> I think the iPhone only supports HLS, which has a rather big latency hit [15:01:17 CEST] <rabbe> i want to see the things as soon as they are captured by the camera [15:01:26 CEST] <BtbN> That's hardly possible [15:01:49 CEST] <JEEB> well if you set up your capture + x264 to very low latency and find a way to push UDP packets over your wifi link fast enough... [15:01:53 CEST] <rabbe> yep.. and VLC seems to suck on iphone.. tried rtmp and rtsp [15:02:05 CEST] <aleek> sup! I need to write a Linux app that generates a video stream (may be raw, I can compress it later) with analog speed indicator. The speed will be taken from real time input. You guys have any idea how to do it? I have no idea what to write into google search to read about it :/ [15:02:09 CEST] <BtbN> You're not going to get an iPhone to play UDP stuff sent to it though [15:02:18 CEST] <JEEB> well you'd have to make your own app of course [15:02:31 CEST] <JEEB> I think that's a prerequisite for something like that :P [15:02:31 CEST] <rabbe> no custom apps [15:02:35 CEST] <BtbN> Pretty sure Apps also aren't allowed to do that. [15:02:39 CEST] <BtbN> TCP only [15:02:39 CEST] <JEEB> well vlc is a goddamn custom app [15:02:50 CEST] <rabbe> either a player that exists for all mobile [15:02:53 CEST] <rabbe> or web [15:03:08 CEST] <BtbN> You'll have to accept a big latency hit then [15:03:17 CEST] <rabbe> ;~~( [15:03:28 CEST] <rabbe> but webrtc should be kinda realtime? [15:03:31 CEST] <JEEB> basically if you limit your scope and put effort and/or money into it, you can do it [15:03:37 CEST] <JEEB> stop talking real-time, talk in fucking latency [15:03:45 CEST] <rabbe> :) [15:03:46 CEST] <JEEB> real-time is just "the encoder keeps up in frame rate" [15:04:21 CEST] <JEEB> BtbN: anyways vlc on iphone seemed to be using UDP for RTSP... loldunno, though [15:04:24 CEST] <rabbe> low latency then, mark my words [15:04:52 CEST] <BtbN> JEEB, I wouldn't be surprised if it uses tcp for rtsp, or the iPhones native RTSP implementation, if it has one [15:05:08 CEST] <JEEB> right, it probably has one. it wasn't TCP because this guy's RTSP server derp'd at TCP [15:05:14 CEST] <JEEB> it seems [15:05:21 CEST] <JEEB> if I parsed his lines correct [15:05:21 CEST] <rabbe> yep [15:06:00 CEST] <JEEB> anyways, it's definitely possible to get stuff going, but the scope has to be limited and there most likely are no widely known pre-made things [15:06:17 CEST] <JEEB> since usually such strict requirements require effort/time :P [15:06:17 CEST] <BtbN> You cannot just stream to a browser with WebRTC [15:06:33 CEST] <JEEB> yes, you need to do the base information sharing first [15:06:41 CEST] <JEEB> handshakes and all that [15:06:47 CEST] <rabbe> that web-experiment.com guy seems to have unidirectional webrtc video going [15:06:50 CEST] <BtbN> In theory it's possibly, but you'll have to write the entire "server", which just acts as another browser with a video source, yourself [15:07:06 CEST] <BtbN> There is nothing readily available for that. [15:07:25 CEST] <rabbe> www.webrtc-experiment.com [15:07:49 CEST] <BtbN> And what part of it being called an experiment makes you think it's a good idea to use in production? [15:08:13 CEST] <JEEB> anyways, tl;dr it's possible but you'll have to pour time and effort into it [15:08:17 CEST] <rabbe> all the talk about webrtc being the way forward for video online [15:08:24 CEST] <BtbN> Between Browsers [15:08:27 CEST] <rabbe> ios 11 supports it now etc. [15:08:32 CEST] <BtbN> WebRTC is a gigantic over-engineered highly complex something [15:08:42 CEST] <BtbN> you can't just stream to it without jumping through 20 hoops [15:08:45 CEST] <JEEB> I think at least one game streaming company uses it [15:08:53 CEST] <JEEB> I am not sure if I ever got it working, though [15:08:55 CEST] <rabbe> thats my initial thought also.. but people keep recommending it [15:09:01 CEST] <BtbN> mixer uses it as its ingest protocol. But their own custom written variation of it [15:09:03 CEST] <JEEB> no, it just hits your requirements [15:09:08 CEST] <BtbN> It's called ftl protocol [15:09:15 CEST] <JEEB> BtbN: it's pretty much WebRTC [15:09:21 CEST] <JEEB> (which in turn is pretty much RTP) [15:09:24 CEST] <JEEB> and it's not just ingest [15:09:35 CEST] <JEEB> it also uses WebRTC on the client side if you try switching to it [15:09:52 CEST] <JEEB> rabbe: basically you've been noting the requirements you have and everything people have done is given you currently available *alternatives* [15:10:03 CEST] <JEEB> you will still have to work out how to do it if you really want to succeed in it [15:10:09 CEST] <JEEB> and/or find another way of doing it [15:10:14 CEST] <rabbe> how live is live streaming on youtube etc.? from a guy doing something in front of the camera to the viewers being able to see it? can't be that live [15:10:29 CEST] <BtbN> ~30 seconds delay [15:10:29 CEST] <JEEB> easily tens of seconds [15:10:37 CEST] <Xogium> that's latency, obviously [15:10:51 CEST] <JEEB> yes, latency due to our HTTP-based ways of streaming etc [15:10:55 CEST] <furq> youtube live is still hls thanks to our friends at apple [15:11:09 CEST] <BtbN> Well, it's HLS because there is nothing else [15:11:16 CEST] <BtbN> YouTube uses HLS with mp4 segments [15:11:40 CEST] <JEEB> also I think it's DASH. although I think if you pick the webm dash format it will have extra latency because libvpx can't keep up :P [15:12:00 CEST] <furq> last i checked it was hls for live and dash for everything else [15:12:08 CEST] <furq> i assume they would use dash for live but for iOS [15:12:21 CEST] <JEEB> I checked a random live stream on browser some time ago and it was VP9/DASH [15:12:23 CEST] <furq> but i'm not going to claim to understand google's motivation for doing things [15:12:30 CEST] <JEEB> so they definitely have multiple things around [15:12:36 CEST] <furq> oh really [15:12:39 CEST] <JEEB> most likely HLS for iDevices [15:12:41 CEST] <furq> yeah [15:13:11 CEST] <furq> that must have changed fairly recently [15:13:17 CEST] <furq> either that or firefox is super weird [15:13:25 CEST] <JEEB> not sure when I first started getting it. [15:13:50 CEST] <furq> that makes sense because they obviously would prefer not to use hls at all [15:13:56 CEST] <JEEB> anyways, latency wise something over UDP < something over TCP < something over HTTP [15:14:10 CEST] <JEEB> (greater being greater latency) [15:14:13 CEST] <Xogium> udp is a bit better for latency [15:14:30 CEST] <Xogium> certainly better than http [15:14:54 CEST] <JEEB> well with HTTP you have the problem that none of the browsers are able to keep reading a URL without buffering all of it [15:15:04 CEST] <JEEB> which kills the most obvious way of streaming with an unending HTTP thing [15:15:25 CEST] <JEEB> (as soon as you throw browsers into the mix things get really nasty) [15:15:46 CEST] <BtbN> You can just dump a fragmented mp4 stream into a Websocket and feed it to MSE [15:15:52 CEST] <JEEB> yea [15:15:54 CEST] <BtbN> The problem is, it wants seperate streams for audio and video [15:16:07 CEST] <JEEB> sure, but that really isn't *that* much of a problem [15:16:17 CEST] <BtbN> It has no notion of timestamps [15:16:25 CEST] <JEEB> fragment start DTS [15:16:27 CEST] <JEEB> is a thing [15:16:39 CEST] <JEEB> so when you get a fragment you get it's DTS [15:16:40 CEST] <BtbN> Yeah, but it just doesn't care, you have to make sure you feed it in sync yourself [15:16:55 CEST] <JEEB> sure, now that is specific to those things being awful [15:17:08 CEST] <furq> i'm so glad i've never had a need to do this with low latency [15:17:09 CEST] <JEEB> you made it sound as if there are no timestamps in the fragments :P [15:17:11 CEST] <Xogium> well I got quite a low latency for my audio stream over srtp tbh, not even half a second [15:18:02 CEST] <Xogium> but then again it's from a machine in the lan to another [15:18:20 CEST] <Xogium> still, I don't think I could decrease latency even more [15:20:30 CEST] <JEEB> half a second is quite a bit of latency and with audio only you could get it pretty low [15:20:46 CEST] <JEEB> encoder delay + one sample? [15:20:50 CEST] <Xogium> how should I do ? [15:20:55 CEST] <Xogium> always curious :D [15:21:07 CEST] <JEEB> don't ask me for how because you really need to invest time and effort into these things :P [15:21:15 CEST] <JEEB> and nobody has paid me to do such things yet [15:21:20 CEST] <Xogium> encoded in opus, 20 kbps and frame duration is 20 [15:21:21 CEST] <JEEB> I've just seen some succesful people [15:21:54 CEST] <Xogium> I think it's a bit below half a second [15:22:02 CEST] <Xogium> maybe 250 ms [15:22:25 CEST] <JEEB> also the client always has to be optimized as well in the end [15:22:35 CEST] <JEEB> so that it buffers the absolute minimum [15:22:45 CEST] <JEEB> but yea, it's not something you can do out of the box with a lot of stuff :P [15:22:46 CEST] <Xogium> yep [15:22:53 CEST] <Xogium> in mpv you can try doing --no-cache [15:23:03 CEST] <JEEB> mpv is not a low latency player [15:23:22 CEST] <Xogium> I wonder what is, then.. [15:23:23 CEST] <JEEB> anyways, all I know is that someone had made a medical thing doing UDP streaming with x264 [15:23:31 CEST] <Xogium> wow [15:23:36 CEST] <JEEB> so low latency *is* possible [15:23:43 CEST] <JEEB> but you really need to put effort into it [15:23:46 CEST] <BtbN> No readily made player is designed for low latency [15:23:52 CEST] <BtbN> they all favor smooth playback [15:23:56 CEST] <JEEB> yea [15:24:36 CEST] <JEEB> because when you start going into really low latency it starts fighting with "smooth experience" [15:24:38 CEST] <BtbN> With that low latency, every slight nudge on the network cable might throw you off and drop tons of frames [15:25:28 CEST] <Xogium> there, yet again. Not even an hour after starting the stream I have to restart it again because of hmac mismatch [15:25:51 CEST] <JEEB> then your server might be limiting the access token's lifetime or something [15:25:56 CEST] <JEEB> not much I can say without knowing jack [15:26:05 CEST] <Xogium> I have no server. It's just ffmpeg [15:26:40 CEST] <Xogium> not to mention if I restart the stream the old file from yesterday will work just like it should [15:27:01 CEST] <Xogium> it never changed [15:28:53 CEST] <JEEB> there's no srtpenc.c in libavformat? [15:28:58 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=libavformat;h=03f37e2b4749f5… [15:29:05 CEST] <Xogium> I don't see any option for time validity of the key [15:29:06 CEST] <JEEB> so what your server is is something different? [15:29:30 CEST] <Xogium> it's just pure ffmpeg, no vlc [15:30:06 CEST] <JEEB> well you are still accessing the stream from somewhere, no? [15:30:18 CEST] <JEEB> or do you say that ffmpeg.c is your server? [15:30:52 CEST] <JEEB> there's an rtpenc.c in libavformat, yes [15:31:17 CEST] <BtbN> srtp is an url protocol in lavf [15:31:36 CEST] <Xogium> like ffmpeg -f alsa -ac 1 -i jw:0,0 -c libopus -ac 1 -b:a 20k -f rtp -srtp_out_suite suite -srtp_out_params $(echo "some text"|base64) srtp://ip:port [15:32:09 CEST] <Xogium> and then I grab the sdp info it prints and put them in a file for my player [15:34:42 CEST] <Xogium> still working after 5 minutes.. Trying to see after how much time it will tell me hmac mismatch [15:35:20 CEST] <JEEB> so it fails with something easily testable like mpv? [15:35:36 CEST] <Xogium> yes [15:35:37 CEST] <JEEB> if so, please make a ticket on trac and see if you can get cehoyos to help you out [15:35:51 CEST] <JEEB> if you provide exact command lines it should be possible [15:35:57 CEST] <Xogium> sure [15:36:14 CEST] <JEEB> in the worst case you will get told that you are getting something really simple wrong, but at least you learn that. [15:36:28 CEST] <BtbN> The srtp RFC specifies a key lifetime [15:36:35 CEST] <JEEB> right, I kind of expected that [15:36:36 CEST] <BtbN> the ffmpeg srtp implementation specifies that it does not implement that. [15:36:41 CEST] <JEEB> :D [15:37:19 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/srtp.c;h=f8b686c… [15:38:00 CEST] <Xogium> soooo ? [15:38:07 CEST] <Xogium> :/ [15:38:22 CEST] <BtbN> patches that implement it are welcome I guess [15:38:31 CEST] <Xogium> still working after 10 min [15:38:56 CEST] <Xogium> this is bad.. [15:39:20 CEST] <Xogium> yet again something I'd want to do but since I can't understand the most basic things in programming... :p [15:40:19 CEST] <JEEB> BtbN: so it does support it on the server side but not on client side or? [15:40:58 CEST] <JEEB> since otherwise I'd think things would work if both sides would not implement it [15:42:00 CEST] <Xogium> the message is fairly misleading though, don't you think ? Hmac mismatch... Sounds more like the key is suddenly invalid while it never changed [15:43:22 CEST] <rabbe> anyone tried UV4L? [15:44:09 CEST] <Xogium> or maybe it's just cause I'm not a native english speaker [15:53:08 CEST] <Xogium> key is invalid after 20 mins [15:53:50 CEST] <JEEB> well that means that something updated it :P [15:54:04 CEST] <Xogium> and yet, nothing did [15:54:18 CEST] <JEEB> how do you know? [15:54:39 CEST] <Xogium> nothing changed in the ffmpeg sdp outpout [15:54:44 CEST] <JEEB> anyways, whip up that issue ticket on trac with a simple way to replicate, and see what comes out of it :P [15:54:46 CEST] <Xogium> *output [15:54:52 CEST] <JEEB> that doesn't IMHO mean much [15:55:23 CEST] <Xogium> if I restart stream with exact same command line it will work for 20 minutes again [15:56:05 CEST] <Xogium> if I keep connection open via mpv or whatever above 20 min it will leave me connected, but new connection will be rejected after 20 minutes (i.e: closing mpv after 20 mins and trying to play it again) [15:57:59 CEST] <JEEB> it is great that you test it as much :) [15:58:14 CEST] <JEEB> thus I recommend you make that ticket with all that information so that someone can easily replicate it [15:58:18 CEST] <Xogium> if key had changed I expect ffmpeg to at least write new sdp info so I can send them to client right ? Because right now only way is to restart the stream every 20 mins [15:58:40 CEST] <Xogium> yeah, where should I open that bug precisely ? [15:59:20 CEST] <JEEB> trac.ffmpeg.org [15:59:40 CEST] <JEEB> Xogium: I wouldn't *expect* FFmpeg to update that. expecting things out of software is generally a bad idea [15:59:49 CEST] <Xogium> I'm surely not a programmer, but I like testing stuff :p [16:00:06 CEST] <JEEB> you have two things: ffmpeg.c (your server), and mpv (your client) - both of which in theory should be using the libavformat library from FFmpeg [16:00:14 CEST] <Xogium> well, this means that srtp is bad idea [16:00:36 CEST] <Xogium> mpv, vlc, audacious, they all use it yes [16:00:48 CEST] <Xogium> they all throw the same error [16:01:58 CEST] <Xogium> I'd rather avoid having to restart the ffmpeg stream every 20 mins [16:02:12 CEST] <JEEB> VLC might actually use something else [16:02:32 CEST] <JEEB> also opening that ticket can lead you to noticing something you've poked wrong or whatever [16:02:43 CEST] <JEEB> anyways, I just don't know enough of SRTP [16:02:49 CEST] <JEEB> and it's not exactly hot on the interwebs [16:03:09 CEST] <Xogium> used the official doc for the srtp protocol so unless it's not up to date I did exactly as described [16:03:25 CEST] <Xogium> for ffmpeg that is [16:03:33 CEST] <Xogium> but will still open it [16:04:21 CEST] <ulf`> There IS traffic here [16:04:26 CEST] <ulf`> :) [16:04:42 CEST] <ulf`> I have a USB 2.0 webcam as a source for the following raw pixel format: [video4linux2,v4l2 @ 0x960d1e0] Raw : yuyv422 : YUV 4:2:2 (YUYV) : 640x480 352x288 320x240 176x144 160x120 is my webcam [16:04:49 CEST] <ulf`> Any idea how I can use ffserver to produce an RTP feed ZoneMinder will understand in its monitor configuration? [16:04:53 CEST] <ulf`> Or I should say: How I can produce an RTP feed any media player will understand. So far no luck. [16:06:06 CEST] <JEEB> first of all, drop all hope regarding ffserver, that's not the tool you are wishing for [16:06:25 CEST] <JEEB> rtp should be creatable by ffmpeg.c I think? [16:06:42 CEST] <JEEB> no idea what video format or other parameters that ZoneMinder thing would require :P [16:07:09 CEST] <Xogium> JEEB: yep just like srtp [16:07:20 CEST] <Xogium> which is just the secure version of rtp [16:08:51 CEST] <ulf`> JEEB: so Zoneminder would display a feed that can be opened in a browser as well or so they told me [16:09:08 CEST] <ulf`> here's my ffserver.conf https://pastebin.com/RdKHFN8r [16:09:19 CEST] <JEEB> I have no idea what that is, and don't expect ffserver help [16:09:30 CEST] <ulf`> JEEB: well ffserver is incredibly hard to use [16:09:37 CEST] <ulf`> JEEB: the issue is the camera is remote hooked up to an Edison [16:10:04 CEST] <JEEB> ffserver is also really ugly in API usage so a lot of developers want to get rid of it. [16:10:12 CEST] <ulf`> hehehehe [16:10:15 CEST] <JEEB> in your case it sounds like ffmpeg.c without ffserver would do the job [16:10:38 CEST] <ulf`> JEEB: OK..... [16:10:47 CEST] <ulf`> JEEB: how do I expose a port without ffserver? [16:10:59 CEST] <c_14> ulf`: ffmpeg -f rtp rtp://<destination_ip>:<destination_port> [16:11:08 CEST] <c_14> (input goes before that of course) [16:11:24 CEST] <ulf`> c_14: so I do need to send it to server that does passthrough [16:11:45 CEST] <c_14> you send to your client ip [16:11:49 CEST] <c_14> the thing that wants to watch the rtp [16:12:01 CEST] <JEEB> well Xogium here seemingly was able to create an (S)RTP stream that the client was capable of connecting to :P [16:12:04 CEST] <JEEB> with ffmpeg.c [16:12:07 CEST] <ulf`> c_14: there is nothing listening on that end [16:12:16 CEST] <c_14> well [16:12:19 CEST] <c_14> someone wants to watch the video [16:12:23 CEST] <c_14> otherwise you could just use -f null [16:13:02 CEST] <c_14> rtp isn't really client/server model, the server just blasts out data and whoever it sends the data to can pick it up [16:13:04 CEST] <c_14> or ignore it [16:13:25 CEST] <c_14> (at least with ffmpeg) [16:13:36 CEST] <c_14> I believe there's some rtcp stuff so you can add yourself to the multicast but I can't remember [16:13:48 CEST] <ulf`> Yeah so the client would be Zoneminder [16:13:55 CEST] <ulf`> Which wants an RTP URL to use [16:14:02 CEST] <ulf`> But it has no open port for it [16:14:07 CEST] <c_14> you usually feed it the sdp file [16:14:16 CEST] <c_14> which ffmpeg will give you [16:14:16 CEST] <ulf`> And of course the documentation for how this is done right is terrible [16:14:22 CEST] <c_14> by default on stdout (or with -sdp_file) [16:14:30 CEST] <ulf`> c_14: ah! [16:14:50 CEST] <ulf`> c_14: maybe I try that. Can I set a file limit so that the file doesn't grow beyond a certain size? [16:14:59 CEST] <c_14> and if you want you can serve the sdp file with some sort of server (say http or whatever) [16:14:59 CEST] <ulf`> c_14: or is that not necessary in case of sdp? [16:15:10 CEST] <c_14> the sdp file won't be lager than a few hundred bytes [16:15:17 CEST] <ulf`> cool! [16:15:22 CEST] <ulf`> I will give that a try when I get to work [16:15:25 CEST] <ulf`> Thanks [16:15:35 CEST] <Xogium> c_14: do you know about srtp and how it's done in ffmpeg ? :D just wondering if you may have the same issue as I do or if you know what I could have done wrong [16:15:58 CEST] <Xogium> since it's you that helped me for the most part yesterday [16:16:09 CEST] <c_14> Xogium: I don't know, I wanted to check what you said earlier but haven't had the time yet [16:16:16 CEST] <Xogium> ahah [16:16:19 CEST] <JEEB> basically HMAC errors after 20min or so [16:16:20 CEST] <c_14> I usually just use regular rtp since I control the wires [16:16:39 CEST] <JEEB> and yea, most people use RTP [16:16:47 CEST] <Xogium> well good news is, it takes about only 20 mins of streaming to verify, afaik.. It's case here so probably the same for everywhere [16:16:57 CEST] <JEEB> quite likely :P [16:16:58 CEST] <c_14> I can probably check later tonight [16:18:12 CEST] <Xogium> if you keep your player open for like 30 mins just to be sure, close it and then restart it and give it the same sdp file it will complain about hmac mismatch. Only way is to restart ffmpeg on the other end and suddenly your sdp file will work for another 20 mins [16:20:17 CEST] <Xogium> so good side is it's fairly easy to test [16:20:29 CEST] <Xogium> btw latest ffmpeg, 3.3.4 [16:21:55 CEST] <JEEB> even the releases rolled beyond that now (which most people around FFmpeg don't actually use). but yea, most likely SRTP hasn't changed a dime since :P [16:22:04 CEST] <JEEB> since SRTP is not exactly something with active developers [16:23:01 CEST] <relaxed> Xogium: latest is 3.4 [16:23:13 CEST] <Xogium> aww well dang [16:23:15 CEST] <Xogium> :D [16:23:39 CEST] <Xogium> well at least 3.3.4 is fairly recent :p [16:23:41 CEST] <JEEB> but as I noted, most likely no change in SRTP :P [16:23:49 CEST] <Xogium> probably none [16:26:57 CEST] <Xogium> well I'd use rtp but it's definitely not secure especially if I want to check in when I'm not in the lan [17:00:18 CEST] <Fyr> is there a way to send subtitles to pipe and read those subtitles from it? [17:01:13 CEST] <JEEB> I'd say "why not"? [17:01:21 CEST] <JEEB> something just has to know how to read them [17:01:40 CEST] <Fyr> I'm trying, it writes: [17:01:41 CEST] <Fyr> [ssa @ 0x54799a0] Only SUBTITLE_ASS type supported. [17:01:53 CEST] <Fyr> and: [17:01:53 CEST] <Fyr> [matroska,webm @ 0x50c6020] EBML header parsing failed [17:01:57 CEST] <JEEB> that's because you're not telling it to copy the style [17:02:02 CEST] <JEEB> uhh, not style but the stream [17:02:18 CEST] <JEEB> it's trying to convert to text-based stuff and erroring out since the subtitle type is not text [17:02:31 CEST] <JEEB> subtitles still aren't in AVFrames which is a problem in that sense :P [17:02:38 CEST] <Fyr> JEEB, ok, now I'm stuck with the same error: [17:02:38 CEST] <Fyr> av_interleaved_write_frame(): Invalid argument [17:03:01 CEST] <Fyr> the same error appears even when I'm sending the subtitles through a pipe. [17:03:21 CEST] <JEEB> yes, because the input timestamps either are borked to begin with, or get borked by ffmpeg.c [17:03:31 CEST] <JEEB> which is why I asked you to post a limited log of ffmpeg.c with that track only [17:03:39 CEST] <JEEB> with debug_ts [17:03:56 CEST] <Fyr> well, I pasted the complete log. [17:04:22 CEST] <JEEB> you pasted a link to the 10MiB+ complete log with all streams on dropbox which wouldn't let me easily read it [17:04:37 CEST] <JEEB> and I think you don't get it with curl, either, although that would be :effort: . and yes, I am lazy [17:06:54 CEST] <JEEB> Fyr: but so far it basically looks like a broken stream in a matroska file. not sure how the flying fuck someone muxed it, of course. but it doesn't let you mux it again after you read it without fixing the timestamps [17:07:28 CEST] <JEEB> you might have more luck with something that might fix the timestamp while you're not looking like mkvtoolnix's mkvmerge or something (if just a remux helps) [17:25:27 CEST] <ulf`> c_14: doesn't look like I can define /dev/video0 as an input and an sdp file as an output. How would I do this? :) [17:26:04 CEST] <JEEB> the sdp file thing is a specific parameter for the muxer [17:26:09 CEST] <JEEB> well, "muxer" [17:26:23 CEST] <JEEB> the output is of course something along the lines of "rtp://STUFF" [17:26:33 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [17:26:38 CEST] <JEEB> I recommend ctrl+F'ing that one :P [17:27:43 CEST] <JEEB> oh, it's a global option... "fun" [17:42:22 CEST] <ulf`> JEEB: jesus christ this thing is a beast [17:42:38 CEST] <ulf`> Whover wrote ffmpeg obviously hates humanity [17:43:31 CEST] <JEEB> ffmpeg.c tries to offer access to as many features as possible that are in the libraries [17:45:38 CEST] <zerodefect> I would like to use the ffmpeg C-API to generate an m3u8 playlist. I was successful yesterday using the cmd line, but now looking at the API - I'm not sure what parameters I should pass to 'avformat_alloc_output_context2()' Do I need to only give it a path to an m3u8 file? [17:48:04 CEST] <JEEB> looking at the examples under doc/examples, yes :P [17:48:48 CEST] <JEEB> also there's the documentation on muxing @ https://ffmpeg.org/doxygen/trunk/group__lavf__encoding.html [17:50:09 CEST] <zerodefect> @JEEB, I'm guessing you're referring to a src file? Which one? [17:50:23 CEST] <Xogium> c_14: btw the -srtp_out_suite I use is SRTP_AES128_CM_HMAC_SHA1_80 [17:51:16 CEST] <Xogium> with whatever base64 encoded text you like [17:51:28 CEST] <Xogium> for -srtp_out_params [17:51:58 CEST] <JEEB> zerodefect: I mean there's multiple :P [17:56:03 CEST] <Xogium> at least rtp is really nicely keeping latency low instead of increasing like it did when I was using tcp still, I missed something like 300 packets cause of a small network hickup and latency didn't increase [18:37:29 CEST] <niko1990> Hello everyone :) [18:54:00 CEST] <niko1990> I have a question: I'm trying to record my screen with the following command. If I'm running the bash script manually, everything works fine, but when I let the bash script run by a cron job, shows the following error... https://pastebin.com/wCcHaZS8 [18:55:31 CEST] <JEEB> first of all it seems like you're calling a mismatched ffmpeg.c compared to your libraries [18:55:32 CEST] <jkqxz> "WARNING: library configuration mismatch" indicates that you have some libraries installed which don't match the binary. [18:55:50 CEST] <JEEB> and second of all, you need to quote the 00:... stuff [18:56:07 CEST] <JEEB> because right now it's misunderstanding 00 as the protocol :P [18:56:34 CEST] <JEEB> although wait no. also why is -t before input? [18:56:47 CEST] <JEEB> oh, the input is :0 [18:57:01 CEST] <niko1990> JEEB: yes :) [18:57:19 CEST] <JEEB> can you move the -t after the input? [18:57:38 CEST] <niko1990> yes, I'm going to give it a try =) [18:57:59 CEST] <JEEB> also you are hiding a lot of the logs... I'd recommend -v verbose [18:58:32 CEST] <jkqxz> Does your cron job have permission to connect to the display :0? [19:01:22 CEST] <niko1990> with the -t ... behind the -i :0 command it shows the error: Requested output format 'x11grab' is not a suitable output format :0: Invalid argument [19:02:15 CEST] <jkqxz> That's probably your library mismatch, or maybe cron is actually running a different binary entirely? [19:02:19 CEST] <niko1990> jkqxz: hmm... I'm not sure... how can I find that out? Or how do i give permission to do that? Btw. the cron job is running as root [19:03:24 CEST] <jkqxz> Do you get the same configuration mismatch message when you run it yourself? [19:03:33 CEST] <jkqxz> (And version information and whatnot.) [19:08:08 CEST] <niko1990> Hmm... yes I get the same mismatch... This is the output... [19:08:11 CEST] <niko1990> https://pastebin.com/np1g1RJs [19:18:35 CEST] <jkqxz> "xhost +" disables all access control in X and allows anyone to connect. [19:18:45 CEST] <jkqxz> But you should probably fix the configuration thing first. [19:20:22 CEST] <niko1990> jkqxz: hmm... I just found out, when I'm running the command with sudo in front, I can run it manually and get the same error. So It must be, because root is running it... [20:17:41 CEST] <niko1990> jkqxz: I got it done to fix my config problem :) But I'm still having problems with the xhost + command... How do i use this command the right way? I tried putting it into my bash script before the ffmpeg command like this xhost +root. It gives me the error "xhost: unable to open display "" [20:18:33 CEST] <jkqxz> You need to run it, as you, inside the X session you are going to capture. [20:19:06 CEST] <jkqxz> Then later the command run from cron will be allowed to connect to it. [20:21:40 CEST] <niko1990> jkqxz: Oh... But that would mean, that I can not make it automatically only with a cron job... Is there not another way of dealing with this problem? [20:25:03 CEST] <jkqxz> Run the cron job as your own user? Normally the access control of X prevents other users from connecting. [20:42:00 CEST] <markusl> hi [20:43:19 CEST] <markusl> i'm using ffmpeg to generate several live streams for our university radio (mp3, ogg/vorbis, opus/webm, hls, ...) and it's working great. [20:44:27 CEST] <markusl> now i'm revamping our metadata system. currently we're using icecast's http endpoint to update song info for the playing programme in the mp3 and ogg streams. icecast doen't support this for webm. [20:45:08 CEST] <markusl> is there any possible way to change metadata in a running stream (alsa input, http or chunk output) [20:45:12 CEST] <markusl> ? [20:53:12 CEST] <alexpigment> markusl: does opus need to be inside webm? [20:53:19 CEST] <alexpigment> could you not just put opus in an ogg container? [20:55:12 CEST] <markusl> hmm, I guess it doesn't need to be. right now I simply do progressive streaming to a <audio> element with opus/webm [20:55:52 CEST] <markusl> i'm planning to implement HLS and/or DASH (opus/webm?) for browsers, so icecast won't be involved anymore [20:56:15 CEST] <markusl> but, in browsers I don't need to care about metadata inside the stream [20:56:49 CEST] <alexpigment> well, I know that opus is supported in several containers - mkv, mp4, mpegts, etc - so if webm is the only one giving you problems, it might be worth just using another container [20:56:50 CEST] <markusl> so yeah, offering ogg/opus instead of webm/opus using icecast should work :) [20:57:36 CEST] <Xogium> markusl: icecast doesn't support showing opus metadata on status page [20:59:47 CEST] <markusl> would be nice to have the metadata in players that support it (like VLC, kodi), but otoh kodi doesn't show the ogg and mp3 metadata, maybe i have to research in which containers kodi can show/update metadata at all [21:00:16 CEST] <Xogium> metadata should be sent to players [21:00:32 CEST] <Xogium> but the status page just can't display those [21:02:53 CEST] <markusl> Xogium: ok. but i have no way to update those with ffmpeg? can I maybe generate a (simple) stream w/ only metadata in a 3rd party component that I can merge with the encoded soundcard input? [21:03:22 CEST] <Xogium> not sure tbh, used icecast only with liquidsoap [21:04:05 CEST] <c_14> Xogium: ffmpeg running for 31 minutes with srtp, restarted client still works [21:05:47 CEST] <markusl> afaik VLC can do this, I could try liqudsoap but i'm *very* happy with the ffmpeg encoding pipeline (just a bunch of seperate ffmpeg processes fed through the same dsnoop alsa device) i've been running for the last ~year [21:16:18 CEST] <c_14> Xogium: nvmd, set something incorrectly. trying again [21:19:57 CEST] <Xogium> c_14: no worries :) [22:11:20 CEST] <c_14> Xogium: yeah, the srtp implementation is broken [22:11:31 CEST] <c_14> would require a fix that may or may not be possible in ffmpeg [22:11:34 CEST] <c_14> will have to check [22:11:47 CEST] <Xogium> :'( [22:11:59 CEST] <Xogium> at least it's confirmed.. :D [22:12:35 CEST] <Xogium> very bad I was planning to regularely connect from outside [22:19:22 CEST] <c_14> Or rather, the ffmpeg implementation is just defective and not complete [22:19:34 CEST] <Xogium> that's what I guessed [22:19:35 CEST] <c_14> Since it doesn't actually handle the offer/answer part [22:20:14 CEST] <Xogium> I guess there' no other way to secure rtp ? [22:20:18 CEST] <Xogium> there's [22:36:52 CEST] <c_14> VPN [22:37:00 CEST] <c_14> ? [22:37:23 CEST] <Xogium> at home that is ? [22:37:49 CEST] <c_14> Yeah [22:38:38 CEST] <Xogium> hmm, never set that up but I'll lok about it being on a home made router [22:38:44 CEST] <Xogium> *look [00:00:00 CEST] --- Thu Oct 19 2017

1 0

ffmpeg-devel.log.20171017
by burek 18 Oct '17

18 Oct '17

[00:14:05 CEST] <hanetzer> BBB: I have a radius server running on one of you ;) [00:16:54 CEST] <BBB> very confused [00:17:46 CEST] <hanetzer> BBB: 'Beagle Bone Black' commonly called a BBB :P [00:17:52 CEST] <BBB> ah [00:18:00 CEST] <BBB> like Big Buck Bunny [00:18:08 CEST] <hanetzer> ah, is that why you're nicked that? [00:18:26 CEST] <jamrial> and Better Business Bureau [00:18:39 CEST] <hanetzer> its my understanding that Big Buck Bunny is basically the a/v version of 'Hello World' :P [00:20:10 CEST] <BBB> no, my name is still different [00:20:33 CEST] <hanetzer> ah. [00:20:36 CEST] <BBB> the thing is that if you think about it as chaos theory, many random paths can end up in 3 alphabetical characters like bbb [00:20:38 CEST] <hanetzer> tf is a *.lib file? [00:21:58 CEST] <atomnuker> BBB: indeed, and its not far-fetched to get 'BBC' either [00:22:22 CEST] <hanetzer> hehe. I know of two BBC's [00:22:40 CEST] <atomnuker> so why did the BBC use 'BBCD' as a magic string to identify dirac frames is up to anyone to guess [00:22:49 CEST] <JEEB> lol [00:27:01 CEST] <hanetzer> seriously though guys, wtf are these *.lib files? [00:27:36 CEST] <jamrial> msvc made libraries, i think [00:27:49 CEST] <JEEB> or linker help files I think? [00:28:00 CEST] <JEEB> basically make it simpler to use the built binaries with MSVC [00:32:21 CEST] <hanetzer> ick. [01:35:04 CEST] <hanetzer> jamrial: which commit did you mention above regarding the --enable-pthreads behavior change? [01:38:37 CEST] <hanetzer> looks like ffmpeg-3.3.3 and ffmpeg-3.4 both have the issue where --enable-pthreads doesn't --disable-w32threads [01:46:06 CEST] <jamrial> 8aad209c13c [01:46:12 CEST] <jamrial> first version with it is 3.3, yes [01:49:05 CEST] <hanetzer> jamrial: so, is this something that needs to be fixed on your end or...? [01:50:18 CEST] <jamrial> i think so, yes [01:50:36 CEST] <jamrial> could you open a ticket in http://trac.ffmpeg.org/? [01:52:06 CEST] <hanetzer> jamrial: sure. Currently I'm fixing the aviocat/aviocat.exe issue in gentoo for our 6 in-tree versions of ffmpeg [01:54:21 CEST] <hanetzer> jamrial: you mean 'configure: fail if autodetect-libraries are requested but not found' ? [01:54:57 CEST] <jamrial> yes [03:37:20 CEST] <hanetzer> wb. [06:19:59 CEST] <cone-594> ffmpeg 03James Almer 07master:15b86d3b4aeb: configure: add missing optional dep on libfribidi to the drawtext filter [06:44:07 CEST] <wm4> holy fuck this hole shit makes it seems as if applying my patch would murder michaelni's mother or something [06:44:32 CEST] <wm4> why the fuck do I have to deal this, it's a fucking Libav merge in the first place [06:44:45 CEST] <wm4> it's not my fucking fuck job to justify what Libav does [06:45:36 CEST] <wm4> I'm not ever sending a Libav patch to the fucking mailing list again [06:45:59 CEST] <wm4> because michaelni might come up with fuck bullshit and make a dumb fuck veto [06:46:12 CEST] <wm4> despite Libav having had the commit for half a year and he caring fuck all about it [06:46:25 CEST] <wm4> and would have cared fuck all if it just had been merged [06:50:11 CEST] <wm4> I announced that I'll push in 3 hours [06:50:23 CEST] <wm4> and that's what I'll do [06:52:19 CEST] <jamrial> wm4: please, don't [06:52:23 CEST] <jamrial> wm4: call a vote, or start a new thread that will get the attention of more devs [06:53:07 CEST] <jamrial> don't start a weeklong drama and revert war [06:53:22 CEST] <wm4> why the fuck should I have to call a vote? [06:53:40 CEST] <wm4> tell me one reason why I should go through all this effort for a fucking Libav merge [06:54:39 CEST] <wm4> also if michaelni starts a revert war he can just be ejected from the project [06:54:57 CEST] <jamrial> you don't. but by the time i or anyone reached that point in merges, it would have been noticed and either prevented (like with the bitstream filter) or asked for a revert (like some merges that weren't working) [06:55:40 CEST] <jamrial> s/filter/reader [06:56:28 CEST] <wm4> yeah right [06:56:40 CEST] <wm4> the only reason why this became an issue is because I posted the patch [06:56:49 CEST] <wm4> and michaelni decided to make a problem out of it [06:58:54 CEST] <jamrial> wm4: see 536ac72f46 [06:59:11 CEST] <jamrial> it broke nothing, yet he noticed after it was merged [07:00:20 CEST] <jamrial> so he would have also noticed this change after it was merged [07:03:02 CEST] <wm4> as long as he takes care of keeping cuvid and videotoolbox working [07:03:18 CEST] <wm4> I guess I'll actually delay this commit until cuvid/vt are ready, and then push them all at once [07:03:42 CEST] <wm4> still michaelni should mentally prepare himself that his veto means shit (as it's a merge) [07:07:02 CEST] <jamrial> anwyay, bbl [09:47:49 CEST] <sandreas> Hi. I recently checked current status of mp4 cover art and came across that ffmpeg does not support it atm. Further research lead me to an 4 year old issue (including a patch) https://trac.ffmpeg.org/ticket/2798 - i did not find this code in current master, may i ask if i'm wrong or if someone remembers, why it has not been merged? [10:40:11 CEST] <durandal_1707> lol, michaelni forked ffmpeg from libav [11:46:14 CEST] <wm4> what is this person even thinking [11:46:51 CEST] <nevcairiel> they probably found some static analyzer and thought they would just dump their shit =p [11:47:44 CEST] <nevcairiel> someone should tell them to just send patches [11:47:49 CEST] <nevcairiel> carl can figure that out =p [11:48:13 CEST] <BtbN> Someone should ask him for a complete commandline and output. [11:49:09 CEST] <sandreas> Anyone? [11:50:02 CEST] <wm4> the worst is that the way he pastes the code is unreadable/corrupted [11:51:09 CEST] <sandreas> So if i send a patch that contains the correct cover art mp4 code, it would be accepted? [11:51:29 CEST] <BtbN> If there aren't any issues with it, sure [11:51:34 CEST] <sandreas> (I would try to take the code, check if it works and then submit a well formed patch) [11:51:50 CEST] <wm4> sandreas: you can try, but most patches require at least some further changes [11:52:22 CEST] <BtbN> I vaguely remember there being some issues with covert-art being implemented in a highly insane way, that makes non-hacky patches hard [11:52:25 CEST] <sandreas> Ok... you mean the "amount of change" is to low? [11:52:46 CEST] <BtbN> implemented by the aac/mp3 format [11:54:18 CEST] <sandreas> Well, there is another tool, that does what i needs but i would like to use ffmpeg as only command line tool. I already found a way to integrate chapters and metadata, but coverart is missing atm. Would it help to point the tool out that works? [11:54:29 CEST] <sandreas> Its written in c/c++ i think [11:59:04 CEST] <sandreas> https://github.com/TechSmith/mp4v2 => mp4art is the binary that integrates covers, but i think that this would need much more rework than using a small patch ;) i try my best to submit one [12:01:09 CEST] <sandreas> If some dev just got nothing better planned, i would really appreciate him to take a look at the issue... since i am not a c/c++ dev, the resulting code would be much better i think ;) [12:01:34 CEST] <sandreas> Anyway thank you very much for the support. [12:29:16 CEST] <hanetzer> whelp, got the tools/aviocat\tools/aviocat.exe issue fixed up for gentoo's mingw-w64 :) [15:05:54 CEST] <cone-250> ffmpeg 03Jacek Jendrzej 07master:f685bbcbe87d: avformat: fix build wihout dashenc [19:26:01 CEST] <jamrial> nevcairiel: what do you think of libav commit 81bffae368? [19:35:02 CEST] <nevcairiel> no clue, i'm not a mac person [19:35:40 CEST] <nevcairiel> sounds sensible to fix proper feature detection [19:40:16 CEST] <jamrial> nevcairiel: ok, will merge then [20:15:46 CEST] <cone-250> ffmpeg 03Luca Barbato 07master:81bffae368f3: configure: Check for -no_weak_imports in ldflags on macOS [20:15:47 CEST] <cone-250> ffmpeg 03James Almer 07master:d8f382ce05fa: Merge commit '81bffae368f331b6cd386a814f225a58e3f32f40' [20:58:05 CEST] <cone-250> ffmpeg 03Aaron Colwell 07master:17adcc40adf1: mov: Fix spherical metadata_source parsing [20:58:06 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:236577230051: mov: Ignore old spherical metadata when newer version is present [20:58:07 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:0f8512c4a87b: mov: Validate spherical metadata version [20:58:08 CEST] <cone-250> ffmpeg 03James Almer 07master:82cddf637401: Merge commit '17adcc40adf1f30cba55c9727dabc1365944d32b' [20:58:09 CEST] <cone-250> ffmpeg 03James Almer 07master:9780d5839e12: Merge commit '236577230051ad61ec67fa2d68e817d54232d2a0' [20:58:10 CEST] <cone-250> ffmpeg 03James Almer 07master:552d2cb6f751: Merge commit '0f8512c4a87b89b4694053d8ffda48066ee1da62' [21:35:58 CEST] <cone-250> ffmpeg 03Carl Eugen Hoyos 07master:a3accd0c3768: lavf/cafenc: Allow muxing opus. [21:52:02 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:114324b9e045: mov: Validate cubemap layout [21:52:03 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:6bce6aa17d7f: spherical: Add tiled equirectangular type and projection-specific properties [21:52:04 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:a825980f9f93: mov: Export bounds and padding from spherical metadata [21:52:05 CEST] <cone-250> ffmpeg 03James Almer 07master:251849f06ce3: mkv: Add support for Spherical Video elements [21:52:06 CEST] <cone-250> ffmpeg 03Vittorio Giovara 07master:0429f01e4722: mkv: Export bounds and padding from spherical metadata [21:52:07 CEST] <cone-250> ffmpeg 03James Almer 07master:1b6803b79549: Merge commit 'a825980f9f93af32c719497f9aab1e14248ab471' [21:52:08 CEST] <cone-250> ffmpeg 03James Almer 07master:68727a1dc05c: Merge commit '251849f06ce36ce8dc076e0fca2922119fa7e39e' [21:52:09 CEST] <cone-250> ffmpeg 03James Almer 07master:6c5d6baeede1: Merge commit '0429f01e4722b8e0c3576a4810a16ca8f6dbc4d4' [21:59:22 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:d05444d2c6d9: h264: Add stream constraint values to the common header [21:59:23 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:b1374e925c1c: hevc: Improve stream constraint values in common header [21:59:24 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:6734eef6b8b4: lavc: Add coded bitstream read/write API [21:59:25 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:b4c915f4b3e1: lavc: Add coded bitstream read/write support for H.264 [21:59:26 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:9b0c7aa0e446: lavc: Add coded bitstream read/write support for H.265 [21:59:27 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:686e388bbb6a: lavc: Add coded bitstream read/write support for MPEG-2 [21:59:28 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:9c7d70b49b64: lavc: Add trace_headers bitstream filter [21:59:29 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:a308872b049e: lavc: Add h264_metadata bitstream filter [21:59:30 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:8b26306294ff: lavc: Add h264_redundant_pps bitstream filter [21:59:31 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:03f982bbca42: lavc: Add hevc_metadata bitstream filter [21:59:32 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:278c308ceae6: mpeg12: Add a common function to find the best frame rate [21:59:33 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:569721ac8dee: lavc: Add mpeg2_metadata bitstream filter [21:59:34 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:2e29ca2a9f19: vaapi_h264: Convert to use coded bitstream infrastructure [21:59:35 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:281b68b02659: vaapi_h264: Add support for AUD NAL units [21:59:36 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:0bc7575ced65: vaapi_h264: Add support for SEI recovery points [21:59:37 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:94a404861966: vaapi_h264: Fix CPB/DPB delays [21:59:38 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:00179664bccd: vaapi_h265: Convert to use coded bitstream infrastructure [21:59:39 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:038a51258c4c: vaapi_h265: Add support for AUD NAL units [21:59:40 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:d8928ad6b6e8: vaapi_mpeg2: Convert to use coded bitstream infrastructure [21:59:41 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:809b0402dc91: cbs: Add some read/write tests [22:20:47 CEST] <cone-250> ffmpeg 03Mark Thompson 07master:a6cfc287a06c: Changelog: Add metadata bitstream filters [22:22:16 CEST] <jamrial> jkqxz: :D [23:01:31 CEST] <cone-250> ffmpeg 03Carl Eugen Hoyos 07master:d180fce6c707: lavf/cafenc: Only allow mono and stereo for Opus. [23:28:47 CEST] <durandal_1707> why CE can push without review, michaelni ? [23:34:57 CEST] <jamrial> durandal_1707: he seems to be the author of the caf muxer, if that's what you're talking about [23:36:04 CEST] <durandal_1707> no, he cant be [23:36:55 CEST] <jamrial> check the git log [23:37:02 CEST] <Compn> why is everyone so angry about not following unwritten rules they follow and expect other people to follow? [23:38:47 CEST] <Compn> http://ffmpeg.org/developer.html are the written rules [23:39:19 CEST] <durandal_1707> Compn: you are conspirator [23:39:37 CEST] <Compn> insulting the messenger will not help [23:41:39 CEST] <durandal_1707> so you dont deny it? [23:42:00 CEST] <jamrial> Compn: you should know by now he jokes with stuff like that all the time [23:42:25 CEST] <Compn> okay [23:42:39 CEST] <Compn> hard to tell sometimes when its something angry vs joke [23:43:27 CEST] <jamrial> rule of thumb, don't take him seriously on irc when he uses terms like conspirator, dictator and such :p [23:43:50 CEST] <jamrial> but yes, you're right that there's too much anger lately [23:44:50 CEST] <Compn> durandal_1707 : come to next VDD [23:45:40 CEST] <durandal_1707> Compn: never, you guys stinks bad, really really bad [23:46:15 CEST] <iive> jamrial: jokes are supposed to be funny [23:46:18 CEST] <durandal_1707> useless bug reports [23:46:33 CEST] <durandal_1707> says funny person [23:47:10 CEST] <Compn> so iive : are you working on any other projects ? just curious [23:47:21 CEST] <Compn> anything new and exciting ? [23:47:31 CEST] <durandal_1707> yes on XvMC [23:47:39 CEST] <Compn> ffmpeg is unexciting now that everyone uses it [23:48:17 CEST] <iive> Compn: actually i'm looking what to do next... [23:48:39 CEST] <iive> in the meantime I'm watching some shows i've neglected. [23:49:10 CEST] <durandal_1707> with mplayer [23:49:46 CEST] <Compn> what do you use to playback media, durandal_1707 ? [23:50:05 CEST] <durandal_1707> Compn: C Media Player [23:50:18 CEST] <Compn> its interesting seeing vlc devs use mplayer, mplayer devs use mpv, ffmpeg devs use vlc etc [23:52:12 CEST] <jamrial> i use mpc-hc, and i'll keep doing it until the last version before the project was abandoned is too obsolete that i'm forced to move on [23:52:33 CEST] <iive> doesn't these run only on windows? [23:52:46 CEST] <jamrial> madvr and lavfilters are still in development after all [23:52:53 CEST] <jamrial> iive: yes [23:53:03 CEST] <durandal_1707> yes, thats point, there is wine [23:53:21 CEST] <Compn> durandal_1707 : it looks like a vlc skin on top of ... ffmpeg ? [23:53:23 CEST] <jamrial> i use Win10, though [23:53:59 CEST] <TD-Linux> jamrial, p.s. https://lists.libav.org/pipermail/libav-devel/2017-July/084460.html [23:54:15 CEST] <durandal_1707> Compn: nope, its proper gui [23:54:21 CEST] <BtbN> jamrial, mpc-hc is still maintained? Very slowly, but there was an update not too long ago. [23:54:51 CEST] <nevcairiel> reports of its demise were a bit overrated [23:55:06 CEST] <BtbN> https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/ [23:55:07 CEST] <BtbN> hm [23:55:16 CEST] <BtbN> well, seems like it's actually done for now [23:55:21 CEST] <jamrial> they announced they were stopping development, then people came out of the woodworks to help, but since then it has barely gotten any development [23:55:55 CEST] <jamrial> last bunch of commits are "import new version of third party dependency" [23:56:13 CEST] <nevcairiel> typical open-source, people showed up, wanted to help, but expected to be "managed", and just disappeared again when noone hand-holded them [23:56:24 CEST] <jamrial> TD-Linux: what about that? [23:56:31 CEST] <jamrial> (i wrote that email, btw) [23:56:42 CEST] <BtbN> Well, if it's not getting feature updates, that's fine, as long as the housekeeping is done every once in a while, it remains useable. [23:56:51 CEST] <durandal_1707> im manager and you are all fired [23:57:08 CEST] <nevcairiel> if you are fine with its featureset, then it really doesnt need any major updates [23:57:16 CEST] <nevcairiel> it gets ffmpeg updates through lav anyway [23:57:23 CEST] <TD-Linux> jamrial, oh lol I didn't check. it would have given context to the current status of caf opus understanding... if you hadn't written it [23:57:32 CEST] <jamrial> :P [23:59:34 CEST] <jamrial> but yeah, that's a basic analisys i made of the kuki chunk, but there are still some unknown values [00:00:00 CEST] --- Wed Oct 18 2017

1 0

ffmpeg.log.20171017
by burek 18 Oct '17

18 Oct '17

[08:42:46 CEST] <stevenliu> Hi guys, i get a problem about the vf_hue ./ffmpeg -f lavfi -i color=red -filter_complex "hue=h=90" -vframes 1 test.png the test.png is green, value:0e9400 when i use Canvas try the red color mp4 file: ctx.filter = 'hue-rotate(70deg)'; ctx.drawImage(v,0,0,270,135); the color value is = 005b00, is the hue have problem? [08:43:21 CEST] <stevenliu> I use the WeVideo preview, the color is same with Canvas color [08:58:27 CEST] <blap> my current project - shader all the windows https://abload.de/img/noisebacktjl01.png [09:19:50 CEST] <Nacht> Anyone ever did something with adding transparent bumpers to your video ? [11:58:36 CEST] <lethalwp> i can hwdecode hevc on an rxvega with opensource amdgpu, but on another system with more or less the same driver/ffmpeg/... versions and rx480 i get the following error:[ffmpeg] AVHWFramesContext: Failed to create surface: 14 (the requested RT Format is not supported). [11:59:00 CEST] <lethalwp> could this be some kind of bug? should i try with a git ffmpeg on both systems? [12:04:46 CEST] <jkqxz> This is 10-bit H.265? Probably an older Mesa without 10-bit support. [12:05:42 CEST] <lethalwp> jkqxz, yes 10bits, ok will check mesa (mpv maybe got statically linked..) thx for the hint [12:07:43 CEST] <lethalwp> jkqxz, my mpv is dynamically linked for mesa and use "ii libgl1-mesa-glx:amd64 1:17.3~git171011125800.b20bccb~x~padoka0" [12:09:43 CEST] <jkqxz> Paste the whole log somewhere? [12:47:47 CEST] <Fyr> guys, I can't find description of -bf option. what does it do? [12:50:14 CEST] <furq> b-frames [12:50:43 CEST] <furq> it's an encoder private option but it's shared by (presumably) every encoder that supports b-frames [12:50:52 CEST] <Fyr> oops [12:51:07 CEST] <Fyr> perhaps, this option should be added to the documentation. [12:51:22 CEST] <furq> it is [12:51:24 CEST] <furq> https://www.ffmpeg.org/ffmpeg-codecs.html [12:51:30 CEST] <furq> it's there with the other encoder private options [12:51:47 CEST] <Fyr> I've grepped http://ffmpeg.org/ffmpeg-all.html [12:51:57 CEST] <furq> search for "bf", not "-bf" [12:52:36 CEST] <furq> that page is also missing a lot of encoders [12:52:44 CEST] <furq> you're better off using -h full or -h codec=libx264 or whatever [12:53:25 CEST] <Fyr> -h encoder=h264_nvenc [12:53:30 CEST] <Fyr> it lacks of it. [12:54:20 CEST] <furq> http://vpaste.net/cf8U5 [12:54:44 CEST] <Fyr> yes, no bf there. [12:55:26 CEST] <furq> shrug [12:58:05 CEST] <uorbe001> Hi, we are trying to create videos with ffmpeg on the fly and pipping those to http clients. We have this working for desktop browsers and android, but we've hit a roadblock with ios. We've come to the conclusion that the problem we have with ios is that when the video isn't served with a byte-range header, it just refuses to load it (and we don't know the byte-range because we don't have the full-video when served). [12:59:16 CEST] <uorbe001> we are wondering if it is calculate to generate the length of the video with ffmpeg before the video itself is created, does anyone know? Or an alternative solution to the problem if someone has gone through it before? [13:02:55 CEST] <c_14> uorbe001: sounds like you wanted chunked http [13:03:02 CEST] <c_14> -ed [13:12:30 CEST] <uorbe001> c_14: you might be right, I haven't looked at chunked http yet, gotta check with my coworker if he has. [13:32:52 CEST] <Fyr> guys, is it possible to use two-pas encoding with NVENC? [13:33:01 CEST] <Fyr> google gives something incomprehensible. [13:35:30 CEST] <Fyr> >>"-rc vbr_2pass -rc-lookahead [13:35:30 CEST] <Fyr> 32" to the command line. The encoder cannot actually do two full passes, but it [13:35:30 CEST] <Fyr> can look ahead up to 32 frames, which acts as a substitute for 2-pass encoding [13:35:30 CEST] <Fyr> and can improve the picture quality a lot especially around I-frames. [14:05:33 CEST] <BtbN> Fyr, nvenc does not support twp pass encoding. [14:06:09 CEST] <Fyr> -h encoder=h264_nvenc hase options like -2pass 1 and -rc vbr_2pass [14:06:13 CEST] <Fyr> ='( [14:08:24 CEST] <furq> yeah nvenc decided to call lookahead "2-pass" [14:08:37 CEST] <furq> because apparently they suffered some kind of terrible head trauma [14:09:00 CEST] <Fyr> is there a way to imporve quality with NVENC? [14:10:26 CEST] <furq> probably -preset hq [14:10:37 CEST] <Fyr> ='( [14:10:45 CEST] <Fyr> it brings nothing. =( [14:10:50 CEST] <furq> maybe -preset slow is better [14:11:18 CEST] <furq> nvenc is never going to be able to compare with x264 [14:12:02 CEST] <BtbN> That's some other kind of two-pass. Not encoding in two passes. [14:12:34 CEST] <BtbN> if you want good quality from nvenc, you need to throw more bitrate at it [14:13:01 CEST] <furq> are there docs somewhere about what the presets actually enable [14:13:16 CEST] <BtbN> Only the ones ffmpeg made up [14:13:19 CEST] <furq> i assume slow enables AQ and stuff [14:13:21 CEST] <BtbN> which is just slow/medium/fast [14:13:32 CEST] <BtbN> The ones coming from the driver are pretty much opaque [14:14:01 CEST] <furq> fun [14:14:33 CEST] <furq> Fyr: you should probably manually enable b-adapt, aq etc just to make sure you're not missing anything [14:14:49 CEST] <Fyr> ok [14:15:45 CEST] <uorbe001> c_14: I just checked and it appears ios wants the range to be provided even if using the chunked transport encoding, so unless I misundertood what you mean I'm back to needing the size of a video we haven't yet finished generating :(. Thanks for the suggestion though. [14:16:59 CEST] <furq> that doesn't sound right [14:17:07 CEST] <furq> the whole point of chunked is for when the response size isn't known [14:17:32 CEST] <c_14> uorbe001: yeah, but you know the range for each chunk [14:20:28 CEST] <uorbe001> Oh, you are both right, the range header doesn't need the full size (got mixed up with the content-range), we might be able to make that work then. [14:20:44 CEST] <uorbe001> Thanks, will try that! [14:27:33 CEST] <stevenliu> furq: ping [14:28:03 CEST] <stevenliu> http://bbs.chinaffmpeg.com/a.html i get a problem about the ffmpeg avfilter hue [14:28:46 CEST] <stevenliu> the result different with chroma/firefox canvas filter [15:17:02 CEST] <Xogium> so, trying to encode from alsa to rtp, I used this command like: ffmpeg -f alsa -i hw:0,0 -acodec libopus -ac 1 -b:a 20k -re -f rtp rtp://234.5.5.5.5. However despite this I get that message: [alsa @ 0xaaaade80b240] cannot set channel count to 2 (Invalid argument). Why is it trying to use 2 channel when I asked -ac 1 ? [15:17:39 CEST] <Xogium> my mic is mono only so obviously 2 channels will fail [15:27:59 CEST] <Xogium> seems like no matter what value I set the -ac option to, it's completely ignored [15:28:35 CEST] <DHE> you're confusing the inputs and outputs [15:28:35 CEST] <Xogium> I tried 3.1 or even 6 for fun, still I see ffmpeg trying to use 2 [15:28:39 CEST] <Xogium> hmm [15:28:48 CEST] <DHE> ffmpeg [input-options] -i input1 [output-options] output1 [15:28:56 CEST] <DHE> you put "-ac 2" into the output-options side [15:28:58 CEST] <Xogium> so where should I put that ? Before the -acodec option ? [15:29:11 CEST] <DHE> it'll have to go before -i hw:0,0 [15:29:17 CEST] <Xogium> oh [15:29:19 CEST] <BtbN> you should also use -c instead of the old acodec/vcodec [15:29:37 CEST] <Xogium> I thought input option were not finished until the -acodec part [15:29:49 CEST] <BtbN> the acodec is an output option. [15:30:00 CEST] <Xogium> right [15:31:54 CEST] <Xogium> is the rest of my command line fine then ? I used -c instead of -acodec [15:32:30 CEST] <Xogium> also I guess ffmpeg can't do srtp ? [15:33:07 CEST] <zerodefect> There has been work happening on srtp. Not sure how far along it is :) [15:35:04 CEST] <zerodefect> Here is something from 2014: https://stackoverflow.com/questions/21433027/using-ffmpeg-for-stream-encryp… [15:35:30 CEST] <zerodefect> That individual was perhaps unsuccesfful, but I'd be amazed if it doesn't work. [15:37:01 CEST] <Xogium> I tried -f srtp and srtp::// address but doesn't seem like it's a suitable protocol [15:48:08 CEST] <Xogium> also using a :1234 at the end of the url is the correct way to specify a port or not ? Guess not sinc ffmpeg is using 38686 and 38687 [15:48:22 CEST] <Xogium> *since [16:02:54 CEST] <DHE> also, don't use -re. your source material (physical hardware capturing real-time events) is already going to cause a real-time bottleneck [16:06:02 CEST] <Xogium> okay [16:06:31 CEST] <Xogium> I still can't figure the whole rtp range and port stuff either [16:08:49 CEST] <fred1807> I am creating a slideshow using https://trac.ffmpeg.org/wiki/Slideshow. Generated movies plays fine on desktop VLC, but omxplayer acused of bad framerate , and wont play it. Can I improve framerate information? [16:09:00 CEST] <fred1807> used: ffmpeg -framerate 10 -pattern_type glob -i '*.jpg' -c:v libx264 -pix_fmt yuv420p out.mp4 [16:27:03 CEST] <Xogium> so I tried to use the ports that I see in ss -tulp in vlc, both refuses to play anything, same for my attempt at using port 1234 [16:28:28 CEST] <c_14> Xogium: IPv4 addresses have 4 octets, not 5 [16:28:37 CEST] <c_14> also, ffmpeg will output the sdp info on stdout [16:28:41 CEST] <c_14> the client needs that [16:29:16 CEST] <Xogium> with this exact formatting ? [16:29:34 CEST] <c_14> yeah [16:29:38 CEST] <c_14> usually as a file input [16:29:52 CEST] <c_14> you can use the -sdp_file option to write the info to a file instead [16:30:50 CEST] <Xogium> mmh, alright, let's try this [16:36:40 CEST] <c_14> And srtp should work just fine as well, needs -f rtp srtp:// as well as an -srtp_out_suite and -srtp_out_params [16:37:52 CEST] <Xogium> meh, vlc doesn't list the sdp file [16:40:25 CEST] <Xogium> and if I force it to take it it doesn't play [16:41:33 CEST] <Xogium> I'll try to see why.. [16:41:38 CEST] <c_14> https://wiki.videolan.org/SDP [16:41:40 CEST] <c_14> *shrug* [16:43:28 CEST] <Xogium> I'm flooded with gtk errors that makes it impossible to read anything else [16:45:01 CEST] <c_14> try using mpv [16:45:04 CEST] <c_14> that works for me [16:45:13 CEST] <c_14> if that works, then the problem is somewhere in vlc [16:46:24 CEST] <Xogium> so mpv <sdp file> ? [16:47:50 CEST] <Xogium> error reading packets from lavf [16:48:39 CEST] <Xogium> do I need something else to be open apart from udp port 1234 ? [16:48:54 CEST] <Xogium> open to outside, that is.. [16:49:31 CEST] <c_14> yeah, port+1 [16:49:46 CEST] <Xogium> so 1235 as well ? [16:49:52 CEST] <c_14> yes [16:50:04 CEST] <Xogium> aww, rtp seems very complicated [16:51:27 CEST] <Xogium> errr, same error [16:51:39 CEST] <c_14> what's your current ffmpeg command? [16:52:49 CEST] <Xogium> ffmpeg -f alsa -ac 1 -i hw:0,0 -c libopus -b:a 20k -ac 1 -f rtp rtp://10.0.0.1:1234 -sdp_file sdp.input [16:54:54 CEST] <Xogium> but I definitely don't see ffmpeg binding to port 1234 in udp, only port 40514 and 40515 [16:55:45 CEST] <Xogium> yet it generates sdp with port 1234 [16:57:33 CEST] <Xogium> I even tried to set the rtcpport to 1235, nada [16:57:44 CEST] <Xogium> still doing as it wants :D [16:57:58 CEST] <Xogium> that is, completely choosing ports to bind to at random [16:58:01 CEST] <c_14> is 10.0.0.1 the local or the remote address? [16:58:15 CEST] <c_14> rtp is a push protocol, not a pull protocol [16:58:21 CEST] <c_14> you have to send to the remote address [16:58:29 CEST] <Xogium> it's the machine from where I run that ffmpeg command [16:58:40 CEST] <Xogium> hmm [16:58:45 CEST] <c_14> you have to put the address of the machine you're sending it to [16:58:53 CEST] <c_14> (this is usually a multicast address) [16:58:53 CEST] <Xogium> so I'd have to send to my laptop in this case [16:59:03 CEST] <Xogium> or not [16:59:45 CEST] <c_14> if you want to watch it on your laptop, you need to put your laptop's ip [17:00:49 CEST] <Nacht> *listen [17:00:58 CEST] <Xogium> hmmm, I will try that :D I'll understand how it really works someday [17:01:16 CEST] <Xogium> this is very confusing for me, first time I mess with that [17:01:27 CEST] <Nacht> Xogium: What are you trying to create then ? [17:02:42 CEST] <Xogium> oh not something real pro, just trying to learn new stuff and get the lowest latency possible (that is while audio is still understandable and not too messed up) [17:03:10 CEST] <Xogium> someone suggested me rtp so I'm trying that route [17:05:26 CEST] <Xogium> oof, I, finally, got it :D [17:06:02 CEST] <Xogium> but I'll need to amplify the audio on the fly, is this doable with ffmpeg ? Add some gain, I mean [17:07:27 CEST] <iwkse> hi, I have some issues with cutting slices with ffmpeg. I have mp4 files (downloaded from youtube) and when I cut slices audio is out of sync. I've tried the aresample filter but it doesn't seem to work. I notice though, vlc shows it in sync but mplayer not. Any hint? [17:08:20 CEST] <iwkse> Xogium: you can use filters [17:08:36 CEST] <Xogium> kay, looking into it [17:08:44 CEST] <Xogium> thanks all :) [17:08:49 CEST] <iwkse> Xogium: http://ffmpeg.org/ffmpeg-all.html#loudnorm [17:09:09 CEST] <iwkse> http://ffmpeg.org/ffmpeg-all.html#dynaudnorm [17:10:08 CEST] <Johnjay> why would cutting slices cause desyncing of audio ? [17:11:38 CEST] <iwkse> Johnjay: I don't know yet [17:14:05 CEST] <Xogium> very interesting, it introduces an *extremely* high latency with loudnorm [17:18:13 CEST] <Nacht> doesn't -af volume just do the trick ? [17:19:38 CEST] <Xogium> heh, could do maybe.. Loudnorm is nice though but I guess it needs time to do its work [17:24:04 CEST] <Xogium> yeah volume seems to do it [17:25:48 CEST] <durandal_1707> volume may introduce clipping and distort audio [17:27:47 CEST] <Xogium> nods, being careful with it, but loudnorm introduces like 15 seconds of latency [17:42:15 CEST] <alexpigment> Xogium: normalization always introduces delay because it requires looking at the context of other volumes around it; it can't be done on the fly [17:42:23 CEST] <alexpigment> it sounds like you need to use a compressor [17:47:45 CEST] <Xogium> yeah I'm looking at other filters [17:50:13 CEST] <Xogium> mic volume is too low even with the gain set to its max in alsamixer :O [17:50:19 CEST] <Fyr> guys, is hdmv_pgs_subtitle a video format? can I pipe it? [18:02:32 CEST] <alexpigment> Xogium: acompressor [18:02:54 CEST] <alexpigment> https://ffmpeg.org/ffmpeg-filters.html#acompressor [18:03:29 CEST] <Xogium> there is just so much things it can do, this software is amazing :D [18:04:43 CEST] <WeiJunLi> im checking ffmpeg source code and im wondering if user can control the struct pointers *avctx and *avpkt [18:04:56 CEST] <WeiJunLi> stands for AVCodecContext struct [18:04:59 CEST] <WeiJunLi> and AVPacket struct [18:05:09 CEST] <WeiJunLi> do user control struct member values on both cases? [18:13:59 CEST] <WeiJunLi> anyone? [18:16:14 CEST] <ChocolateArmpits> WeiJunLi, can you repost your problem, just got here [18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: im checking ffmpeg source code and im wondering if user can control the struct pointers *avctx and *avpkt [18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: stands for AVCodecContext struct [18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: and AVPacket struct [18:16:29 CEST] <WeiJunLi> 17:05 WeiJunLi: do user control struct member values on both cases? [18:16:41 CEST] <ChocolateArmpits> oh can't help there, sorry [18:41:10 CEST] <blap> nice nickname [18:43:57 CEST] <DHE> WeiJunLi: read avcodec.h or use the documentation viewer. the fields are described and specified whether they are meant to be read, written, or in what situations. [18:44:21 CEST] <DHE> usually there's an indication of what is even intended to be public API and where the line between public and private is [19:06:32 CEST] <WeiJunLi> DHE: tks [19:07:53 CEST] <squarecircle> heyo [19:09:06 CEST] <squarecircle> I created a test video from pure green RGB(0,255,0) png files [19:09:39 CEST] <squarecircle> but ffmpeg reads them as (0,255,1) [19:09:50 CEST] <squarecircle> any idea where to search? [19:15:55 CEST] <JEEB> just out of interest, how did you test and did you make sure your test didn't include any colorspace conversions [19:16:09 CEST] <squarecircle> so RGB(255,0,0) becomes RGB(254,0,0) [19:16:14 CEST] <squarecircle> JEEB: no [19:16:23 CEST] <squarecircle> JEEB: that may be a problem [19:16:36 CEST] <squarecircle> Ill post my encoding and my decoding [19:17:19 CEST] <JEEB> just pastebin the full command line and terminal output onto a pastebin and link here if you're using the command line application [19:17:35 CEST] <squarecircle> JEEB: thats not possible ^^ [19:18:23 CEST] <JEEB> well then there's not really much for me to help with [19:19:11 CEST] <squarecircle> JEEB: I call ffmpeg in a python subprocess [19:19:19 CEST] <squarecircle> JEEB: feed it into my decoder [19:19:24 CEST] <fred1807> any tip how could I fix a slideshow movie in mp4 container, so this raspberry pi's omxplayer wont complain and just play it? [19:20:19 CEST] <JEEB> squarecircle: well you still are capable of receiving the stderr in python [19:20:52 CEST] <JEEB> fred1807: I don't think you can fix it much more if the MMAL decoder just gives up on it, unless you re-encode it :P [19:21:04 CEST] <JEEB> I would first though try it out with FFmpeg+mpv built with MMAL/rpi stuff [19:21:13 CEST] <JEEB> then if that fails you can try re-encoding [19:25:17 CEST] <fred1807> not a codec problem... [19:25:30 CEST] <fred1807> problem seems to be with the container [19:25:49 CEST] <fred1807> I am playing with omxplayer [19:47:30 CEST] <koyglreg> When converting color spaces - say you're going from 4:2:0 to 4:4:4 - are there different algorithms for this? [19:48:09 CEST] <koyglreg> Is it like encoding an 8-bit video into 10-bit, and introducing more colors? [19:48:56 CEST] <JEEB> well with bit depths at the most you might have dithering when going downwards, but there's really nothing else than the "correct way" of doing it [19:49:19 CEST] <JEEB> with 4:2:0 to 4:4:4 you hit scaling, where you have so many alternatives to choose from I won't even go further :P [19:49:36 CEST] <JEEB> although generally as long as you're doing your scaling correctly it shouldn't really matter too much with the chroma scaling [19:49:54 CEST] <JEEB> (since that's what in 4:2:20 is a single sample for 2x2 area, while in 4:4:4 each luma sample has its own chroma sample [19:50:07 CEST] <koyglreg> ok, well here's something i actually come across. i have 4:1:1 ntsc dv avi video. [19:50:18 CEST] <JEEB> yes, which has even less chroma [19:50:19 CEST] <koyglreg> and i want to convert it to yuv420p [19:50:53 CEST] <koyglreg> yeah, so do i just put -pix_fmt yuv420p, or are there different algorithms beyond this generic paramter? [19:50:56 CEST] <JEEB> which is just upscaling the chroma and most likely converting it to the top-left instead of whatever it was for the DV with regards to chroma location [19:51:36 CEST] <JEEB> -vf format=yuv420p is what I prefer since it gets you used to the video filter chains :P but I have no idea if there's any different chroma upscaling algorithms available [19:51:58 CEST] <JEEB> (nor am I sure if the chroma location difference is taken into account between DV and the more usual elsewhere thing) [19:52:37 CEST] <koyglreg> hmm, didn't know you could change color space in "vf" [19:53:08 CEST] <JEEB> it will also automagically insert conversions where "required" [19:53:17 CEST] <furq> a lot of commands are just aliases for filters [19:53:23 CEST] <JEEB> I mean, FFmpeg in general. you can have that logged with -v verbose [19:53:26 CEST] <JEEB> I think at least [19:53:33 CEST] <JEEB> if not, -v debug then tells you [19:54:05 CEST] <koyglreg> i wonder if avisynth has different algorithms for chroma upscaling [19:57:24 CEST] <JEEB> well the zscale filter at least lets you set the chroma location (it uses the zimg scaling/colorspace conversion library which vapoursynth also now uses) https://www.ffmpeg.org/ffmpeg-all.html#zscale [19:57:33 CEST] <koyglreg> #avisynth [19:57:54 CEST] Action: koyglreg meant to type /join #avisynth [19:59:12 CEST] <koyglreg> JEEB: that is interesting. i will look at that filter [20:02:20 CEST] <koyglreg> ohhh... so if I theoretically separated a "YUV" video into three separate videos like this: https://en.wikipedia.org/wiki/YCbCr#/media/File:Barns_grand_tetons_YCbCr_se… [20:02:59 CEST] <koyglreg> ... then I could apply whatever scaling algorithm to each channel, and then merge them again later. [20:03:04 CEST] <koyglreg> could that be done? [20:03:16 CEST] <Johnjay> so if I try to do ffmpeg with concat it chokes if the filename mylist.txt has ' anywhere in the file name [20:03:22 CEST] <Johnjay> and without the exterior ' and ' it won't work at all [20:03:30 CEST] <Johnjay> am I doing something wrong here? [20:03:54 CEST] <Johnjay> should i just strip all ' out of filenames? [20:04:47 CEST] <ChocolateArmpits> Johnjay, did you try using escape character? [20:58:29 CEST] <CFS-MP3> I'm having a problem compiling the current FFMpeg on a freshly installed Ubuntu 16.04.3 LTS 64 bits [20:58:36 CEST] <CFS-MP3> I've tried everything I could think of [20:58:42 CEST] <CFS-MP3> but it always ends like this: [20:58:55 CEST] <CFS-MP3> ffmpeg/libpostproc/version.h [20:58:55 CEST] <CFS-MP3> ERROR: libmp3lame >= 3.98.3 not found [20:59:46 CEST] <CFS-MP3> The end of the build log: [20:59:47 CEST] <CFS-MP3> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/home/captions/ffmpeg_build/include -std=c11 -fomit-frame-pointer -pthread -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/freetype2 -I/home/captions/ffmpeg_build/include -I/usr/include/freetype2 -c -o /tmp/ffconf.b0ukzlsd/test.o /tmp/ffconf.b0u [20:59:48 CEST] <CFS-MP3> kzlsd/test.c [20:59:48 CEST] <CFS-MP3> gcc -L/home/captions/ffmpeg_build/lib -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.b0ukzlsd/test /tmp/ffconf.b0ukzlsd/test.o -lmp3lame [20:59:48 CEST] <CFS-MP3> gain_analysis.c:(.text+0x2412): undefined reference to `__log10_finite' [20:59:48 CEST] <CFS-MP3> lame.c:(.text+0x1c94): undefined reference to `cos' [20:59:49 CEST] <CFS-MP3> lame.c:(.text+0x233f): undefined reference to `cos' [20:59:49 CEST] <CFS-MP3> lame.c:(.text+0x2589): undefined reference to `cos' [20:59:50 CEST] <CFS-MP3> lame.c:(.text+0x2625): undefined reference to `cos' [21:00:02 CEST] <CFS-MP3> howver lame was compiled just fine [21:00:35 CEST] <DHE> add -lm [21:00:49 CEST] <CFS-MP3> DHE where? -lm appears in a number of places [21:01:00 CEST] <DHE> oh this is from the config.log ? [21:01:38 CEST] <JEEB> CFS-MP3: are you using pkg-config or without? [21:02:07 CEST] <JEEB> also if you're doing static linking are you passing the --static flags in pkg-config options (there's a configure option for that) [21:02:09 CEST] <CFS-MP3> JEEB I'm following the build tutorial completely - from a freshly installed Ubuntu [21:02:22 CEST] <CFS-MP3> Just pasting, not adding anything myself at this point [21:02:37 CEST] <DHE> I think this is the configure test and it's failing. like it's using the static .a library because there's no .so available? [21:02:39 CEST] <JEEB> yea, but not like I know what this tutorial of yours is? can you post your full config.log [21:02:47 CEST] <JEEB> on pastebin [21:02:48 CEST] <CFS-MP3> It's strange because this has always worked for me, but something has changed I guess in this Ubuntu [21:02:48 CEST] <JEEB> and link here [21:02:57 CEST] <JEEB> CFS-MP3: no, it's FFmpeg trusting libraries more now [21:03:01 CEST] <JEEB> which has brought a lot of "fun" [21:03:11 CEST] <CFS-MP3> JEEB: This tutorial :-) https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [21:03:26 CEST] <JEEB> yes, please post the ffbuild/config.log in a pastebin or so [21:03:29 CEST] <JEEB> and link here [21:04:55 CEST] <JEEB> and yes, unfortunately that "guide" goes around static linking, which is the bane of everyone's pain so far because now that the configure script was changed to trust the pc files more it was found out that whadda you know, they lacked stuff :P [21:05:23 CEST] <JEEB> I think I reviewed a change to add -lm globally now because of that but I don't think that got reviewed yet. the correct thing would be to change the pc file and add -lm to Libs.private [21:05:40 CEST] <CFS-MP3> https://pastebin.com/CE3TeRXs [21:05:42 CEST] <JEEB> thanks [21:06:21 CEST] <JEEB> ugh, so that's not even pkg-config [21:06:32 CEST] <JEEB> fuck all the library checks without pkg-config checks [21:07:51 CEST] <CFS-MP3> Is the tutorial that needs updating, or some file? [21:08:11 CEST] <JEEB> can you check how the LAME pc file looks like, btw? [21:08:30 CEST] <JEEB> it's in your prefix under "$HOME/ffmpeg_build/lib/pkgconfig" [21:08:34 CEST] <JEEB> and pastebin that one [21:09:45 CEST] <CFS-MP3> No such file. Files there: fdk-aac.pc opus.pc vpx.pc x264.pc x265.pc [21:09:50 CEST] <JEEB> :| [21:10:01 CEST] <JEEB> or did you install LAME? [21:10:07 CEST] <JEEB> via the packaging system? [21:10:12 CEST] <CFS-MP3> No, built from source [21:10:23 CEST] <DHE> maybe you did --enable-static --disable-shared or such? [21:10:28 CEST] <JEEB> the tutorial does that :P [21:10:31 CEST] <JEEB> static everything [21:10:32 CEST] <CFS-MP3> cd ~/ffmpeg_sources [21:10:32 CEST] <CFS-MP3> wget http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.5.tar.gz [21:10:32 CEST] <CFS-MP3> tar xzvf lame-3.99.5.tar.gz [21:10:32 CEST] <CFS-MP3> cd lame-3.99.5 [21:10:32 CEST] <CFS-MP3> ./configure --prefix="$HOME/ffmpeg_build" --enable-nasm --disable-shared [21:10:32 CEST] <CFS-MP3> make [21:10:33 CEST] <CFS-MP3> make install [21:10:37 CEST] <CFS-MP3> That's exactly what I did [21:10:37 CEST] <DHE> oh dear [21:10:43 CEST] <JEEB> > LAME has no pc file [21:10:48 CEST] <JEEB> ok, excuse me while I weep a bit [21:10:50 CEST] <relaxed> CFS-MP3: with ffmpeg's configure add --extra-libs="-lm" [21:10:50 CEST] <DHE> well there's one major problem [21:11:34 CEST] <JEEB> CFS-MP3: ok, let me explain why this happened [21:11:46 CEST] <JEEB> before FFmpeg's configure would splat random linker flags [21:11:49 CEST] <JEEB> on all checks [21:11:52 CEST] <JEEB> which included -lm [21:11:57 CEST] <JEEB> so it happened to work until now [21:12:02 CEST] <JEEB> now it was cleaned up [21:12:19 CEST] <JEEB> also holy crap why the flying fuckload does LAME have no pc file :| [21:12:25 CEST] <JEEB> because pkg-config is how you generally handle this [21:12:38 CEST] <relaxed> when was the last lame release? [21:12:40 CEST] <JEEB> the library you're linking against has a pc file that contains the info what is needed to link [21:12:42 CEST] <BtbN> because it's ancient [21:12:50 CEST] <JEEB> well 3.99 most certainly isn't ancient [21:12:54 CEST] <JEEB> much less ancient than pkg-config [21:13:06 CEST] <JEEB> lame-3.99.5.tar.gz, 2012-02-28 [21:13:13 CEST] <CFS-MP3> If I add that -lm the error goes to x265: [21:13:14 CEST] <CFS-MP3> $ PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [21:13:15 CEST] <CFS-MP3> > --prefix="$HOME/ffmpeg_build" \ [21:13:15 CEST] <CFS-MP3> > --pkg-config-flags="--static" \ [21:13:15 CEST] <CFS-MP3> > --extra-cflags="-I$HOME/ffmpeg_build/include" \ [21:13:15 CEST] <CFS-MP3> > --extra-ldflags="-L$HOME/ffmpeg_build/lib" \ [21:13:15 CEST] <CFS-MP3> > --extra-libs="-lm" \ [21:13:15 CEST] <CFS-MP3> > --bindir="$HOME/bin" \ [21:13:16 CEST] <CFS-MP3> > --enable-gpl \ [21:13:16 CEST] <CFS-MP3> > --enable-libass \ [21:13:17 CEST] <CFS-MP3> > --enable-libfdk-aac \ [21:13:17 CEST] <CFS-MP3> > --enable-libfreetype \ [21:13:18 CEST] <CFS-MP3> > --enable-libmp3lame \ [21:13:18 CEST] <CFS-MP3> > --enable-libopus \ [21:13:19 CEST] <CFS-MP3> > --enable-libtheora \ [21:13:19 CEST] <CFS-MP3> > --enable-libvorbis \ [21:13:21 CEST] <JEEB> stop spamming please [21:13:40 CEST] <CFS-MP3> Sorry... pastebin for everything? [21:13:47 CEST] <JEEB> everything more than one or two lines :P [21:13:49 CEST] <CFS-MP3> OK [21:13:58 CEST] <JEEB> and yes, you will get issues with x265 because C++ (and they for some godawful reason strip the lstdc++ off the pc file [21:14:21 CEST] <JEEB> relaxed: also why extra-libs and not extra-ldflags? [21:14:27 CEST] <BtbN> because it's not called -lstdc++ everywhere and there is no proper way to find the right name everyehere [21:14:46 CEST] <JEEB> yes, I know. but cmake has some awful stuff to try and find out the stdlib :P [21:14:56 CEST] <JEEB> which is what they seem to have started removing [21:15:06 CEST] <JEEB> I think jamrial made a bug report to x265 about that [21:15:29 CEST] <BtbN> and they replied. It's intentional because they have no way to find the right thing to put there [21:15:33 CEST] <JEEB> ok [21:15:43 CEST] <JEEB> CFS-MP3: anyways the LAME issue would be "fixed" in master soon since we just add -lm everywhere [21:16:05 CEST] <JEEB> the x265 issue is --extra-ldflags="-lstdc++" -fixable :P [21:16:26 CEST] <JEEB> such a fucking mess when things get cleaned up and the shit underneath gets shown \o/ [21:17:05 CEST] <JEEB> (also -lm was additionally added because a lot of libraries' pc files would lack it, and/or possibly the threading library if one was needed) [21:18:43 CEST] <JEEB> partially to blame is of course the format for static libraries we have :P [21:21:05 CEST] <CFS-MP3> so do I add that --extra-ldflags="-lstdc++" to the configure part in x265? [21:21:12 CEST] <CFS-MP3> or in ffmpeg's configure? [21:21:19 CEST] <JEEB> FFmpeg's [21:22:05 CEST] <JEEB> and this is an old issue, which you might have not noticed if you enabled something else that happened to have lstdc++ added in its configure check before. for example I've had that issue for a while because x265 was the only thing I linked against which was C++-based [21:30:29 CEST] <CFS-MP3> Um, same issue [21:30:29 CEST] <CFS-MP3> ERROR: x265 not found using pkg-config [21:31:02 CEST] <JEEB> post config.log into pastebin [21:32:49 CEST] <CFS-MP3> https://pastebin.com/14yRBNRw [21:33:32 CEST] <JEEB> ah [21:33:33 CEST] <JEEB> pthreads [21:33:35 CEST] <JEEB> the other derp [21:33:58 CEST] <JEEB> in addition to lstdc++ also add -lpthread [21:34:01 CEST] <JEEB> separate by space [21:34:24 CEST] <JEEB> now this one is something that is 100% on x265's side :P [21:34:31 CEST] <JEEB> even more than the C++ stdlib case [21:35:09 CEST] <JEEB> (because the C++ stdlib case can be actually hard while this is just another library linked against) [21:39:59 CEST] <CFS-MP3> OK , so like this (in ffmpeg's configure): --extra-ldflags="-lstdc++ -lpthread" [21:40:11 CEST] <JEEB> yup [21:40:26 CEST] <CFS-MP3> same issue :-( ERROR: x265 not found using pkg-config [21:40:33 CEST] <JEEB> once again, time for config.log :P [21:40:45 CEST] Action: JEEB wonders wtf it is this time [21:42:27 CEST] <CFS-MP3> seems the same thing: https://pastebin.com/BUcn1qbh [21:43:31 CEST] <JEEB> ah [21:43:35 CEST] <JEEB> ok, so extra-libs goes at the end [21:43:49 CEST] <JEEB> move those two to extra-libs instead of extra-ldflags :P [21:44:17 CEST] <JEEB> it's an order thing. it worked for stdc++ because that's global but the rest needs the actual stuff you are building before it [21:45:36 CEST] <CFS-MP3> OK, that worked. Next error is a separation from the tutorial. I could live without this but would be useful to have: [21:45:38 CEST] <CFS-MP3> --enable-libzvbi [21:45:38 CEST] <CFS-MP3> ERROR: zvbi-0.2 not found using pkg-config [21:45:59 CEST] <JEEB> that one is so old so you don't have to build it [21:46:02 CEST] <JEEB> install libzvbi-dev [21:46:06 CEST] <CFS-MP3> wait actually I think since it's a fresh ubuntu I might just not have the package (libzvbi is the exception) [21:46:08 CEST] <JEEB> (or something like that) [21:46:20 CEST] <JEEB> yes, just install the zvbi dev package [21:46:51 CEST] <JEEB> it's a shared library so it will not have these issues :P [21:47:11 CEST] <CFS-MP3> fuck yeah [21:47:13 CEST] <CFS-MP3> finally [21:47:17 CEST] <CFS-MP3> configure is happy [21:47:24 CEST] <CFS-MP3> let's see if make is too [22:01:52 CEST] <CFS-MP3> This is the end of make: [22:01:53 CEST] <CFS-MP3> https://pastebin.com/88hUBHMC [22:02:41 CEST] <CFS-MP3> I do have a ffmpeg binary at least [22:02:42 CEST] <CFS-MP3> ./ffmpeg [22:02:43 CEST] <CFS-MP3> ffmpeg version N-87875-gf685bbc Copyright (c) 2000-2017 the FFmpeg developers [22:02:43 CEST] <CFS-MP3> built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.5) 20160609 [22:28:51 CEST] <CFS-MP3> thanks for your help, JEEB [23:04:21 CEST] <squarecircle> sorry [23:04:29 CEST] <squarecircle> stuff exploded in RL [23:07:25 CEST] <squarecircle> JEEB: ping [23:10:53 CEST] <squarecircle> JEEB: http://paste.ubuntu.com/25761768/ [23:11:24 CEST] <squarecircle> JEEB: all the context will be lost, but that are actually the parts working with the data [23:12:53 CEST] <squarecircle> same question as earlier today: I'm creating a video from pure green, red pictures [23:13:18 CEST] <squarecircle> and I get RGB(0,255,0) -> RGB(0,255,1) [23:13:35 CEST] <squarecircle> or RGB(255,0,0) -> RGB(254,0,0) [23:13:43 CEST] <squarecircle> which is irritating [23:29:11 CEST] <Xogium> so trying to set it up via srtp now.. I need a base64 encoded string.. But how do I even generate one ? [23:40:13 CEST] <alexpigment> squarecircle: I know you've been working with JEEB on this, but out of curiosity, how are you getting the RGB values from the video? [00:00:00 CEST] --- Wed Oct 18 2017

1 0

ffmpeg-devel.log.20171016
by burek 17 Oct '17

17 Oct '17

[00:07:44 CEST] <BtbN> jamrial, yes, that built now [16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:d4d4629dfe72: libavcodec/texturedsp : add rgtc1u_alpha decoding func [16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:50a20de6b9ed: libavcodec/texturedspenc : add rgtc1_u_alpha encoding func [16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:92500c7bc53b: libavcodec/texturedsp : indent after add rgtc1u_alpha func [16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:7480f232d24a: libavcodec/texturedspenc : indent after add rgtc1u_alpha func [16:44:46 CEST] <J_Darnley> Gramner (or anyone else) do you have a good reference for which processors have which AVX-512 variations? [16:52:20 CEST] <jkqxz> J_Darnley: <https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512>? [16:52:57 CEST] <jkqxz> Or do you mean 1 vs. 2 functional units? [16:52:57 CEST] <J_Darnley> Yeah, I saw that but I never trust Wikipedia to be accurate. [16:53:22 CEST] <nevcairiel> there is basically only two active sets for now [16:53:24 CEST] <J_Darnley> I just need to know whether a CPU will have the BW variant or not. [16:53:32 CEST] <nevcairiel> the desktop-set in purley and skylake-e [16:53:41 CEST] <nevcairiel> and the knights-landing set that noone cares about [16:54:13 CEST] <jkqxz> s/noone/noone with anything to do with multimedia/, but yes. [17:01:45 CEST] <J_Darnley> Are those Xeon E5-26xx v5 processors released or not? [17:05:33 CEST] <Gramner> J_Darnley: https://pbs.twimg.com/media/DMA38RyW4AAIzNm.png:large [17:05:34 CEST] <jkqxz> Skylake? It's all rebranded. [17:07:39 CEST] <J_Darnley> I don't know. I don't keep track of processor shenanigans these days. [17:07:57 CEST] <J_Darnley> I'll just quote Wikipedia in the email and hope for the best. [17:08:00 CEST] <Gramner> F+CD+BW+DQ+VL is what you can use as a baseline (that's the "avx512" cpuflag in x264) for anything that isn't xeon phi [17:31:19 CEST] <jamrial> Gramner: is cannon lake still going to feature avx512 plus those two new subsets now that it's been revealed to be a laptop only die shrink of coffe lake? [17:32:51 CEST] <nevcairiel> i could see them leave it out if its laptop only [17:42:11 CEST] <Gramner> jamrial: yes, gotta spend those extra transistors a die shrink gives on something [17:43:03 CEST] <Gramner> could possibly be a gimped variant with 256-bit data paths (like AMD) though [17:43:26 CEST] <Gramner> e.g. AMD does AVX/AVX2 with 128-bit vector units [17:47:27 CEST] <Gramner> the latest "Architecture Instruction Set Extensions and Future Features Programming Reference" from this months reaffirms that CNL is the first client platform with AVX-512 [17:47:54 CEST] <jamrial> cool [17:48:52 CEST] <kierank> J_Darnley: shared you a doc [17:48:56 CEST] <kierank> you'll need to translate betwee nthe marketing [17:56:09 CEST] <J_Darnley> so in addition to model numbers there are also tiers: Bronze, Silve, Gold, and Platinum. [17:58:24 CEST] <jkqxz> Suggest ignoring them - the model numbers carry more information (the 1 vs. 2 AVX-512 functional units change is in the middle of the "gold" tier). [18:04:26 CEST] <J_Darnley> So, these model numbers. Have Intel dropped their old E numbers on Xeons? [18:10:29 CEST] <jkqxz> Yes, it's all changed. [18:38:26 CEST] <J_Darnley> jkqxz: unless there is a typo in Intel's docs for this processor https://ark.intel.com/products/120475/Intel-Xeon-Gold-5122-Processor-16_5M-… then the change from 5xxx to 6xxx doesn't mark where it goes from 1 to 2 units. [18:46:37 CEST] <jkqxz> Probably there to mess with people trying to make generalisations. [18:47:41 CEST] <nevcairiel> the new xeon lines are quite a mess [18:48:11 CEST] <nevcairiel> i'm sure they have a cpu for every use-case imaginable [18:48:16 CEST] <nevcairiel> but its just so hard to find it [18:48:23 CEST] <J_Darnley> At this point they should build CPUs to order like a car. Choose instruction sets, choose speed, choose core count. Then the'll grow you one. [18:48:55 CEST] <nevcairiel> they probably even have every combination, just need a wizard to find it .p [18:50:26 CEST] <jkqxz> Probably half the SKUs never get bought by anyone at all. [18:51:03 CEST] <jkqxz> (That feels true with the proliferation of mobile SKUs as well.) [21:32:56 CEST] <JEEB> jamrial: currently having a user test https://github.com/jeeb/ffmpeg/commit/71b92aa9f92c89c8c7f5552d0caddb9aaadc6… [21:33:18 CEST] <JEEB> does that look correct'ish? [21:33:54 CEST] <jamrial> JEEB: you can remove the quotes from alsa, but yes, looks good [21:34:13 CEST] <JEEB> k [21:34:14 CEST] <jamrial> does the pkg-config file add some extra library? [21:34:22 CEST] <JEEB> it has Libs.private actually correct [21:34:35 CEST] <JEEB> (yes, another case of "I was building static and shit broke" on #ffmpeg) [21:34:46 CEST] <JEEB> almost brought me to tears btw https://pastebin.com/7jFZBX0x [21:34:56 CEST] <JEEB> > actually has -ldl in Libs.private [21:35:04 CEST] <JEEB> > also has pthread and math [21:35:20 CEST] <jamrial> and lrt [21:35:37 CEST] <jamrial> yeah, i welcome the pkg-config addition, then [21:36:26 CEST] <JEEB> waiting for the guy to get back to me if it worked for him, as I tested with the shared lib [21:42:31 CEST] <jamrial> JEEB: it should, assuming he runs configure with --pkg-config-flags=--static [21:47:04 CEST] <JEEB> yes, he did that [21:49:24 CEST] <JEEB> can anyone spot why this thing fails to enable pthreads? https://bpaste.net/show/490903f961fa [21:49:31 CEST] <JEEB> I see two checks which both seem to pass? [21:49:43 CEST] <JEEB> (why he's trying to use pthreads on windows is a separate question of course) [21:50:41 CEST] <hanetzer> << dude with the pthreads issue :) [21:52:43 CEST] <jamrial> sounds like you used --enable-pthreads but didn't use --disable-w32threads [21:52:54 CEST] <JEEB> ah [21:52:58 CEST] <JEEB> so you have to disable the other alternative [21:53:04 CEST] <JEEB> (which is the default) [21:53:07 CEST] <hanetzer> jamrial: hrm... lemme see if I can inject it into the build easily. [21:53:56 CEST] <jamrial> just add --disable-w32threads. that should make configure run all the pthreads checks [21:54:41 CEST] <JEEB> hanetzer: unless you really want your pthreads I recommend you just drop that enable-pthreads from there then :D [21:55:31 CEST] <jamrial> was going to say, w32threads is usually more than enough for a windows build [21:56:08 CEST] <hanetzer> true that may be, but I'd rather like to know the underlying cause as to why our ffmpeg ebuild doesn't work for mingw-w64 before I start slinging fixes :) [22:02:05 CEST] <JEEB> jamrial: posted the ALSA patch on the ML [22:02:30 CEST] <JEEB> the guy on #ffmpeg drifted away [22:02:33 CEST] <hanetzer> ok, testing with USE="-threads" to see if it will compile, and will file a bug with gentoo itself. [22:03:28 CEST] <hanetzer> so, basically what you're saying is I need to either --enable-pthreads --disable-w32threads or just not --enable-pthreads at all, then? [22:03:57 CEST] <JEEB> or --enable-w32threads --disable-pthreads if you want to be explicit [22:04:12 CEST] <JEEB> (which is the default) [22:04:38 CEST] <hanetzer> yep. USE="-threads" gets to the point of compilation. [22:04:52 CEST] <JEEB> and that doesn't actually disable threads? :D [22:05:02 CEST] <JEEB> because that's another option which I would expect "-threads" to do [22:05:21 CEST] <jamrial> hanetzer: for pthreads, --enable-pthreads and --disable-w32threads. for w32threads, nothing at all since it's default on windows, but adding --enable-w32threads doesn't hurt [22:05:22 CEST] <hanetzer> -useflag disables a use flag on gentoo. [22:05:46 CEST] <JEEB> hanetzer: so it doesn't mean an explicit flag the other way gets added? [22:05:50 CEST] <JEEB> because some things do it that way [22:06:13 CEST] <JEEB> jamrial: what were the other patches that you needed checked? [22:06:27 CEST] <JEEB> the libm thing I LGTM'd [22:06:34 CEST] <hanetzer> so USE="-x264" emerge media-video/ffmpeg will build it without the x264 library. [22:07:04 CEST] <JEEB> hanetzer: yea but there's a world of difference if you do --enable-libx264 and then leave it out. or set --disable-libx264 [22:07:14 CEST] <JEEB> although in this case I guess it works because you want to disable pthreads anyways :P [22:10:34 CEST] <hanetzer> I'm unsure if -threads just does no diddling at all or actively inverts the diddling. [22:11:41 CEST] <jamrial> ok, i think this in some way can be considered a regression since 8aad209c13c [22:12:45 CEST] <hanetzer> did my last message get through? [22:12:55 CEST] <jamrial> so better open a ticked in our bug tracker [22:13:00 CEST] <jamrial> hanetzer: the diddling one? yes [22:14:31 CEST] <JEEB> hanetzer: the main point though was to make sure that it didn't completely disable all threading [22:14:35 CEST] <JEEB> :) [22:14:45 CEST] <JEEB> since that's also something -threads could in theory do [22:14:54 CEST] <JEEB> if you could check the config.log kthx [22:15:23 CEST] <jamrial> why are you experiencing this now? the commit that seemingly started this has been in the tree for almost a year now [22:15:35 CEST] <hanetzer> k. also looks like it gets past making ffmpeg and ffprobe but 'no target to make tools/aviocat' later on. [22:16:12 CEST] <JEEB> hanetzer: can you check what I noted btw? just to double-check that your config is still sane [22:16:38 CEST] <hanetzer> JEEB: one sec. [22:17:46 CEST] <jamrial> sounds like it should be aviocat.exe for windows? [22:18:15 CEST] <hanetzer> maybe, but if the make target is changing per os that's a bit fucky in my book. [22:20:21 CEST] <hanetzer> JEEB: USE="-threads" i686-w64-mingw32-emerge media-video/ffpmeg builds with --disable-pthreads and does not futz with w32threads at all. [22:20:54 CEST] <JEEB> hanetzer: so no --disable-threads or some global disablement? [22:21:11 CEST] <hanetzer> not that I'm finding with a string search. [22:22:15 CEST] <nevcairiel> the ebuild sounds very much designed for linux only [22:22:38 CEST] <hanetzer> nevcairiel: nah. it does some freebsd and mingw handling. just not all of them. [22:23:05 CEST] <jamrial> nevcairiel: still, the commit i mentioned above did change the behavior of --enable-pthreads when used alone [22:23:11 CEST] <hanetzer> so does the make target for aviocat actually change for windows? [22:23:16 CEST] <jamrial> yes [22:23:23 CEST] <jamrial> every binary target on windows needs .exe [22:23:27 CEST] <jamrial> it's always been like that [22:23:33 CEST] <hanetzer> well that's dumb :P [22:23:51 CEST] <nevcairiel> make targets files, so yeah [22:24:20 CEST] <hanetzer> well it looks like the aviocat fix is fairly simple. [22:51:38 CEST] <cone-976> ffmpeg 03James Almer 07master:ae6fe04bee60: configure: add missing optional deps on gcrypt and openssl to the hls muxer [23:39:29 CEST] <cone-976> ffmpeg 03Jun Zhao 07master:2e9449022590: ffmpeg: remove hwaccel_lax_profile_check option [00:00:00 CEST] --- Tue Oct 17 2017

1 0

ffmpeg.log.20171016
by burek 17 Oct '17

17 Oct '17

[01:05:52 CEST] <Pandela> Does FFmpeg support directshow output? [01:35:05 CEST] <g0n> Pandela yes [01:36:08 CEST] <Pandela> g0n: As in like a directshow device readable by 3rd party apps? Could you show me an example? [01:38:45 CEST] <Cracki_> dshow display is probably what they meant [01:38:58 CEST] <Cracki_> not a dshow source you can pull from [01:42:36 CEST] <Pandela> Cracki_: Exactly, similar to how manycam or splitcam has their own. Or even this https://github.com/CatxFish/obs-virtual-cam [01:42:49 CEST] <Cracki_> hmmm [01:43:19 CEST] <Cracki_> interesting application [01:43:28 CEST] <Cracki_> how does such a virtual device get its data fed? [01:44:45 CEST] <Pandela> https://en.wikipedia.org/wiki/GraphEdit [01:44:45 CEST] <Pandela> Thats a good question, i dont knoow the actual process but you can usually do it manually with graphedit [01:46:46 CEST] <Cracki_> surely that OBS stuff can be adapted [01:47:21 CEST] <Cracki_> I figure these sources are created and destroyed by whatever provides the data, and live only so long [01:48:25 CEST] <Pandela> I mean OBS uses ffmpeg anyway, i feel like it could [01:49:13 CEST] <Pandela> Who wouldnt want to use ffmpeg output as a virtual webcam [01:49:19 CEST] <Pandela> Wonder what the dev channel would say lol [06:39:39 CEST] <andjarnic> Hello all. I discovered the wonderful ability to concatenate multiple videos into one, and using the -c copy option to avoid rendering..just muxing. Question though.. Given that it is not rendering but simply putting one file after another, thus just writing the files out to one combined file, why is it so slow? [06:39:53 CEST] <andjarnic> It is doing like 5fps.. on my quad core system with 64GB RAM and SSD drives. [06:40:28 CEST] <andjarnic> Seems like it should take a matter of minutes or less to combine files together into one. [07:32:31 CEST] <furq> andjarnic: pastebin the command [09:33:53 CEST] <g0n> hi [09:34:56 CEST] <g0n> I have a serie of packets coming from an application with fields: dts pts data duration. [09:35:26 CEST] <g0n> These packet are of variable size. [09:36:32 CEST] <aem34i> hey folks - Is there an option to set (or a patch) for ffmpeg to auto-connect to my jack ports (e.g. Ardour Jack ports)? (I'm using Jack2 and I don't want to use qjackctl's patchbay) [09:36:47 CEST] <g0n> Can someone point me in the right direction for encoding this into a file? [09:40:26 CEST] <blap> g0n: maybe output redirection will help, using ">" [09:43:27 CEST] <g0n> Im not using the command-line, but the C interface. is that something usable in c? [09:53:31 CEST] <blap> no [09:58:26 CEST] <g0n> Thats what I tought. thanks anyway. [10:00:03 CEST] <g0n> From what i know I think i have to somehow put this in avpackets, from that encode avframes and then build the video [10:00:24 CEST] <JEEB> decode you mean :) [10:00:29 CEST] <JEEB> but yes, you need a demuxer [10:00:51 CEST] <JEEB> or if you already have the packets in a data structure you need to create an AVPacket [10:00:58 CEST] <JEEB> and then set the fields accordingly with the buffer [10:01:20 CEST] <JEEB> then that can be utilized to get decoded things as AVFrames with the normal AVPacket-ingesting decoding APIs :) [10:01:32 CEST] <JEEB> then you can encode that with encoders that ingest AVFrames [10:01:57 CEST] <JEEB> g0n: do note that if you're already getting raw data then you might want to just skip to generating AVFrames [10:02:15 CEST] <Nacht> Anyone knows which configure option I need to enable to use dshow ? [10:02:26 CEST] <g0n> Nice explanation [10:02:53 CEST] <g0n> How would i go about skipping the avframes part? [10:02:54 CEST] <JEEB> Nacht: on windows with a new enough SDK/mingw-w64 it should just get enabled [10:03:10 CEST] <JEEB> g0n: you generate an AVFrame and set fields accordingly as well [10:03:11 CEST] <g0n> Im almost surf is raw data [10:03:15 CEST] <g0n> Sure [10:03:24 CEST] <JEEB> and raw data as in already decoded stuff [10:04:40 CEST] <g0n> Good question... [10:04:55 CEST] <JEEB> if you are for example getting raw packets of H.264 NAL units [10:04:58 CEST] <JEEB> then that is no longer raw [10:05:14 CEST] <JEEB> as that needs a H.264 decoder to be made into raw pictures [10:06:00 CEST] <g0n> Well, i gues Ill try the first approach, with avframe and see where that goes... [10:06:39 CEST] <aem34i> Can someone plz answer my question? [10:07:04 CEST] <g0n> The size of a 77 min vídeo is about 60 gb (1280x720) [10:11:18 CEST] <g0n> Than for pointing me in the right direction and correcting my terms, that will sure help!!! [10:11:30 CEST] <g0n> Thanks [10:13:42 CEST] <JEEB> aem34i: not many people using JACK input module here unfortunately [10:13:56 CEST] <aem34i> JEEB: :( [11:54:56 CEST] <bove> Should I be worried about RTP: missed n packets when using an rtsp input? Does that mean the frames where lost. And is there anything I can do to prevent it? https://pastebin.com/F6VSQzn6 [11:57:45 CEST] <BtbN> It's UDP. If you're on a shitty connection, there is going to be loss. [11:59:11 CEST] <bove> BtbN: I tried ?rtsp_flags=prefer_tcp, but it didn't help much [12:01:49 CEST] <BtbN> No idea how rtsp is implemented, but even when using tcp, if it can't keep up, it's going to drop stuff [12:03:08 CEST] <bove> I'm thinking maybe there's a way do create a buffer between my rtsp input and http output? [12:04:03 CEST] <BtbN> The sender is dropping stuff. [12:05:06 CEST] <BtbN> It's a real-time protocol after all, as the name implies [12:15:36 CEST] <bove> I see. I was hoping to get smoother playback by converting to http before piping it across the internet, but just piping the rtsp stream gives smoother playback [12:30:12 CEST] <AlienPenguin> hi all, i have a question regarding the ffmpeg windows binary packages... when i use those in a VC 2010 project of mine i got mixed results: in debug builds everything is fine, in release builds the app does not start because i get the following error: impossible to find entry point for ?fastFree@cv@YAXPAX@Z in avcodec-57.dll [12:30:25 CEST] <AlienPenguin> Can anyone point me in the right direction? [12:30:47 CEST] <JEEB> zeranoe is making those unofficial binaries [12:32:08 CEST] <furq> are you using opencv [12:32:35 CEST] <furq> the zeranoe builds are built with mingw so i wouldn't expect them to play nicely with a C++ MSVC project [12:32:52 CEST] <AlienPenguin> furq, yes my project already linked opencv as opencv before i started adding ffmpeg [12:33:28 CEST] <AlienPenguin> furq, so you think i have no chance with VC? there is no doc about compiling ffmpeg with VC, only using mingw [12:33:41 CEST] <furq> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [12:33:46 CEST] <furq> idk if it's strictly necessary though [12:33:55 CEST] <furq> i've not touched C++ enough to know what the actual problem is [12:34:17 CEST] <JEEB> mingw-w64 itself should be OK, but indeed opencv could be a problem [12:34:26 CEST] <JEEB> esp. since static linking is not utilized [12:34:31 CEST] <JEEB> mingw-w64 + MSVC + static linking is a PITA [12:35:02 CEST] <JEEB> but yes, you can compile with MSVC but support for C99 features was added in an update to VC2013 [12:35:10 CEST] <JEEB> so 2010 is awfully outdated in that sense [12:35:23 CEST] <JEEB> it would probably be simpler to build with a modern mingw-w64 without opencv on FFmpeg's side [12:35:33 CEST] <JEEB> that way it wouldn't try to get things from the FFmpeg DLL [12:35:36 CEST] <AlienPenguin> why opencv should be a problem? do you think that zeranoe builds are using it? the strange thing is that when building in debug mode everything works fine [12:35:47 CEST] <JEEB> probably because your VC library is different then [12:35:50 CEST] <furq> well that missing symbol is from opencv [12:36:03 CEST] <furq> at least according to google [12:38:46 CEST] <JEEB> http://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20171014-065581… [12:38:50 CEST] <JEEB> what Zeranoe links [12:39:09 CEST] <JEEB> or actually this http://ffmpeg.zeranoe.com/builds/readme/win64/shared/ffmpeg-20171014-065581… [12:39:21 CEST] <JEEB> he has vid.stab there which might be using opencv? [12:40:27 CEST] <AlienPenguin> ok, i think i have to try and compile that by myself then... [12:40:39 CEST] <AlienPenguin> however it's a PITA i am stuck with VS2010 [12:41:04 CEST] <furq> i assume you can build ffmpeg with mingw as long as you don't link any C++ libs [12:41:36 CEST] <furq> which is still annoying but nowhere near as annoying as building it with msvc [12:51:54 CEST] <JEEB> AlienPenguin: yea just build shared with mingw-w64 and link like with zeranoe's [12:59:46 CEST] <AlienPenguin> JEEB, i currently do not have a mingw toolchain, however the app is still 32bits, so i guess mingw64 is a no-go [13:08:07 CEST] <furq> mingw-w64 will build for i686 [13:08:27 CEST] <furq> the name is confusing [13:08:43 CEST] <furq> the original mingw couldn't build for amd64, so mingw-w64 is a fork that can [13:09:15 CEST] <furq> and because original mingw was completely stagnant, everyone uses -w64 now [14:30:31 CEST] <SolarAquarion> ERROR: libflite not found [14:30:38 CEST] <SolarAquarion> somethings going on [14:31:56 CEST] <JEEB> do you need that one? [14:32:02 CEST] <JEEB> I mean, only enable stuff that you need [14:32:20 CEST] <JEEB> a basic `./configure` will already give you 99% of all decoders and thus you only need to care about encoders [14:32:37 CEST] <JEEB> specific encoders that you might need and which have a "lib" prefix [15:00:35 CEST] <rabbe> anyone tried using SimpleWebRTC using only one master to stream his video to the other 'slaves'? [15:09:16 CEST] <Nacht> I only ever tried with a modified omxplayer to have a master-slave setup [15:09:27 CEST] <Nacht> But that was due to the fact I was doing in on RPi's [15:14:58 CEST] <rabbe> using rtsp to send the video? [15:15:31 CEST] <rabbe> with an rtsp server? [15:16:40 CEST] <Nacht> Nah, they all shared the same VOD and played that. [15:17:08 CEST] <Nacht> Now I'm just using mutlicast [15:17:19 CEST] <Nacht> Which works decent, but not perfect. [15:17:52 CEST] <Nacht> If the video buffers don't really line up, you still get some sync issues. But on the Rpi you don't really have much variation in players. [15:17:58 CEST] <Nacht> As in, you're stuck with OMXplayer [15:18:13 CEST] <rabbe> k.. i need to stream realtime video [15:18:53 CEST] <rabbe> and i would like to record and be able to watch in slow motion also... :) impossible? [15:20:00 CEST] <Nacht> Record what ? [15:20:14 CEST] <rabbe> the master's video [15:21:23 CEST] <Nacht> I'm not really sure what you're trying to do here. Start with explaining what you're trying to make/achieve [15:27:42 CEST] <rabbe> camera on a robot arm. video signal captured with capture card. mobile devices like android or ipad tablet that should watch the realtime stream. functionality to start and stop recording and the mobile devices should be able to watch the recordings also, in slow motion if they want [15:28:33 CEST] <rabbe> preferably in a web environment, but using VLC would be ok also [15:29:16 CEST] <rabbe> i've tried flv over rtmp, but i cannot get the same nice latency in VLC as by using ffplay -fflags nobuffer [15:30:09 CEST] <Nacht> How many fps does the camera give off, and how many does the capture card support [15:30:47 CEST] <rabbe> i read that rtsp would give better latency when played with VLC, but i couldn't get v4l2rtspserver to work because of the v4l2loopback thing that i couldn't get working [15:31:16 CEST] <rabbe> it's a gopro hero5. capture card supports 1080p@60fps which the camera can provide [15:33:23 CEST] <Nacht> RTMP has the advantage that you can show it on websites. [15:33:35 CEST] <Nacht> RTSP also, but you need an activeX component [15:33:43 CEST] <rabbe> without plugins? [15:33:51 CEST] <Nacht> RTMP would need Flash [15:34:07 CEST] <rabbe> yeah.. [15:34:07 CEST] <Nacht> thing is, for low latency streams, you still stuck using old tech [15:34:22 CEST] <Nacht> HTTP streams create latency, sadly [15:34:54 CEST] <rabbe> but webrtc is supposed to be the sh*t nowadays, right? [15:35:06 CEST] <Nacht> Hence, when you're using hardware products with build in web features which allow you to see the actual video, you're looking at a RTMP stream [15:35:55 CEST] <rabbe> or RTSP? [15:38:15 CEST] <rabbe> i figured that an IP camera is not built for twisting and turning in strange ways, which was why i decided to go with an action camera.. [15:39:15 CEST] <robswain[m]> The Stockholm subway uses axis cameras for monitoring everything. They use gstreamer and rtsp/rtp I believe [15:39:38 CEST] <robswain[m]> Depends how low latency you need [15:40:07 CEST] <robswain[m]> And also what reliability you need [15:40:21 CEST] <rabbe> initially i was gonna use the udp stream available through the gopro's own wifi, but i didn't think it provided production quality because of the jitter [15:40:42 CEST] <rabbe> okay [15:40:55 CEST] <robswain[m]> I would guess streamers use rtmp over tcp because of a combination of legacy and reliability [15:41:25 CEST] <Nacht> Mostly, in industrial areas, you go for industrial camera's [15:41:30 CEST] <Nacht> Such as machine vision camera's [15:41:49 CEST] <Nacht> Axis (CCTV) camera's can as well, but they are usually not that sturdy, but allot cheaper [15:41:51 CEST] <robswain[m]> Reliability being perhaps more important for broadcast than end to end latency [15:42:03 CEST] <rabbe> yeah, but the ones i checked had too low resolution [15:45:14 CEST] <rabbe> anyways.. right now i have the following options: flv over RTMP with nginx, giving latency and longtime instability using VLC. trying to get v4l2rtspserver working so i can test v4l2rtspserver with VLC, or trying to customize SimpleWebRTC [15:45:43 CEST] <rabbe> using VLC i guess it will not be that user friendly for an operator to get the recorded videos [15:45:51 CEST] <rabbe> so web is preferred [15:47:35 CEST] <rabbe> i got recording working with nginx+rtmp.. and it should work equally with recording an rtsp stream.. using webrtc i guess i would try RecordRTC... hopefully i can record on the sending side to avoid lag [15:48:15 CEST] <Nacht> Define low [15:48:15 CEST] <Nacht> I wouldn't really advice using consumer products for industrial means, as they usually dont last logn [15:49:19 CEST] <blap> glory glory to the lord. i have keycolor transparency working in X11 [15:49:45 CEST] <rabbe> the solution is build so that any HDMI camera or usb camera should work [15:50:24 CEST] <rabbe> i liked the nice support of accessories provided by the gopro.. didn't have to think too much about constructions for the robot arm [15:57:29 CEST] <rabbe> so.. back to webrtc.. how would i let only one client of the page provide the stream to all other clients? should i check the IP? and will i always need to open the browser to start the stream? [15:58:26 CEST] <rabbe> i will start the stream from the same computer that hosts the page [16:22:12 CEST] <SolarAquarion> JEEB: I compared the files I have to deb Dev files and they're the same [16:41:10 CEST] <Zeranoe_> Does FFmpeg have a native decoder for Speex, or does it rely on the external library? [16:41:46 CEST] <Zeranoe_> Followup question: are there legitimate reasons to use Speex today? [16:43:26 CEST] <JEEB> very few to be honest, but maybe someone has some legacy system somewhere making speex? [16:43:57 CEST] <furq> there's no native decoder [16:44:08 CEST] <furq> and yeah there's no reason to use it or celt over opus for new applications [16:51:01 CEST] <Zeranoe_> How about openh264? Is it somehow better than x264? [16:51:31 CEST] <JEEB> it might be faster on ARM in some very specific use cases, generally it is used because of its license and how cisco distributes binaries that you don't have to pay MPEG-LA for [16:51:39 CEST] <DHE> no. it's actually quite bad. but it does have the blessings of the licensing people, so there's that [16:51:43 CEST] <bencoh> Zeranoe_: far from being complete [16:51:52 CEST] <JEEB> doesn't apply to binaries you distribute of course, only cisco [16:54:14 CEST] <Zeranoe_> Are there any on here that should be added back? https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=5164#p12626 [17:03:15 CEST] <furq> i would probably keep vorbis [17:04:08 CEST] <furq> and i personally build with modplug and gme, although i don't think i've ever actually used them [17:04:54 CEST] <furq> openh264 is probably pointless because you'd probably want to build ffmpeg yourself anyway if you need it for the license [17:05:47 CEST] <furq> also i know gme uses cmake (and not even very well) so i understanding wanting rid of that [17:05:53 CEST] <furq> -ing [17:05:57 CEST] <bencoh> it's "useful" only in that it isn't gpl [17:06:12 CEST] <bencoh> (and doesn't taint) [17:06:15 CEST] <Zeranoe_> furq: I'll remove x265 then [17:06:21 CEST] <furq> lol [17:06:26 CEST] <bencoh> ? [17:06:32 CEST] <Zeranoe_> cmake [17:06:37 CEST] <furq> one cmake is better than two [17:06:41 CEST] <Zeranoe_> lots of libs are [17:06:55 CEST] <furq> i just remember having nightmares trying to get gme to actually build a shared lib [17:06:56 CEST] <Zeranoe_> it's what the cool kids are doing [17:07:05 CEST] <furq> the documented flag for it didn't work [17:07:09 CEST] <bencoh> """cool""" [17:07:17 CEST] <SolarAquarion> i have a issue with flite [17:07:24 CEST] <furq> SolarAquarion: do you actually need flite [17:07:42 CEST] <SolarAquarion> furq, it's needed in the pkgbuild i use [17:07:54 CEST] <furq> so remove it? [17:07:55 CEST] <Zeranoe_> furq: I'll add Vorbis back, GME I can't figure out a use for, or modplud [17:08:01 CEST] <SolarAquarion> but i guess i should remove the switch [17:08:34 CEST] <furq> Zeranoe_: they're probably more useful for audio players using the libs [17:08:53 CEST] <furq> i can imagine doing some kind of batch conversion with them though [17:09:17 CEST] <Fyr> guys, what does pseudocolor in FFMPEG do? [17:11:14 CEST] <Zeranoe_> "Alter frame colors in video with pseudocolors." [17:11:34 CEST] <Fyr> ok, what is pseudocolors here? [17:11:37 CEST] <brendan_> Hi there. I am using the zeranoe build to transcode using h264_qsv. When I transcode using the following ffmpeg -y -stats -i inputfile.mp4 -c:v h264_qsv -preset fast output.mp4 on an HD file... the transcode uses 1000kbps. If I use libx264, then it keeps a reasonable bitrate of > 5000kbps. I don't necessarily know the input file's bitrate to start with and was hoping that it would keep a reasonable frame rate. Any ideas why? [17:12:27 CEST] <brendan_> Unless I specify bitrate, the h264_qsv sticks to 1000kbps [17:12:31 CEST] <Zeranoe_> brendan_: What are your reasons to use QSV? [17:12:54 CEST] <brendan_> I am trying to transcode quicker (i.e. use GPU [17:13:32 CEST] <brendan_> I see this line in the console: Stream #0:0(und): Video: h264 (h264_qsv) (avc1 / 0x31637661), nv12, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 1000 kb/s, 25 fps, 12800 tbn, 25 tbc (default) [17:14:43 CEST] <brendan_> I want to use nvenc when I can, but default to qsv when I only have an intel i5/i7 processor [17:17:53 CEST] <Zeranoe_> brendan_: It's probably the rate control, which varies by device [17:18:57 CEST] <brendan_> I tried adding -crf 23... same result... this is what I tried: .\ffmpeg -y -stats -i input.mp4 -c:v h264_qsv -crf 23 -preset fast output.mp4 [17:19:16 CEST] <brendan_> Is there another way to set this? New to me [17:19:50 CEST] <Zeranoe_> brendan_: what if you use -b:v 1M? [17:20:08 CEST] <Zeranoe_> 5M rather [17:20:54 CEST] <brendan_> That works 100% [17:21:12 CEST] <brendan_> I am trying to work around now knowing the bitrate of the input file [17:21:46 CEST] <brendan_> so my input file could be any file type or resolution... which I am trying to get into a common format, and then downscale to the lower resolutions [17:24:19 CEST] <brendan_> My fallback plan is to determine the width / height of the source file, and then to force bitrates... but I was hoping not to have to do this. [17:24:31 CEST] <Zeranoe_> brendan_: it should be noted that qsv is pretty fragile, so be warned [17:25:02 CEST] <brendan_> ok, well I can get around this issue if qsv has its moments. Just hoping I am not making a mistake [17:25:02 CEST] <Zeranoe_> If you need a robust encoder, don't use it [17:25:06 CEST] <brendan_> ok [17:25:16 CEST] <brendan_> I assume an NVidia card and nvenc would be a lot better> [17:25:19 CEST] <brendan_> ? [17:25:19 CEST] <AlienPenguin> Zeranoe_, hi, i was trying to use your latest build in a project of mine (which uses opencv 3.20) with VS 2010, however when running in release mode the application won't start because of the error: Impossible to find the entry point ?fastFree@cv@YAXPAX@Z of the procedure in the dll avcodec-57.dll [17:25:37 CEST] <Zeranoe_> brendan_: Does it work with quality? -q [17:25:40 CEST] <AlienPenguin> when i run all in debug mode it works flawlessly [17:25:44 CEST] <brendan_> let me check quick [17:25:53 CEST] <AlienPenguin> do you have any insight? [17:26:50 CEST] <Zeranoe_> AlienPenguin: Hm, my builds don't have an opencv in them, are you sure it's due to my dll? [17:27:37 CEST] <AlienPenguin> well, i did not have any other ffmpeg library on my system and if i remove ffmpeg support the application start just fine both in release and debug [17:28:32 CEST] <AlienPenguin> besides, as i said, this happens only if i run the application in "release" mode, when running in debug the app works just fine [17:30:00 CEST] <Zeranoe_> AlienPenguin: It can find the dll, right? [17:30:23 CEST] <AlienPenguin> Zeranoe_, yes, if i move the dll away then the app won't start saying it is missing the dll [17:30:42 CEST] <Zeranoe_> AlienPenguin: I'd need a minimal code example to reproduce it [17:31:48 CEST] <brendan_> Zeranoe_: I can't find documentation on -q... do you have a value I could use? [17:32:07 CEST] <AlienPenguin> i have to see if i can find a snippet, unfortunately now it is quite integrated in my app code... [17:34:54 CEST] <Zeranoe_> brendan_: I forget the range, just try -q 30 [17:36:22 CEST] <brendan_> .\ffmpeg -y -stats -i input.mp4 -c:v h264_qsv -q 30 -t 0:01:00 output.mp4 give me "More than one of: { constant qscale, lookahead, VCM } requested, only one of them can be used at a time." and "Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [17:38:02 CEST] <Zeranoe_> brendan_: ffmpeg -y -stats -i input.mp4 -c:v h264_qsv -q 30 -look_ahead 0 -t 0:01:00 output.mp4 [17:38:30 CEST] <arinov> why the stream fps is always 8 and sound are so shitty and laggy? [17:38:38 CEST] <arinov> whatever i do [17:38:41 CEST] <arinov> 320x240 [17:38:43 CEST] <arinov> the same [17:38:50 CEST] <Zeranoe_> arinov: You forgot pretty much all the info we need [17:39:14 CEST] <brendan_> zeranoe_: ok that still gives me 1000kb/s: Stream #0:0(und): Video: h264 (h264_qsv) (avc1 / 0x31637661), nv12, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 1000 kb/s, 25 fps, 12800 tbn, 25 tbc (default) [17:39:35 CEST] <brendan_> wait I lie [17:39:56 CEST] <brendan_> that is the powershell output, but if I check the file it is a bitrate of 1885kbps [17:40:14 CEST] <brendan_> still very low for 1080p [17:40:15 CEST] <arinov> ffmpeg -f v4l2 -video_size 320x240 -framerate 30 -r 10 -i /dev/video0 \ [17:40:17 CEST] <arinov> -f alsa -i pulse -ac 2 -vcodec libx264 -vf hue=s=0 -pix_fmt yuv420p -preset ultrafast -g 20 -b:v 2500k \ [17:40:19 CEST] <arinov> -acodec libmp3lame -ar 44100 -ab 128k -threads 0 -bufsize 512k \ [17:40:21 CEST] <arinov> -f flv "rtmp://a.rtmp.youtube.com/live2/$STREAM_KEY flashver=FMLE/3.0\20(compatible;\20FMSc/1.0)" [17:41:46 CEST] <arinov> Zeranoe_: [17:42:03 CEST] <Zeranoe_> brendan_: Honestly I don't know if constant quality will work here. Maybe someone else here knows, but I always use -b:v myself [17:42:42 CEST] <arinov> maybe i should stream 10x10? [17:42:43 CEST] <Zeranoe_> arinov: Is this from a webcam? [17:42:47 CEST] <arinov> yep [17:42:48 CEST] <brendan_> Thanks Zeranoe. I think my bigger issue was trying to figure out if I was making an error in its usage. I will use -b:v [17:42:55 CEST] <alexp> hey guys. I'm trying to fix an issue with Yadif where AVCHD videos from cameras do not get properly deinterlaced unless you manually specify the frame rate prior to input. I'm looking in vf_yadif.c but I'm not sure where I should be looking to override the frame rate detection logic [17:43:08 CEST] <brendan_> Zeranoe... thanks for the help! [17:43:14 CEST] <Zeranoe_> arinov: How does ffplay work with it? [17:43:19 CEST] <arinov> but the lags in sound too, which is from default audio device [17:43:37 CEST] <arinov> i need to find out, wait [17:43:39 CEST] <Zeranoe_> arinov: no encoding, just see if you can get decent results with ffplay [17:43:52 CEST] <arinov> perfect [17:44:04 CEST] <arinov> fast and smooth [17:44:19 CEST] <arinov> Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 320x240, 36864 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc [17:44:29 CEST] <Zeranoe_> arinov: Are you getting buffer overflow errors when encoding? [17:44:56 CEST] <arinov> ffplay or stream? [17:45:10 CEST] <arinov> [flv @ 0x90f6c0] Failed to update header with correct duration.rate=2189.1kbits/s [17:45:11 CEST] <Zeranoe_> arinov: the stream [17:45:12 CEST] <arinov> [flv @ 0x90f6c0] Failed to update header with correct filesize. [17:45:14 CEST] <arinov> ffplay says [17:46:02 CEST] <arinov> nope [17:46:08 CEST] <arinov> it seems nothing critial [17:46:16 CEST] <arinov> just a couple of yellow strings [17:46:26 CEST] <Zeranoe_> what does ffmpeg -f v4l2 -video_size 320x240 -framerate 30 -r 10 -i /dev/video0 -f alsa -i pulse -ac 2 -vcodec libx264 -vf hue=s=0 -pix_fmt yuv420p -preset ultrafast -g 20 -b:v 2500k -acodec libmp3lame -ar 44100 -ab 128k -threads 0 -bufsize 512k -f matroska | ffplay - [17:46:29 CEST] <arinov> rame= 512 fps=8.5 q=2.0 size= 13275kB time=00:00:49.90 bitrate=2179.4kbits/s [17:46:52 CEST] <Zeranoe_> what does ffmpeg -f v4l2 -video_size 320x240 -framerate 30 -r 10 -i /dev/video0 -f alsa -i pulse -ac 2 -vcodec libx264 -vf hue=s=0 -pix_fmt yuv420p -preset ultrafast -g 20 -b:v 2500k -acodec libmp3lame -ar 44100 -ab 128k -threads 0 -bufsize 512k -f matroska - | ffplay - [17:47:30 CEST] <arinov> oh hate weechat and its strings [17:47:34 CEST] <arinov> a second please [17:47:41 CEST] Action: arinov weechat is shit [17:49:11 CEST] <arinov> http://pastebin.centos.org/377796/ [17:49:15 CEST] <arinov> full output [17:50:10 CEST] <arinov> sound is laggy there [17:50:26 CEST] <arinov> tr-tr-tr-tr-tr-tr-tr- [17:50:43 CEST] <arinov> but the video is pretty fast [17:52:08 CEST] <arinov> oh now the sound died [17:52:40 CEST] <arinov> video is good, the sound lags, lags, lags and died [17:53:17 CEST] <arinov> 120 kbits/s [17:53:21 CEST] <arinov> the best result [17:53:23 CEST] <alexpigment> arinov: just to rule things out, have you tried keeping the audio at 48khz in case the conversion from 48k to 44.1 is causing the problem? [17:54:05 CEST] <arinov> the better way is? [17:54:17 CEST] <arinov> just stream 48? [17:54:19 CEST] <alexpigment> -ar 48000 (or don't define it at all) [17:54:23 CEST] <alexpigment> just as a test [17:54:32 CEST] <arinov> ok [17:55:13 CEST] <arinov> 2-5 seconds clear sound, then again tr-tr-tr-tr-tr-tr [17:55:32 CEST] <arinov> Stream #0:1: Audio: mp3, 48000 Hz, stereo, s16p, 128 kb/s (default) [17:55:39 CEST] <alexpigment> arinov: Ok, I just figured I'd throw that suggestion out there [17:55:43 CEST] <arinov> it seems the sound problems here [17:56:54 CEST] <arinov> 2-5 seconds of clear sound with 800kbits/s and then it starting lagg with 100-120 kbits/s [17:57:29 CEST] <alexpigment> and I assume you've already raised the thread_queue_size as it suggested? [17:58:33 CEST] <alexpigment> if not, try -thread_queue_size 512 [17:58:46 CEST] <alexpigment> or even -thread_queue_size 1024 [17:58:51 CEST] <demonicsweaters> hey all, I'm hoping somebody will have an idea here. What I want to do is take 2 MP3s, one is a complete song, the other is just a short talking clip, I want to mix them together, but when the voice is playing, I want the music level to drop abit to allow the talk to be louder, then after the talking stops, the music comes back up and the song completes [17:59:35 CEST] <blap> a compressor/limiter would do that demonicsweaters [17:59:52 CEST] <Zeranoe_> I don't think FFmpeg can do that in one pass [18:00:21 CEST] <blap> pretty sure you can do it actually, mix two sources, then run through a compressor filter [18:00:26 CEST] <arinov> the same [18:00:37 CEST] <demonicsweaters> hmm, maybe a sidechain to create a ducking effect [18:00:38 CEST] <alexpigment> blap: assuming that the voiceover is significantly louder, yes [18:00:55 CEST] <arinov> maybe i should run from mp3 to ogg? [18:01:10 CEST] <alexpigment> arinov: any tests are good ones [18:01:11 CEST] <demonicsweaters> is sidechain compression possible in ffmpeg? [18:01:13 CEST] <arinov> or this is an Intel, the God of trottling? [18:01:45 CEST] <alexpigment> arinov: try -c:a copy first . if it's a problem there, you can rule out encoding altogether [18:02:50 CEST] <arinov> hmm [18:03:04 CEST] <arinov> it seems the sound from webcam lags [18:03:14 CEST] <arinov> i should check any other sources [18:04:59 CEST] <arinov> is there a way to set pulse audio input device to ffmpeg? [18:05:11 CEST] <arinov> i have several inputs here [18:07:46 CEST] <arinov> oh it can be changed by the system sound preferences [18:30:00 CEST] <Johnjay> idea: a filter in addition to segment that just takes a number and splits the file into chunks [18:30:37 CEST] <Johnjay> as in ffmpeg -i file.wav -f divide 3 output.wav => 3 files of equal length adding up to output [18:31:06 CEST] <alexpigment> Johnjay: do you have a use case in mind? [18:31:39 CEST] <alexpigment> it seems odd to me that your goal is ever to just get a specific number of segments [18:31:51 CEST] <alexpigment> more than likely, you'd need a specific file size per segment [18:32:07 CEST] <alexpigment> (or specific length) [18:32:43 CEST] <Johnjay> alexpigment: I use an mp3 player to listen to things while i work out. But the talks I download are typically 2-3 hours in length [18:33:05 CEST] <Johnjay> So I have to split them down into segments. And so I have to calculate exact time with segment filter [18:33:18 CEST] <alexpigment> Johnjay: right, so the number of segments seems like an indirect way to split on length [18:33:47 CEST] <Johnjay> Right. but if I see something is say 2 hours 30 min, then I can just tell it to divide in half [18:34:05 CEST] <Johnjay> instead of trying to compute exact amount for segment time in seconds [18:34:22 CEST] <Johnjay> if segemnt time took HH:MM:SS that would be another possibily [18:34:25 CEST] <Johnjay> *possibility [18:35:31 CEST] <alexpigment> Johnjay: well, it still sounds very niche to me, but others may feel differently [18:35:49 CEST] <Johnjay> I'm trying that out right now, maybe it does accept that format [18:36:00 CEST] <Johnjay> damn i guess it does [18:38:03 CEST] <alexpigment> well there you go :) [18:38:23 CEST] <alexpigment> I actually thought specifying the HH:MM:SS was the thing you were trying to avoid initially [18:38:31 CEST] <Johnjay> it seemed to split as 10:20 even though I told it 10:10 [18:38:53 CEST] <Johnjay> No I just assumed it wouldn't work because the -t or -to option wouldn't take HH:MM:SS before [18:39:10 CEST] <relaxed> Johnjay: are you using the segment muxer? [18:39:13 CEST] <Johnjay> yes [18:47:31 CEST] <Johnjay> honestly this thing is kind of weirdly designed [18:47:41 CEST] <Johnjay> it's just a headset, no interface, and has 4GB of storage [18:48:04 CEST] <Johnjay> but it's useless because it doesn't respect folders or let you browse them [18:48:13 CEST] <Johnjay> just play next and play last [18:48:43 CEST] <Johnjay> so why have 4GB of storage if you can have playlists? Just to have 4GB of music on random play? [18:48:55 CEST] <Johnjay> *can't have [18:55:02 CEST] <arinov> the sound is good without video [18:55:11 CEST] <arinov> no lags, nothing [18:59:31 CEST] <arinov> ok i solve the problem [18:59:38 CEST] <BytesBacon> Is there a way to take the input video, crop out the letterboxing and change to 720p while keeping the aspect ratio? Seems anyway I run video filter I can't get it encode right, should be 1280x536 with a 2.40:1 ratio, but I keep getting 1280x720, with the same aspect ratio which changes it to 1728x720. [18:59:42 CEST] <arinov> the resolution and other parameters [19:00:04 CEST] <arinov> the only way to stream with webcam without sound lags - dont tweak the video [19:00:13 CEST] <arinov> any video options will cause lags [19:00:49 CEST] <Johnjay> BytesBacon: What do you mean keep the same aspect ratio? [19:02:11 CEST] <arinov> f v4l2 -i /dev/video0 [19:02:31 CEST] <BytesBacon> I'm trying to descale to from 1080p that has letterboxing, so I want to remove the letterboxing and go to 720p, which ended up being 1280x536. Seems I'm not getting this -vf command right. Or do I need to encode once and then encode a 2nd time to crop out the letterboxing. [19:03:26 CEST] <BytesBacon> scale to 720p from 1080p* [19:04:08 CEST] <Johnjay> er so of the 1080 height pixels 720 are the image and 360 are black boxing? [19:05:24 CEST] <BytesBacon> Yep, so when I re-encode just the 1080p, I do -vf crop=1920:804:0:128 to remove the bars. Which works will, it's just now going from 1080p to 720p, that I'm missing something. [19:06:59 CEST] <BytesBacon> Thought -vf scale=1280:-1:force_original_aspect=decrease and use the crop before that work, but it doesn't seem to make a 1280x536 with 2.40:1 [19:11:19 CEST] <Johnjay> so the -vf crop goes to 0,128 and then takes a rectangle of 1920 width and 804 height? [19:13:43 CEST] <Johnjay> I'm confused because 804+128+128 = 1060, not 1080 [19:17:30 CEST] <Johnjay> idk maybe furq knows what to do [19:23:46 CEST] <c_14> BytesBacon: get rid of the force_original_aspect_ratio maybe [19:23:55 CEST] <c_14> Oh, eh [19:23:59 CEST] <c_14> Are you specifying -vf twice? [19:24:01 CEST] <c_14> don't do that [19:24:05 CEST] <c_14> -vf crop,scale [19:24:06 CEST] <oddjob> hello, im recording a m3u8 stream and gets skips [19:24:14 CEST] <oddjob> only "odd" thing I see is for reading [19:24:15 CEST] <oddjob> skipping 1 segments ahead, expired from playlists [19:24:25 CEST] <oddjob> or maybe thats normal? [19:24:28 CEST] <c_14> You're encoding too slowly [19:24:33 CEST] <c_14> are you using -re ? [19:24:35 CEST] <c_14> (hint, don't) [19:24:49 CEST] <oddjob> no reoncoding at all [19:25:08 CEST] <c_14> Well, the problem's that you're writing too slowly [19:25:14 CEST] <c_14> What's the command you're using? [19:26:06 CEST] <oddjob> ffmpeg -i "stream" out.mkv [19:26:37 CEST] <oddjob> or -re -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 4294 -i "$stream" $qmap -c copy -flags -global_header -hls_flags delete_segments -hls_time 20 -hls_list_size 60 -hls_wrap 0 -use_localtime 1 out.m3u8 [19:26:46 CEST] <c_14> get rid of the -re [19:26:50 CEST] <c_14> like I said [19:26:52 CEST] <oddjob> ok [19:26:57 CEST] <oddjob> are you sure its a write problem? [19:27:04 CEST] <oddjob> couse other streams gets me no problem [19:27:09 CEST] <oddjob> only from this stream [19:27:26 CEST] <c_14> 99% [19:27:49 CEST] <c_14> What that message means is that the client is reading the stream too slowly [19:27:53 CEST] <c_14> And is lagging behind [19:28:02 CEST] <c_14> And then source segments time out and ffmpeg has to skip them [19:28:07 CEST] <c_14> which causes the skips [19:28:22 CEST] <c_14> I mean, it could also be the network connection [19:28:24 CEST] <c_14> If that's too slow [19:28:40 CEST] <oddjob> probably not [19:28:42 CEST] <oddjob> akademi [19:28:46 CEST] <oddjob> 1ms away [19:29:13 CEST] <oddjob> well ill try without re [19:33:23 CEST] <oddjob> yes it did work [19:33:25 CEST] <oddjob> thanks god [19:33:29 CEST] <oddjob> thanks alot c_14 ! [19:41:46 CEST] <BytesBacon> c_14, thanks I'll give that a try. [19:43:05 CEST] <BytesBacon> Okay so that works. But is there a way to find the letterboxing dimensions so that I don't have to know what the height is? [19:44:07 CEST] <c_14> cropdetect [19:44:09 CEST] <c_14> that's 2 pass though [19:45:58 CEST] <c_14> (i.e. detect in one run, use the values in the next) [19:51:17 CEST] <BytesBacon> Will could I use that and set the -t switch so it's only a small output video. Would it give the needed data on cropping? Like the start point location? (x, y, and w, h) [19:52:11 CEST] <c_14> yeah, though also use -f null. You don't need to actually create an output video, you just need to process the input [19:53:23 CEST] <BytesBacon> sweet! Thank you c_14. Glad to know I can use the tool to do the hard work for me, vs me trying to find out what the end results need to be by doing the math myself. [19:58:01 CEST] <BytesBacon> That's odd, using the cropdetect but it's getting a height of 528 and not 536. Any idea why c_14? [19:58:21 CEST] <c_14> rounding to the nearest multiple of 16 [19:58:31 CEST] <c_14> set round=1 [19:58:52 CEST] <BytesBacon> okay, thank you [19:59:52 CEST] <BytesBacon> It's still getting 528, with cropdetect=24:1:0 [20:00:42 CEST] <c_14> try round=0 maybe? [20:00:45 CEST] <c_14> otherwise adjust limit [20:00:54 CEST] <c_14> part of the bars might be too gray [20:01:26 CEST] <BytesBacon> Ooo okay, it could be, I'll play around with it, thank you. [20:21:04 CEST] <doublya> Pulled from ffmpeg master, and not I'm getting undefined reference to 'dlsym' 'dlopen' 'dlclose' in alsa/src/dlmisc.c during ffmpeg configure [20:21:34 CEST] <JEEB> yes, there recently has been a flurry of findings that the pkg-config files of things fail at life [20:21:49 CEST] <JEEB> although wait that is alsa... [20:22:06 CEST] <JEEB> is that building alsa or trying to link FFmpeg against alsa? [20:22:18 CEST] <JEEB> because I'm surprised if it's showing you the C file [20:22:22 CEST] <JEEB> of ALSA [20:22:26 CEST] <JEEB> in the error [20:25:03 CEST] <doublya> I've built alsa from src and I've provided the pkg-config path to ffmpeg configure [20:25:42 CEST] <JEEB> ok, so if it's during the FFmpeg compilation then it's a case of the pkg-config file sucking [20:25:51 CEST] <JEEB> can you check pkg-config --libs alsa or whatever its name is :) [20:26:00 CEST] <JEEB> maybe with the static parameter [20:26:15 CEST] <JEEB> (which adds the Libs.private stuff) [20:28:04 CEST] <doublya> I pulled from ffmpeg to get cuda9 support. is there a commit that provides cuda9 support that doesn't have broken pkg-config? [20:28:44 CEST] <JEEB> what I want to find out is if this is an ALSA bug or FFmpeg bug [20:28:49 CEST] <JEEB> so please then just post your ALSA pkg-config file [20:28:51 CEST] <JEEB> thank you [20:29:46 CEST] <JEEB> because recently we removed additional flags and actually started trusting the pkg-config files (.pc files) [20:30:01 CEST] <doublya> pkg-config --modversion alsa is returned the correct version. and --libs alsa work as well [20:30:11 CEST] <JEEB> can you really not fucking read? [20:30:22 CEST] <JEEB> Please post the pc file's contents [20:30:32 CEST] <JEEB> and tell me if you're trying to do static or shared linking [20:30:38 CEST] <JEEB> the pc file in a pastebin or so, thank you [20:30:41 CEST] <JEEB> and link here [20:30:46 CEST] <doublya> static, standby [20:30:47 CEST] <JEEB> don't paste onto the channel [20:31:01 CEST] <JEEB> ok, yes. most issues are with static because most libraries don't make their pc files correctly [20:31:08 CEST] <JEEB> let's see how the pc file looks like [20:34:06 CEST] <doublya> https://pastebin.com/7jFZBX0x [20:34:11 CEST] <JEEB> cheers [20:34:20 CEST] <JEEB> woah [20:34:24 CEST] <JEEB> it actually has that stuff now :) [20:34:50 CEST] <JEEB> doublya: then most likely you were missing --pkg-config-flags="--static" [20:34:55 CEST] <JEEB> in FFmpeg configure [20:35:13 CEST] <JEEB> (make sure to clear your build root) [20:35:23 CEST] <JEEB> if that still fails then pastebin the failure please [20:36:04 CEST] <doublya> I have pkg_config_flags="--static". The only thing I've done since this WAS working, was pull from ffmpeg master. [20:36:07 CEST] <Johnjay> pc files are bogus? huh? [20:36:36 CEST] <JEEB> can you please post the full log then of the compilation [20:36:56 CEST] <JEEB> doublya: or wait, post make V=1 [20:37:00 CEST] <JEEB> which shows teh actual commands used [20:37:27 CEST] <JEEB> we might be missing the alsa pkg-config flags somewhere, but I want to check if that's true first [20:37:36 CEST] <JEEB> Johnjay: yea a lot of them lack stuff to link things statically [20:37:53 CEST] <JEEB> before we were manually adding various flags but now we're trusting the pkg-config files more [20:38:05 CEST] <JEEB> which led to some things borking because the pkg-config files were... borked [20:38:11 CEST] <JEEB> but some things of course can be our bugs [20:38:35 CEST] <Johnjay> hrm, I see [20:38:57 CEST] <JEEB> usually related to things like C++ stdlib [20:39:01 CEST] <JEEB> which almost nothing puts in there [20:39:06 CEST] <JEEB> or the threading or math library [20:39:20 CEST] <JEEB> if you build the library shared those are found as they're linked against [20:39:28 CEST] <JEEB> but with a static AR archive that's not the case [20:39:40 CEST] <JEEB> you have to then define those dependencies once again when linking the "next level" [20:39:59 CEST] <Johnjay> AR is the .a files right? [20:40:03 CEST] <JEEB> ya [20:40:07 CEST] <Johnjay> ok [20:40:14 CEST] <JEEB> basically if you do `ldd SOME_SO_FILE.so` [20:40:20 CEST] <JEEB> you will get a list of dependencies to shared libraries [20:40:29 CEST] <JEEB> you don't have that with AR archives [20:40:59 CEST] <Johnjay> compilation is such a big messy task [20:41:04 CEST] <Johnjay> i'm amazed i got ffmpeg to compile under msys2 in windows [20:42:17 CEST] <JEEB> I've gotten used to both *nix and windows build systems and I more or less understand how things work together and what some things can cause so I don't really consider it messy at this point. [20:42:40 CEST] <Johnjay> sort of like Han and chewy on star wars [20:43:09 CEST] <doublya> configure test that fails for alsa https://pastebin.com/QRZnsJ6r [20:43:28 CEST] <doublya> I changed some paths names as there are confidential [20:43:34 CEST] <JEEB> yea, that's OK [20:44:00 CEST] <JEEB> and you say this is with the static flag for pkg-config? [20:44:05 CEST] <JEEB> let me check that configure check [20:44:34 CEST] <JEEB> also in case you have ALSA on your system [20:44:45 CEST] <JEEB> can you make sure that the --static --libs thing gives you -ldl ? [20:45:05 CEST] <doublya> yes. I have a similar problem with other depends. I have to add some LD_FLAGS to configure like -lm and -lpthread [20:45:14 CEST] <doublya> ok [20:45:26 CEST] <relaxed> doublya: add to ffmpeg's configure, --extra-libs="-ldl" [20:45:42 CEST] <JEEB> relaxed: I'm trying to trouble-shoot it here because his pc file seems to contain -ldl [20:46:02 CEST] <JEEB> and I'm trying to double-check if he is actually getting the proper (the one he wants) pc file used [20:46:08 CEST] <JEEB> no need for extra-libs or extra-ldflags [20:46:20 CEST] <JEEB> as in, there shouldn't be a need for them [20:47:43 CEST] <doublya> JEEB: I'll check the pkg-config output in a sec. I just did a configure with -ldl in extra libs and I'm not getting that alsa error anymore [20:47:54 CEST] <JEEB> well d'uh [20:48:04 CEST] <JEEB> "guess why" [20:48:16 CEST] <JEEB> you forcibly added it there [20:48:23 CEST] <JEEB> thus of course the check now passes [20:48:28 CEST] <JEEB> hmm [20:48:30 CEST] <JEEB> oh fun [20:48:35 CEST] <JEEB> pkg-config isn't even being used for ALSA [20:48:41 CEST] <JEEB> that explains [20:49:10 CEST] <relaxed> \o/ [20:49:40 CEST] <JEEB> "-lasound should be enough for everyone!" [20:49:42 CEST] <JEEB> said someone years ago [20:50:12 CEST] <JEEB> doublya: ok it doesn't matter if you were using the right pc file or not, since the darn thing doesn't even try to find out alsa with pkg-config [20:50:19 CEST] <JEEB> I might whip a patch up for that [20:50:54 CEST] <JEEB> also so darn rare for something to set its Libs.private correctly [20:51:02 CEST] <JEEB> also makes me go all sentimental [20:51:50 CEST] <JEEB> doublya: if I push a branch somewhere soon would you be ready to test it out? [20:52:00 CEST] <doublya> I'm not knowledgeable enough with pkg-config to appreciate it haha. [20:52:00 CEST] <doublya> yes [20:52:17 CEST] <JEEB> ok [20:53:26 CEST] <doublya> thanks [20:56:50 CEST] <JEEB> just grabbed some hot tea because I'm not exactly feeling well today [20:58:38 CEST] <doublya> sorry to hear. I had a cold last week. [21:00:04 CEST] <blap> tea is the best [21:04:10 CEST] <Mavrik> JEEB, I think ffmpeg needs more cmake to fix things ;P [21:04:39 CEST] <JEEB> lol [21:04:47 CEST] <JEEB> might as well go meson [21:09:31 CEST] <JEEB> fun, my VM decided not to come back to life [21:09:36 CEST] Action: JEEB hard-reboots [21:16:03 CEST] <JEEB> ok, that did it :) [21:19:09 CEST] <hanetzer> yello o/ [21:19:17 CEST] <JEEB> ok, double checked that Fedora has the pc file as well [21:21:58 CEST] <hanetzer> a question have I, how does the ffmpeg build process check for pthreads? because, I've installed a mingw-w64 toolchain with gcc configured with "Thread model: posix" and the mingw-w64 runtime installed with the thread libraries enabled, but its not being found during my cross-emerge. [21:22:25 CEST] <JEEB> hanetzer: checking ffbuild/config.log is what you'll probably want to do :) [21:22:37 CEST] <JEEB> also it's highly likely that the internal pthreads implementation of posix threads is utilized [21:22:42 CEST] <JEEB> which wraps around Windows threads [21:25:36 CEST] <JEEB> alright, moment of truth :) [21:27:07 CEST] <JEEB> doublya: seems like I got something working :) [21:27:16 CEST] <JEEB> let me commit and have you try it out [21:27:33 CEST] <JEEB> because this seems positive in config.log :) http://up-cat.net/p/35bfb8c7 [21:29:05 CEST] <JEEB> doublya: https://github.com/jeeb/ffmpeg/tree/alsa_pkgconfig_addition [21:29:17 CEST] <JEEB> or you can specifically cherry-pick https://github.com/jeeb/ffmpeg/commit/71b92aa9f92c89c8c7f5552d0caddb9aaadc6… [21:36:20 CEST] <Hink> how do i make a near-lossless 60fps .gif from a lossless 60fps video file? [21:38:48 CEST] <hanetzer> well, theoretically it should have found it, if its looking for -pthread as a linker flag. [21:39:40 CEST] <JEEB> hanetzer: ffbuild/config.log has the asnwer [21:39:45 CEST] <JEEB> in your build root [21:39:57 CEST] <JEEB> it contains everything that the configure script did [21:40:12 CEST] <hanetzer> JEEB: doesn't seem to, doing a bit of searching against the string 'error:' and 'pthread' [21:41:05 CEST] <hanetzer> but then again, the ffmpeg 'configure' script is some homegrown thingus I have very little idea how to parse ;P [21:41:28 CEST] <hanetzer> http://bpaste.net/show/490903f961fa [21:41:49 CEST] <JEEB> oh [21:41:58 CEST] <JEEB> you did enable-pthreads [21:42:13 CEST] <JEEB> if you leave it out it will default to the internal win32 thread wrapper [21:42:28 CEST] <hanetzer> but I have pthreads in my mingw-w64 toolchain. [21:42:36 CEST] <JEEB> (you can specifically pick it with --enable-w32threads [21:42:49 CEST] <JEEB> hanetzer: generally the internal wrapper was found to be faster than the mingw-w64 thing [21:42:55 CEST] <JEEB> you can test it yourself if you want [21:43:13 CEST] <hanetzer> JEEB: are you talking about libpthreadGC2 or the one with the mingw runtime? [21:43:21 CEST] <JEEB> libpthreadGC2 is the old one [21:43:28 CEST] <JEEB> mingw-w64 has a newer one AFAIK [21:43:33 CEST] <hanetzer> yep, which I have. [21:43:50 CEST] <JEEB> yes, and that one the last time people benched was slower than the wrapper inside FFmpeg (or x264) [21:43:58 CEST] <JEEB> but feel free to bench for yourself [21:44:37 CEST] <hanetzer> the main issue here is, if you can tell, I'm using gentoo and I'd have to have the upstream ebuild changed to not use pthreads on windows builds :) [21:44:58 CEST] <hanetzer> I'm just wondering why it is not finding my existant version of pthreads at all. [21:45:24 CEST] <JEEB> I see at least one pthread test succeeding [21:46:23 CEST] <JEEB> http://up-cat.net/p/db06c9dc [21:46:34 CEST] <JEEB> and no errors around that [21:47:15 CEST] <hanetzer> which is why I'm here asking questions. everything seems to be alright. [21:49:51 CEST] <JEEB> poked -devel since I can't see the reason there [21:50:08 CEST] <hanetzer> should I hop in there? [21:50:15 CEST] <JEEB> you can if you want to [21:50:35 CEST] <JEEB> also darn, doublya timed out :P [21:50:48 CEST] <JEEB> anyone else doing alsa static here to check my pkg-config fix :P [21:51:58 CEST] <JEEB> although I already got an OK from jamrial so I guess I'll just do the git send-email [22:12:34 CEST] <koyglreg> What's the reason for TV having the 10-235 range while computers have 0-256? [22:12:53 CEST] <JEEB> you mean 0-255 [22:13:03 CEST] <koyglreg> JEEB: yes [22:13:13 CEST] <JEEB> and if you want the nitty gritty details it's 235 for Y and 240 for CbCr IIRC [22:13:28 CEST] <JEEB> anyways, it's because broadcast needs its integer based filtering and it needs some space to overflow [22:14:01 CEST] <JEEB> anyways, 99.9% of all YCbCr content you will find is limited range [22:14:04 CEST] <koyglreg> JEEB, what's integer based filtering? [22:15:07 CEST] <JEEB> I'm not going to go there :D [22:15:31 CEST] <JEEB> but basically, they need the overhead and that's why limited range YCbCr is a thing [22:17:31 CEST] <koyglreg> ok. i've been learning the difference between RGB and YUV. I almost always use -pix_fmt yuv420p for encoding videos, such as with libx264. now, you said 99.9% of all YCbCr content you will find is limited range. "yuv" in ffmpeg-speak means YCbCr, right? [22:17:36 CEST] Action: Mavrik goes to google integer based filtering. [22:17:51 CEST] <JEEB> koyglreg: no, the other way [22:17:59 CEST] <JEEB> there is no digital YUV [22:18:05 CEST] <JEEB> yet people keep calling YCbCr YUV [22:18:10 CEST] <JEEB> like with "yuv420p" [22:18:14 CEST] <koyglreg> JEEB: okay [22:18:20 CEST] <JEEB> so if we were going FFmpeg-speak it would be YUV :P [22:18:33 CEST] <koyglreg> right, so are you saying yuv420p is NOT YUV? [22:18:45 CEST] <JEEB> yes, since YUV as far as I remember is an analog thing [22:19:03 CEST] <furq> The scope of the terms Y2UV, YUV, YCbCr, YPbPr, etc., is sometimes ambiguous and overlapping. Historically, the terms YUV and Y2UV were used for a specific analog encoding of color information in television systems, while YCbCr was used for digital encoding of color information suited for video and still-image compression and transmission such as MPEG and JPEG. [22:19:10 CEST] <furq> thanks wikipedia [22:19:30 CEST] <JEEB> it's yes [22:19:38 CEST] <koyglreg> furq: that's some of what i've read already. so yeah, i got the impression there was some overlap [22:19:56 CEST] <JEEB> yes, colloquially YUV is used for YCbCr, just like in "yuv420p" [22:20:22 CEST] <koyglreg> so yuv420p is YCbCr? [22:20:25 CEST] <JEEB> yes [22:20:37 CEST] <JEEB> Y is luminance, C for chroma and b/r for blue/red [22:21:00 CEST] <furq> what's P [22:21:04 CEST] <koyglreg> so when you say almost all YCbCr content is limited range, do you mean from TV? or do you mean ALL digital videos, such as found on youtube? [22:21:07 CEST] <furq> oh, phase [22:21:15 CEST] <JEEB> koyglreg: pretty much everything [22:21:31 CEST] <JEEB> koyglreg: the only exception that's widely used is the FRAPS screen capture video format [22:21:39 CEST] <JEEB> and JPEG I guess? [22:21:44 CEST] <JEEB> which isn't a video format really [22:21:52 CEST] <koyglreg> I didn't realize that. For instance, I thought the "black" in my encoded videos was pure 0 black. [22:21:56 CEST] <Mavrik> Isn't JPEG also slightly modified YUV? :) [22:22:10 CEST] <JEEB> Mavrik: it's the BT.601 colorspace hardcoded, yes [22:22:12 CEST] <JEEB> IIRC [22:22:23 CEST] <JEEB> although I think JPEG has o9k parameters to define the colorspace [22:22:28 CEST] <Mavrik> Although, I might be wrong, you can encode RGB JPEG as well [22:22:29 CEST] <JEEB> that they kind of got right, I think? [22:22:32 CEST] <JEEB> yes [22:22:33 CEST] <Mavrik> Or did I mix something up? [22:22:35 CEST] <doublya> JEEB: Internet went down right when you send your link. I'll test in a bit [22:22:50 CEST] <JEEB> doublya: I already sent it to the mailing list but feel free to test :) [22:23:13 CEST] <koyglreg> Shouldn't we use RGB for internet/computer videos, so we can use the full range? [22:23:28 CEST] <furq> rgb doesn't compress as well [22:23:29 CEST] <JEEB> koyglreg: you still get compression benefits from separating colors from the luminance [22:23:35 CEST] <JEEB> RGB has information duplicated [22:23:52 CEST] <koyglreg> okay, but can you have full-range YUV? [22:23:55 CEST] <furq> you can [22:23:59 CEST] <JEEB> theoretically, yes [22:24:04 CEST] <JEEB> as I said, FRAPS does it for example [22:24:21 CEST] <JEEB> but really, any content that you have around and want to play in most players has to be limited range if YCbCr [22:24:21 CEST] <furq> x264/x265 will encode full range [22:24:28 CEST] <furq> but i wouldn't trust any player to play it back properly [22:24:37 CEST] <JEEB> the sad point of it, yes :P [22:24:39 CEST] <furq> certainly not ones in web browsers [22:24:54 CEST] <koyglreg> okay... so obviously limited-range YUV digital video reigns [22:24:58 CEST] <kerio> how does RGB have duplicated info [22:25:07 CEST] <kerio> it's still three coordinates [22:25:14 CEST] <koyglreg> but why? it's not broadcast, it's digital [22:25:19 CEST] <furq> koyglreg: legacy [22:25:32 CEST] <BtbN> Also because it's smaller for not a lot of visual loss [22:25:35 CEST] <furq> never underestimate the power of inertia [22:25:45 CEST] <kerio> koyglreg: if backwards compatibility wasn't a thing we'd be using av1+opus probably [22:25:46 CEST] <JEEB> not really, kierank whacked everyone's head when they tried to say it was legacy reasons from the analog domain [22:26:02 CEST] <JEEB> it's just due to the fixed point / integer filtering stuff [22:26:12 CEST] <JEEB> so you have to have overhead in such broadcast systems :P [22:26:15 CEST] <koyglreg> JEEB: which I still don't understand [22:26:18 CEST] <JEEB> (until those get converted to floating point [22:26:38 CEST] <koyglreg> JEEB: when you say overhead, do you mean captions and stuff like that? [22:26:41 CEST] <furq> how is that not a legacy issue [22:26:54 CEST] <JEEB> well yes, but people usually mean legacy as in analogue [22:26:56 CEST] <JEEB> but sure [22:26:57 CEST] <JEEB> :) [22:27:14 CEST] <JEEB> koyglreg: nope [22:27:38 CEST] <JEEB> just the fact that when such non-floating point filters do their stuff they can overflow the range, which would otherwise not be pretty if there was no overhead [22:27:49 CEST] <JEEB> kerio: all of the things IIRC contain luminance [22:27:50 CEST] <furq> i mean legacy as in "people are using old shit and people who make new shit don't want to put up with complaints that it doesn't work with people's old shit" [22:27:56 CEST] <furq> and so the cycle continues forever [22:28:00 CEST] <JEEB> ok [22:28:14 CEST] <koyglreg> makes sense [22:28:17 CEST] <kerio> JEEB: and all the components in YCbCr contain red [22:28:31 CEST] <Cracki_> rgb is three times intensity. if you encode yuv, you have better separation between dimensions, can compress better. [22:28:42 CEST] <JEEB> (Ž4@) [22:28:47 CEST] <Cracki_> ¯\_(Ä)_/¯ [22:28:59 CEST] <kerio> U( )W [22:29:12 CEST] <koyglreg> can someone point me to a link that explains what fixed-point filters are? [22:29:20 CEST] <Cracki_> fixed point math [22:29:34 CEST] <Cracki_> as opposed to floating point [22:29:46 CEST] <Cracki_> fixed point is basically integer with shifts [22:29:49 CEST] <koyglreg> okay, a link to explain integer based filtering [22:29:54 CEST] <Cracki_> so faster on dumber hw [22:29:54 CEST] <koyglreg> I don't have any idea what that is [22:30:02 CEST] <Cracki_> any signal filter [22:30:13 CEST] <koyglreg> well, what's a signal filter? [22:30:19 CEST] <Cracki_> smoothing for example [22:30:21 CEST] <Cracki_> or deblocking [22:30:30 CEST] <JEEB> woah Cracki_ - you are compassionate :) [22:30:32 CEST] <Cracki_> or denoising, or a convolution, or a DCT [22:30:41 CEST] <koyglreg> hmm, well i know what filters are in general [22:30:41 CEST] <Cracki_> huh? [22:30:47 CEST] <Cracki_> am I feeding a troll or what do you mean [22:30:50 CEST] <JEEB> (I would have just given up explaining) [22:30:55 CEST] <koyglreg> but what does "signal" filter mean? [22:31:01 CEST] <JEEB> nah, just someone who has no idea about things [22:31:08 CEST] <Cracki_> i see now [22:31:36 CEST] <koyglreg> JEEB: you are correct - i'm not a troll; just someone with a skull full of mush [22:31:44 CEST] <koyglreg> teach me, o learned ones, the ways of ffmpeg [22:31:56 CEST] <JEEB> also lol at the "YUV" article on wikipedo. copypasta NV12 to RGB thing from Android [22:31:57 CEST] <Cracki_> you go zig, then you go zag [22:32:09 CEST] <JEEB> I wonder if it's BT.601 or BT.709 [22:32:25 CEST] <Cracki_> does it speak about OETF/EOTF/gamma? [22:32:26 CEST] <koyglreg> So tell me what a "signal filter" is [22:33:04 CEST] <JEEB> Cracki_: way higher level stuff that is :) it's the colorspace conversion stuff as far as I can tell [22:33:12 CEST] <Cracki_> the matrix [22:33:53 CEST] <Cracki_> well, wp:yuv looks not too bad [22:34:12 CEST] <JEEB> aww, colorspace.h in libavutil doesn't use the same calculations so I can't just check the numbers :) [22:34:24 CEST] Action: JEEB added BT.709 there for BD subtitles [22:34:43 CEST] <JEEB> (and yes, it's a yet another place where FFmpeg has the colormatrix stuff) [22:35:20 CEST] <Cracki_> why don't we just use 32 bit floats for everything [22:35:21 CEST] <koyglreg> ok, a different question. how common is interlaced x264? [22:35:29 CEST] <Cracki_> 23 bit mantissa, good enough for everything [22:35:54 CEST] <Cracki_> omfg kill everyone who does interlaced these days, and everyone they know and love [22:36:00 CEST] <JEEB> koyglreg: you mean interlaced AVC/H.264? x264 is an encoder [22:36:07 CEST] <JEEB> (that produces AVC/H.264) [22:36:16 CEST] <JEEB> in broadcast interlacism is still in high produce [22:36:23 CEST] <furq> yeah most broadcast 1080i is h264 [22:36:24 CEST] <JEEB> out of broadcast it is finally lowering down [22:36:37 CEST] <Cracki_> broadcast is over [22:36:41 CEST] <JEEB> web video generally tends to be progressive [22:36:49 CEST] <Cracki_> just dump to 50/60p [22:36:53 CEST] <JEEB> and blu-rays generally tend to be progressive as well [22:36:57 CEST] <Cracki_> *bump [22:37:05 CEST] <koyglreg> JEEB: hmm, yes. that is, using ffmpeg with libx264 to produce AVC/H.264. [22:37:05 CEST] <furq> i don't think i've seen any interlaced bluray [22:37:25 CEST] <furq> i sure have seen m2v bluray though [22:37:27 CEST] <furq> that's a lot of fun [22:37:55 CEST] <furq> actually the bluray i'm thinking of is 1080i, so yeah [22:37:57 CEST] <koyglreg> I have a bunch of home-recorded DVDs - low bitrate, not great quality. I've thought of encoding to interlaced h264/mp4. thoughts? [22:38:08 CEST] <furq> you're better off just deinterlacing them [22:38:29 CEST] <koyglreg> furq: would ivtc be even better? [22:38:36 CEST] <furq> only if they're telecined [22:38:45 CEST] <Cracki_> the good thing about interlacing: you see when someone doesn't know their shit [22:38:48 CEST] <koyglreg> furq: they're movies recorded from tv [22:38:49 CEST] <JEEB> furq: PAL stuff tends to be at least flagged interlaced since you can't officially do 25p in blu-ray :) [22:38:56 CEST] <furq> lol what [22:39:10 CEST] <JEEB> fake-interlaced in x264 is for that :D [22:39:13 CEST] <koyglreg> these are NTSC DVDs with movies [22:39:18 CEST] <JEEB> so that it gets flagged as 25i [22:39:23 CEST] <JEEB> but actual coded content is 25p [22:39:30 CEST] <furq> that is incredibly stupid [22:39:36 CEST] <furq> i thought we'd left that shit behind with dvd [22:39:42 CEST] <JEEB> blame whomever made up the BD spec [22:39:59 CEST] <furq> koyglreg: by movies do you mean like recorded off the tv [22:40:03 CEST] <furq> or home movies [22:40:05 CEST] <JEEB> although I think the same thing goes for 30/1.001 [22:40:12 CEST] <koyglreg> furq: yes, feature films [22:40:19 CEST] <furq> i mean [22:40:21 CEST] <JEEB> you can't encode it progressive so you have to do fake-interlaced [22:40:28 CEST] <furq> if you pirated them once then you might as well just pirate them again, but properly this time [22:40:55 CEST] <koyglreg> furq: these are my recordings [22:41:55 CEST] <furq> are you saying that makes it not piracy or that that gives some kind of sentimental value to these low-bitrate dvds [22:42:15 CEST] <koyglreg> furq: not saying anything [22:42:21 CEST] <furq> fair enough [22:42:45 CEST] <furq> well yeah if it was me i would probably throw them out unless i couldn't find a better quality copy online [22:43:02 CEST] <furq> of course i do not advocate piracy [22:43:06 CEST] <koyglreg> now if these have MOSTLY telecined content on them (movies), but segments (such as intro) that are "video", how could I ivtc? [22:43:07 CEST] <furq> (aside) i do. it's brilliant [22:43:17 CEST] <JEEB> koyglreg: manually [22:43:20 CEST] <furq> koyglreg: with difficulty [22:43:40 CEST] <JEEB> you'd have to filter it in pieces [22:43:47 CEST] <furq> generally what i do with that is i manually find and select the frame ranges in vapoursynth [22:43:52 CEST] <JEEB> yup [22:44:21 CEST] <furq> at least in theory. i've never actually bothered completing such an annoying operation [22:44:32 CEST] <JEEB> I did quite some time ago [22:44:40 CEST] <koyglreg> hmm ok [22:44:41 CEST] <JEEB> back then AvsPmod and avisynth were the tools :D [22:44:53 CEST] <JEEB> thankfully I only had the credits sequence of a TV show [22:45:10 CEST] <JEEB> so as long as I knew the point where those two separate I could just blast a good deinterlacer on the other side [22:45:14 CEST] <JEEB> and normal IVTC on the other [22:45:18 CEST] <furq> i only have one dvd that needs doing but it has a radial wipe from telecined to interlaced [22:45:28 CEST] <furq> and i really couldn't be bothered figuring out how i wanted to deal with that shit [22:45:45 CEST] <furq> it's in the intro as well so it's on every episode [22:45:48 CEST] <JEEB> I remember there was some nice blend filter for fades with combs [22:46:18 CEST] <JEEB> interlaced editing on a telecined show is the best, isn't it :) [22:46:46 CEST] <furq> you know it [22:47:24 CEST] <furq> i normally have it lucky with pal [22:47:45 CEST] <furq> the worst thing i commonly deal with is 50i titles and credits around a 25p show [22:47:55 CEST] <furq> which is incredibly simple by comparison [22:47:59 CEST] <JEEB> yea [22:48:34 CEST] <JEEB> doublya: any luck with the patch? [22:51:41 CEST] <koyglreg> let's say i have a bunch of ripped dvds in .mpg form and i don't want to re-encode them. lots of them need very simple filtering like cropping or changing the aspect ratio. can i put options like cropping/stretching in the video metadata for something? i mean, i doubt i can do it for .mpg, but maybe .mkv? or is there a video player that can remember settings for every video? [22:52:36 CEST] <furq> you can do both of those in mkv [22:52:52 CEST] <furq> player support for AR in the container is pretty much universal [22:52:54 CEST] <koyglreg> for instance, using MPC-HC with madVR, i can play .avs scripts. is this a bad solution? [22:52:58 CEST] <furq> idk about cropping but i assume it's less common [22:53:16 CEST] <JEEB> the cropping fields are unfortunately badly specified as they were originally meant to override the decoder cropping stuff [22:53:37 CEST] <JEEB> aspect ratio is just fine with matroska [22:54:07 CEST] <furq> iirc i tested cropping in mkv and it worked in mpv [22:54:14 CEST] <furq> so if you just want it to work there, you're fine [22:54:32 CEST] <koyglreg> what about playing .avs scripts in MPC-HC or another video player? [22:54:46 CEST] <furq> you can use vapoursynth scripts with mpv [22:55:11 CEST] <furq> maybe avs on windows, idk [22:55:34 CEST] <furq> ffmpeg will take avs as input but idk if mpv with lavf with avs support will do it [22:55:59 CEST] <koyglreg> not familiar with vapoursynth, but i get the idea. would you say playing scripts like that is a good solution for "permanently saving" those settings (beyond just ar) without re-encoding? [22:56:22 CEST] <furq> i wouldn't call it good but i can't really think of anything better [22:56:34 CEST] <furq> and VS is more or less the same thing as avs, just crossplatform [22:56:46 CEST] <koyglreg> furq: ah, i see [22:57:15 CEST] <koyglreg> are there media servers (like Plex) that support .avs? [22:57:27 CEST] <furq> no idea [22:57:29 CEST] <furq> i'd be surprised [22:57:37 CEST] <koyglreg> ok [22:57:54 CEST] <koyglreg> would you say vlc is the best overall media player for windows? [22:58:00 CEST] <furq> i would certainly not say that [22:58:50 CEST] <furq> mpv is probably the best, mpc-hc is all right [22:59:20 CEST] <koyglreg> how is mpv superior in your view? [22:59:44 CEST] <Fenrirthviti> mpc-hc is my go-to. [22:59:47 CEST] <Fenrirthviti> for windows. [23:00:08 CEST] <Fenrirthviti> but mpv isn't an abandoned project, so it has that going for it. [23:00:56 CEST] <koyglreg> Fenrirthviti, didn't know mpc-hc was abandoned [23:01:11 CEST] <furq> development stopped a few months ago [23:01:42 CEST] <furq> https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/ [23:02:11 CEST] <Fenrirthviti> They basically handed the project to the wild. It was sad :( [23:02:24 CEST] <furq> there are some commits on the repo in august [23:02:27 CEST] <furq> so maybe someone did step up [23:02:52 CEST] <furq> but yeah, afaik most of the mpc-hc developers moved over to mpv [23:03:06 CEST] <furq> as i'm sure other people in here can tell you about in more detail [23:03:36 CEST] <koyglreg> does mpv support .avs? [23:04:00 CEST] <JEEB> nah, most mpc-hc developers just passed onto the real life (and DShow not being too interesting I don't blame 'em) [23:04:03 CEST] <furq> i assume it does if it was built with ffmpeg with --enable-avisynth [23:04:06 CEST] <furq> but i've never tried it [23:19:02 CEST] <koyglreg> hmm, the mpg captions (from tv) are lost when it goes through avisynth... [23:29:23 CEST] <hanetzer> yark. [23:30:35 CEST] <hanetzer> Is there any plans on moving ffmpeg's build system to something standardish? for example, autotools/cmake/meson ? [23:31:03 CEST] Action: Mavrik smiles. [23:31:43 CEST] <JEEB> hanetzer: nope. someone would have to go through the work of implementing all those checks [23:54:37 CEST] Action: hanetzer volunteers as tribute [00:00:00 CEST] --- Tue Oct 17 2017

1 0