[01:56:54 CEST] <alexmarkley> hi, i'm trying to figure out how to affect webcam capture properties when doing avformat_open_input() [01:57:10 CEST] <alexmarkley> i'm trying something like this https://pastebin.com/uH2cv1Tr but it's not having the desired (or apparently any) effect [03:55:15 CEST] <alexmarkley> i'm still looking for a solution which allows me to tell video4linux2 to open the camera at a particular resolution [03:55:36 CEST] <alexmarkley> i must be missing something in the documentation [04:17:28 CEST] <alexmarkley> i'm seeing exactly what i want to do in the example on this page: http://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html [04:17:33 CEST] <alexmarkley> but it's not working for me [08:26:16 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [08:26:21 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it? [08:46:44 CEST] <freepoutine> did you mistype your bufsize? [08:48:28 CEST] <keglevich> hmm...I tried different values, from 80k, to 4000k, no difference really [08:49:21 CEST] <keglevich> lower value also helps keep stream a bit more CBR...bigger value more spikes and bursts [08:51:39 CEST] <keglevich> produced stream actually is CBR, but the issue is UDP output as it seems it sends packages as soon as they're available in some kind of bit-bursts...so it goes up and down like 2500k, 2700k, 2500k, 2700k, ..., etc. [09:53:16 CEST] <azaki> BtbN, ah, ok, thanks. i saw the av1 parser recently landed, so looks like it'll indeed make it into 4.1, that's sweet. [09:53:18 CEST] <azaki> =) [14:59:54 CEST] <ilushka4> Hey guys,I have no idea why my rtsp stream won't work. I tried asking in videolan forums but nobody responded. Here is the log: https://paste.ee/p/PilXq. Maybe it has to do with the codecs? [18:25:39 CEST] <keglevich> there are options like "bitrate" and "burst_bits" for UDP output.... if I set the "bitrate=260000", what's the suggested value for burst_bits? I can't find any info on that one... [19:21:04 CEST] <ilushka4> Hey guys,I have no idea why my rtsp stream won't work. I tried asking in videolan forums but nobody responded. Here is the log: https://paste.ee/p/PilXq. Maybe it has to do with the codecs? [19:21:51 CEST] <ilushka4> https://paste.ee/p/kp0DH (the link was broken) [19:23:37 CEST] <c_14> >Server returned 400 Bad Request [21:05:20 CEST] <w1kl4s> Hello, does anyone know if those issues are still around? [21:05:20 CEST] <w1kl4s> incorrectly uses BT.601 matrix for all content (results in wrong colors) [21:05:20 CEST] <w1kl4s> - colormatrix filter causes strong banding [21:05:20 CEST] <w1kl4s> - uses point upscaling for chroma planes and ordered dithering (low video quality) [21:06:49 CEST] <JEEB> w1kl4s: i think swscale does both bt709 and bt601 [21:07:29 CEST] <JEEB> but if you want high quality colorspace conversion then the zscale filter using the zimg library is what you want [21:07:56 CEST] <JEEB> i don't think even swscale by default uses point scaling for chroma tho [21:08:19 CEST] <JEEB> (swscale is used by the scale filter automagically) [21:08:32 CEST] <w1kl4s> I will be honest with you, you are speaking language of the gods to me [21:08:42 CEST] <w1kl4s> i have no idea about encoding and stuff, i am just a shitty dev [21:09:29 CEST] <w1kl4s> i wanted to make a program that compares videos with different sources, so ffmpeg was my best bet because it's avalaible on every system [21:09:36 CEST] <w1kl4s> but i found that on the wiki [21:09:49 CEST] <JEEB> basically, swscale has its issues but I don't think it's as bad as noted as long as you signal the colorspace correctly [21:10:01 CEST] <JEEB> oh, if you are doing static file comparison [21:10:20 CEST] <w1kl4s> yeah [21:10:23 CEST] <JEEB> look into vapoursynth and ffms2 [21:10:26 CEST] <w1kl4s> i wanted to pull out single frames [21:10:45 CEST] <durandal_1707> no, file comparison can be done with mpv [21:10:48 CEST] <JEEB> ffms2 is a wrapper around ffmpeg that is frame accurate [21:11:05 CEST] <w1kl4s> durandal_1707 i am using mpv right now gor that [21:11:07 CEST] <JEEB> it indexes the input [21:11:10 CEST] <w1kl4s> *for [21:11:20 CEST] <w1kl4s> but i wanted to make it automated [21:11:44 CEST] <w1kl4s> and MPV is kind of tricky to get stuff right without opening up interface [21:12:08 CEST] <w1kl4s> at least i didn't have any luck with that [21:13:07 CEST] <w1kl4s> JEEB i don't need indexed frames, timestamps will get the job done as well [21:14:14 CEST] <w1kl4s> i just wanted to know if those issues still persist for making screenshots using ffmpeg [21:14:20 CEST] <JEEB> the problem is that with not all containers are frame accurate in seeking. so even if you seek into a timestamp you might end up earlier or later [21:14:35 CEST] <JEEB> earlier not really a problem o 'course [21:14:52 CEST] <JEEB> since you can decode to the wanted timestamp [21:14:56 CEST] <w1kl4s> that shouldn't be a problem since i'm gonna be comparing diffrent sources anyway [21:15:04 CEST] <w1kl4s> so time diffrences are expected [21:16:24 CEST] <JEEB> also I'll say that some issues are still there but I think chroma and bt709/601 should be handled ok now? granted zscale will do it more fancily (or you can use zimg yourself due to the liberal license) [21:16:28 CEST] <JEEB> )6 [21:16:32 CEST] <w1kl4s> like i random a frame from source 1, get general timestamp of it, and using OpenCV i'll look for a frame that has highest similarity [21:16:40 CEST] <w1kl4s> and pull that one out [21:17:36 CEST] <durandal_1707> OpenCV ? what it does special? [21:18:34 CEST] <w1kl4s> well, look for proper frame to pull out [21:19:25 CEST] <durandal_1707> of all available? [21:19:25 CEST] <JEEB> i think marcan just used fft for that [21:20:10 CEST] <w1kl4s> no, i wanted to pull random frame from first source, and make openCV search like lets's say 5 seconds back and 5 seconds forth [21:20:43 CEST] <w1kl4s> pulled numbers out of my ass now, those will prolly need some fiddling to not make it sluggish as hell [21:20:54 CEST] <w1kl4s> while maintaining accuracy [00:00:00 CEST] --- Sun Oct 7 2018