January 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190110
by burek 11 Jan '19

11 Jan '19

[14:51:59 CET] <cone-518> ffmpeg 03Linjie Fu 07master:e92ce340e630: lavc/qsvenc: add VDENC support for H264 [14:52:00 CET] <cone-518> ffmpeg 03Zhong Li 07master:0aaaca25e044: lavc/qsvenc: set pict_type to be I for IDR frames. [16:22:47 CET] <durandal_1707> is my SIMD patch OK? [16:36:14 CET] <atomnuker> durandal_1707: last I looked at it it had brackets on one line if statements [16:40:48 CET] <durandal_1707> atomnuker: why are you so anal about brackets [16:40:50 CET] <atomnuker> also if its sse only you can remove the xm* prefix from registers, unless you plan to avx it and you require 128bit regs [16:41:34 CET] <atomnuker> they waste a line, aren't in the coding style, and look ugly [16:42:12 CET] <atomnuker> its acceptable in x86/whatever_init.c if you plan on adding more versions of the function in the future as it'll reduce the diff by 2 lines [16:42:28 CET] <durandal_1707> ok [19:59:14 CET] <cone-518> ffmpeg 03Carl Eugen Hoyos 07master:34ca5adf9a77: configure: Fix hymt decoder standalone compilation. [20:02:35 CET] <jamrial> michaelni: does fate-checkasm-af_afir fail in any of your x86 machines? [20:03:00 CET] <jamrial> if so, can you check if changing FLT_EPSILON into something more lax fixes it? [20:03:02 CET] <cone-518> ffmpeg 03Carl Eugen Hoyos 07master:e52140ba3780: lavfi/Makefile: Fix bwdif filter standalone compilation. [20:12:03 CET] <cone-518> ffmpeg 03Carl Eugen Hoyos 07master:e51811d21598: lavfi/f_select: Fix aselect filter standalone compilation. [20:15:46 CET] <cone-518> ffmpeg 03Carl Eugen Hoyos 07master:02b6d1dd6306: lavfi/f_select: Cosmetics, move a function. [20:32:26 CET] <durandal_1707> if there are no comments i will apply x86 SIMD patch soon [20:36:46 CET] <iive> got link to the patch? [20:37:01 CET] <durandal_1707> iive: not for you [20:37:56 CET] <durandal_1707> iive: it is on patchwork [20:38:31 CET] <iive> huh? I thought all patches send to the mail list get on patchwork [20:39:19 CET] <jamrial> he said it is there [20:39:42 CET] <iive> oh, so he can give an url [20:41:43 CET] <durandal_1707> iive: url cost 5$ [20:42:06 CET] <michaelni> jamrial, "if (!float_near_abs_eps(cdst[i], odst[i], 1000*FLT_EPSILON)) {" seems to work on mingw32 400* fails on firsttry [20:42:57 CET] <durandal_1707> you should use 1/32768 and +1/-1 when converted to int16 [20:45:27 CET] <iive> durandal_1707, why are you using unaligned movups, when you have a code to allign them at the start? [20:45:47 CET] <durandal_1707> iive: i do not have aligned code [20:46:35 CET] <durandal_1707> i mean all data is accessed unaligned [20:47:03 CET] <durandal_1707> except for compute_cache but that one is already SIMDed by clang and I'm lazy [20:47:12 CET] <iive> what are the valid values of len ? [20:47:37 CET] <durandal_1707> iive: any number, even 0 [20:47:54 CET] <durandal_1707> actually for S it is >= 1 [20:48:08 CET] <durandal_1707> but that one is not useful much [20:48:29 CET] <durandal_1707> so number can not be and is not aligned to 16 [20:50:09 CET] <iive> yes, I see you have a *ss code at the end. [20:51:35 CET] <iive> is it possible to align the input buffers (f1/f2) or they could/should be from any position? [20:52:08 CET] <durandal_1707> no point in aligning, you would waste extra instructions for little gain [20:52:30 CET] <durandal_1707> this is moving windows of samples [20:56:03 CET] <iive> that's not the case for most sse processors. [20:56:29 CET] <iive> avx2 processors are fast with movu... i think. [20:56:42 CET] <durandal_1707> dead processors are dead [20:57:31 CET] <iive> it might also explain why your avx code was slower ;) [21:00:19 CET] <durandal_1707> iive: that was another code, with also aligned data [21:02:29 CET] <iive> are you sure this code works? [21:02:55 CET] <durandal_1707> why do you ask? is there something obviously wrong? [21:05:01 CET] <iive> the modification of f1/f2 pointers looks strange. you actually move them 1/4 length before the values given to the function. [21:07:28 CET] <durandal_1707> iive: they are decreased by len*4 so instead of -S to +S it goes 0 to 2*S+1 [21:08:24 CET] <iive> you mean len/4 [21:08:30 CET] <durandal_1707> no [21:09:00 CET] <iive> ok [21:09:06 CET] <iive> mybad. [21:10:50 CET] <iive> have you tried decreasing loop0 ? [21:11:08 CET] <durandal_1707> what? [21:11:19 CET] <iive> starting from lenq and going to zero? [21:11:33 CET] <iive> this way you combine add+cmp with a sub [21:11:43 CET] <iive> ... into a sub [21:11:50 CET] <durandal_1707> overall net change for this function is very low, so no point in losing too much time on it [21:14:06 CET] <iive> what does that mean? that your sse variant is not much faster than the pure C one? [21:14:42 CET] <durandal_1707> it is faster than C and what clang autovectorization does [21:18:21 CET] <iive> why are you using lend, when all the other uses are lenq ? [21:18:29 CET] <iive> aka 32 bit vs 64 it. [21:20:52 CET] <durandal_1707> no special reason [21:21:28 CET] <iive> if you want to handle buffers bigger than 4GB, then use only lenq [21:21:45 CET] <durandal_1707> no reason [21:21:55 CET] <iive> if you do not even think of that, then it is better to always use 32 bit registers. [21:22:20 CET] <iive> and since that code shifts, it is 1GB [21:31:41 CET] <jamrial> iive: using lend clears the upper 64 bits of the reg. it's useful when the argument is passed from stack in x86_64, but in this case it will always be passed directly in the reg, so it's mostly cosmetic [21:32:33 CET] <iive> jamrial, that's the problem, it would clip it [21:33:23 CET] <jamrial> it will not, it's an int [21:33:41 CET] <iive> ptrdiff [21:33:44 CET] <jamrial> oh, he made it ptrdiff_t. even less of an issue then [21:34:02 CET] <iive> isn't ptrdiff the size of a pointer? [21:34:07 CET] <jamrial> yeah, 100% cosmetic with no real effect [21:34:33 CET] <iive> explain [21:35:08 CET] <iive> len is 64 bit, lend would clip it. [21:35:56 CET] <iive> you should either go all 32 bit, or all 64 bit. [21:35:57 CET] <durandal_1707> such high len are not supported anyway [21:35:58 CET] <jamrial> len is an int, durandal_1707 changed it to ptrdiff_t since that simplifies simd [21:37:01 CET] <jamrial> len will never have a value bigger than 32bits wide. it can't since ptrdiff_t on x86_32 is 32bits wide [21:37:23 CET] <iive> and on 64 bit... [21:37:35 CET] <jamrial> i said it will never be bigger than 32bits wide [21:37:45 CET] <jamrial> because len is an int [21:37:58 CET] <jamrial> and this dsp function simply treats it as ptrdiff_t [21:38:25 CET] <iive> even so, it is shifted left, so *4 [21:38:33 CET] <jamrial> he can change it to lenq. it doesn'tr really matter [21:38:56 CET] <iive> once again, if len is never going to need 64 bits, then it should be lend everywhere [21:39:05 CET] <iive> mixing them is wrong. [21:39:21 CET] <jamrial> no, it isn't [21:39:30 CET] <jamrial> please, look at dozen other dsp functions [21:39:39 CET] <durandal_1707> omg, next time i will just shut up and apply patch [21:39:54 CET] <jamrial> it's a trick to clear the higher 32 bits of the regs when the argument is passed from stack on x86_64 windows builds [21:40:13 CET] <jamrial> in this case it does nothing [21:40:23 CET] <iive> jamrial, yes, but here it is not used as trick to clear the higher 32 bits [21:40:36 CET] <jamrial> no, it isn't. it's doing nothing [21:40:36 CET] <iive> jamrial, did you look at the code? [21:40:46 CET] <jamrial> yes [21:40:50 CET] <iive> it's just inconsistent. [21:41:14 CET] <jamrial> no, it isn't [21:41:19 CET] <iive> i've been told to alway use 32 bit, unless I do need it to be 64 [21:41:24 CET] <jamrial> look at any other dsp function. pick one [21:43:04 CET] <durandal_1707> changed lend to lenq locally [21:43:17 CET] <iive> :) [21:53:57 CET] <cone-518> ffmpeg 03Paul B Mahol 07master:dcae5ba322fc: avfilter: add anlmdn filter x86 SIMD optimizations [21:53:58 CET] <cone-518> ffmpeg 03Paul B Mahol 07master:395e8a53fa02: avfilter/af_anlmdn: use lut table to calculate weights [22:03:33 CET] <iive> one final thing, there was something where cpu's combine cmp with jxx , but it had some requirement for the conditional jump... [22:03:47 CET] <iive> basically saved one uop. [22:12:28 CET] <iive> ((x<<1)+1)<<2) should be the same as (x<<3+4) [22:15:20 CET] <iive> or rather ((x<<3)+4) [00:00:00 CET] --- Fri Jan 11 2019

1 0

ffmpeg.log.20190110
by burek 11 Jan '19

11 Jan '19

[02:57:58 CET] <foo> What makes more sense: a voice memo at 64 kBits with 2 audio channels, or a voice memo at 128 kBits with 1 audio channel? I'm looking for best experience with lowest file size [02:58:01 CET] <foo> thank you [03:00:47 CET] <klaxa> for a voice memo mono should be good enough [03:03:10 CET] <furq> did you put those bitrates the right way around [03:03:38 CET] <furq> anyway yeah mono is fine and opus should sound good at like 16kbps [03:06:29 CET] <foo> klaxa / furq - just realized, garageband must have took one channel and made it into two... in which case it's not even true stereo and one channel probably makes the most sense [03:26:38 CET] <foo> furq / klaxa - bah, garageband doesn't seem to have an option to make the audio mono, and 64 kBits sounds terrible. I think I'll export at 192 from garageband in stereo and then convert to mono with ffmpeg [03:32:24 CET] <foo> mp3 @ 0x7ff475000e00] overread, skip -5 enddists: -3 -3peed=40.7x - that's strange. [03:34:25 CET] <foo> What does that mean? [04:35:34 CET] <primenum> Launching several processes that perform encoding of audio and measuring stats via vmstat (user space cpu, mem) with the aim of finding a max # of simultaneous audio encodings. Should I consider other metrics? [06:40:08 CET] <ttgg> hi [06:40:37 CET] <ttgg> C:\>"c:\ffmpeg\bin\ffmpeg.exe" -r 1/5 -start_number 0 -i "C:\ffmpeg\imaages\*.jpg" -c:v libx264 -vf "fps=25,format=yuv420p" C:\test\out.mp4 [06:40:49 CET] <ttgg> C:\ffmpeg\imaages\.jpg: No such file or directory [06:40:59 CET] <ttgg> C:\ffmpeg\imaages\*.jpg: No such file or directory [06:41:03 CET] <ttgg> ? [06:44:01 CET] <ttgg> All my images are named "test (#).jpg" [06:44:34 CET] <ttgg> I can't get multiple image to single video conversion to occur, because it says it can't find those files, so I guess my question is, how would I assign an appropriate wildcard? [07:29:36 CET] <c_14> have you tried setting -pattern_type glob ? [07:29:48 CET] <c_14> though I'm not sure glob works on windows [07:29:52 CET] <ttgg> it doesn't [07:30:05 CET] <ttgg> This folder ONLY has .jpg images I want to use in it. [07:30:14 CET] <ttgg> Is there a "everything in this folder" wildcard? [07:30:40 CET] <c_14> if your images are named "test (#).jpg" can't you just use "test (%d).jpg" ? [07:31:00 CET] <c_14> though that only works if the numbers are sequential [07:32:12 CET] <ttgg> sweet, let me try that [07:32:41 CET] <ttgg> Trophy to you sir [07:32:49 CET] <ttgg> You have successfully helped a PEBKAC idiot. [07:32:53 CET] <ttgg> <3 [07:33:29 CET] <ttgg> Although... It seems like not too many frames [07:33:38 CET] <ttgg> I have 120 images in there, and it's definitely not using them all [07:33:59 CET] <ttgg> "c:\ffmpeg\bin\ffmpeg.exe" -r 1/5 -start_number 0 -i "C:\ffmpeg\imaages\test (%d).jpg" -c:v libx264 -vf "fps=25,format=yuv420p" C:\test\out.mp4 [07:34:16 CET] <ttgg> that gave me the video, but only 1 frame, the mp4 file is 72KB [07:34:34 CET] <ttgg> All of the images together are over 10MB [07:34:57 CET] <ttgg> it definitely didn't use them all, unless mp4 is some kind of quantum compression algorithm from the future. ;p ;) [07:35:08 CET] <ttgg> Going to have to check the wiseman score on that [07:39:01 CET] <c_14> use -framerate instead of -r [07:39:26 CET] <c_14> if you use -r it'll drop a bunch of frames [07:41:27 CET] <ttgg> tried it and getting the same thing with framerate [07:42:10 CET] <c_14> are there jumps in the frame numbers? i.e. 1, 2, 5, 6, 7 or something like that? [08:38:51 CET] <ttgg> no gaps [08:39:10 CET] <ttgg> test (1).jpg | test (2).jpg | test (3).jpg etc... [08:39:13 CET] <ttgg> all the way to 120 [08:43:42 CET] <ttgg> there was a break [08:43:44 CET] <ttgg> fixed it [08:43:51 CET] <ttgg> it does all the images now, thanks a ton guy! :D [09:29:55 CET] <ttgg> "c:\ffmpeg\bin\ffmpeg.exe" -framerate 1/1 -start_number 0 -i "C:\ffmpeg\imaages\test (%d).jpg" -c:v libx264 -vf "fps=40,format=yuv420p" C:\test\out.mp4 [09:30:11 CET] <ttgg> What can I edit here, to make the frames display fluidly? Right now it looks like a power point presentation [09:59:14 CET] <ttgg> figured it out [10:15:59 CET] <ariyasu> 1/1 is just 1 :p [19:20:42 CET] <cousin_luigi> Greetings. [19:21:47 CET] Action: cousin_luigi needs to transform a clip both by cropping away the black borders and also zooming in: is there a way to do so without having to reencode twice? [19:23:00 CET] <relaxed> yes, use crop,scale filter chain [19:44:06 CET] <Aerroon> would it be possible for me to detect a single color frame in a video? i'm trying to find if a video has a frame in it that's completely or almost completely green [19:44:58 CET] <Aerroon> and by green i meant red, oops [19:48:30 CET] <durandal_1707> see signalstats filer [19:48:48 CET] <Aerroon> ty [21:47:12 CET] <cousin_luigi> relaxed: thanks. [00:00:00 CET] --- Fri Jan 11 2019

1 0

ffmpeg-devel.log.20190109
by burek 10 Jan '19

10 Jan '19

[00:08:26 CET] <diggidydave> Hello all, I'm new to development using ffmpeg libs (and, generally, to av stuff), and I'm trying to get my bearings, so to speak... [00:08:52 CET] <diggidydave> I have a lot of cameras, each of which will sometimes be sending h264 encoded video via RTP to a dedicated endpoint. I was thinking I will have a broker that sets up the endpoint and ultimately causes a service to listen for that RTP data, and then it will do some other things with that stream. Right now, I'm trying to figure out the "entry point" into ffmpeg for that RTP data. [00:09:49 CET] <diggidydave> I have raw RTP packets coming in, and I can get the raw payload out of those of course. Can anyone point me towards any good examples of how to ingest RTP from UDP packets? [00:16:24 CET] <Compn> are you developing a patch for ffmpeg [00:16:26 CET] <Compn> or for yourself ? [00:17:07 CET] <diggidydave> this is for myself, am I in the wrong channel? [00:17:44 CET] <diggidydave> oh, man I didn't see the header up there. I saw the #ffmpeg message which seemed to suggest this channel, but I didn't see this one pointing my back there. :-) my aopologies [00:29:55 CET] <Compn> tno worries [16:07:25 CET] <durandal_1707> how to do horizontall add with avx/ymm? [16:17:51 CET] <atomnuker> of floats? 4 shuffles and 4 adds or 2 haddps [16:18:10 CET] <jamrial> durandal_1707: HADDD macro [16:19:19 CET] <jamrial> haddps and phaddd are very slow, so only use them when you want to add two regs horizontally the exact way the instructions handle it [16:20:57 CET] <atomnuker> isn't HADDD integer only? [16:27:50 CET] <jamrial> yeah [16:30:58 CET] <jamrial> if he wants to add horizontally all 8 floats in an ymm reg, it's vextractf128, addps, movhlps, addps, shufps, addss, using a tmp reg [16:56:55 CET] <jamrial> durandal_1707: see scalarproduct_float in libavutil/x86/float_dsp.asm [16:57:19 CET] <jamrial> after the loop is the horizontal add, including some x86_32 specific bits [18:14:38 CET] <durandal_1707> anybody see where i failed to rewrite this: https://github.com/richardpl/FFmpeg/commit/a7a594ec951f8a592359ab68043cde08… ? [18:16:54 CET] <BtbN> durandal_1707, first thing that springs to my eye is that v is reset between the two calls you have now, while previously it keps growing over the two for-loops [18:18:30 CET] <durandal_1707> BtbN: i use cache + S [18:28:12 CET] <durandal_1707> i found it [18:29:20 CET] <BtbN> What is it? [18:30:02 CET] <durandal_1707> v was not set, it should be 2 * S later in code... [21:20:02 CET] <cone-299> ffmpeg 03Paul B Mahol 07master:ed3b64402ef7: avfilter/af_anlmdn: ignore too small values [21:39:13 CET] <llogan> michaelni: got a rough idea when you're going to release 4.1.1? [23:13:15 CET] <thebombzen> I sent a patch a while ago to the mailing list but it had a problem, so I fixed it and sent v2 but never got a response. is it okay to bump it? [23:15:43 CET] <durandal_1707> yes [23:29:39 CET] <thebombzen> I ended up rerunning make fate and reformatting the patch and resending with git send-email but the patch contents should be the same [00:00:00 CET] --- Thu Jan 10 2019

1 0

ffmpeg.log.20190109
by burek 10 Jan '19

10 Jan '19

[04:39:11 CET] <FLX90> Hello, I'm trying to mux a video stream embedded in mkv from that mkv container to mp4 container (ffmpeg -r 24000/1001 -i test.mkv -map 0:0 -c copy test.mp4). Video stream has cfr 24000/1001 but ffmpeg thinks it is vfr. I tried the solution from here https://trac.ffmpeg.org/ticket/4768 and force framerate with -r. But that don't work. When I try to mux the raw h264 stream (ffmpeg -r 24000/1001 -i video.264 -c copy test.mp4) I get [04:39:11 CET] <FLX90> this message: "pts has no value time=00:02:38.19 bitrate=1312.4kbits/s speed= 154x". many times Can you help me? [04:40:24 CET] <FLX90> Tried with latest build of course. [06:36:31 CET] <tombert> howdy everyone; I am trying to generate an HLS stream using the m3u8 playlist thingy; I want the urls in the file to be formatted with http://blahblahblah.com/vids/thevideo [06:36:39 CET] <tombert> how do I go about specifying the format? [06:42:08 CET] <tombert> nvm, I figured it out; -segment_list_entry_prefix is what I needed [12:50:05 CET] <beta_alf> Hey, I am trying to integrate ffmpeg with an OpenGL Framework and I would like to get the state from the HW Decoder (NVDEC) directly to the OpenGL context, parallel to this: https://stackoverflow.com/questions/49862610/opengl-to-ffmpeg-encode. Is such a thing possible? [13:21:35 CET] <victorqueiroz> is there any kind of advantage of using directly opus codec instead of using ffmpeg? (performance for example) [13:25:41 CET] <Elirips> Hello. I'm using ffmpeg to extract frames using a cmd-line like 'ffmpeg -i rtsp://.. -r 5 -an -s 100x100 -q:v 2 -updatefirst 1 -y c:\myfile.jpg' [13:26:02 CET] <Elirips> this works fine, but since some version of ffmpeg, ffmpeg first writes to a c:\myfile.jpg.tmp and then seems to copy that file to c:\myfile.jpg [13:26:11 CET] <Elirips> is there any way to prevent it from creating the tmp file? [13:51:54 CET] <jcelerier> hello :) [13:52:15 CET] <jcelerier> when linking with ffmpeg 4.1 on linux, I'm having the same linker errors that are mentioned here: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg73506.html [13:52:27 CET] <jcelerier> does anyone have an idea of where it could come from ? thanks ! [14:00:45 CET] <Elirips> ah, with a more recent ffmpeg, no .tmp file is generated when using 'update' [14:35:11 CET] <DHE> jcelerier: sounds like you have the libraries out of order when linking. the gcc linker is single-pass only (unless you use the messy parameters to do multi-pass) [14:35:34 CET] <jcelerier> DHE: yes, it was that indeed ! sorry for the noise [15:28:24 CET] <BtbN> Elirips, it will create a tmp file, and then rename it into place, so there are never half-written jpg files [15:32:54 CET] <Elirips> BtbN: not the most recent windows-built static binary I downloaed [15:34:05 CET] <Elirips> BtbN: the background is, in my case its not writing to a file, but to a named pipe, and with the hard-coded (?) .tmp file, I need to open two pipes, whats a little bit an overhead [15:35:01 CET] <kepstin> if you're outputting to a pipe, you should probably be using -f image2pipe [15:36:02 CET] <BtbN> The img2 muxer should auto detect writing to a pipe [15:36:22 CET] <kepstin> it might not if it's a named pipe (on the filesystem)? [15:36:34 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/img2enc.c;h=a09c… the logic looks pretty simple [15:41:21 CET] <Elirips> kepstin: uh, image2pipe [15:41:26 CET] <Elirips> never seen that [15:42:16 CET] <Elirips> hm, I'm just outputing to a file named \\.\pipe\my-pipe [15:42:23 CET] <Elirips> \\.\pipe\my-pipe.jpg [15:42:33 CET] <BtbN> oh god, Windows stuff [15:42:45 CET] <BtbN> no idea how _that_ is recognized [15:42:48 CET] <Elirips> I dont know if that AVFormatContext knows about that [15:42:54 CET] <Elirips> :) [15:43:45 CET] <kepstin> anyways, you can force the image muxer to use pipe mode by selecting -f image2pipe, and then it should just write the images out in sequence to the selected output filename whatever it is. [15:44:01 CET] <Elirips> this is great, thanks for the help! [15:50:16 CET] <Elirips> kepstin: this is indeed working, but how can I (on the other end of the pipe) then recognize the end of a "file"? [15:50:31 CET] <Elirips> If I do not use -f image2pipe, I get an EOF for every file extracted from the stream [15:50:55 CET] <Elirips> with the -f image2pipe I get an "infinite" stream of bytes and miss the end of a single image [15:51:35 CET] <kepstin> huh. i forgot about that kinda weird behaviour of named pipes. [15:51:51 CET] <kepstin> (in the case of jpeg, it's possible to parse the stream to see the boundaries, but yeah) [15:52:48 CET] <Elirips> hehe, yes I would like to avoid having the parse the data read [15:53:09 CET] <Elirips> I basically just need to copy every complete image to some other place [15:53:14 CET] <Elirips> (in memory) [15:53:44 CET] <Elirips> (and yes, it would be a lot smarter to just libffmpeg, instead of spawning external ffmpeg process that send their data via named pipes) [15:54:01 CET] <kepstin> well, libavcodec+libavformat, but yeah - that's what I'd recommend [15:54:04 CET] <Elirips> (but I really really failed at using ffmpeg to connect to a a lot of different streams) [15:54:22 CET] <Elirips> failed using libffmpeg, while with ffmpeg.exe it "just works" [15:55:24 CET] <Elirips> the problem is, I have tons of different cameras connected using rtsp, and with ffmpeg it "just works". [15:55:47 CET] <Elirips> while, if I would use the libraries, I think I would have to do a lot of things myself (connect rtsp, find correct stream, and so on) [16:42:45 CET] <GuiToris> hey, should I manually specify ; coder, context, slices and error correction when I use ffv1 version 3? [16:52:05 CET] <zerodefect> I have an Mpge-2 video wrapped in MXF. The spatial resolution of the clip is 720x480. Using the C-API, is it possible to decode it to a 720x486 AVFrame without doing a copy? I thought about pre-allocating the AVFrame buffers, but I've noticeed that 'avcodec_receive_frame' calls av_frame_unref() on the input AVFrame. [16:54:00 CET] <BtbN> You'll probably have to implement get_buffer yourself and then use the buffer you want there [16:54:39 CET] <zerodefect> Ah ok. I'll take a look. [16:55:19 CET] <DHE> Being able to specify my own buffers has been something I've wanted as well. Mainly because I was looking at doing some hugetlb things. [16:57:23 CET] <DHE> I didn't see an easy way to do it that didn't involve some pretty invasive code changes [16:57:29 CET] <zerodefect> :/ [17:04:57 CET] <kepstin> note that 720x480 mpeg video is usually ntsc lines 23-262 and 286-525 while 486 line video is typically ntsc lines 21-263 and 283-535, so you'd want the video to be offset down from the top of the frame, too :/ [17:08:54 CET] <zerodefect> Yes, correct. Those were my intentions. [17:18:02 CET] <zerodefect> I'm only going to use BtbN's suggestion if AV_CODEC_CAP_DR1 is set? [17:19:04 CET] <zerodefect> *I'm only going to be able to [19:24:21 CET] <victorqueiroz> How can I compile FFmpeg using CMake? [19:25:37 CET] <pink_mist> by yourself rewriting all the compilation stuff to use CMake instead of autotools [19:27:08 CET] <victorqueiroz> Is it possible to integrate FFmpeg in a CMake project? [19:30:55 CET] <DHE> you could just treat it as an external library that should already be installed into /usr/lib or whatever.... [19:34:04 CET] Action: Mavrik has a nice hunch he's trying to link it into an Android project :P [19:35:23 CET] <BtbN> Android rarely uses cmake [19:35:41 CET] <Mavrik> Uh. [19:35:54 CET] <Mavrik> That's a strange statement. [19:35:57 CET] <victorqueiroz> Mavrik: that's right! [19:36:12 CET] <BtbN> Last time I looked at android it was like 99% gradle [19:36:24 CET] <victorqueiroz> I'm heavily using NDK [19:36:42 CET] <victorqueiroz> It's hard to think in raw Makefile when you have CMake *-* <3 [19:37:04 CET] <Mavrik> BtbN, yes, and the Android Gradle plugin supports CMake as pretty much the only standard way of compiling C++ code. [19:37:18 CET] <Mavrik> BtbN, with the other option being the legacy ndk-build thing. [19:37:34 CET] <BtbN> that's horrible [19:37:44 CET] <Mavrik> BtbN, I fail to see how. [19:37:54 CET] <victorqueiroz> I'm just not sure how can I link ffmpeg in the project [19:37:59 CET] <Mavrik> victorqueiroz, the easiest way for me was to just build the ffmpeg libs three times using the configure stuff [19:38:22 CET] <Mavrik> and then configure -L / -l in CMake script for the android .so [19:38:35 CET] <victorqueiroz> Mavrik: using the Android toolchains? [19:38:54 CET] <Mavrik> Yeah, setting compiler, linker and base path to NDK compilers [19:39:09 CET] <Mavrik> It was awhile ago so I used GCC... no idea if ffmpeg compiles with clang these days. [19:39:15 CET] <BtbN> FFmpeg, or really any lib, on android is really no fun. They don't support sonames or anything iirc [19:39:33 CET] <Mavrik> Static linking is the way to go :) [19:39:46 CET] <Mavrik> But I agree, lack of CMake supports makes it no fun ;) [19:40:00 CET] <BtbN> Even if ffmpeg used cmake to build, it wouldn't really help you much [19:40:42 CET] <Mavrik> It would save all the fsckery around dealing with different arches manually. [19:40:54 CET] <Mavrik> Since Gradle + NDK toolchain configures that rather well. [19:41:04 CET] <BtbN> You'd still need to setup an external project, cause you cannot just include external cmake project into a parent tree [19:41:50 CET] <BtbN> It should be possible to add ffmpeg as ExternalProject in cmake without too many issues, except that it will be annoying on Windows [19:42:54 CET] <Mavrik> Yeah, windows tends to be the headache. [19:44:43 CET] <BtbN> You need a shell and make in PATH [20:03:13 CET] <Aerroon> i'd like to generate proxies for editing with premiere [20:03:55 CET] <Aerroon> 1080p videos. what kind of encoder should i look into? i'd like to emphasize on speed of playback while still being 1080p so that text remains readable (but bitrate can be low) [20:06:51 CET] <BtbN> proxies? [20:07:00 CET] <BtbN> For video editing, you usually want lossless source material [22:10:10 CET] <flacs> am i right in my understanding that it's not possible to extend ffmpeg dynamically, e.g. write a plugin that ffmpeg dlopen()'s and includes in its codec list? [22:12:04 CET] <furq> yes [22:13:13 CET] <durandal_1707> you can use ladspa lv2 frei0r plugins [22:13:23 CET] <flacs> for a video codec? [22:13:32 CET] <durandal_1707> not for that [22:31:10 CET] <GuiToris> hey, should I manually specify ; coder, context, slices and error correction when I use ffv1 version 3? [00:00:00 CET] --- Thu Jan 10 2019

1 0

ffmpeg-devel.log.20190108
by burek 09 Jan '19

09 Jan '19

[01:58:16 CET] <cone-430> ffmpeg 03Michael Niedermayer 07master:038d291b70bf: avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row [09:12:13 CET] <durandal_1707> atomnuker: i'm very dissapointed [12:22:03 CET] <cone-914> ffmpeg 03Peter Ross 07master:2659a0fe3632: avcodec/vp3data: use more compact data type [13:45:44 CET] <atomnuker> durandal_1707: don't be, I bet you get no mold over there to waste half a day cleaning only for it to grow back in a week [13:46:46 CET] <durandal_1707> atomnuker: where you live? it is dangerous? [13:53:38 CET] <kierank> atomnuker: same in the office, cleaned it a month ago and it's coming back [14:41:03 CET] <atomnuker> durandal_1707: not even in a basement, on the 3rd floor [14:47:56 CET] <Compn> touchpad is the best [14:48:10 CET] <Compn> i need a new touchpad mouse [15:39:40 CET] <durandal_1707> Compn: mplayer is dead, hooraay [15:44:08 CET] <BBB> is it? is it? [15:45:04 CET] <durandal_1707> why you typed same thing twice? [15:45:10 CET] <BBB> excitement [15:51:59 CET] <durandal_1707> if human neurons were stored in RAM how much would it take? [15:55:27 CET] <thardin> you could build a little fort out of RAM stick and put a brain inside it [15:55:32 CET] <thardin> sticks [16:23:12 CET] <atomnuker> durandal_1707: welp, its kinda difficult to define [16:23:30 CET] <atomnuker> what stores neuron state such that if "resumed" it'll execute the exact same operations [16:24:20 CET] <atomnuker> there's an internal state within the neuron itself which accumulates and upon an adapted treshold fires whatever's connected to the axon, be it a single other neuron/no neurons at all/multiple neurons [16:24:47 CET] <atomnuker> but the really messed up thing is how the individual connections to each neuron are stored [16:25:17 CET] <atomnuker> e.g. the weight of each connection to the neuron from other neurons [16:25:45 CET] <atomnuker> and its the distance the charge has to travel to reach the center [16:26:45 CET] <atomnuker> so if you wanted to store an ideal copy, you'd need the positions of pretty huge amount of atoms inside the brain, plus their states [16:29:21 CET] <thardin> there's evidence that there's quantum effects at play too, so that may not necessarily be enough [16:29:28 CET] <atomnuker> indeed [16:29:51 CET] <thardin> it might not actually be computable, despite what transhumanists would have you believe [16:29:59 CET] <BradleyS> what if most of the brain's atoms are inert gases [16:30:32 CET] <atomnuker> thardin: that way no, but I really don't think its necessary to emulate the electrochemistry of neurons perfectly [16:30:57 CET] <thardin> perhaps not. depends on what you want to do [16:31:24 CET] <thardin> openworm has a simulation of c. elegans "brain", which may or may not be accurate [16:31:44 CET] <atomnuker> that's the thing if accurate == accurate in the real world [16:32:12 CET] <atomnuker> but what if you need accurate == good enough to function and survive within its new environment [16:32:47 CET] <atomnuker> sure, it'll deviate from real world behavior but it'll work and function exactly as before on a macroscale [16:36:58 CET] <durandal_1707> atomnuker: what about commenting patch? [16:38:33 CET] <atomnuker> I didn't see anything code-wise that looked wrong but I still need to test it [17:40:20 CET] <atomnuker> jamrial: can libdav1d now render to user-given frames? [17:43:29 CET] <durandal_1707> due to lack of comments and force i will apply anlmdn asap! [17:43:51 CET] <jamrial> atomnuker: i think so, but afaik we can't use get_buffer2() with it [17:44:11 CET] <jamrial> we can't ensure the constrains will be met [17:44:39 CET] <BBB> atomnuker: dav1d's constraints are that the buffer needs to be superblock aligned [17:44:46 CET] <BBB> atomnuker: and ffmpeg doesn't guarantee that, sadly [17:45:08 CET] <BBB> we can fix the decoder to not need that, I did that for ffvp9, but I'd rather fix it on the ffmpeg side [17:46:52 CET] <durandal_1707> why is that really needed? [17:48:20 CET] <kierank> durandal_1707: https://www.youtube.com/watch?v=4JWgmv92fQk [17:49:53 CET] <atomnuker> BBB: IIRC users ask lavc for alignment value [17:50:21 CET] <BBB> durandal_1707: the alignment to superblocks? [17:50:40 CET] <BBB> because blocks can be up to 128x128, and can extend the visible frame up to (I believe) 63 pixels [17:50:55 CET] <atomnuker> yep, users call avcodec_align_dimensions2() to get the stride/w/h aligns [17:50:57 CET] <BBB> so if you have a buffer of width X, you can write up to [x+62] [17:51:02 CET] <atomnuker> with a configured avctx [17:51:21 CET] <BBB> and libavcodec only guarantees alignment (and thus edge extension) of up to 31 (or maybe it's 15 now on some systems) [17:51:36 CET] <BBB> alignment of 16/32 of course, and thus extended width of up to 15/31 [17:51:47 CET] <BBB> wihch means dav1d can overwrite the next line's start [17:51:49 CET] <BBB> which we don't want [17:52:14 CET] <BBB> so, avcodec's get_buffer constraints are not compatible with dav1d's get_buffer requirements [17:53:02 CET] <BBB> at the ottom of the frame, it's worse [17:53:06 CET] <BBB> since we don't align height at all [17:53:10 CET] <BBB> but we have the same requirements [17:53:21 CET] <durandal_1707> there is some code that does it [17:53:22 CET] <BBB> so we can overwrite up to 63 lines, all of which basically overwrite the top of the chroma plane [17:53:31 CET] <BBB> so same conclusion [17:53:41 CET] <atomnuker> BBB: where is it documented that get_buffer only supports alignment of 31 max? [17:53:51 CET] <BBB> it's not documented, it's how it's implemented [17:53:56 CET] <atomnuker> where? [17:54:15 CET] <BBB> utils.c? [17:54:23 CET] <atomnuker> its the users that do the alignment in case of DR [17:54:31 CET] <BBB> I understand that [17:54:34 CET] <atomnuker> so? [17:54:37 CET] <durandal_1707> cant you use coded_width/height? [17:54:42 CET] <BBB> but if even the default implementation doesn't work [17:54:52 CET] <BBB> then how can I expect a user's custom implementation to work? [17:55:32 CET] <BBB> I'm sure you could use coded_* or some other solution [17:55:36 CET] <BBB> but that's not how it works right now [17:55:44 CET] <BBB> ffvp9 does double buffering on edges [17:55:56 CET] <BBB> and dav1d simply set wider cosntraints that are incompatible with ffmpeg's default implementation [17:55:57 CET] <BBB> so no DR [17:56:08 CET] <BBB> if you want to fix it, go for it, I have other things I'd rather do [17:56:18 CET] <durandal_1707> swscale [17:56:25 CET] <atomnuker> my point was it'll work for users without any changes [17:56:39 CET] <BBB> atomnuker: I tested it with ffvp9 and it did not [17:56:40 CET] <BBB> sorry [17:56:44 CET] <BBB> it did not work [17:56:56 CET] <BBB> I had to imlpement double buffering to get it to work [17:56:56 CET] <atomnuker> eh? but ffvp9 dr works [17:57:01 CET] <atomnuker> ah [17:57:03 CET] <BBB> yes, b/c I added double buffering [17:57:09 CET] <BBB> I'm not adding double buffering to dav1d [17:57:22 CET] <BBB> I instead changed the get_buffer constraints [17:57:25 CET] <atomnuker> surely it would have been simpler to just change the alignment requirements in utils.c [17:57:38 CET] <BBB> that's an API break [17:57:46 CET] <BBB> given that it means all users have to implement a new get_buffer callback [17:57:49 CET] <BBB> imagine that pain [17:57:52 CET] <BBB> I'd rather not [17:57:59 CET] <BBB> I udnerstand your point [17:58:06 CET] <BBB> but I don't think it's practical, it will cause huge pains [17:58:34 CET] <atomnuker> so get_buffer is documented to require no more than width + max 16(or was it 31) pixels of alignment? [17:58:52 CET] <BBB> I don'tknow how it's documented; but that's how it's implemented in the default implementation [17:59:01 CET] <BBB> and so I assume most custom implementations do that too [17:59:04 CET] <atomnuker> I'm just not sure where the API break would be [17:59:32 CET] <BBB> https://ffmpeg.org/doxygen/3.2/structAVCodecContext.html#a7c93198032a3a728b… [17:59:38 CET] <BBB> avcodec_align_dimensions2() should be used to find the required width and height, as they normally need to be rounded up to the next multiple of 16. [18:00:08 CET] <BBB> https://ffmpeg.org/doxygen/3.2/libavcodec_2utils_8c_source.html#l00260 [18:00:17 CET] <BBB> I don't want to change all that [18:00:35 CET] <BBB> the API break is that some implementations that used to work, no longer work [18:00:38 CET] <BBB> and they fail silently [18:00:46 CET] <BBB> that is, they return memory, and then it crashes [18:01:11 CET] <BBB> now, these may be implementations that don't call avcodec_align_dimensions2 as they should [18:01:16 CET] <BBB> but they used to work and now they don't [18:02:59 CET] <atomnuker> they're using the API incorrectly and its their fault [18:04:31 CET] <atomnuker> and "as they normally need to be rounded up to the next multiple of 16." just implies some standard h264 alignment, not a max or min limit [18:10:46 CET] <BBB> I get it [18:10:48 CET] <BBB> I really do [18:10:53 CET] <BBB> but I'm not going to be the one changing it [18:10:54 CET] <BBB> sorry [18:11:06 CET] <BBB> you wanna fix it? go for it [18:11:07 CET] <BBB> I'm not doing it [18:11:23 CET] <BBB> from my perspective, there is no bug in dav1d [18:11:29 CET] <durandal_1707> OK you _NOT_ doing it [18:11:33 CET] <BBB> and I don't care enough to fix this particular bug in ffmpeg [18:11:39 CET] <atomnuker> I didn't say there is, and its not a bug here either [18:11:55 CET] <BBB> there is. you need to increase the 16 to 128 in that function [18:11:59 CET] <BBB> that is a bug [18:12:01 CET] <atomnuker> all one (someone) needs to do is add a case for AV1 in the dimensions fn [18:12:14 CET] <BBB> right now, DR with that implementation of get_dimensions won't work [18:12:19 CET] <BBB> that is a bug [18:12:23 CET] <atomnuker> BBB: some codecs already require aligns of 64 of both width and height [18:12:27 CET] <atomnuker> SVQ [18:12:40 CET] <atomnuker> it will [18:12:51 CET] <atomnuker> as long as an av1 entry is added to indicate 128 aligns [18:13:36 CET] <BBB> I've been saying that all along [18:13:38 CET] <BBB> it needs a change [18:13:43 CET] <BBB> and I'm not making that change [18:13:46 CET] <BBB> not worth it for me [18:13:50 CET] <atomnuker> no, you're not [18:13:51 CET] <BBB> you wanna make that change? go for it [18:13:54 CET] <BBB> I'm not making it [18:13:54 CET] <durandal_1707> LOL [18:14:04 CET] <BBB> "needs change" == "current version doesn't work" [18:14:12 CET] <durandal_1707> i'm not making it either [19:12:55 CET] <durandal_1707> atomnuker: have you removed mold? [19:49:14 CET] <durandal_1707> atomnuker: i can no longer wait, will apply it [19:56:44 CET] <atomnuker> yeah allright, patch applied, going to test it now [20:14:13 CET] <atomnuker> durandal_1707: gave it a go, sounds very good [20:14:24 CET] <atomnuker> the n option doesn't seem to do much though [20:14:36 CET] <atomnuker> the filter seems to always consume 2 cores [20:15:09 CET] <atomnuker> and code-wise remove the brackets around 1-line statements in compute_distance_ssd() and filter_channel() [20:20:11 CET] <durandal_1707> atomnuker: i removed n option and do it automatically internally depending on number of samples in input [20:21:12 CET] <durandal_1707> atomnuker: i only do not like how it process very high frequencies, like loud breathing - it distort it too much [22:05:37 CET] <durandal_1707> cone-149 is not showing commits [00:00:00 CET] --- Wed Jan 9 2019

1 0

ffmpeg.log.20190108
by burek 09 Jan '19

09 Jan '19

[00:53:11 CET] <Neoflash> I keep getting a bunch of "error while deconding MB" errors, what do they mean? [01:23:31 CET] <iive> Neoflash, that's usually result of damaged bitstream [01:26:04 CET] <Neoflash> I have change the settings according to some article that I have found on the internet and it helped, I've got the stream going but the video is lagging about 10 seconds behind the camera. What would normally cause that? [01:57:35 CET] <DHE> buffering in the player is a normal thing, and some codecs do internal buffering as well. I think x264 buffers a couple of seconds unless you use -tune:v zerolatency (at your own risk) [01:57:41 CET] <DHE> oh he's gone... [08:00:04 CET] <jimgray> hey, guys. I have downloaded a dash audio with webm format, how to convert it to mp3? [08:00:21 CET] <jimgray> also i'd like to keep the quality as best [12:21:29 CET] <lavaflow> I'm playing around with the showspectrum filter and noticed that when I reduce the vertical dimension, the spectrogram scrolls faster [12:22:02 CET] <lavaflow> is this because it's faster to generate for a smaller vertical resolution? and what if I want it to stay slow? [12:22:14 CET] <lavaflow> the fps option doesn't help [12:22:27 CET] <lavaflow> command I'm testing with: ffplay -f lavfi 'amovie=in.mp3,asplit=2[out1][a]; [a]showspectrum=color=rainbow:scale=cbrt:slide=scroll:orientation=vertical:overlap=1:s=1366x700[out0]' [12:23:38 CET] <lavaflow> if I knock that s=1366x700 down to s=1366x100 or something like that, it scrolls really fast. Ideally I'd like to say "use the 1366 width to show N seconds" [14:03:04 CET] <durandal_1707> lavaflow: there is fps option, try adjust that one [14:17:46 CET] <fred1807> I found this line as an example how to stream a video with ffmpeg: ffmpeg -re -i video.mov -vcodec copy -f avi -an udp://239.0.1.23:1234 , please explain like I am five... Should I set the udp ip number to the ip number of my machine? Or I can leave this number from the example (and this ip will be "created" out of thin air) ? I know this may be a really dumb question... [14:22:21 CET] <kepstin> lavaflow: different height means it has to change the window size on the fft, which means each column corresponds to more/less time. [14:22:41 CET] <BtbN> 239.0.0.0/8 is multicast. And why would you use avi for that? Is that even streamable? [14:22:52 CET] <kepstin> lavaflow: you can always pick a size that results in a speed you like then just scale the height. [14:27:26 CET] <fred1807> BtbN: well that was the example I found... I dont know why it has -f avi.... [15:02:22 CET] <fred1807> I have this strange video format: Width: 608 pixels Height : 1 080 pixels Rotation: 270°. Locally, mpv plays it like it should, using the full screen. When I streaming this with ffmpeg -i video.mov -vcodec copy -f mpegts udp://239.0.1.23:123, the playing mpv rotates the video... [15:08:45 CET] <fred1807> maybe solution would be to encode the rotation, instead of using only a metadata? [15:11:02 CET] <BtbN> You'll need to copy the rotation metadata. I doubt mpegts supports it though. [15:36:24 CET] <fred1807> BtbN: Any suggestion? [15:39:44 CET] <DHE> a quick source code search suggests that only MP4/MOV supports rotation metadata, at least in ffmpeg [16:04:43 CET] <fred1807> -f mp4 results in error.. How can I stream in mp4 ? [16:15:28 CET] <DHE> mp4 isn't streaming-friendly, except that a finished mp4 with the right options can be played over "streaming" protocols like HTTP [16:25:55 CET] <Mavrik> Rotate the video and stream it like that, there's bunch of players that don't properly support the rotation flag anyway. [20:06:15 CET] <lavaflow> kepstin: ah good call, thanks [00:00:00 CET] --- Wed Jan 9 2019

1 0

ffmpeg-devel.log.20190107
by burek 08 Jan '19

08 Jan '19

[00:00:10 CET] <pross> kurosu_: nice find [12:38:42 CET] <durandal_1707> atomnuker: what do you think? [14:37:59 CET] <durandal_1707> cinepak: the return to ML ---> saga continues [17:30:07 CET] <BBB> fast decoder... vp8? [17:30:20 CET] <BBB> vp8 was a lot faster than h264 to decode (although also worse) [17:30:24 CET] <BBB> (in quality) [17:35:19 CET] <jamrial> if this is about that mips 100mhz email, maybe they shouldn't aim for 30fps and instead try 15fps. that's what old D.O.S., playstation and early windows games did for similarly constrained hardware and video resolution [17:40:34 CET] <durandal_1707> im sick of google patches [17:42:48 CET] <jamrial> why? [17:43:00 CET] <durandal_1707> google is cancer [17:48:42 CET] <kurosu_> pross, I'm not sure what I'm supposed to have found: I just remember seeing a ffmpeg ticket about a vp6 file that had decoding issues [17:49:12 CET] <kurosu_> the leaked vp6 decoder had the same issue iirc, and it looked like this (or the special "obmc" mode they had) [17:49:25 CET] <nevcairiel> vp6f is that flash variant isnt it, wouldnt be s urprised if thats full of hacks [17:50:57 CET] <kurosu_> pross, this one: https://trac.ffmpeg.org/ticket/1282 [17:51:00 CET] <kurosu_> I think [17:51:43 CET] <kurosu_> nevcairiel, I don't remember much, I think there was a sharpen setting besides the 'f', which indeed as I recall, stood for flash [17:52:50 CET] <kurosu_> like wmv9 (s/w decoding), it was so fringe I decided not to bother after a while testing [17:55:49 CET] <atomnuker> durandal_1707: that dumpwave filter? yeah, I don't like it either [18:00:38 CET] <jamrial> the fate tests they added are going to fail on some systems i bet [18:01:31 CET] <nevcairiel> filters that access files are always iffy and best avoided [18:01:46 CET] <nevcairiel> even more so if they dont even use avio [18:12:58 CET] <durandal_1707> nevcairiel: how you know that? filters that access files are just fine, the question is what they do really [18:13:24 CET] <nevcairiel> filesystem access is inherently insecure [18:13:26 CET] <nevcairiel> hence, iffy [18:13:45 CET] <durandal_1707> atomnuker: have you had chance to try anlmdn? i posted 2nd version [18:14:59 CET] <atomnuker> no, not yet, will try it in a few hours [20:53:15 CET] <durandal_1707> wtf, chrome put part of my paste into mail header, now you know what document i'm seeking [20:53:42 CET] <atomnuker> did you middle click somewhere? [20:54:27 CET] <durandal_1707> nope, and middle click would not be that perfect spot [20:54:56 CET] <atomnuker> you probably middle clicked somewhere [20:55:05 CET] <atomnuker> join the club, kill primary selection now [20:55:13 CET] <durandal_1707> nope, i use sway [20:55:29 CET] <atomnuker> still supported [20:57:34 CET] <durandal_1707> well i for sure did not pressed with three fingers, - have touchpad [20:58:40 CET] <durandal_1707> also when tried to paste after that it pasted nothing [20:59:28 CET] <atomnuker> touchpads are exactly the worst when it comes to mistakenly middle-clicking [21:00:06 CET] <durandal_1707> atomnuker: but how i would perfectly pasted it at that location? [21:00:07 CET] <atomnuker> in firefox you can thankfully disable it via middleclick.paste = false [21:00:37 CET] <atomnuker> literaly magic, middle click mistakes work like that [21:01:03 CET] <durandal_1707> no, this is chrome bug, developers are stupid [21:02:26 CET] <atomnuker> you should try firefox, it has wayland support [21:23:56 CET] Action: debianuser loves middleclick copy-paste - it's the best way to copy many short text snippets between two nearby windows (e.g. a bunch of irc messages into a shell script or a console output back into IRC window) - 1-click-select + 1-click-paste, nothing is faster than that (physical 2-button+wheel mouse here) [21:25:52 CET] <debianuser> (there's also secondary selection, for editing text files mostly: http://www.cs.man.ac.uk/~lindsec/secondary-selection.html but I never really got used to that) [21:38:00 CET] <atomnuker> if you have a mouse, yes, maybe [21:38:39 CET] <atomnuker> with a touchpad I've made a lot of middle clicking by mistake [21:40:01 CET] <durandal_1707> no sponsoring - no development any more [00:00:00 CET] --- Tue Jan 8 2019

1 0

ffmpeg.log.20190107
by burek 08 Jan '19

08 Jan '19

[00:07:51 CET] <DHE> because you've lost information from the original image. reversing it is naturally imperfect [00:09:02 CET] <ring0> BtbN, here I found some ffmpeg reference for using it in combination with a fpga on page 11: https://www.xilinx.com/publications/events/developer-forum/2018-frankfurt/s… [00:11:06 CET] <DHE> sure, but you need the programming for those FPGAs. I'm guessing it's not open or free... [00:11:49 CET] <DHE> also FPGA or ASIC based encoding has historically been of somewhat poor quality compared to what a CPU can do... my ryzen7 (first gen) can encode 1080p at 60fps realtime more efficiently than my nvidia card [00:12:55 CET] <ring0> you could do the implementation on your own with verilog/vhdl or use the non-free ip cores, sure [00:13:32 CET] <ring0> looking at history totally correct DHE [00:15:04 CET] <ring0> I also saw that ffmpeg has been in touch with this approach, looking at https://trac.ffmpeg.org/ticket/7214 [00:20:50 CET] <iive> DHE, depends how you define efficiently. I know somebody using nvidia pro card to encode above 16 HD streams realtime. [00:23:07 CET] <iive> so nvidia encoder is a beast. do they produce the same quality for that bitrate as x264 would get? probably no, but definitely doesn't need 16 separate computers. [00:24:02 CET] <iive> consumer/gaming cards use same encoder, the drivers just limit it to 1 or 2 encodes. [00:34:16 CET] <DHE> iive: it has the capacity. I have a somewhat old quadro (the kind that doesn't get the 2-streams-max limit removed) and estimated it could do 300fps at 1080p [00:34:27 CET] <DHE> even in its "best quality" mode [00:34:43 CET] <DHE> but x264 medium (defaults) preset at otherwise identical bitrate settings looks better than nvenc does [00:35:10 CET] <DHE> I've heard that the rtx2000 series has a new generation encoder that does better, but not seen it myself [00:52:56 CET] <iive> DHE, we totally agree. [01:25:02 CET] <Neoflash> Hello everyone. Man this feels weird. I haven't done IRC since 1998. I didn't know it was still around. Who needs Slack or Discord, amarite! [01:31:36 CET] <Neoflash> So I guess I'll start with an easy question: How the f@?% do I grok video. I am working on a small dev project that involves taking a live video stream coming from a remote camera on a UDP port and transmiting it to web browser clients with as little latency as possible. In trying to get this working I have stumbled on ffmpeg but I realize that I [01:31:37 CET] <Neoflash> don't know enough about digital video to make use of it. Where do I start? [01:32:17 CET] <klaxa> i guess wikipedia is good at giving general outlines [01:32:58 CET] <klaxa> https://en.wikipedia.org/wiki/Digital_container_format would probably be a good start? [01:33:38 CET] <klaxa> there are probably a lot of other good starting points [01:37:19 CET] <Neoflash> I already read that entry and bunch of others on digital video but I guess I still don't understand how it all fits together. For starters, what the heck am I getting on that UDP port? [01:39:04 CET] <klaxa> hard to know from just knowing it's udp [01:39:08 CET] <klaxa> probably rtp? [01:39:28 CET] <klaxa> https://en.wikipedia.org/wiki/Real-time_Transport_Protocol [01:39:45 CET] <klaxa> or rather maybe [01:40:56 CET] <Neoflash> I have also read that entry. How do I figure out if it's coming in thru RTP or just straight UDP messages? [01:42:07 CET] <klaxa> can you play it back? if not you can use wireshark to let that figure out what kind of packets you are receiving [01:42:29 CET] <iive> ffplay might be able to figure that out. [01:42:47 CET] <iive> UDP may also be mpeg-ts, but that is not very likely. [01:43:59 CET] <Neoflash> I was able to use ffplay didn't quite work for me but I was able use ffmpeg to save it to an mp4 file (just followed blog post, doc and tutorials without really understanding what any of it meant). The file works, I was able to play it. [01:46:18 CET] <Neoflash> I didn't know about Wirershark... seems like a good place to start. [01:51:48 CET] <friendofafriend> Neoflash: You'll need to find a server that will accept ffmpeg as a source and handle your web clients. I've used Icecast for that. [01:52:18 CET] <Neoflash> I guess one of the things I don't quite understand is how video can a video "file" be written and read live. How can a partial file be read, wouldn't it normally be considered corrupt, because it is missing so important information? [01:53:05 CET] <Neoflash> friendofafriend I am writing my own Node.js server. [02:04:50 CET] <Neoflash> Ok, I've installed Wireshark but I need to restart my computer. Thanks for the help so far, I'll be back later. [02:23:13 CET] <Neoflash> Hey I'm back with a fresh install of Wireshark and ready to test those UDP packets. I'll try to figure it out on my own and report back. [02:41:52 CET] <Neoflash> Ok, so there's a bunch of stuff coming in but as far as I can see, the packets on the part that I'm interested in are showing up as being UDP protocol and apart from a few exceptions here and there always have a payload of 1460 bytes. [02:44:21 CET] <Neoflash> Which would explain why I'm able to just feed them to ffmpeg without any other kind of preprocessing I guess. So where do I go from there. How do I figure out what exactly each packet's payload represents? [03:00:49 CET] <DHE> it depends on the container. RT[M]P isn't in my area of knowledge, but there are "file formats" that are streaming friendly, or RTP may act as both "container" and network transport at the same time and you don't worry about it... [03:03:11 CET] <meiamsome> If you successfully fed it through ffmpeg, wouldn't it have logged out what it worked out the format of the input stream is? [03:04:36 CET] <Neoflash> I did not notice anything like that, let me run it through again and see if it displays the format of the input stream. [03:11:08 CET] <Neoflash> Ok, I did a simple ffmpeg -i udp://192.168.10.1:11111 output.mp4 and it spewed out a bunch of stuff, of wich I understand pretty much nothing. What am I looking for? [03:12:10 CET] <Neoflash> On the bright side the output file works. [03:16:20 CET] <Neoflash> Here is a pastebin of whatever was logged: https://pastebin.com/RFasnY33 [03:37:39 CET] <meiamsome> Lines 101 - 103 seems to imply it's a raw h264 stream as far as I know how to read that [03:40:15 CET] <meiamsome> You could reasonably stream this directly to web browsers with WebRTC, perhaps if it is just h264 [03:46:14 CET] <meiamsome> otherwise, you could also generate HLS or MPEG DASH fairly easily which are formats for video streams over HTTP [03:47:37 CET] <meiamsome> WebRTC is better but harder imo, hls could be as simple as `ffmpeg -i udp://192.168.10.1:11111 output/master.m3u8` and then serving the output/ folder with a webserver and clients could use hls.js to play it out [03:54:18 CET] <meiamsome> So, as you say you are using node, you can probably run `npx http-server --cors` to serve up that folder, and then go here: https://video-dev.github.io/hls.js/stable/demo/ you could enter http://localhost:8080/master.m3u8 and theoretically it'd play, but ymmv [10:42:23 CET] <rocktop> is here any ffmpeg static and full without compiling ? [10:46:41 CET] <poutine> http://lmgtfy.com/?s=k&q=ffmpeg+static+builds [10:47:43 CET] <rocktop> poutine: yes I know this one but I am looking for full static version [10:58:28 CET] <rocktop> I have this issue Unrecognized option 'preset' [10:58:39 CET] <rocktop> any idea ? [11:01:08 CET] <Mavrik> We don't have a crystal ball. Provide more info. [11:07:17 CET] <rocktop> Mavrik: https://bpaste.net/show/fb600f0c5bc7 [11:07:39 CET] <Mavrik> You're ffmpeg version is beyond ancient. [11:08:01 CET] <Mavrik> We're at version 4.1 right now and you're at 0.6 [11:09:35 CET] <rocktop> oh yes sorry [11:09:54 CET] <rocktop> its ok now [11:09:59 CET] <rocktop> Thank you very much [12:42:49 CET] <oc1et> Hi all [12:43:25 CET] <oc1et> is it possible to provide the image of a waveform (not a spectrogram) and get the audio /wave file from it ? [12:48:29 CET] <durandal_1707> oc1et: that is not possible, unless you have infinite large images CPU and RAM [12:52:02 CET] <oc1et> thanks durandal_1707 [12:59:20 CET] <durandal_1707> or one use vectors to describe waveform... with bitmap its not possible in general [13:03:26 CET] <bruce-> your images will be finite sized, but it does seems a bit impractical to have (48000*seconds) x 65536 for 48khz/16 bit sound [13:04:39 CET] <bruce-> (mono) [14:59:00 CET] <Neoflash> Hey guys, so I have (what seems to be) a raw h264 stream coming in from a networked camera over plain UDP (see https://pastebin.com/RFasnY33) I am planning to use WebRTC Data Channels to stream the live video to web browser clients where I will use the MediaSource and SourceBuffer APIs to feed the video to a video Html element. I'm doing all of t [14:59:01 CET] <Neoflash> his from a NodeJs server. From what I can understand, I can't just pipe the raw H.264 to the media source and I need to containerize it first and this is where ffmpeg comes in. I'm looking for guidance on the best way to use ffmpeg to transform the raw feed and pipe it to the web browser in a way that will allow for extremely low latency (I need th [14:59:01 CET] <Neoflash> e client to see what the camera sees in real-time). I don't want the browser to have to wait and buffer, it needs to play the stream right away. Are there things I need to pay special attention to? [16:50:23 CET] <kepstin> nah, image of a waveform should be enough - as long as you have at least one pixel per sample horizontally, and 64K pixels vertically (for 16-bit audio) :) [16:50:39 CET] <kepstin> it will be huge of course, but not infinite. [16:50:55 CET] <kepstin> er, as bruce- said :/ [19:17:48 CET] <Neoflash> Anyone familiar with the Media Source Extensions Web API ? [00:00:00 CET] --- Tue Jan 8 2019

1 0

ffmpeg-devel.log.20190106
by burek 07 Jan '19

07 Jan '19

[14:19:19 CET] <durandal_1707> atomnuker: i improved performance drastically even without SIMD [19:14:09 CET] <cone-824> ffmpeg 03James Almer 07master:674b59c07515: avcodec/bsf_list: implement a AVBSFContext.flush callback [19:14:09 CET] <cone-824> ffmpeg 03James Almer 07master:4ec2daf0de1a: configure: add dxva2 extralibs to avcodec [19:34:43 CET] <cone-824> ffmpeg 03Michael Niedermayer 07master:96e495082aed: avcodec/huffyuvdec: Check that slice height is non negative. [19:34:44 CET] <cone-824> ffmpeg 03Michael Niedermayer 07master:ab160efa2850: avcodec/huffyuvdec: Check that slices do not exceed frame height [20:44:08 CET] <kurosu_> that vp4 loop filter rings a bell [20:44:54 CET] <kurosu_> I think the vp6 decoder isn't bit exact (4CC VP6F iirc), and I suspected this and mc to be wrong [20:55:24 CET] <atomnuker> BBB: why is the default trc for all=bt601 in vf_colorspace SMPTE170M instead of AVCOL_TRC_GAMMA28 which is "ITU-R BT470BG" according to the docs [20:55:41 CET] <atomnuker> when all=bt601 sets everything else to bt470bg [20:55:55 CET] <atomnuker> I just find it odd, the results come out looking correct [20:58:28 CET] <BBB> uhm [20:58:32 CET] <BBB> that's a long time ago [20:58:34 CET] <BBB> I don't know? [20:59:02 CET] <BBB> are they different? [20:59:10 CET] <BBB> I recall some trcs having different names but the same values [20:59:16 CET] <BBB> I don't know if that's true for these particular two [20:59:47 CET] <atomnuker> AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 [21:00:19 CET] <atomnuker> maybe what separates bt601 and bt470bg is just the trc, while everything else is identical [21:03:35 CET] <atomnuker> I can believe vp8 was blind enough not to have seen bt709 as the future [22:11:10 CET] <durandal_1707> atomnuker: do you want to comment anlmdn? [22:15:07 CET] <jamrial> durandal_1707: why not split compute_distance off into its own dsp context now instead of in a following patch? [22:15:29 CET] <atomnuker> durandal_1707: I'd like to test it first, do you have any noisy files? [22:16:12 CET] <durandal_1707> atomnuker: what kind of audio engineer does not have noisy audio? [22:17:31 CET] <durandal_1707> i have some librivox recordings, with different light to mid background noise [22:18:05 CET] <atomnuker> durandal_1707: the kind who works on digital audio, where analog noise is rare? [22:58:40 CET] <durandal_1707> atomnuker: get random librivox audio book and find file with enough of noise? other samples are more for voice extraction [22:59:30 CET] <durandal_1707> i could upload single sample though [23:03:43 CET] <durandal_1707> atomnuker: https://0x0.st/sRRb.mp3 [23:05:09 CET] <durandal_1707> defaul options values are for 8k sample rate, for 22050 rate multiply by 3 values r and p option default values [23:06:00 CET] <durandal_1707> anlmdn=n=10:p=100:r=400:s=300 for example [23:59:37 CET] <pross> kurosu_: vp56_mc looks very similar [00:00:00 CET] --- Mon Jan 7 2019

1 0

ffmpeg.log.20190106
by burek 07 Jan '19

07 Jan '19

[00:04:09 CET] <fella> ffprobe -show_streams -of csv INPUT 2>/dev/null | awk -F',' '{if ($6=="audio") print $2,$NF}' <- prints stream # and lang of any audio stream to be found in INPUT [00:14:43 CET] <fuxxy> fella, your example doesnt seem to show language in my test [00:15:23 CET] <fuxxy> ffprobe INPUTFILE -show_entries stream=index:stream_tags=language -select_streams a -of compact=p=0:nk=0 does work, but outputs a pile of data in front of the index=1|tag:language=eng [00:18:05 CET] <fuxxy> https://hastebin.com/obonanotal.bash [00:21:14 CET] <fella> one problem is, that not every INPUT has a default audio, afaik [00:22:05 CET] <fuxxy> hmm [00:25:13 CET] <fella> i mean, change 'ffprobe -show_streams -of json INPUT' --> under 'disposition' you'll find 'default' [00:25:25 CET] <fella> not every INPUT has default streams [00:25:49 CET] <fella> ^change^try [04:05:00 CET] <MichaelJoel> am I mistaken or isn't there a flag that causes ffmpeg to check and download the latest version? [04:06:42 CET] <pink_mist> pretty sure you're mistaken [04:07:17 CET] <MichaelJoel> probably - very odd I was almost sure I had done it [04:08:51 CET] <pink_mist> getting the latest version isn't as easy as downloading something and you're done - unless your distribution has binary packages for you to use, you'll need to recompile from source, which has lots of options to select from -- and if your distribution gives you binary packages to use, well, ffmpeg doesn't really want to haveto keep track of the packages for every version of every distro out there [04:30:48 CET] <DHE> long story short, ffmpeg itself doesn't really make precompiled packages [04:32:14 CET] <MichaelJoel> Ok - I just remembered... it wasn't ffmpeg it was another projet I was using with ffmpeg [04:32:20 CET] <MichaelJoel> project* [08:23:19 CET] <cluelessperson> how do you black/blur over an area of the frame/image using ffmpeg? [09:34:32 CET] <furq> cluelessperson: drawbox or delogo [10:39:37 CET] <th3_v0ice> Should I divide framerate by two if av_guess_frame_rate() returns 50/1, and actual fps is 25/1? Is this true for all interlaced cases? [17:24:09 CET] <murthy> How to repair a corrupt mp4 [23:17:04 CET] <lindylex> Hello all, I am trying to get this ffmpeg command to work ffmpeg -i t.mov -filter_complex "[0:v]crop=0:0:1280:330,boxblur=enable='between(t,0,60)=10[fg]'; [0:v][fg]overlay=320:330[v]" -map "[v]" -map 0:a -c:v libx264 -an -movflags +faststart -y c6_blur.mp4 I receive this error "[boxblur @ 0x55f77b194700] [Eval @ 0x7ffd938be140] Invalid chars '=10[fg]' at the end of expression 'between(t,0,60)=10[fg]'" [23:18:02 CET] <durandal_1707> =10 seems invalid [23:19:34 CET] <lindylex> What is valid? [23:19:56 CET] <durandal_1707> remove =10 [23:21:21 CET] <lindylex> This ffmpeg -i t.mov -filter_complex "[0:v]crop=200:200:60:30,boxblur=enable='between(t,0,60)=[fg]'; [0:v][fg]overlay=320:330[v]" -map "[v]" -map 0:a -c:v libx264 -an -movflags +faststart -y c6_blur.mp4 Gives me this ERROR >>> [boxblur @ 0x564a87d1b700] [Eval @ 0x7ffd1d746350] Invalid chars '=[fg]' at the end of expression 'between(t,0,60)=[fg]' [23:22:19 CET] <durandal_1707> you failed to remove = [23:22:26 CET] <lindylex> one sec [23:22:36 CET] <durandal_1707> probably multi byte chars [23:22:47 CET] <durandal_1707> copy paste fail [23:24:21 CET] <lindylex> https://pastebin.com/pL96qq3r [23:24:32 CET] <lindylex> Is that an cleare? [23:24:36 CET] <lindylex> clearer? [23:25:22 CET] <durandal_1707> no [23:25:53 CET] <iive> [fg] is probably video output, so e.g. [fg:v] everywhere might make it work [23:25:57 CET] <durandal_1707> mannually retype full command, as you have invalid characters in it [23:26:16 CET] <ring0> hi, is there any support from ffmpeg side for encoding using the capabilities of a fpga? [23:26:32 CET] <lindylex> fg is my video output. [23:36:11 CET] <ring0> so far I found this fork of ffmpeg from xilinx, which seem to add some fpga stuff to it https://github.com/Xilinx/FFmpeg-xma [23:37:15 CET] <ring0> any pointers would be highly appreciated :) [23:38:10 CET] <BtbN> nothing official, no. FPGAs don't sound very useful for that, they are quite static [23:39:23 CET] <ring0> well, there are devices, which feature a special video compression unit [23:40:06 CET] <ring0> to do h265/h264 encoding/decoding [23:41:27 CET] <BtbN> They are usually relatively or very bad and proprietary. [23:43:09 CET] <ring0> proprietary, yes indeed. bad with regards to fps while encoding, no. I did h265 encoding on 4k samples with ~100 fps [23:45:38 CET] <BtbN> bad in regards to looking horrible at bitrates where x264 looks flawless [23:46:18 CET] <ring0> I'll check that :) [23:47:46 CET] <ring0> also, I heard xilinx was going to work together with ffmpeg. but could have been marketing blabla, and they just manage to hand in a few commits at the best [23:51:29 CET] <ring0> anyways thanks for the heads up BtbN [23:54:22 CET] <terminalator> Forgive my ignorance, but how does one use ffmpeg to remove a watermark? [23:55:43 CET] <durandal_1707> you do not [23:57:44 CET] <terminalator> Why not? [00:00:00 CET] --- Mon Jan 7 2019

1 0