Ffmpeg-devel-irc

Thread Start a new thread

Download

ffmpeg-devel-irc@ffmpeg.org

December 2019

1 participants
62 discussions

ffmpeg-devel.log.20191220
by burek 21 Dec '19

21 Dec '19

[00:00:00 CET] --- Fri Dec 20 2019

1 0

ffmpeg.log.20191220
by burek 21 Dec '19

21 Dec '19

[01:47:45 CET] <v`> o [01:47:59 CET] <v`> sorry, fumblefingers [01:49:38 CET] <v`> i'm looking at https://ffmpeg.org/ffmpeg-filters.html#Examples-19 [01:50:04 CET] <v`> specifically, "Another example for audio with whisper and explosion parts:" compand=0|0:1|1:-90/-900|-70/-70|-30/-9|0/-3:6:0:0:0 [01:50:46 CET] <v`> the "-90/-900|-70/-70|-30/-9|0/-3" part, that's the "points="? [01:51:21 CET] <v`> does that mean "0|0" is attacks and "1:-90" is decays? [01:51:36 CET] <v`> err, 1:-90 is decays? [01:51:48 CET] <v`> gah sorry [01:51:58 CET] <v`> 1|1 is decays? [01:52:36 CET] <v`> i'm so used to pipes being terminators that it's hard to get my eyes to see that colon is terminator here [01:56:54 CET] <v`> what does the pipe operator do there? [01:59:17 CET] <furq> you could also write compand=attacks=0|0:decays=1|1:points=-90/-900|-70/-70|-30/-9|0/-3:soft-knee=6 [01:59:36 CET] <furq> it'd be nice if one of the examples did that [02:00:32 CET] <furq> | is just a list separator [02:03:14 CET] <v`> wait, so "0|0" is just like saying attacks is zero for the first channel and then the 2nd zero in "0|0" sets the remaining channels' attacks to zero too? [02:04:44 CET] <furq> the second would be the second channel [02:04:54 CET] <furq> if you have 5.1 then you probably need 0|0|0|0|0|0 [02:05:00 CET] <furq> i've never used that filter though so maybe just 0 works [02:05:39 CET] <furq> If specified number of attacks & decays is lower than number of channels, the last set attack/decay will be used for all remaining channels. [02:05:42 CET] <furq> oh right [02:05:43 CET] <v`> i'm wondering because "If specified number of attacks & decays is lower than number of channels, the last set attack/decay will be used for all remaining channels." [02:05:52 CET] <furq> yeah you can just use 0 then [02:06:08 CET] <v`> wait, so, [02:06:20 CET] <v`> is attacks=0|0 the thing to do, or, [02:06:32 CET] <v`> is that the same as attacks=0, or...? [02:06:36 CET] <furq> should be [17:03:08 CET] <deltasquared> I'm currently attempting to re-encode some webm's that use vp8 for the video codec into h264 so that they play nicer with my phone's hardware decoding ability. just noticed that ffmpeg's defaults for the "slow" preset don't appear to be tolerated by my phone though at at least 720p and above. [17:03:30 CET] <deltasquared> (being played with the stock video player on a lineageos samsung galaxy S5.) [17:03:56 CET] <deltasquared> just going to copy the command I used and do some quick sanity ffprobe's... [17:04:12 CET] <kepstin> the preset only indirectly affects this, and ffmpeg doesn't default to slow [17:04:32 CET] <furq> deltasquared: -level 41 [17:04:32 CET] <kepstin> if you know what h264 profile the device supports, you can use the -profile option to tell x264 not to exceed that profile's limits [17:04:44 CET] <kepstin> or level, yeah [17:05:05 CET] <furq> it's pretty much always high at 4.1 [17:05:16 CET] <furq> and also i checked and it is for that phone [17:06:32 CET] <deltasquared> kepstin: I was trying to retain source quality where possible. I guess -crf would be a better way to achieve that [17:06:47 CET] <kepstin> deltasquared: preset affects encoding efficiency, not quality [17:07:06 CET] <furq> setting the preset is fine, you just need to ensure it doesn't exceed the max refs for the level your hwdec supports [17:07:18 CET] <furq> -level 41 should clamp it to the right number [17:08:31 CET] <deltasquared> I'll try playing with that setting and see if it'll play on one video first then try the others. [17:08:34 CET] <furq> with that said slow and slower should be fine at 720p [17:08:43 CET] <furq> that should only be an issue at 1080p [17:08:48 CET] <deltasquared> furq: there's a couple 1080p ones :P [17:08:55 CET] <deltasquared> thankfully nothing higher than that [17:09:08 CET] <deltasquared> (just as well, I only *have* a 1080p screen on the device!) [17:09:09 CET] <furq> anything above 1080p probably won't work at all [17:09:42 CET] <deltasquared> > 30.01 fps [17:09:43 CET] <deltasquared> wut [17:09:53 CET] <deltasquared> (just having a look at ffprobe output of one of the 1080p ones) [17:10:08 CET] <kepstin> https://www.qualcomm.com/products/snapdragon-processors-801 says it's supposed to to 4k, but i wonder if that's only hevc? [17:10:24 CET] <deltasquared> gosh, I have never tried h265 on this thing [17:10:24 CET] <furq> yeah it normally is [17:10:51 CET] <furq> 4k h264 needs level 5.1 iirc and basically nothing will hwdec that [17:11:04 CET] <kepstin> also different versions of that phone use different chips, so :/ [17:11:25 CET] <kepstin> could be a snapdragon 801, snapdragon 805, or exynos 5 octa 5422 [17:12:01 CET] <deltasquared> kepstin: I have the international version (klte) [17:12:26 CET] <kepstin> if you have the exynos version apparently it has hardware vp8 decoding [17:12:40 CET] <kepstin> whether that actually works in the os... ? :/ [17:12:48 CET] <deltasquared> not sure [17:12:59 CET] <deltasquared> the device gets very warm and often struggles playing anything webm [17:13:07 CET] <furq> are you sure they're not vp9 [17:13:27 CET] <furq> i don't think youtube does vp8 for hd resolutions [17:13:36 CET] <deltasquared> furq: hard to tell seeing how much of an asspull it is to get a linux chroot on it now with all the SELinux restrictions [17:13:42 CET] <deltasquared> furq: not youtube. [17:13:46 CET] <furq> oh [17:14:02 CET] <kepstin> ffprobe would say the actual codec [17:14:09 CET] <furq> i also don't know why anyone would use vp8 for 1080p but it's a big old internet out there [17:14:19 CET] <deltasquared> kepstin: in the case of the videos I have here they're all vp8 [17:14:20 CET] <furq> i'm sure someone's found a reason [17:16:10 CET] <deltasquared> furq: https://a.uguu.se/cAThGkcw6BrW_ffprobe.txt [17:16:26 CET] <kepstin> but yeah, h264 high profile level 4.1 is a good safe option. [17:16:33 CET] <ramiro> is there any diagram-based ui for ffmpeg and filters out there? [17:16:51 CET] <ramiro> kind of like gst-editor (which seems to be dead for over a decade) [17:16:56 CET] <furq> there's graph2dot but that's read-only [17:17:03 CET] <deltasquared> ramiro: something like unity's node graph say? [17:17:17 CET] <deltasquared> (or whatever engine that fancy shader editor belongs to) [17:18:26 CET] <ramiro> deltasquared: interesting. yes, something like that. [17:22:10 CET] <deltasquared> kepstin: "$input" -acodec copy -vcodec libx264 -level 41 "${input}.mp4" [17:22:19 CET] <deltasquared> still get a "can't play this video" when copied to the device [17:22:32 CET] <deltasquared> erm, missed the ffmpeg -i off the start of that [17:22:58 CET] <deltasquared> kepstin: what, of the ffmpeg run? won't that mangle the terminal escape codes? [17:23:28 CET] <kepstin> of the ffmpeg run, just need the text i don't care about colours or anything like that [17:24:55 CET] <deltasquared> it'd help if ffmpeg wasn't insisting on writing to stderr all the time >_> [17:27:11 CET] <deltasquared> kepstin: https://a.uguu.se/RnrmMhIAEy7Q_ffmpeg.log.txt there. [17:27:26 CET] <kepstin> it's usually easiest to just let it run then copy/paste the text from the terminal, but you can try the "-report" option if you're using a terminal with poor copy/paste support. [17:27:46 CET] <kepstin> (btw, if the stats line is scrolling for you, make the terminal window wider) [17:28:03 CET] <deltasquared> copy-pasting a large chunk of text is always gonna be clumsy even with good copy-paste. I just prefer to tee it. [17:28:12 CET] <kepstin> you're putting vorbis audio into an mp4 file, that's probably going to end with a bad time [17:28:16 CET] <deltasquared> ... [17:28:20 CET] <deltasquared> how did I not notice that [17:28:23 CET] <deltasquared> D: [17:28:27 CET] <deltasquared> FUDGE [17:28:30 CET] <kepstin> try "-c:a aac" (that should be the default with mp4 output) [17:28:41 CET] <deltasquared> kepstin: this thing can understand mkv so I may try that instead [17:29:00 CET] <deltasquared> at least that way the container supports the codec (I hope) [17:30:36 CET] <deltasquared> that appears to have worked. [17:30:53 CET] <deltasquared> kepstin: I guess that's why you wanted the terminal output huh. even supposed programmers miss the bleeding obvious at times >_> [17:31:01 CET] <kepstin> the video codec probably wasn't the issue all along [17:32:02 CET] <deltasquared> kepstin: perhaps not, but using just the defaults bar -level 41 does give visually acceptable results, so I guess I'm happy for now [17:32:07 CET] <kepstin> (honestly, i wouldn't be surprised if x264 was generating high profile level 4.1 from the start, at least on the 720p videos) [17:32:15 CET] <furq> yeah it should have been [17:32:31 CET] <furq> it'll be 4.1 or less unless you have more than 9 refs [17:32:49 CET] <furq> slow uses 5 and slower uses 8 [17:32:50 CET] <deltasquared> refs in this context being...? [17:32:53 CET] <furq> reference frames [17:33:22 CET] <kepstin> deltasquared: you can still use the -profile and -crf options in combination with profile/level to adjust quality and size tradeoffs, of course [17:33:50 CET] <furq> more reference frames is better for compressibility but it means the decoder needs a bigger buffer to hold them [17:34:11 CET] <furq> and obviously hwdec has a fixed size buffer so if you exceed that it just won't work [17:34:33 CET] <deltasquared> what would actually happen in practice? would it just stall and/or stutter perhaps? [17:34:40 CET] <deltasquared> (in the case you described) [17:34:56 CET] <furq> well the max refs used by the stream is signalled in a header [17:34:59 CET] <furq> so it would just bail out immediately [17:35:24 CET] <furq> or more likely fall back to software [17:36:00 CET] <deltasquared> well, in a correctly designed software stack perhaps... given the inability of the video player on this device currently to frameskip when it runs into trouble, I don't have that much faith in it [17:36:18 CET] <furq> it's probably falling back to software and then the cpu can't keep up [17:36:35 CET] <deltasquared> yeah but like why's it gotta stall for five secs or lock up completely :/ [17:36:39 CET] <deltasquared> something's not right in there [17:40:52 CET] <deltasquared> re: my acodec derp, that would explain why that "lower res" video worked as well... it didn't have an audio stream to begin with. x) [19:16:18 CET] <gp> Is anyone able to remove me from the users mailing list? I've tried a few times via the website and also by sending an unsubscribe email but no luck for about a month [19:16:45 CET] <gp> Or able to change it to a summary of conversations I haven't participated in [19:20:28 CET] <BtbN> There's instructions at the bottom of every E-Mail you get from the list. [19:20:37 CET] <BtbN> Just make sure to actually send from the address that's on the list. [19:22:50 CET] <phk> hi, i got have scale_npp filter in my ffmpeg [19:23:10 CET] <phk> i have completed with cuda [19:23:35 CET] <phk> and i see nvenc and cuvid encoder/decoders [19:23:48 CET] <phk> but i dont have scale_npp [19:24:37 CET] <phk> do i have to enable anything while compilation? [19:28:25 CET] <phk> ffmpeg version git-2019-12-08-9f7b2b3 Copyright (c) 2000-2019 the FFmpeg developers [19:28:25 CET] <phk> built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-39) [19:28:25 CET] <phk> configuration: --enable-gpl --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-version3 --enable-pic --enable-libfreetype --enable-libfdk-aac --enable-openssl --enable-shared --enable-libass --enable-libvpx --enable-libx265 --enable-libtwolame --enable-libpulse [19:28:25 CET] <phk> libavutil 56. 36.101 / 56. 36.101 [19:28:26 CET] <phk> libavcodec 58. 64.101 / 58. 64.101 [19:28:28 CET] <phk> libavformat 58. 35.101 / 58. 35.101 [19:28:30 CET] <phk> libavdevice 58. 9.101 / 58. 9.101 [19:28:32 CET] <phk> libavfilter 7. 68.100 / 7. 68.100 [19:28:34 CET] <phk> libswscale 5. 6.100 / 5. 6.100 [19:28:36 CET] <phk> libswresample 3. 6.100 / 3. 6.100 [19:28:42 CET] <phk> libpostproc 55. 6.100 / 55. 6.100 [19:28:44 CET] <phk> sorry pastebin isnt working [19:38:19 CET] <phk> NVIDIA-SMI 440.26 Driver Version: 440.26 CUDA Version: 10.2 [19:40:33 CET] <gp> btbn: I have sent the unsubscribe as instructed atleast a dozen times and gotten confirmation responses. I have also logged into the mailman interface and changed my subscription settings. But it doesn't seem to remember and I get like 20 emails some days [19:41:19 CET] <BtbN> Sounds to me like you unsubscribed the wrong address. [19:54:49 CET] <gp> Maybe so [19:55:16 CET] <gp> there isn't an option for a weekly digest is there [19:55:32 CET] <gp> ? I like to stay up on questions but I can't track the bursts of emails [21:24:55 CET] <bencc1> I'm getting "default: No such process" error inside debian stable container when trying to capture screen and audio: [21:25:14 CET] <bencc1> ffmpeg -f pulse -ac 2 -ar 48000 -i default -f x11grab -framerate 30 -i :0.0 -acodec aac -b:a 96k -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 -vf fps=30 cap.nut [21:36:15 CET] <bencc1> also getting the error when using: "ffmpeg -f pulse -i default out.wav" [00:00:00 CET] --- Sat Dec 21 2019

1 0

ffmpeg-devel.log.20191219
by burek 20 Dec '19

20 Dec '19

[00:00:00 CET] --- Thu Dec 19 2019

1 0

ffmpeg.log.20191219
by burek 20 Dec '19

20 Dec '19

[00:52:59 CET] <ncouloute> Can any one explain to me why you get a different frame of video depending on how you seek to a particular frame on most modern video players. Frame by frame forward to particular frame, jumping to a particular frame and Frame by frame backwards to particular frame. Seem to give me a different frame of video depending on the file. Some files don't do that but others do. (Tigher key frames perhaps). FFMPEG seems to give [00:53:00 CET] <ncouloute> me the frame I would get if I went frame by frame forward from the beginning of the file. [00:55:08 CET] <DHE> seeking must go to a keyframe or decoding cannot proceed [00:55:14 CET] <jokoon> ffprobe on webm doesn't yield a duration? [00:55:32 CET] <jokoon> only something in 'tags' ? [00:55:38 CET] <kepstin> some players seek to the first keyframe after the desired timestamp. others seek to the keyframe before the desired timestamp, decode and discard the extra frames, then start playing [01:03:09 CET] <ncouloute> Even within the same player I get different behavior. For example PotPlayer using LAV decoder... Jump to a frame and Rew to a frame I get the "future frame" (Frame taken from a later point in time). If I step frame by frame from the beginning I get the "older frame". Older frame seems to use older keyframe and future frame uses newer keyframe. If that is true then how can I know what frame I'm actually seeing.... [01:06:45 CET] <kepstin> also remember that most containers don't store frame numbers or count frames, instead each frame has a timestamp [01:06:59 CET] <kepstin> frames are (generally) uniquely identified by their timestamp [01:11:26 CET] <shibboleth> BtbN, DHE: the issue is def the resolution. looks like the vaapi can only handle "common" resolutions (720 and 1080) [01:11:34 CET] <shibboleth> re our convo y-day [01:12:19 CET] <furq> jokoon: duration is normally in -show_format [01:23:38 CET] <ncouloute> Even if i seek using time the issue still remains. It seems to be a matter of if I approach the time or frame going forward or backwards. I would imagine the accurate answer is when I go forward. When I go backwards the players seem to be guessing at what is suppose to be there. Same for when I jump to a frame. I would imagine the proper way would be to go the last keyframe before the point in time in question then [01:23:38 CET] <ncouloute> start decoding from there... Problem is I need to find out where the "guessed frame" actually is. I suppose I can just go to the nearest keyframe instead of trying to get accurate marks but thats giving up. [01:32:06 CET] <jokoon> [NULL @ 000001ebe993aec0] Unable to find a suitable output format for '[1:v]scale=320:180:force_original_aspect_ratio=decrease,pad=320:180:(ow-iw)/2:(oh-ih)/2,setsar=1[rescaled1]' [01:32:19 CET] <jokoon> is there something wrong in my filter? [01:32:31 CET] <jokoon> I should share the whole command [01:38:06 CET] <nicolas17> yes you should [01:38:41 CET] <jokoon> https://bpaste.net/show/RDEVW note those are lines passed as an array to python's subprocess.run() it takes care of spaces etc [01:38:59 CET] <jokoon> for now I get a [AVFilterGraph @ 000001f7a41edb80] No such filter: '' [01:40:42 CET] <jokoon> I'm doing both a concat and a xstack [01:40:55 CET] <jokoon> first scaling, then concat, then xstack [01:41:15 CET] <jokoon> not sure if -filter_complex is similar to -vf [01:58:35 CET] <jokoon> go to sleep, sorry [01:58:36 CET] <jokoon> https://stackoverflow.com/questions/59402005/invalid-command-with-ffmpeg-fi… [04:44:48 CET] <lavaflow> I have a load of mkv's with ass/ssa subtitles and I'd like to grep the subtitles to find files that contain particular words or phrases, is there a good way to do this? [04:45:09 CET] <lavaflow> right now I'm extracting all the subs using ffmpeg so I can grep them, but I'm wondering if there is a better way [04:45:25 CET] <TheAMM> There isn't [04:45:39 CET] <TheAMM> Not that I'm a bearer of absolute knowledge, but I've done did that as well [04:46:11 CET] <TheAMM> It's simply easiest to demux the subs and cache/store them for later use [04:46:24 CET] <TheAMM> Or, well, depends on what exactly you want [04:46:53 CET] <TheAMM> One thing to certainly keep in mind is to handle all the subtitles in one pass [04:46:53 CET] <lavaflow> bummer. this works well enough though I suppose [04:47:03 CET] <lavaflow> oh? [04:47:13 CET] <TheAMM> Multiple outputs [04:47:30 CET] <lavaflow> I'm running `ls *.mkv | xargs -I _ ffmpeg -i _ _.ass` [04:47:39 CET] <lavaflow> oh, right I see [04:47:40 CET] <TheAMM> Just one read pass to demux them, use named pipes as outputs [04:47:57 CET] <lavaflow> I think all of these only have a single subtitle track, but I'll have to keep that in mind in the future. [04:48:15 CET] <TheAMM> Requires something to handle the pipes but I've done my thing with 190TB of anime, so I have a bit of experience [04:48:26 CET] <TheAMM> Not authority but "done did that" experience [04:48:42 CET] <lavaflow> wew 190 TB, I'm pretty jealous [04:48:55 CET] <TheAMM> Not stored or anything, just processed [04:49:20 CET] <TheAMM> Got 13 million screenshots and ffprobe/mediainfo/subs etc etc etc extracted out of them, fun juicy data [04:49:32 CET] <TheAMM> But that's a different thing [04:49:39 CET] <lavaflow> dang, impressive [04:49:53 CET] <TheAMM> You can also stop demuxing early if you know you don't want to extract it all [04:50:05 CET] <TheAMM> (I'm figuring Python or something, here) [04:50:16 CET] <lavaflow> I've been thinking about an ffprobe dump for all the files on my nas but haven't done it yet [04:50:29 CET] <TheAMM> Spawn ffmpeg, read the output as it comes, see if lines have what you want [04:50:31 CET] <lavaflow> I've not used ffmpeg as a library before, only from the command line [04:50:59 CET] <TheAMM> You can also leverage ffmpeg beng able to convert text subtitles to a different format, like write just an ASS parser and have ffmpeg format SRTs as ASS [04:51:18 CET] <lavaflow> yeah, I've done that before. [04:51:21 CET] <TheAMM> Nah, I've never used ffmpeg as a library either [04:52:18 CET] <lavaflow> a while ago I was playing around with creating a DSL in racket or elisp to construct complex ffmpeg commands, with an emphasis on simplifying the creation of complex filter graphs [04:52:41 CET] <lavaflow> then I got to thinking that I should probably be using ffmpeg as a library for that sort of thing, then I kind of stalled out and didn't finish it -_- [04:52:52 CET] <TheAMM> I had a prototype of a thing that'd scan for all video files and extract subtitles to a local cache and index them for searching, but never finished that [04:53:16 CET] <TheAMM> Used the knowledge for the anime thing though, and then improved the tricks [04:53:32 CET] <TheAMM> Should one day get at it again but finishing things is haaaard [04:54:27 CET] <lavaflow> I think it would be cool to have a sqlite db filled with ffprobe dumps for all my media files [04:54:44 CET] <lavaflow> I think that might be a reasonable way to do it. [04:55:36 CET] <lavaflow> maybe subtitles could be thrown in there as well with sqlite's full text search extension, though I've not used that before so I'm not sure if it would be a good fit. [04:56:44 CET] <TheAMM> I had a LIKE search done, plan was to use ES for real text searching [04:57:46 CET] <lavaflow> elastisearch? that'd be neat [04:57:57 CET] <TheAMM> You'll probably want to uniquely identify your files, so my suggestion is to hash the first and last N bytes of them (like, 10+10 is more than enough) [04:58:30 CET] <TheAMM> Alongside a full hash too, but hashing the start and end (and maybe filesize to be paranoid) will allow you to quickly hash the files and check if they exist in your db [04:59:10 CET] <TheAMM> add mtime and path checking and you should have a thing that's fine to run over and over again quickly, without reading literally all the files every time [04:59:32 CET] <lavaflow> probably, though I think that ship has sailed for me. I already have like 90% of the files on my nas catalogued/tagged, using their full paths only as identifiers. [05:00:32 CET] <lavaflow> I could probably retrofit file hashes onto this system though [05:00:53 CET] <lavaflow> I'll have to give that some thought. there are definite advantages [05:01:25 CET] <TheAMM> Yeah, it's just something that'll withstand duplicates or moving stuff around without needing a full processing on the changed stuff [05:02:34 CET] <lavaflow> right. as it stands I do all my file management (moving, copying, etc) through my file tagging system, otherwise it would lose track of files [05:02:41 CET] <lavaflow> which is far from ideal [08:24:16 CET] <lain98> i called av_rescale_q with the parameters (0, 1/10000000, 1/25) and (170667, 1/10000000, 1/25) but i got zero in both cases. [08:24:33 CET] <lain98> not sure why [08:50:51 CET] <JEEB> lain98: the value seems to be less than 0.5 so highly likely the integer math ends up zero [08:51:25 CET] <JEEB> 0.0170677 seconds vs 0.04 seconds, latter of which is the smallest tick of 1/25 [10:06:55 CET] <jokoon> my xstack job is finally running [10:06:57 CET] <jokoon> frame=80000 fps=431 q=33.0 size= 9728kB time=00:00:00.07 bitrate=996775.0kbits/s dup=79993 drop=0 speed=0.000431x [10:07:18 CET] <jokoon> "More than 100000 frames duplicated" [10:07:31 CET] <jokoon> Seems something's wrong [10:07:56 CET] <lain98> ok i know why my math didnt work. [10:14:11 CET] <jokoon> wow encoding is super slow... [10:14:34 CET] <jokoon> I know my CPU is slow but it's only 35s of video [10:14:48 CET] <jokoon> at speed=0.000389x [10:15:13 CET] <jokoon> Guess I might need rescale video first [10:19:10 CET] <JEEB> lain98: basically `(170677 / 10000000) * 25` is how I checked - I think that's possibly correct :P [10:19:15 CET] <JEEB> and that gives me a value less than 0.5 [10:19:28 CET] <JEEB> so that even if you had double/float math and then were rounding, that would end up 0 [10:19:45 CET] <lain98> yes but also lack of sleep [10:19:50 CET] <lain98> :) [10:20:01 CET] <JEEB> :) [11:28:18 CET] <ufk> how can I send an image file to a v4l2 video device ? using 'ffmpeg -re -i binary-file.png -f v4l2 /dev/video0' returns Requested output format 'v4l2' is not a suitable output format [11:38:46 CET] <jokoon> Warning: data is not aligned! This can lead to a speed loss [11:38:54 CET] <jokoon> Frame rate very high for a muxer not efficiently supporting it. [11:39:22 CET] <jokoon> https://bpaste.net/show/H6272 [11:44:29 CET] <jokoon> MB rate (920000000) > level limit (16711680) [11:45:01 CET] <jokoon> trying to use filters: scale then concatenate then xstack [12:21:02 CET] <jokoon> Anybody using python? I'm sending this with subprocess.run() https://bpaste.net/show/32T2E and I'm not sure ffmpeg likes it [12:27:27 CET] <jokoon> also curious if mixing vp8 and other format would lead to those issues [12:28:18 CET] <DHE> macroblock rate is through the roof. you sure you got the framerates aligned? [12:29:03 CET] <jokoon> I was told to not care about framerate when using xstack [12:29:15 CET] <jokoon> maybe when doing concat? [12:29:25 CET] <jokoon> those are diverse formats [12:30:10 CET] <jokoon> https://i.imgur.com/vhpmoL1.png [12:30:32 CET] <jokoon> wait framerates are not shown [12:31:37 CET] <DHE> I think the PATH column is superfluous and all the other columns are shifted. 'rate' makes sense as a framerate [12:31:47 CET] <jokoon> yes I know [12:32:00 CET] <jokoon> this script is a clusterfungus [12:33:03 CET] <DHE> still, some of these are 100fps videos [12:42:55 CET] <jokoon> https://i.imgur.com/YoA2NVN.png [12:48:51 CET] <jokoon> https://i.imgur.com/QkxEzEU.png DHE [12:48:52 CET] <squ> what is this tool which tabularizes video information? [12:48:56 CET] <jokoon> some are 12fps [12:49:28 CET] <jokoon> should I normalize those fps then? [12:53:25 CET] <furq> 11:29:03 ( jokoon) I was told to not care about framerate when using xstack [12:53:26 CET] <furq> uhh [12:53:47 CET] <jokoon> not you, someone else :p [12:54:00 CET] <jokoon> rather, I was told to test, and come back for question [12:54:13 CET] <jokoon> and now I don't really remember how to normalize fps :x [12:55:46 CET] <jokoon> I don't understand why this doesn't work, because I did a xstack and it worked, I added concat to my script and testing it on very short videos, and now framerate is an issue where it was not an issue on other longer videos [12:56:13 CET] <jokoon> I suspect it might be caused by a few of those short videos Im testing the script [12:56:43 CET] <jokoon> im using those short video to test it, so ffmpeg can do it faster [13:02:41 CET] <jokoon> Im convert a gif to a vid and it result in a 100fps vid [13:02:53 CET] <jokoon> and it's defintely not a 100 fps gif [13:03:13 CET] <jokoon> this one [13:03:14 CET] <jokoon> https://giphy.com/gifs/reaction-boy-5DQvlC5vk5ihy [13:07:30 CET] <jokoon> -r 25 fixed this gif, still it's weird that ffmpeg chose 100 [13:07:39 CET] <jokoon> I converted many others and it was not 100 [13:15:01 CET] <b1nny> Hello, does anyone happen to know if there is a way to get CPU statistics per video filter? [13:15:44 CET] <ubitux> jokoon: sanest highest recommended framerate for gif is 50 [13:16:03 CET] <ubitux> b1nny: bench and abench [13:16:36 CET] <b1nny> ubitux: cheers! That seems like it will help me out :) [13:31:52 CET] <jokoon> squ, make this thing myself, it's just a python script generating some html [13:32:25 CET] <jokoon> also found a tiny bit of JS that sort a HTML table directly [13:32:30 CET] <squ> okey [13:33:30 CET] <squ> maybe you are interested https://twitter.com/alexlindsay/status/1199089615056982016 [14:16:56 CET] <jokoon> can '-r 30' work as a filter? [14:24:40 CET] <jokoon> just trying to normalize fps [14:29:02 CET] <DHE> there is an fps filter [14:29:14 CET] <DHE> maybe you just want to put it at the end of the filter chain [14:29:43 CET] <kepstin> jokoon: if your ffmpeg is old, you want to normalize fps before the concat filter [14:30:20 CET] <kepstin> if you ffmpeg is anything but latest git, you should definitely normalize fps before using any of the *stack filters. [14:31:01 CET] <jokoon> ffmpeg version git-2019-10-23-ac0f5f4 [14:31:02 CET] <kepstin> (actually, i'm not sure the concat fix is even in a release yet) [14:31:28 CET] <kepstin> hmm, that should have the concat fix but not the *stack fix. [14:31:42 CET] <jokoon> does that concat bug affect what I do? [14:31:53 CET] <jokoon> oh there's a xstack bug? [14:32:20 CET] <jokoon> Im still struggling to apply a fps or framerate filter [14:32:25 CET] <DHE> is it trying to select a framerate that is the LCM of all the inputs? [14:32:44 CET] <kepstin> xstack previously set the output framerate to the framerate of the first input [14:32:58 CET] <kepstin> now it sets it to 1/0 (vfr) if inputs have different framerates, i think [14:33:24 CET] <jokoon> DHE, well as you told me, it seems that ffmpeg calculate a fps that was too high, which might be caused my having too many different FPS in my inputs [14:33:35 CET] <jokoon> I have many video inputs, which are very diverse [14:33:51 CET] <jokoon> You used "through the roof" [14:34:02 CET] <DHE> I said the macroblock rate was through the roof [14:34:04 CET] <jokoon> I don't know how to avoid that LCM [14:34:14 CET] <jokoon> oh [14:34:15 CET] <DHE> which is explained either by a very high FPS, or an extremely large image. (or both) [14:34:22 CET] <kepstin> jokoon: you should stick an fps filter for each video in your filter chain, in the same place as where you're doing scaling. [14:34:26 CET] <jokoon> is 100 a very high fps? [14:34:33 CET] <jokoon> highest I saw was 100 [14:35:03 CET] <DHE> yes, considering hardware video decoders that are not GPUs tend to be limited to ~60fps at 1080p h264 decoding (level 4.1 or so) [14:35:18 CET] <jokoon> I found some doc but Im not sure it's the fps filter [14:35:33 CET] <jokoon> oh ok [14:35:49 CET] <kepstin> don't find "some doc", find the official ffmpeg filters documentation [14:35:53 CET] <jokoon> I was trying to remove those few 100fps vid [14:35:56 CET] <kepstin> conveniently linked off the ffmpeg site [14:36:52 CET] <kepstin> anyways, usage is simple for this. if you want to convert all your videos, to, say, 30fps, add the filter "fps=30" [14:51:02 CET] <jokoon> woooow it worked [14:51:16 CET] <jokoon> I put the fps filter after the rescale [14:51:39 CET] <jokoon> so [vidX]fps=30[vidfX] [14:52:01 CET] <jokoon> I've seen what fps=fps=30 meant but that was an issue too [14:53:30 CET] <jokoon> so happy [14:53:46 CET] <jokoon> 420 lines of python haha [14:54:15 CET] <jokoon> I guess mixing the sound won't be so hard [14:54:39 CET] <jokoon> https://gfycat.com/pastelfarflunggentoopenguin [17:16:33 CET] <TanaPanda> when I use ffmpeg to stream a video out to an IP address what command tells ffmpeg specifically which interface to use? I want it to sprecifically stream out of my eth0 [17:32:58 CET] <ncouloute> So this "player" behavior I was talking about before. Seems to be the same as input seeking. When I transcode a file I get the output seeking result. I need to figure out where the Input seek frame ends up. How does input seeking work? Is it just giving me the nearest key frame? [17:39:17 CET] <kepstin> TanaPanda: i don't think there's a way to bind to a particular interface, but you can set the local ip address to use (e.g. localaddr udp option), which should make it use the interface with that ip address assigned, i think. [17:39:56 CET] <kepstin> other than that, fix your routing priorities so the interface you prefer is the preferred interface. [17:39:58 CET] <DHE> depends on the OS. linus will use the routing table at all times to the best of my knowledge... [17:40:05 CET] <DHE> *linux [17:40:56 CET] <DHE> even if you're outputting to multicast, add the multicast addresses to your routing table as /32 entries (or shorter prefixes if you prefer and are doing many outputs) [17:41:23 CET] <TanaPanda> I am using raspbian [17:42:14 CET] <DHE> pretty sure that's still linux [17:43:01 CET] <furq> the udp output lets you set the interface [17:43:04 CET] <furq> so if it is multicast then that's easy [17:43:45 CET] <TanaPanda> well the command i use with ffmpeg is this: ffmpeg -loglevel debug -max_interleave_delta 15000000 -rtbufsize 128000k -threads 0 -stream_loop -1 -re -i /home/pi/Desktop/ActiveChannel/Property_LCI.mp4 -codec copy -shortest -f mpegts udp://192.168.6.2:20?pkt_size=1316?buffer_size=65536 [17:43:53 CET] <kepstin> does it? if so it's not documented :/ [17:44:07 CET] <furq> https://ffmpeg.org/ffmpeg-protocols.html#udp [17:44:08 CET] <DHE> yeah I'm looking at -h full [17:44:16 CET] <furq> localaddr=addr [17:44:16 CET] <furq> Local IP address of a network interface used for sending packets or joining multicast groups. [17:44:32 CET] <DHE> yeah that sets the source IP address. but linux doesn't care that the IP it uses is on the interface [17:44:35 CET] <kepstin> that sets an ip, not an interface. [17:44:41 CET] <TanaPanda> can localaddr=eth0? [17:46:41 CET] <furq> i'm assuming if you have two different interfaces with the same ip then you're competent enough with iptables to figure this out [17:46:53 CET] <DHE> no this is definitely routing table stuff [17:47:18 CET] <DHE> ip route add 192.0.2.123/32 [via 192.168.1.1] dev eth0 [17:47:18 CET] <TanaPanda> lol assuming i am competant [17:47:20 CET] <TanaPanda> thats precious [17:47:30 CET] <TanaPanda> hmmm [17:47:34 CET] <TanaPanda> i like where this is going [17:47:35 CET] <DHE> where 'via' is the gateway IP if need be, and 192.0.2.123 is the intended recipient [17:47:54 CET] <TanaPanda> 192.168.6.2 is the destination of the stream [17:48:11 CET] <DHE> and 'ip route get 192.168.6.1' indicates the wrong NIC? [17:48:22 CET] <DHE> (how many NICs does a rasp pi even have?) [17:48:33 CET] <furq> presumably eth0 and wlan0 [17:48:35 CET] <DHE> (fix my IP typo) [17:48:44 CET] <DHE> ah, wifi.. that makes sense [17:49:32 CET] <TanaPanda> so your suggesting i add [17:50:00 CET] <TanaPanda> sudo ip route add 192.168.6.2/32 via 192.168.6.1 dev eth0 [17:50:04 CET] <TanaPanda> or something like that [17:50:21 CET] <DHE> the via is clearly wrong [17:50:36 CET] <kepstin> if it's on the same subnet as the local ip, it doesn't need the via [17:50:36 CET] <DHE> you specify the Pi's router, not the destination's router [17:50:51 CET] <DHE> and if it's local, you don't specify `via` at all [17:51:01 CET] <TanaPanda> well its wired to the pi [17:51:09 CET] <DHE> then again if it's local, are you sure you need to be specifying it at all? are both LAN and Wifi on the same network? [17:51:16 CET] <TanaPanda> no [17:51:28 CET] <TanaPanda> lan is going to a non-dhcp device with no internet connectivity [17:51:39 CET] <TanaPanda> wifi is connecting to dhcp router with internet [17:51:49 CET] <another> so... what's your problem? [17:51:54 CET] <kepstin> ok, so they have ip addresses in *different* subnets, right? [17:51:57 CET] <TanaPanda> i cant get both to run at the same time [17:52:00 CET] <TanaPanda> yes [17:52:10 CET] <DHE> then chances are this doesn't matter. if the lan port has 192.168.6.x/24 assigned, that will always be the default for anything in that block [17:52:15 CET] <TanaPanda> one sec [17:52:16 CET] <kepstin> if so, there's no issue, linux should do the right thing assuming addresses and routes are configured right [17:52:18 CET] <TanaPanda> for the sake of it [17:52:29 CET] <TanaPanda> currently i am trying to stream to 192.168.6.2 [17:52:34 CET] <furq> yeah if they're in different subnets then eth0 shouldn't have a route to 192.168.6.2 [17:52:39 CET] <TanaPanda> and my wifi is on a 10.100.13.xxx address [17:52:43 CET] <furq> oh [17:52:45 CET] <furq> what [17:53:03 CET] <DHE> and the lan is presumably 192.168.6.5 or something ? [17:53:13 CET] <TanaPanda> well i have just left it as dhcp [17:53:20 CET] <TanaPanda> I am not terribly good at networking [17:53:25 CET] <kepstin> i thought you said there is no dhcp on the lan interface [17:53:26 CET] <TanaPanda> i know what i want just not how to get there [17:53:31 CET] <TanaPanda> there isnt [17:53:33 CET] <kepstin> if so, you need to manually configure an ip [17:53:40 CET] <TanaPanda> so the ip address of the lan is 169.254.x.x [17:53:46 CET] <kepstin> that's not a real ip [17:53:49 CET] <TanaPanda> which is the default no dhcp detected address [17:53:52 CET] <TanaPanda> yeah [17:54:07 CET] <kepstin> you need to configure the eth0 interface manually with an ip on the same subnet as the device you want to communicate with [17:54:33 CET] <TanaPanda> whats the best way to do this? i have tried using the GUI to set it manually but it doesnt seem to chnage [17:54:34 CET] <another> kepstin: it *is* a real ip :D [17:54:55 CET] <furq> what gui [17:55:14 CET] <TanaPanda> right click and click on wired and wireless netowrk settings [17:55:29 CET] <kepstin> networkmanager, i'd assume? after making a config change with that you normally have to stop and start the interface to get the change applied [17:55:35 CET] <furq> yeah [17:55:51 CET] <furq> normally it's just in /etc/network/interfaces but i'm guessing gnome overrides that somehow [17:55:58 CET] Action: DHE throws NetworkManager into the same fire systemd is burning in [17:56:20 CET] <kepstin> networkmanager on debian is kinda weird since i think they setup some alternate config plugin instead of the default one :/ [17:56:53 CET] <TanaPanda> and why they name things differently why cant it just say ip,gateway,subnet,dns1,dns2 [17:57:15 CET] <TanaPanda> no it has to be router dns search [17:58:53 CET] <kepstin> i think you're looking in the wrong place or have the wrong mode selected? for this interface you want to leave all routing and dns configuration blank. [18:00:56 CET] <kepstin> You want to set IPv4 method to "Manual", fill in the address and netmask field, and leave everything else either blank or auto. [18:01:10 CET] <furq> you should just be able to set it in /etc/network/interfaces [18:01:17 CET] <furq> apparently networkmanager ignores anything set there by default [18:02:01 CET] <kepstin> or even as a one-off, you could just run "ip addr add 192.168.6.5/24 dev eth0" (that will get stuff working right now, but won't be saved on reboot) [18:23:48 CET] <TanaPanda> is there like a generic command to stream a video to an IP address that I can use that would always work regardless of the video? [18:25:34 CET] <jokoon> does concat work the same for audio and video? [18:29:42 CET] <DHE> TanaPanda: possibly, but the reliability may be a concern if using udp [18:36:16 CET] <TanaPanda> unfortunatly UDP is my only option [18:36:43 CET] <TanaPanda> I have a line that works on a small video but then when I ran it on a video file that was 2.8GB large [18:36:51 CET] <TanaPanda> it took a hot min to get up to 1x speed [18:37:09 CET] <TanaPanda> I have since then compressed the file to a smaller version but havent gotten around to testing it yet [18:37:44 CET] <TanaPanda> the compressed file is only 450MB now [18:37:56 CET] <TanaPanda> so hopefully compressing while resolve that issue [18:40:25 CET] <ncouloute> So what I think is happening is with input seeking I seek to where Frame 207 is but I'm actually getting Frame 216. which is the next keyframe. Which explains why when I go frame by frame from "207". it goes 208 then jumps to 217 then 218,219. Any idea what would cause a file to do that? Maybe the way the frames were encoded. [18:59:47 CET] <kepstin> ncouloute: what player are you using? [19:00:14 CET] <ncouloute> PotPlayer.. but I get the same behavior using ffplay/ffmpeg [19:01:10 CET] <kepstin> ffplay with -ss should display the frame at the desired seek time, then continue frame by frame from there [19:01:29 CET] <kepstin> anything else either indicates a broken file or a bug, really. [19:02:18 CET] <ncouloute> ffmpeg -ss 00:00:08.63363 -i "C:\Users\Me\Desktop\QB School Profile.mp4" -frames:v 1 out1.jpg vs ffmpeg -i "C:\Users\Me\Desktop\QB School Profile.mp4" -frames:v 1 -ss 00:00:08.63363 out1.jpg When I use a video player I get the first commands output [19:03:01 CET] <kepstin> oh, you're comparing -ss before and after -i with ffmpeg cli [19:03:19 CET] <kepstin> that will actually give different results, due to ffmpeg's normalization of file timestamps during input processing [19:03:29 CET] <ncouloute> well that is the same behavior. Ffplay/potplayer behave like input seeking [19:03:59 CET] <kepstin> -ss before -i uses the timestamps in the file itself, using -ss after -i runs ffmpeg's timestamp processing, then discards frames up to the requested (post-processing) start time. [19:04:12 CET] <kepstin> so if the timestamps in the file don't start at 0, the result could be different [19:06:42 CET] <ncouloute> If I add -seek_timestamp 1 -ss 0 before the input. So that should account for that no? It still wrong frame however [19:07:38 CET] <kepstin> you should just always be using -ss before -i unless you have a particular reason to do otherwise [19:07:45 CET] <ncouloute> So this: ffmpeg -seek_timestamp 1 -ss 0 -i "C:\Users\Me\Desktop\QB School Profile.mp4" -frames:v 1 -ss 00:00:08.63363 out1.jpg [19:08:23 CET] <ncouloute> well i dont actually use -ss after input.. but that just simulates what the transcoded file would be. [19:09:56 CET] <kepstin> for what it's worth, the -ss output option runs after the filters and before encoding [19:10:48 CET] <kepstin> i'm not sure what you're trying to accomplish here? :/ [19:15:20 CET] <ncouloute> So basically I have these point in time in the video. in this example lets say 08.63363. The 08.63363 in the original file is not the 08.63363 in the transcoded file. I want to get the 08.63363 as input option frame to have the same frame of video in the transcoded file. The 08.63363 in the transcoded file is the same 08.63363 as if I seeked as an output option [19:16:13 CET] <ncouloute> So I think at some point during the decoding process the frames are being moved [19:20:55 CET] <kepstin> maybe you just want to use the -copyts option when doing the transcode to disable ffmpeg's timestamp processing? [19:21:10 CET] <kepstin> assuming there's no negative timestamps, then the output timestamps and input timestamps should match. [19:21:38 CET] <kepstin> might need -vsync passthrough or additional muxer options depending on the format. [19:22:40 CET] <kepstin> the -ss output option runs before muxing, so if any additional timestamp transformation is done during muxing, it won't account for that. [19:26:20 CET] <ncouloute> -copyts and -vsync passthrough. I still get the wrong frame. =/ [19:39:44 CET] <jokoon> Wrote a script that take any number of videos, and makes a xstack with it [19:39:52 CET] <jokoon> no ideo if somebody would be interested [19:42:18 CET] <TanaPanda> what is an xstack? [19:42:37 CET] <jokoon> having several videos playing at the same time [19:42:43 CET] <jokoon> in a layout of your choice [19:42:57 CET] <jokoon> although for now all I managed to do is 2x2 [19:43:15 CET] <jokoon> but the params are already available on the wiki [19:43:17 CET] <TanaPanda> for like a video wall? [19:43:26 CET] <jokoon> for 4x4 and even beyond [19:43:28 CET] <jokoon> yes [19:43:32 CET] <TanaPanda> hmmm [19:43:40 CET] <TanaPanda> think your script would work on the raspberry pi? [19:43:52 CET] <jokoon> it's an encode script [19:43:56 CET] <BtbN> If you don't need more than 1fps [19:43:59 CET] <jokoon> not real time [19:44:12 CET] <TanaPanda> ah [19:44:18 CET] <jokoon> although I don't know if you can adapt it for real time [19:44:19 CET] <TanaPanda> then I dont think i would have a use [20:24:13 CET] <ncouloute> So if I convert the mp4 to a ts file. The timestamps are correct. If I try to remux that ts file back to mp4. Marks are off again. Something with the mp4 container that is screwing things up. =/ [21:38:11 CET] <ncouloute> I've had this problem before. Why does the ts container seem to be the only container that is frame accurate? Is it because most of my video files are either 30000/1001 or 60000/1001 or some variation over 1001. I need it to be mp4. [21:47:45 CET] <kepstin> I'd expect doing a transcode from mp4 source to mp4 destination would preserve timestamps, I dunno what's up :/ [21:49:08 CET] <ritsuka> maybe you need to manually set the correct timescale [22:09:59 CET] <ncouloute> I'm assuming you meant video_track_timescale. I tried setting it to same as input and 90k. I guess I have to go back to using a frameserver. Which is weird because they are all based on ffmpeg. (l-smash or LAV + avisynth + ffmpeg). It is super slow though. [22:17:08 CET] <ncouloute> brb [22:19:40 CET] <jokoon> mmmh I got this problem now [WinError 206] The filename or extension is too long [22:19:53 CET] <jokoon> I gave too many input file and the command line is saturated [22:20:08 CET] <jokoon> I guess it's possible to give ffmpeg a file list? [22:25:14 CET] <jokoon> so apparently .txt file with file "file.mp3" on several lines [22:47:23 CET] <jokoon> with 500 inputs, I guess I might be abusing ffmpeg? [23:00:44 CET] <BtbN> Is there a way to silence _just_ that annoying "Opening 'https://...." spam when reading a HLS playlist? [23:07:15 CET] <BtbN> Where does that message even come from? oO [23:07:18 CET] <BtbN> grep does not find it anywhere [23:08:24 CET] <BtbN> It's an unconditional log in http.c... [23:08:25 CET] <BtbN> Why [23:08:57 CET] <BtbN> I want to get rid of that message, but keep the speed and status output. [23:09:57 CET] <BtbN> The message is so spammy that it being printed for every segment causes the processing to slow down a ton [23:11:09 CET] <pink_mist> edit the source and recompile ffmpeg :P [23:15:23 CET] <furq> BtbN: -v error -stats [23:17:15 CET] <BtbN> hm, better than nothing, but I'm still kinda annoyed by that message existing. [23:17:26 CET] <BtbN> It seems pointless [23:17:55 CET] <TheSashmo> Has anyone had a similar problem like this: ffplay video size is 1920x1080, the source video is 320x240, when I try to overlay some text on top of the video, I need to scale the text to the 320x240 video resolution because the text will look huge in the player, so for some reason the overlay is taking the real video resolution instead of the player resolution.... any ideas? [23:19:30 CET] <furq> there's no way for filters to know what size your ffplay window is [23:20:01 CET] <furq> if you want the text to look good then -vf scale=1920:1080,drawtext... [23:20:26 CET] <furq> or i guess 1440:1080 if it's 320x240 now [23:21:07 CET] <TheSashmo> hmm let me try that again, last time I did that, it didnt help.... thanks @furq [23:24:59 CET] <TheSashmo> furq: I'm using the lavfi-complex is that still supported with that style of argument? [23:51:31 CET] <BtbN> Hm, we are getting very very tiny audio glitches when segmenting a video into a bunch of mpegts segments, and then concat demux them back together. [23:52:13 CET] <BtbN> Is this because an audio frame did not end on a video frame boundary? Why did the segment muxer not fix this? [00:00:00 CET] --- Fri Dec 20 2019

1 0

ffmpeg-devel.log.20191218
by burek 19 Dec '19

19 Dec '19

[00:00:00 CET] --- Wed Dec 18 2019

1 0

ffmpeg.log.20191218
by burek 19 Dec '19

19 Dec '19

[00:04:33 CET] <jokoon> I don't understand how to make a letterbox [00:08:15 CET] <jokoon> It reencoded a 1280x540 to a 480x270, but when I open it, the letterbox doesn't show, I'm guessing VLC has a feature to hide them? [00:10:54 CET] <DHE> codecs can indicate non-square pixels. by default ffmpeg will set this field in order to maintain the aspect ratio of the original video unless you manually override [00:11:18 CET] <jokoon> you mean SAR vs DAR? [00:16:17 CET] <jokoon> im so confused [00:16:54 CET] <jokoon> what's this non square pixel? [00:17:29 CET] <jokoon> input says [SAR 1:1 DAR 64:27] [00:17:37 CET] <jokoon> is that what you're talking about? [00:18:19 CET] <jokoon> I use 'scale=480:270:force_original_aspect_ratio:1,pad=480:270:(ow-iw)/2:(oh-ih)/2', [00:18:34 CET] <jokoon> shouldn't this have a letterbox? [00:24:33 CET] <jokoon> 64:27 is 16/9 multiplied by 4/3 [00:24:42 CET] <jokoon> who invents those things? [00:25:08 CET] <DHE> sample aspect ratio, or the ratio of the pixels. 1:1 means perfectly square pixels. DAR is display aspect ratio, or the ratio of the screen/window it plays in [00:25:57 CET] <jokoon> so the video player will stretch the video to match the DAR [00:26:08 CET] <jokoon> but why can't I have a letterbox? [00:26:29 CET] <DHE> because the default is to preserve the DAR when encoding by playing with the SAR if needed. you must override [00:28:45 CET] <jokoon> with force_original_aspect_ratio ? [00:29:32 CET] <jokoon> no not that [00:36:51 CET] <jokoon> setdar=0 doesn't work either [00:49:39 CET] <jokoon> going to sleep [00:49:42 CET] <jokoon> not giving up [00:49:57 CET] <jokoon> I wish I could letterbox any video and have a generic solution [00:50:20 CET] <jokoon> I gather it's currently night in california and in the US [00:50:30 CET] <jokoon> actually it's evening [00:50:41 CET] <jokoon> I'll see [00:50:44 CET] <jokoon> good night [00:51:00 CET] <jokoon> no echelog :( [01:02:47 CET] <shibboleth> i was unable to test ffmpeg with qsv-support compiled in since support the old sdk (supporting ivy bridge and haswell) has been deprecated in ffmpeg [01:03:08 CET] <shibboleth> and i'm unable to test the new sdk since it doesn't support ivy/haswell. [01:03:24 CET] <shibboleth> anyway: using vaapi i'm getting these errors from some sources: [01:04:59 CET] <shibboleth> Failed to get HW surface format for vaapi_vld [01:05:00 CET] <shibboleth> Available HW surface format was vdpau. [01:05:03 CET] <shibboleth> Available HW surface format was yuvj420p. [01:05:04 CET] <shibboleth> Failed to get HW surface format for vaapi_vld. [01:05:06 CET] <shibboleth> Available HW surface format was vdpau. [01:05:08 CET] <shibboleth> Available HW surface format was yuvj420p. [01:05:13 CET] Last message repeated 1 time(s). [01:05:13 CET] <shibboleth> oops, was supposed to be comma-sep [01:05:14 CET] <shibboleth> sorry [01:06:50 CET] <shibboleth> ffprobe: Stream #0:0: Video: h264 (Baseline), yuvj420p(pc, progressive), 2032x1536, 30 fps, 30 tbr, 90k tbn, 60 tbc [01:07:33 CET] <shibboleth> ffprobe for the working sources: Stream #0:0: Video: h264 (High), yuvj420p(pc, bt709, progressive), 1920x1080 [SAR 189:190 DAR 168:95], 25 fps, 25 tbr, 90k tbn, 50 tbc [01:08:50 CET] <shibboleth> does anything jump out as to why vaapi can't handle the first variant? vainfo output: https://paste.debian.net/hidden/35bd7059/ [01:16:21 CET] <BtbN> The resolution could simply be too high for that old of a GPU [01:16:35 CET] <shibboleth> just beat me to it [01:16:42 CET] <shibboleth> i was looking at vdpauinfo [01:16:49 CET] <shibboleth> more vebose: [01:16:51 CET] <shibboleth> verbose [01:16:59 CET] <shibboleth> Video surface: [01:17:00 CET] <shibboleth> name width height types [01:17:00 CET] <shibboleth> ------------------------------------------- [01:17:00 CET] <shibboleth> 420 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 [01:17:00 CET] <shibboleth> 422 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 [01:17:00 CET] <shibboleth> 444 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 [01:17:16 CET] <BtbN> vdpau info is pretty meaningless for an Intel GPU though, since it does not support vdpau. [01:17:40 CET] <shibboleth> ibvdpau-va-gl [01:17:43 CET] <shibboleth> libvdpau-va-gl [01:17:51 CET] <BtbN> That stuff is seriously old and broken, don't use it. [01:18:09 CET] <shibboleth> under decoder capabilities: H264_BASELINE 51 16384 2048 2048 [01:18:10 CET] <shibboleth> H264_MAIN 51 16384 2048 2048 [01:18:10 CET] <shibboleth> H264_HIGH 51 16384 2048 2048 [01:18:29 CET] <shibboleth> still, suggests that this is, in fact, caused by the resolution [01:18:35 CET] <BtbN> the vdpau-vaapi wrapper hasn't seen work in 5 years or so. No degree of brokenness would surprise me about it. [01:18:45 CET] <BtbN> That whole thing itself could be limited to 1080p [01:18:58 CET] <shibboleth> sure, i mention it only because vainfo output is less verbose [01:20:36 CET] <shibboleth> would it be possible to offload some cpu usage by using opencl hwaccel? [01:21:14 CET] <BtbN> no [01:21:24 CET] <DHE> x264 does this, but whether it helps or hurts performance varies. I've seen it do both. 20% was the best improvement I saw though [01:21:25 CET] <shibboleth> drm? [01:21:40 CET] <BtbN> GPUs are bad at video de/encoding. They are not helpful in any way. [01:22:03 CET] <shibboleth> x264 uses opencl? [01:22:12 CET] <BtbN> It has an option to, but it sometimes makes it slower. [01:22:27 CET] <BtbN> so it's generally pretty pointless [01:22:57 CET] <shibboleth> ok. clinfo finds the device, CL_DEVICE_TYPE_ACCELERATOR not found however [01:23:23 CET] <BtbN> Again, GPUs suck at video de/encoding. OpenCL does not help you with it. [01:23:32 CET] <BtbN> Video filtering however it's very useful for [01:23:41 CET] <shibboleth> anyway, i've been able to shave off about 50% prev cpu usage after switching to vaapi for the 1080 streams [01:24:06 CET] <shibboleth> might have to settle for no accel for the last source [01:40:59 CET] <shibboleth> how well does ffmpeg handle v4l-devices (bttv)? [03:48:09 CET] <whoareU> using "ffprobe my.mp4" , one line is "Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'MDF.mp4':", why are there so many format on this video which is obvious mp4 [04:46:08 CET] <Spring> With animted WebP how similar is it to VP8 which it's based upon? Since in my tests with libwebp in ffmpeg, using the -qscale quality option, I found that filesizes were still pretty large for the resolution and quality, while for VP8 it can handle higher resolutions and quality for smaller filesizes. [04:54:37 CET] <matto312> I've been stuck for while on issue. Any help that could push me in right direction would be awesome. Input is live RTMP input and output is multi-variant HLS. Most of the time works as expected, but sometimes output is frozen video. TS files are being generated but it's frozen to single frame (and the video files are ~1/3 size). Here is the cmd and output when the issue happens. https://pastebin.com/PQMQVzXZ Thanks! [04:55:14 CET] <matto312> I recently upgrade ffmpeg to 4.2, but still happens [06:42:06 CET] <BeerLover> bitrate * duration of song should give me the size of audio file right? But it's not the case: https://dpaste.org/f3vH [06:42:19 CET] <BeerLover> Song's size = 53 mb [06:43:31 CET] <BeerLover> but bitrate 128kbps (0.128 mbps) * 3478.308562 = 424.59 mb [06:56:45 CET] <Spring> BeerLover, I think it depends whether it's constant bitrate or variable bitrate. [07:00:18 CET] <BeerLover> Spring i was doing wrong calculation [07:00:20 CET] <BeerLover> never mind [07:00:35 CET] <BeerLover> I want to know if I can estimate the encoding time beforehand? [07:00:50 CET] <BeerLover> since i have a 57min audio file [07:01:13 CET] <BeerLover> I want to know the time ffmpeg might take to encode it into a specific bitrate [10:07:54 CET] <jokoon> ok I finally managed to make that letterbox [10:08:00 CET] <jokoon> youhouuuu [10:15:24 CET] <bencc1> kepstin: I've used SSD on the server with much more iops and bandwidth and still getting freezes during the capture [11:08:14 CET] <ePirat> whats the replacement for the deprecated avcodec_register_all ? [11:08:33 CET] <ePirat> the changelog and API doc is quite unhelpful in that regard [11:09:06 CET] <JEEB> I think you don't need to register them at all any more [11:09:49 CET] <ePirat> why isnt the function a no-op then? [11:10:14 CET] <ePirat> in current git master, that is [11:10:50 CET] <JEEB> good question :P [11:13:54 CET] <BeerLover> i there any way to know how much time ffmpeg will take to encode a song before starting to encode? [11:14:24 CET] <JEEB> it calls av_codec_init_next which just creates a linked list [11:14:31 CET] <JEEB> but the list is supposed to be static now [11:14:47 CET] <jokoon> I'm planning to open 35 videos which combined, weight 900MB, I have 12GB of ram, am I expecting to have problem? (using xstacks) [11:14:55 CET] <jokoon> weigh* [11:22:02 CET] <ePirat> JEEB, Ah ok, thanks [11:34:17 CET] <meepmeep> :) [12:18:47 CET] <jokoon> when doing those [3:v] identifiers, can I use any integer value? [12:19:21 CET] <jokoon> I mean they don't have to be contiguous like 0 1 2 3 [12:19:33 CET] <jokoon> I can use 101 102 201 202... [12:22:12 CET] <jokoon> mmh seems I can't [12:22:28 CET] <jokoon> the -i are always numbered 0 1 2 3 [12:24:13 CET] <JEEB> yes [12:25:51 CET] <jokoon> yes? you mean I can't [12:26:02 CET] <jokoon> or yes there's another way? [12:26:10 CET] <JEEB> they are numbered as you input them [12:26:13 CET] <jokoon> ok [13:05:14 CET] <LFSVeteran> https://pastebin.com/TezruxRt [13:05:44 CET] <LFSVeteran> trying to cross build FFmpeg for aarch64, however arguing with pkgconfig [13:06:03 CET] <JEEB> for cross-compilation you should utilize PKG_CONFIG_LIBDIR [13:06:05 CET] <JEEB> _PATH appends [13:06:09 CET] <JEEB> _LIBDIR overrides [13:06:46 CET] <JEEB> and the actual error should be within ffbuild/config.log [13:18:00 CET] <LFSVeteran> undefined reference to `cabs' [13:18:08 CET] <LFSVeteran> https://pastebin.com/iN75PEcp [13:20:05 CET] <JEEB> cexp in the vorbis test, yup [13:20:23 CET] <JEEB> if all of your dependencies are static libs, then add the --static option to pkg-config options [13:20:35 CET] <JEEB> --pkg-config-flags=--static [13:20:49 CET] <JEEB> that tells pkg-config to also utilize Libs.private [13:20:54 CET] <JEEB> in addition to Libs [13:21:11 CET] <JEEB> since vorbis's pc file seems to have Libs.private: -lm there [13:24:08 CET] <LFSVeteran> just parse --pkg-config-flags=--static to configure right? [13:24:47 CET] <JEEB> pass, yes [13:24:58 CET] <JEEB> that tells configure to use --static when calling pkg-config [13:29:06 CET] <LFSVeteran> hmm still the same [13:30:11 CET] <LFSVeteran> https://pastebin.com/vwET1892 [13:34:10 CET] <JEEB> PKG_CONFIG_LIBDIR=.. pkg-config --static vorbis [13:34:14 CET] <JEEB> what does this give? [13:34:53 CET] <JEEB> because clearly something is derp [13:35:23 CET] <LFSVeteran> If just do that on the commandline, I get no result [13:35:35 CET] <JEEB> also apparently it doesn't even get to testing that? since the test doesn't contain vorbis_info_init [13:35:53 CET] <JEEB> LFSVeteran: sorry, --lib or so as well [13:36:02 CET] <JEEB> *libs [13:36:44 CET] <LFSVeteran> PKG_CONFIG_LIBDIR=.. pkg-config --static --libs vorbis [13:36:58 CET] <LFSVeteran> Package vorbis was not found in the pkg-config search path. [13:38:16 CET] <LFSVeteran> PKG_CONFIG_LIBDIR=/opt/aarch64-unknown-linux-gnu/usr/lib/pkgconfig pkg-config --static --libs vorbis [13:38:22 CET] <LFSVeteran> -L/opt/aarch64-unknown-linux-gnu/usr/lib -lvorbis -lm -logg [13:38:28 CET] <LFSVeteran> PKG_CONFIG_LIBDIR=/opt/aarch64-unknown-linux-gnu/usr/lib/pkgconfig pkg-config --libs vorbis [13:38:35 CET] <LFSVeteran> -L/opt/aarch64-unknown-linux-gnu/usr/lib -lvorbis [13:38:55 CET] <LFSVeteran> strange...since I have native vorbis installed as well [13:46:28 CET] <bencc1> what does "-chunk_duration 1000k" do? [13:46:55 CET] <bencc1> does it has any effect when converting mkv to mp4 while copying audio and video? [13:47:29 CET] <bencc1> ffmpeg -i in.mkv -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart -threads 1 out.mp4 [13:47:50 CET] <JEEB> ffmpeg -h muxer=mp4 [13:47:55 CET] <JEEB> and see the chunk_duration option's description [13:53:19 CET] <bencc1> JEEB: there is no chunk_duration option [13:53:26 CET] <bencc1> in the output [13:53:35 CET] <bencc1> does it means that it's irrelevant? [13:57:19 CET] <LFSVeteran> interesting...https://pastebin.com/gXAs4zL6 [13:57:37 CET] <JEEB> bencc1: ah no, it seems like a global option visible in `ffmpeg -h full |grep chunk_duration` [13:58:44 CET] <bencc1> -chunk_duration <int> E....... microseconds for each chunk (from 0 to 2.14748e+09) (default 0) [13:59:01 CET] <bencc1> what does it means? where it can be used? [13:59:12 CET] <JEEB> it seems to be a global option for the muxing logic. whatever that means :P [13:59:22 CET] <bencc1> I have the above command in a script and trying to decide if it should be removed [13:59:30 CET] <JEEB> probably related to interleaving logic [13:59:31 CET] <bencc1> ffmpeg -i in.mkv -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart -threads 1 out.mp4 [13:59:41 CET] <bencc1> relevant here? [14:00:02 CET] <JEEB> no effing idea unfortunately :P [14:00:10 CET] <JEEB> I've never had to adjust that option for any purposes [14:00:25 CET] <bencc1> thanks [14:09:23 CET] <LFSVeteran> can't see the error... [15:13:06 CET] <lesshaste> is there a tool to speed up a video but keep the audio at the right frequency and synchronised? [15:24:01 CET] <pink_mist> librubberband? [16:37:35 CET] <kepstin> lesshaste: ffmpeg can do it, but note that you have to scale the speed of the audio and video separately in matching amounts using filters. you have a bunch of choice on how exactly you'd like to deal with each stream. [16:39:43 CET] <phobosoph> hi [16:41:10 CET] <phobosoph> so I got a h264 video in full HD streamed from HTTP [16:41:20 CET] <phobosoph> is there bandwidth shaping tech supported by modern browsers? [16:42:24 CET] <kepstin> player side bandwidth control has to be done in javascript, but it is doable (most big video streaming sites do it) [16:42:50 CET] <kepstin> typically done by having multiple encodes at different rates available via dash or hls, can switch on segment boundaries. [16:45:47 CET] <phobosoph> kepstin: so it can't dynamically just send only parts of it? It has to be a wholly differently encoded video stream thing? [16:45:54 CET] <phobosoph> kepstin: any js player solutions out there? [16:46:21 CET] <phobosoph> I can use Adobe Premiere, Encoder, ffmpeg [16:46:21 CET] <phobosoph> can these programs encode a video file for different resolutions? [16:46:21 CET] <phobosoph> similar to <picture> and srcset for img in html5? [16:46:27 CET] <kepstin> if you build your own sidechannel thing where the player can notify the server to change rate, you can do it in-stream i suppose. [16:46:44 CET] <phobosoph> kepstin: in-stream, so a HTTP server thing has to transcode it on-demand? [16:46:53 CET] <phobosoph> or does it simply pick something else? [16:46:56 CET] <phobosoph> :/ [16:47:00 CET] <kepstin> it's up to how you build it [16:47:04 CET] <kepstin> browser does nothing automatically [16:47:28 CET] <phobosoph> I see [16:47:37 CET] <phobosoph> youtube seems to encode it for different p, 1080, 720, 480p? [16:47:39 CET] <kepstin> as i said, most places do it by having dash or hls with multiple rates available, and then having a javascript player switch between them. [16:49:43 CET] <phobosoph> kepstin: hm, so DASH claims to be much more efficient than HLS, but less supported? [16:49:56 CET] <phobosoph> https://caniuse.com/#feat=http-live-streaming [16:49:58 CET] <phobosoph> ofc, the IE lol [16:50:02 CET] <BtbN> DASH is HLS with more XML. [16:50:06 CET] <phobosoph> hm, chrome also [16:50:07 CET] <BtbN> Otherwise... about the same [16:50:24 CET] <BtbN> If you do HLS with fragmented mp4 it's virtually identical to DASH [16:50:25 CET] <phobosoph> BtbN, kepstin: any ready solutions for this? except hosting on youtube or similar? [16:50:33 CET] <BtbN> Any http server? [16:50:44 CET] <phobosoph> yes [16:50:49 CET] <kepstin> phobosoph: https://caniuse.com/#feat=mediasource is the one that matters [16:50:54 CET] <phobosoph> ah [16:50:58 CET] <kepstin> the actual dash or hls is implemented in javascript [16:51:07 CET] <phobosoph> support looks much better [16:51:18 CET] <phobosoph> kepstin: any JS library/player thing that supports this that I should look into? [16:51:22 CET] <BtbN> It's still a horrible mess from my experience, and only really works reliably in Chrome. [16:51:24 CET] <phobosoph> I also want to use it for background [16:51:44 CET] <BtbN> Luckily every browser except firefox is chrome nowadays. [16:51:48 CET] <kepstin> apple devices can natively play hls without a javascript player [16:51:59 CET] <kepstin> but that's a historical artifact [16:52:04 CET] <BtbN> Edge can also do that [16:52:24 CET] <kepstin> i bet chromium edge can't tho :) [16:52:30 CET] <BtbN> It did when I tested it [16:52:38 CET] <phobosoph> I use video backgrounds and I want to make it more efficient [16:52:52 CET] <phobosoph> which means I am interested in adaptive video stuff for <video> backgrounds, too [16:52:55 CET] <BtbN> That sounds inefficient no matter what [16:52:56 CET] <kepstin> phobosoph: I have autoplay disabled, that makes it more efficient :) [16:53:15 CET] <phobosoph> kepstin: and then I want to offer optional audio on/off (opt-in as chrome enforces it anyway) [16:53:30 CET] <phobosoph> is it possible to download the audio part only when the user enables it? [16:53:31 CET] <BtbN> Playing a video for no particular reason is a waste [16:53:34 CET] <phobosoph> and otherwise skip the audio? [16:53:42 CET] <kepstin> moving backgrounds is an accessibility problem too, for motion sensitive people [16:53:45 CET] <BtbN> Audio is entirely irrelevant in size compared to video [16:53:47 CET] <phobosoph> BtbN: in this very particular case it is a short looping background video :) [16:53:51 CET] <phobosoph> ah [16:54:00 CET] <BtbN> No matter if it's short looping [16:54:03 CET] <phobosoph> kepstin: I need to look for a css selector for motion sensitive [16:54:04 CET] <phobosoph> hm [16:54:08 CET] <BtbN> it still needlessly keeps the GPU and CPU busy for no reason [16:54:12 CET] <BtbN> specially mobile users will hate you [16:54:51 CET] <phobosoph> hm [16:54:57 CET] <phobosoph> alternative to a short movie thing? gifv? [16:55:13 CET] <kepstin> gifv isn't a real format, that's just a short movie [16:55:28 CET] <furq> gifv is just mp4 [16:56:09 CET] <BtbN> How about just not permanently playing a video? [16:56:12 CET] <furq> or more precisely it's just a fake file extension imgur uses to give you a bare html page with a video tag with looping set [16:56:14 CET] <kepstin> my recommendation is use a static background, and if something you have would be best explained with motion video, then have a click-to-play video element for that. [16:56:20 CET] <BtbN> Browsers just won't let you autoplay a video anyway [16:56:31 CET] <BtbN> It's all forced click to play [16:56:32 CET] <furq> also yeah video backgrounds don't work in chrome any more [16:56:34 CET] <furq> for pretty good reasons [16:56:51 CET] <BtbN> Only a certain huge video platform has an exception [16:57:01 CET] <furq> can't imagine how they swung that [16:58:03 CET] <phobosoph> ok [16:58:15 CET] <phobosoph> BtbN: well, it does autoplay with mute attribute [16:58:41 CET] <phobosoph> https://developers.google.com/web/updates/2017/09/autoplay-policy-changes [16:58:42 CET] <kepstin> depends on the browser, and in chrome it depends on weird heuristics about how often you access the site [16:58:51 CET] <phobosoph> "Muted autoplay is always allowed. [16:59:00 CET] <furq> oh right yeah [16:59:02 CET] <kepstin> that's from 2017 [16:59:03 CET] <phobosoph> :D [16:59:07 CET] <phobosoph> but it is like that [16:59:10 CET] <kepstin> 2017 is a long time ago :) [16:59:36 CET] <phobosoph> they hadn't changed it [16:59:46 CET] <LFSVeteran> https://pastebin.com/CbVqWSk0 [17:00:34 CET] <phobosoph> https://github.com/Dash-Industry-Forum/dash.js/blob/5f0cb17824bc121123952b1… [17:00:43 CET] <kepstin> ah, the heuristics stuff only affects video with sound [17:00:45 CET] <phobosoph> dash.js looks like a good player for dash/hls/browser stuff [17:01:03 CET] <furq> i've used hls.js before and it's fine [17:01:04 CET] <phobosoph> now I need to setup a nginx with rtmp/dash/hls support for video files? [17:01:15 CET] <furq> only for live streaming [17:01:20 CET] <phobosoph> furq: hls.js vs dash.js? any differences? it seems that dash.js can fall back to hls and be more efficient? [17:01:25 CET] <kepstin> any plain http server can host vod dash or hls content [17:01:30 CET] <furq> hls is just a playlist and a bunch of segments in a directory [17:01:37 CET] <phobosoph> furq: ok, so now I have to provide multiple video files in different resolution, like youtube does? [17:01:42 CET] <phobosoph> kepstin: that's nice [17:01:49 CET] <BtbN> DASH and HLS are effectively the same thing, just one with and one without XML [17:02:02 CET] <furq> or multiple playlists in this case [17:02:08 CET] <bencoh> (and dash allows mp4 segments) [17:02:08 CET] <phobosoph> https://github.com/videojs/videojs-contrib-dash [17:02:12 CET] <kepstin> does hls still mandate mpeg-ts, or do they support mp4 now? [17:02:14 CET] <BtbN> They both support multiple quality lists [17:02:18 CET] <phobosoph> this seems to offer the best of both worlds, dash and hls [17:02:24 CET] <furq> hls nominally supports mp4 but not all implementations do [17:02:28 CET] <bencoh> oh [17:02:39 CET] <phobosoph> "A video.js source handler for supporting MPEG-DASH playback through a video.js player on browsers with support for Media Source Extensions." [17:02:40 CET] <furq> also you don't really need both dash and hls [17:02:41 CET] <phobosoph> nice!!! [17:02:47 CET] <phobosoph> furq: so what should I prefer? [17:02:58 CET] <phobosoph> dash claims to be up to 200% or whatever more efficient than hls? [17:03:00 CET] <furq> i forget what the deal is with apple stuff and dash [17:03:01 CET] <phobosoph> however this should work [17:03:03 CET] <phobosoph> lol [17:03:10 CET] <furq> also idk what their basis for claiming dash is more efficient is [17:03:13 CET] <phobosoph> ah right, ios seems to natively do hls? [17:03:14 CET] <phobosoph> hm [17:03:23 CET] <kepstin> apple stuff should be fine with dash, assuming recent updates, you get mse with current ios versions [17:03:27 CET] <bencoh> I see no proper reason for it to be more efficient [17:03:35 CET] <BtbN> Neither DASH nor HLS are in any way efficient/inefficient. They are just playlists. [17:03:36 CET] <furq> a lot of livestreaming stuff used hls for years because safari and ios stuff doesn't do mse [17:03:45 CET] <furq> like youtube used dash for vod and hls for live [17:03:47 CET] <kepstin> mpeg-ts has more muxing overhead than other formats, and hls normally uses mpeg-ts [17:03:53 CET] <furq> because apple stuff would fall back for http for vod [17:03:56 CET] <kepstin> so that might be what they mean? shouldn't be "200%" tho [17:03:59 CET] <furq> but i guess apple finally caved [17:04:06 CET] <furq> kepstin: does it have much more overhead than fmp4 [17:04:13 CET] <furq> i guess for sufficiently large segments it does [17:04:34 CET] <furq> but yeah that's like 10% overhead compared to non-fragmented mp4 [17:04:44 CET] <phobosoph> hm, other sites recommend HLS [17:04:52 CET] <phobosoph> because apple,right [17:04:55 CET] <furq> probably [17:05:04 CET] <kepstin> always check dates on this stuff, things change quickly in this space. [17:05:06 CET] <furq> i used hls because hls.js was way easier to get running when i last looked into this [17:05:11 CET] <furq> but that's like two years ago now [17:05:41 CET] <BtbN> HLS is just way nicer and more readable of a format [17:05:48 CET] <furq> yeah that as well [17:05:48 CET] <BtbN> While DASH is horribly over-engineered [17:05:56 CET] <furq> i still don't really understand dash [17:06:01 CET] <furq> granted because i've never needed to [17:06:14 CET] <phobosoph> https://github.com/Viblast [17:06:21 CET] <phobosoph> they claim to be even better than dash.js and video.js [17:06:22 CET] <phobosoph> hmmmm [17:06:27 CET] <phobosoph> so many different players [17:06:29 CET] <furq> whereas hls is just an m3u8 file full of mpegts segment [17:06:30 CET] <furq> s [17:06:39 CET] <BtbN> Or mp4 fragments [17:06:40 CET] <furq> or full of other m3u8 files [17:07:03 CET] <phobosoph> hm, now I tend towards HLS because it requires less js fallback [17:07:18 CET] <furq> they're both fine [17:07:28 CET] <furq> as far as client experience goes [17:07:39 CET] <phobosoph> ah, so the client doesn't notice a difference [17:07:44 CET] <furq> like i said youtube used both and nobody ever noticed [17:08:06 CET] <furq> and i think they now use dash for live streams and nobody noticed [17:08:35 CET] <BtbN> Don't most sites use some kind of self-baked WebSocket-Straight-to-MSE construct nowadays? [17:08:50 CET] <furq> i'd rather not think about that [17:09:04 CET] <BtbN> At least when you inspect the players, you end up with a wss:// url for the video [17:09:47 CET] <furq> yeah nowadays if youtube-dl doesn't already support it i just assume it's not worth it [17:10:28 CET] <furq> someone smarter than me has probably already tried and given up [17:10:35 CET] <phobosoph> https://bitmovin.com/status-mpeg-dash-today-youtube-netflix-use-html5-beyon… [17:11:01 CET] <phobosoph> This looks like the best opensource player solution out there: https://github.com/videojs/videojs-contrib-dash [17:11:12 CET] <phobosoph> video.js for DASH and HLS fallback [17:11:13 CET] <furq> didn't safari actually secretly support mse for years but only for whitelisted sites, and the whitelist was netflix.com [17:11:25 CET] <phobosoph> furq: woa, microsoft-style competition practics :/ [17:11:28 CET] <furq> or the ios native video element thing [17:11:34 CET] <furq> which i assume is some safari component [17:11:40 CET] <phobosoph> furq: they hadn't got in trouble with that whitelisting competition thign? [17:11:49 CET] <furq> idk i heard that once from someone in here [17:12:06 CET] <furq> you could tell me anything about apple doing that sort of thing and i'd uncritically believe it without checking [17:12:11 CET] <furq> it's like the dprk at this point [17:13:31 CET] <phobosoph> ah [17:13:45 CET] <phobosoph> furq: so let's say I want to use that https://github.com/videojs/videojs-contrib-dash thing [17:13:56 CET] <phobosoph> I have to set up a directory on the web server to host the video files, right? [17:14:00 CET] <furq> yeah [17:14:03 CET] <phobosoph> and a m3u and dashwhatever playlist thing? [17:14:11 CET] <phobosoph> can I autogenerate them? or is it just some piece of text? [17:14:19 CET] <furq> ffmpeg will generate them if you use the hls muxer [17:14:24 CET] <furq> along with all the segments [17:14:38 CET] <furq> or the dash muxer i guess [17:14:49 CET] <phobosoph> ah cool [17:14:56 CET] <phobosoph> furq: and it can generate both, for dash and for hls? [17:15:13 CET] <furq> i don't think so but i've never tried [17:15:54 CET] <phobosoph> ah [17:16:00 CET] <furq> at least not for the same set of segments [17:17:18 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#dash-2 [17:17:19 CET] <furq> hls_playlist hls_playlist [17:17:19 CET] <furq> Generate HLS playlist files as well. [17:17:21 CET] <furq> cool [17:17:24 CET] <phobosoph> https://github.com/videojs/http-streaming [17:17:24 CET] <phobosoph> ah [17:18:10 CET] <furq> i don't think there's any reason to use both though [17:18:26 CET] <furq> if the browser supports mse and javascript then it supports both hls and dash [17:19:21 CET] <phobosoph> furq: so I just use dash.js [18:53:51 CET] <phobosoph> In Audacity one can store the stereo channel difference instead each channel separate - this should yield the same results, right? [18:53:57 CET] <phobosoph> because it is digital? [18:58:29 CET] <kepstin> phobosoph: need more context. what codec? [18:59:05 CET] <phobosoph> mp3 [18:59:06 CET] <kepstin> note that most lossy codecs automatically decide whether to use stereo or mid/side (stereo difference), sometimes even on a per-frame basis [18:59:11 CET] <kepstin> there shouldn't be any config needed [18:59:40 CET] <kepstin> with mp3 (lame encoder), you normally want to use one of the preset modes, and it'll automatically use mid/side as appropriate [18:59:52 CET] <furq> lame uses joint stereo by default [19:01:10 CET] <furq> it yields better results with lossy codecs because it takes less space [19:01:34 CET] <kepstin> it takes less space on signals where there's correlation between the two channels, anyways [19:01:41 CET] <kepstin> which is true of most musc [19:02:01 CET] <furq> well like you said it'll only be enabled for frames where it's of benefit [19:03:39 CET] <kepstin> phobosoph: anyways, it's an internal implementation detail of how the codec works, and isn't something most people need to look at let alone touch :/ [19:04:27 CET] <furq> i assume it's some encoder configuration checkbox [19:05:01 CET] <furq> there's no point messing with anything other than -V or -b for lame [19:05:09 CET] <kepstin> in some special cases where you have unusual audio signals you might notice reduced stereo separation, in which case having the option to manually force dual-mono encoding could be useful. [20:09:08 CET] <phobosoph> ah [20:09:23 CET] <phobosoph> another thing: When I got a normal headset microphone, the input is mono, right? :) [20:09:30 CET] <phobosoph> so I could just use a mono channel in e.g. audacity? [20:11:11 CET] <pink_mist> completey depends on the microphone in question [20:12:21 CET] <JEEB> aughey: anyways not sure if you can get much more help unless you post some code onto a pastebin or so [20:12:49 CET] <JEEB> because it feels like something is awry or expecting something else (Since I've been able to convert YCbCr to RGB just fine [20:15:31 CET] <aughey> Here's my code. https://github.com/aughey/ffmpegtest/blob/master/FFMPEGPipeC2.cpp very minorly modified from the standard examples to output the video buffers to stdout. [20:16:25 CET] <aughey> There are at least 3 attempts to get it to work correctly. All have the same results. [20:21:35 CET] <JEEB> good ol' swscale [20:22:06 CET] <kepstin> aughey: i don't have any context for what's wrong, but at a quick glance at your code, that's using the old apis, hmm. And you generally don't want to preallocate the buffers for video frames when decoding, they'll normally be automatically allocated. [20:22:36 CET] <JEEB> aughey: I used to use swscale ages ago [20:22:38 CET] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn… [20:22:43 CET] <JEEB> that's the left-over history of that one :P [20:23:51 CET] <kepstin> if you're using swscale, you need to use the allocation methods that add a bit of extra space to the lines/frames for alignment reasons. i forget what those are offhand. [20:24:14 CET] <JEEB> apparently that he is doing [20:24:21 CET] <JEEB> also what on earth is that avpicture_fill doing [20:25:34 CET] <JEEB> also thankfully we've gained a lot of helpers for this stuff [20:26:05 CET] <aughey> I dont' need to use swscale, it's somewhat left over from modifying other examples in an attempt to get this to work. I shoudl be able to write out the planes directly from avcodec_decode_video2 [20:26:35 CET] <aughey> I've tried that too, similar results [20:26:54 CET] <JEEB> then something's weird [20:27:21 CET] <aughey> I know my GPU rendering of the frame buffer is correct, because if I extract out raw video frames using the command line ffmpeg.exe, I get correct results [20:27:33 CET] <kepstin> i'm missing something here, what's the bad results that you're getting? [20:27:44 CET] <aughey> I'm writing my own frame extractor so that I can seek and do other processing. [20:28:05 CET] <JEEB> note: if you are planning on wanting frame-exact seeking in the end you might want to look at ffms2 [20:28:06 CET] <aughey> "-hide_banner -loglevel panic -fflags nobuffer -flags low_delay -ss " + start_offset + " -i " + filename + " -f rawvideo -vcodec rawvideo pipe:1" [20:28:11 CET] <JEEB> that does indexing on the lavf level [20:28:24 CET] <aughey> This is the command line I generate to generate raw frames with ffmpeg [20:28:32 CET] <kepstin> note that ffmpeg's rawvideo output is *not* the same as ffmpeg's in-memory video representation [20:28:33 CET] <JEEB> yea, that gives you no extra stride I think [20:28:43 CET] <aughey> this outputs native yuv420p frames which my shader on the gfx side handles correctly [20:29:11 CET] <aughey> So if I write out each line of the frame (in the commented out section of my code), I get the same skewed results [20:29:25 CET] <kepstin> ffmpeg's native representation of planar videos requires using separate pointers for the different planes, and using stride arithmetic to handle the extra line padding for alignment reasons [20:29:33 CET] <aughey> Here's the distorted frame I get https://github.com/aughey/ffmpegtest/blob/master/skew.JPG [20:30:14 CET] <JEEB> aughey: I think you should first minimize the example to only have demux+decode there. you will get an AVFrame from lavc [20:30:45 CET] <aughey> in https://github.com/aughey/ffmpegtest/blob/master/FFMPEGPipeC2.cpp around line 179 I should be doing the stride math [20:30:49 CET] <JEEB> lavc is able to generate the buffers itself, and you should just have an AVFrame (structure, not buffers) allocated for it [20:31:17 CET] <kepstin> yeah, drop all your manual buffer allocation stuff [20:31:23 CET] <JEEB> I've clearly gotten the same stuff to work just fine, and various GPU based things also work [20:31:44 CET] <JEEB> as in, things that then move the buffer to the GPU and render with a shader [20:34:55 CET] <ry> DOes anyone have an idea of what syntax I would use with ffmpeg to send an IP stream to broadcast (so all hosts on the same subnet would receive it). (This is an experiment, I know multicast is the way to go for production use). [20:43:09 CET] <JEEB> no idea, I've just used multicast on the interface generally [20:45:28 CET] <aughey> When you say to use lavc, what do you mean? [20:50:03 CET] <JEEB> aughey: libavcodec's short hand [20:50:06 CET] <JEEB> lavf is libavfilter [20:50:12 CET] <JEEB> *libavformat [20:50:16 CET] <JEEB> lavfi is libavfilter [20:53:35 CET] <kepstin> ry: it should in theory be as simple as using the subnet broadcast address as the destination address [20:53:51 CET] <kepstin> with udp, of course. [20:57:05 CET] <ry> kepstin, I get permission denied trying to use udp://10.27.0.255:4900 -- as an example: "sudo ffmpeg -stream_loop -1 -re -i CNBC-WDC-180213-0901.ts -map 0 -c copy -f mpegts udp://10.27.0.255:4900" ends up with the following error: "av_interleaved_write_frame(): Permission denied", "Error writing trailer of udp://10.27.0.255:4900: Permission denied" [20:58:26 CET] <ry> Am I doing anything wrong here? [20:59:22 CET] <kepstin> looks like you need to enable the broadcast option on the udp protocol handler, https://www.ffmpeg.org/ffmpeg-protocols.html#udp [21:00:55 CET] <ry> Ah, that did it. Thanks kepstin [21:05:03 CET] <aughey> So I have an example that uses demuxing_decoding.c straight from the ffmpeg examples. This should just be using lavc. This is the stock code and my only change is to neuter the printfs audio writing, and to direct the fwrite for video to stdout. I get the same thing. And again, the same draw code using the output of ffmpeg rawvideo gives [21:05:04 CET] <aughey> correct results. [21:05:20 CET] <aughey> I've been on this issue for days, I'm at my wits end. :-) [21:14:58 CET] <JEEB> aughey: I really can't speak of the examples but since so many can get it right, there is something that's utilizing the buffer wrong, one some side [21:30:05 CET] <nicolas17> ry: note there's a multicast address that means "all hosts", I think that should work the same [21:34:42 CET] <ry> This started with me talking to a network engineer who was completely unable to utilize multicast on their network (not technical reasons, but not well thought out corp policy). They are streaming to broadcast, and using IP Directed Broadcast on their Cisco hardware to get those broadcast IP streams across VLANs. They have this working and demo'ed it for me - that was the first I'd even heard of IP Directed Broadcast, no less doing IP streams with broadcast. I'd [21:34:43 CET] <ry> like to try it out in my lab, and see what I can get it working with. [21:38:03 CET] <ddubya> is there a better way to detect errors in files (e.g. bitrot) besides -err_detect ? [21:41:25 CET] <nicolas17> keep checksums of your files :P [21:41:52 CET] <TheAMM> (let zfs keep checksums and repair your files) [21:45:21 CET] <pink_mist> yeah, zfs will detect that [21:45:39 CET] <pink_mist> and if you have raidz it will repair it [21:47:40 CET] <ddubya> thanks [21:51:00 CET] <ddubya> was wondering if there was a filter combination that might indicate a problem [21:51:22 CET] <ddubya> most formats/codecs don't implement a crc for some reason [21:53:29 CET] <ddubya> maybe a noise detector? [21:54:43 CET] <srandrews> Hi everyone, am a novice user of ffmpeg (well save for audio) and am attempting to get it to input RTSP from a hardware HVEC encoder that supports multiple streams. It appears to set up properly and get the RTSP SDP but then times out after mapping the input to the output. A hardware decoder, and VLC seem to receive the RTSP stream which [21:54:43 CET] <srandrews> discounts the configuration of the encoder as the root cause. https://pastebin.com/xYERHWhL [22:16:29 CET] <srandrews> facepalm. Ignore my Q. -rtsp_transport udp is obviously wrong since the encoder is streaming tcp. [00:00:00 CET] --- Thu Dec 19 2019

1 0

ffmpeg-devel.log.20191217
by burek 18 Dec '19

18 Dec '19

[01:00:35 CET] <cone-529> ffmpeg 03Xinpeng Sun 07master:2e2dfe6673fa: avfilter: Add tonemap vaapi filter for H2S [01:09:55 CET] <cone-529> ffmpeg 03Linjie Fu 07master:efefba61f851: lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers [09:22:39 CET] <cone-878> ffmpeg 03Martin Storsjö 07master:0f50be625f15: fate: Add an option for disabling the 2k/4k tests [11:51:05 CET] <cpplearner> What's the meaning of FF in FFmpeg? [11:51:14 CET] <cpplearner> Just curious. XD [11:51:41 CET] <durandal_1707> fast & furious [11:55:17 CET] <cpplearner> No joke? [11:56:18 CET] <cpplearner> Oh, it's fast forward. I see. [12:03:33 CET] <linjie_fu> lol [13:34:10 CET] <cone-141> ffmpeg 03Paul B Mahol 07master:3530fdc78ed8: avfilter/vf_stack: set framerate to VFR when inputs frame rates differs [15:56:51 CET] <cpplearner> Guys, how can I see the list of time_base allowed for a specific encoder? [16:00:16 CET] <nevcairiel> AVCodec has a supported_framerates member for those codecs where it applies [16:05:51 CET] <cone-141> ffmpeg 03Lynne 07master:377a095dc372: vc2enc: zero padding of the coefficient buffer [16:06:33 CET] <Lynne> tmatth: sorry that took so long, couldn't push while port 22 was blocked [16:06:53 CET] <tmatth> Lynne: np, thanks for the fix [16:07:15 CET] <tmatth> one step closer to finding a use case for vc2 ;) [16:19:12 CET] <cpplearner> nevcairiel: Thanks! =) [16:20:12 CET] <jamrial> michaelni: i replied to some of you cbs patches as well, so if you didn't get them chck the archive or patchwork [16:32:55 CET] <Lynne> tmatth: right now, lossy ycocg [16:33:29 CET] <Lynne> it really needs actual in-place per-slice transforms with assembly to be fast for anything else [16:33:57 CET] <Lynne> but I think dnxhd is better and much more standard [16:47:14 CET] <tmatth> Lynne: wasn't familiar [16:47:32 CET] <tmatth> i'm still relegated to the lowly world of rtmp+webrtc formats [16:50:17 CET] <Lynne> I could could on one hand the codecs supported by those, but then I remembered the obscure semi-prorietary audio codecs webrtc supports exist [18:22:05 CET] <cone-141> ffmpeg 03Linjie Fu 07master:d31a29022610: lavc/hevc_cabac: fix cbf_cb and cbf_cr for transform depth 4 [18:22:06 CET] <cone-141> ffmpeg 03Linjie Fu 07master:ed2bd94fc0f4: FATE: add test for hevc files with 4 TUDepth(0..4) of cbf_cb/cbf_cr [18:22:07 CET] <cone-141> ffmpeg 03Linjie Fu 07master:fb705e40733b: FATE/hevc.mak: cosmetic for fate-hevc-paired-fields

1 0

ffmpeg.log.20191217
by burek 18 Dec '19

18 Dec '19

[00:03:35 CET] <cehoyos> Your mfx may be old [00:03:54 CET] <shibboleth> yes, i'm using 2015r6 since it is the last to support ivy bridge [00:04:07 CET] <shibboleth> current doesn't even support haswell [00:06:49 CET] <shibboleth> is there anything in ffmpeg commit/notes that makes 2015r6 incompatible? [00:19:03 CET] <fling> cehoyos: is libaom still slow? [00:48:45 CET] <Arnob> @durandal11707: "it means your ffmpeg version is too old" :-) ok, thank you. I am using Linux Mint 18.3, it's time for an upgrade... [00:49:33 CET] <shibboleth> cehoyos, ? [01:00:07 CET] <cehoyos> shibboleth: You just found out that newer FFmpeg is incompatible with old libmfx, this is generally not surprising but not something I knew [01:00:37 CET] <shibboleth> yeah, i asked if this is "likely" or simply "possible" [01:05:50 CET] <nicolas17> fling: "-threads 1" means *don't* use multiple threads [01:12:02 CET] <shibboleth> is there anything in changelogs that points this out? [01:15:29 CET] <fling> looks like libaom still slow [01:15:32 CET] <fling> nicolas17: ok [01:15:44 CET] <nicolas17> do you have libaom from git? [01:15:48 CET] <BtbN> It's libaom. It's never going to be fast. [01:15:52 CET] <nicolas17> latest git master is faster than 1.0 [01:15:55 CET] <nicolas17> but it's still slow [01:16:01 CET] <fling> no, 1.0.0, can go latest [01:16:08 CET] <fling> how much faster? :D [01:16:24 CET] <nicolas17> hmm I don't remember numbers, someone here might know [01:16:35 CET] <fling> I will just rebuild [01:16:48 CET] <fling> speed=0.00229x [01:29:52 CET] <fling> latest is faster 0.0113x [02:46:55 CET] <K1rk> Hello, I am trying to help someone get a rather advanced ffmpeg setup working how they need it to. [02:47:13 CET] <K1rk> We compiled an ffmpeg.exe (they're using Windows) using RDP's ffmpeg build helper: https://github.com/rdp/ffmpeg-windows-build-helpers [02:47:38 CET] <K1rk> This build and several other builds we have seem to set a vbv_delay of "n/a". [02:47:48 CET] <K1rk> We have another build where the vbv_delay gets set to -1 with the same input params [02:47:58 CET] <K1rk> Is this something that is changed during compiling or is there a flag I am missing somewhere? [02:51:45 CET] <K1rk> It's possible that we could be reading too much into this particular difference, but when we see this difference in the output we seem to experience some kind of memory leak that results in an eventual crash. [02:52:01 CET] <K1rk> So I was looking to see if we could manually set vbv_delay=-1 somehow on my build of ffmpeg.exe [02:55:55 CET] <Soni> how do I make a 100MHz pcm_u8 mono from my 48kHz 16-bit stereo audio? [06:52:29 CET] <qmr> how can I stream device w mplayer or ffmpeg on macos? it's FPV doodad, it presents as a USB webcam [06:52:45 CET] <qmr> [AVFoundation input device @ 0x7fc28bc3a3c0] [0] USB2.0 PC CAMERA in ffmpeg [11:39:33 CET] <jokoon> generally speaking, when I re-encode a video, when I downsize, is it faster the lower the new resolution? [11:39:50 CET] <furq> yes [11:44:39 CET] <jokoon> I want to resize several videos which have various size, I want them to have the same width, if I set -vf scale=360:-1 does it mean ffmpeg will choose a multiple of 4 size for h264? [11:45:35 CET] <jokoon> or will it slightly stretch the video or add pixels? [11:46:06 CET] <jokoon> are there other ways to make sure things are multiple of 4 ? [11:54:32 CET] <furq> jokoon: 320:-4 [11:54:53 CET] <jokoon> you mean 360:-4? [11:54:55 CET] <furq> yeah [11:54:58 CET] <jokoon> ok thanks! [11:55:35 CET] <furq> -2 should be fine unless you need mod4 for some other reason [11:59:24 CET] <jokoon> well Im encoding in 264 so I need mod4 [11:59:40 CET] <jokoon> Don't I ? [11:59:54 CET] <furq> no [12:00:55 CET] <jokoon> only mod2? [12:01:03 CET] <furq> it depends on the pixel format [12:01:10 CET] <furq> which is almost always yuv420p, so mod2 is fine [12:01:22 CET] <jokoon> ok [12:27:49 CET] <jokoon> How is it possible to change the framerate without re-encoding the video? [12:29:29 CET] <jokoon> Yesterday I asked about making several video the same framerate so I can make a proper xstack. I heard there are several option, it seems framerate is slightly better than fps [12:30:15 CET] <jokoon> Also I want 30 to be the framerate [12:30:29 CET] <jokoon> meaning several videos will have their framerate increased [12:32:31 CET] <durandal_1707> not possible without reencoding [12:34:21 CET] <jokoon> https://stackoverflow.com/questions/45462731/using-ffmpeg-to-change-framera… [12:34:45 CET] <jokoon> the answer says "Remux with new framerate" [12:35:14 CET] <BtbN> If you don't have audio, sure, that works. [12:36:36 CET] <cehoyos> You can use the input option "-r", but the option is a hack and will not work in all cases [12:36:49 CET] <jokoon> ok [12:36:59 CET] <jokoon> so -framerate is better [12:37:08 CET] <cehoyos> No, framerate is another option [12:37:15 CET] <cehoyos> You must use the input option "-r", but the option is a hack and will not work in all cases [12:37:47 CET] <BtbN> There simply is no way to change the framerate without re-encoding, if you don't want the video to run faster/slower afterwards and be entirely off-sync with its audio. [12:38:02 CET] <cehoyos> You can change the framerate without re-encoding with ffmpeg [12:38:28 CET] <jokoon> cehoyos, but it will speedup/slowdown the video [12:38:29 CET] <BtbN> Which will effectively just speed up/slow down the video. [12:38:40 CET] <jokoon> yes that's not what I want [12:38:51 CET] <cehoyos> of course, that is what you want to achieve with a change of framerate [12:39:02 CET] <BtbN> Not really, no [12:39:04 CET] <jokoon> not really [12:39:12 CET] <BtbN> you usually want to drop/duplicate frames. Which requires a re-encode. [12:39:12 CET] <jokoon> I mean not necessarily [12:39:44 CET] <cehoyos> If you have 100 input frames with a framerate of 25fps and you want to change the framerate (as you wrote above), the duration of the video will change [12:39:48 CET] <cehoyos> This is unavoidable [12:40:07 CET] <BtbN> Not if you duplicate every frame and show each only half as long. [12:40:20 CET] <cehoyos> Then you have to re-encode [12:40:27 CET] <BtbN> ... yes? [12:40:38 CET] <jokoon> I was just curious about the SO answer [12:40:59 CET] <jokoon> not sure if that SO answer talked about that solution speeding up/ slowing down the vid [12:41:24 CET] <BtbN> It discards the entire container and metadata involved, and treats the video as a stream of raw frames. And puts new timestamps on it. [12:41:35 CET] <cehoyos> The SO question clearly states that the goal was to change the duration of the stream [12:41:36 CET] <BtbN> So, effectively it just speeds up/slown down the video, while discarding any audio. [12:41:52 CET] <jokoon> oh then sorry I did not read it properly [12:42:42 CET] <cehoyos> Second line [12:47:05 CET] <jokoon> so I can use -framerate to turn a 24fps video into a 30fps video [12:47:34 CET] <jokoon> I know it won't increase quality [12:47:41 CET] <jokoon> I just need the video to be 30fps [12:47:46 CET] <BtbN> It will make it worse, cause re-encode. [12:47:57 CET] <jokoon> I know [12:48:12 CET] <jokoon> As I said, I need this because Im using xstack after this [12:48:24 CET] <cehoyos> What do you mean with "-framerate"? [12:48:48 CET] <jokoon> as an alternative to -r? Ive read -r is hacky [12:48:55 CET] <cehoyos> (Command line and complete, uncut console output missing.) [12:49:05 CET] <cehoyos> "-r" is a hack that can be useful, yes [12:49:15 CET] <cehoyos> The input option "-r" is a hack that can be useful, yes [12:49:24 CET] <cehoyos> The output option -r is not a hack [12:50:17 CET] <cehoyos> The input option "-r" changes video speed, you wrote that you don't want to change video speed, so you don't need an alternative for "-r", you need something else [12:50:25 CET] <cehoyos> not entirely sure what you need / wnat [12:50:31 CET] <furq> if this is just for xstack then don't do anything [12:50:42 CET] <furq> just use the fps filter on that input before xstack [12:51:06 CET] <cehoyos> There is a framerate filter (that does not have a "-"), it is what you need but I suspect it is cpu-expensive [12:51:27 CET] <cehoyos> Using the fps filter is much cheaper (nearly free) [12:51:50 CET] <jokoon> and it doesn't change the video length? [12:52:02 CET] <cehoyos> It changes the framerate, not the duration [12:52:06 CET] <jokoon> ok [12:52:13 CET] <cehoyos> To change the duration, you can use the input option "-r" [12:52:27 CET] <furq> jokoon: -i 24fps.mkv -i 30fps.mkv -lavfi "[0:v]fps=30[tmp0];[tmp0][1:v]hstack" [12:52:55 CET] <cehoyos> Is tmp0 needed? [12:53:21 CET] <furq> not if you tell me it isn't [12:54:22 CET] <jokoon> Im going to do the xstack separately because I need to attach videos together [12:54:54 CET] <jokoon> I have about 30, that I need to play in a 2x2 xstack [12:54:54 CET] <BtbN> That's a full pointless intermediate re-encode [12:55:07 CET] <furq> yeah that just loses more quality [12:55:15 CET] <jokoon> not a problem [12:55:20 CET] <cehoyos> This works here with two input files: -lavfi fps=25,hstack [12:55:50 CET] <furq> yeah i was about to say you should just unconditionally make every video 30fps [12:56:04 CET] <furq> but i'm not entirely sure that's a noop if the input video is already 30fps [12:56:04 CET] <jokoon> that's what Im doing [12:56:15 CET] <furq> i mean in the same command as xstack [12:56:18 CET] <furq> there's no point doing it ahead of time [12:56:25 CET] <cehoyos> No, the fps filter can only work on one input [12:56:39 CET] <jokoon> because I will merge several videos [12:57:05 CET] <cehoyos> If you care about quality or speed or harddrive space, you should do it in one command [12:57:11 CET] <jokoon> I have about 30, and I want to make a single one, in a 2x2, that plays them all [12:57:14 CET] <furq> well you wouldn't be using xstack if you weren't merging several videos [12:57:32 CET] <BtbN> you apply the fps filter to the input _before_ giving it to xstack [12:57:37 CET] <furq> ^ [12:57:54 CET] <BtbN> And I'm pretty sure the fps filter is a no-op if the input fps already matches [12:58:10 CET] <cehoyos> of course [12:58:14 CET] <jokoon> Im merging them in xstack but I also need to merge them in time, the durations are different for all of those videos [12:58:38 CET] <jokoon> of course Im not changing the fps if it's already 30 [12:58:46 CET] <furq> also videos don't need to be the same framerate for xstack anyway [12:58:54 CET] <cehoyos> If quality or encoding time and harddrive space don't matter, there is nothing wrong with not doing it in one command [12:58:57 CET] <jokoon> only doing it on those who are not 30fps, it's maybe 80% of those vids [12:59:44 CET] <jokoon> you can have several framerate with xstack? [12:59:48 CET] <jokoon> really? [12:59:54 CET] <furq> you can with hstack so i assume xstack is the same [13:00:01 CET] <cehoyos> Yes, but there is a master and a slave and it may not be documented which is which [13:00:11 CET] <cehoyos> therefore you should choose it yourself [13:00:12 CET] <furq> i'm pretty sure it rebases them all to match the first input [13:00:17 CET] <furq> which may not be ideal [13:00:19 CET] <cehoyos> yes [13:00:30 CET] <jokoon> so... the video will decode several videos in a video that is a xstack? [13:00:44 CET] <furq> no it just automatically changes the fps of every video to match the first input [13:00:58 CET] <cehoyos> xstack is not a video, it is a filter like crop or pad [13:01:04 CET] <jokoon> hum [13:01:11 CET] <cehoyos> Having more than one input [13:01:32 CET] <furq> but like we've been saying, you can do that manually with -lavfi fps=30,xstack [13:01:37 CET] <jokoon> oh it does it automatically [13:01:53 CET] <cehoyos> Which means not relying on something that may not be documented (I didn't check) and is free anyway [13:02:01 CET] <cehoyos> (mostly) [13:02:09 CET] <furq> yeah my basis for saying it's the first video is i just tried it with two inputs to hstack [13:02:21 CET] <furq> so that might not be accurate for other situations [13:03:08 CET] <cehoyos> https://ffmpeg.org/ffmpeg-filters.html#xstack doesn't say that the framerate of the first video is used [13:03:19 CET] <jokoon> yes I checked too [13:03:31 CET] <jokoon> I assumed it was required because it made sense [13:03:37 CET] <cehoyos> But this shouldn't affect you in any way since you are using the fps filter anyway [13:04:04 CET] <jokoon> well Im not using the FPS filter if I can do without [13:04:10 CET] <cehoyos> You should [13:04:14 CET] <jokoon> oh ok [13:04:32 CET] <cehoyos> Relying on undocumented behaviour makes very little sense [13:04:34 CET] <jokoon> because, hardware might have trouble playing a xstack? [13:04:43 CET] <cehoyos> no [13:04:52 CET] <jokoon> ok [13:04:55 CET] <furq> well say one of your input videos is 5fps and ffmpeg decides to rebase all the other videos to match that [13:04:58 CET] <furq> that's not going to be great [13:05:22 CET] <furq> plus the automatic behaviour is almost certainly doing the same thing the fps filter would [13:05:38 CET] <jokoon> no, the worst fps is 24 [13:05:42 CET] <cehoyos> I suspect there is an additional memcpy [13:05:48 CET] <jokoon> the best being around 60 [13:06:12 CET] <furq> well it's presumably good to actually know for sure what the output framerate is going to be [13:06:22 CET] <jokoon> ALTHOUGH, I heard that if the framerate don't match, it might induce several more reencode [13:06:28 CET] <furq> uh [13:06:29 CET] <jokoon> was told this yesterday [13:06:35 CET] <furq> whatever that was doesn't apply to this [13:07:20 CET] <cehoyos> jokoon: I believe you so far have no idea what xstack (and fps) do, please run a few tests on your local system, then come back if you have more question (and more knowledge) [13:07:27 CET] <jokoon> copypasting: <kepstin> jokoon: basically every time there's a new frame on any input, xstack will make an output frame [13:07:54 CET] <furq> that has nothing to do with reencoding [13:08:09 CET] <jokoon> that has to do with different framerates [13:08:27 CET] <durandal_1707> yes, it will pick highest fps [13:08:34 CET] <furq> it doesn't [13:08:42 CET] <furq> at least hstack doesn't [13:08:42 CET] <durandal_1707> timebase to be more exact [13:08:45 CET] <cehoyos> It's not documented [13:09:16 CET] <kepstin> that was my understanding based on looking at how the framesync code works with videos with non-matching timebases. [13:09:25 CET] <furq> hstack is picking the lcm timebase of both inputs [13:10:00 CET] <durandal_1707> it pickes first timebase returnted by framesync [13:10:13 CET] <durandal_1707> so one that can hold all timestamps [13:10:32 CET] <furq> yeah that makes sense [13:10:42 CET] <furq> [Parsed_xstack_0 @ 000001cd0d764840] [framesync @ 000001cd0dc19a40] Selected 1/150 time base [13:10:46 CET] <furq> i get that with 25 and 30fps inputs [13:10:56 CET] <furq> but the actual reported output fps always matches the first input [13:11:01 CET] <furq> "always" [13:11:26 CET] <cehoyos> Does it report drops? [13:11:39 CET] <furq> it does [13:11:46 CET] <furq> at least if the first input is lower framerate [13:11:54 CET] <cehoyos> That's what I meant [13:13:44 CET] <kepstin> huh, that doesn't do what I thought, if it's using a timebase that's lcm of all inputs, there's no reason it would drop frames. [13:14:06 CET] <cehoyos> ffmpeg (the application) does [13:14:11 CET] <kepstin> is the filter not setting the framerate to vfr? [13:14:18 CET] <kepstin> that's a bug the concat filter used to have [13:15:18 CET] <kepstin> concat used to set the output framerate to the framerate of the first input, then ffmpeg (or the ffmpeg filter code, not sure) would drop the extra frames if the second input had higher framerate. [13:15:34 CET] <furq> https://clbin.com/gIeOe [13:15:41 CET] <furq> for some reason it's not dropping frames with -f null [13:15:46 CET] <furq> it was when i was piping to mpv [13:16:49 CET] <kepstin> what format were you piping? [13:16:55 CET] <furq> rawvideo in nut [13:18:20 CET] <kepstin> i notice that ffmpeg output has the output stream saying 25fps, which does indicate that the stack filter might be incorrectly setting the output fps to the fps of the first input. [13:18:42 CET] Action: kepstin should look at the code to verify [13:19:03 CET] <furq> yeah mpv reports it as 25fps [13:19:16 CET] <furq> not sure why ffmpeg says it encoded 50 frames [13:20:12 CET] <cehoyos> furq: -f null defaults to vfr, -f mov (and friends) to cfr [13:20:53 CET] <kepstin> confirmed, the stack filter does set the outlink frame_rate to the frame rate of the first input, it should set it to 1/0 if the frame rates of all inputs don't match :/ [13:20:54 CET] <furq> oh right [13:20:56 CET] <furq> https://clbin.com/CxXsk [13:20:59 CET] <furq> yeah there you go then [13:22:04 CET] <furq> that actually makes a lot more sense now [13:23:17 CET] <furq> mpv still reports 25fps with -vsync vfr but i guess that matches what kepstin just said [13:25:27 CET] <durandal_1707> ah i need to fix this vfr [13:26:53 CET] <kepstin> interesting that the stack filter is explicitly setting outlink frame_rate to the framerate of the first input. The bug in concat was that it didn't set the outlink frame_rate at all, so the filter framework was implicitly setting it to the framerate of the first input. [13:30:31 CET] <jokoon> so... should I still convert all those videos into 30fps? [13:30:44 CET] <jokoon> I have time following up [13:30:51 CET] <jokoon> a hard time* [13:31:02 CET] <cehoyos> No, you should use the fps filter to make sure the xstack filter gets identical output [13:31:04 CET] <cehoyos> Yes, I know [13:31:10 CET] <jokoon> Should I ask on the forums? [13:31:12 CET] <kepstin> my advice still stands, convert all inputs to matching fps before sending to stack filter [13:31:13 CET] <cehoyos> [13:07] <cehoyos> jokoon: I believe you so far have no idea what xstack (and fps) do, please run a few tests on your local system, then come back if you have more question (and more knowledge) [13:31:45 CET] <jokoon> ok [13:37:13 CET] <kepstin> hmm, it would probably make sense for the framesync code to provide a suitable output frame_rate to use. There's probably a lot of filters that generate one output frame each time framesync provides a set of frames, so it would be nice to not have to duplicate the logic to find a suitable output frame_rate [13:39:09 CET] <kepstin> add a frame_rate field to FFFrameSync, have ff_framesync_configure put something reasonable in there. [13:52:20 CET] <kibibyte> hi [14:35:54 CET] <bencc1> I'm capturing the screen to a nut file with: [14:35:56 CET] <bencc1> ffmpeg -f pulse -ac 2 -ar 48000 -i default -f x11grab -framerate 30 -i :0.0 -acodec aac -b:a 96k -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 -vf fps=30 cap.nut [14:36:40 CET] <bencc1> when I play the video it freezes for few seconds while the audio continues [14:36:59 CET] <bencc1> am I doing something wrong with the -framerate and fps params? [14:37:18 CET] <cehoyos> Do you mean the audio start early? [14:37:33 CET] <bencc1> the audio plays ok all the time [14:37:49 CET] <cehoyos> And A/V sync is always correct except for the first second? [14:38:08 CET] <bencc1> A/V sync is ok [14:38:26 CET] <cehoyos> But please provide the command line including complete, uncut console output. [14:38:27 CET] <bencc1> the picture freeze while the audio continue and after few seconds the picture continue moving [14:38:35 CET] <cehoyos> Audio starts early [14:38:51 CET] <bencc1> the picture freeze every few seconds again [14:38:56 CET] <bencc1> not just at the start [14:39:02 CET] <bencc1> I'll paste the command [14:39:08 CET] <cehoyos> Then please provide the command line you tested together with the complete, uncut console output [14:39:14 CET] <bencc1> ok [14:58:08 CET] <jokoon> here are some funny framerate of the videos I have: 35300000/1176673 3654750/121951 40910415/1365044 47234296/1576051 49955000/1666871 517950181/8641135 60000/1001 842490000/35139083 [14:58:28 CET] <jokoon> although the 60k/1001 is pretty bormal [14:58:31 CET] <jokoon> normal [14:59:30 CET] <jokoon> Might have to do with the video sensors [15:09:30 CET] <bencc1> cehoyos: https://pastebin.com/BFPPwh3p [15:11:23 CET] <bencc1> cehoyos: this time it the picture doesn't freeze in the result so I'm trying again [15:11:29 CET] <bencc1> but the command and console are correct [15:23:08 CET] <cehoyos> Does ultrafast improve the situation? [15:24:28 CET] <bencc1> cehoyos: I'll try [15:24:58 CET] <bencc1> in the paste I see several warnings that might be relevant: [15:24:58 CET] <bencc1> Stream #0: not enough frames to estimate rate; consider increasing probesize [15:25:05 CET] <bencc1> Thread message queue blocking; consider raising the thread_queue_size option (current value: 512) [15:25:11 CET] <bencc1> Queue input is backward in time02.29 bitrate= 1.4kbits/s speed=0.541x [15:25:17 CET] <bencc1> Non-monotonous DTS in output stream 0:1; previous: 112378, current: 109448; changing to 112379. This may result in incorrect timestamps in the output file. [15:25:25 CET] <bencc1> is this indication of a problem? [15:26:07 CET] <cehoyos> jokoon: Old software produced such framerates, this is all supposed to be 30000/1001 or 60000/1001 [15:26:24 CET] <cehoyos> No, but speed=0.541x is (imo) [15:27:08 CET] <bencc1> cehoyos: speed should be 1x? [15:27:14 CET] <cehoyos> Please do not post excerpts of the console output, always paste the command line together with the complete, uncut console output [15:28:21 CET] <bencc1> cehoyos: ok. just highlighted lines from the complete paste I sent before which might be relevant [15:29:55 CET] <cehoyos> I would hopefully find the relevant lines but gtg now, sorry [15:30:36 CET] <bencc1> thank you for the help [16:19:13 CET] <jokoon> launched the xstack, speed is at 1.5 [16:19:21 CET] <jokoon> old cpu [16:22:22 CET] <jokoon> so the output is 30fps, the input are 30/1 30/1 25/1 24000/1001 [16:23:56 CET] <jokoon> except it seems one video was trimmed when using scaling=360:-2 [16:25:10 CET] <kepstin> do you mean scale=360:-2? [16:25:25 CET] <jokoon> yes [16:25:43 CET] <kepstin> those scale options don't compensate for sar, so if one of the video has a different sar than the others you might have issues. [16:25:58 CET] <jokoon> SAR? [16:26:16 CET] <kepstin> other than that, it's the good old "please paste the ffmpeg command line as you ran it, and the complete console output" [16:30:55 CET] <jokoon> https://bpaste.net/show/64LXU [16:32:09 CET] <jokoon> oh sorry the output [16:35:46 CET] <jokoon> output https://bpaste.net/show/WB4GS [16:37:25 CET] <kepstin> your second input file isn't the same aspect ratio as the others, it's something weird between 4:3 and 16:9 [16:37:32 CET] <kepstin> what do you want to do with it? [16:37:47 CET] <kepstin> either has to be letterboxed or cropped. [16:38:01 CET] <jokoon> letterboxed [16:40:19 CET] <jokoon> mmmh Im reading questions on SO [16:40:32 CET] <jokoon> something with pad= [16:41:26 CET] <kepstin> yeah, you have to scale based on height to match the other videos, then use the pad filter to add bars [16:42:05 CET] <kepstin> "scale=-2:202,pad=360:202:-1:-1" is probably close [16:42:35 CET] <kepstin> (360 width doesn't have a nice even integer height for 16:9 video, which is annoying) [16:43:24 CET] <jokoon> what's the next best width for that? [16:46:58 CET] <pink_mist> 480 probably? at least 480 is common [16:47:17 CET] <jokoon> ok [16:47:35 CET] <jokoon> I will have to work on concatenating videos next [16:47:43 CET] <jokoon> thanks for the great help! [16:48:14 CET] <kepstin> I'd probably go with 640x360 per tile, then the final video will be 1280x720 (720p) normal size [16:49:43 CET] <jokoon> I would have to use on a generic 'pad=' argument first [16:54:31 CET] <ntrrgc> Is there a way to perform a synchronous wait for decoded frames in avcodec? It seems to be assumed you will poll with avcodec_receive_frame(), but that's not ideal. [16:56:45 CET] <BtbN> the ffmpeg APIs are blocking. [16:57:27 CET] <ntrrgc> will therefore avcodec_receive_frame() block until at least one decoded frame becomes available? [16:57:33 CET] <BtbN> if recv_frame comes back with EAGAIN, calling it again won't change that result usually. It wants more input. [16:58:28 CET] <BtbN> Generally, you decode by feeding the decoder packets until it bails out, then get frames, and then repeat [16:59:00 CET] <BtbN> Or just a loop of "feed packet, try recv frame(s)". [17:01:17 CET] <ntrrgc> what I've found is that until a new packet is fed, you can't receive all the previously decoded frames [17:02:21 CET] <ntrrgc> this is gstreamer avdec element, so there is quite a bit more code than just avdec, but the loop is like you describe [17:03:48 CET] <kepstin> due to frame reordering with bidirectionally predicted frames, it's expected that there are circumstances where you can't get a frame until you send more packets to the decoder. [17:04:15 CET] <ntrrgc> and the situation is, if I feed quickly packets for time [0, 3) and then stop because of an unbuffered condition, how many decoded frames are obtained depends on thread luck, but it's often noticeably lower than the number of fed packets [17:05:06 CET] <ntrrgc> this can't be due to frame reordering (alone) since changes to the CPU scheduler affect the outcome [17:05:12 CET] <kepstin> thread luck shouldn't matter, this is generally deterministic based on characteristics of the input stream. [17:06:10 CET] <ntrrgc> if I set aside a few packets, e.g. [2, 3) and send them 5 seconds later, then I actually get [0, 2) decoded every time. [17:06:29 CET] <kepstin> which codec and decoder is being used? [17:07:30 CET] <ntrrgc> h264, decoder only [17:08:07 CET] <kepstin> which decoder? ffmpeg's builtin software decoder? [17:10:48 CET] <ntrrgc> I think so. The default one. [17:13:33 CET] <kepstin> hmm. i'd have to check the code to confirm, but calling receive_frame on that should block to wait for decoding, and return the next reordered frame. [17:14:36 CET] <kepstin> if the next reordered frame isn't available because you haven't fed enough input, it will of course return EAGAIN. [17:18:57 CET] <kepstin> you'd be able to understand what's going on better if you log the dts vs. pts of each packet. [17:20:37 CET] <ntrrgc> there is quite a lot of stuff going on in my bug report, so I'll try to make a reduced test case. [19:54:37 CET] <form> hi, when using -ss to cut a mkv file (ffmpeg -ss 10 -i in.mkv -c copy out.mkv) the "Encoding settings" in the header generated by x264 will be discarded and dont get into the output file. with -ss 0 they do. is this a bug? [19:55:34 CET] <form> with "Encoding settings" i mean the encoding-parameters of x264 which you can verify with mediainfo [19:57:13 CET] <JEEB> if those SEI messages are in the stream itself, that's not really a bug [19:57:27 CET] <JEEB> as opposed to the part of matroska where you have the decoder initialization data :) [20:06:57 CET] <form> hm, i dont know what you mean. the input file was encoded using ffmpeg, too. how can i ensure that the parameters are visible in the trimmed file, too? [20:08:27 CET] <JEEB> when you are cutting, you are skipping packets. the SEI message (think of a packet which says "I have some random data inside" and which is text) [20:08:35 CET] <JEEB> is a packet on the time line [20:08:39 CET] <JEEB> probably in the very beginning [20:08:52 CET] <JEEB> thus, when you seek, you move further into the stream [20:10:13 CET] <form> yes its in the beginning. but ffmpeg could look there, as is does for other parameters like "fps" etc., too :-) [20:10:40 CET] <kepstin> those other parameters are in an actual header, they aren't part of the main data stream [20:10:59 CET] <kepstin> the x264 encoding options are just a "junk" bit of data stuck in with the encoded video frames. [20:11:17 CET] <form> ah, understoof [20:11:19 CET] <form> -f+d [20:11:19 CET] <JEEB> form: if you mean the parameter sets ("decoder initialization data"), that's in a separate thing [20:11:36 CET] <JEEB> separate from the actual A->B video stream packets [20:11:54 CET] <form> i mean the encoder settings like " cabac=1 / ref=5 / deblock=1:0:0 ... " [20:11:58 CET] <JEEB> kepstin: not really junk. it's a proper NAL unit :D but yes, it's "just a packet" [20:12:04 CET] <JEEB> yes, I know. that's in a SEI packet :P [20:12:24 CET] <bencc1> I have a server with 8 hyperthreads. how can I limit ffmpeg to 1 core when transcoding? [20:12:32 CET] <bencc1> using "-threads 1"? [20:12:49 CET] <kepstin> bencc1: 1 core or 1 hyperthread? [20:12:54 CET] <JEEB> yes, although ffmpeg.c probably will spawn multiple threads overall :P [20:13:09 CET] <JEEB> your OS might also be able to set the process to a specific set of processor(s) [20:14:41 CET] <bencc1> kepstin: limit to 1 hyperthread [20:36:49 CET] <bencc1> if I want to reduce CPU load when capturing should I remove "-vf fps=30" re-encode in a post-processing to set constant frame rate?? [20:37:27 CET] <bencc1> this is what I currently do: https://pastebin.com/BFPPwh3p [20:38:00 CET] <kepstin> bencc1: should be negligible (probably not even a detectable difference) [20:38:10 CET] <bencc1> ok [20:38:22 CET] <bencc1> should I change "-preset:v veryfast -crf 23" to "-preset:v ultrafast -crf 0" ? [20:38:42 CET] <kepstin> depends on what your goal is and how your system performs [20:39:12 CET] <kepstin> note that -crf 0 is lossless (with 8-bit video) which means the resulting file is a lot bigger, might have to worry about io speed limitations [20:39:45 CET] <bencc1> I capture to .nut and later convert to mp4. the image in the output freeze for a few seconds each time during the video while the audio keep playing [20:39:55 CET] <bencc1> there is no A/V sync issue [20:40:21 CET] <kepstin> could be any number of things causing that, would have to analyze system load as a whole to figure out where the bottleneck is. [20:42:38 CET] <kepstin> all that means is that ffmpeg wasn't able to run x11grab to fetch the next frame in time, which could be due to it being busy encoding, being blocked writing to disk, being unable to get cpu because some other task is running, or even something in the x server taking a while. [20:43:38 CET] <bencc1> kepstin: my disk throughput is 0.48 MS/s [20:43:53 CET] <kepstin> what, is this an sd card or something? [20:44:09 CET] <kepstin> you'd be better off plugging in a spinning hdd over usb 2.0 and using that instead. [20:44:15 CET] <kepstin> that's probably the main issue. [20:44:18 CET] <bencc1> google cloud SSD persistent disks [20:45:15 CET] <bencc1> sorry, that's per GB so it's 30 times that. about 15MB/s [20:46:13 CET] <kepstin> hmm, 15MB/s is fine if it doesn't have unpredicatable high latencies. but you should still check actual achieved disk speeds using monitoring tools, make sure your system doesn't have high io wait. [20:46:45 CET] <bencc1> checking in prometheus [20:48:38 CET] <kepstin> (if your kernel's new enough, the io pressure monitoring in /proc/pressure/io is great for this, typical good case is for the "some" measurement to be in the low single digits) [20:49:21 CET] <bencc1> I measure node_cpu_seconds_total with prometheus node_expoter [20:49:30 CET] <bencc1> I'll check if they use /proc/pressure/io [20:49:46 CET] <bencc1> node_cpu_seconds_total is 0.015% [21:01:23 CET] <jokoon> kepstin, you told me that 640*360 was a good tile choice, to get 720p, why's that? [21:02:11 CET] <kepstin> nothing really special, that's just a common 'HD' video resolution that's easily divisible into 4. [21:02:24 CET] <pink_mist> because those numbers add up to 1280*720 if you stack them in a 2x2 grid [21:03:49 CET] <jokoon> doesn't that also work for 480*270? [21:04:35 CET] <pink_mist> no, that doesn't add up to 1280*720 if you stack them 2x2 [21:04:56 CET] <jokoon> I know [21:05:03 CET] <kepstin> that gives you 960x540, which is an unusual resolution. it would work fine, of course. [21:05:47 CET] <jokoon> what's wrong with unusual? [21:14:07 CET] <jokoon> oh ok so when letterboxing, its pad=<wanted width>:<wanted height>:<letterbox width>:<letterbox height> [21:14:31 CET] <jokoon> iw and ow are input width and output width [21:15:36 CET] <jokoon> my problem being I want to upscale AND downscale [21:15:42 CET] <jokoon> AND letterbox [21:18:25 CET] <kepstin> not sure what you mean by upscale and downscale [21:18:30 CET] <kepstin> you can only do one or the other? [21:19:06 CET] <kepstin> well, i suppose you can scale up in one axis and down in the other if you want to stretch your video in strange ways [22:03:30 CET] <TanaPanda> Hello [22:03:54 CET] <TanaPanda> I am streaming a video using the command: ffmpeg -loglevel debug -max_interleave_delta 15000000 -rtbufsize 128000k -threads 0 -stream_loop -1 -re -i /home/pi/Desktop/ActiveChannel/Property_LCI.mp4 -codec copy -shortest -f mpegts udp://192.168.6.2:20?pkt_size=1316?buffer_size=65536 [22:04:45 CET] <TanaPanda> but the video took a hot min to get up to 1x speed and the picture was coming in choppy [22:04:47 CET] <TanaPanda> any thoughts [22:13:01 CET] <TanaPanda> also. When I stream out the video file using VLC i keep my wifi connection. However when I stream out via ffmpeg i lose my internet. Do i need to add a command saying that the file should only stream out via ethernet? [22:42:42 CET] <bencc1> can low disk IOPS cause freezes when capturing the screen with ffmpeg? [22:43:42 CET] <bencc1> when I have one instance of ffmpeg capturing a xvfb screen inside docker it works fine [22:43:54 CET] <bencc1> when I have 4 instances on the same machine I get freezes [22:44:12 CET] <bencc1> but I don't see a problem with CPU load or memory in the machine graphs [22:45:41 CET] <BtbN> elmininate the disk writes and find out? [22:45:57 CET] <BtbN> But screen grabbing is just relatively inefficient, so I'd suspect multiple processes doing it will just kill it. [22:48:03 CET] <bencc1> BtbN: what will be the bottleneck? [22:48:17 CET] <BtbN> The screen capture [22:48:27 CET] <bencc1> cpu, memory, disk? [22:48:35 CET] <BtbN> no, the screen capture itself [22:49:03 CET] <bencc1> I'm running each screen capture in a separate docker container with separate virtual xvfb screen [22:49:26 CET] <bencc1> assuming I have enough resources, why is the screen capture the bottleneck? [22:49:32 CET] <bencc1> what resource does it consume? [22:49:41 CET] <kepstin> memory bandwidth mostly [22:49:57 CET] <BtbN> On entirely headless X, without a GPU involved, just memory. [22:49:57 CET] <bencc1> so not total ram but memory bw? [22:50:03 CET] <BtbN> But it's also horribly inefficient and locking in itself [22:50:06 CET] <bencc1> without GPU [22:50:15 CET] <BtbN> So it does not need any resourced to suck [22:50:46 CET] <bencc1> it has to be limited by something [22:51:00 CET] <bencc1> it might be memory bandwidth, I don't know [22:51:16 CET] <bencc1> but I don't understand what "horribly inefficient and locking in itself" means [22:51:19 CET] <bencc1> what does it lock? [22:51:22 CET] <BtbN> X [22:51:38 CET] <bencc1> doesn't each docker container has separate X? [22:51:50 CET] <BtbN> Who know how that stuff interacts. [22:51:53 CET] <kepstin> if you're running separate xvfb for each then yeah [22:52:01 CET] <bencc1> yes, I am [22:52:12 CET] <BtbN> It should be fairly trivial to test if it's disk io. [22:52:16 CET] <BtbN> Just... don't write to disk [22:52:16 CET] <bencc1> each ffmpeg running in a separate docker container with a separate xvfb [22:52:25 CET] <bencc1> how? [22:52:56 CET] <bencc1> if I don't write to disk, how can I test the ffmpeg video output? [22:53:11 CET] <kepstin> switch ffmpeg to use "-f null -" instead of your real output file [22:53:35 CET] <bencc1> and compare what? [22:53:35 CET] <kepstin> hmm, well, i suppose it would be hard to tell if it's hitting this issue [22:58:36 CET] <bencc1> what happens if ffmpeg doesn't have enough iops on the disk? [22:58:43 CET] <bencc1> how can I see it in ffmpeg? [22:59:53 CET] <kepstin> wouldn't be anything obvious, other than that the speed in the stats output might drop below 1.0x [23:00:12 CET] <kepstin> ffmpeg cli wasn't designed as a realtime tool, but as a batch tool :/ [23:10:37 CET] <bencc1> can I make ffmpeg use less iops? maybe with increasing thread_queue_size or similar? [23:13:53 CET] <kepstin> use settings that make the video output smaller, i guess? [23:14:24 CET] <kepstin> add 6 to your crf, that should significantly reduce the output bitrate. [23:14:44 CET] <kepstin> make it look terrible, but it's just for testing so whatever [23:15:38 CET] <bencc1> thanks [23:15:53 CET] <bencc1> maybe I'll switch to SSD and check if it fixes the issue [23:16:16 CET] <bencc1> it has much more iops and throughput [23:22:33 CET] <jokoon> hum [23:22:40 CET] <jokoon> I have a video with an orientation [23:22:45 CET] <jokoon> how can I change that? [23:23:29 CET] <jokoon> nevermind [23:33:51 CET] <jokoon> actually I cant manage to make it work [23:34:05 CET] <jokoon> I tried -codec copy with a metadata change [23:34:20 CET] <jokoon> '-codec', 'copy', '-metadata:s:v','rotate="90"', [23:46:21 CET] <jokoon> also has a chroma location: left [23:46:37 CET] <jokoon> I have green zones after converting [23:52:33 CET] <jokoon> forget it I reencoded [00:00:00 CET] --- Wed Dec 18 2019

1 0

ffmpeg-devel.log.20191216
by burek 17 Dec '19

17 Dec '19

[00:00:52 CET] <durandal_1707> they probably just wrappers [00:29:52 CET] <cone-419> ffmpeg 03Andreas Rheinhardt 07master:ed9279afbd3b: h264_mp4toannexb: Remove unnecessary check [02:53:49 CET] <mkver> stevenliu: This patch here: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254421.html fixes a recent regression (a memleak) in the hls muxer. [04:09:29 CET] <mkver> stevenliu: Can you give a link to your dash patch where someone commented you should put the variables to the start of the function? [04:11:28 CET] <stevenliu> let me find that [04:27:43 CET] <stevenliu> mkver: wait some days later, i have to repair my computer, because the Macbooks' battery have bulging :( [04:28:03 CET] <mkver> Ok. Sorry to hear that. [04:28:27 CET] <stevenliu> i will do that use backup computer :D [04:28:35 CET] <stevenliu> bye [10:11:34 CET] <kierank> we should ban rude people from trac [10:16:03 CET] <kurosu> that issue sure packs a lot of such people [10:16:53 CET] <kurosu> I never quite understood the value of troll- or bully-driven incentivi[sz]ation [10:17:56 CET] <kurosu> in this particular case, if someone was capable of implementing this, such ticket may drive him away from doing it [10:18:20 CET] <thardin> idgi, isn't it just a case of telling ffmpeg to copy over the metadata? [10:19:37 CET] <thardin> aha, it ties into lavfi's color model and whatnot [10:20:12 CET] <thardin> real boomer energy in there [10:23:03 CET] <kurosu> thardin: not paying further attention to this ticket anyway [10:24:03 CET] <thardin> good call [11:11:58 CET] <thardin> this guy doesn't seem to be aware that transfer functions are still a thing for 8-bit components [11:33:46 CET] <nevcairiel> that entire ticket is full of so much ignorance [11:40:04 CET] <JEEB> I think the ticket just veered somewhere ages ago [11:40:11 CET] <JEEB> I haven't looked at it in months [11:41:26 CET] <nevcairiel> The initial ticket was reported by that same guy thats still trying to educate everyone, so it never really had a good start to begin with [11:42:59 CET] <nevcairiel> gotta love people that have an opinion how everyone else should run their projects and spend their time, but haven't contributed a single thing to anything in their lifetime [12:08:51 CET] <cehoyos> This will make it much better;-) [12:11:03 CET] <Illya> well... maybe he's not aware it's possible to sponsor work? :p [12:11:09 CET] <Illya> not like it can get much worse anyway [12:12:09 CET] <cehoyos> I'm not so sure: After all, the ticket was quiet for several months [13:13:50 CET] <durandal11707> i get best output if i use normalize filter, so only tf is needed [13:23:23 CET] <thardin> Illya: I think it's good [13:24:20 CET] <thardin> someone exuding this amount of boomerism should not have a problem paying people for their hard work [13:31:56 CET] <JEEB> teh colorspace info if it still is lost, is because ffmpeg.c initializes the encoder before it gets the output from filtering [13:32:02 CET] <JEEB> you have that with non-HDR as well [13:32:30 CET] <JEEB> I've been thinking if we should instead move libx264/5 to test init in init(), and actually properly init according to the AVFrame fed in case avcodeccontext doesn't have values set [13:32:45 CET] <JEEB> that's AFAIR how VLC does it with their libx264 module [13:34:05 CET] <nevcairiel> i thought we fixed some of that, but regardless, the HDR details are probably still lost, but imho their base assumption is just wrong, when they encode with any other tool, they'll be prompted to pick what kind of of format of video they want to encode, and specify such information like HDR, but just because ffmpeg CLI is not interactive like that, they assume it'll magically do the "right thing" (whatever that is), without having [13:34:06 CET] <nevcairiel> to provide any information whatsoever [13:34:45 CET] <JEEB> at least with filter_complex last I tested it wouldn't get the colorspace info, so libx264 got initialized with nope-nope-nope [13:34:52 CET] <JEEB> but yes [13:42:54 CET] <nevcairiel> there is a mechanic to wait for the filter to produce a frame before the output is setup, but it may just not hook up color properties at all [13:43:10 CET] <nevcairiel> because of the disparity between context color properties and frame properties [13:45:01 CET] <nevcairiel> in any case its not impossible to solve, someone just needs to untangle that a bit [13:46:43 CET] <JEEB> yea [13:46:57 CET] <JEEB> I tried to also make reconfig handle colorspace changes in libx264 once [13:47:02 CET] <JEEB> got as far as adding code in x264 [13:47:12 CET] <JEEB> but I don't think it does anything unless you change rate control [13:47:14 CET] <JEEB> :< [13:48:15 CET] <durandal11707> yes, i found color space definitions for Blackmagic Design [14:11:34 CET] <Illya> thardin: seems it was ignored anyway :'( [14:15:11 CET] <JEEB> wow, they're in their own bubble [14:31:29 CET] <thardin> no you see what he's saying is based on logic so he must be right [16:18:36 CET] <cone-434> ffmpeg 03Andriy Gelman 07master:c07a77247363: lavc/cbs_h2645_syntax_template: Fix memleak [20:45:56 CET] <philipl> BtbN: it was ffmpeg-devel. [20:53:47 CET] <cone-529> ffmpeg 03Carl Eugen Hoyos 07master:84db67894f9a: lavu/log: Also print the log level for level trace. [22:26:42 CET] <philipl> BtbN: https://patchwork.ffmpeg.org/patch/16329/ [22:41:00 CET] <cehoyos> Please don't feed the troll... [22:46:43 CET] <cone-529> ffmpeg 03Carl Eugen Hoyos 07master:9f6a06d9271a: lavc/allcodecs: Add mpeg4 omx encoder, missed in 0e387232 [22:47:24 CET] <durandal11707> michaelni: please review swscale asm patches [22:50:48 CET] <j-b> durandal11707: the ARM one? [22:50:59 CET] <cehoyos> no, ssse3 iirc [22:52:16 CET] <j-b> ok [22:57:53 CET] Action: michaelni thought the developers who review all the x86 asm nowadays would want to review that too, but i can take a look, not today though, too late and too many other things to do [22:58:55 CET] <j-b> Did someone summon Gramner or psilokos on those? [23:32:43 CET] <BBB> I don't think psilokos is an active ffmpeg developer (yet) [00:00:00 CET] --- Tue Dec 17 2019

1 0

ffmpeg.log.20191216
by burek 17 Dec '19

17 Dec '19

[00:00:17 CET] <kepstin> with good cables and equipment, it would be hard to tell the difference between component and hdmi at sd resolutions. [00:00:33 CET] <kepstin> but hdmi is only one cable/connector, so it's nicer to use :) [00:00:35 CET] <johnjay> sorry what? [00:00:43 CET] <johnjay> isn't that a contradiction? [00:00:54 CET] <johnjay> oh i see composite [00:01:05 CET] <johnjay> composite =/= component @_@ [00:01:39 CET] <kepstin> composite sticks all the stuff from the three signals in component together onto one wire - it's a "composite" signal of multiple components [00:02:12 CET] <johnjay> which means less bandwidth total and more loss? [00:02:28 CET] <BtbN> both [00:02:31 CET] <kepstin> yeah, and it can also cause interference between different parts of the signal [00:02:44 CET] <BtbN> It's better than RF, but still pretty horrible [00:03:13 CET] <BtbN> Ideally for analog sources you want RGB or YUV Component output [00:03:24 CET] <johnjay> hmm. i hate to throw away working stuff though. maybe i can just give this dvd player to salvation army [00:03:36 CET] <BtbN> Does it not have SCART with RGB? [00:03:58 CET] <kepstin> johnjay: should confirm what region you're in :) [00:03:59 CET] <johnjay> i'm not sure what scart is but it has the red/green/blue things [00:04:06 CET] <kepstin> scart is a europe-only thing [00:04:12 CET] <johnjay> NA here [00:04:17 CET] <kepstin> (i've only heard of it in uk, actually) [00:04:30 CET] <johnjay> wiki mentioned it but i didn't understand the description [00:04:52 CET] <kepstin> yeah, north american equipment has pretty much only ever had composite or YUV component using rca connectors [00:05:24 CET] <BtbN> S-Video is also a thing over there [00:05:26 CET] <kepstin> (the component cable ends are normally coloured red, green, and blue but they actually carry a YUV signal, not RGB) [00:05:30 CET] <BtbN> It's like slightly better composite [00:05:46 CET] <BtbN> And the most fragile plugs anyone could ever come up with [00:05:48 CET] <johnjay> kepstin: interesting [00:05:59 CET] <johnjay> haha indeed! [00:06:20 CET] <kepstin> johnjay: fun fact, you can switch the red/blue cables or leave one unconnected to mess the colour channels up [00:06:53 CET] <kepstin> i had a friend who played an entire ps2 game with one of the colour channels disconnected and they didn't even notice, because it was the blue one so skin tones didn't look very wrong [00:08:42 CET] <johnjay> lol [00:09:22 CET] <kepstin> (connecting only the green cable - Y channel - gives you a black/white picture) [00:09:59 CET] <kepstin> that's the cable that has the synchronization signalling on it, you'll get no picture at all unless that cable is connected. [00:10:13 CET] <BtbN> That varies [00:10:26 CET] <BtbN> I have a bunch of equipment here that has a 4th Sync-Wire [00:11:01 CET] <kepstin> well, with 3-connector composite connectors of the type popular in north american consumer electronics, that's the case [00:11:57 CET] <kepstin> that same friend of mine also has some scart equipment, and has built equipment to split out or combine the sync signals :/ [00:12:11 CET] <kepstin> i mostly just do digital video :) [00:12:13 CET] <BtbN> Since SCART cables commonly carried both composite and component at the same time, they always used the composite line for sync signaling [00:13:55 CET] <kepstin> speaking of digital video, does anyone know what the corpus vbr mode (corpus-complexity option) for libvpx-vp9 is supposed to do? [00:14:13 CET] <kepstin> there's basically no documentation for it, even in libvpx [00:25:59 CET] <noudle> currently trying to build ffmpeg on arch arm in order to build omxplayer, but im getting "unrecognized command line option '-mfpu=vfp'; did you mean '-mcpu='?" and the same for '-mfloat-abi=hard' [00:26:12 CET] <noudle> following instructions in the readme from here https://github.com/popcornmix/omxplayer [00:26:29 CET] <noudle> any ideas what i could do? [00:27:07 CET] <noudle> this is on the "make ffmpeg" step in the configure step [00:27:19 CET] <noudle> the error is from the config.log [00:29:47 CET] <noudle> cant find anything regarding that on google tbh [00:32:44 CET] <cehoyos> noudle: Do not follow third-party readmes (or ask them for support), just tell configure where it find your toolchain [00:33:21 CET] <noudle> cehoyos: i get a similar problem when trying to configure the ffmpeg sources directly [00:34:17 CET] <noudle> then the -mcpu= is missing one arg [00:55:22 CET] <noudle> cehoyos: gcc: error: missing argument to '-mcpu=' [01:03:47 CET] <cehoyos> noudle: Please provide the configure line you tested including the complete, uncut console output and confirm that you are testing current FFmpeg git head, the only version supported here [01:04:01 CET] <cehoyos> And the gcc version [01:11:59 CET] <noudle> cehoyos: http://ix.io/24yu [01:13:27 CET] <cehoyos> I see: ./configure --arch=armel --target-os=linux --enable-gpl --enable-omx --enable-omx-rpi --enable-nonfree [01:14:02 CET] <cehoyos> This shows no error message but both target-os and -arch look unneeded. [01:14:07 CET] <cehoyos> Why is there "enable-nonfree"? [01:14:55 CET] <cehoyos> ok, nonfree is required for omx [01:16:40 CET] <noudle> i can ommit those two and see what happens [01:17:04 CET] <cehoyos> You could also start with "./configure --enable-gpl" [01:17:14 CET] <noudle> true [01:17:21 CET] <noudle> let me just do so [01:17:35 CET] <cehoyos> Sadly, I have to leave soon, sorry [01:17:41 CET] <noudle> np [01:17:44 CET] <noudle> ty anyways [01:17:45 CET] <noudle> :) [01:18:00 CET] <cehoyos> but please test now [01:18:25 CET] <noudle> i get "ERROR: OpenMAX IL headers from raspberrypi/firmware not found" without those two args but with the rest [01:18:49 CET] <cehoyos> You could also start with "./configure --enable-gpl" [01:19:14 CET] <noudle> yes thats running atm [01:19:21 CET] <noudle> sec [01:20:27 CET] <noudle> that seems to pass [01:21:06 CET] <cehoyos> I suggest you also test compilation and fate (make SAMPLES=fate-suite fate-rsync && make SAMPLES=fate-suite fate) [01:21:39 CET] <cehoyos> To resolve the omx header issue, you have to look at the tail of config.log [01:21:51 CET] <cehoyos> (I never compiled with omx, no idea what you need for it) [01:22:53 CET] <noudle> it is the only player which can play videos fluently on a pi [01:23:04 CET] <noudle> because of some hardware acceleration [01:23:08 CET] <noudle> iirc [01:23:23 CET] <cehoyos> I suggest you also test compilation and fate (make SAMPLES=fate-suite fate-rsync && make SAMPLES=fate-suite fate) <- this is to check if I am correct that arch is unneded: I always thought it should never be used but it can be useful for some Windows toolchains [01:23:37 CET] <noudle> hmm will do so [01:23:38 CET] <noudle> ty [01:23:52 CET] <cehoyos> I didn't mean I have no idea what omx is, just that I never tested it and never compiled it [01:25:47 CET] <Arnob> furq: Thks. When running: ffmpeg -y -i 1.wav -loop 1 -i b.jpg -filter_complex "[0:a]showwaves=s=1280x720:mode=line:colors=0xff0000|0x0000ff,colorkey=0x000000:0.01:0.1,format=yuva420p[v];[1:v][v]overlay[outv]" -map "[outv]" -pix_fmt yuv420p -map 0:a -c:v libx264 -c:a copy -shortest output1.mkv , I have this error: [Parsed_showwaves_0 @ 0xea7080] Option 'colors' not found [01:25:49 CET] <Arnob> [AVFilterGraph @ 0xea6b40] Error initializing filter 'showwaves' with args 's=1280x720:mode=line:colors=0xff0000|0x0000ff' [01:25:51 CET] <Arnob> Error initializing complex filters. [01:25:53 CET] <Arnob> Option not found [01:39:48 CET] <cehoyos> Arnob: The option "colors" of the showwaves filter is four years old... [01:39:57 CET] <cehoyos> Please test current FFmpeg git head before reporting any issues [06:20:21 CET] <grosso> for a codec that has the AV_CODEC_CAP_DELAY flag set, I want to know what is the actual delay [09:59:30 CET] <gamelaster> Hi, is there function in c api, with which I can parse packet manually, instead of avio_alloc_context's customs read funcs? [09:59:53 CET] <JEEB> more specifics, please? [10:00:03 CET] <JEEB> parsing has a very specific meaning with lavf/lavc, which is separate from demuxing [10:01:06 CET] <gamelaster> JEEB ah yeah, true. I have file with MPEGTS, I want to parse it by myself => find MPEGTS (188 size) bytes, and then supply it to avformat mpegts demuxer, which will return me AVPacket [10:01:40 CET] <gamelaster> I just want to connect MPEGTS packet with AVPacket, to measure performance of ffmpeg and my code [10:01:59 CET] <JEEB> not sure how simple that would be :P [10:02:25 CET] <JEEB> I mean, I've only seen/used the custom AVIO APIs if you want to have your own I/O buffer and feeding funcs [10:04:19 CET] <gamelaster> yeah, me too, but then I can't connect directly the AVPacket with MPEGTS packet. Well, I will try to lurk the ffmpeg docs and funcs if I will find something useful. [11:25:31 CET] <Arash_dev> hi guys, anyone scipted an animated watermark on videos?? [11:25:44 CET] <Arash_dev> i want script a watermark moving on corners and stop on each corner for a seconds [11:25:44 CET] <Arash_dev> this movment repeat until video has ended [11:28:05 CET] <Arash_dev> some thing like this [11:28:06 CET] <Arash_dev> ffmpeg -i "video.mp4" -i "1B.png" -i "1B.png" -i "1B.png" -i "1B.png" -i "1B.png" -i "1B.png" -filter_complex " [11:28:06 CET] <Arash_dev> overlay=1:H-h:enable='between(t,0,3)', [11:28:06 CET] <Arash_dev> overlay=1+(t-3)*200:(H-h):enable='between(t, 3, 7)', [11:28:06 CET] <Arash_dev> overlay=W-w:H-h:enable='between(t,7, 12)', [11:28:06 CET] <Arash_dev> overlay=W-w:(H-h)-(t-12)*200:enable='between(t, 12, 16)', [11:28:07 CET] <Arash_dev> overlay=W-w:1:enable='between(t,16,20)', [11:28:07 CET] <Arash_dev> overlay=(W+w)-(t-20)*200:1:enable='between(t, 20, 26)'" out.mp4 [11:29:45 CET] <pink_mist> please use a paste site for that many lines [11:33:56 CET] <Arash_dev> some thing like this : https://justpaste.it/1tp6g [11:42:03 CET] <sine0> ok im going for a long road trip today and i have a crappy mp3 hardware usb radio. whats going to be the best settings or bitrate for compatability [11:42:26 CET] <sine0> mp3 128 256 cbr [12:25:44 CET] <jokoon> sorry to ask again, but is there a way to combine several videos into one ? for example to play 6 videos into 1, in a 2x3 layout? [12:26:12 CET] <furq> jokoon: https://ffmpeg.org/ffmpeg-filters.html#xstack [12:26:21 CET] <jokoon> ah thanks [12:26:33 CET] <furq> sine0: any cbr mp3 should be fine [12:26:40 CET] <furq> really really old stuff has issues with vbr [12:26:47 CET] <furq> anything made in the last 10 years should be fine [12:27:00 CET] <furq> probably just encode some stuff and check it before you leave [12:27:29 CET] <jokoon> problem is, most of those videos don't have the same size, not to mention ratio [12:28:28 CET] <jokoon> so I might start to resize those video first [12:28:35 CET] <furq> xstack supports inconsistent sizes, it'll just add padding [12:28:44 CET] <furq> you can just resize them earlier in the filterchain if you want to avoid that [12:29:02 CET] <jokoon> yeah but if the size difference is too large, it won't be good [12:29:30 CET] <jokoon> in the filterchain? [12:29:34 CET] <furq> -lavfi "[0:v]scale=1280:720[tmp0];[tmp0][1:v]hstack" or something like that [12:29:45 CET] <jokoon> will ffmpeg also mix the sound? [12:30:11 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#amix [12:33:10 CET] <jokoon> thanks [12:44:07 CET] <jokoon> any UI software can do this with some interface? [12:44:11 CET] <jokoon> like avidemux? [12:44:27 CET] <jokoon> I mean xstack? [14:02:03 CET] <Arnob> @cehoyos: Does it mean I can't use the option 'colors' anymore? In that case how can I change the waveform color? [14:03:51 CET] <durandal11707> Arnob: it means your ffmpeg version is too old [14:58:48 CET] <grosso> for a codec that has the AV_CODEC_CAP_DELAY flag set, there is a way to know the actual delay? [15:02:42 CET] <JEEB> I think there currently is no proper interface for that [15:15:08 CET] <grosso> thank you [15:42:10 CET] <noudle> i try to compile the latest ffmmpeg from the git repo on my pi which is running arm arch fully updated. i configure ffmpeg like this: ./configure --enable-gpl [15:42:42 CET] <noudle> configure passes but it fails at compilation with "libavcodec/dds.c: In function 'dds_decode':" "libavcodec/dds.c:749:1: internal compiler error: Illegal instruction" [15:43:05 CET] <noudle> using gcc 8.3.0 [15:44:04 CET] <noudle> in the end i want to compile ffmpeg to compile omxplayer (https://github.com/popcornmix/omxplayer) [15:44:44 CET] <noudle> also i tried to follow the compile instructions here: https://github.com/legotheboss/YouTube-files/wiki/(RPi)-Compile-FFmpeg-with… [15:45:19 CET] <noudle> but adding '--arch=armel' or '--target-os=linux' to ./configure fails with 'gcc: error: missing argument to '-mcpu='' [15:46:22 CET] <noudle> and adding the '--enable-omx --enable-omx-rpi --enable-nonfree' results in 'ERROR: OpenMAX IL headers from raspberrypi/firmware not found' [15:46:41 CET] <noudle> altho pacman say 'extra/libomxil-bellagio 0.9.3-2 [installed]' [15:47:01 CET] <noudle> any ideas what i can do now? [16:23:21 CET] <noudle> i'll idle a bit if someone has a tip pls msg me :) [16:24:22 CET] <kepstin> noudle: that error you gave with compilation failing indicates that your system compiler is broken, nothing to do with ffmpeg [16:25:12 CET] <kepstin> please contact your linux distro support. [16:38:06 CET] <noudle> kepstin: you mean the missing argument one? [16:38:20 CET] <kepstin> no, the "internal compiler error: illegal instruction" one [16:38:31 CET] <noudle> ah i see [16:38:37 CET] <noudle> okay [16:39:07 CET] <kepstin> probably means the compiler package was built for a different/incompatible cpu than the one in your system [16:41:04 CET] <noudle> hmm i installed it through the system package manager [16:46:36 CET] <pink_mist> not surprising [16:46:57 CET] <pink_mist> that's why you were recommended to contact your distribution's support [16:47:45 CET] <noudle> ye i understand that but i was thinking the compiler package from the system package manager would be suited for the system [16:48:36 CET] <noudle> im currently running another compile try with different configure args, its still running.. if it fails again with that error i will do so [16:55:33 CET] <pink_mist> noudle: yes, we're all thinking that the compiler package from the system package manager _should_ be suited for the system ... the fact that it's not is why you should contact your distribution's support [16:56:05 CET] <noudle> that what i will do if this compile attempt running atm will fail too [16:57:53 CET] <jokoon> I have 517950181/8641135 in frame rate [17:00:28 CET] <kepstin> that's a fun number. [17:00:59 CET] <kepstin> looks like someone rounded 60000/1001 incorrectly. [17:01:27 CET] <jokoon> why 1001? [17:01:42 CET] <kepstin> because historical reasons [17:01:54 CET] <jokoon> that's an excellent excuse [17:01:56 CET] <kepstin> (that's the field rate of ntsc colour television, by definition) [17:02:03 CET] <jokoon> ok [17:02:45 CET] <kepstin> black and white was exactly 60, they slowed it down a touch when they added colour to reduce interference with the colour subcarriers. [17:03:08 CET] <jokoon> something along the line "because of the earth tilt" and "there are not exactly 24 hours in a day" [17:03:50 CET] <noudle> pink_mist: the compile passed hehe [17:04:07 CET] <kepstin> noudle: might have just been a cosmic ray glitch in your ram or something then :) [17:04:11 CET] <jokoon> can you image the quantum computer in years 5000? aliens will ask "what is \n and \r?" [17:04:29 CET] <kepstin> even now people ask what those are for and why they're separate [17:08:47 CET] <kepstin> i mean, when's the last time you've seen a teletypewriter with a print mechanism using a carriage? [17:09:22 CET] <noudle> kepstin: have you an idea how to fix "ERROR: OpenMAX IL headers from raspberrypi/firmware not found"; meaning how to tell ffmpeg configure where to find the headers? [17:10:22 CET] <noudle> as i think i have them installed through pacman already [17:11:08 CET] <kepstin> it expects them in either the system headers location or /opt/vc/include/IL (presumably the default raspi distro location) [17:11:28 CET] <kepstin> if it's not in either of those, you might just have to manually add the include location to your cflags [17:14:47 CET] <noudle> you mean export them? [17:16:24 CET] <kepstin> pass an --extra-cflags= option to the configure script with the options required to get the compiler to find the omx headers [17:16:42 CET] <noudle> okay sec [17:19:57 CET] <noudle> hmm [17:20:11 CET] <noudle> i mean it needs to find OMX_Core.h and such right? [17:20:18 CET] <noudle> they are in /usr/include/ [17:21:02 CET] <kepstin> does your OMX_Core.h file contain "OMX_IndexConfigBrcmVideoRequestIFrame"? [17:21:28 CET] <kepstin> if not, then you don't have the raspberry-pi specific headers [17:21:29 CET] <noudle> no [17:21:39 CET] <noudle> meh [17:22:01 CET] <noudle> i found some sources bit they where from 2009 or so so i was not sure if those where the right ones.. [17:22:04 CET] <noudle> *but [17:22:35 CET] <kepstin> tbh, i've only ever heard of this working on the raspian distro, i didn't even know you could run arch on the things. [17:23:19 CET] <noudle> there is even a omxplayer package for arch arm but it did not work for me thats why i try to compile things from sources [17:23:43 CET] <noudle> are theese the right ones? https://github.com/felipec/libomxil-bellagio [17:24:39 CET] <noudle> guess not.. [17:47:46 CET] <grosso> I notice h264_mediacodec decoder has the AV_CODEC_CAP_DELAY set, and, in fact, it has a very high latency of several frames even with baseline profile, while ffmpeg's native h264 codec has none. [17:49:00 CET] <grosso> i want to know: 1) if I can estimate that latency in advance; 2) If I can configure mediacodec decoder to avoid such latency [17:51:05 CET] <jokoon> can ffmpeg be configured to use the GPU to encode? [17:51:24 CET] <kepstin> grosso: are you sure it actually has a frame latency, and not just an asynchronous wait while it send to the hardware, decodes, and downloads off the hardware? [17:51:47 CET] <kepstin> jokoon: ffmpeg can be configured to use the hardware encoder included on the dies of many GPUs [17:52:05 CET] <jokoon> and does it give a big enough boost with low to moderate GPU ? [17:52:17 CET] <kepstin> jokoon: note that these are dedicated hardware encoders, it does not use the gpu compute power [17:52:20 CET] <jokoon> does it work for all video encoders? [17:52:41 CET] <kepstin> the hardware encoder is used *instead* of the software encoder, it does not speed up the software encoder [17:52:50 CET] <kepstin> codec support depends on the hardware [17:52:54 CET] <jokoon> so is it an option worth pursuing? [17:53:12 CET] <pink_mist> mostly not [17:53:19 CET] <pink_mist> they often give worse results [17:53:20 CET] <kepstin> hardware encoders are mostly useful for encoding realtime video streams when your cpu is busy doing something else [17:53:27 CET] <jokoon> oh ok [17:53:44 CET] <jokoon> I remember mediacoders advertised using the GPU [17:53:46 CET] <kepstin> e.g. they're decent for livestreaming gaming and things like that [17:53:51 CET] <jokoon> the software called mediacoder [17:54:02 CET] <grosso> kepstin: I'm not sure about that; all I can see is that while I feed h264 packets in, it seems to buffer several of them, and then it begins to output decoded frames [17:54:57 CET] <kepstin> grosso: hmm, so if you just send one packet in and poll receive_frame for a while, you don't get a frame ever? [17:56:03 CET] <kepstin> well, polling receive_frame isn't really the way the api is intended to be used, i dunno what that'll actually do in this case :) [17:56:51 CET] <kepstin> grosso: as far as it goes, ffmpeg's just using an external api here, there's not really much control :/ [17:57:45 CET] <jokoon> https://i.imgur.com/SYastgk.png I have those videos, Im planning to make a 3x3 xstack... should I resize them or can ffmpeg do it with it's doing the xstack stage? I've read it can scale the video [17:58:05 CET] <jokoon> Im aware some have a 0.5 ratio, I will those [17:58:25 CET] <jokoon> Im also curious about the frame rate difference, will that cause problems? [17:59:41 CET] <kepstin> xstack does not scale video, you need to scale before using the filter [18:00:05 CET] <jokoon> thing is, I'm also planning to queue videos, since they have various duration, but I don't know if it can be done [18:00:25 CET] <kepstin> i'd recommend making the framerates all match before using xstack for best performance [18:00:34 CET] <jokoon> meaning each square will play another video when one will finish [18:01:05 CET] <jokoon> performance? so xstack will interpolate or something else? [18:01:06 CET] <grosso> kepstin: I go to try it and I tell you the result... but I guess it's not going to work... you see, when I say "several frames" I mean more than 1 second, since my video is 10fps... I doubt that an asynchronous wait for hardware communication is that long... [18:01:33 CET] <kepstin> jokoon: basically every time there's a new frame on any input, xstack will make an output frame [18:01:47 CET] <kepstin> jokoon: so if the inputs have different framerates, it'll output lots of extra frames [18:01:54 CET] <jokoon> Oh I see [18:02:12 CET] <jokoon> it will be much slower [18:02:38 CET] <jokoon> how ffmpeg reduce the framerate? interpolation? [18:02:50 CET] <kepstin> jokoon: there's multiple ways to change framerate in ffmpeg [18:03:00 CET] <kepstin> the fps filter simply drops/duplicates frames [18:06:11 CET] <kepstin> the framerate filter does a plain linear blend between frames (maybe ok if there's minimal motion) [18:06:28 CET] <kepstin> the minteroplate filter does motion compensated interpolation [18:06:40 CET] <grosso> there is any ffmpeg-mediacodec documentation and/or examples? [18:07:30 CET] <kepstin> hmm, i'm getting confused, mediacodec is the android thing, right? [18:07:40 CET] <kepstin> got it mixed up with the apple one [18:07:56 CET] <jokoon> so minterpolate is best, I guess it doesn't require that much more CPU ? [18:08:09 CET] <kepstin> i'd expect it to require significantly more cpu [18:08:26 CET] <kepstin> for most video, fps filter probably does something reasonable [18:08:40 CET] <kepstin> motion interpolation can add noticable artifacts [18:09:04 CET] <jokoon> wait, fps filter and framerate filter are different things/ [18:09:05 CET] <jokoon> ? [18:09:08 CET] <grosso> mediacodec is the android thing, that is [18:09:35 CET] <kepstin> fps filter preserves what the video currently looks like as close as possible when increasing framerate, worst it does it add a bit of jitter to frame timing. [18:09:57 CET] <grosso> the apple one is videotoolbox, by the way, way better [18:10:32 CET] <jokoon> I have video at 30 and 24, should I make them all 24 or 30? [18:10:47 CET] <kepstin> jokoon: it'll look bad either way [18:11:02 CET] <kepstin> but if you do 30 it won't remove frames, it'll just make the 24fps video a bit juddery [18:12:41 CET] <jokoon> so 30 seems better [18:12:48 CET] <jokoon> I'm going to test either way [18:13:04 CET] <kepstin> if you have to merge videos with different framerates like that into one video, would be best to match the refresh of the intended output device. [18:13:12 CET] <kepstin> so probably 60, although 120 would be better :) [18:13:51 CET] <jokoon> I'm not really targetting any particular device [18:14:13 CET] <jokoon> both computer screen and smartphone screens [18:15:48 CET] <jokoon> does most ffmpeg users use the command line, or some UI or maybe some scripting to do things? [18:19:06 CET] <kepstin> i personally mostly use the cli tool, sometimes scripted. [18:53:12 CET] <matto312> Hello! I've been working on a video project for about month now. I'm experienced dev, but new to video domain. I'm close to having this done, but stuck on 1 issue. I'm taking live RTMP input and generating multi-variant HLS output. Most of the time works great, however, sometimes output is frozen video. TS files are being generated but it's frozen to single frame (and the video files are ~1/3 size). Here is the cmd and output of case wh [18:53:13 CET] <matto312> ere the above issue happens. https://pastebin.com/feshz4DJ Any help would be greatly appreciated! Let me know if I need to provide more info. Thank you! [19:02:41 CET] <BeerLover> Hi, I am running this command https://0x0.st/z0Zj.txt to create a HLS master playlist with 4 different bitrates - 320k, 128k, 64k, 32k. But the final master.m3u8 created has different bandwidths. master.m3u8 https://0x0.st/z0Z2.m3u8 [19:02:51 CET] <BeerLover> What can be the issue? [19:15:39 CET] <BeerLover> if i copy the audio codec, can i not change the bitrate? [19:16:05 CET] <BeerLover> for example, ffmpeg -i s.mp3 -c:a copy -b:a 32k s2.mp3 [19:22:46 CET] <DHE> BeerLover: you can't both copy it and change it [19:23:18 CET] <DHE> if you want to use the SAME codec, you still have to specify it. but since you're outputting to mp3, it will auto-select a codec and you can just leave out the -c:a parameter entirely [19:33:31 CET] <BeerLover> DHE: what about my other question [19:33:34 CET] <BeerLover> ? [19:33:44 CET] <BeerLover> Hi, I am running this command https://0x0.st/z0Zj.txt to create a HLS master playlist with 4 different bitrates - 320k, 128k, 64k, 32k. But the final master.m3u8 created has different bandwidths. master.m3u8 https://0x0.st/z0Z2.m3u8 [19:42:15 CET] <DHE> sorry busy right now [19:43:28 CET] <kepstin> the hls muxer would be estimating that based on the media it receives, so it's possible that the abr on the mp3 encoder overshot during the period that it sampled, or maybe it's just including mpeg-ts overhead? [19:50:55 CET] <BeerLover> kepstin: can i cap that per stream? [19:51:17 CET] <BeerLover> so that it never goes beyond the defined cap? [19:54:11 CET] <sine0> furq: cbr ftw drive was tollerable [20:05:46 CET] <webreformer> Is there any tool that provides stats(frequency, frames) at the sound card level ? [20:07:37 CET] <webreformer> There is a pitch change and I would like to trace back audio details before it;s actually played by sound card. [20:37:07 CET] <cehoyos> noudle: Workaround for the compiler bug is to either compile the specific file without optimizations (run make V=1 libavcodec/dds.o, copy the invocation and add -O0) or use the configure switch --disable-decoder=dds [20:46:11 CET] <BeerLover> Hi, I am running hls transcoding to create a HLS master playlist with 4 different bitrates - 320k, 128k, 64k, 32k. But the final master.m3u8 created has different bandwidths and the segments also have different bitrates. The input file info, command, segment info (all bitrates), master.m3u8 file info: https://0x0.st/z0NQ.txt [20:46:58 CET] <BeerLover> Is there any way I can cap the audio bitrate in the segments? I tried -maxrate -minrate -bufsize, but there's no difference [20:49:24 CET] <noudle> cehoyos: i did compile ffmpeg with omx support on the pi some hours ago, now im testing it [20:51:10 CET] <cehoyos> BeerLover: You are specifying the codec bitrate on the command line, the master file contains the file bitrate (which is only identical for raw audio formats like mp3, not for high-overhead streaming formats like mpegts) [20:51:24 CET] <cehoyos> noudle: Did you disable the dds decoder? [20:51:42 CET] <noudle> nope [20:51:57 CET] <noudle> i just needed some extra flags for the configure script [20:52:00 CET] <BeerLover> cehoyos: so what should I do? [20:52:05 CET] <noudle> and the omx headers from the right packages [20:52:23 CET] <noudle> which are not available for my arch but seems like i could compile them anyways [20:53:39 CET] <BeerLover> cehoyos: what if i edit the master.m3u8 file and alter the bitrate? Will it cause any problem? Actually there's some hardcoding in the client that depends on the BANDWIDTH in master.m3u8 file [20:58:33 CET] <cehoyos> Why don't you just reduce the codec bitrate? [20:58:51 CET] <cehoyos> noudle: What extra flags did you provide? [20:59:10 CET] <noudle> cehoyos: when i try to open a video with ffplay i get "No decoder could be found for codec av1" and i then can just "see" the audio on screen [20:59:23 CET] <noudle> cehoyos: ./configure --enable-libfreetype --enable-gpl --enable-nonfree --enable-libx264 --enable-libass --enable-libmp3lame --enable-omx --enable-omx-rpi [21:06:36 CET] <cehoyos> noudle: That indicates (imo) that you have a termal issue with your hardware [21:06:53 CET] <noudle> what indicates that? [21:07:05 CET] <cehoyos> Your configure line still tries to compile dds.o, if it fails once but succeeds another time, this is not a good sign for your hardware. [21:07:19 CET] <cehoyos> gcc is known to trigger such issues easier than most other software [21:07:46 CET] <cehoyos> To get av1 decoding, you need either dav1d or libaom [21:08:00 CET] <cehoyos> Since compiling dav1d is a major task, I suggest libaom (which is slower) [21:08:26 CET] <noudle> is a "major task" just taking more time to compile or is it harder to compile? [21:08:35 CET] <noudle> as on a pi i like things that are "faster" [21:12:32 CET] <BeerLover> cehoyos: is there any specific relation between the codec bitrate and final file bitrate? How much should I reduce it by to get "X" bitrate? Or is it hit and trial? [21:15:12 CET] <noudle> cehoyos: i ned to fix some audio over hdmi problems first befire i can continue with the video output of ffplay [21:17:17 CET] <cehoyos> noudle: Feel free to test dav1d compilation, although I am not sure if the "faster" is also true for arm [21:17:40 CET] <noudle> i will [21:17:41 CET] <fling> How do I add a thumbnail to mp4 properly? [21:17:43 CET] <noudle> i guess [21:17:49 CET] <fling> Is it just another mjpeg stream? [21:17:52 CET] <cehoyos> BeerLover: You can calculate it but you already know the numbers... [21:18:06 CET] <fling> this thing adds them somehow http://atomicparsley.sourceforge.net [21:18:33 CET] <BeerLover> cehoyos: didn't get you. [21:21:06 CET] <BeerLover> I know what I want in the final master.m3u8 (bandwidths) [21:21:23 CET] <BeerLover> How to know what bitrates I should pass wo codec? [21:22:25 CET] <cehoyos> You posted a link to a page that showed the overhead [21:23:25 CET] <fling> Is there a piece of metadata telling which stream has a thumbnail in mp4? [21:23:52 CET] <BeerLover> cehoyos: really? I can't find it in the link i shared [21:24:54 CET] <cehoyos> You asked for 32k and how much did you get? [21:25:13 CET] <BeerLover> 35200 [21:25:27 CET] <cehoyos> Indicates 10% overhead, no? [21:25:52 CET] <BeerLover> sorry I got 37k, but bandwidth is 35200 [21:26:05 CET] <BeerLover> it's not 10% constant across bitrates [21:35:11 CET] <fling> it is -disposition attached_pic [21:38:39 CET] <fling> Can I mux a text file as a stream? [22:03:29 CET] <cehoyos> fling: Most containers do not like "text" [22:12:07 CET] <fling> cehoyos: I found -attach option [22:17:55 CET] <fling> How do I apply a filter only to one of the streams? [22:18:30 CET] <fling> -filter[:stream_specifier] [22:18:31 CET] <fling> ok ;P [22:22:34 CET] <noudle> cehoyos: got ffplay working and audio over alsa too, can playback videos with audio over hdmi nearly fluently [22:22:53 CET] <noudle> is there a way to check if ffplay uses the omx stuff to include GPU for processing? [22:23:00 CET] <noudle> as its eating up all the cpu power of the pi [22:23:06 CET] <noudle> and its getting really hot LOL [22:23:21 CET] <cehoyos> Complete, uncut console output missing. [22:23:35 CET] <noudle> of ffplay? [22:23:47 CET] <cehoyos> Of whatever command you were testing [22:24:05 CET] <noudle> ye was ffplay [22:24:05 CET] <noudle> sec [22:25:06 CET] <noudle> cehoyos: http://ix.io/24D5 [22:25:47 CET] <cehoyos> The only av1 decoder you enabled is dav1d, so dav1d is used [22:26:02 CET] <kepstin> that's an av1 video, the rpi doesn't have a hardware decoder that iirc? so, yeah, gonna be cpu only. [22:26:24 CET] <cehoyos> There is no hardware decoder (yet) for av1, this is not rpi-specific [22:27:16 CET] <noudle> only for h.264 or what it was iirc [22:27:18 CET] <noudle> right? [22:27:21 CET] <kepstin> (and with ffmpeg/ffplay, hardware decoders aren't used unless you manually specify them, either with -hwaccel or by decoder name depending on the type) [22:27:26 CET] <cehoyos> noudle: Did you compile dav1d or was there a package? [22:27:36 CET] <noudle> cehoyos: there was a package [22:28:04 CET] <noudle> kepstin: so just passing -hwaccel and having the input in the right format should get me on the way? [22:28:34 CET] <cehoyos> There is also an asp omx decoder [22:29:03 CET] <cehoyos> Sorry, no [22:29:18 CET] <cehoyos> There is an omx h264 and an omx mpeg4asp encoder [22:30:21 CET] <cehoyos> This cannot be heavily tested code: The mpeg4 encoder is implemented but cannot be called... [22:31:09 CET] <cehoyos> noudle: Please test the h264 encoder: ffmpeg -f lavfi -i testsrc2 -t 10 -vcodec h264_omx out.mp4 [22:31:38 CET] <kepstin> huh, does ffmpeg not have any way to use the hw decoder on the rpi? [22:31:59 CET] <cehoyos> Openmax is encoding-only [22:32:01 CET] <cehoyos> in FFmpeg [22:32:26 CET] <noudle> encoding only? thats bad for me.. [22:32:38 CET] <cehoyos> Can you test the encoder? [22:32:40 CET] <noudle> so i really need omxplayer to playback [22:32:43 CET] <noudle> ye sec [22:33:57 CET] <noudle> what should i pass for testsrc2 ? [22:34:02 CET] <noudle> passing my video fails [22:34:25 CET] <kepstin> "testsrc2" is a literal string [22:34:29 CET] <noudle> ah okay [22:35:55 CET] <noudle> it fails with "/opt/vc/lib/libbcm_host.so not found" even tho the file is there [22:35:56 CET] <noudle> hu [22:36:51 CET] <noudle> cehoyos: ^ [22:40:26 CET] <noudle> strange [22:40:36 CET] <noudle> the file is definitely ther [22:40:37 CET] <noudle> e [22:46:37 CET] <fling> cehoyos: which container should I use? [22:47:01 CET] <cehoyos> Not sure there is one, matroska and nut are supposed to be general purpose containers [22:47:13 CET] <cehoyos> I activated the omx mpeg4-asp encoder [22:47:53 CET] <fling> [mp4 @ 0x5602a4c3a420] Could not find tag for codec none in stream #3, codec not currently supported in container [22:47:56 CET] <fling> it works with mkv [22:47:58 CET] <fling> will try nut :> [22:48:09 CET] <fling> should not I specify a codec there? [22:48:40 CET] <fling> [nut @ 0x56369c474420] No codec tag defined for stream 3 [22:50:37 CET] <cehoyos> If it works with mkv, use it [22:52:49 CET] <fling> thanks [22:54:46 CET] <fling> How to use more cpu with x264? [22:57:21 CET] <fling> It is not using a lot :< [23:01:36 CET] <fling> 32 threads only utilizing like 350% cpu [23:06:33 CET] <cehoyos> It is a property of a software encoder for a "real" codec that it cannot max out all cores. [23:06:50 CET] <cehoyos> There is a patch that allows the encoder to max out all cores on your cpu [23:07:17 CET] <cehoyos> Unfortunately, it makes overall encoding slower (while using more electricity) [23:12:28 CET] <fling> I can run multiple encodings in parallel! [23:14:28 CET] <cehoyos> of course [23:14:58 CET] <cehoyos> Note that scaling to several processors always has an overhead, so if you have enough videos to encode, consider using -threads 1 for all encodes [23:16:02 CET] <fling> is not -threads always the global flag? [23:17:45 CET] <cehoyos> It can be used for decoding and encoding, but I thought you were talking about completely indepedent encodes [23:19:56 CET] <fling> yes ok [23:23:24 CET] <shibboleth> i'm attempting to build ffmpeg with intel qsv/libmfx support [23:23:53 CET] <shibboleth> /tmp/ffconf.iVINm47c/test.c:1:26: fatal error: mfx/mfxvideo.h: No such file or directory [23:24:13 CET] <shibboleth> likely caused by: [23:24:14 CET] <shibboleth> BEGIN /tmp/ffconf.iVINm47c/test.c [23:24:14 CET] <shibboleth> 1 #include <mfx/mfxvideo.h> [23:24:14 CET] <shibboleth> 2 #include <stdint.h> [23:24:16 CET] <kepstin> on linux, it's usually easier to get the vaapi interface working instead. [23:24:42 CET] <shibboleth> yeah, but isn't qsv magnitudes better in terms of acceleration? [23:25:02 CET] <kepstin> it's the same physical hardware encoder either way [23:25:18 CET] <kepstin> i think the mfx interface might provide more configuration options tho? [23:26:00 CET] <shibboleth> hmm [23:26:12 CET] <shibboleth> ok, i'll benchmark this if i get it working [23:26:24 CET] <shibboleth> anyway, 1 #include <mfx/mfxvideo.h> in /tmp/ffconf.iVINm47c/test.c [23:28:02 CET] <shibboleth> how would i finesse which location ffmpeg configure tries to oad it from? [23:28:04 CET] <shibboleth> load [23:28:14 CET] <kepstin> if you installed libmfx via intel media sdk/intel media server studio, you have to manually provide the include path for the headers and link path for the libraries (e.g. using --extra-cflags, --extra-ldflags) [23:29:38 CET] <shibboleth> yes, i'm trying to avoid doing a global install of that sdk from 2015. i've put what's needed in /usr/local/libmfx (usr/local/libmfx/lib/, usr/local/libmfx/include, usr/local/libmfx/include/mfx) [23:29:55 CET] <shibboleth> and configured the libmfx.pc accordingly [23:30:19 CET] <shibboleth> mfx/mfxvideo.h is in fact located in usr/local/libmfx/include/ [23:30:30 CET] <shibboleth> which has a subfolder and file mfx/mfxvideo.h [23:30:45 CET] <kepstin> if your libmfx.pc is in your pkg-config search path, it should just work [23:31:47 CET] <kepstin> make sure "pkg-config --cflags --libs libmfx" returns something reasonable. [23:32:07 CET] <shibboleth> -I/usr/local/libmfx/include -L/usr/local/libmfx/lib -lmfx -ldispatch_shared -lva -lva-drm -lsupc++ -lstdc++ [23:32:41 CET] <shibboleth> wouldn't -I/usr/local/libmfx/include take care the subfolder/file mfx/mfxvideo.h? [23:34:14 CET] <kepstin> I'd expect it to. please provide the complete config.log [23:38:44 CET] <shibboleth> one sec [23:42:17 CET] <shibboleth> log exceeds pastebin size limit [23:45:10 CET] <shibboleth> here the "test" part though: [23:45:36 CET] <shibboleth> https://paste.debian.net/hidden/3454f00a/ [23:48:52 CET] <cehoyos> shibboleth: Your pc file is missing -ldl [23:48:54 CET] <fling> is x265 good? [23:49:09 CET] <cehoyos> libaom is said to be "better" [23:50:19 CET] <shibboleth> hmm, the .pc has -ldl on a sep line [23:51:17 CET] <shibboleth> progress [23:51:26 CET] <shibboleth> uno momento [23:53:20 CET] <shibboleth> tada [23:53:24 CET] <shibboleth> thanks, cehoyos [23:58:25 CET] <shibboleth> o, compile errors: [23:59:03 CET] <shibboleth> https://paste.debian.net/hidden/79f47664/ [00:00:00 CET] --- Tue Dec 17 2019

1 0