Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2017

1 participants
62 discussions

ffmpeg-devel.log.20170810
by burek 11 Aug '17

11 Aug '17

[03:10:56 CEST] <liyou> hi,all [03:27:39 CEST] <cone-632> ffmpeg 03Sasi Inguva 07master:e7e1fbc49bf6: lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC. [04:21:29 CEST] <cone-632> ffmpeg 03James Almer 07master:c100330a8ff4: avformat/movenc: reindent after the previous commit [10:50:38 CEST] <ubitux> durandal_1707: http://www.ipol.im/pub/art/2017/192/ [10:50:41 CEST] <ubitux> -vf addgrain? [10:52:25 CEST] <durandal_1707> we have noise which is pretty fast [10:53:00 CEST] <durandal_1707> im afraid their algo is sloow [10:53:40 CEST] <ubitux> afaict it's depending on the input contrary to noise [10:53:59 CEST] <ubitux> also, does noise have transparency so it's "overlayable" onto an input? [10:54:46 CEST] <ubitux> not all filters are designed for real time anyway [11:13:05 CEST] <atomnuker> proposal: how about making decoder pre-skip being handled by utils.c [11:13:09 CEST] <atomnuker> cc wm4 [11:13:35 CEST] <atomnuker> so the data pointers in avframe would be offset by however many samples the pre-skip is [11:14:15 CEST] <atomnuker> and nb_samples would be reduced by the preskip as well [11:15:34 CEST] <atomnuker> thata way users wouldn't need to do anything special for audio formats [11:17:33 CEST] <wm4> it already does that by default if the side data is used [11:21:26 CEST] <atomnuker> wm4: ah, nevermind, its because opus is special [11:21:52 CEST] <atomnuker> where your initial preskip can be arbitrary [11:30:13 CEST] <wm4> we still should reduce it to 1 mechanism [11:30:19 CEST] <wm4> instead of having 2 or 3 [11:34:43 CEST] <ZeroWalker> btw is I420 actually planar? [11:35:00 CEST] <wm4> ffmpeg has no concept of I420 [11:35:39 CEST] <ZeroWalker> will see what ffmpeg translates it to [11:36:52 CEST] <ZeroWalker> ah yeah it's AV_PIX_FMT_YUV420P, forgot i actually learned that before lol [11:37:22 CEST] <ZeroWalker> so confusing when the format is called i420 from the source and then it's actually planar -_- [11:38:39 CEST] <wm4> that's not confusing at all [11:39:06 CEST] <ZeroWalker> lucky you;p [11:39:16 CEST] <wm4> I420 usually refers to what ffmpeg calls YUV420P (just that I420 is often used on contexts where the planes are sequential in memory or so) [11:39:38 CEST] <nevcairiel> not sure what the I is actually supposed to mean, if it means anything at all [11:41:07 CEST] <ZeroWalker> but wait, isn't planar basically, you have the entire picture in Y, then U then V, it's not sequential, or well i guess it depends what you mean with that [11:41:36 CEST] <ZeroWalker> yeah the 'i', we will never know what it means [11:42:00 CEST] <nevcairiel> planar means that each plane is separate, but they might as well be in continous memory [11:42:22 CEST] <jkqxz> It's perfectly valid with YUV420P for the chroma planes to be line-interleaved, say. Some definitions of I420 might ban that. [11:44:39 CEST] <ZeroWalker> so wait, how would one determine if it's line interleaved or not? [11:45:37 CEST] <jkqxz> Look at the pointers and linesizes. It doesn't matter to any software implementation, but hardware might care. [11:46:06 CEST] <ZeroWalker> yeah well as i am working on shader conversion, that's probably kinda important xd [11:49:10 CEST] <ZeroWalker> looking at the linesize it seems to be, 640,320,320 in this case. so i guess it's line interleaved, or:s? [11:49:21 CEST] <nevcairiel> its not. [11:49:34 CEST] <nevcairiel> that wouldnt really happen on software frames that avcodec outputs [11:49:40 CEST] <nevcairiel> but it is in theory possible [11:49:58 CEST] <ZeroWalker> this is an input, sorry about that [11:50:13 CEST] <ZeroWalker> so it's produced by a webcam in this case [11:50:41 CEST] <ZeroWalker> and i got the linesize by filling it out with the format [11:50:43 CEST] <J_Darnley> Stop confusing the poor bastard. Treat planes as planes in separate areas of memory. [11:51:04 CEST] <ZeroWalker> :( [11:52:37 CEST] <ZeroWalker> but that doesn't tell me that much, i mean, isn't it completely different if it's per line compared to the entire picture being split into 3 parts [11:52:58 CEST] <J_Darnley> No. [11:53:12 CEST] <J_Darnley> The data pointer points to the first byte of each plane [11:53:28 CEST] <J_Darnley> the linesize tells youhow many bytes to the next row. [11:54:02 CEST] <bencoh> you just end up with a different stride, that's all [11:54:17 CEST] <J_Darnley> You don't care where exactly the data is relative to each other. [11:54:39 CEST] <ZeroWalker> yeah well i am going to convert it in a shader, so i would need to be able to determine how it's structure myself. So the data being at different places makes all the difference [12:11:30 CEST] <cone-103> ffmpeg 03Martin Storsjö 07master:9042402ec78a: d3d11va: Check WINAPI_FAMILY instead of HAVE_LOADLIBRARY [12:40:11 CEST] <BtbN> I don't get that guys problem. The spec clearly says it has to be greater or equal. So being 1 second greater is perfectly fine and might safeguard for some broken players [12:40:42 CEST] <BtbN> Never seen him state anything that breaks, except for maybe his sense for aesthetics [12:44:16 CEST] <JEEB> lol [12:44:23 CEST] <JEEB> usual case of derp [12:44:39 CEST] <wm4> has anyone ever seen this assert trigger when building ffmpeg with mingw? https://github.com/bminor/binutils-gdb/blob/master/bfd/cofflink.c#L2341 [12:55:46 CEST] <BtbN> Trac detected an internal error: OperationalError: database is locked [12:55:47 CEST] <BtbN> hm [12:59:12 CEST] <Compn> that cant be good [13:07:13 CEST] <JEEB> that probably means that there was a transaction that required a certain area that another request was trying to poke to be locked [14:34:29 CEST] <J_Darnley> Do any of you know a good binary diff program? I want to investigate the differences between two files I'm making. [14:47:01 CEST] <RiCON> J_Darnley: https://github.com/dwbuiten/bxd ? [14:47:58 CEST] <atomnuker> J_Darnley: vimdiff [14:48:40 CEST] <atomnuker> best of all, you already have it [15:17:55 CEST] <J_Darnley> bxd isn't too bad. does exactly what I need from it. It would benefit from knowing page up/down, home, and end keys. Oh and maybe Ctrl-Z to suspend it. [16:06:37 CEST] <cone-103> ffmpeg 03Vittorio Giovara 07master:8c34a2024da7: h264: Add support for alternative transfer characterics SEI [16:06:38 CEST] <cone-103> ffmpeg 03Vittorio Giovara 07master:f3571048669b: pixfmt: Support chroma-derived and ictcp color matrices [16:29:00 CEST] <durandal_1707> http://i.imgur.com/SyoFhJb.png [17:15:49 CEST] <durandal_1707> nobody likes my demo? [17:21:15 CEST] <durandal_1707> ok, no reason to continue its developement [17:22:01 CEST] <ubitux> it's a screenshot of a textarea& [17:24:05 CEST] <cbsrobot> ffedit - an editor for filtergraph escaping [17:26:55 CEST] <durandal_1707> lol , coding gui app from sctrach for first time is demanding [17:28:36 CEST] <ubitux> alias ffedit='ffplay -f lavfi "$(zenity --entry --text=filtergraph:)"' [17:35:17 CEST] <durandal_1707> ubitux: ffplay does not allow frame accurate seeking [17:35:46 CEST] <ubitux> lavfi doesn't allow seeking [17:36:17 CEST] <durandal_1707> but one can seek to certain point [17:36:41 CEST] <ubitux> you can replace ffplay with mpv if you prefer :p [17:36:56 CEST] <ubitux> mpv has a lavfi input, no? [17:37:28 CEST] <durandal_1707> mpv is mplayer offspring [17:38:36 CEST] <durandal_1707> besides idea is not playback, but real gui [18:41:59 CEST] <thebombzen> the patch I just sent (replacing --full-help with --fullhelp) fixes a typo in the documentation [18:42:48 CEST] <thebombzen> I assume this is not controversial but if I missed some conventions I can resend [19:08:54 CEST] <atomnuker> durandal_1707: is it going to be like a non-linear editor? [19:09:42 CEST] <atomnuker> or is it just going to do basic trimming/picking a segment and applying effects on it (which change over time)? [19:09:43 CEST] <kierank> avfilter can't seek so no [19:10:34 CEST] <atomnuker> k, there are dozens of nles anyway [19:12:34 CEST] <atomnuker> (lavfi doesn't really need to handle seeking imo, its up to the user to skip and feed it frames from another time) [19:18:23 CEST] <durandal_1707> yes thats main idea, also what ubitux said providing nice 2D filtergraph view [19:20:44 CEST] <thebombzen> you mean we're going to stop saying "get an NLE" whenever someone wants to do some really complicated non-sequential splice-and-edit [20:24:38 CEST] <atomnuker> huh, an rpi 1 boots up fine with a 64 gig sd card [20:25:12 CEST] <atomnuker> an overkill considering how slow it is, might as well make it run fate twice a day [20:25:35 CEST] <atomnuker> fact: an rpi 1 consumes as much current under load as it does idling [20:33:35 CEST] <kierank> atomnuker: lol rpi1 [21:00:46 CEST] <rcombs> can I use a Pi3 as an aarch64 dev board yet [21:01:07 CEST] <rcombs> if not, what should I buy [21:01:19 CEST] <rcombs> I need to get off my ass and learn ARM [21:01:54 CEST] <BtbN> An actual arm64 android phone I guess? [21:02:20 CEST] <rcombs> something with a real OS [21:02:42 CEST] <rcombs> I mean, I once did get gcc running on android [21:02:46 CEST] <rcombs> but it was hellish [21:03:10 CEST] <rcombs> and I lost it all in an OS update (turns out those wipe the root partition) [21:03:57 CEST] <BtbN> you can setup a debian chroot on android [21:04:10 CEST] <BtbN> the root partition is usually wiped on reboot [21:04:15 CEST] <BtbN> as it's only a tmpfs [21:05:11 CEST] <BtbN> I might have to RMA my Ryzen... [21:05:34 CEST] <BtbN> It's affected by the "crash while compiling gcc or mesa" [21:08:04 CEST] <ubitux> rcombs: no you can't, unless you don't want PMU counters, wifi, or anything gpu related [21:08:10 CEST] <ubitux> odroid is still okish [21:08:22 CEST] <atomnuker> rcombs: I have an rpi3 running archlinux arm in 64 bit mode [21:08:32 CEST] <BtbN> where did you get the firmware? [21:08:35 CEST] <ubitux> atomnuker: with perf counters? :) [21:08:55 CEST] <rcombs> that reminds me that I really need to learn to use linux's perf system [21:08:56 CEST] <ubitux> rcombs: i'm currently waiting for the nanopi neo 2, for which i have some relatively high expectation [21:09:00 CEST] <rcombs> I'm spoiled by Instruments on macOS [21:09:05 CEST] <atomnuker> with absolutely nothing needing firmware, so only a CPU and an ethernet port, that's it [21:09:07 CEST] <ubitux> (it might be available already depending on your country) [21:09:12 CEST] <atomnuker> no wifi, bluetooth or even temperature sensor [21:09:28 CEST] <rcombs> is there anything like that for perf [21:09:31 CEST] <atomnuker> usb was unstable too I think when I tried it [21:09:40 CEST] <rcombs> (Instruments is a GUI for dtruss, basically) [21:10:32 CEST] <atomnuker> I can't imagine writing simd without the conveniences of x86_64 has [21:10:48 CEST] <atomnuker> s/has// [21:11:17 CEST] <J_Darnley> An operating system that works is now a convenience? [21:11:44 CEST] <atomnuker> sure you have more registers than you know what to do with but the very last thing you do when writing simd is using more regs than you can skimp with [21:12:32 CEST] <rcombs> ubitux: it is! [21:12:42 CEST] <ubitux> you sure? [21:12:50 CEST] <rcombs> yeah, it's on Amazon [21:12:57 CEST] <ubitux> url? [21:13:06 CEST] <ubitux> you checked it's the h5 cpu? [21:13:09 CEST] <rcombs> https://www.amazon.com/Allwinner-High-performance-Quad-Core-Running-UbuntuC… [21:13:16 CEST] <ubitux> sounds like it [21:13:26 CEST] <ubitux> i have to wait for end of september for my country, but well [21:13:36 CEST] <atomnuker> allwinner is junk [21:13:48 CEST] <ubitux> anyway, i can't give any guarantee, though there are a lot of mainline effort for these boards [21:13:55 CEST] <ubitux> atomnuker: mainline support is good :) [21:13:56 CEST] <J_Darnley> BtbN: Is there any Ryzen that isn't affected by that bug? I have heard that EPYC and ThreadRipper might not be [21:14:17 CEST] <BtbN> From the looks of it, only the very first few production runs are affected [21:14:18 CEST] <ubitux> atomnuker: basically, only sunxi boards give me mainline support [21:14:28 CEST] <BtbN> so just getting a replacement that was manufactured later fixes it [21:14:29 CEST] <ubitux> which is a shame given the shady company, but the community does a good work [21:14:50 CEST] <J_Darnley> Ah that's good no know. The longer I delay in buying one myself the better my chances. [21:14:54 CEST] <ubitux> damnit, that nanopi form factor is cute [21:14:55 CEST] <atomnuker> I've had nothing but bad experiences with allwinner, though that was 4 years ago now [21:15:02 CEST] <rcombs> so, what, ODROID-C2 if I want something that performs well for testing? [21:15:05 CEST] <atomnuker> they were also very hardcore android-centric [21:15:15 CEST] <BtbN> buying one right now is pretty much safe [21:15:25 CEST] <BtbN> week 25 of 2017 is confirmed fine [21:15:38 CEST] <BtbN> I have no idea what week mine is, as I'd have to disassemble the PC to check [21:15:40 CEST] <ubitux> any news on mainline for the odroid? [21:15:58 CEST] <atomnuker> ubitux: yeah, armbian works [21:16:10 CEST] <ubitux> patched kernel? [21:16:17 CEST] <atomnuker> nope, though its ubuntu based junk and not debian [21:16:25 CEST] <ubitux> 4.12? [21:16:27 CEST] <J_Darnley> Even better. I'm still delaying because I am cheap [21:16:28 CEST] <atomnuker> (why did these idiots call it armbian then) [21:16:30 CEST] <atomnuker> yes [21:16:30 CEST] <BtbN> The problem is, to RMA it, I'd have to send it back to AMD [21:16:42 CEST] <BtbN> And they don't give me an intermediate replacement [21:16:44 CEST] <ubitux> 4.12 doesn't have mmc support iirc [21:16:46 CEST] <BtbN> and it takes 4-6 weeks [21:16:52 CEST] <ubitux> sdcard* support [21:17:17 CEST] <atomnuker> ubitux: I guess, I only ran it from the 1 emmc I had [21:17:40 CEST] <ubitux> how are you booting the first time? [21:17:46 CEST] <rcombs> is there any particular advantage of the NanoPi over the Odroid [21:17:50 CEST] <rcombs> other than it being cheap and tiny [21:18:23 CEST] <ubitux> i'd say the nanopi is faster, but you need to check [21:18:31 CEST] <ubitux> again, haven't bought it yet [21:18:41 CEST] <atomnuker> ubitux: normally? I tried that 2 months ago and it worked fine until the polyfuse blew, I thought it broke and ordered another c2 [21:18:49 CEST] <ubitux> :D [21:20:16 CEST] <rcombs> they're both A53s [21:20:30 CEST] <BtbN> I might just buy a 100¬ R3 quad core for the mean time and try to sell it off later :( [21:21:14 CEST] <ubitux> rcombs: ah, yeah well, go for odroid [21:21:19 CEST] <rcombs> Odroid at 2GHz, NanoPi at& apparently 1.2GHz? [21:21:47 CEST] <rcombs> presumably for thermal reasons [21:21:58 CEST] <rcombs> I had trouble finding a clock figure for the NanoPi [21:22:31 CEST] <ubitux> nanopi is recent [21:22:43 CEST] <rcombs> well Odroid had it in their product description [21:22:45 CEST] <ubitux> you'll have to dig your way to get it work [21:23:09 CEST] <rcombs> alright, going with the Odroid; wish me luck [21:23:19 CEST] <jamrial> BtbN: that crash can't be fixed with microcode update? [21:45:49 CEST] <iive> BtbN: are you in europe? [21:46:02 CEST] <BtbN> yes [21:46:32 CEST] <iive> i think that the the one you bought the part takes all the troubles [21:46:41 CEST] <iive> i mean, the shop [21:47:19 CEST] <BtbN> I already asked the shop. They hadn't heard from the issue at all so far. And most news articles about it tell you to contact AMD directly [21:47:38 CEST] <iive> by law. they MUST do one of the following: 1. repair in 1 month; 2. replace 3. return your money. [21:48:01 CEST] <BtbN> Yeah, but even then, I'd be one month without CPU :D [21:48:26 CEST] <BtbN> I'm gonna call them tomorrow [21:48:29 CEST] <BtbN> and ask [21:48:36 CEST] <iive> ask them fore replacement. [21:48:39 CEST] <iive> for [21:48:54 CEST] <BtbN> I want a replacement that is known good though. And AMD can provide that. the shop can't [21:49:03 CEST] <BtbN> Even though pretty much all their R7 stock they have now should be good [21:49:31 CEST] <iive> BtbN: they should be OK with replacement, because the part you return would be replaced by AMD [21:50:06 CEST] <BtbN> Yeah, but it'd still take a while [21:51:30 CEST] <iive> BtbN: it might be good idea to read the law of your country. a lot of shops like to bulshit their customers ;) [21:51:43 CEST] <BtbN> I can return it with them just fine [21:51:53 CEST] <BtbN> it's just that I don't want to. Because I have only that one CPU [21:52:21 CEST] <iive> just ask for replacement. The shop is not taking a financial hit [21:52:37 CEST] <iive> they will sell the replacement they get from AMD as a new CPU to somebody else. [21:52:47 CEST] <BtbN> Yeah, but the way it works is I send them the old one, they check it, maybe send it to AMD for a check, and when it's confirmed, I get the replacement [21:53:13 CEST] <iive> no, you ask the shop for replacement. [21:53:17 CEST] <iive> you don't care about AMD [21:53:28 CEST] <iive> that's problem of the shop, not yours [21:55:38 CEST] <BtbN> I also can't find the small plastic holder thing the CPU belong into anymore [21:55:50 CEST] <BtbN> so without a replacement, I absolutely can't safely package it [21:56:18 CEST] <iive> you'll find it. when you don't need it anymore ;) [21:56:35 CEST] <BtbN> I might have actually thrown it away [21:57:06 CEST] <iive> that's bad [21:57:09 CEST] <wm4> <BtbN> It's affected by the "crash while compiling gcc or mesa" <- what's this about anyway? [21:57:35 CEST] <iive> yeh, i was about to ask if the problem has been ... explained [21:57:36 CEST] <BtbN> compiling gcc and mesa randomly crashes gcc on early Ryzen CPUs [21:57:47 CEST] <iive> it should have been diagnosed and fixed. [21:58:05 CEST] <BtbN> They only said they could reproduce it and are investigating it [21:58:14 CEST] <BtbN> and they said it only affects the very first few batches of ryzen CPUs [21:58:20 CEST] <iive> so, no microcode update that fixes it? [21:58:27 CEST] <BtbN> not yet at least [21:58:32 CEST] <J_Darnley> I haven't seen talk about a fix yet (but I haven't been looking) [21:58:44 CEST] <BtbN> and if it's actually bad silicon, I don't want a CPU that has that [21:59:22 CEST] <iive> can you reproduce it yourself? [21:59:26 CEST] <BtbN> yes, easily [21:59:34 CEST] <BtbN> just building gcc crashes after a few minutes [21:59:48 CEST] <BtbN> gcc just randomly segfaults [22:00:54 CEST] <BtbN> to make things more weird, it's only when compiling specific things [22:01:00 CEST] <BtbN> like, I can build webkit or libreoffice just fine. [22:01:07 CEST] <BtbN> It's specifically gcc that always crashes [22:01:09 CEST] <BtbN> and sometimes mesa [22:01:24 CEST] <BtbN> The system is also not unstable otherwise [22:01:29 CEST] <BtbN> I can run Prime95 for hours on end [22:13:40 CEST] <iive> it's probably something wierd, like the i7 mov ah/al collision [22:14:12 CEST] <BtbN> On Windows, the DX12 CPU Benchmark of Ashes of Singularity also crashes every time [22:14:18 CEST] <BtbN> So it's not something linux exclusive [22:14:29 CEST] <BtbN> and building stuff in bash-for-windows also shows the same crashes [22:15:27 CEST] <iive> it might be cache related, e.g. if there is some access pattern that loads and replaces cache entries. [22:16:42 CEST] <BtbN> Disabling OpCache does mostly mitigate it [22:16:45 CEST] <BtbN> as does disabling SMT [22:16:49 CEST] <BtbN> As does not using Core 0 [22:17:00 CEST] <BtbN> But all just "almost mitigate" it [22:17:07 CEST] <BtbN> it still happens, just not as frequently [22:17:10 CEST] <iive> opcache, is that instruction cache? [22:17:13 CEST] <J_Darnley> :) [22:17:25 CEST] <BtbN> No idea, the bios calls the option just "OpCache Enable/Disable" [22:17:29 CEST] <BtbN> with no further explanation [22:18:14 CEST] <iive> micro-op cache. [22:19:20 CEST] <BtbN> Disabling all but one core makes it happen even faster [22:19:32 CEST] <BtbN> Read some people speculating about interrupt handlers being involved [22:20:27 CEST] <JEEB> at least it seems like the ryzen segfaults do not happen with threadripper/epyc [22:20:45 CEST] <JEEB> so while it sucks, it seems to have been taken care of [22:21:27 CEST] <iive> BtbN: does it happen if you never use core0 ? [22:21:57 CEST] <BtbN> yes [22:22:06 CEST] <BtbN> but less frequently [22:22:28 CEST] <BtbN> JEEB, they supposedly also don't happen with later production batches [22:22:37 CEST] <BtbN> basically only the people who got it on day 1 are affected [22:22:53 CEST] <BtbN> So just getting any replacement will most likely be good [22:23:01 CEST] <JEEB> ouch [22:23:32 CEST] <BtbN> It's most likely just a bad batch [22:25:21 CEST] <cone-618> ffmpeg 03Marton Balint 07master:493f637d1e93: ffplay: add support for rendering yuv images with negative line size [22:25:22 CEST] <cone-618> ffmpeg 03Marton Balint 07master:7004ac5eeb8e: ffplay: add support for displaying rgb images with alpha [22:25:23 CEST] <cone-618> ffmpeg 03Marton Balint 07master:3bd2228d05a0: ffplay: add support for more SDL pixel formats when rendering video [22:30:45 CEST] <rcombs> atomnuker: btw, which x86_64 conveniences are you referring to? [22:30:57 CEST] <rcombs> the nasm macro engine and x86inc? [22:32:01 CEST] <rcombs> or other features of the nasm assembly syntax over GNU (labels, etc)? [22:37:28 CEST] <atomnuker> rcombs: being able to add a multiple of a register plus a constant as an offset to memory for free [22:37:42 CEST] <rcombs> 0.o ARM doesn't have that? [22:37:53 CEST] <rcombs> I guess it'd take up too much space in the instruction encoding [22:38:25 CEST] <rcombs> as much as people hate x86's variable-length encoding& I suppose it's there for a reason [22:39:57 CEST] <iive> yeh [22:40:01 CEST] <JEEB> ugh, https://github.com/mozilla/rr/issues/2034#issuecomment-304445368 [22:40:16 CEST] <JEEB> seems like Ryzen has some other issues?`unless these are also limited to first gen [22:43:40 CEST] <cone-618> ffmpeg 03Marton Balint 07master:498c90c70844: avfilter/vf_overlay: fix alpha blending for planar formats with a transparent background [22:45:13 CEST] <BtbN> I don't even understand what that stuff is about [22:46:56 CEST] <atomnuker> hard to replicate, one in a thousand runs bugs [22:47:24 CEST] <JEEB> I think they did deduce the bug to an easily replicate'able case [22:47:38 CEST] <BtbN> Wonder if it's related [22:47:46 CEST] <BtbN> should try on a known-good CPU [23:55:38 CEST] Action: kepstin has one of the affected ryzen chips, and something in the code generation from gcc 6 makes the segfaults happen a lot less often than with older gcc versions, it seems [23:55:52 CEST] <kepstin> kinda weird, really. [23:56:46 CEST] <Compn> or someone fixed gcc6... [23:56:49 CEST] <Compn> more likely [23:57:02 CEST] <Compn> a workaround for a buggy proc [00:00:00 CEST] --- Fri Aug 11 2017

1 0

ffmpeg.log.20170810
by burek 11 Aug '17

11 Aug '17

[00:28:14 CEST] <durandal_1707> ultrav1olet: what version? [00:30:17 CEST] <argoneus> hello [00:30:36 CEST] <ultrav1olet> durandal_1707: I copy-pasted -ss 00:XX:XX - obviously the result became shorter. Sorry, I'm an idiot ;-) [00:30:56 CEST] <argoneus> I have a .mkv file with english subtitles and I'm using ffmpeg -i file.mkv -filter_complex "[0:v][0:s]overlay[v]" -map "[v]" -map 0:a:1 output.mp4 [00:31:09 CEST] <argoneus> but for some reason the resulting mp4 is missing the hardcoded subtitles? [00:33:26 CEST] <dl2s4> are you sure they are hardcoded? i guess hardcoded subtitles does not disappear just so [00:33:35 CEST] <argoneus> well [00:33:42 CEST] <argoneus> when I open the .mkv in my video player I can choose them [00:33:54 CEST] <argoneus> but when I open the mp4 there's no subtitles anymore nor are there any in the video [00:36:09 CEST] <notdaniel> any tips on nvenc optimization? missing some of the x264 parameters :/ been setting a max bitrate and buffer size but otherwise just using -cq [00:36:09 CEST] <dl2s4> yeah they are not hardcoded then. you should be able to mux in the subtitles maybe ass, srt or whatever format into your mp4 i guess... i guess mp4 allows most subtitles format, could be wrong, not sure how to fix your problem exactly though, i mean how the ffmpeg command would look like. [00:36:25 CEST] <argoneus> hmm [00:36:40 CEST] <iive> dl2s4: it supports only its own format(s) for subtitles [00:37:29 CEST] <ultrav1olet> mp4 is quite picky in regards to subtitles formarts [00:37:31 CEST] <dl2s4> iive, ok, thanks. argoneus then you would need subtitle format which are supported for mp4 [00:37:47 CEST] <ultrav1olet> you cannot just copy e.g. srt subs to it as far as I remember [00:39:12 CEST] <argoneus> it doesn't work with .mkv either [00:40:55 CEST] <iive> mkv should take srt, ass and vobsub [00:42:19 CEST] <argoneus> it's dvd subtitles [00:42:30 CEST] <argoneus> not sure if that changes anything [00:44:22 CEST] <iive> vobsub are dvd subtitles, and they are bitmap based ones [00:44:35 CEST] <iive> so no easy conversion to text based ones, like srt/ass [00:45:50 CEST] <argoneus> I just need to take a mkv file [00:46:06 CEST] <argoneus> and produce a mp4 or similar with the subtitles already in it [00:46:11 CEST] <argoneus> because where I'm playing these you can't choose subs [00:46:13 CEST] <argoneus> is there no easy way to do this? [00:57:23 CEST] <relaxed> you can hard sub them, but it requires encoding [01:12:08 CEST] <bhuey> Hi, I'd like some help with confguration files [01:12:45 CEST] <bhuey> I got a .swf URL working with a combination of ffmpeg and ffserver configurations but I really don't understand what's going on there [01:12:58 CEST] <bhuey> I'd like to eventually get it to work with .mpg format [01:13:08 CEST] <bhuey> and abandon .swf [01:13:26 CEST] <bhuey> this a Raspberry Pi 3 btw [01:13:32 CEST] <bhuey> it's got omx acceleration [04:03:06 CEST] <LABcrab> Hello room. I have a finnicky .AVI file. It's almost 5 GB and it will only play well in WMP. I made it using Virtual VCR. What should I do to make this a more convenient file? ffmpeg and related tools misrender the file. [04:04:11 CEST] <dystopia_> misrender how? [04:04:30 CEST] <dystopia_> x264 is probably the best codec to use atm [04:04:48 CEST] <LABcrab> It will spit out a random frame from time to time. WMP doesn't do that. [04:05:49 CEST] <dystopia_> ffmpeg -i in.avi -c:v libx264 -c:a copy out.mkv [04:06:11 CEST] <dystopia_> or add in -t 60 to test a small sample like [04:06:19 CEST] <dystopia_> ffmpeg -t 60 -i in.avi -c:v libx264 -c:a copy out.mkv [04:06:34 CEST] <LABcrab> Yes, but won't this still give me a problem? [04:07:10 CEST] <dystopia_> test it [04:07:12 CEST] <dystopia_> then report back [04:07:21 CEST] <dystopia_> also a pastebin of your media info [04:07:28 CEST] <dystopia_> and a pastebin of your ffmpeg log [04:07:33 CEST] <dystopia_> would help diagnose issues [04:08:34 CEST] <LABcrab> Still doing it. :-( [04:13:13 CEST] <LABcrab> https://pastebin.com/MrmD8iER [04:17:23 CEST] <LABcrab> The audio portion (PCM) works just fine. It's the video (RAW) that is giving me a problem. [04:30:11 CEST] <LABcrab> Can anyone help me with the raw file, please? [05:14:44 CEST] <dystopia_> sorry i was afk LABcrab [05:14:54 CEST] <dystopia_> it's 4:2:2 [05:15:01 CEST] <dystopia_> you should probably make it 4:2:0 [05:15:14 CEST] <LABcrab> How can I do this? [05:15:35 CEST] <LABcrab> I've extracted all the frames as BMP. [05:16:41 CEST] <dystopia_> add -pix_fmt yuv420p [05:17:05 CEST] <dystopia_> ffmpeg -t 30 -i in.avi -c:v libx264 -pix_fmt yuv420p -c:a copy out.mkv [05:18:09 CEST] <LABcrab> Should I change something in my Virtual VCR settings? [05:18:27 CEST] <dystopia_> i don't know [05:18:39 CEST] <dystopia_> it's up to you what your capturing and how you want to do it [05:59:31 CEST] <LABcrab> I redid the capturing and almost all errors are gone. No more indexing and so forth. I still need to fix a small part at the end of the music video, but it shouldn't be a big deal. [06:40:20 CEST] <HoPollo> Hello there, can someone help me about ndi pls ? [11:17:14 CEST] <ultrav1olet> I'm trying to mux my video with UTF-8 subs and ffmpeg doesn't like that [11:17:50 CEST] <ultrav1olet> Unable to recode subtitle event "Meet my fiancý," from UTF-8 to UTF-8 [11:17:52 CEST] <ultrav1olet> Error while decoding stream #1:0: Invalid or incomplete multibyte or wide character [11:18:26 CEST] <ultrav1olet> this doesn't work: "-sub_charenc UTF-8 -i subs.srt" [11:18:41 CEST] <ultrav1olet> the subtitles file is a valid UTF-8 file [11:18:44 CEST] <BtbN> that does not look like they are in UTF-8. The error means it encountered a character that's not UTF-8 [11:19:19 CEST] <ultrav1olet> the file is indeed UTF-8 :( [11:19:29 CEST] <ultrav1olet> "Meet my fiancée" [11:19:51 CEST] <ultrav1olet> 7-bit ascii -> Meet my fianc.e [11:20:22 CEST] <ultrav1olet> ooops, 8859-1 "Meet my fiancée" also works [11:20:26 CEST] <ultrav1olet> strange [11:21:36 CEST] <ultrav1olet> BtbN: thanks, ISO 8859-1 works :-) [13:35:08 CEST] <flok420> I get "int avcodec_copy_context(AVCodecContext*, const AVCodecContext*) is deprecated" what is the alternative? the examples in google show something that uses a codec member of a structure but apparently that codec-member is deprecated as well? [13:37:16 CEST] <JEEB> you create your own avcodec context and if you want to initialize it from the codec parameters of a stream you use avcodec_parameters_to_context [13:37:26 CEST] <JEEB> for the input that is [13:37:43 CEST] <JEEB> for output you should be creating your own lavc context in any case [13:43:33 CEST] <flok420> so, AVCodecContext *codec_ctx = avcodec_alloc_context3(codec); avcodec_parameters_to_context(codec_ctx, format_ctx->streams[video_stream_index]->codecpar); ? (I'm trying to adapt an example I found on stackoverflow to reflect the deprecation changes: https://stackoverflow.com/questions/10715170/receiving-rtsp-stream-using-ff… ) [13:46:15 CEST] <flok420> oh, no, something fails now: [swscaler @ 0xf3b9a0] bad src image pointers [13:51:51 CEST] <JEEB> flok420: I recommend just looking at the examples under docs/examples :P [13:51:57 CEST] <JEEB> those take you through demuxing [13:52:07 CEST] <JEEB> and to be honest "receiving RTSP" is nothing special [13:52:52 CEST] <JEEB> the only thing you have to keep in mind that you want to look at an example that uses the avcodec_send_packet | avcodec_receive_frame [13:52:58 CEST] <JEEB> new decoding APIs [13:53:09 CEST] <JEEB> (encoding side has the same thing, where the API consists of two end points) [13:53:16 CEST] <JEEB> feed with one, receive from another [13:53:28 CEST] <JEEB> and both can tell you to try again after poking the other [13:56:54 CEST] <flok420> JEEB: ok, I will. thank you for your time! [14:38:46 CEST] <flok420> 1 warning left! \o/ [16:02:52 CEST] <T-K1> hi i'm trying to have ffmpeg read from an existing stream but it's complaining about the port, am I doing something wrong? ffmpeg -i udp://127.0.0.1:41234 thestream.mp4 [16:03:44 CEST] <T-K1> [udp @ 0x3131800] bind failed: Address already in use [16:34:14 CEST] <dystopia_> hello [16:34:33 CEST] <dystopia_> using concat to join 2 .m2ts files, but my output no longer has audio [16:34:35 CEST] <dystopia_> https://pastebin.com/raw/QEiwYH9L [16:34:52 CEST] <dystopia_> anyone know why ? it looks like it's catting the audio in the log [16:40:50 CEST] <alexpigment> dystopia: what if you just do a stream copy on one into a new m2ts container? [16:41:02 CEST] <alexpigment> in my experience, the ts muxer in ffmpeg sucks, and i've gotten the same result many time [16:41:04 CEST] <alexpigment> *times [16:41:13 CEST] <alexpigment> completely unrelated to concat in my experience [16:42:32 CEST] <dystopia_> how would i do that alexpigment? [16:42:32 CEST] <atomnuker> ts sucks period, you can't make it not suck [16:42:42 CEST] <dystopia_> this is my first time working with m2ts [16:43:17 CEST] <alexpigment> dystopia: just do ffmpeg -i [input] -c copy -f mpegts [output.m2ts] [16:43:29 CEST] <alexpigment> atomnuker: i disagree with this whole-heartedly, but to each his own ;) [16:43:58 CEST] <alexpigment> i mean, sure, it may not be as robust as MKV, but it's supported natively by more systems, both in the user and commercial world [16:44:10 CEST] <alexpigment> and with a good muxer like Tsmuxer, everything works fine [16:44:15 CEST] <dystopia_> so "ffmpeg -i 1.m2ts -1 2.m2ts -c copy -f mpegts out.m2ts" ? [16:45:17 CEST] <atomnuker> alexpigment: its not robust, its very wasteful and it doesn't support new technologies [16:45:18 CEST] <alexpigment> yeah [16:45:24 CEST] <dystopia_> it's running now, will see how it ends up :) [16:45:36 CEST] <alexpigment> dystopia: sorry, no [16:45:39 CEST] <alexpigment> i meant just one video [16:45:41 CEST] <dystopia_> when i get the files joined atomnuker it will be going to x264 :) [16:45:52 CEST] <dystopia_> then how do i add the second video alexpigment? [16:46:00 CEST] <dystopia_> i already have 2x 1 video :p [16:46:13 CEST] <alexpigment> this is not a 'fix'; this is verifying that the problem just exists in general, regardless of concat [16:46:38 CEST] <alexpigment> if you get audio when just doing a stream copy for one file, then you can ignore the concat part of the issue [16:46:54 CEST] <alexpigment> i said that backwards, but hopefully you get my point ;) [16:48:02 CEST] <alexpigment> atomnuker: i get that it's not the newest technology. it was created a very long time ago and has been slow to update. but it's a professional standard and works very well on more systems than MKV does [16:48:18 CEST] <alexpigment> like, for instance, a fresh install of Windows 7 [16:49:28 CEST] <alexpigment> MKV only works if you install a bunch of crap. the average person will install VLC, which is a horrible piece of shit, and probably end up watching improperly deinterlaced content (480i and 1080i are common in ts files) [16:50:18 CEST] <dystopia_> no audio doing that alexpigment [16:50:25 CEST] <alexpigment> that's what i figured [16:50:26 CEST] <dystopia_> but again it looks like it's copying the audio [16:50:30 CEST] <alexpigment> ok, so ffmpeg is not your tool :) [16:50:36 CEST] <alexpigment> is it PCM audio, by chance? [16:50:46 CEST] <dystopia_> yeah 24bit [16:50:51 CEST] <alexpigment> yep [16:51:17 CEST] <dystopia_> i can encode in segments and then cat afterwards [16:51:22 CEST] <dystopia_> but thats meh [16:51:29 CEST] <dystopia_> would like to just set it going and leave it [16:51:38 CEST] <alexpigment> that's a long-standing issue that I would someone would fix, but there are too many people out there who naively think that TS is a format not worth working on, rather than, you know, a huge international standard ;) [16:51:40 CEST] <furq> no audio in what [16:51:48 CEST] <furq> in what player [16:51:54 CEST] <dystopia_> [15:34:35] <dystopia_> using concat to join 2 .m2ts files, but my output no longer has audio [16:51:54 CEST] <dystopia_> [15:34:36] <dystopia_> https://pastebin.com/raw/QEiwYH9L [16:51:59 CEST] <dystopia_> no audio in the file furq [16:52:03 CEST] <alexpigment> furq: it's a problem with streams not getting copied into TS files in general [16:52:12 CEST] <dystopia_> looking in media info, and playing in mpc [16:52:15 CEST] <dystopia_> no audio is present [16:53:14 CEST] <alexpigment> dystopia_ do you *need* ffmpeg for this? I know tsmuxer should be able to do it [16:53:29 CEST] <furq> if you're reencoding anyway then don't mux to ts [16:53:39 CEST] <furq> you might as well just use the concat filter if you're reencoding [16:53:58 CEST] <dystopia_> so go to which container then? [16:54:06 CEST] <furq> probably mkv [16:54:08 CEST] <alexpigment> MKV doesn't have the same issue [16:54:15 CEST] <dystopia_> ok :) [16:54:16 CEST] <dystopia_> testing now [16:54:48 CEST] <dystopia_> [matroska @ 0000000002c22f00] No wav codec tag found for cod [16:54:48 CEST] <dystopia_> av_interleaved_write_frame(): Invalid argument [16:54:48 CEST] <dystopia_> Error writing trailer of Red.Night.mkv: Invalid argument [16:54:51 CEST] <atomnuker> alexpigment: "professional" is a bad word when talking about multimedia [16:54:53 CEST] <dystopia_> yeah it didn't like that [16:54:59 CEST] <atomnuker> professional things suck [16:55:00 CEST] <dystopia_> i will give ts muxer a shot [16:55:16 CEST] <alexpigment> atomnuker: all television. all blu-ray. is that a better description? [16:55:33 CEST] <furq> try adding -c:a pcm_s24le [16:55:38 CEST] <dystopia_> ok [16:55:39 CEST] <furq> mkv should definitely support 24-bit pcm [16:55:53 CEST] <alexpigment> furq: it might not support 24be maybe? [16:56:07 CEST] <furq> maybe [16:56:07 CEST] <alexpigment> assuming this is coming from a blu-ray disc, i'm pretty sure they use 24-bit big endian [16:56:11 CEST] <furq> yeah [16:56:13 CEST] <dystopia_> it's running furq [16:56:15 CEST] <furq> pcm_bluray is big endian [16:56:45 CEST] <furq> i doubt the endianness makes a difference, it probably just can't find the codec tag [16:56:59 CEST] <alexpigment> fair point [16:57:07 CEST] <furq> but going to pcm_s24[bl]e is lossless anyway [16:57:09 CEST] <atomnuker> alexpigment: not all television, only compressed one and uncompressed is already pretty much taking over [16:57:21 CEST] <atomnuker> for studio-studio stuff [16:57:36 CEST] <alexpigment> atomnuker: what television system do you know of that doesn't use TS? [16:57:56 CEST] <atomnuker> uncompressed internal stuff [16:58:13 CEST] <alexpigment> yeah, mxf and mov are big for intermediate stuff [16:58:17 CEST] <alexpigment> i'm talking about deliverables [16:58:29 CEST] <JEEB> raw streams over IP is what atomnuker is talking about [16:58:39 CEST] <JEEB> within the broadcast studio to feed into encoders [16:58:51 CEST] <JEEB> well, "studio" [16:58:55 CEST] <alexpigment> that's fine; i just said that all television and all blu-ray use TS [16:59:20 CEST] <alexpigment> which is really just to say that TS is a HUGE standard. it's not some weird format [16:59:53 CEST] <atomnuker> it is a weird format [16:59:57 CEST] <alexpigment> as a person who authors blu-ray discs regularly, i deal with it every single day [16:59:59 CEST] <atomnuker> what sane format uses 188 byte packets [17:00:20 CEST] <alexpigment> atomnuker: your opinions on this are really just misinformed. i'm done with this conversation [17:01:02 CEST] <JEEB> (note: he works in broadcast so he has most definitely worked with the internals of MPEG-TS :D) [17:01:07 CEST] <JEEB> or well, he *used* to work [17:02:02 CEST] <dystopia_> that worked furq [17:02:13 CEST] <dystopia_> but the output mkv is 800mb smaller than the source files [17:02:23 CEST] <dystopia_> did i just loose meta data and stuff like that? [17:02:25 CEST] <alexpigment> dystopia: you're probably missing some streams [17:02:26 CEST] <furq> no [17:02:32 CEST] <furq> that's normal for mpegts to mkv [17:02:33 CEST] <alexpigment> unless it's a REALLY long file [17:02:41 CEST] <dystopia_> ok [17:02:46 CEST] <dystopia_> tyvm :) [17:02:53 CEST] <furq> video:16784092kB audio:1292961kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 10.315392% [17:02:59 CEST] <alexpigment> ah, nm then [17:03:05 CEST] <furq> note the muxing overhead [17:03:07 CEST] <alexpigment> lots of null packets i suppose [17:20:58 CEST] <El_Porro> hello [17:24:57 CEST] <El_Porro> is there any way to redirect output stream to an audio-video player like can do RTMPdump or other streaming tools ? [17:32:23 CEST] <El_Porro> is there any link i can follow ? [17:42:53 CEST] <porro> is there any way to redirect an output ffmpeg stream to an audio-video player ? [17:48:06 CEST] <markmedes2> Friends, I'm trying to set the number of threads on ffmpeg, but it's not working. Do you know why? [17:48:36 CEST] <alexpigment> markmedes2 - are you using the libx264 encoder? [17:48:43 CEST] <markmedes2> yes [17:48:49 CEST] <alexpigment> and i presume you're specifying -threads [#] [17:48:54 CEST] <markmedes2> yes [17:49:04 CEST] <alexpigment> no clue, then. that should work [17:49:34 CEST] <markmedes2> I want to use less cores so I can keep using the machine, but it's always using all of them [17:49:41 CEST] <alexpigment> oh [17:49:50 CEST] <alexpigment> i don't think those two things necessarily correlate [17:50:45 CEST] <alexpigment> having said that, how many threads are you specifying, how many logical cores do you have, and what CPU % is ffmpeg taking up? [17:51:34 CEST] <markmedes2> I have 4 logical cores, intel i5. I'm asking ffmpeg to use 3 or less, I've specified 1 thread, 2 and 3, but it keeps using all four [17:51:57 CEST] <markmedes2> pretty much 100% usage [17:51:58 CEST] <alexpigment> is ffmpeg taking up 25% CPU when you specify 1 thread? [17:52:08 CEST] <markmedes2> no, full 100% [17:54:06 CEST] <alexpigment> i just verified i'm getting ~14% with 1 thread on my Core i7 [17:54:11 CEST] <alexpigment> what version are you using? [17:54:52 CEST] <DHE> threading may be used in other ways than you specified. filtering, decoding, and encoding can all be threaded and each takes different args for how to specify the thread counts [17:55:08 CEST] <markmedes2> version 3.3.2 [17:55:34 CEST] <markmedes2> oh, that's new info for me [17:55:40 CEST] <alexpigment> DHE makes a good point. decoding shouldn't generally account for the rest of the 100% [17:55:50 CEST] <alexpigment> but do you have any filtering going on? [17:56:01 CEST] <markmedes2> yes, I'm scalling [17:56:04 CEST] <alexpigment> libx264 itself will generally respect the thread count [17:56:31 CEST] <markmedes2> is there a doc on how to use all those different args? [17:57:23 CEST] <alexpigment> can you check to make sure it's sitting at around 25% when you take out the scaling? [17:57:43 CEST] <markmedes2> no right, now, I'm currently encoding, should take some time [17:58:37 CEST] <alexpigment> and just to be clear, ffmpeg itself is taking up nearly 100%, right? i want to make sure you're not looking at the overall CPU usage for your system [17:58:50 CEST] <markmedes2> nope, it's ffmpeg alright [17:58:54 CEST] <alexpigment> k [17:58:59 CEST] <alexpigment> are you using lanczos scaling? [17:59:02 CEST] <alexpigment> or bilinear? [17:59:18 CEST] <markmedes2> -filter:v scale="640:trunc(ow/a/2)*2" [17:59:29 CEST] <markmedes2> I'm on freebsd if that matters... [18:00:36 CEST] <alexpigment> it very well could. that same filter on my brings my CPU usage up above 20% on average, so there is a penalty, but it's nowhere near what you're seeing [18:00:54 CEST] <alexpigment> i'm on Windows. I can't test freebsd unfortunately [18:01:01 CEST] <markmedes2> k [18:02:03 CEST] <markmedes2> well, I'll test it again without scalling when econding is done. I have to go now. Thank you for tips. [18:02:13 CEST] <thebombzen> DHE: how does one specify multiple threads for a filtergraph :O [18:03:12 CEST] <jkqxz> There are a lot of things in ffmpeg that might create threads, including external libraries like libx264. If the specific CPU use matters, you are probably better off controlling it externally by the tools your OS offers. [18:03:37 CEST] <markmedes2> k [18:03:53 CEST] <jkqxz> The internet suggests that taskset exists on freebsd. [18:04:15 CEST] <markmedes2> cool [18:04:20 CEST] <markmedes2> thank you [18:04:27 CEST] <jkqxz> So set CPU affinity to the first three CPUs and no ffmpeg thread will ever run on the fourth one. [18:05:50 CEST] <markmedes2> nice thx [18:25:44 CEST] <relaxed> the power to serve [18:54:41 CEST] <pgorley> hi, swr_convert's second parameter (in) is a decoded AVFrame's data, right? [19:17:45 CEST] <LABcrab> Hi! I'm looking to use ffmpeg to output a Theora file, as ffmpeg2theora doesn't work with RAW files for me. [19:18:33 CEST] <BtbN> Why do you want to use theora? It's... not good [19:18:48 CEST] <LABcrab> BtbN, it works well on PowerPC. [19:19:07 CEST] <BtbN> and h264 or vp9 doesnt? [19:19:19 CEST] <LABcrab> Namely, the G4 Mac. The quality is fine for me. I'm converting from a raw VHS recording in any case. [19:19:45 CEST] <LABcrab> It's for use with TenFourFox, which doesn't natively support H264. [19:20:21 CEST] <BtbN> no idea how software decode compares there [19:21:01 CEST] <LABcrab> It works wonders on 360p. [19:21:25 CEST] <thebombzen> LABcrab: if you have ffmpeg compiled with libtheora support, you can use the standard ffmpeg syntax [19:22:09 CEST] <thebombzen> ffmpeg -i input_file -c:v libtheora -b:v VIDEO_BITRATE -c:a libvorbis -q:a 5 output.ogv [19:22:32 CEST] <LABcrab> Is there such a thing as -q:v? If so, is there something around 3Mbit/s? [19:22:47 CEST] <LABcrab> 3Mbytes/s is what I meant. [19:22:52 CEST] <thebombzen> Only if the video encoder supports VBR encoding. I have no idea if libtheora does [19:23:26 CEST] <thebombzen> You might be able to get away with some -qp:v N, but I recommend just setting the bitrate to 3M if you want that [19:23:40 CEST] <thebombzen> You can use 2-pass encoding to make it better [19:23:57 CEST] <LABcrab> ffmpeg -i 1.avi -vcodec libtheora -acodec libvorbis -q:a 6 -b:v 3072k -vf "scale=640:480, crop=640:360, yadif" ~/Desktop/Movie.ogv [19:24:26 CEST] <thebombzen> You should use -c:v or -codec:v, and -c:a or -codec:a [19:24:33 CEST] <thebombzen> simply because vcodec and acodec are deprecated [19:24:44 CEST] <thebombzen> they're not wrong, but good habits are to use new syntax [19:24:51 CEST] <LABcrab> Yeah. Shorter, too. [19:24:55 CEST] <thebombzen> also, ffmpeg supports -b:v 3M [19:25:09 CEST] <LABcrab> How would I add two-pass? [19:25:10 CEST] <thebombzen> Also, if you're going to deinterlace it, you should do that first [19:25:26 CEST] <LABcrab> Thus yadif, scale, crop. [19:25:33 CEST] <BtbN> you deinterlace last. [19:25:36 CEST] <BtbN> after scaling [19:25:37 CEST] <thebombzen> really what [19:25:44 CEST] <thebombzen> but doesn't ffmpeg smudge the scanlines together [19:26:03 CEST] <BtbN> iirc scale is interlacing aware. But you still do it first, for better quality [19:26:17 CEST] <BtbN> I meant in that commandline, not how to to it properly [19:26:21 CEST] <thebombzen> OH [19:26:24 CEST] <thebombzen> okay I was really confused [19:26:32 CEST] <BtbN> It should work though [19:26:38 CEST] <thebombzen> yea LABcrab we mean Yes, you should yadif, scale, crop [19:26:40 CEST] <BtbN> but the other way around is better [19:27:23 CEST] <thebombzen> LABcrab: Also, consider using zscale instead of scale if your FFmpeg has zimg support compiled in [19:27:34 CEST] <thebombzen> otherwise just use scale [19:27:44 CEST] <LABcrab> It's the ffmpeg in OS X on Intel. [19:27:56 CEST] <BtbN> OSX has ffmpeg? [19:27:59 CEST] <BtbN> like, on its own [19:28:09 CEST] <thebombzen> the easiest way to check is to try using -vf zscale and if it complains that it can't find the filter, then go back to scale [19:28:20 CEST] <thebombzen> ffmpeg -f lavfi -i testsrc -vf zscale -f null - [19:28:23 CEST] <thebombzen> what does this say? [19:29:02 CEST] <thebombzen> either way, to answer your earlier question on how to do 2-pass, you should try this: [19:29:27 CEST] <LABcrab> It seems like a lot of work to convert an AVI from a VHS. [19:29:42 CEST] <thebombzen> Not quite, we just don't know what you have available to you [19:30:19 CEST] <LABcrab> I added ffmpeg. :-) [19:30:36 CEST] <LABcrab> I installed it from the binaries online. Same with ffmpeg2theora. [19:31:35 CEST] <thebombzen> for two-pass, do this: ffmpeg -i input -vf yadif,scale=640:480,crop=640:360 -c:v libtheora -b:v 3072k -an -pass 1 -f null - [19:31:37 CEST] <thebombzen> that's the first pass [19:32:13 CEST] <thebombzen> then: ffmpeg -i input -vf yadif,scale=640:480,crop=640:360 -c:v libtheora -b:v 3072k -c:a libvorbis -q:a 5 -pass 2 output.ogv [19:45:06 CEST] <LABcrab> [libtheora @ 0x7f8a53010200] theora_encode_YUVin failed (encoder is not ready or is finished) [-10] [19:45:06 CEST] <LABcrab> Video encoding failed [19:45:06 CEST] <LABcrab> [libvorbis @ 0x7f8a53011400] 36 frames left in the queue on closing [19:45:06 CEST] <LABcrab> Conversion failed! [19:45:15 CEST] <LABcrab> However, the video plays just fine. [19:52:19 CEST] <applepi> Hi all.. I am using node-rtsp-stream to stream an RTSP stream over a websocket (it uses ffmpeg behind the scenes.) When letting it run on my server, the size= output continues to grow and grow, it starts at about 2000KB and eventually starts causing issues around 6.5GB. [19:52:28 CEST] <thebombzen> LABcrab: what version of FFmpeg are you using? [19:52:30 CEST] <applepi> Any thoughts on what could be causing this? [19:52:32 CEST] <thebombzen> what version of libtheora? [19:53:24 CEST] <BtbN> that sounds like exactly what I'd expect to happen? [19:53:36 CEST] <BtbN> If you keep streaming video, the size just gets bigger and bigger [19:53:38 CEST] <thebombzen> applepi: size= ist he total number of bytes encoded [19:53:51 CEST] <thebombzen> it's not the bitrate [19:54:11 CEST] <thebombzen> it growing nonstop is expected behavior. if it stopped growing that would be essentially a freeze [19:54:43 CEST] <thebombzen> LABcrab: that sounds like a bug in the theora encoder or wrapper. what version are you using of FFmpeg? [19:55:37 CEST] <applepi> Ahh, hm, I haven't had time to start it again but I was concerned it was actually just growing continuously in RAM, not just keeping track of how much it's encoded over time. [19:55:57 CEST] <applepi> * well, I've started it again, but it was just a few minutes ago [20:00:07 CEST] <thebombzen> yea, ffmpeg doesn't keep track of the total amount of ram it uses in various places [20:00:32 CEST] <thebombzen> but it's only a single process, so you can figure that out elsewhere [20:01:05 CEST] <LABcrab> I have 3.3.2 [20:03:18 CEST] <Mista_D> Hi, is there any filter to mark audio encoding, identifying audio btrates when streaming adaptive audio please? [20:09:03 CEST] <thebombzen> LABcrab: do the last 36 frames of the video play just fine? just wondering. if you dont' care then yay! [20:09:13 CEST] <thebombzen> but otherwise we'll have to debug that [20:09:33 CEST] <LABcrab> I concatenate two files together anyway. The video plays just fine. I'm sure the 36 last frames are black. [20:09:51 CEST] <thebombzen> alright cool [20:09:58 CEST] <LABcrab> If you're interested, I can send you a link. It's about 95 MB, though. [20:22:12 CEST] <thebombzen> not worth it enough to me [20:23:10 CEST] <LABcrab> Okay. [20:23:45 CEST] <LABcrab> In HTML5, does the video only download when "Play" is clicked, or is it cached when my page loads? [20:23:57 CEST] <BtbN> that's entirely up to your browser [20:23:58 CEST] <LABcrab> I'm assuming the former. [20:24:08 CEST] <BtbN> Firefox and Chrome alone behave vastly different [20:36:26 CEST] <LABcrab> Thanks for the help. Have a nice day. [22:23:54 CEST] <c7j8d9> when I copy a vp9.2 webm video to a mkv container the file size reduces in half. Is this normal? [22:24:25 CEST] <JEEB> can you play it and get exact same amount of pictures out? [22:24:31 CEST] <JEEB> s/play/decode/ [22:26:24 CEST] <c7j8d9> hadn't tried that. was just curious if it was normal. it was the same with mp4 [22:28:57 CEST] <kerio> when you say "copy"... [22:29:53 CEST] <c7j8d9> -c copy [22:29:56 CEST] <c7j8d9> remuxing [22:36:36 CEST] <JEEB> c7j8d9: it's not normal for any track to go down in size significantly unless the bit rate is very very small. which is why I recommend doing something like `ffmpeg -i input -f null -` for both input and output clips [22:36:45 CEST] <JEEB> which will decode them and do nothing with the output [22:36:52 CEST] <JEEB> (throw them to "null") [22:44:26 CEST] <paveldimow> Hi, does anyone here know how timecodes (timestamps) actually work? It's not specific ffmpeg question but I don't know a better place to ask [22:45:09 CEST] <JEEB> paveldimow: you have PTS and DTS and a time base [22:45:22 CEST] <JEEB> time base is how many ticks is one thing (second) [22:45:40 CEST] <JEEB> and PTS and DTS are the presentation and decoding time stamp on that time base [22:45:41 CEST] <JEEB> that's it [22:46:06 CEST] <paveldimow> well that's it for someone who knows much more then me :) [22:46:17 CEST] <paveldimow> but let me ask you a more direct question [22:47:28 CEST] <paveldimow> what I would like to do is to have one incoming stream (let it be rtmp) that contains both audio and video that are in sync. [22:47:48 CEST] <c7j8d9> JEEB: of course when I tried remuxing again they were the same size. thanks for the help [22:48:32 CEST] <paveldimow> now, I have another incoming audio stream which for example is 5 sec late and I want to mix AND sync that audio with video coming in the first stream [22:48:51 CEST] <paveldimow> is something like this technically possible? [22:49:25 CEST] <JEEB> yes, you just have to adjust the timestamps accordingly on one or the other source's tracks [22:49:36 CEST] <JEEB> if you know the actual difference it's all possible :P [22:50:20 CEST] <paveldimow> heh ok, fair enough ;) [22:51:35 CEST] <paveldimow> thank you JEEB I will take a closer look at this since I am coming from cisco network space :) [22:51:45 CEST] <paveldimow> I will have a lot to learn [22:51:51 CEST] <paveldimow> thank you once again [22:52:50 CEST] <paveldimow> almost to forgot the main question [22:54:01 CEST] <paveldimow> beside ffmpeg are there any tools that are low level with gui which I can you to inspect mpeg2, mpeg4 and mpeg ts ? something like wireshark for mpeg [22:55:01 CEST] <JEEB> I don't think a GUI is needed if the output is good enough and fits a less buffer :) but for MPEG-TS I am using https://sourceforge.net/projects/dvbinspector/files/?source=navbar [22:55:34 CEST] <JEEB> for MPEG-4 Part 12 I utilize L-SMASH's boxdumper with the --box parameter (and output to a less buffer which I can scroll through) [22:56:12 CEST] <JEEB> for very basic inspection ffmpeg/ffprobe are already quite useful [22:57:12 CEST] <c7j8d9> mediainfo works well and looks good too [22:57:42 CEST] <JEEB> that's similar to ffprobe, as in it doesn't go on the format specifics [22:57:59 CEST] <paveldimow> thank you guys, much appreciated! [22:58:03 CEST] <JEEB> also ffprobe can output data on all demuxed packets' general data, unlike mediainfo (and output as json) [22:58:42 CEST] <JEEB> also mediainfo can tell you things that are not necessarily true more often. and then when someone asks why mediainfo shows something all I can reply is "I don't know, read the source code of mediainfo" [22:59:06 CEST] <paveldimow> any book(s) you can recommend for newbie like me? [22:59:28 CEST] <JEEB> I hear http://lurkertech.com/lg/video-systems/ is OK for a basic guide [23:00:07 CEST] <paveldimow> you reply fast like google :) [23:00:32 CEST] <JEEB> and then after you get through basics you can go for stuff like https://tech.ebu.ch/circles-of-confusion [23:01:31 CEST] <JEEB> of course each format (container, video, audio, subtitle etc) is different [23:02:23 CEST] <paveldimow> thank you! [23:03:06 CEST] <JEEB> but the basics on what YCbCr is (in general terms), and that 99%+ of all video is YCbCr goes a long way [23:03:18 CEST] <JEEB> you'd be surprised how many people think that video comes as RGB and just needs to be scaled or so ;) [23:03:22 CEST] <JEEB> (After decoding) [23:03:56 CEST] <JEEB> oh, and that limited (aka "TV") range is the de facto standard in video for YCbCr [23:06:53 CEST] <paveldimow> hmmmm that's to much info for me I will start to cry :) I never heard of YCbCr or something similar [23:07:13 CEST] <paveldimow> I am network guy, you know packets everywhere ;) [23:07:28 CEST] <JEEB> think of Y as the greyscale version of your image, and Cb is chroma (color) blue, Cr is chroma (red) [23:08:15 CEST] <paveldimow> and Y? [23:08:20 CEST] <JEEB> luminance [23:08:25 CEST] <JEEB> "greyscale version of your image" [23:08:27 CEST] <paveldimow> oh a gray scale [23:08:32 CEST] <paveldimow> grey [23:08:33 CEST] <paveldimow> :) [23:08:41 CEST] <JEEB> ugh, sorry about that [23:08:44 CEST] <JEEB> getting late :P [23:08:50 CEST] <paveldimow> np :) [23:09:17 CEST] <paveldimow> hmmmm do you know if time codes are present in mpeg4 container? [23:09:25 CEST] <paveldimow> or it's just in mpeg ts? [23:09:33 CEST] <JEEB> timecodes or timestamps? [23:09:47 CEST] <JEEB> timecodes usually mean SMPTE timecodes [23:09:59 CEST] <JEEB> timestamps are just timestamps (PTS/DTS) [23:10:21 CEST] <paveldimow> what confuses me from wikipedia [23:10:23 CEST] <paveldimow> Transport Stream had been originally designed for broadcast. Later it was adapted for usage with digital video cameras, recorders and players by adding a 4-byte timecode (TC) to standard 188-byte packets, which resulted in a 192-byte packet.[11][12] This is what is informally called M2TS stream. The Blu-ray Disc Association calls it "BDAV MPEG-2 transport stream".[11] JVC called it TOD (possibly an abbreviation for "Transport stre [23:11:33 CEST] <JEEB> non-standard stuff can call itself how it wants. I haven't checked what the 4 extra bytes in the 192 byte MPEG-TS contain :) [23:11:44 CEST] <JEEB> some sort of timestamp, but if it's SMPTE timecode or not is E_NO_IDEA [23:11:55 CEST] <paveldimow> :) [23:12:07 CEST] <paveldimow> so it's non standard thing [23:12:29 CEST] <JEEB> might be standardized in blu-ray specifications but I don't think it's in the MPEG-TS specification [23:12:45 CEST] <JEEB> as long as it doesn't contain 0x47 it's compatible ;) [23:12:55 CEST] <JEEB> (MPEG-TS packets start with 0x47) [23:14:33 CEST] <paveldimow> and I can get a packet level view with dvb inspector? [23:15:02 CEST] <JEEB> yes, MPEG-TS packet view [23:15:21 CEST] <JEEB> ffprobe actually gets you each packet contained within the container with -show_packets option [23:15:29 CEST] <JEEB> it's on a different level of abstraction :) [23:15:54 CEST] <JEEB> *each stream packet contained within the container [23:16:12 CEST] <JEEB> because you don't get each MPEG-TS packet, but then the data chunks within those packets [23:17:22 CEST] <paveldimow> hmmmm so one data chunk contains multiple packets? [23:17:44 CEST] <JEEB> MPEG-TS packets are 188 byte so you kind of have to often span multiple MPEG-TS packets :D [23:18:02 CEST] <JEEB> and of course all the metadata is passed in MPEG-TS packets as well [23:19:03 CEST] <paveldimow> understand [23:20:33 CEST] <JEEB> like usually a few times a second you get a PAT, which explains what programs (think: separate sets of streams - "TV channels") there are in the stream, each of which will then also have a PMT coming (which then tells you how many streams there are in a specific program ("channel")) [23:20:55 CEST] <paveldimow> what? [23:21:02 CEST] <paveldimow> PAT? [23:21:09 CEST] <JEEB> Program Association Table [23:21:17 CEST] <paveldimow> is that in mpeg packets too? [23:21:39 CEST] <JEEB> it's a type of MPEG-TS packet, yes [23:21:41 CEST] <JEEB> :) [23:21:49 CEST] <JEEB> I think it's the one that has ID 0x00 or so [23:22:07 CEST] <paveldimow> type? what that means that there are multiple MPEG-TS packet types? [23:22:33 CEST] <JEEB> ayup. they are all 188 byte long and start with 0x47, but the contents differ [23:22:49 CEST] <JEEB> (and some contents span multiple packets) [23:23:07 CEST] <paveldimow> wait [23:23:57 CEST] <paveldimow> you said that all are 188 bytes and start with 0x47 but why did you say that PAT starts with 0X00 then? [23:24:02 CEST] <JEEB> no [23:24:06 CEST] <JEEB> the *id* is 0x00 [23:24:16 CEST] <JEEB> it's a field in an mpeg-ts packet ;) [23:24:23 CEST] <JEEB> "pid" [23:24:27 CEST] <paveldimow> aha that makes sense! [23:24:29 CEST] <paveldimow> :) [23:27:16 CEST] <JEEB> so you start reading data, wait until you get the 0x47 start code. then you try parsing the MPEG-TS packet, and ignore them until you find one with PID 0x00. then you will know the PIDs of PMT (Program Mapping Table) packets for all the currently registered programs in the stream. then you can wait for packets with that PID :D [23:27:42 CEST] <JEEB> and it goes further like that [23:28:06 CEST] <JEEB> PMT contains the PIDs for the tracks of a program, and their types if I recall correctly [23:28:19 CEST] <paveldimow> hmmmm [23:28:40 CEST] <paveldimow> it's pretty late here but I must ask you one more stupid question [23:29:07 CEST] <paveldimow> ready steady go! [23:29:10 CEST] <paveldimow> :) [23:29:36 CEST] <paveldimow> how any decoder knows which pakets are in one "frame" [23:30:07 CEST] <paveldimow> every frame has some kind of header? [23:30:24 CEST] <paveldimow> how about timestamps? are they used for synchronization? [23:30:39 CEST] <JEEB> do you mean decoder as in parser or an actual decoder? [23:31:03 CEST] <paveldimow> actual decoder let's say player vlc for example ffplay or so [23:31:37 CEST] <JEEB> usually decoders will take in full packets only so you have a parser before hand to build them up for you [23:32:04 CEST] <paveldimow> how they know, hey here is the MPEG-TS packets that belongs to the same I frame? [23:32:31 CEST] <paveldimow> but still how parser knows? [23:33:04 CEST] <JEEB> well, in case of MPEG-TS there most likely is a field that says that the packet contains a part of a coded video/audio/subtitle packet [23:33:32 CEST] <JEEB> and then you have a parser that parses raw coded frames and usually there's some way of knowing where the coded frame ends [23:33:58 CEST] <JEEB> so the demuxer feeds the parser data and then the parser follows the standard to cut those into actual packets that you can feed into a decoder [23:34:19 CEST] <paveldimow> and how/when synchronization jumps in place? [23:34:35 CEST] <JEEB> every MPEG-TS packet I think has a 33 bit timestamp field [23:35:04 CEST] <JEEB> and then a counter so you know if you had packet loss [23:36:37 CEST] <JEEB> the timestamps in MPEG-TS were DTS if I recall correctly, so with less simple formats you have to decode the stream (or at least parse it) to start getting proper PTS. [23:37:30 CEST] <paveldimow> rocket since for me for now ;) [23:38:49 CEST] <JEEB> something like matroska or ISOBMFF (mpeg-4 container) have variable length packets (samples) [23:38:53 CEST] <JEEB> which is simpler [23:39:04 CEST] <JEEB> since you get <LENGTH><DATA> [23:39:20 CEST] <JEEB> so if it's a coded video sample you just grab the data and pass it to a decoder [23:41:41 CEST] <paveldimow> I'll take a look at matroska since I like that name :) [23:41:58 CEST] <paveldimow> I can't understand anymore without sleep [23:42:01 CEST] <paveldimow> :) [23:42:22 CEST] <paveldimow> Thank you JEEB, it was a pleasure to chat with you! [23:42:56 CEST] <paveldimow> you gave me a lot of explanations [23:44:08 CEST] <paveldimow> it's still blurry to me, but much less for sure after this chat [00:00:00 CEST] --- Fri Aug 11 2017

1 0

ffmpeg-devel.log.20170809
by burek 10 Aug '17

10 Aug '17

[01:39:23 CEST] <ZeroWalker> can someone help me understand YUV422, a bit confused as to how it's packed. From my understanding it's something like YUVY, which turns into 2 pixels? [01:45:21 CEST] <iive> kind of, [01:45:35 CEST] <iive> do you know how yuv444 works is? [01:51:05 CEST] <ZeroWalker> isn't that YUV = 1 pixel? [01:51:16 CEST] <ZeroWalker> so 24bit [02:03:38 CEST] <Mista_D> Ticket #6575 added bounty if anyone's interested [02:14:46 CEST] <J_Darnley> ZeroWalker: Yes, 444 has one luma, one Cb, and one Cr sample per pixel. [02:15:14 CEST] <J_Darnley> 422 has it's chroma scaled to half the width. [02:15:50 CEST] <ZeroWalker> which means, 4 bytes = 2 pixels right? [02:16:05 CEST] <J_Darnley> For 8-bit samples, yes [02:16:29 CEST] <ZeroWalker> so, y0 + uv and y1 +uv? (not that math, but yeah) [02:16:43 CEST] <J_Darnley> Not nessecarily [02:16:45 CEST] <ZeroWalker> the luma use the same chroma samples? [02:16:45 CEST] <ZeroWalker> oh [02:16:58 CEST] <J_Darnley> Chroma can be placed almost anywhere [02:17:08 CEST] <J_Darnley> it is tricky [02:17:31 CEST] <ZeroWalker> do you mean like, planar vs interleaved, and all the weird YUVY UVYU etc [02:18:00 CEST] <J_Darnley> the chroma could be aligned with the first luma sample, or aligned with the second luma sample, or between the two. [02:18:22 CEST] <ZeroWalker> but isn't that format specific? [02:18:30 CEST] <J_Darnley> Generally yes. [02:18:33 CEST] <ZeroWalker> thought YUV2 was, YUVY (like that in the address) [02:18:46 CEST] <ZeroWalker> meaning Luma0, Chroma, Luma2 [02:18:54 CEST] <ZeroWalker> Luma1* [02:18:55 CEST] <J_Darnley> But ffmpeg isn't going to realign everything when it reads video. [02:19:21 CEST] <ZeroWalker> yeah it's not specific to ffmpeg, i am wondering about the format as i am learning to convert it via shaders [02:19:46 CEST] <ZeroWalker> and well it's not super clear how the format works for me, hence me asking here [02:21:23 CEST] <J_Darnley> If you just want to know how a pixel format (in ffmpeg's language) is laid out in memory then you probably need to read the relevant header. [02:21:42 CEST] <J_Darnley> avutil/pixel*something*.h [02:21:48 CEST] <ZeroWalker> ah [02:22:05 CEST] <iive> ZeroWalker: sorry i went away [02:22:18 CEST] <ZeroWalker> ah no worries;d [02:22:47 CEST] <ZeroWalker> packed YUV 4:2:2, 16bpp, Y0 Cb Y1 Cr [02:22:48 CEST] <iive> yuv444 has 3 planes, where each plane represents one component, Y U V (U V are shorts for Cr Cb) [02:23:14 CEST] <iive> so you can think of Y plane like grayscale bitmap [02:23:26 CEST] <ZeroWalker> yeah that's kinda what i see it as, black/white [02:23:57 CEST] <iive> to calculate rgb. you take the samples from the same positions. [02:24:30 CEST] <iive> yuv422 has the U and V plane resized, so they have half width compared to the Y [02:25:03 CEST] <iive> so if you have to calucate rgb, you'd have to interpolate (at least) half the values. [02:25:36 CEST] <ZeroWalker> but if Y0 and Y1 basically share UV [02:25:36 CEST] <iive> or you can say, that 2 horizontal Y pixels share same UV samples [02:26:04 CEST] <ZeroWalker> yeah so, how would one interpolate it, there's nothing to interpolate is there? [02:26:49 CEST] <iive> ? [02:27:11 CEST] <iive> you do that with the next pixel, just like you would if you upscale an image [02:27:41 CEST] <ZeroWalker> so, Y1 would interpolate UV0 and UV1 ? [02:28:03 CEST] <iive> yes [02:28:12 CEST] <iive> or you can not interpolate at all [02:28:54 CEST] Action: J_Darnley shudders at the thought of nearest neighboring the chroma. [02:28:57 CEST] <ZeroWalker> oh phew, well the only scaling experience i have is point resize if you will, so no fancy stuff, but i guess even that would work here? [02:29:08 CEST] <ZeroWalker> haha, what timing to write that [02:30:48 CEST] <iive> well, to complicate matters more, it is possible a standard to define UV sample centers that are off compares to the Y samples, so you never have an exact match. [02:31:07 CEST] <iive> s/compares/compared [02:32:28 CEST] <ZeroWalker> oh, yay xd [02:33:15 CEST] <ZeroWalker> well at least i get the default structure of it. basically i could take YUY2 (YUVY) and produce 2 pixels with it. Ugly but it Would work right? [02:33:46 CEST] <iive> yes [02:34:21 CEST] <iive> most video codecs however expect planar formats, so they will want to convert. (swscale) [02:36:34 CEST] <ZeroWalker> well in my case this is for converting from YUY2 or probably other interleaved YUV to RGB for displaying. So i can probably get away from the planar part there. For encoding i use swscale [04:28:27 CEST] <jamrial> atomnuker: the af_compand compilation issue on gcc trunk is fixed [07:35:59 CEST] <ZeroWalker> well yuv to rgb with shaders was harder than expected cause of it being more pixels per package. it's simple to just turn the YUV to RGB, but YUVY to RGBRGB, not so much xd [07:51:40 CEST] <thebombzen> YUVY? is that a thing? [07:51:50 CEST] <thebombzen> isn't it usually yuyv [10:12:33 CEST] <wm4> death to packed yuv [10:12:57 CEST] <wm4> 4 byte non-subsampled packed yuv can stay [10:22:29 CEST] <cone-063> ffmpeg 03Andy 07master:448c88e1a586: avfilter/dynaudnorm: increment input outside of the FFMIN macro so it doesn't get double incremented [16:55:19 CEST] <J_Darnley> Does ffmpeg have a helper function to copy a rectangle from one AVFrame to another? [17:03:43 CEST] <JEEB> J_Darnley: av_frame_move_ref or so? [17:03:58 CEST] <JEEB> unless you actually mean a memcpy [17:04:14 CEST] <JEEB> although that's moving the buffer to another AVFrame instead of copying it [17:05:28 CEST] <J_Darnley> I do mean a memcpy, yes. [17:09:49 CEST] <wm4> av_frame_copy or so [17:18:35 CEST] <JEEB> yea, I think that [17:19:26 CEST] <nevcairiel> thats for full frames tho, not sub-rectangles, if thats what you wanted [17:20:25 CEST] <wm4> you could use the new crop function, although that's pretty roundabout [17:20:54 CEST] <J_Darnley> Thanks for the suggestions but I'll just do it myself [17:24:01 CEST] <kierank> J_Darnley: why do you need to copy rectangles? [17:24:35 CEST] <J_Darnley> To copy slices of the picture drawn in encode_video [17:25:28 CEST] <durandal_1707> vf_swaprect [17:25:56 CEST] <wm4> we're getting way too many vf_veryspecific [17:25:59 CEST] <kierank> J_Darnley: why? [17:26:11 CEST] <wm4> (it would be ok if those were functions) [17:26:16 CEST] <J_Darnley> So I can see whether I do anything correctly in the encoder [18:19:12 CEST] <BtbN> Coverity has some issues with the new vf_premultiply patches [21:11:19 CEST] <durandal_1707> wm4: what filters must be very generic? [21:20:02 CEST] <durandal_1707> would ffedit using qt be accepted in repo? [21:20:50 CEST] <ubitux> tools/ffedit.c? [21:21:07 CEST] <wm4> I don't think it's going to be .c [21:21:18 CEST] <ubitux> with qt, yeah i guess so [21:21:28 CEST] <ubitux> durandal_1707: what does it do? [21:21:37 CEST] <ubitux> construct lavfi graph with a gui? [21:21:52 CEST] <durandal_1707> similar as vsedit [21:22:13 CEST] <ubitux> i don't know vsedit [21:22:20 CEST] <durandal_1707> preview filtergraph output [21:23:17 CEST] <ubitux> how are you going to cumulate them? [21:23:39 CEST] <durandal_1707> what? [21:24:08 CEST] <ubitux> how are you going to represent multiple filters and their settings in the UI? [21:24:40 CEST] <ubitux> https://cloud.githubusercontent.com/assets/8057201/9976995/e81ac04a-5ef7-11… [21:24:43 CEST] <ubitux> something like this? [21:25:09 CEST] <ubitux> (source: github/vurtun/nuklear) [21:25:24 CEST] <durandal_1707> maybe [21:25:39 CEST] <ubitux> you'll be forced to use C for that [21:25:45 CEST] <durandal_1707> but first simple script [21:25:48 CEST] <ubitux> or a binding to ffmpeg [21:26:04 CEST] <ubitux> (because some filters have dynamic inputs so you need to have some exec) [21:26:12 CEST] <ubitux> inputs+outputs* [21:26:53 CEST] <durandal_1707> why ? i cant call c from c++? [21:27:04 CEST] <ubitux> if you make a simple py+qt script that parses ffmpeg -h filter=xxx, that may be good enough for tools/ sure [21:27:17 CEST] <ubitux> i meant use C versus scripts [21:27:44 CEST] <ubitux> like, you'll have trouble calling lavfi API with scripting languages [21:27:53 CEST] <ubitux> unless you make some cython bindings or whatever [21:28:14 CEST] <durandal_1707> i plan to call api [21:28:44 CEST] <durandal_1707> and do it in C++ [21:30:19 CEST] <durandal_1707> idea is to provide seeking in filtergraph [21:32:57 CEST] <FishPencil> What's a decent way to find a group of pixels that match a certain criteria? Right now I loop through the image and add each of the pixels that match to an array. I then loop through that array and look for p[x+1][y+1] to see if there's another in an adjacent spot. Is there a better way? [21:35:22 CEST] <durandal_1707> give more details, does it need to be all pixels with certain criteria? [21:36:07 CEST] <FishPencil> I'm looking for bright pixels and using summed RGB values over some threshold [21:37:34 CEST] <durandal_1707> i doubt there is faster way [21:38:08 CEST] <FishPencil> I guess I could also go row by row, recording the bright "group" start and end and then compare that to groups in y+/-[1-n] [21:38:41 CEST] <FishPencil> [1+n] [21:40:58 CEST] <FishPencil> I was thinking I would start at the first pixel that's bright (top left) and go x+1 and y+1 until no match is found diagonally. Then record the center x,y and remove the surround pixels in the radius so the next row doesn't look for them too [21:42:22 CEST] <FishPencil> All I care about in the end is x and y's of the center point for groups and the radius of the group [21:46:33 CEST] <atomnuker> durandal_1707: sure, I'd like for it to be part of the repo [21:47:11 CEST] <durandal_1707> even in c++ with qt? [21:47:17 CEST] <atomnuker> yep [21:47:19 CEST] <atomnuker> (having some lua scripting interface would probably make it replace anything else) [21:47:54 CEST] <atomnuker> just make sure to use qt 5 and not rely on kde stuff, its not very heavy then [22:05:06 CEST] <FishPencil> Should the 2D array of "found" pixels contain all pixels in the image, and a 1 for "found", 0 for not? something like if (p[1234][123]) for x = 1234, y = 123, so that I can do y + 1 to get the next row? [22:06:23 CEST] <FishPencil> or should it only contain those that are found, so that p[n][0] = 1234 and p[n][1] = 123 [22:09:07 CEST] <cone-035> ffmpeg 03Nicolas Sugino 07master:df884e038f5d: avcodec/aacdec: Fix PCE channel_layout verification [22:09:22 CEST] <iive> FishPencil: i think opencv might already have something that does it. [22:13:28 CEST] <FishPencil> it has a threshold feature but I don't see grouping [22:15:54 CEST] <atomnuker> FishPencil: you do know ffmpeg doesn't deal with 2d arrays any code dealing with images, right? [22:17:07 CEST] <durandal_1707> FishPencil: i did floodfill filter recently which may come handy [22:19:20 CEST] <FishPencil> is there something wrong with multidim arrays that FFmpeg doesn't like? [22:20:06 CEST] <durandal_1707> they consume memory [22:20:23 CEST] <atomnuker> FishPencil: an extra dereference per row [22:20:52 CEST] <atomnuker> memory too [22:20:53 CEST] <FishPencil> so pseudo-2d is needed? [22:21:16 CEST] <atomnuker> we use a single large buffer with dimensions stride*height [22:21:33 CEST] <atomnuker> where stride is generally width aligned to some amount of bytes for simd [22:21:52 CEST] <atomnuker> so to address arbitrary pixels you use buffer[y*stride + x] [22:23:28 CEST] <FishPencil> interesting [22:23:29 CEST] <atomnuker> (never noticed this until now but this neatly fits with how x86 does addressing) [00:00:00 CEST] --- Thu Aug 10 2017

1 0

ffmpeg.log.20170809
by burek 10 Aug '17

10 Aug '17

[00:00:04 CEST] <JEEB> it should tell you the output SAR/DAR [00:00:09 CEST] <furq> Stream #0:0: Video: wrapped_avframe, yuv420p, 720x300 [SAR 1:1 DAR 12:5], [00:00:33 CEST] <JEEB> anyways, if you just want to force a 1:1 SAR ",setsar=sar=1" at the end of the filter chain should work (not sure if the internal sar is needed) [00:00:35 CEST] <ultrav1olet> blurry as hell and matches my results [00:00:39 CEST] <furq> er [00:00:40 CEST] <furq> Stream #0:0: Video: wrapped_avframe, yuv420p, 768x320 [SAR 1:1 DAR 12:5], [00:00:48 CEST] <BtbN> It's your player then [00:00:56 CEST] <BtbN> There is absolutely no blur in there at all [00:01:23 CEST] <ultrav1olet> mpv 0.8.3/MPlayer 1.3.0 [00:01:36 CEST] <JEEB> wow, that's some old stuff [00:02:15 CEST] <BtbN> 0.26.0 here, and VLC 3.0.0 [00:02:32 CEST] <JEEB> also just make sure that whatever your checking has SAR 1:1 [00:02:37 CEST] <JEEB> you're [00:02:37 CEST] <ultrav1olet> thank you all! [00:02:45 CEST] <ultrav1olet> My mplayer setup is f*cked up [00:02:51 CEST] <ultrav1olet> trying to see what's wrong here [00:03:05 CEST] <JEEB> kind of guessed that :P [00:03:34 CEST] <ultrav1olet> mplayer has this: vo = gl:lscale=1,cscale=1 [00:03:58 CEST] <JEEB> I mean, at the point where zscale was doing stuff "wrong" I was pretty much sure that it was your stuff [00:03:58 CEST] <ultrav1olet> why it gets applied when I don't resize the video for f*ck's sake? [00:04:13 CEST] <JEEB> because zimg is pretty dang good [00:04:15 CEST] <BtbN> because it's an ancient version [00:04:22 CEST] <JEEB> also mplayer is mplayer [00:05:58 CEST] <furq> ultrav1olet: because it's stretching the video to correct the aspect ratio [00:06:11 CEST] <furq> actually nvm i forgot you fixed that now [00:06:36 CEST] <ultrav1olet> thank you all [00:06:41 CEST] <ultrav1olet> I'm closing the bug report [00:07:29 CEST] <JEEB> ultrav1olet: to be honest I was trying to get you make an angry bug report @ zimg (and then getting told off by the FFmpeg-unrelated author) [00:07:56 CEST] <JEEB> because you were so fixated on FFmpeg [00:07:57 CEST] <JEEB> lol [00:08:03 CEST] <flaxo> hi is there a way to grab random chapters from DVDs? [00:08:12 CEST] <furq> not with ffmpeg [00:08:15 CEST] <furq> tcdemux/tccat will do it [00:08:38 CEST] <flaxo> jup that was just dumped from debian... [00:08:38 CEST] <ultrav1olet> JEEB: great many thanks! [00:08:50 CEST] <flaxo> so my workflow is fucked right now [00:09:00 CEST] <furq> lol what [00:09:08 CEST] <furq> that's fucking stupid [00:09:22 CEST] <flaxo> transcode is not deemed cool anymore with the kids... it seems [00:09:26 CEST] <furq> i guess you're building transcode yourself then [00:09:38 CEST] <flaxo> yeah great [00:09:58 CEST] <furq> there's probably something else that does it, but i couldn't tell you what [00:10:02 CEST] <flaxo> like cdrecord.. and all the other stuff that got kicked out [00:10:27 CEST] <flaxo> arch seems more promising each day... [00:10:38 CEST] <furq> someone should really split tccat out into a separate package [00:10:51 CEST] <furq> tccat and tcdemux are the only useful bits of transcode [00:11:02 CEST] <flaxo> well [00:11:19 CEST] <JEEB> flaxo: what was teh reason for removal? usually it's related to lack of maintenance [00:11:21 CEST] <flaxo> thats what i was using all the time :/ [00:11:31 CEST] <flaxo> dead upstream [00:11:33 CEST] <flaxo> they tell my [00:11:34 CEST] <furq> yeah [00:11:35 CEST] <flaxo> me [00:11:48 CEST] <furq> no updates since wheezy [00:11:48 CEST] <flaxo> it was not dead it was feature-complete [00:11:50 CEST] <furq> and probably before that [00:11:54 CEST] <furq> that's a dumb reason though [00:12:08 CEST] <ultrav1olet> JEEB: speaking of preserving or omitting DAR ratio - what's the best way to encode in the future? By specifying -2 as the second dimension? [00:12:27 CEST] <ultrav1olet> I don't want my future encodes to have the wrong DAR [00:12:30 CEST] <JEEB> ultrav1olet: that sets the height automatically to the closest mod2 [00:12:34 CEST] <furq> ultrav1olet: -2 will keep the original aspect ratio [00:12:41 CEST] <flaxo> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817199 [00:12:43 CEST] <JEEB> to make sure after that that you have 1:1 SAR you then force the sar [00:12:50 CEST] <JEEB> as I noted, ",setsar=sar=1" [00:12:54 CEST] <JEEB> at the end [00:13:11 CEST] <JEEB> (esp. if you're scaling to smaller sizes the aspect ratio might not be exact with the closest mod2) [00:13:22 CEST] <JEEB> but the difference might be really small [00:13:31 CEST] <ultrav1olet> furq: I just thought that if I properly scale manually (e.g. divide each dimension by the same number) everything should work :( [00:13:33 CEST] <JEEB> and thus it might make sense set forcibly set sar to 1 [00:14:00 CEST] <ultrav1olet> looks like I was wrong [00:14:05 CEST] <BtbN> ultrav1olet, that's how it works. You just miscalculated [00:14:14 CEST] <BtbN> But using -2 is easier anyway [00:14:23 CEST] <ultrav1olet> BtbN: I will use -2 then [00:14:30 CEST] <BtbN> You can use it for either of the two [00:14:31 CEST] <ultrav1olet> sound like an easier solution [00:14:43 CEST] <ultrav1olet> less chance for mistakes [00:14:48 CEST] <BtbN> if you want a specific height, just put -2 for the width [00:14:54 CEST] <ultrav1olet> will do [00:15:21 CEST] <ultrav1olet> I guess ffmpeg's manual should mention what you've all just said [00:15:35 CEST] <JEEB> yes [00:15:43 CEST] <JEEB> ffmpeg-all.html [00:15:50 CEST] <JEEB> is the thing you want to ctrl+F through [00:15:59 CEST] <ultrav1olet> I looked at https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg [00:16:11 CEST] <furq> !filter scale [00:16:11 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#scale-1 [00:16:13 CEST] <furq> it's in there [00:16:22 CEST] <ultrav1olet> and it happily offers me to use "ffmpeg -i input.avi -vf scale=320:240 output.avi" [00:16:30 CEST] <furq> If one and only one of the values is -n with n >= 1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. [00:16:31 CEST] <ultrav1olet> yeah I see [00:17:12 CEST] <ultrav1olet> it's just "its most basic form:" has no mention that it might completely break things ;) [00:17:14 CEST] <BtbN> you want -2 because of YUV420 needing multiples of two [00:19:19 CEST] <ultrav1olet> Ideally I would love a scale option which allows me to specify a divisor, so that I was free not to specify the resulting dimensions at all, say -vf scale 3/5,3/5 or something like that [00:20:00 CEST] <furq> you can do that [00:20:07 CEST] <ultrav1olet> so for 1920x1080 source I'd get 1920*3/5,1080*3/5 - is that possible? [00:20:20 CEST] <furq> -vf scale=iw*(3/5):ih*(3/5) [00:20:32 CEST] <ultrav1olet> and it'll preserve DAR? [00:20:40 CEST] <furq> should do [00:20:52 CEST] <BtbN> that's highly uncommon though [00:20:56 CEST] <BtbN> you usually want a specific height or width [00:20:57 CEST] <furq> that's simplified because that'll end up giving you some non-mod2 sizes [00:21:04 CEST] <furq> and also yeah you normally want a target size [00:21:47 CEST] <ultrav1olet> I do understand that the resulting dimensions should be at least divisible by 2 and better yet 4 [00:21:57 CEST] <furq> 4/8/16 aren't really any better than 2 [00:22:07 CEST] <furq> iirc x264 encodes mod16 regardless [00:22:09 CEST] <ultrav1olet> cause x264 works best for 4x4 and higher [00:22:10 CEST] <BtbN> for h264, you ideally want multiples of 8. But it doesn't overly matter [00:22:23 CEST] <BtbN> it will just add padding and crop it away on playback [00:22:26 CEST] <furq> right [00:22:32 CEST] <furq> is it mod8 or mod16 [00:22:45 CEST] <JEEB> more like multiples of 16 internally since macroblocks, but the padding is so effective you shouldn't care [00:22:46 CEST] <BtbN> hm, 1080p is actually 1088p. So it might even be 16 [00:22:51 CEST] <JEEB> it is 16 [00:22:54 CEST] <JEEB> and HEVC is 64 [00:22:58 CEST] <furq> nice [00:23:00 CEST] <JEEB> coding tree unit size [00:23:26 CEST] <BtbN> as long as the padding isn't filled with randomness [00:23:38 CEST] <BtbN> if it's a permanent static color, it should compress into nothingness [00:23:52 CEST] <JEEB> the padding basically is done in a way that lets the encoder optimize the hell out of it :P [00:23:55 CEST] <JEEB> so you don't have to care [00:24:06 CEST] <JEEB> thus you actually care more about the playback devices' issues [00:24:13 CEST] <JEEB> like renderers failing with mod2 [00:24:17 CEST] <JEEB> or something like that [00:24:28 CEST] <ultrav1olet> ffmpeg -i source.mkv -vf 'scale=iw*(2/5):ih*(2/5)' -c:v utvideo result.mkv works beautifully! [00:24:48 CEST] <BtbN> if it happens to end up with multiples of two, yes [00:24:53 CEST] <BtbN> if not, it will explode [00:24:59 CEST] <ultrav1olet> source: Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default) [00:25:04 CEST] <JEEB> with 4:2:0, yes [00:25:07 CEST] <ultrav1olet> result: Stream #0:0: Video: utvideo (ULY0 / 0x30594C55), yuv420p, 768x320 [SAR 1:1 DAR 12:5], q=2-31, 200 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default [00:25:12 CEST] <furq> but yeah you'd actually want something like -vf scale=floor(iw*(3/5)/2)*2 [00:25:17 CEST] <furq> to force mod2 [00:25:24 CEST] <cq1> I presume that any reasonable encoder is more sophisticated than simply "padding with some value", and instead when it does any form of rate-distortion optimization that errors in the padded region count for nothing... [00:25:32 CEST] <JEEB> cq1: yes [00:28:11 CEST] <ultrav1olet> One problem I've always wondered but never actually tried: when encoding for the same bitrate target, what's better 1) encoding the source with lower quality or 2) slightly downscaling it (e.g. from 1080p to 720p) and using a higher quality? [00:28:37 CEST] <furq> depends on the bitrate and target device [00:28:41 CEST] <ultrav1olet> Of course when you're ready to sacrifice a wee bit of visual fidelity [00:28:53 CEST] <ultrav1olet> just what I thought [00:28:54 CEST] <furq> downscaling will make a big difference to quality/size though [00:29:11 CEST] <ultrav1olet> exactly, so the answer is not really obvious [00:29:15 CEST] <furq> right [00:29:25 CEST] <furq> as usual when it comes to video, there's no right or wrong answer [00:29:33 CEST] <kepstin> this is the sort of thing where netflix does big studies over massive video libraries to try to decide what to do :/ [00:29:39 CEST] <ultrav1olet> "trust your eyes" )) [00:30:10 CEST] <furq> and as usual when it comes to there being no right or wrong answer, there is someone who keeps asking us what the right answer is [00:30:21 CEST] <furq> and then JEEB starts swearing at them because they won't just encode a test sample like he keeps telling them [00:31:12 CEST] <ultrav1olet> are there any plans to make ffmpeg compatible with avisynth filters or that's not even theoretically possible? [00:31:12 CEST] <furq> it's been a while since we've had one of those guys tbf [00:31:20 CEST] <furq> ultrav1olet: it can already load .avs on windows [00:31:24 CEST] <furq> and you can pipe vapoursynth into it [00:31:50 CEST] <furq> if you mean incorporating avisynth filters into lavfi then that isn't directly possible [00:31:59 CEST] <furq> some have been ported though [00:32:06 CEST] <ultrav1olet> I for one dream of having MDegrain2 in ffmpeg [00:32:19 CEST] <ultrav1olet> probably the best denoiser I've seen in my entire life [00:32:20 CEST] <furq> yeah it'd be nice to have qtgmc in ffmpeg [00:32:30 CEST] <furq> but it's not that much effort to go through vs [00:32:38 CEST] <ultrav1olet> works wonder and I have to boot into windows to use it :( [00:32:46 CEST] <furq> it's probably been ported to vapoursynth [00:33:36 CEST] <ultrav1olet> my workflow is to use it in windows to encode to x264 losslessly, then I encode once again in Linux [00:33:42 CEST] <ultrav1olet> that's kinda awful [00:33:47 CEST] <furq> that's extremely awful [00:34:01 CEST] <JEEB> avisynth works under wine since 2004 or so [00:34:12 CEST] <JEEB> so when I was (ab)using university workstations it was 2009 [00:34:18 CEST] <JEEB> to encode stuff in parts [00:34:21 CEST] <ultrav1olet> I'm too stupid to use it without MeGUI :( [00:34:51 CEST] <furq> ultrav1olet: https://github.com/dubhater/vapoursynth-mvtools [00:34:52 CEST] <ultrav1olet> last time I tried MeGUI doesn't work under wine [00:35:06 CEST] <furq> vs has free multithreading as well [00:35:14 CEST] <q66> hi furq [00:35:27 CEST] <furq> hi there little buddy [00:35:44 CEST] <furq> how can i help you today [00:35:50 CEST] <q66> idk [00:35:55 CEST] <q66> i just came to idle and stick around for a while [00:36:04 CEST] <ultrav1olet> Hopefully someone with an itch will port MDegrain to ffmpeg :-) [00:36:08 CEST] <q66> just #mpv isn't enough multimedia madness [00:36:31 CEST] <furq> you will be pleased to hear that nobody talks about animes in here [00:36:40 CEST] <q66> that's nice [00:36:48 CEST] <q66> do they talk about perl [00:36:53 CEST] <furq> not that i've seen [00:36:57 CEST] <q66> that's also nice [00:37:10 CEST] <JEEB> #ffmpeg is just dumb lusers [00:37:21 CEST] <JEEB> and random people saying they will build the next major video site [00:37:22 CEST] <furq> ultrav1olet: vapoursynth is easy enough to use [00:37:23 CEST] <q66> sounds fun [00:37:28 CEST] <JEEB> or people asking how to do their porn site [00:37:33 CEST] <furq> it's easier than rebooting into windows every time you want to encode anything [00:38:21 CEST] <ultrav1olet> furq: looking at it, thanks [00:40:00 CEST] <ultrav1olet> my needs are very basic actually: https://pastebin.com/raw/dn1RicLD [00:40:15 CEST] <ultrav1olet> copied straight from mdegrain manual [00:41:25 CEST] <q66> it's pretty much the same with vapoursynth except in python [00:41:49 CEST] <ultrav1olet> looks like this will work as is with vapoursynth [00:42:04 CEST] <furq> yeah just install mvtools and that's all basically the same [00:42:23 CEST] <ultrav1olet> great, will definitely try that [00:43:59 CEST] <q66> yeah though convert are not separate funcs in vs [00:46:28 CEST] <furq> http://vpaste.net/zIKCc [00:46:29 CEST] <furq> something like that [00:46:45 CEST] <q66> yeah like that [00:47:27 CEST] <ultrav1olet> you're amazing, guys! [00:55:55 CEST] <ultrav1olet> great many thanks! [01:02:11 CEST] <iive> so, I see people complain that there is not enough talking about anime. [01:02:49 CEST] <iive> maybe somebody would be kind enough to recommend me something to watch. [01:03:20 CEST] <iive> i do prefer to be recent title and to be a complete. [01:04:25 CEST] <JEEB> shouwa genroku rakugo shinjuu [01:05:31 CEST] <iive> this is about the actors, isn't it? [01:05:39 CEST] <furq> i would like to assure you that i was not complaining [01:05:41 CEST] <JEEB> yes, the traditional comedy thing [01:06:10 CEST] <JEEB> as in, about comedians in that genre [01:06:21 CEST] <JEEB> two seasons out now, which nicely brought it to an end [01:06:31 CEST] <ultrav1olet> it even has a trailer ... in Japanese [01:06:37 CEST] <ultrav1olet> https://www.youtube.com/watch?v=rMWOuwFpF-g [01:06:59 CEST] <iive> i've seen it recommended before, I'll take a look. [01:07:08 CEST] <klaxa> i apparently have shit taste, but my favorite show last season was zero kara hajimeru mahou no sho [01:07:31 CEST] <JEEB> klaxa: it's OK, it was one of the shows I was kind of going through [01:07:40 CEST] Action: JEEB watches way too much crap [01:08:10 CEST] <klaxa> i cut back on watching crap shows [01:08:29 CEST] <klaxa> meaning i watch fewer crap shows [01:09:09 CEST] <klaxa> i was surprised by how much i liked renai boukun even though the genre and tropes have already been used to death [01:13:40 CEST] <iive> JEEB: there seem to be ova too, and it is marked as prequel, so I guess I should start with it first. [01:14:10 CEST] <JEEB> I skipped that and I don't think I lost anything [01:14:17 CEST] <JEEB> I have a feeling it's something that was done before, separately [01:14:32 CEST] <iive> ok. [01:14:45 CEST] <JEEB> because (spoiler alert) the two seasons go through pretty much the whole life of those folk [01:15:38 CEST] <iive> it's marked as prequel, not alternative version. [01:16:15 CEST] <JEEB> let's just say I ignored it and missed seemingly nothing [01:16:21 CEST] <JEEB> of course I don't know what I missed but still :P [01:16:28 CEST] <iive> :D [01:16:59 CEST] <iive> klaxa: sometimes there are show that are not highly prised, but I find a lot more meaningful, that the highly rated ones. [01:17:44 CEST] <JEEB> the thing I bought the whole set of discs for was shirobako, and you can think of that at 60eur a pop and about eight discs [01:17:56 CEST] <JEEB> one of my favourites for 2014 [01:17:58 CEST] <klaxa> >p.a. works [01:18:01 CEST] <JEEB> inorite [01:18:05 CEST] <klaxa> although i heard it was good for a change [01:18:17 CEST] <JEEB> yea, I skipped a lot of PA stuff before that [01:18:29 CEST] <klaxa> all the other p.a. works shows i dropped after a few eps (except for angel beats) [01:18:30 CEST] <JEEB> shirobako hit me as a nice thing [01:25:27 CEST] <CounterPillow> anime sucks [01:31:01 CEST] <iive> CounterPillow: i wonder, what is your most hated anime :E [01:42:01 CEST] <CounterPillow> Spongebob [01:44:22 CEST] <iive> that's not anime [01:44:58 CEST] <klaxa> in japan it is :x [01:48:48 CEST] <klaxa> okay autoconf 2.13 is too old [01:58:27 CEST] <klaxa> ah whoops, wrong buffer, lol [03:42:29 CEST] <Harzilein> hi [03:45:27 CEST] <Harzilein> i made a 'still frame video' like this: ffmpeg -ss 1209.041000 -i defiance303.mkv -an -c copy -vframes 1 defiance303.thumb.mkv # https://pastebin.com/C9eTrh6A [03:48:58 CEST] <Harzilein> and i now want to make a video with that still frame looped and the audio from the complete file: ffmpeg -i defiance303.mkv -stream_loop -1 -r 2 -i defiance303.thumb.mkv -map 0:a:0 -map 1:v:0 -c copy -fflags +genpts defiance303.mp4 # https://pastebin.com/vneMrWQn [03:52:07 CEST] <Harzilein> when i look at the output of mediainfo the video stream is only a couple of ms long, but playback seems to work fine (with mpv) ... the only problem is that when i try to seek, playback aborts with an 'end of file' message: https://pastebin.com/xTMrTFJh [09:55:06 CEST] <yong> I want to encode frames received through a network socket. These frames are sent as individual .bmp files. Currently I'm trying it like this: [09:55:09 CEST] <yong> ffmpeg -f bmp_pipe -framerate 10 -i tcp://localhost:4444 -vframes 20 -an -c:v libx264 -preset veryfast test.mp4 [09:55:42 CEST] <yong> but ffmpeg doesn't even create a test.mp4, and when the sender closes the socket (after sending 40 frames), all ffmpeg outputs is "tcp://localhost:4444: Unknown error" [09:55:49 CEST] <yong> What do I have to specify to make this work? [09:56:58 CEST] <furq> you probably want image2pipe [10:11:00 CEST] <bencc> why the releases in the branches aren't in sync? [10:11:22 CEST] <bencc> I see random 3.1.x, 3.2.x, 3.3.x releases [10:11:27 CEST] <bencc> https://github.com/FFmpeg/FFmpeg/releases [10:11:38 CEST] <bencc> I would expect all the branches to release on the same day [10:15:52 CEST] <thebombzen> furq: that almost certainly is not the issue, assuming that they're receiving bmp images [10:16:28 CEST] <thebombzen> png_pipe, jpeg_pipe, bmp_pipe etc. have all been split off from image2pipe. image2pipe still works but those are better [10:16:51 CEST] <yong> furq: Actually I'm stupid, I can't even connect to ffmpeg, it doesn't matter when I close the socket, ffmpeg just times out with "tcp://localhost:4444: Unknown error" no matter what (even if I'm not doing anything) - which is kind of weird, since it should just listen on a socket which doesn't really have a timeout? Does ffmpeg not support network input like this? [10:18:21 CEST] <yong> Or do I have to use UDP? I was going to use TCP for testing purposes so I can be sure ffmpeg at least gets data [10:20:50 CEST] <yong> Alright I guess I have to just specify it to listen, like this: [10:20:53 CEST] <yong> ffmpeg -f image2pipe -framerate 10 -i tcp://localhost:4444?listen=1 -vframes 20 test.mp4 [10:20:59 CEST] <yong> still can't connect to it though :D [10:21:38 CEST] <yong> at least it doesn't timeout anymore [10:29:46 CEST] <yong> ohhhhhhh solved it lol [10:30:11 CEST] <yong> localhost = ipv6, you have to specify tcp://127.0.0.1 for ipv4 [14:04:05 CEST] <cableguy> hey team [14:04:40 CEST] <cableguy> i converted a sample file to yuv color with this [14:04:42 CEST] <cableguy> ffmpeg -i test.mkv -c:v rawvideo -pix_fmt yuv420p test.yuv [14:04:51 CEST] <cableguy> the test.mkv source is 50mb [14:04:58 CEST] <cableguy> and the output test.yuv is 2gb size [14:05:05 CEST] <cableguy> video is 60 second long [14:05:29 CEST] <cableguy> i tried doing this to a 2h long video, i ran out of hdd space [14:05:34 CEST] <cableguy> i dont think this is right [14:05:50 CEST] <dystopia_> morning [14:06:00 CEST] <furq> what part of that doesn't seem right [14:06:18 CEST] <cableguy> why output becomes so big? [14:06:19 CEST] <c_14> the -c:v rawvideo probably [14:06:25 CEST] <furq> because it's rawvideo [14:06:25 CEST] <dystopia_> raw makes every frame an i frame [14:06:27 CEST] <dystopia_> and is massive [14:06:31 CEST] <furq> it's uncompressed [14:07:04 CEST] <furq> 60 seconds of 1080p30 yuv420p rawvideo is 5.5GB [14:07:23 CEST] <cableguy> my input is 60 seconds of 720x576 dvd vob sample [14:07:39 CEST] <dystopia_> why go to raw? [14:07:59 CEST] <dystopia_> it's mpeg2, go to whatever end format is desired [14:08:10 CEST] <furq> use ffv1 in nut if you want a lossless intermediate format [14:08:18 CEST] <furq> but you could just use -c copy [14:09:44 CEST] <cableguy> because x265 encode only from yuv dystopia_ [14:09:44 CEST] <dystopia_> i have a 1920x1080 video, that i want to encode to 4:3 to fit in 640x480 [14:09:56 CEST] <dystopia_> but i don't want to loose any of the picture [14:10:03 CEST] <dystopia_> what resolution can i scale to ? [14:10:07 CEST] <furq> cableguy: you know ffmpeg supports libx265, right [14:10:21 CEST] <furq> dystopia_: you can't [14:10:31 CEST] <furq> unless you want to fuck up the aspect ratio [14:10:33 CEST] <dystopia_> furq im happy with black bars top and bottom [14:10:34 CEST] <dystopia_> yeah [14:10:36 CEST] <furq> oh right [14:10:37 CEST] <dystopia_> i do :p [14:10:44 CEST] <dystopia_> but im not sure what res will fit [14:10:55 CEST] <cableguy> furq, do i look like someone who knows anything at all [14:11:14 CEST] <furq> 640*360 with black bars to preserve ar [14:11:17 CEST] <dystopia_> you can go to x265 from mpeg2 with ffmpeg cableguy [14:11:26 CEST] <cableguy> so how is it different [14:11:27 CEST] <dystopia_> thanks [14:11:29 CEST] <dystopia_> will test [14:11:30 CEST] <cableguy> from converting to yuv with ffmpeg [14:11:33 CEST] <furq> 640 / (16/9) [14:11:34 CEST] <cableguy> and then encoding with x265 [14:11:57 CEST] <furq> it means you don't need to store two hours of rawvideo and kill your hard disk [14:12:08 CEST] <cableguy> oh [14:12:18 CEST] <cableguy> can you write an example of command line [14:12:30 CEST] <furq> granted you don't need to do that anyway because you can pipe ffmpeg's output into x265 [14:12:44 CEST] <furq> ffmpeg -i foo.vob -c:v libx265 [options] out.mkv [14:13:08 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/H.265 [14:14:02 CEST] <furq> or ffmpeg -i foo.vob -c:v rawvideo -f yuv4mpegpipe - | x265 [options] [14:14:12 CEST] <furq> there's no real reason to do that though [14:15:02 CEST] <cableguy> how do i incorporate avs script into this [14:15:08 CEST] <cableguy> if i need to deinterlace or crop [14:15:14 CEST] <furq> you can do both of those with ffmpeg [14:15:17 CEST] <dystopia_> don't [14:15:18 CEST] <dystopia_> yeah [14:15:27 CEST] <furq> unless you're using some super fancy deinterlacing script like qtgmc [14:15:38 CEST] <cableguy> what about yadif [14:15:44 CEST] <furq> -vf yadif=1 [14:15:45 CEST] <cableguy> cuz its just some old dvd [14:16:14 CEST] <cableguy> how about running something like SelectRangeEvery() [14:16:16 CEST] <cableguy> for testing [14:16:34 CEST] <dystopia_> -vf yadif=0:0,crop=720x576:0:0 [14:16:38 CEST] <furq> i assume that's the same as -t 60 [14:16:56 CEST] <furq> ffmpeg will just load avs scripts if you're more comfortable with that [14:16:58 CEST] <furq> -i foo.avs [14:17:14 CEST] <cableguy> wait so [14:17:42 CEST] <dystopia_> crop values - crop=width_after_crop:height_after_crop:left_crop:top_crop [14:17:46 CEST] <cableguy> how do you load avs and convert mpeg2 to yuv and encode to x265 all with ffmpeg [14:17:58 CEST] <furq> you don't do the middle bit [14:18:08 CEST] <furq> ffmpeg -i foo.avs -c:v libx265 [options] out.mkv [14:18:22 CEST] <furq> assuming your avisynth.dll is in the right place [14:18:24 CEST] <cableguy> so the avs must contain the input src that is already yuv format [14:18:29 CEST] <furq> yes [14:18:39 CEST] <cableguy> so you dont save any space [14:18:46 CEST] <furq> what [14:18:56 CEST] <cableguy> in order to use avs script [14:19:05 CEST] <cableguy> you end up converting the mpeg2 to yuv burning hdd space [14:19:07 CEST] <furq> let me revise my answer: no [14:19:19 CEST] <furq> you load the d2v or whatever in your avs and have avisynth output yuv [14:19:23 CEST] <cableguy> so you could include that new uncompressed yuv in avs [14:19:39 CEST] <furq> at no point in this process does rawvideo get saved to your disk [14:20:00 CEST] <furq> honestly though if you're just cropping and running yadif, you should ditch avisynth [14:20:20 CEST] <furq> it's an unnecessary complication when ffmpeg will do both of those things identically [14:20:41 CEST] <cableguy> but how you prepare it for encoding [14:20:45 CEST] <furq> you don't [14:21:06 CEST] <cableguy> if you use megui or something it writes a avs script that sets crop values, etc its easy to follow [14:21:48 CEST] <dystopia_> ffmpeg -i in.vob -vf yadif=0:0,crop=720:576:0:0 -c:v libx265 out.mkv [14:21:57 CEST] <dystopia_> ^ this imo [14:22:15 CEST] <dystopia_> you can do -t 60 to test, will save you a lot of hasstle [14:22:22 CEST] <furq> yeah basically that [14:22:42 CEST] <furq> 13:18:08 ( furq) ffmpeg -i foo.avs -c:v libx265 [options] out.mkv [14:22:49 CEST] <furq> this will work with the avisynth script megui produces though [14:22:58 CEST] <furq> you don't need to create any intermediate files [14:23:29 CEST] <cableguy> dystopia_, so what do you use to count how many pixels you need to crop e.g. for black bars [14:24:17 CEST] <cableguy> so does including libx265 automatically solves the mpeg2 to yuv part [14:25:06 CEST] <dystopia_> cableguy i script my stuff [14:25:16 CEST] <dystopia_> basically i use ffmpeg to dump a frame of video [14:25:22 CEST] <dystopia_> then open that frame in paint [14:25:32 CEST] <dystopia_> and enable grid lines, zoom into max [14:25:43 CEST] <dystopia_> and every square on the grid = 1 pixel [14:25:50 CEST] <dystopia_> so i just count what needs to be cropped [14:25:56 CEST] <dystopia_> then set it in my script [14:27:04 CEST] <cableguy> do you also wear a fedora [14:29:58 CEST] <dystopia_> i do not [14:30:23 CEST] <dystopia_> %PATHC2%\ffmpeg -ss 58 -i 01.ts -r 1 %PATHC4%\%houtput%.bmp [14:30:23 CEST] <dystopia_> mspaint %PATHC4%\%houtput%.bmp [14:32:06 CEST] <dystopia_> https://paste.ofcode.org/3aAPytUMRDstAvFFmjGCjCd my old crop code if you want it [14:32:23 CEST] <cableguy> ffmpeg -i foo.avs -c:v libx265 [options] out.mkv [14:32:34 CEST] <cableguy> what do you include in [options] part [14:32:45 CEST] <cableguy> it doesnt recognize x265 options [14:32:58 CEST] <cableguy> e.g. --preset fast [14:34:26 CEST] <dystopia_> it should [14:34:31 CEST] <iive> cableguy: man ffmpeg-codecs "/" to search "libx265" [14:35:13 CEST] <iive> it says that therea are: -preset, -tune, -forced-idr and -x265-params [14:35:37 CEST] <cableguy> ur right [14:35:43 CEST] <cableguy> its one dash not two [14:36:18 CEST] <dystopia_> any idea why this drops tons of frames :) [14:36:23 CEST] <dystopia_> ffmpeg.exe -i "in.mp4" -sws_flags spline -s 640x360 -c:v mpeg1video -c:a mp2 -q:a 224 test.mpg [14:36:31 CEST] <dystopia_> Past duration 0.823357 too large 8754kB time=00:01:37.78 bitrate= 733.4kbits/s dup=37 drop=32 speed=12.2x [14:37:49 CEST] <dystopia_> drops 77 frames over 5mins of video [14:38:25 CEST] <relaxed> dystopia_: maybe a change in framerate [14:38:38 CEST] <dystopia_> hmm [14:39:11 CEST] <dystopia_> yes [14:45:54 CEST] <cableguy> but how do you know which x265 version ffmpeg is using [14:46:01 CEST] <cableguy> how do you know its latest [14:46:20 CEST] <cableguy> the encoding result says its x265 2.4+87 [14:46:39 CEST] <iive> it uses the one it is linking to [14:46:58 CEST] <iive> that's why it is a lib<codec>, because it is an external library [14:46:59 CEST] <cableguy> but latest is 2.5+6 [14:47:15 CEST] <iive> well... what version do you have installed on your system? [14:47:18 CEST] <cableguy> how do you change where its linking [14:47:24 CEST] <relaxed> cableguy: https://www.johnvansickle.com/ffmpeg/ [14:47:39 CEST] <iive> windows? [14:47:46 CEST] <cableguy> ye [14:47:48 CEST] <viric> Do you know if all formats start the streams at time 0? I have MTS files and I think they may start after 0 [14:47:51 CEST] <cableguy> i guess my ffmpeg is out of date [14:47:52 CEST] <viric> between 0 and 1s [14:48:21 CEST] <iive> well, then it depends what version has been linked by the one who built ffmpeg for you. [14:48:25 CEST] <cableguy> can you update ffmpeg through terminal [14:48:41 CEST] <cableguy> im just using some windows build available from public [14:49:24 CEST] <cableguy> hey maybe the shared version is what i need [14:50:30 CEST] <cableguy> no, it doesnt have any x265 exe files,although it says linking [14:59:13 CEST] <cableguy> wait so [14:59:24 CEST] <cableguy> where is ffmpeg pulling the x265 lib from on windows [14:59:36 CEST] <cableguy> is it compiled into ffmpeg.exe [14:59:40 CEST] <BtbN> wherever you told it to [14:59:59 CEST] <cableguy> but i diddnt tell it anything [15:00:04 CEST] <BtbN> You did while building it [15:00:24 CEST] <cableguy> i didnt build it [15:00:26 CEST] <cableguy> its windows [15:00:33 CEST] <cableguy> you just snatch it from here https://ffmpeg.zeranoe.com/builds/ [15:00:35 CEST] <BtbN> Then whoever built it did. [15:00:55 CEST] <cableguy> so its inside ffmpeg.exe [15:01:23 CEST] <cableguy> would be nice if you could point ffmpeg.exe to some external x265.exe [15:01:46 CEST] <BtbN> it does not use an exe. [15:51:22 CEST] <kepstin> viric: various formats can start at pts other than 0 yes, mpegts is a good example of that. Note that the ffmpeg cli tool (by default) rewrites input timestamps to start at 0. [15:55:18 CEST] <viric> kepstin: aaah good to know. I never understood what happened with that number. [15:55:30 CEST] <viric> kepstin: what about concatenating two MTS? [15:55:59 CEST] <viric> kepstin: do you know any case where that number is used? [15:56:29 CEST] <viric> By conatenating MTS, I mean two consecutive MTS that a camcorder created for continuous shot [15:57:01 CEST] <kepstin> viric: not enough info, it depends what the camcorder did with the timestamps [15:58:39 CEST] <kepstin> when concatenating arbitrary mpeg-ts, there's often a timestamp discontinuity - they'll jump backwards or far forwards. I think there's some code somewhere (in ffmpeg cli?) to notice these with heuristics and make timestamps continuous. [15:59:41 CEST] <kepstin> but on a camcorder, if they're only been split because of max file size limits? it might be a single continuous mpegts stream, so concatenating them would give you... a single continuous stream [16:00:10 CEST] <viric> kepstin: only max size limits. [16:00:16 CEST] <viric> ah ok. [16:00:39 CEST] <kepstin> depends on the camcorder, I don't know what yours does. [16:00:46 CEST] <viric> ok. [16:00:49 CEST] <viric> How can I know? :) [16:00:59 CEST] <viric> what to look at, with ffprobe? [16:01:46 CEST] Action: kepstin isn't great with ffprobe, so there's probably an easier way to do this, but... [16:02:34 CEST] <kepstin> if you look at the output of 'ffprobe -show_frames', which includes the frame timestamps, you can see if the timestamps at the start of one file follow from the timestamps at the end of another [16:03:32 CEST] <kepstin> ffprobe shows the timestamps as they are in the file, it doesn't do any cleanup/rewriting like the ffmpeg cli tool. [16:38:01 CEST] <Bear10> anyone knwo why: av_image_copy(frame->data, frame->linesize, data, linesize, pix_fmt, w, h); could be causing my memory to increase drastically (it's called on every frame in my custom filter) however I'm changing the data on the frame which I understand should be freed later on [16:38:26 CEST] <Bear10> i do av_frame_free(&in) and av_freep(&data[0]) to ensure that the originals are freed up [16:39:59 CEST] <atomnuker> your input is refcounted and you don't unref it [16:40:13 CEST] <Bear10> atomnuker: isn't that what the av_frame_free(&in) does? [16:41:19 CEST] <Bear10> just trying to learn :) [16:41:45 CEST] <atomnuker> custom filter? [16:41:56 CEST] <Bear10> yeah [16:41:59 CEST] <atomnuker> couldn't you just make the frame writeable? [16:42:10 CEST] <atomnuker> and then write to it [16:43:24 CEST] <Bear10> well i've tried with ff_load_image(frame->data, frame->linesize, ....) but had the same issue, and the w/h/pixfmt might be different since I'm reading a different image [16:43:57 CEST] <Bear10> correction: ff_load_image (in->data, in->linesize, ...) [16:45:27 CEST] <atomnuker> ff_ stuff is private [16:46:35 CEST] <Bear10> how would you recommend reading a jpg from a file and putting it into the frame? [16:47:10 CEST] <Bear10> I was pointed to https://github.com/jnicklas/ffmpeg_test/blob/master/test.c [16:47:29 CEST] <atomnuker> its already a frame [16:48:13 CEST] <Bear10> I understand that in is a frame, but it has a lot of information from the original frame which I want to completely replace with the information I read from a new jpg [16:49:00 CEST] <Bear10> hence I was pointed to that link [16:49:04 CEST] <Bear10> I have all of it working as desired a part from the memory issue [16:50:20 CEST] <atomnuker> trace all allocations you make then, ffmpeg internals make sure to NULL any freed pointers [16:50:52 CEST] <atomnuker> if you're working with 2 jpeg images then you'll need to make sure both avframes are unref'd [16:51:40 CEST] <atomnuker> (if you have a filter doing frame_a + frame_b -> frame_c, otherwise for something like frame_a + frame_b -> frame_a/frame_b make sure whatever you leave behind gets unreffd somehow) [16:55:31 CEST] <Bear10> atomnuker: hmm I thought that's what I was doing here's a pastebin https://pastebin.com/U2waqUqX of the filter_frame function [16:55:40 CEST] <Bear10> not sure if you see me missing anything you mentioned [16:56:11 CEST] <Bear10> I've also attempted adding av_frame_unref(...) before the av_free_frame(...) [16:57:56 CEST] <atomnuker> oh wait, its an internal filter? [16:58:05 CEST] <atomnuker> I thought it was external [16:58:19 CEST] <atomnuker> Bear10: ask durandal_1707 in this case [16:58:19 CEST] <Bear10> atomnuker: yeah it's a filter based on the writing_filters.txt [16:59:12 CEST] <Bear10> thanks atomnuker for the help :) [16:59:29 CEST] <Bear10> hello durandal_1707 if you get the chance could you lend me a quick hand? [17:01:42 CEST] <atomnuker> are you planning to put the patch on the ml? [17:03:45 CEST] <Bear10> ml? [17:04:08 CEST] <atomnuker> mailing list so the filter gets upstreamed? [17:04:15 CEST] <durandal_1707> Bear10: what about freeing data[1] and so on? [17:04:33 CEST] <Bear10> durandal_1707: I tried freeing data[1] [2] and [3] and still had the same issue oddly enough [17:04:51 CEST] <Bear10> atomnuker: if it turns out there's an actual issue and it's not me being a noob of course [17:04:55 CEST] <Bear10> :) [17:05:59 CEST] <durandal_1707> Bear10: are you on unix, use valgrind [17:06:47 CEST] <Bear10> durandal_1707: the odd thing also is on a mac OS X it doesn't seem to have this memory issue but on Linux Mint it's where it's happening [17:06:54 CEST] <Bear10> haven't heard of it i'll give it a look now [17:07:14 CEST] <JEEB> valgrind is awesomesauce [17:07:27 CEST] <JEEB> I would not be able to code as well as I do without the help of valgrind and static analyzers [17:07:43 CEST] <Bear10> in that case installing it now :) [17:08:47 CEST] <atomnuker> Bear10: you need to do it properly then and make the filter take 2 inputs rather than a frame and a name, look how e.g. vf_premultiply does it [17:10:59 CEST] <Bear10> ok will have a look, it's going to be a bit to look into but i'll try and come back with some results / information [17:11:01 CEST] <Bear10> thanks again guys :) [17:12:48 CEST] <durandal_1707> Bear10: what filter actually do? [17:13:09 CEST] <Hello_> Hi, I need help [17:13:25 CEST] <Hello_> pls [17:13:27 CEST] <Bear10> durandal_1707: it ignores the frame that's being input (it's in an overlay) and replaces it with a jpg of my choosing [17:13:58 CEST] <Bear10> but I can't do it with normal cli commands or existing filters because it needs to be dynamic (changing on queue) [17:14:10 CEST] <Bear10> like a news anchor talking about the weather a sun shows up [17:14:55 CEST] <Bear10> when he/she talks about economic crisis a chart jpeg would show up [17:14:55 CEST] <Bear10> etc etc [17:15:08 CEST] <Bear10> on cue* [17:15:26 CEST] <atomnuker> Bear10: vf_overlay already does that [17:16:05 CEST] <durandal_1707> but overlay isnt dynamic [17:16:21 CEST] <atomnuker> define dynamic? [17:16:29 CEST] <atomnuker> you can change its input [17:16:42 CEST] <atomnuker> you can even toggle it using the timeline since its supported by it [17:17:01 CEST] <Bear10> atomnuker: does it? i tried looking everywhere and couldn't find information anywhere [17:17:18 CEST] <Bear10> i don't mean timeline [17:17:26 CEST] <Bear10> because an offset isn't the same as "on cue" [17:17:36 CEST] <durandal_1707> you would need to just write filter which would take inputs as commands and copy it to output [17:17:53 CEST] <atomnuker> Bear10: what offset? [17:18:06 CEST] <durandal_1707> Hello_: help what? [17:18:33 CEST] <Bear10> atomnuker: I've heard of -itoffset or something like that, can't find it right now [17:18:41 CEST] <Bear10> for an overlay to appear / disappear after X seconds [17:19:03 CEST] <atomnuker> vf_overlay does that [17:19:09 CEST] <Bear10> that's not what I want [17:19:11 CEST] <atomnuker> you just need to use the api [17:19:16 CEST] <durandal_1707> overlay approach looks to complicated [17:19:23 CEST] <atomnuker> and feed in the second source as you need [17:19:39 CEST] <atomnuker> why do you feel you need to cram everything into the ffmpeg command line tool? [17:20:05 CEST] <Bear10> atomnuker: I'm new to ffmpeg and the documentation available isn't the easiest in the world to understand the sourcecode :) [17:20:09 CEST] <atomnuker> the API is there if it doesn't do what you need it to do [17:21:07 CEST] <durandal_1707> atomnuker: he would need to create new filtergraph for every new image [17:21:18 CEST] <atomnuker> durandal_1707: not necessary [17:22:12 CEST] <durandal_1707> there is no filter which concat various overlays over video [17:22:22 CEST] <atomnuker> just make vf_overlay's second input the same as the first input and do compositing on it using some toolkit [17:22:42 CEST] <atomnuker> using the alpha channel to mask stuff out of the second input [17:22:57 CEST] <atomnuker> *same size that is [17:23:04 CEST] <durandal_1707> yes that what im saying for overlay input [17:23:51 CEST] <durandal_1707> filter would just load images dynamically and create transparent pixels when needed [17:24:07 CEST] <Bear10> durandal_1707: that's what I'm attempting to do [17:24:11 CEST] <atomnuker> not filter, the user himself needs to do that [17:24:25 CEST] <atomnuker> a filter would be too inflexible [17:24:53 CEST] <durandal_1707> well not really, there are commands for filters [17:25:36 CEST] <atomnuker> yes, but "show this logo for 10 seconds" and then "show another for 4 seconds" is not something a filter needs to do [17:26:32 CEST] <atomnuker> its something users need to do [17:27:33 CEST] <Bear10> when you say "using some toolkit" could you give an example of one? [17:27:36 CEST] <durandal_1707> but they want too use cli and not c [17:28:01 CEST] <Bear10> or where in the code I should be looking at if not a custom filter [17:41:19 CEST] <atomnuker> durandal_1707: the cli gets far too inflexible for something like this, not to mention you can't do frame-perfect sync [17:41:51 CEST] <atomnuker> its not the proper way of doing things [17:44:24 CEST] <atomnuker> depending on what you need to do you might want to run 2 filter instances in your program [17:44:53 CEST] <atomnuker> so one filter to produce what you want to overlay and another to overlay it onto your main image [17:46:35 CEST] <atomnuker> so to load an image you can either do it the standard way and use lavc + lavf to get a frame or vf_movie to do it for you [17:47:09 CEST] <Bear10> well that's basically what we have isn't it? 1) we have our filter named "news" where we grab the frame, place the image etc, and then our output goes 2) into the overlay filter [17:47:23 CEST] <atomnuker> then if you needed to draw some text somewhere you'd use the drawtext filter on the resulting frame [17:47:33 CEST] <Bear10> I mean we have the desired output, the problem is in the memory [17:47:34 CEST] <atomnuker> Bear10: that's not the issue [17:47:40 CEST] <atomnuker> the issue is control [17:47:48 CEST] <atomnuker> how do you control what shows up and when? [17:48:18 CEST] <Hello_> aaa [17:48:28 CEST] <atomnuker> you have no way of controlling this via the command line [17:48:39 CEST] <Hello_> duranda1_1707 [17:48:45 CEST] <Bear10> atomnuker: we're not trying to control the image via the command line though [17:49:06 CEST] <Bear10> but there are options and I saw there was a way to dynamically change options [17:49:06 CEST] <atomnuker> what, you just load some random files from a directory whenever they crop up? [17:50:04 CEST] <Bear10> currently for testing and prototype purposes we're doing it with a txt file, but I saw we could maybe use zmq [17:50:09 CEST] <atomnuker> you can't change any options via the command line [17:50:19 CEST] <atomnuker> after you run it, that's it, its done [17:50:31 CEST] <atomnuker> if you need to change options you need to use the API [17:51:04 CEST] <atomnuker> during runtime that is [17:51:13 CEST] <Bear10> when you say API to what are you referring to? [17:51:23 CEST] <atomnuker> the libavfilter API [17:51:42 CEST] <Bear10> I linked you to the frame_filter code we have, we're using the API [17:52:27 CEST] <Bear10> as mentioned we have the desired output, everything is working as we want, we're just having an issue with a memory leak with the frame and buffer with the av_image_copy [17:52:55 CEST] <Bear10> it happens on Linux Mint but not OS X [17:52:58 CEST] <atomnuker> fine, you can sort it out yourselves, though if you try to upstream it I'll object to having it in the codebase [17:53:41 CEST] <atomnuker> its in no way something that should be encouraged, writing filters because you can't do things via the command line [17:54:05 CEST] <Bear10> you have a doc that says writing_filters.txt [17:55:01 CEST] <Bear10> you're contradicting yourself by saying "it shouldn't be done", "use the API", "don't write a filter" "you have to use CLI", "you can't change options via CLI" [17:55:28 CEST] <atomnuker> I never said you have to use the cli, I said the opposite of that [17:55:45 CEST] <Bear10> so I have a filter... so what's the issue? [17:55:49 CEST] <atomnuker> it sucks [17:55:59 CEST] <Bear10> and you have proposed nothing to fix it [17:56:00 CEST] <atomnuker> its a hack [17:56:18 CEST] <atomnuker> nevermind that it doesn't work, its conceptually wrong [17:58:34 CEST] <Bear10> it does work though [17:59:25 CEST] <Bear10> on OS X it works fine, Linux Mint it has a leak from an av_image_copy which is part of the API, I'm attempting to use av_frame_free (part of the API) and av_freep (also part of the API) but perhaps I'm missing something else [18:00:38 CEST] <bencoh> considering you're running the very same code on both platform, I'd try with another memory allocator on linux (say, jemalloc) just to make sure [18:02:28 CEST] <Bear10> ok will give that a try thanks bencoh [18:07:19 CEST] <Blubberbub_> is file-metadata(interpret,title,...) for audio only included in the first or in every frame? [19:06:54 CEST] <markmedes2> Fellas, I need to scan some files for errors, I'm using ffmpeg -v error -i ... Is there a way to include the timestamp of the error in the log? [20:38:10 CEST] <pgorley> to convert an audio file to an array of samples (int16_t), do i need to decode the audio using the send_packet/receive_frame api? [21:52:21 CEST] <viric> kepstin: thank you [21:52:32 CEST] <viric> kepstin: in fact I want to program an audio track aligner [21:52:36 CEST] <viric> does that exist at all? [21:52:59 CEST] <kepstin> I'm not sure what you mean by "audio track aligner" [21:55:00 CEST] <Blubberbub_> so you have like a similar sound at the beginning and want to mix all audio tracks together and shift them, so the signal is aligned? [21:56:25 CEST] <Blubberbub_> for example when recording something with multiple cameras people often "clap" before doing anything, so they can synchronize everything later? [21:59:31 CEST] <viric> kepstin: I have two recording devices for the same scene, and I want them under same pts [22:00:20 CEST] <viric> kepstin: they have slightly different clock, additionaly. [22:00:52 CEST] <viric> kepstin: about 1s drift per hour [22:00:56 CEST] <kepstin> sounds annoying to deal with, if they're on different clocks :/ [22:01:36 CEST] <viric> right. [22:01:41 CEST] <viric> only slightly different [22:02:12 CEST] <Blubberbub_> Do you want to do that live? [22:02:55 CEST] <kepstin> but yeah, aligning those tracks in post really wouldn't be that hard as long as you have some identifiable synchronization points near the start and near the end of each track, so you can find what pts in each track the synch points are at [22:03:01 CEST] <pgorley> does "ffmpeg -i <file> -f s16le -acodec pcm_s16le output.raw" extract the raw audio samples from the file? [22:03:15 CEST] <kepstin> then just resample to fix the length, and apply an offset to align them [22:04:03 CEST] <viric> kepstin: right. But usually the identifiable points are hard to find too. I hope I can write something that will find the correlations/offsets/atempo factors for me [22:04:23 CEST] <Blubberbub_> there is a python script on github somewhere that does something like that [22:04:40 CEST] <viric> Blubberbub_: can you find it? [22:04:45 CEST] <kepstin> getting into some fun audio analysis stuff for that, yeah. Out of my area of experience :) [22:05:20 CEST] <Blubberbub_> viric, https://github.com/bbc/audio-offset-finder [22:05:34 CEST] <Blubberbub_> it only works on python2, though [22:05:51 CEST] <viric> https://github.com/protyposis/AudioAlign ? [22:06:00 CEST] <kepstin> the bbc one only appears to do the offset, not the scaling to compensate for clock drift [22:06:10 CEST] <viric> what bbc? [22:06:20 CEST] <viric> ah bbc. ok [22:14:08 CEST] <viric> mh that AudioAlign would be hard to beat [22:14:12 CEST] <viric> but it's for Windows. [22:14:59 CEST] <ultrav1olet> I cannot seem to find any documentation on video stream framerate information. Could someone please document all the values because Googling hasn't netted anything interesting. [22:15:14 CEST] <ultrav1olet> I'm talking about: " 25 fps, 25 tbr, 1k tbn, 50 tbc (default)" [22:15:35 CEST] <ultrav1olet> these things are absolutely cryptic and 1k looks like 1000 which doesn't make any sense [23:08:30 CEST] <markmedes2> Is there a way to scan a file for error and print the timestamp of the error when ffmpeg finds one? [23:40:19 CEST] <Mista_D> can a format of the source file be passed to output, regardless of file extension? [23:57:55 CEST] <ultrav1olet> The source video which contains 135475 frames became a video with 132725 frames. What gives? [23:58:30 CEST] <ultrav1olet> I've just reencoded video - that's all - no fancy options/parameters/anything [00:00:00 CEST] --- Thu Aug 10 2017

1 0

ffmpeg-devel.log.20170808
by burek 09 Aug '17

09 Aug '17

[02:16:47 CEST] <thebombzen> it looks like they're linking in Libav, not ffmpeg [02:17:16 CEST] <thebombzen> given the whole --enable-avserver --enable-avplay [02:17:39 CEST] <thebombzen> kierank: this doesn't look like an issue with FFmpeg [02:17:58 CEST] <thebombzen> so yea it's an GPL violation but shouldn't this by taken up with Libav? [02:18:00 CEST] <kierank> hmm probably yes [02:18:13 CEST] <kierank> but there's definitely ffmpeg code in there so whatever [02:22:33 CEST] <thebombzen> IANAL /shrug [03:07:01 CEST] <rcombs> any GPL violation is generally going to be violating the copyright of both projects [03:07:12 CEST] <rcombs> since they share most of their code [05:34:57 CEST] <ZeroWalker> is there a way to tell ffmpeg that the video frame is upside down? [06:35:30 CEST] <cone-468> ffmpeg 03James Almer 07master:45759540a559: fate: update ref files for gray pixel formats changes [09:37:32 CEST] <nevcairiel> how do dropbox mails like that even get to the ML, clearly dropbox isnt subscribed, shouldnt that then be in ML moderation? did someone approve that? :p [10:02:08 CEST] <durandal_1707> Compn approved it [11:41:35 CEST] <Compn> [04:02] <durandal_1707> Compn approved it [11:41:36 CEST] <Compn> lies [11:52:36 CEST] <Compn> the last time we investigated a similar email, it turned out that the automated mailer (i think it was linkedin....) had spoofed its mail headers [11:55:56 CEST] <Compn> so shyamaldass001@gmail is a subscriber to the list, and dropbox used that email as its FROM: , while using an reply-to email no-reply(a)dropboxmail.com [11:56:02 CEST] <Compn> at least thats my guess [11:56:06 CEST] <Compn> i didnt verify with the logs [14:18:28 CEST] <kurosu> nasm dependency generation seems broken here (MSYS2/2.13.01) [14:18:36 CEST] <kurosu> example: libavcodec/x86/simple_idct10.o: <PATH>/libavcodec/x86/simple_idct10.asm [14:19:14 CEST] <kurosu> correct: libavcodec/x86/simple_idct10.o: <PATH>/libavcodec/x86/simple_idct10.asm config.asm <PATH>/libavutil/x86/x86util.asm <PATH>/libavutil/x86/x86inc.asm <PATH>/libavcodec/x86/simple_idct10_template.asm [14:19:58 CEST] <kurosu> seems to work correctly if "-MD <FILE>.d -M" is used instead of plain "-MD <FILE>.d" [14:20:08 CEST] <kurosu> moving the '-M' in front doesn't work [14:21:25 CEST] <kurosu> (above is content of libavcodec/x86/simple_idct10.d) [14:23:32 CEST] <kurosu> test: change date of libavcodec/x86/simple_idct10_template.asm and see not being libavcodec/x86/simple_idct10.o recompiled [14:24:54 CEST] <kurosu> nevermind the solution, doesn't work, but the problem still there [14:25:08 CEST] <J_Darnley> atomnuker, kierank: do you have any suggestions for removing/working around the buffer allocation for bitstream writing in vc2enc? [14:26:41 CEST] <atomnuker> J_Darnley: you need a buffer to write to [14:26:52 CEST] <atomnuker> and its already written to directly, there's nothing to remove [14:27:18 CEST] <atomnuker> you need to know how many bits it'll take to encode something to you know how much to alloc [14:27:49 CEST] <nevcairiel> buffer allocation in encoders is an annoying problem [14:27:54 CEST] <atomnuker> you could always allocate the max possible [14:28:01 CEST] <atomnuker> then encode to it without knowing the size [14:28:05 CEST] <J_Darnley> But I can't allocate it without knowing the size needed. I can't know that without doing the transform. I can't do the transform without the whole picture. [14:28:38 CEST] <atomnuker> then you have a buffer where you write to which is always big enough to store uncompressed coeffs + a bit more [14:28:41 CEST] <nevcairiel> ffv1enc uses the max size, but the max size is basically uncompressed size, which poses its own sort of problems with high resolution content [14:28:43 CEST] <atomnuker> you encode to it [14:28:52 CEST] <J_Darnley> But it seems to allocate 1 buffer for every slice? [14:28:55 CEST] <atomnuker> and then you copy the amount you wrote to the main one [14:29:35 CEST] <atomnuker> you could get away without copying but then you'll need to do things serially [14:30:02 CEST] <atomnuker> so you won't be able to slice thread if you don't memcpy [14:30:09 CEST] <J_Darnley> I miss the days when I was writing directly to network card buffer. [14:34:22 CEST] <atomnuker> the only exciting thing about network cards is ipv6 [14:35:02 CEST] <atomnuker> I had to connect to an rpi I flashed, I didn't have a router, I didn't have a dhcp server, I had a cable and 2 ethernet ports [14:35:26 CEST] <atomnuker> thanks to stateless ipv6 I was able to just hook them up and use the rpi's hostname to ssh [14:40:55 CEST] <kierank> J_Darnley: if you constrain the encoder to take a slice at a time you can do what you want [14:41:04 CEST] <kierank> Just allocate and overshoot [14:41:11 CEST] <kierank> And then write direct to that buffer [14:56:29 CEST] <kurosu> nevcairiel / jamrial (when and if he shows up): https://bugzilla.nasm.us/show_bug.cgi?id=3392420 for the above issue [14:59:07 CEST] <iive> can we assume that the encoded picture would always be smaller than the raw input fame size? [14:59:14 CEST] <iive> frame [14:59:25 CEST] <atomnuker> iive: nope [15:00:08 CEST] <iive> ok, but if it gets bigger... maybe we should just dump the raw frame ;) [15:01:52 CEST] <cone-446> ffmpeg 03wm4 07master:caa12027baf1: lavc, lavu: move frame cropping to a convenience function [15:01:53 CEST] <cone-446> ffmpeg 03wm4 07master:463b81de2b25: imgutils: add function to clear an image to black [15:25:58 CEST] <atomnuker> J_Darnley: no one has started working on such a thing on the encoding side, only on the decoding side using draw_horiz_band [17:15:05 CEST] <durandal_1707> how good is speex aec? [17:16:35 CEST] <wm4> have merges completely died? [17:17:35 CEST] <wm4> last one was 3 months ago [17:18:03 CEST] <atomnuker> durandal_1707: should be pretty good, though ask jmspeex in #opus if he has come up with something better [17:18:45 CEST] <wm4> philipl: tried to look at libav's cuda hwaccel? [18:01:15 CEST] <durandal_1707> ubitux is on vacation [18:55:19 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:41096904d036: avfilter/vf_separatefields: stop leaking last frame [18:57:33 CEST] <Compn> wm4 : no one wants merge job [18:57:49 CEST] <Compn> wm4 : feel free to cherry pick ? [18:58:11 CEST] <durandal_1707> Compn: are you coming to VDD? [18:59:06 CEST] <Compn> durandal_1707 : no, dont think so [18:59:18 CEST] <Compn> durandal_1707 : are you going ? [18:59:32 CEST] <durandal_1707> no :( [18:59:35 CEST] <Compn> why not ? [18:59:41 CEST] <Compn> paris is nice [18:59:50 CEST] <durandal_1707> im busy and afraid [19:00:17 CEST] <atomnuker> Compn: okay, you're not there, is you beard going to attend though? [19:00:40 CEST] <Compn> only if it was in the south france part [19:00:47 CEST] <Compn> i'd go if it were held in nice :) [19:01:08 CEST] <Compn> check out monaco again [19:01:59 CEST] <Compn> atomnuker : buy a beard and wear it around vdd to keep the beard levels up [19:25:41 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:a5380f9c1c46: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [19:32:45 CEST] <kierank> durandal_1707: afraid of whom? [19:32:59 CEST] <kierank> I know kung fu I can protect you [19:33:14 CEST] <durandal_1707> kierank: im afraid of paris [19:33:41 CEST] <kierank> who isn't [19:34:03 CEST] <atomnuker> I know, right, the metro system can leave you trapped in the tunnels [19:34:20 CEST] <kierank> i'm afraid of the smell tbh [19:34:29 CEST] <kierank> everywhere smells of piss [20:02:12 CEST] <philipl> wm4: No. They added a full one? [20:02:23 CEST] <wm4> yes [20:02:36 CEST] <wm4> haven't had the chance to test because I'd need the cuda sdk installed [20:02:39 CEST] <philipl> Someone loves suffering. nvidia don't document how to use it without their parser [20:02:53 CEST] <wm4> seems like elenril figured it out [20:05:11 CEST] <philipl> But still too stubborn to borrow any code from ffmpeg so he didn't use the dynamic loader for cuda [20:06:52 CEST] <philipl> I think, conceptually, it's better to have a real hwaccel as the nvidia parser is not perfect. It's probably the cause for the glitches that hanna observed. [20:07:05 CEST] <wm4> I had this discussion with him [20:07:09 CEST] <philipl> BtbN: You look at this? [20:07:10 CEST] <wm4> he was all like "just install the sdk" [20:07:24 CEST] <BtbN> hm? [20:07:31 CEST] <philipl> real cuvid hwaccel [20:07:50 CEST] <BtbN> Did they actually merge it in libav? [20:07:53 CEST] <philipl> Yep [20:07:58 CEST] <philipl> https://github.com/libav/libav/blob/master/libavcodec/cuvid_hevc.c etc [20:08:07 CEST] <BtbN> How did they solve the issue of it being horribly slow, because no buffering? [20:08:21 CEST] <philipl> Of course, only two codecs right now. [20:08:33 CEST] <philipl> Dunno. I guess it's fast enough for playback even if you do nothing [20:08:42 CEST] <philipl> Transcode might be garbage, but we'd have to test [20:09:50 CEST] <philipl> If there are no functional regressions (and performance is the big one I guess), I'd be in favour of adopting it. Of course, we'd need to keep the current one around to cover the other codecs until someone writes the individual hwaccels [20:10:32 CEST] <philipl> I don't think there's any claim that the nvidia parser is better in any circumstance. [20:10:55 CEST] <BtbN> It's nice to have it around though [20:12:13 CEST] <BtbN> https://github.com/libav/libav/blob/master/libavcodec/decode.h#L39 [20:12:33 CEST] <philipl> Assuming we had all the hwaccels and no functional regressions, would you actually want it around? [20:12:38 CEST] <philipl> That's his solution to buffering? [20:12:46 CEST] <BtbN> https://github.com/libav/libav/commit/704311b2946d74a80f65906961cd9baaa1868… [20:12:49 CEST] <BtbN> yes, looks like it [20:13:10 CEST] <BtbN> https://github.com/libav/libav/commit/badf0951f54c1332e77455dc40398f3512540… [20:13:28 CEST] <philipl> Yay I guess. [20:13:43 CEST] <BtbN> Yeah, if it works at the same performance, I'd prefer it [20:13:53 CEST] <BtbN> Allows for some more obscure stuff to be possible [20:13:56 CEST] <philipl> In practical terms, I know the nvidia parser prevents us supporting wmv9 and webp. [20:14:11 CEST] <BtbN> like those weird in-video subtitles [20:14:51 CEST] <philipl> Aren't those fun... [20:15:06 CEST] <BtbN> I wonder though, the delay that adds does not seem overly crazy [20:15:10 CEST] <philipl> Switching would also let me drop the whole fake hwaccel comamnd line thing that we never resolved. [20:15:35 CEST] <BtbN> I don't think switching is possible without breaking api [20:17:03 CEST] <philipl> Well, we can keep the current decoder around - the namespace is separate [20:17:17 CEST] <philipl> So this would be additional until the next break opportunity [20:17:53 CEST] <BtbN> It does not look like their cuvid stuff is able to output CUDA frames though? [20:17:59 CEST] <wm4> both cuvid decoder and hwaccel will call get_format [20:18:03 CEST] <wm4> you're in for some mess [20:18:12 CEST] <philipl> eh... [20:18:17 CEST] <BtbN> hm? [20:18:29 CEST] <BtbN> The new cuvid decoder is a normal hwaccel [20:18:34 CEST] <BtbN> It will behave like any other one [20:18:41 CEST] <philipl> wm4: I mean, we'd have give the two hwaccels different names. [20:19:02 CEST] <wm4> get_format uses _only_ the pixfmt to identify or select the hwaccel [20:19:22 CEST] <BtbN> Just going to get rid of the dummy hwaccel then [20:19:25 CEST] <wm4> so a caller using the cuda hwaccel would have to distinguish them in another way [20:19:26 CEST] <BtbN> it's not needed anymore then anyway [20:19:36 CEST] <philipl> Well, then we now have an opportunity to change the format to use cuda arrays :-) [20:19:38 CEST] <wm4> that could work, or would at least reduce the mess [20:20:17 CEST] <wm4> btw. I wonder if there is cuda/vulkan interop [20:21:07 CEST] <BtbN> There is a generic extension for VK to use "external memory" [20:24:13 CEST] <philipl> I keep looking. [20:24:20 CEST] <philipl> There needs to be a cuda side to the VK extension [20:24:26 CEST] <philipl> That doesn't exist yet - maybe it's in cuda 9 [20:24:38 CEST] <wm4> it could be that the vulkan side just imports generic memory [20:24:59 CEST] <wm4> and you use that as an image [20:25:08 CEST] <wm4> (vulkan is low level enough that this is possible) [20:25:39 CEST] <wm4> via VK_KHX_external_memory / VK_KHX_external_memory_fd [20:25:52 CEST] <kurosu> what's the content of libavcodec/x86/simple_idct10.d (build system dependency file included by makefile) for people targeting x86 here? [20:26:26 CEST] <kurosu> can anyone confirm it has a single dependency <PATH>/libavcodec/x86/simple_idct10.asm [20:27:34 CEST] <philipl> wm4: it is possible, but it does at least need to be documented as to whether you just pass a cuda pointer, etc. [20:27:40 CEST] <wm4> yeah [20:38:29 CEST] <kierank> kurosu: J_Darnley: ping [20:38:43 CEST] <kierank> maybe you know the answer J_Darnley [20:38:50 CEST] <J_Darnley> Maybe [20:41:15 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:fea7bc9e7b9a: avcodec/dvenc: Support adjusting the quantizer deadzone [20:41:16 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:abaeeb3ce08d: avcodec/dvenc: Change quantizer dead zone default to 7 [20:41:19 CEST] <J_Darnley> I would expect the deps for an assembly object to be the .asm file, x86inc.asm, x86util.asm [20:41:37 CEST] <J_Darnley> Oh, and config.asm I guess [20:42:03 CEST] <kurosu> and also simple_idct10_template.asm in that case [20:42:17 CEST] <kurosu> that's the output of -M, while -MF is borked [20:42:56 CEST] <kurosu> for a particular case, until verified on other platforms [20:43:38 CEST] <J_Darnley> Didn't someone file a bug on nasm's tracker about it? [20:43:53 CEST] <kurosu> <- you're probably thinking of this guy [20:44:01 CEST] <J_Darnley> :) maybe I am [20:46:54 CEST] <ubitux> hello [20:47:24 CEST] <ubitux> holidays are boring, i'm better at home derping with other nerds [20:47:50 CEST] <ubitux> hey wm4, not sure if you saw it, i fixed your subrip nesting issue a few days ago [20:47:56 CEST] <ubitux> you may want to give it a try [20:48:08 CEST] <ubitux> (i took the opportunity to improve the br handling too) [20:48:11 CEST] <J_Darnley> kurosu: yes, with nasm 2.13 I have only the asm file as a dependency [20:48:40 CEST] <ubitux> J_Darnley: nasm deps are broken, i opened a ticket a while ago, but i should probably open it at nasm bug tracker [20:48:48 CEST] <kurosu> oh [20:48:49 CEST] <ubitux> i wasn't sure if we messed up options ourselves [20:48:51 CEST] <kurosu> I just did [20:49:08 CEST] <wm4> ubitux: saw it, it's nice [20:49:12 CEST] <kurosu> no, bug confirmed by martsin storsjo & a nasm developper [20:49:22 CEST] <kurosu> https://bugzilla.nasm.us/show_bug.cgi?id=3392420 [20:49:33 CEST] <ubitux> oh that's great [20:49:36 CEST] <kurosu> and it now appears to be for several platforms (I suspect all) [20:49:53 CEST] <kurosu> weird that nobody was bitten by this bug [20:50:46 CEST] <kurosu> using -M (which doesn't generate the object file) generates the proper output [20:51:03 CEST] <ubitux> mmh i can't find the ticket again [20:51:19 CEST] <ubitux> only https://trac.ffmpeg.org/ticket/6516 which is unrelated (but also a nasm bug) [20:51:27 CEST] <ubitux> maybe i only poke on the ml [20:52:22 CEST] <J_Darnley> Well, I would only be bitten by it if I were working on the headers. [20:53:03 CEST] <thebombzen> Who administers the website HTML stuff? There's a deadlink: http://0x0.st/d2f.png [20:53:07 CEST] <J_Darnley> I might have noticed when working on the idct template but I was usually dealing with both files for that. [20:53:16 CEST] <thebombzen> This button "Read on Gmane" is a big fat 404 [20:53:45 CEST] <thebombzen> or do I submit a trac bug for website UI issues as well [20:53:58 CEST] <J_Darnley> kierank: was the nasm thing why you pinged me? [20:54:53 CEST] <kierank> Yes [20:54:59 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212899.html [20:55:00 CEST] <J_Darnley> thebombzen: if nobody replies then you may submit a ticket [20:55:05 CEST] <ubitux> kurosu: seems i only reported it here ^ [20:55:14 CEST] <thebombzen> alright [20:55:21 CEST] <ubitux> (and we had a discussion on irc) [20:56:12 CEST] <kurosu> "touch libavcodec/x86/simple_idct10_template.asm" doesn't trigger a recompilation of the object file, as expected with the incomplete dependency file [20:57:04 CEST] <ubitux> yep [20:57:06 CEST] <kurosu> well, I was likely to have missed all these discussions, but the bug is filed and acknowledged by the nasm authors [20:57:15 CEST] <ubitux> it took me a while to realize the problem when i was doing regression testing [21:01:23 CEST] <jamrial> does that affect every nasm version until now, or just the most recent ones? [21:02:16 CEST] <jamrial> depending on that, we should add a configure check to use the yasm style preprocess-then-assemble in two separate calls based on reported nasm version [21:06:35 CEST] <durandal_1707> have new chl api been merged into libav? [21:14:01 CEST] <kurosu> jamrial, no idea, I think I saw a bug report around 2014 because -MF (or -MD) didn't exist [23:34:58 CEST] <BtbN> 0.6.3?! [23:35:07 CEST] <nevcairiel> its a very old ticket [00:00:00 CEST] --- Wed Aug 9 2017

1 0

ffmpeg.log.20170808
by burek 09 Aug '17

09 Aug '17

[00:03:37 CEST] <BtbN> HEVC is h265. [01:15:14 CEST] <roman_> hello [01:15:33 CEST] <roman_> are there any ffmpeg binaries out there that contain just the LGPL libs [01:15:45 CEST] <roman_> and not the GPL libs (i.e. libx264 libx265 etc.) [01:16:12 CEST] <roman_> im trying to find one for macos without having to compile mine, so it will work on all versions and not just sierraq [01:17:11 CEST] <thebombzen> roman_: if you're looking for static builds (i.e. the command-line tools) there is minimal practical difference between the GPL and LGPL versions [01:17:31 CEST] <thebombzen> if you're interested in the dynamic libraries, then you will probably have to compile them yourself [01:17:55 CEST] <roman_> yes but this is for commercial distribution and in order to keep the product closed source i cant have the gpl [01:18:09 CEST] <thebombzen> only with linking [01:18:47 CEST] <roman_> right i know [01:18:56 CEST] <roman_> im going to do dynamic link [01:19:17 CEST] <roman_> and include ffmpeg's src as well i just want to see if there's a place where this has been built already [01:19:24 CEST] <thebombzen> You will probably have to compile it yourself. This is not a bad thing though because compiling it yourself lets you enable exactly what you need [01:19:40 CEST] <roman_> right, but how do i make it work on all versions though? [01:19:46 CEST] <roman_> because when i compile it does it for just my environment [01:20:07 CEST] <thebombzen> for a commercial distribution, compiling your own dynamic LGPL verisons and disalbing components you don't need is probably the best bet [01:20:15 CEST] <roman_> ok [01:20:21 CEST] <roman_> how do i ensure backwards compatibility? [01:20:22 CEST] <thebombzen> as for what compiler flags on macOS you need to ensure compatibility? [01:20:27 CEST] <thebombzen> it depends on what version you want to target [01:20:34 CEST] <roman_> like 10.8+ [01:20:39 CEST] <thebombzen> good options are --enable-runtime-cpudetect [01:20:45 CEST] <roman_> and im building on 10.12 [01:21:07 CEST] <roman_> i mean the problem is that the macos compiler defaults it to minimum sdk version 10.12 [01:21:13 CEST] <roman_> and i need it at 10.8ish [01:21:18 CEST] <thebombzen> I'm not exactly familiar with macOS's compilers but, if they're GCC compatible you can use -march=x86_64 -mtune=generic [01:21:32 CEST] <thebombzen> this eliminates the CPU issue [01:21:51 CEST] <roman_> its not really a cpu issue, but an os version issue [01:22:10 CEST] <roman_> because the environment its built in = the minimum environment it can run in [01:22:20 CEST] <roman_> so if i build it in 10.12 then it sets minimum version requirement to 10.12 [01:22:37 CEST] <thebombzen> there is a way to do this, I am certain. I just don't know what it is seeing as I don't use macOS. However someone here does know so you can wait for them to answer [01:22:56 CEST] <roman_> alright [01:22:59 CEST] <roman_> thank you thebombzen ;) [01:41:10 CEST] <JEEB> roman_: yea I definitely recommend you building yourself. and yes, you'll have to build on a VM of 10.8 or so if you want to keep compat with 10.8 [01:41:21 CEST] <JEEB> it's a pain in the arse but you will definitely want to have that knowledge [01:42:11 CEST] <roman_> ok [01:42:18 CEST] <roman_> ive done command line and all that stuff before [01:42:23 CEST] <roman_> i just want to ensure max compatibility [01:42:33 CEST] <JEEB> and yes, apple doesn't make that simple [01:42:49 CEST] <roman_> what about downloading the different codecs i.e. libvpx [01:42:50 CEST] <JEEB> some people even made tools to get old xcodes around to newer macoses [01:42:59 CEST] <JEEB> roman_: include only what you really need [01:43:06 CEST] <roman_> yea [01:43:07 CEST] <JEEB> 99% of all decoders are in FFmpeg itself [01:43:19 CEST] <JEEB> only include encoders you need [01:43:27 CEST] <roman_> ok [01:43:34 CEST] <JEEB> in other words, find out which formats you need to encode to [01:43:42 CEST] <roman_> right i already know which libs i need [01:43:48 CEST] <JEEB> ok [01:44:12 CEST] <roman_> so when i download those libs, do i just get it from homebrew or do i have to compile those too [01:44:28 CEST] <roman_> in other words i dont want the compiler to target my specific system, but allow compatibility with all macos systems [01:44:42 CEST] <JEEB> if you are going to distribute those, I definitely recommend not on relying on someone else's binaries [01:44:58 CEST] <roman_> so the only thing i need to worry about is my os version or do i need to worry about stuff like cpu architecture etc etc [01:45:01 CEST] <roman_> ok [01:45:31 CEST] <JEEB> xcode contains the toolchain so I would guess it's actually more about the xcode version installed than macos? no idea though, I have such a limited view into macos :P [01:45:36 CEST] <kepstin> I think the typical way people do mac os builds like that is find a mac mini or something running the oldest mac os version they want to support :/ [01:45:42 CEST] <JEEB> yes [01:46:00 CEST] <thebombzen> haha [01:46:06 CEST] <roman_> ok [01:46:09 CEST] <thebombzen> can't you create a VM or something as well? [01:46:12 CEST] <JEEB> yes [01:46:16 CEST] Action: JEEB has VMs [01:46:30 CEST] <roman_> so when im compiling [01:46:35 CEST] <JEEB> so a mac can run an older version of macos/OS X [01:46:38 CEST] <JEEB> in a VM [01:46:55 CEST] <JEEB> often the macs just lack the RAM for that, though :P [01:46:58 CEST] <thebombzen> is this built-in technology or do you need something 3rd party like virtualbox? [01:47:08 CEST] <furq> JEEB: is that seriously the only way you can target older OSX versions [01:47:10 CEST] <furq> because that fucking sucks [01:47:23 CEST] <JEEB> furq: I hear running older xcode *can* work [01:47:26 CEST] <JEEB> but that requires hacks [01:47:29 CEST] <furq> i was expecting like a compiler flag or something [01:47:36 CEST] <furq> not "run the version you want to target in a VM" [01:47:41 CEST] <thebombzen> furq: apple explicitly and deliberately rejects supporting older versions of the operating systems [01:47:48 CEST] <JEEB> newer xcode lets you only target newer macos [01:47:58 CEST] <roman_> so when im compiling i just need to go to the lowest macos version i want to support and compile that way? I don't have to worry about anything else? [01:48:05 CEST] <JEEB> yes [01:48:13 CEST] <roman_> ok [01:48:14 CEST] <JEEB> just test all the versions upwards you care about, of course [01:48:19 CEST] <roman_> ok [01:48:27 CEST] <thebombzen> furq: for example if you own an iPhone it's impossible to downgrade your firmware. Because the phone has a call-home feature where Apple has to sign the firmware (gs.apple.com) and if they don't the phone will reject it [01:48:30 CEST] <JEEB> and some libraries will not be available for you if they were added later [01:48:54 CEST] <roman_> i just wanted to make sure clang didnt do any other stuff like only target specific chipsets or whatever [01:49:04 CEST] <JEEB> for macos that generally doesn't happen [01:49:11 CEST] <JEEB> unless you built for iOS or something [01:49:16 CEST] <JEEB> but even that is ARM [01:49:21 CEST] <roman_> so generally when im compiling on macOS, it will work for all the macs that version and above? [01:49:24 CEST] <thebombzen> furq: you can get around this by requesting a signature from Apple and stashing it, so you can always use the stashed version to downgrade, but that's it [01:49:26 CEST] <roman_> yeah im just doing macs no iphone [01:49:37 CEST] <thebombzen> Apple actively rejects supporting older versions of hte OS for new software [01:50:24 CEST] <roman_> also how do i get xcode [01:50:27 CEST] <roman_> do i need a developer account [01:50:33 CEST] <roman_> or do i just download it from the apple store [01:51:19 CEST] <roman_> or is there an alternative way to get command line tools to save me from downloading the 5gb file [01:51:39 CEST] <JEEB> it's available from either itunes or the developer downloads (just apple account, though). post-10.6 versions have been free so even if login is required it should be good enough to go [01:51:57 CEST] <JEEB> anyways, read up the documentation on the OS X/macos version you'll be supporting :P [01:55:04 CEST] <roman_> ok [01:55:07 CEST] <roman_> thank you guys [02:05:16 CEST] <roman_> one last question [02:05:19 CEST] <roman_> when installing the libs i need [02:05:21 CEST] <roman_> do i use homebrew [02:05:25 CEST] <roman_> or do i have to compile them manually too [02:28:30 CEST] <roman_> also JEEB how do i get xcode on an older version again? [02:46:49 CEST] <thebombzen> one last question [02:47:22 CEST] <thebombzen> roman_: it doesn't matter how you install dependencies but if you're planning on shipping builds of dynamic libraries you should probably build them yourself [02:47:25 CEST] <thebombzen> rather than homebrew them [02:49:09 CEST] <roman_> ok [02:49:12 CEST] <roman_> once again thank you [02:49:17 CEST] <roman_> and i figured out the xcode thank you [02:49:38 CEST] <roman_> one last thing [02:50:03 CEST] <roman_> if I am to comply with LGPL, all I have to do is ship binary, ship source tarball, and include a text file saying how I compiled it? thebombzen [02:50:57 CEST] <thebombzen> I am not sure exactly what is needed. I do know that if you dynamically link to an LGPLed library, your own code doesn't have to be LGPLed [02:51:47 CEST] <thebombzen> I believe that LGPLed libraries, if you distribute them, a source tarball, and a copy of the LGPL about them, with relevant copyright info that should be enough, but I Am Not A Lawyer and you should not take my word as the final say [02:52:28 CEST] <thebombzen> Perhaps you don't need to distribute a source tarball with the binaries but host a source tarball and provide a pointer to where a user can download them, but I do not know if this is sufficient. [02:52:45 CEST] <thebombzen> Before you publish your commerical product you should consult your lawyer about exactly what is necessary [03:23:07 CEST] <roman_> right [03:23:08 CEST] <roman_> thank you! [03:48:48 CEST] <rmbeer> hello [03:49:07 CEST] <rmbeer> i want playing a stream video in real time, how to playing with ffmpeg? [03:49:47 CEST] <kiroma> ffplay [03:58:03 CEST] <rmbeer> ok, i can't view with ffplay... [03:58:14 CEST] <rmbeer> the link is https://www.youtube.com/c/SolarLune/live [03:58:42 CEST] <rmbeer> and want view in other format with very low size, like 95 or 94 [04:46:24 CEST] <kittyfoots> hey guys, im seeing memory errors in valgrind in avcodec_decode_video2. Using ffmpeg 3.3.3 on ubuntu 16.04 via apt. Is there a version of ffmpeg where these errors are fixed? My program is occasionally crashing in the decoder and I've been going through it with a fine-tooth comb trying to suss out any potential issues, but the memory errors in ffmpeg are..problematic. [04:46:57 CEST] <kittyfoots> (im actually using the new decode api, but i guess it uses decode_video2 under the hood) [05:05:52 CEST] <timofonic> Hello [05:06:15 CEST] <timofonic> What's this? What advantages does it provide? Is it merged in ffmpeg? https://github.com/qeek-dev/ffmpeg_libyami/ [07:43:48 CEST] <thebombzen> is there any real harm in appending two of the same fps filters in a row [07:44:00 CEST] <thebombzen> suppose a script ends up producing a filterchain of fps=60,fps=60 [07:44:19 CEST] <thebombzen> similar with format=yuv420p10le,format=yuv420p10le [07:44:21 CEST] <thebombzen> is this bad? [07:45:40 CEST] <thebombzen> or is it relatively harmless [07:55:30 CEST] <timofonic> Anyone is under qemu/kvm/xen and wants GPU virtualization with Intel GPUs? I sent an email to the igvt-g mailing list. Anyone is interested on merging to upstream? https://lists.01.org/pipermail/igvt-g/2017-August/001262.html [07:55:35 CEST] <timofonic> OOs [07:55:40 CEST] <timofonic> Wrong channel! hAHA [07:55:42 CEST] <timofonic> Sorry [12:26:46 CEST] <ultrav1olet> could anyone comment on bug 6574? I smell something extremely wrong is going on but I don't understand what [12:30:31 CEST] <ultrav1olet> also since upload.ffmpeg.org is down, what's the best place to upload samples? [12:47:28 CEST] <ultrav1olet> ffmpeg from GIT exhibits the same problem :( [13:07:50 CEST] <BtbN> looks fine to me? [13:34:14 CEST] <nahsi> Anyone used mpdecimate? [13:36:31 CEST] <kepstin> thebombzen: in the particular cases you mentioned: Extra 'format' filters should be basically no-ops, extra fps filters will add some overhead but do nothing to the video, other filters? depends on the filter... [13:37:05 CEST] <thebombzen> I thought that this was approximately the case [13:37:33 CEST] <thebombzen> format requests from the previous filter, but I wasn't sure if libavfilter was smart enough to stack consecutive formats without inserting ,scale, between [13:37:57 CEST] <thebombzen> as for fps, I assumed there'd be some overhead, but I meant to the actual video [13:38:03 CEST] <thebombzen> but thanks for clearing that up that it's "safe" [13:38:43 CEST] <kepstin> if you can avoid the dup filters, i'd recommend doing that, just in case you end up adding one that's not "safe" at some point [13:39:36 CEST] <thebombzen> I have a segmented script, one of them necessarily spits out 60 fps video and the other one requires 60 fps video [13:40:02 CEST] <thebombzen> I want to be able to use each scripts independently so the first one just appends ,fps=60 and the second one prepends fps=60, [13:40:18 CEST] <thebombzen> I wasn't sure if this would actually change the video or just have a minor performance hit [13:40:21 CEST] <thebombzen> I can live with that [13:40:27 CEST] <thebombzen> but yea, it appears you cleared that up, thanks [14:17:16 CEST] <viric> Hello [14:17:51 CEST] <viric> I think that my camera records to MTS files adding some kind of "void-time" at the beginning, below 1 second [14:18:01 CEST] <viric> does anybody recall the MTS format having that thing? [15:27:35 CEST] <disappear> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks [17:26:33 CEST] <Bear10> I finally have a "workable" solution for my filter, I'm just wondering if someone knows how to create a AVFrame and read an image into it? [17:27:00 CEST] <Bear10> right now I'm doing AVFrame *out = in; (but I don't want to be referencing the in frame, or if I do I want to be completely removing it's current data and replacing it with a jpeg of my choice) [17:28:24 CEST] <Bear10> it's "somewhat" working when I use ff_load_image(...) and then copy it to the out with av_image_copy(...) but because it still has a lo of information from the original image it shows up with the wrong masks, and the old image still present [17:30:17 CEST] <pgorley> hi, is there another way to get the number of frames in an audio file than to count them one by one? [17:32:14 CEST] <pgorley> Bear10: https://www.ffmpeg.org/doxygen/trunk/group__lavu__frame.html#gaec4e92f6e1e7… [17:32:49 CEST] <pgorley> you could use av_frame_copy after allocating your output frame [17:32:59 CEST] <Bear10> pgorley: i tried that to no avail [17:33:51 CEST] <Bear10> I would actually get a segment fault when using this approach, but even then according to the method it copies the contents of data which is something I'm trying to avoid [17:35:02 CEST] <pgorley> so you want to replace the frame's image? [17:35:14 CEST] <Bear10> pgorley: correct [17:35:44 CEST] <Bear10> pgorley: so here's a pastebin of the idea basically https://pastebin.com/mZNJV9sD [17:35:49 CEST] <Bear10> line 45 you see the issue [17:36:00 CEST] <Bear10> with the current "approach" [17:37:16 CEST] <pgorley> do you want to apply a filter to the frame or do you want to load an image file into the frame? i'm confused [17:37:22 CEST] <Bear10> the latter [17:37:45 CEST] <pgorley> so why the filter? [17:38:00 CEST] <Bear10> it's the only way that occured to me to replace the data in the current overlay filter [17:38:53 CEST] <pgorley> you're using curl to save the image to disk, right? [17:39:15 CEST] <Bear10> pgorley: right now yes, in the future it might be memory but let's work off the assumption its on disk [17:40:47 CEST] <pgorley> https://github.com/jnicklas/ffmpeg_test/blob/master/test.c [17:41:11 CEST] <pgorley> that shows an example of using ff_load_image to get your file into an AVFrame [17:41:23 CEST] <Bear10> great! let's give that a shot! [17:44:43 CEST] <zerodefect> Looking for some help using the C-API. I have some decoded binary video data that I wish to encode. I'm guessing I need to allocate an AVFrame and set the pointers to the original data (instead of making a deep copy). Once I've passed the AVFrame to encoder, I'm concerned about data lifetime. How do I know that the encoder is finished with the input data? [17:47:46 CEST] <atomnuker> zerodefect: you don't just set the data pointers of each frame to the data you have [17:48:23 CEST] <atomnuker> avframes have an avbufferref which is what describes the buffer(s) backing the data planes [17:48:42 CEST] <atomnuker> there you have a callback which gets called once the encoder's done with the frame [17:49:13 CEST] <atomnuker> so you need to allocate avbufferrefs at each avframe allocation and fill in the structure including the release function pointer [17:49:36 CEST] <atomnuker> which is what'll get executed with the opaque context you give when making the avbufferref [17:50:04 CEST] <zerodefect> atomnuker: Terrific. I'll take a look. Thanks! [17:50:24 CEST] <atomnuker> it'll be from another thread too so make sure its threadsafe [17:50:58 CEST] <atomnuker> if you've got the file memmapped then the release function should do nothing [17:52:12 CEST] <atomnuker> (memmapping rules and people with small address space don't know what they're missing) [17:52:40 CEST] <zerodefect> atomnuker: Yeah, was about to ask about thread safety [18:01:20 CEST] <zerodefect> atomnuker: so once I've allocated AVFrame, do I set the AVFrame->buf[AV_NUM_DATA_POINTERS] with the allocated AVBufferRefs? [18:03:08 CEST] <atomnuker> yes, that's up to you [18:03:19 CEST] <atomnuker> keep in mind you generally only need 1 avbufferref [18:05:13 CEST] <zerodefect> Out of curiosity, is the size in the AVBufferRefs important? [18:05:15 CEST] <atomnuker> so you have 1 buffer with either planar or non-planar pixels, and your avbufferref will point to the base and the data planes in the avframe will point to offsets for each plane [18:05:27 CEST] <atomnuker> zerodefect: not really [18:06:32 CEST] <zerodefect> Yes, will use single AVBufferRef with planar pixels. Thanks again for your help :) [18:06:33 CEST] <atomnuker> so you only really need one avbufferref unless you have some crazy crazy file [18:06:41 CEST] <zerodefect> No, nothing crazy here [18:07:12 CEST] <atomnuker> (where you have like 30 frames of luma, then thirty frames of u and then 30 frames of v if your file has 30 frames) [18:07:35 CEST] <zerodefect> yeah, cool. [18:07:45 CEST] <atomnuker> rather than as standard where you have luma, u and v following (if you have a planar format) or a yuvyuvyuv or something else interleaved [18:17:27 CEST] <pgorley> could i call av_read_frame in a loop to count the number of frames in an audio file? [18:23:54 CEST] <DHE> depends what you mean by number of frames [18:27:58 CEST] <pgorley> DHE: i'm replacing sndfile with ffmpeg and i've got to replace SndfileHandle->frames() [18:28:53 CEST] <pgorley> .frames() sorry, though it shouldn't make a difference [18:29:53 CEST] <durandal_1707> yes, just make sure you do not leak frames [18:30:24 CEST] <DHE> just wondering if, depending on the file format, there's a better way that you could get from the AVFormatContext data after doing a guess-format [18:30:36 CEST] <DHE> it might lose some accuracy, but may be a lot faster [18:32:27 CEST] <pgorley> well there's AVStream->nb_frames but it's not always nonzero [18:32:47 CEST] <pgorley> counting the number of frames one by one is more of a backup method [18:35:50 CEST] <pgorley> durandal_1707: as long as i free the frame after av_read_frame it should be fine, right? [18:36:23 CEST] <durandal_1707> yes, i dont see the code though [18:37:12 CEST] <pgorley> haven't finished writing it yet [18:44:16 CEST] <pgorley> do i need to call avcodec_open2 before av_read_frame or can i skip that? [18:53:55 CEST] <DHE> reading a frame (raw data from container) does not require decoding capability [18:54:21 CEST] <DHE> it's a known misnomer that av_read_frame should probably be called av[format]_read_packet [19:00:13 CEST] <JEEB> yea [19:00:38 CEST] <JEEB> it is totally misleading [19:10:30 CEST] <pgorley> tools/pktdumper.c seems to do exactly what i need [19:12:09 CEST] <Lirk> hi [19:12:45 CEST] <Lirk> is there some input bitrate value for building expression? [19:13:04 CEST] <Lirk> input bitrate variable [19:21:07 CEST] <alexpigment> Lirk: you're better off using ffprobe to get the bitrate of a source video [19:21:13 CEST] <alexpigment> having said that, what is your goal? [19:21:59 CEST] <alexpigment> If you'd like to maintain a certain amount of quality without having to calculate the source bitrate, it's best to use -crf [20:33:49 CEST] <Mista_D> can FFmpeg add "Bit rate atom" to MP4 (btrt in MOOV https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… ) [20:36:20 CEST] <durandal_1707> open bug report [20:49:41 CEST] <Mista_D> Is there a GMANE alternative for FFmpeg mail list searching please? [20:50:58 CEST] <c_14> There's the archives, but not sure they're that searchable https://ffmpeg.org/pipermail/ffmpeg-devel/ [20:51:09 CEST] <c_14> You can check if google or whoever indexed them [20:52:17 CEST] <thebombzen> Mista_D: did you try going to ffmpeg.org/contact.html (which has the mailing list info) [20:52:48 CEST] <thebombzen> gg, never mind, there's something wrong haha [20:54:12 CEST] <thebombzen> I was going to suggest this button, but it's a 404. http://0x0.st/d2f.png [20:54:53 CEST] <Mista_D> Yeah, gmane's broken for last year or two... [20:57:42 CEST] <pgorley> how do i convert AVStream->duration to seconds? [20:57:50 CEST] <JEEB> timebase [20:58:22 CEST] <JEEB> time base is how many ticks is a single (second) [20:59:46 CEST] <pgorley> JEEB: so AVStream->duration * av_q2d(AVStream->time_base) ? [21:26:58 CEST] <DarkElement> Is there any way to get the quality of a video made from individual frames to match the quality of the individual frames? With ffmpeg [21:27:50 CEST] <DarkElement> I've been using this so far `ffmpeg -threads 8 -pattern_type glob -i "*.jpg" -vcodec libx264 -vb 20M 0_predictions.avi` on a bunch of images, however this is the original frame https://gyazo.com/43bdf55b928f946380d315b53b17352b and this is the resulting video https://gyazo.com/6f69c06ba9c78efef3a89789a4652d85, which is just worse enough to be annoying [21:32:12 CEST] <viric> How can I know what parameters does a codec want from AVCodecContext? [21:54:24 CEST] <RandomCouch> Hello, can someone tell me the difference between these 2 streams? [21:54:29 CEST] <RandomCouch> Stream #0:1(eng): Audio: aac (LC), 8000 Hz, mono, fltp [21:54:34 CEST] <RandomCouch> Stream #0:1(eng): Audio: aac (LC) ([64][0][0][0] / 0x0040), 8000 Hz, mono [21:59:06 CEST] <alexpigment> RandomCouch - is the second one 16-bit and the first one not? [21:59:27 CEST] <RandomCouch> I actually don't know lol, that's why I'm asking [21:59:30 CEST] <JEEB> it just doesn't say and to be honest, AAC doesn't have bitdepth when coding [21:59:37 CEST] <alexpigment> doesn't fltp (granted, I have no experience with this weird format) mean not 16-bit? [22:00:00 CEST] <JEEB> AAC is always decoded to float because that's the closest representation you can get from the lossy coding [22:00:34 CEST] <alexpigment> JEEB: then why does this post (and its reply) exist? https://stackoverflow.com/questions/32392571/how-to-make-sdl-play-fltp-samp… [22:00:35 CEST] <JEEB> anyways, that just looks like verbosity being different and whether the decoder was initialized or not [22:01:02 CEST] <JEEB> alexpigment: because not everything that takes in audio takes in floating point numbers [22:01:09 CEST] <JEEB> which is why you have resamplers [22:01:38 CEST] <JEEB> the lossily coded audio is decoded into floating point because that's the closest representation. if your next thing requires something else, you resample [22:02:17 CEST] <alexpigment> ok, well I guess I'll retire back to the shadows. the "FLTP" just stood out to me as being weird [22:02:58 CEST] <JEEB> my WASAPI audio API in windows takes in floating point numbers just fine (and most likely does a global mix in the end), and maybe some other audio API like SDL doesn't maybe support that? (although it seems like the copypasta'd example code specifically sets the format to AUDIO_S16SYS) [22:04:31 CEST] <JEEB> RandomCouch: basically according to those lines there's no difference [22:04:42 CEST] <RandomCouch> hm alright thanks [22:04:59 CEST] <JEEB> the most likely explanation for the difference in output (if that is the same version of ffprobe or so) is that there's container specific stuff there and that the decoder wasn't started in the latter? [22:05:11 CEST] <JEEB> but hte profile is the same LC [22:05:17 CEST] <JEEB> rate is same, 8000Hz [22:05:23 CEST] <JEEB> mono and mono [22:06:33 CEST] <BtbN> one is with the extradata info [22:06:45 CEST] <BtbN> so either the other doesn't have extradata, or it's not parsed yet [22:06:49 CEST] <JEEB> yes [22:08:25 CEST] <RandomCouch> hm alright, again, I'm still using ffmpeg on android lol, and on a Nexus 6 specifically, I try to merge 2 videos, when I playback the result video, the second part of it (which is the second video that got concatenated) has no audio, although I am transcoding the whole result video using aac [22:08:56 CEST] <RandomCouch> also using -bsf:a aac_adtstoasc for the result [22:10:33 CEST] <RandomCouch> I'm gonna try without the bitstream filter [22:21:56 CEST] <RandomCouch> Yeah it didn't change anything [22:51:42 CEST] <RandomCouch> Ahhh I finally fixed it! :D oh man I'm so happy [22:51:55 CEST] <RandomCouch> and I also realized how dumb I am to not have found the solution sooner [22:56:26 CEST] <ultrav1olet> I've found out that the scaler in ffmpeg generates very blurry output when downscaling the source. Is there a workaround or I've found an actual bug? [22:56:44 CEST] <JEEB> try zscale [22:56:55 CEST] <ultrav1olet> I've filed bug 6574 but perhaps I'm missing something [22:57:08 CEST] <JEEB> zscale requires https://github.com/sekrit-twc/zimg [22:57:13 CEST] <JEEB> and --enable-libzimg [22:57:38 CEST] <JEEB> otherwise it has a very similar command interface filter-wise to the scale filter [22:57:46 CEST] <BtbN> I still think your downscaled image looks perfectly fine. [22:58:02 CEST] <ultrav1olet> compare source.png and result.png [22:58:12 CEST] <ultrav1olet> the difference is staggering [22:58:38 CEST] <JEEB> if zimg produces something similar, then either zimg is wrong or your expectations are wrong [22:59:12 CEST] <ultrav1olet> his chain armour is completely destroyed [22:59:41 CEST] <DHE> you could also compare different algorithms. lazncos (sp?) is worth giving a shot [22:59:45 CEST] <BtbN> the images are the same size [22:59:50 CEST] <BtbN> Did you scale it down and back up? [22:59:57 CEST] <ultrav1olet> also look at his left cheek - the result is smooth and the texture is lost [23:00:37 CEST] <durandal_1707> nice guy [23:00:57 CEST] <ultrav1olet> just downscaled [23:01:09 CEST] <BtbN> oh, both are downscaled [23:01:11 CEST] <ultrav1olet> did nothing else [23:01:15 CEST] <ultrav1olet> exactly [23:01:16 CEST] <BtbN> Yeah, try one of the other scalers [23:01:29 CEST] <BtbN> zimg is said to be very good [23:01:40 CEST] <BtbN> no idea what algorithm sws uses [23:01:42 CEST] <ultrav1olet> I think the problem is not in the type of scaler but in something else [23:02:02 CEST] <ultrav1olet> mplayer/Xv uses a very basic scaler and it looks miles better [23:02:06 CEST] <BtbN> https://ffmpeg.org/ffmpeg-scaler.html [23:02:12 CEST] <BtbN> default is bicubic it seems [23:02:26 CEST] <BtbN> set it to lanczos for a test [23:02:43 CEST] <ultrav1olet> I've already tried lanczos [23:03:01 CEST] <ultrav1olet> In fact I've always used it until yesterday when I discovered this bug [23:03:28 CEST] <BtbN> lanczos really shouldn't produce results like this [23:03:57 CEST] <ultrav1olet> does this look correct? -vf scale=768x342 -sws_flags lanczos [23:05:07 CEST] <ultrav1olet> lanczos looks almost exactly like result.png [23:05:40 CEST] <JEEB> anyways, I recommend testing with zscale [23:07:19 CEST] <BtbN> I think it's -vf scale=w=1234:h=1234:flags=lanczos ? [23:08:27 CEST] <JEEB> -vf "zscale=w=768:h=342,format=gbrp" [23:08:31 CEST] <JEEB> with zscale, IIRC [23:09:24 CEST] <JEEB> since you have to hint what you want as output with the format pseudo-filter [23:09:54 CEST] <ultrav1olet> -vf scale=w=1234:h=1234:flags=lanczos ? => the same result [23:10:15 CEST] <JEEB> unsurprising [23:12:30 CEST] <ultrav1olet> JEEB: why " [23:12:31 CEST] <ultrav1olet> gbrp [23:12:33 CEST] <ultrav1olet> force planar RGB output [23:12:34 CEST] <ultrav1olet> ? [23:13:34 CEST] <ultrav1olet> and it doesn't work: code 3074: no path between colorspaces [23:14:01 CEST] <JEEB> you don't have colorspace information in your input then [23:14:09 CEST] <JEEB> for YCbCr at the minimum you need... [23:14:41 CEST] <JEEB> min [23:14:52 CEST] <JEEB> if it's bt.709 set min=bt709 [23:15:07 CEST] <ultrav1olet> zscale without options produces the same blurry result [23:15:08 CEST] <JEEB> if it's 470bg you set min=bt470bg [23:15:27 CEST] <ultrav1olet> my source is yuv420p [23:15:29 CEST] <JEEB> ok, then most likely your expectations are wrong. if you truly believe you're right file a bug in zimg [23:15:46 CEST] <JEEB> ultrav1olet: yes but there's different colorspaces even within YCbCr [23:15:55 CEST] <ultrav1olet> Why mplayer/Xv works miles better without using any special algorithms? [23:15:56 CEST] <JEEB> matrix etc [23:16:16 CEST] <ultrav1olet> I smell something is terribly wrong with ffmpeg [23:16:34 CEST] <ultrav1olet> like it applies some additional filter after scaling [23:16:41 CEST] <ultrav1olet> gauss maybe [23:16:47 CEST] <JEEB> if zscale gives you issues then if there was an issue it'd be in zimg as well [23:17:01 CEST] <JEEB> feel free to make an issue in zimg if you want, that's used by multiple professional pieces of software [23:17:24 CEST] <JEEB> (because the license is very liberal etc) [23:17:37 CEST] <JEEB> in addition to as far as I know Very Correct [23:17:54 CEST] <JEEB> that's why it doesn't let you convert YCbCr to RGB when you don't have any color metadata, either :P [23:17:55 CEST] <ultrav1olet> ffmpeg's output is not indicative of using any filters - is this how it works? [23:18:16 CEST] <JEEB> there most likely are no magical filters in the middle [23:18:30 CEST] <JEEB> make an issue with zimg if you want a 3rd party opinion unrelated to FFmpeg [23:18:31 CEST] <JEEB> :P [23:20:22 CEST] <ultrav1olet> are there any applications using z.lib other than ffmpeg? I cannot find any [23:20:35 CEST] <JEEB> in open source vapoursynth is one [23:21:33 CEST] <JEEB> there's also contributions from netflix related people so according to discussions I've had IRL they're using it as well [23:21:58 CEST] <JEEB> closed source software doesn't have to advertise zimg so (Ž4@) [23:23:24 CEST] <JEEB> and /34 [23:23:32 CEST] <BtbN> I somehow have doubts about this being a scaling issuer [23:23:34 CEST] <BtbN> -r [23:23:45 CEST] <BtbN> I just can't imagine swscale being that bad [23:23:53 CEST] <BtbN> specially with other algorithms [23:24:41 CEST] <ultrav1olet> the source is yours [23:24:47 CEST] <ultrav1olet> the result is all yours [23:24:53 CEST] <ultrav1olet> I'm using ffmpeg from GIT [23:24:58 CEST] <ultrav1olet> it is that bad [23:25:08 CEST] <BtbN> Yes, but I suspect it's not the scaler making it bad [23:25:12 CEST] <ultrav1olet> I can upload the source PNG if you're interested [23:25:23 CEST] <ultrav1olet> to make your life easier [23:25:41 CEST] <JEEB> also when using FFmpeg's API there's a function in libavfilter to dump a "graphical" representation of the libavfilter filter chain, not sure if there's a command line parameter to do it too [23:26:06 CEST] <JEEB> http://up-cat.net/p/cbfdf4f9 [23:26:09 CEST] <BtbN> Yeah, attach it to the ticket. Would be very handy to have. And once carl finds the ticket, he will demand it anyway. [23:26:43 CEST] <ultrav1olet> I've posted a link to a source video ;-) [23:27:05 CEST] <JEEB> avfilter_graph_dump [23:27:09 CEST] <JEEB> let's see if that's used anywhere [23:27:42 CEST] <ultrav1olet> https://image.ibb.co/i2XXuv/source1080p.png [23:28:14 CEST] <JEEB> meh, ok. seems like ffmpeg.c doesn't have a way of calling that dumper [23:28:25 CEST] <JEEB> that would have just made it 100% clear what sort of filter chain ffmpeg.c is creating [23:28:30 CEST] <JEEB> although -v debug should also tell you [23:28:39 CEST] <JEEB> albeit in less straightforward terms [23:28:49 CEST] <JEEB> (although not like the "dump" is visually well readable) [23:28:58 CEST] <BtbN> The -f lavfi format as output should be able to do it [23:29:31 CEST] <JEEB> if it's like the graph I posted then that should be OK [23:29:31 CEST] <ultrav1olet> I've just used resize in the simplest image editor and the result is better than what ffmpeg generates [23:29:38 CEST] <BtbN> It calls that function [23:30:00 CEST] <BtbN> Hm, but it's only the lavfi demuxer [23:30:06 CEST] <BtbN> Can't act as output [23:31:04 CEST] <ultrav1olet> -v debug gives it all [23:31:22 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] Setting 'w' to value '768x342' [23:31:29 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] Setting 'flags' to value 'lanczos' [23:31:35 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] w:768 h:342 flags:'lanczos' interl:0 [23:31:52 CEST] <ultrav1olet> what is [graph 0 input from stream 0:0 @ 0x93e10a0] Setting 'sws_param' to value 'flags=2' ? [23:33:20 CEST] <JEEB> I would guess 2 is "lanczos" [23:33:44 CEST] <JEEB> internal values, ho [23:34:15 CEST] <ultrav1olet> this is madness. [23:34:25 CEST] <ultrav1olet> When I encode an image alone the result is perfect. [23:34:44 CEST] <ultrav1olet> When I downscale the source video the result is horrible. [23:34:46 CEST] <JEEB> anyways, I'd be more interested in the dump of the filtering chain with zscale because the role with the automated scale filter should only be doing GBRP to RGB24 [23:36:02 CEST] <JEEB> basically to check if the automated scale filter is doing anything else than bgrp->rgb24 or so, in which case it just packs the planar values [23:36:16 CEST] <JEEB> (I thought about adding libp2p support into zscale but :eff:) [23:36:47 CEST] <ultrav1olet> https://pastebin.com/Rus7VAWH [23:37:12 CEST] <ultrav1olet> raw https://pastebin.com/raw/Rus7VAWH [23:39:37 CEST] <JEEB> ok, so in this case there shouldn't even be an auto-inserted scale filter since planar 4:2:0 can be gotten from zimg [23:39:46 CEST] <JEEB> [Parsed_zscale_0 @ 0x59086c0] w:1920 h:800 fmt:yuv420p sar:1/1 -> w:768 h:342 fmt:yuv420p sar:171/160 [23:40:52 CEST] <JEEB> have you by chance tried a resolution that is 1:1 SAR on the output side as well? or setting ",setsar=1" after zscale to tell the encoder to not set aspect ratio data? [23:41:40 CEST] <JEEB> anyways, if you think this is incorrect then just make a ticket on zimg's side btw [23:41:50 CEST] <JEEB> this is now 100% zimg [23:42:21 CEST] <ultrav1olet> JEEB: why there's no bug when encoding a single image? [23:42:30 CEST] <JEEB> with scaling? [23:42:33 CEST] <ultrav1olet> yep [23:42:39 CEST] <JEEB> as image or as H.264? [23:42:46 CEST] <ultrav1olet> I'm 100% sure the problem is not with zscaler but with some additional filter ffmpeg applies [23:42:53 CEST] <ultrav1olet> as a PNG image [23:43:17 CEST] <JEEB> ok, so in that case RGB [23:43:35 CEST] <JEEB> you can output RGB with libx264 if you want [23:43:53 CEST] <ultrav1olet> color space or not, blurriness stems from something completely different [23:44:03 CEST] <ultrav1olet> since I'm encoding at crf=0 [23:44:20 CEST] <ultrav1olet> um [23:44:33 CEST] <ultrav1olet> that makes me thinking, what if the x264 is the culprit [23:44:44 CEST] <BtbN> try some other encoder [23:44:45 CEST] <ultrav1olet> I must try another codec [23:44:52 CEST] <JEEB> try utvideo for example [23:45:01 CEST] <JEEB> supports both YCbCr and RGB [23:45:06 CEST] <JEEB> into, say, avi [23:45:10 CEST] <ultrav1olet> does MPEG2 have a lossless mode? [23:45:14 CEST] <JEEB> no [23:45:29 CEST] <JEEB> -c:v utvideo and check with mpv [23:45:38 CEST] <JEEB> (least retarded opengl renderer around) [23:46:21 CEST] <BtbN> might also be the player you used to look at the video [23:46:29 CEST] <BtbN> x264 with -crf 0 should really not touch the picture at all [23:47:03 CEST] <ultrav1olet> Stream #0:0: Video: utvideo (ULY0 / 0x30594C55), yuv420p - blurriness persists [23:47:21 CEST] <JEEB> and ut video doesn't do any bullshit [23:47:29 CEST] <ultrav1olet> the problem is with ffmpeg itself [23:47:33 CEST] Action: JEEB wrote the encoder back in the day [23:47:44 CEST] <ultrav1olet> and only when encoding videos and _not_ single images [23:47:52 CEST] <JEEB> try with RGB and ut video :P [23:48:03 CEST] <ultrav1olet> What's the command? [23:48:18 CEST] <ultrav1olet> I suck at remembering ffmpeg's options [23:48:36 CEST] <JEEB> "<zscale>,format=gbrp" should be enough I think [23:48:45 CEST] <JEEB> zscale part being the zscale scaling [23:49:00 CEST] <ultrav1olet> doesn't work as I said earlier [23:49:13 CEST] <ultrav1olet> code 3074: no path between colorspaces [23:49:14 CEST] <JEEB> that's because your input lacks colorspace information then [23:49:18 CEST] <JEEB> set min as well [23:49:25 CEST] <JEEB> to either bt709 or bt470bg [23:49:29 CEST] <ultrav1olet> treat me as a stupid please [23:49:30 CEST] <JEEB> according to your source's information [23:49:33 CEST] <JEEB> ok [23:49:35 CEST] <JEEB> zimg is anal [23:49:43 CEST] <JEEB> if you don't have required data about what sort of YCbCr it is [23:49:51 CEST] <JEEB> it will barf at you [23:49:54 CEST] <ultrav1olet> actually the source is all yours: https://mega.nz/#!bp0jwCoJ!--QLIwVLvDnFfNWdVyYH6zkE0pUApN6tjhVNq0xylPc [23:49:55 CEST] <JEEB> the one value it at the very least needs [23:50:00 CEST] <JEEB> is min [23:50:09 CEST] <JEEB> if it's from blu-ray or something set min=bt709 [23:50:11 CEST] <JEEB> :P [23:50:27 CEST] <JEEB> which sets the input color matrix to BT.709 [23:51:28 CEST] <JEEB> FFmpeg's swscale is happy to do the guessing for you, while zimg is made to stop you from doing stuff you don't think you're doing [23:52:16 CEST] <BtbN> ultrav1olet, https://btbn.de/public/scrn/1502229107.png [23:52:42 CEST] <BtbN> this is generated with: ffmpeg.exe -i source.mkv -vf scale=768:-2 -c:v utvideo result.mkv [23:53:05 CEST] <ultrav1olet> BtbN: yours looks exactly how it should be [23:53:19 CEST] <JEEB> just out of interest, which player are you using for preview? :P [23:54:02 CEST] <BtbN> ultrav1olet, https://btbn.de/public/scrn/1502229220.png this is what I get when using your resolutions [23:54:04 CEST] <ultrav1olet> MPV [23:54:04 CEST] <BtbN> same blur [23:54:16 CEST] <ultrav1olet> sorry, mplayer [23:54:22 CEST] <BtbN> you are just breaking aspect ratio, and the stretching is what causes the blurr [23:54:44 CEST] <JEEB> mplayer is completely different, and yes - that's why I noted setsar [23:54:51 CEST] <JEEB> if the aspect ratio compensation was causing it :P [23:55:00 CEST] <ultrav1olet> both MPV and mplayer produce the same result here [23:55:06 CEST] <JEEB> since when you code a picture most image formats don't have a way of coding that in [23:55:12 CEST] <JEEB> while video formats have aspect ratio flags [23:55:22 CEST] <JEEB> and your output resolution was 170/160 or so [23:55:30 CEST] <ultrav1olet> BtbN: I used your command right now - the same blurriness [23:55:30 CEST] <JEEB> so it asks the player to widen it a wee bit [23:56:09 CEST] <ultrav1olet> BtbN: could you upload your result.mkv? [23:56:33 CEST] <BtbN> of what? [23:56:34 CEST] <BtbN> with -2? [23:56:37 CEST] <ultrav1olet> yep [23:56:51 CEST] <ultrav1olet> is the screenshot you've just posted is from it [23:56:54 CEST] <ultrav1olet> if [23:57:16 CEST] <JEEB> if you want to ignore input aspect ratio add ",setsar=1" at the end of your filter chain [23:57:24 CEST] <ultrav1olet> I don't see how I'm stretching anything guys [23:57:30 CEST] <JEEB> during playback [23:57:37 CEST] <ultrav1olet> I'm watching the result as is without upscaling it [23:57:38 CEST] <JEEB> I saw in your logs sar 170/160 [23:57:55 CEST] <JEEB> so the player should automagically scale according to aspect ratio [23:57:57 CEST] <JEEB> which is a bit wider [23:58:05 CEST] <BtbN> You're scaling to 768x342 [23:58:15 CEST] <BtbN> the correct downscale is 768x320 though [23:58:18 CEST] <ultrav1olet> yeah: source: Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default) [23:58:22 CEST] <BtbN> if you want to keep aspect ratio [23:58:24 CEST] <JEEB> that's the input [23:58:29 CEST] <JEEB> https://pastebin.com/raw/Rus7VAWH [23:58:31 CEST] <ultrav1olet> result: Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 768x342 [SAR 171:160 DAR 12:5], q=-1--1, 23.98 fps, 1k tbn, 23.98 tbc (default) [23:58:34 CEST] <JEEB> 768x342 [SAR 171:160 DAR 12:5] [23:58:47 CEST] <JEEB> yes, so the players will apply aspect ratio fixing [23:58:54 CEST] <ultrav1olet> so what am I doing wrong and how I can avoid this problem in the future? [23:58:55 CEST] <BtbN> Just put -2 as one of the parts of the scale, and it will pick the correct one [23:58:57 CEST] <JEEB> that explains why image formats were OK [23:59:08 CEST] <JEEB> because those don't have a flag for SAR/DAR [23:59:09 CEST] <JEEB> usually [23:59:10 CEST] <ultrav1olet> -2 generates the same blurry file [23:59:10 CEST] <JEEB> :P [23:59:25 CEST] <BtbN> https://btbn.de/public/result.mkv [23:59:32 CEST] <ultrav1olet> (ffmpeg -i source.mkv -vf scale=768:-2 -c:v utvideo result.mkv) [23:59:45 CEST] <BtbN> That's the exact commandline I used to generate that [23:59:49 CEST] <BtbN> no blur for me at all [23:59:58 CEST] <JEEB> check the command line output [00:00:00 CEST] --- Wed Aug 9 2017

1 0

ffmpeg-devel.log.20170807
by burek 08 Aug '17

08 Aug '17

[12:19:41 CEST] <durandal_1707> is there a flag for fate to automatically update checksums? [12:26:16 CEST] <J_Darnley> GEN=1 [12:26:41 CEST] <J_Darnley> It will use the results as the new reference values. [12:40:59 CEST] <J_Darnley> Now on an unrelated topic... [12:43:41 CEST] <J_Darnley> actually ignore that for now [12:52:38 CEST] <funman> maybe to test scatter/gather, dunno [12:52:56 CEST] Action: funman looks for his shell [13:16:47 CEST] <J_Darnley> Has anyone here ever started work on writing code to allow avcodec to encode anything less than a whole frame? [13:17:04 CEST] <J_Darnley> Or do you know of similar work elsewhere? [13:18:47 CEST] <J_Darnley> Perhaps someone had a use for separated fields? [13:23:52 CEST] Action: J_Darnley thinks he should send an email to the ML [13:35:51 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:5621a99e2751: avfilter/drawutils: support gbrap10 too [13:35:51 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:ab6d89d7ee5c: libavutil: add GRAY9 pixel format [13:35:51 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:de48710c11ce: libswscale: add gray9 support [13:35:51 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:7bfbc2d787a4: avfilter/vf_extractplanes: add 9 bitdepth support [13:35:51 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:86222a7ea071: avfilter/vf_waveform: add support for 9 bit depth lowpass [13:35:52 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:bac508fec1c4: avfilter: add support for GRAY9 and GBRAP10 [13:36:48 CEST] <durandal_1707> J_Darnley: thats bad idea [13:37:11 CEST] <J_Darnley> :) which bit in particular? [13:37:29 CEST] <durandal_1707> encoding fields [13:37:38 CEST] <J_Darnley> It sure is. [13:37:53 CEST] <JEEB> I don't know, the only problem is that the rest of things don't really check if they're getting a field or frame [13:37:57 CEST] <JEEB> they just take a picture in/out [13:38:09 CEST] <JEEB> like I think yadif et al currently fail with HEVC [13:38:21 CEST] <JEEB> because the HEVC decoder outputs field pictures [13:38:29 CEST] <JEEB> if the video is field coded [13:38:34 CEST] <J_Darnley> Forget about the fields then [13:38:57 CEST] <J_Darnley> I want to pass 16 lines to an encoder and get 16 lines out almost immediately. [13:39:43 CEST] <J_Darnley> But separated fields would a half-decent, real-world example. [13:40:26 CEST] <J_Darnley> Anyway, I'm going to lunch [14:01:49 CEST] <J_Darnley> Maybe I shouldn't mention fields. It always triggers people who hate interlacing, like me. [14:16:14 CEST] <JEEB> don't worry, it happens to the best of us [15:11:37 CEST] <kierank> J_Darnley: i would say just see if you can get vc2enc to accept it, forget about other encoders and forget about fate [15:14:21 CEST] <J_Darnley> Sure, I wouldn't expect to solve it for every encoder [15:14:39 CEST] <J_Darnley> but I have no idea where to even begin with that "small" task [15:14:57 CEST] <J_Darnley> I have no idea how data goes from outside to inside the encoder. [15:15:58 CEST] <J_Darnley> Even some shitty hack will need a minimum of support from the rest of the API otherwise you won't even be able to compile [15:17:32 CEST] <J_Darnley> ^^ or then how data goes from inside to back outside [15:22:39 CEST] <kierank> J_Darnley: did you see https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/encode_video.c… [15:23:07 CEST] <kierank> try it with vc2 set to encode to 1920x1080 [15:23:13 CEST] <kierank> send avframes of 32x8 or whatever [15:23:17 CEST] <J_Darnley> No. I have no such file. [15:23:17 CEST] <kierank> and then see where it gets rejected [15:23:28 CEST] <kierank> that's the example for encoding video [15:23:58 CEST] <J_Darnley> Oh dammit. I'm still on atomnuker's ancient dirac branch [15:25:47 CEST] <J_Darnley> I expect that so call encode_frame of vc2enc many more times than 24 [15:26:04 CEST] <J_Darnley> Which I expect to produce ribbush [15:26:09 CEST] <J_Darnley> *rubbish [15:26:24 CEST] <BBB> J_Darnley: about x264, yes at some point it had slice threading [15:26:31 CEST] <BBB> J_Darnley: it was replaced with frame threading at some point [15:26:46 CEST] <BBB> J_Darnley: if you read their threading docs theyll point you to the exact commits [15:28:50 CEST] <J_Darnley> Yes, thank you for helpful comment. /s [15:29:23 CEST] <J_Darnley> I clearly cannot explain myself [15:32:25 CEST] <BBB> J_Darnley: about libavcodec, I dont think we have API to input less than a frame; we have decoder API for that (avctx->draw_horiz_band()), but I Dont believe we have encoder API for that [15:32:34 CEST] <BBB> (assuming you want to reduce latency) [15:32:54 CEST] <J_Darnley> Yes, that is kierank's goal [15:32:57 CEST] <BBB> I dont tihnk its particularly hard to model the encoder API to optionally be like avctx->draw_horiz_band [15:33:15 CEST] <BBB> (in special/limited use cases) [15:33:39 CEST] <BBB> so this isnt something generic that would be available for all encoders, just a small limited subset that set a special flag and are opened with a special option set etc. [15:34:34 CEST] <BBB> and then the internal implementation of that in the encoder (in terms of load balancing between threads - or even whether threading is enabled at all) is entirely up to the encoder, i.e. up to you [15:34:59 CEST] <BBB> (i.e. feed_horiz_band and slice threading are entirely independent of each other, although youd probably want to use both in most typical use cases) [15:35:14 CEST] <BBB> (or maybe not, hard to say without knowing the use case :) ) [15:36:24 CEST] <J_Darnley> Sounds close enough to me. [15:38:15 CEST] <J_Darnley> I don't know what I can and can't talk about here but I think I can say that lowering the latency is the goal. [15:44:20 CEST] <iive> won't it be easier to use an existing codec that already has slices support? [15:45:38 CEST] <iive> and rtp already has a ton of crap to work on slice level. [15:46:40 CEST] <J_Darnley> I have no idea. [15:47:29 CEST] <kierank> I just want to encode slices as they arrive [15:47:33 CEST] <J_Darnley> Isn't rtp a muxer or protcol? Just how does that relate to an encoder. [15:48:47 CEST] <kierank> I would ignore those weird ones [15:49:44 CEST] <iive> if you want to avoid patents, then mpeg1/2 should be ideal, as they should have expired already. [15:50:12 CEST] <iive> real time protocol, network transmission. [15:51:18 CEST] <iive> an old one. rtsp is based on top of it. [16:04:05 CEST] <J_Darnley> Ugh. The encode_video example doesn't appear to work. [16:04:21 CEST] <J_Darnley> At first it was flat grey so I hiked up the bitrate [16:04:53 CEST] <J_Darnley> Now ffplay only shows 1 frame. [16:06:42 CEST] <J_Darnley> I guess I should check whether ffmpeg does it any better. [16:18:43 CEST] <J_Darnley> No, it isn't. [16:19:10 CEST] <J_Darnley> Now is that because the bitstream cannot code more than 1 image? [16:19:25 CEST] <J_Darnley> *raw bitstream [16:20:00 CEST] <J_Darnley> Does the demuxer just not like it? [16:33:18 CEST] <BBB> I think encode_video doesnt mux [16:33:24 CEST] <BBB> so it doesnt work for all use cases [16:34:05 CEST] <J_Darnley> Yeah, you only give an encoder name. [16:47:40 CEST] <kierank> raw vc2 should work [16:52:53 CEST] <J_Darnley> So clear up confusion: Neither ffmpeg or encode_video can produce a raw vc2 bistream that ffplay can play more than just the first frame. [16:56:41 CEST] <kierank> J_Darnley: it's should work [16:56:48 CEST] <durandal_170> J_Darnley: no parser? [16:57:08 CEST] <J_Darnley> I don't know, don't care. I might have to care later. [18:21:40 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:181c9abd47cb: avfilter/vf_premultiply: add inplace mode [18:41:15 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:1bef0088dce7: avfilter/drawutils: add gray9/10/12 support [18:48:02 CEST] <J_Darnley> Hacking doc/examples/encode_video was not very instructive. [18:48:48 CEST] <J_Darnley> Allocating full size frames gets gets the encoder encoding zeros after the initial band drawn in the example [18:49:37 CEST] <J_Darnley> Allocating less than the full frame results in a segfault becauce the encoder doesn't check the height of the given frame. [18:49:47 CEST] <J_Darnley> The first is hardly surprising. [18:50:19 CEST] <J_Darnley> I guess the second shows that there isn't some check hidden away somewhere rejecting frames. [19:03:18 CEST] <kierank> J_Darnley: that's good [19:03:41 CEST] <kierank> if you add your own x, y position stuff in AVFrame then you can do things [20:35:39 CEST] <durandal_170> vdd open sauce [20:35:56 CEST] <BBB> if its free, it must be bad [20:36:17 CEST] <BBB> you should come though [20:36:18 CEST] <BBB> :-p [20:36:22 CEST] <BBB> [tm] [20:36:38 CEST] <J_Darnley> Open Sores! [20:37:29 CEST] <durandal_170> what will be presented this year? [20:39:30 CEST] <BBB> Id like to do something with vp9 [20:39:33 CEST] <BBB> but I dont know what yet [20:40:21 CEST] <durandal_170> vp9? there is nothing new, everything is known [20:40:46 CEST] <BBB> one test says its 30% worse than x265, another says its 10% better [20:40:48 CEST] <BBB> which test is right? [20:41:00 CEST] <durandal_170> neither [20:41:03 CEST] <BBB> :-p [20:42:39 CEST] <durandal_170> yea do vmaf/psnr/ssim comparison of various derf samples, once it finish encoding [20:46:52 CEST] <kierank> J_Darnley: want to present at VDD like BBB said before? [20:47:44 CEST] <J_Darnley> Present what? mmpeg2 stuff? Not really. [20:47:56 CEST] <kierank> k [20:48:12 CEST] Action: J_Darnley sighs [20:48:18 CEST] <durandal_170> make some asm workshop with vlc guys [20:48:33 CEST] <J_Darnley> I still didn't start the third part of the blog post series. [20:49:55 CEST] <BBB> I can also do something about x86inc.asm/x264asm [20:50:08 CEST] <BBB> but I fear that it would have very limited interest for most people [20:50:19 CEST] <BBB> most people like asm as long as someone else writes it [20:59:36 CEST] <kierank> J_Darnley: no rush [21:27:38 CEST] <atomnuker> BBB: talk about how its the best puzzle game and its a shame newspapers don't put SIMD problems next to crosswords [21:28:54 CEST] <kierank> lol [21:29:00 CEST] <atomnuker> people just need to get hooked up with it once to know its crack cocaine and soon they'll be running out of complex functions to simd [21:29:28 CEST] <BBB> intel will just come up with wider registers and newer strange instruction names [21:29:37 CEST] <BBB> vphfksjdnklrelnzxsw [21:29:42 CEST] <BBB> it does magic things [21:29:57 CEST] <BBB> how to abuse this magic new instruction to make your function 10% faster? [21:30:03 CEST] <BBB> read about it next week @ VDD! [21:30:12 CEST] <RiCON> wouldn't be surprised if that's actually a real name now or in the future [21:31:01 CEST] <kierank> atomnuker: does that make me your drug dealer? [21:31:43 CEST] <atomnuker> yep, yes it does [21:31:48 CEST] <BBB> ... [21:31:56 CEST] <kiroma> I joined this channel to see how professional programmers write code to a big project [21:32:09 CEST] <JEEB> welcome to open source [21:40:24 CEST] <jamrial> BBB: it does magic things, but takes alone 5x as much time to finish than the combination of 10 separate intructions that together do the same thing [21:41:43 CEST] <jamrial> see sse4 dpps, or avx2 vgather [21:41:53 CEST] <jamrial> it seems to be the norm for anything past ssse3 :p [21:42:02 CEST] <BBB> I like avx2 [21:42:13 CEST] <BBB> pmovz/sx* are quite useful [21:42:18 CEST] <BBB> even if they arent exactly novel [21:42:51 CEST] <BBB> I wish we had more variants like pmulhrsw [21:42:57 CEST] <jamrial> it's neat, yes [21:42:58 CEST] <BBB> e.g. a rounded shift from dword to word would be very useful [21:43:14 CEST] <atomnuker> jamrial: dpps seems crazy, why is there even a need for a mask argument? [21:43:30 CEST] <BBB> like paddd a, [something], paddd b, [something], psrad a, something, psrad b, something, packssdw,a, b [21:43:30 CEST] <atomnuker> this could be just a mulps and an andps [21:43:45 CEST] <BBB> I bet you could do that in a single call like pmulhrsw [21:44:07 CEST] <BBB> (in a more limited sense would be fine, e.g. just rounded shift by a fixed integer number without the multiply would be fine) [21:44:15 CEST] <jamrial> i have no idea, never used it. just read a blog post of someone trying to implement it and finding that it's just too slow compared to using a combination of other instructions. just like vgather on anything pre skl-x [21:44:47 CEST] <jamrial> BBB: yeah, a instruction like that could be used for example in jpeg2000dsp [21:44:48 CEST] <atomnuker> is it actually faster than doing it individually on skl-x? [21:45:02 CEST] <BBB> an instruction like that could be used anywhere [21:45:03 CEST] <atomnuker> still waiting on agner fog's to see what skl-x does good [21:45:05 CEST] <BBB> it would be hugely useful [21:45:08 CEST] <jamrial> gather is fast only in skl-x [21:45:16 CEST] <BBB> but intel dont listen to me [21:46:25 CEST] <jamrial> they are busy adding weird instructions for deep learning [21:47:09 CEST] <BBB> deep learning is the 2020 version of lomoso [21:48:17 CEST] <BBB> apparently its SoLoMo, not LoMoSo (anyway...) [22:09:11 CEST] <Gramner> atomnuker: official skl-x instruction latencies and throughput are release. it's missing some stuff and other things are outright wrong, but still [22:10:07 CEST] <Gramner> the best one is vpconflictd with zmm regs. it's 67/17.5 [22:10:42 CEST] <Gramner> https://software.intel.com/sites/default/files/managed/ad/dc/Intel-Xeon-Sca… [22:12:29 CEST] <atomnuker> vgathers don't seem much better, they just have halved throughput compared to sklylake [22:13:30 CEST] <Gramner> gathers have fine throughput. they just have a bunch of extra latency over doing individual loads for who knows what reason [22:14:25 CEST] <atomnuker> I bet its wasting time doing the mask [22:15:37 CEST] <atomnuker> the fact it modifies it to return error status is particularly wrong [22:15:49 CEST] <iive> What?! [22:16:30 CEST] <Gramner> it's implemented in the most sensible way [22:17:05 CEST] <Gramner> how else would you do it efficiently in a way that's compatible with x86 fault semantics? [22:17:50 CEST] <atomnuker> it already triggers a segfault on out of bounds indices [22:18:50 CEST] <Gramner> page faults are the relevant fault type for gathers [22:19:13 CEST] <Gramner> segfaults are irrelevant. it can take another million cycles if that happens and nobody would care [22:20:28 CEST] <atomnuker> page faults? as in the soft faults when the page you need to load from is only on ram atm or something? [22:20:31 CEST] <Gramner> if you do a gather of 16 elements and hit a page fault on the 15:th, the OS will handle the page fault and restart the instruction. but you obviously don't want to have to redo the already completed 13 elements which is why the mask is updated to reflect that they have already been gathered [22:20:49 CEST] <Gramner> 14* [22:21:33 CEST] <iive> Gramner: given how much cycles a page fault takes to be handled, that would be irrelevant. [22:22:24 CEST] <atomnuker> aren't page faults only relevant if you're running starting to run out of CPU? [22:22:35 CEST] <Gramner> and I doubt updating a bitflag takes 20 cycles [22:22:35 CEST] <iive> you mean ram [22:23:10 CEST] <iive> and that could involve waiting for HDD. [22:33:52 CEST] <Gramner> anyway, I really doubt that gathers are slow due to how the instruction is defined. it's most likely just a suboptimal implementation (they have been made faster every cpu generation since they were introduced) [22:34:35 CEST] <Gramner> it wouldn't surprise me if they ignore L1 and just go straight for L2 or something [22:40:46 CEST] <Gramner> more interesting things about SKL-X is that some instruction latencies varies depending on which port they execute on. zmm floating-point ops and multiplies for example have 4 cycles latency on p0 but 6 cycles on p5 [22:42:42 CEST] <Gramner> also vpermw et. al are a lot slower than dword and qword equivalents. I'm guessing that will get improved at the same time as avx512vbmi is introduced though [22:43:23 CEST] <TD-Linux> BBB, x86inc.asm + rust! (it's pretty boring though) [22:43:35 CEST] <BBB> rust? [22:44:10 CEST] <Gramner> kostya did some blog post about rust in relation to multimedia stuff [22:47:23 CEST] <TD-Linux> yeah I've read it, it's reasonable [22:47:39 CEST] <Blubberbub_> https://codecs.multimedia.cx/2017/07/rust-not-so-great-for-codec-implementi… <- this? [22:47:48 CEST] <Gramner> yeah [22:48:29 CEST] <Gramner> there was also some later one about performance vs C I think [22:50:16 CEST] <Gramner> https://codecs.multimedia.cx/2017/08/rust-optimising-decoder-experience/ [22:57:26 CEST] <J_Darnley> Wow. Someone is actually doing the work instead of just saying "why don't you rewrite in rust" [22:58:54 CEST] <JEEB> that happens sometimes [23:34:12 CEST] <BBB> omg I just wasted 5 minutes of my life reading these two blog posts [23:34:14 CEST] <BBB> poor kostya [23:34:28 CEST] <BBB> so his goal was really just to prove ignorant fools wrong? [23:34:47 CEST] <BBB> but ignorant fools cannot be convinced of obvious things, thats why you dont start trying to convince them [23:35:08 CEST] <BBB> you just keep ignoring them and they will continue to use your software anyway [23:35:13 CEST] <thardin> is improving rustc really an insurmountable task? [23:35:14 CEST] <BBB> poor kostya [23:35:45 CEST] <BBB> thardin: I think the sad but harsh reality is that it doesnt matter [23:36:10 CEST] <thardin> so? nothing matters [23:36:13 CEST] <thardin> who cares? [23:36:18 CEST] <BBB> until someone specifically focuses and demonstrates that mylanguage is optimized for multimedia-like problem areas, it wont be appropriate for it [23:36:24 CEST] <thardin> it's an interesting experiment [23:36:53 CEST] <BBB> well& [23:37:00 CEST] <BBB> heres my take on it [23:37:14 CEST] <BBB> an ignorant fool can ask any question at a rate of about 60 questions per minute [23:37:52 CEST] <BBB> demostrating the foolishness of the question - as meta-demonstrated by kostya - takes a few days per question [23:38:08 CEST] <BBB> that assymetry means that we need more than zero evidence before we approach a potentially-foolish question [23:38:55 CEST] <BBB> just because otherwise all we would ever do (and get done) is to address a fools concerns, but we wouldnt be writing software anymore [23:39:00 CEST] <BBB> akak wed be dinosaurs [23:39:08 CEST] <BBB> akak=a.k.a. [23:40:06 CEST] <BBB> (thats probably very cynical&) [23:40:16 CEST] <wm4> so when will ffmpeg be converted to rust (serious question) [23:40:34 CEST] <BBB> it sounds like kostya is almost done with it [23:40:37 CEST] <kierank> avformat is not an unreasonable candidate [23:40:56 CEST] <kierank> and then decoding done via hw decoders [23:40:56 CEST] <BBB> ffmpeg.c is probably a good candidate [23:41:18 CEST] <wm4> modern demuxers are already written in JS and this safe [23:41:49 CEST] <thardin> it's only 3x slower than C! [23:41:59 CEST] <thardin> ffmpeg electrum app when? [23:43:50 CEST] <thardin> sleep time soon, so I can continue work on my patchset [23:58:45 CEST] <thardin> I do hope kostya gets better. he seems burned out [00:00:00 CEST] --- Tue Aug 8 2017

1 0

ffmpeg.log.20170807
by burek 08 Aug '17

08 Aug '17

[00:32:21 CEST] <furq> is there no way to select stream type with -map 0:m [00:32:45 CEST] <furq> doing -map 0:v -map 0:m:language:eng and getting two video streams is a whole lot of fun [01:51:02 CEST] <markmedes2> So, I found the problem. Apparently I have either a file system corruption or a bad block on the disk. I couldn't copy the file from the usb drive to my computer [02:32:36 CEST] <jerkey> is it possible to cut a clip from an .mkv that does not start on a keyframe? [02:34:28 CEST] <JEEB> that has two different readings [02:34:59 CEST] <JEEB> 1) you want to cut a clip from a matroska file that doesn't start with an IRAP [02:35:11 CEST] <JEEB> 2) you want to cut a clip that doesn't start with an IRAP from a matroska file [02:36:27 CEST] <jerkey> i have a movie, i want to cut ten seconds from it, but it will only give me an output that starts at the nearest keyframe (IRAP?) to the -ss ##:##:## i give it [02:36:39 CEST] <jerkey> i want to cut from a specific second, and it refuses to do that [02:38:08 CEST] <JEEB> IRAP is a convenient term that was added in the HEVC spec that is an umbrella term for all types of pictures that a decoder can start decoding after random access (RA) [02:38:54 CEST] <JEEB> since you can either have an IDR picture (all intra + references are to be reset), open GOP intra picture that is a random access point etc. [02:39:10 CEST] <JEEB> but in general if you cut somewhere that is not an IRAP your result will not be decode'able [02:39:42 CEST] <JEEB> so you either need to re-encode a part in the beginning until the first GOP ends where you end up [02:39:59 CEST] <JEEB> or you use something like mp4 edit lists to get the player to throw away initial frames [02:40:32 CEST] <JEEB> you might test the latter with itsoffset or so [02:40:37 CEST] <jerkey> ok i am willing to re-encode, do i need to use an edit list file instead of the -ss parameter? [02:40:38 CEST] <JEEB> (and outputting to mp4) [02:40:48 CEST] <JEEB> re-encode is something you'll have to do manually [02:41:04 CEST] <JEEB> in two parts and using parameters that lead to similar enough parameter sets [02:41:23 CEST] <JEEB> (otherwise you need to make sure at least the latter part of the thing has parameter sets all over the thing [02:41:42 CEST] <JEEB> anyways, it's almost four here so I'm dropping out [02:42:49 CEST] <jerkey> ok thanks JEEB [03:23:37 CEST] <relaxed> furq: it's mapping the same video stream twice? [03:23:53 CEST] <furq> yeah [03:24:08 CEST] <furq> it's not a big deal, i just picked the audio stream by number [03:24:15 CEST] <furq> but i can imagine some batch use cases where that would be really annoying [03:24:36 CEST] <relaxed> I tried the same options on some anime and it mapped only audio, ass, and one video stream [03:24:54 CEST] <furq> usually the video stream doesn't have a language tag [03:24:58 CEST] <furq> but evidently for this file it does [03:25:21 CEST] <relaxed> right, I don't know why it would have a language set [03:25:37 CEST] <furq> i've seen someone else with this problem with audio and subtitle streams though [03:26:35 CEST] <relaxed> in ffmpeg's defense, isn't it giving you what you asked for? [03:26:42 CEST] <furq> yeah it is [03:26:55 CEST] <furq> which is why there should be a way to specify a stream type with m [03:29:54 CEST] <relaxed> right, something like -map 0:m:a,s:language:eng [03:32:36 CEST] <relaxed> maybe -map 0:a:m:language:eng -map 0:s:m:language:eng would make more sense [03:39:51 CEST] <relaxed> what was the problem with audio and subtitle streams? [03:42:21 CEST] <relaxed> furq: you meant the same issue? [03:45:01 CEST] <furq> yeah [04:32:52 CEST] <markmedes2> Guys, what's the matter here? I used the option -ec with the flag deblock [04:32:55 CEST] <markmedes2> Codec AVOption ec (set error concealment strategy) specified for output file #0 (/home/user/Desktop/encoded/kingsman.avi) is not an encoding option. [04:36:45 CEST] <relaxed> markmedes2: command? [04:37:28 CEST] <markmedes2> relaxed, time ffmpeg -i /home/user/Desktop/to_encode/KINGSMEN.mts -filter:v scale="640:trunc(ow/a/2)*2" -map 0:0 -map 0:1 -map 0:2 -vcodec libx264 -crf 20 -c:a aac -err_detect ignore_err -ec deblock /home/user/Desktop/encoded/kingsman.avi [04:42:41 CEST] <relaxed> I think that's a decoding option [04:43:34 CEST] <markmedes2> hmmm [04:43:43 CEST] <relaxed> place it before the input [04:43:44 CEST] <markmedes2> why it was working before? [04:43:50 CEST] <markmedes2> ah ok [04:44:04 CEST] <markmedes2> still... why it was working before just fine? [04:45:05 CEST] <markmedes2> nevermind, now it's working, thank you [04:45:40 CEST] <relaxed> you're welcome [04:45:47 CEST] <markmedes2> One more thing: Is there a way to re-encode using libmp3lame and keep audio in sync with video? [04:46:15 CEST] <relaxed> why wouldn't be in sync? [04:46:30 CEST] <relaxed> it be* [04:46:46 CEST] <markmedes2> idk, re-encoded videos with lame are completely out of sync [04:47:37 CEST] <relaxed> just libmp3lame? [04:47:46 CEST] <markmedes2> yes [04:48:00 CEST] <markmedes2> I found this: https://superuser.com/questions/1042988/ffmpeg-audio-out-of-sync-when-trans… [04:48:09 CEST] <markmedes2> but it's too complicated and I don't understand [04:48:43 CEST] <markmedes2> and not lame related [04:50:20 CEST] <relaxed> it's off from the start? [04:50:33 CEST] <markmedes2> yes [04:50:47 CEST] <relaxed> try -async -1 [04:51:27 CEST] <markmedes2> k [05:02:35 CEST] <markmedes2> relaxed, I found something. About 1 minute into the movie there is a quick glitch in the video, it's lost for a few seconds. So maybe that's why it's desyncing? [05:03:11 CEST] <relaxed> yeah, could be [05:09:43 CEST] <markmedes2> relaxed, the audio track doesn't suffer from the glitch, maybe I can make the video sync to the audio? [05:11:52 CEST] <relaxed> with a damaged file you might be out of luck [05:12:51 CEST] <markmedes2> oh well, I give up, thank you bro [07:17:39 CEST] <xacktm> anyone have issues with nvenc or can get nvenc to work? I get a "Cannot init CUDA" when I try to capture the screen https://bpaste.net/show/b6dc126a1354 [10:59:38 CEST] <whald> hi! i'm having trouble to let configure pick up my libva (which is installed in a non-standard location). here's my current state of affairs: https://pastebin.com/PE9dDRH5 [11:00:04 CEST] <whald> can s.o. help me figure out why the include directory is not picked up? [11:02:42 CEST] <furq> whald: PKG_CONFIG_PATH is printed in config.log, check that to make sure it's picking that up [11:04:06 CEST] <whald> furq, cat ffbuild/config.log | grep PKG_CON gives "PKG_CONFIG_PATH='/home/trem/mdi/playground/lib/pkgconfig'", looks good to me [11:06:34 CEST] <BtbN> whald, I don't think the libva checks use pkgconfig [11:06:47 CEST] <BtbN> you need to set the lib and include path yourself in extra-cflags/ldflags [11:06:58 CEST] <whald> BtbN, ahhh, that's interesting! [11:07:07 CEST] <whald> BtbN, i'll give it a spin, thanks [11:09:05 CEST] <darsain> hey guys, will "-map 0:s" select all subtitle streams? [11:12:57 CEST] <furq> yes [11:22:35 CEST] <Mavrik> From the first input file :) [11:23:06 CEST] <darsain> yes yes, I got it. ty :) [11:23:53 CEST] <darsain> also is there a way how to specify only a video video stream? I have an mkv file where there are 4 video streams, out of which 3 are mjpeg images [11:24:41 CEST] <darsain> I could do -map 0:v:0, but what if video won't be the first stream? [11:24:54 CEST] <BtbN> 0:v will always match the first video stream. [11:25:13 CEST] <darsain> I thought 0:v will match all video streams from 1st file, no? [11:51:01 CEST] <whald> BtbN, PS: using extra-cflags/ldflags did the trick, thanks! :-) [13:39:19 CEST] <papi> Hello [13:39:36 CEST] <papi> Does anyone have experiences with nginx rtmp module? [15:25:37 CEST] <Bear10> does anyone know how I could decode a jpeg within a filter to get its raw contents? [15:54:39 CEST] <JEEB> y/23 [16:36:03 CEST] <papi> Hello [16:36:10 CEST] <papi> Can some1 help me with following issue? [16:36:11 CEST] <papi> https://groups.google.com/forum/#!topic/nginx-rtmp/vWzKHt3ya9Q [16:40:31 CEST] <relaxed> papi: first thing to try is a recent version of ffmpeg [16:41:44 CEST] <papi> I use last version in debian:jessie [16:41:50 CEST] <papi> It should be very stable version [16:41:51 CEST] <papi> or not? [16:43:42 CEST] <relaxed> not. I recommend compiling a recent version or using https://www.johnvansickle.com/ffmpeg/ [16:45:15 CEST] <papi> I tried to compile ffmpeg, but it is very complicated [16:45:28 CEST] <papi> Too many flags in configure... [16:45:59 CEST] <relaxed> then use my static build :) [16:47:59 CEST] <papi> I'll try... ty :) [16:49:30 CEST] <papi> Hmmmm... my version is 3.2.5 and newest is 3.3.7 [16:49:35 CEST] <papi> I think it's not too old [16:59:06 CEST] <papi> Can you tell me how to compile your static build pls? [16:59:54 CEST] <papi> @relaxed [17:03:12 CEST] <papi> Ignore prev message :D [17:03:16 CEST] <papi> I am dumb D [17:03:17 CEST] <papi> :D [17:04:12 CEST] <papi> Output of your static ffmpeg: https://pastebin.com/nurBnYHs [17:07:56 CEST] <relaxed> maybe that's why the older build was not working? [17:08:48 CEST] <relaxed> I don't have any experience with ffmpeg + nginx streaming, sorry [17:09:53 CEST] <papi> Ok..... I don't think it's problem of older build. Your build won't send play command [17:12:23 CEST] <Bear10> just going to try one more time incase someone missed it, does anyone know does how I could decode a jpeg within a filter to get its raw contents? [17:18:14 CEST] <relaxed> Bear10: In a filter? Would this work --> ffmpeg -i input.jpg -f rawvideo output.raw [17:18:47 CEST] <Bear10> relaxed: not quite, we're trying to change the input.jpg on the fly for livestreams like OBS allows you to change the inputs [17:19:19 CEST] <Bear10> so I thought one approach would be in the code to create a custom filter and decode at will a specific jpg, however thats resulting a lot more difficult than i imagined [19:35:47 CEST] <pgorley> hi, does the h264 decoder have a settings to drop frames that contain artifacts? [20:28:11 CEST] <gwohl> On FFmpeg nightly build, the HEVC decoder is presenting errors like `Could not find ref with POC 340` when streaming adaptively over HTTP but not when decoding that same stream locally. Remotely, decoding gets very distorted with lots of blocking and color artifacts, but nothing bad occurs during local decode. Can anyone point to a likely cause? [20:34:52 CEST] <Shawn_> Hello. I'm converting a MOV to WebM and the translucency does not look the same. For some reason, the WebM is letting much more of the background through. Any ideas what could cause this? [20:35:55 CEST] <klaxa> translucency? i don't think vp8/vp9 supports transparent pixels? [20:36:02 CEST] <furq> vp8 does [20:36:29 CEST] <klaxa> well color me surprised [20:36:35 CEST] <furq> oh apparently vp9 does as well [20:36:45 CEST] <Shawn_> Here is some info: https://developers.google.com/web/updates/2013/07/Alpha-transparency-in-Chr… [20:37:16 CEST] <furq> what pixel format is the mov [20:37:43 CEST] <furq> if it's rgba or something then maybe swscale is just doing a dodgy conversion [20:40:13 CEST] <Shawn_> It's Apple QuickTime RLE Video if that helps. How can I check to see if it's RGBA? [20:40:19 CEST] <furq> ffprobe [20:40:59 CEST] <furq> it must be argb though because that's the only pixel format qtrle supports with alpha [20:43:40 CEST] <Shawn_> Here is the output of the FFProbe: https://pastebin.com/AQMZgs78 [20:44:33 CEST] <furq> maybe try -sws_flags dst_range=full [20:44:51 CEST] <Shawn_> I'll give that a try! [20:51:06 CEST] <Shawn_> @furq: Getting an error: https://pastebin.com/UV5aeeTi [21:25:30 CEST] <papi> Hello guys [21:25:39 CEST] <papi> FFmpeg cannot play RTMP stream from nginx [21:25:47 CEST] <papi> With VLC I have no problems [21:25:54 CEST] <papi> I am using FFmpeg 3.2.5 [21:25:57 CEST] <papi> Any solution? [21:27:05 CEST] <JEEB> test latest master? [21:27:20 CEST] <JEEB> if it still doesn't work provide a sample RTMP stream and post an issue on trac [21:41:53 CEST] <nahsi> guys, i'm using mpdecimate filter to get the correct framerate from ~30 fps silent movie which originally was 14-16. The result is very impressive, but not without drawbacks. It drops black frames. There are very little of those frames in the beginning only. How can I tell it not to drop completely black frames? [21:58:36 CEST] <lacrymology> question: ffserve serves live streams, right? like.. the client doesn't have any control over what it's getting? [21:59:05 CEST] <lacrymology> I'm trying to find a way to cast to my chromecast that supports seeking [21:59:07 CEST] <JEEB> lacrymology: ffserver is something that nobody will be able to help you with, so do not look at it [21:59:21 CEST] <lacrymology> JEEB: lol. ok, but why [21:59:45 CEST] <JEEB> because it's a thing that has never even been understood by most people. and it seemingly isn't really great at what it does [22:01:28 CEST] <lacrymology> :) [22:02:21 CEST] <pgorley> lacrymology: use vlc if you need a streaming server [22:04:07 CEST] <lacrymology> pgorley: I haven't been able to make it work as I want. Ideally I'd be able to control the stream (pause, seek) either by commands from the client or by just doing it on the server and have the client not break [22:06:39 CEST] <pgorley> lacrymology: i've never had those issues with vlc, but i wasn't doing anything other than a few tests with it [22:07:58 CEST] <lacrymology> pgorley: how do you control playback? [22:09:07 CEST] <pgorley> lacrymology: you should ask the guys at #videolan instead, i haven't fiddled with vlc for months [22:09:37 CEST] <pgorley> but iirc i would just move the slider to seek in the file [22:10:45 CEST] <pgorley> don't remember anything breaking [22:21:00 CEST] <Shawn_> Furq, are you still there? I can't get the -sws_flags to work (https://pastebin.com/UV5aeeTi) [22:22:23 CEST] <Shawn_> The WebM transparency is working with the exception of partial opacity (i.e. a ghost hand with the background showing through). The ghost hand is letting much more of the background threw than the MOV. [22:22:37 CEST] <Shawn_> through* [22:23:24 CEST] <Shawn_> For the parts that are 100% transparent, no issues. [23:06:21 CEST] <abdul> Hi, im trying to play a v5zap dvbc/annex_a captured stream by using ffmpeg. FFmpeg says 'could not find codec parametersvq= 0KB sq= 0B f=0/0' when i play hd channels but on public free hd channels it works normaly! so is there a special codec needed or something? [23:25:30 CEST] <timofonic> Hello [23:26:18 CEST] <timofonic> Does ffmpeg supports DCP? https://en.wikipedia.org/wiki/Digital_Cinema_Package [23:26:47 CEST] <JEEB> MXF is supported, composition XML not [23:42:01 CEST] <timofonic> JEEB: Oh, why no? :( [23:42:08 CEST] <timofonic> JEEB: Any hopes? [23:42:45 CEST] <JEEB> now the real question is, do you /require/ the info that's in the XML. in libavformat itself [23:43:02 CEST] <JEEB> I've had some clips in DCP format and I just ignored the XML [23:43:16 CEST] <JEEB> load video, load audio, know how the flying fuck the audio was mixed [23:43:20 CEST] <JEEB> and off you go [23:44:09 CEST] <timofonic> JEEB: It's just for convenience in a projection room, just looking for a friend. I'm not a usual consumer of DCP [23:44:20 CEST] <JEEB> well the problem with that stuff then [23:44:29 CEST] <JEEB> is the fact that software jpeg2000 decoding is *slow* [23:44:40 CEST] <JEEB> you can already play the MXF Files together with mpv or so [23:44:44 CEST] <JEEB> or VLC [23:44:55 CEST] <JEEB> VLC even has support for the XML I think if you're a lazy person like that [23:45:21 CEST] <timofonic> JEEB: Oh, interesting :) [23:46:32 CEST] <timofonic> JEEB: Now I'm having a really weird HDD error. Going to ask elsewhere. Thanks a lot [23:52:19 CEST] <abdul> can it be a receiver hardware problem? the decoder supports HVEC but not h264/h265 [23:54:23 CEST] <abdul> my tv can handle all these streams without any decoder or in germany called 'hd card' [00:00:00 CEST] --- Tue Aug 8 2017

1 0

ffmpeg-devel.log.20170806
by burek 07 Aug '17

07 Aug '17

[00:26:06 CEST] <cone-093> ffmpeg 03Michael Niedermayer 07master:1f53bde6d817: avcodec/h264_slice: Fix overflow in slice offset [00:26:07 CEST] <cone-093> ffmpeg 03Michael Niedermayer 07master:1e443051b277: avcodec/aacdec_fixed: fix invalid shift in predict() [03:01:31 CEST] <jamrial> does anyone know how to report bugs to clang and can do it? because clang since version 5 is miscompiling the jpeg encoder (and maybe also decoder) [03:02:01 CEST] <jamrial> probably only encoder [03:13:03 CEST] <thebombzen> jamrial: probably on their bug tracker :P [03:14:17 CEST] <thebombzen> just a google search took me to this: https://bugs.llvm.org/ [03:20:01 CEST] <Compn> probably the correct place [03:20:21 CEST] <Compn> thebombzen : its possible jamrial wants someone to create samples that miscompile though [03:20:34 CEST] <Compn> because compiler projects require sample code (and they dont want full .c files) [03:20:50 CEST] <Compn> and especially not 1mb ffmpeg project zip ;) [03:21:17 CEST] <Compn> jamrial : we could probably ask on twitter for a volunteer [03:21:29 CEST] <Compn> jamrial : if you want to post what happens to our bugtracker and then we point twitter at it [03:21:49 CEST] <jamrial> nobody here uses clang at all? [03:21:58 CEST] <Compn> there are some clang users here i think [03:21:59 CEST] <jamrial> seems a bit too extreme to ask on twitter about it [03:22:01 CEST] <Compn> maybe just afk :D [03:22:09 CEST] Action: Compn hides [03:38:04 CEST] <iive> jamrial: ask atomnuker [04:03:16 CEST] <BBB> jamrial: about your patch [04:03:29 CEST] <jamrial> BBB: yeah? [04:03:30 CEST] <BBB> jamrial: lets hypothetically suggest that I wanted to put h264 ps headers in the frame side data [04:03:36 CEST] <BBB> e.g. the slice header [04:03:46 CEST] <BBB> that would break for multi-slice frames afte your patch [04:04:24 CEST] <jamrial> how do you access them? custom code looping over existing side data? because av_frame_get_side_data() will always only return the first result of the requested type [04:04:32 CEST] <BBB> custom code loop yes [04:04:45 CEST] <jamrial> is that proper/documented api usage? [04:04:50 CEST] <BBB> I dont know [04:04:52 CEST] <BBB> it works [04:05:38 CEST] <BBB> you could also add an api to get the nth of a type of side data [04:05:40 CEST] <jamrial> plenty of things will work when you abuse an api :P [04:05:45 CEST] <BBB> where the default function returns nth=0 [04:05:50 CEST] <BBB> sure [04:05:55 CEST] <BBB> but this is not a crazy use case [04:05:56 CEST] <jamrial> but you should expect them to be broken without notice [04:05:58 CEST] <BBB> how would you do it? [04:06:07 CEST] <BBB> lets sya you are me and want slice headers [04:06:11 CEST] <BBB> what would you do? [04:06:21 CEST] <jamrial> i agree, so maybe this should be documented, or a new function allowing one to get the other results should be added [04:06:31 CEST] <BBB> thats what I just said [04:06:43 CEST] <BBB> add a function to get the nth element of a type of side data [04:06:48 CEST] <BBB> and for the default function, get nth=0 [04:07:12 CEST] <jamrial> epatchwelcome :p [04:07:13 CEST] <BBB> and if we reach the end of the side data list without encountering n side datas of that type, return NULL [04:07:28 CEST] <BBB> you proposed a patch to break a use case [04:07:31 CEST] <jamrial> i can drop this patch. i wrote it just to be consistent with the current packet side data behavior [04:07:34 CEST] <BBB> I just loop over the struct directly [04:07:44 CEST] <BBB> because I dont want to add external api that is weird [05:33:15 CEST] <atomnuker> jamrial: yeah, I use clang, it work fine with ccache and is slightly faster than gcc [06:06:10 CEST] <jamrial> atomnuker: can you try to make a testcase for the above and report it to llvm? [06:12:20 CEST] <atomnuker> jamrial: was it clang's fault? the commit doesn't say [06:13:00 CEST] <jamrial> what commit? [06:13:24 CEST] <jamrial> look at fate, every jpeg encoder test is failing with clang 5 (release) and newer [06:13:50 CEST] <jamrial> on both x86_32 and x86_64 [06:15:40 CEST] <atomnuker> ah, I thought you meant the bug which was just closed [06:18:40 CEST] <atomnuker> "New user self-registration is disabled due to spam. For an account please email bugs-admin(a)lists.llvm.org with your e-mail address and full name." [06:24:34 CEST] <jamrial> same happened to gcc's bugzilla afaik [07:21:08 CEST] <atomnuker> speaking of compiler errors, debian's latest gcc-snapshot fails to compile at all [07:21:11 CEST] <atomnuker> "libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed" [07:53:28 CEST] <Blubberbub_> https://www.ffmpeg.org/developer.html#Contributing <- this should probably changed, because pull requests aren't accepted through github, right? [09:12:48 CEST] <cone-726> ffmpeg 03DeHackEd 07master:eabeb9093abe: avformat/hlsenc: allow dynamic encryption key rotation [09:54:02 CEST] <nevcairiel> Blubberbub_: you can still do that and send it to the ML for review, it doesnt mention pull request specifically [09:54:55 CEST] <Blubberbub_> yea, i think i misunderstood it. Its probably about having my own fork of ffmpeg and referencing a branch in my fork on the mailing list? [09:59:34 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.3:e51e07c34eb7: avfilter/vf_ssim: fix temp size calculation [11:36:22 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.2:5987b16f868c: avfilter/vf_ssim: fix temp size calculation [11:58:16 CEST] <cone-726> ffmpeg 03Muhammad Faiz 07release/3.1:eadb52d45904: avfilter/vf_ssim: fix temp size calculation [12:36:17 CEST] <Blubberbub_> a simple NaN can really ruin a productive day... [12:45:58 CEST] <atomnuker> Blubberbub_: where? [12:47:02 CEST] <atomnuker> (and yeah, nans suck, they also make every float op take 300-400 cycles so they're pretty easy to detect) [12:47:33 CEST] <Blubberbub_> i'm writing a filter that trims silence from the start and end of audio. The compute_rms-function in af_silenceremove uses a sqrt() which apparently can generate NaNs [12:48:05 CEST] <Blubberbub_> and i wrote my code where the nan triggered the wrong condition [12:51:34 CEST] <Blubberbub_> i can't english today. :D [13:06:54 CEST] <durandal_1707> Blubberbub_: use fabs [13:07:57 CEST] <Blubberbub_> assuming that a*a is >= 0 for double values i shouldn't need fabs. But maybe that assumption is wrong? [13:16:09 CEST] <durandal_1707> Blubberbub_: are you modifying existing filter? [13:16:26 CEST] <Blubberbub_> kind of [13:16:33 CEST] <Blubberbub_> i'm writing a variant [13:19:54 CEST] <durandal_1707> Blubberbub_: what variant? [13:20:29 CEST] <Blubberbub_> i want to remove silence from the start and end of the file, but not anything else [13:22:19 CEST] <durandal_1707> Blubberbub_: and how would you do that if you dont know duration? [13:22:45 CEST] <Blubberbub_> writing everything that looks like silence into a fifo until i encounter eof or non-silence [15:16:19 CEST] <atomnuker> Blubberbub_: what if you have silence in the middle of the file [15:16:37 CEST] <atomnuker> if you want to remove from the start and end only you'll need to cache everything until EOF [15:16:47 CEST] <Blubberbub_> only the silence, but yes [15:17:33 CEST] <Blubberbub_> so i write the silence to a buffer and if i notice that there is non-silence after the silence i just buffered i empty that buffer and start over [15:17:45 CEST] <Blubberbub_> if i find eof i just ignore the buffered silence [15:19:28 CEST] <BtbN> a filter that hold back output for a very long time and then dumps it all sounds problemetic [15:19:50 CEST] <atomnuker> BtbN: that's how the areverse and reverse filters work [15:20:16 CEST] <atomnuker> (and they work alright as long as you have enough ram to store everything uncompressed) [15:21:58 CEST] <Blubberbub_> i also destroy the regularity of frame sizes in the progress, but i haven't yet encountered any problems with that [17:44:28 CEST] <durandal_1707> why nobody wrote ff edit like utility years ago [17:45:03 CEST] <durandal_1707> they just complain and use shit like vs or avs [17:50:41 CEST] <atomnuker> exactly [18:20:40 CEST] <BtbN> https://bpaste.net/show/92253bb6d717 is it intended that the hls muxer keeps spamming this? [18:27:12 CEST] <DHE> yes, ever since it turned out to be a potential security hazard to open the contents of playlist-based formats... [18:27:21 CEST] <DHE> that is, it's intentional. not that I agree with it. [18:30:01 CEST] <BtbN> it's spamming so hard that reducing the log level made it go notably faster [18:30:35 CEST] <JEEB> it's writing so I'm not sure if that is necessary [18:30:37 CEST] <BtbN> I don't really understand how creating a hls video/stream is a security issue though [18:30:41 CEST] <JEEB> yea [18:31:10 CEST] <JEEB> just make a patch about it making the logging level something more verbose [18:31:17 CEST] <JEEB> than AV_LOG_LEVEL_INFO [18:31:27 CEST] <BtbN> I don't even see where in the code those logs come from [18:31:27 CEST] <JEEB> that goes into VERBOSE or TRACE for me personally? [18:31:29 CEST] <BtbN> it's not in hlsenc.c [18:33:26 CEST] <nevcairiel> it generically logs all file opening [18:35:03 CEST] <BtbN> that should be at least verbose [18:35:31 CEST] <nevcairiel> i'm sure someone will argue that its "security relevance" is only meaningful if its shown to people by default =p [18:35:49 CEST] <DHE> see commit 53e0d5d7247548743e13c59c35e59fc2161e9582 [18:38:24 CEST] <BtbN> So I guess adding the hls muxer to that check is in order [18:39:38 CEST] <BtbN> Or in general at least some option to silence it. [18:39:52 CEST] <BtbN> Specially with short segmented non-live hls it's a massive wall of spam [21:18:52 CEST] <jamrial> <atomnuker> "libavfilter/af_compand.c:328:12: internal compiler error: verify_ssa failed" [21:19:08 CEST] <jamrial> what configure options and how old is the snapshot? [21:21:44 CEST] <DHE> an ICE is automatically a compiler or hardware fault. try again. if it happens twice, update gcc. if it doesn't, check your hardware [21:23:36 CEST] <atomnuker> jamrial: gcc (Debian 20170731-1) 8.0.0 20170731 (experimental) [trunk revision 250749], config options were https://0x0.st/dNP.txt [21:24:52 CEST] <DHE> ... gcc 8.0.0 isn't an official release... see gcc.gnu.org/ [21:25:14 CEST] <jamrial> DHE: it's the in development version [21:25:36 CEST] <DHE> yes I see that... [21:25:56 CEST] <jamrial> svn trunk snapshots are all 8.0.0 [21:26:28 CEST] <jamrial> so if it's crashing compiling ffmpeg, better report it now so they fix it before it's released [21:44:39 CEST] <jamrial> atomnuker: can reproduce, will make a ticket on gcc's bugzilla later [21:45:24 CEST] <JEEB> cool [22:27:41 CEST] <atomnuker> is there anything odd at all about our tta decoder? anything at all? [22:28:14 CEST] <atomnuker> running showcqt in mpv's lavfi-complex causes pauses once every second or so [22:28:23 CEST] <atomnuker> but only when decoding tta [22:28:53 CEST] <atomnuker> (number of audio decoding threads makes no difference so its not a threading bug) [22:31:53 CEST] <jamrial> atomnuker: not that i know of, but ask durandal_1707 [22:31:59 CEST] <jamrial> try cpuflags 0 and such as well [22:34:11 CEST] <durandal_1707> tta have some strange heuristic for guessing last frame [22:34:31 CEST] <durandal_1707> i failed to get it working [22:43:47 CEST] <jamrial> durandal_1707: doesn't that depend on the container? .tta files are fine, it's matroska where things can get iffy since for some reason in the spec they decided to drop the tta header [22:44:58 CEST] <durandal_1707> jamrial: tta is same, as when you seek you forget when you are [00:00:00 CEST] --- Mon Aug 7 2017

1 0

ffmpeg.log.20170806
by burek 07 Aug '17

07 Aug '17

[00:08:50 CEST] <Roberth1990> hello, I'm new to this audio normalization thing, im trying to make the dynaudnorm work, but with its default settings it seems way too agressive, lets say one person talks, and another person talks louder(raising his voice), with dynaudnorm the louder voice gets even quieter than the other voice, how can I avoid this? [02:01:03 CEST] <SomeClown> Quick question: Is it possible to use ffmpeg-python to retrieve all metadata from an M4V file? If so, can someone point me to appropriate documentation? [02:04:19 CEST] <JEEB> "all metadata" is often a problematic thing since whether or not everything considered "metadata" would be defined well, and second of all if it supported for reading by the libraries [02:04:26 CEST] <JEEB> also no idea about the python wrapper [02:04:43 CEST] <JEEB> in theory you can get a lot of stuff by just using ffprobe's `-of json` mode [02:07:54 CEST] <SomeClown> Hmm... yeah, for all the power of Python, I'm finding it exceedingly difficult to read any metadata at all from Apple's media files (iTunes videos, music). Haven't found a single library that can do it, at least not yet. [02:08:27 CEST] <JEEB> no idea who made that wrapper or how far it goes [02:08:35 CEST] <SomeClown> Thanks, though... I'll play with ffmpeg for some other things. [02:08:44 CEST] <JEEB> ffprobe's json output would at least be simple enough to parse from python :P [02:08:47 CEST] <JEEB> from json import loads [02:09:21 CEST] <JEEB> then use subprocess or something to execute ffprobe and catch stdout [02:09:51 CEST] <JEEB> (of course all that data is also available from the APIs as well but as I said I have no idea how well that library of yours integrates things) [02:09:58 CEST] <SomeClown> I could certainly parse the json, but I'm trying to avoid running a command line tool from inside (using subprocess call). [02:10:02 CEST] <JEEB> ok [02:10:09 CEST] <SomeClown> Thanks, though! [02:10:15 CEST] <JEEB> then godspeed because the wrappers tend to age fast [02:10:29 CEST] <JEEB> with rust I'm using the mozilla-maintained bindgen [02:10:41 CEST] <JEEB> and thankfully golang has pkg-config and header parsing by default [02:11:45 CEST] <JEEB> manual wrapper writing just isn't a thing you get things done with with FFmpeg due to the changes being done every now and then, and additional things being added even if backwards compatibility is still kept [02:12:01 CEST] <JEEB> anyways, in the API the metadata should be on the libavformat level [02:12:14 CEST] <JEEB> open the demuxer and probe the input etc [02:12:36 CEST] <JEEB> then the AVFormatContext should have a *lot* of data [03:15:36 CEST] <thebombzen> sometimes it's just easier to execute ffmpeg.c or ffprobe.c and then grab the output [03:15:51 CEST] <thebombzen> than it is to try to link to the libraries at least, because bindings and wrappers and shenanigans [06:10:31 CEST] <xacktm> hey guys, is it possible to get nvenc working with a gtx 1060? I get a "Cannot init CUDA" with yesterday's git HEAD https://bpaste.net/show/b6dc126a1354 [06:10:53 CEST] <xacktm> this forum post has a similar issue but there were no leads https://devtalk.nvidia.com/default/topic/740805/linux/nvenc-h-264-encoder-i… [06:37:14 CEST] <FlorianBd> Hi! How can I turn ffmpeg http://192.168.12.34/video/mjpg.cgi?profileid=1' -acodec copy -vcodec copy file.mp4 into something with motion detection that makes a new file every time a new motion is detected? [07:32:01 CEST] <mnr200> stream from rtsp server is not playing with ffplay >> like this ffplay rtsp://localhost:8089/live.sdp [07:37:17 CEST] <mnr200> what could be the possible problem? [07:45:05 CEST] <mnr200> okay, got it working [07:46:12 CEST] <mnr200> okay now I have another problem that I couldn't solve earlier, I got error like this >> Unknown input format: 'dshow' [07:46:31 CEST] <mnr200> with this command >> ffmpeg -f dshow -i video="Virtual-Camera" -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -f mpegts rtsp://localhost:8554/live.sdp [09:07:35 CEST] <npn> If I download an mp4, I can start playing it immediately while the download runs. The information about the total size seems to be present from the start. If I run ffmpeg on an mp4 - no encoding options just adding a watermark, I can not open the file until ffmpeg is complete. Is there any way to be able to start watching while ffmpeg is still running? [09:17:01 CEST] <Blubberbub_> adding a watermark probably needs re-encoding [09:20:07 CEST] <ritsuka> npn: you have to enable the fast start option [09:20:34 CEST] <npn> Sorry for bad explanation. I AM reencoding, I meant- I'm not changing the format [09:21:41 CEST] <npn> ffmpeg -i input.mp4 -vf drawtext="fontfile=/path/to/font.ttf: text='Test Watermark': fontcolor=white: fontsize=24: box=1: boxcolor=black(a)0.5: boxborderw=5: x=(w-text_w)/2: y=(h-text_h)/2" -codec:a copy output.mp4 [09:24:22 CEST] <Blubberbub_> do i understand you correctly, that you have ffmpeg write to a file that is being read from your webserver at the same time? [09:25:25 CEST] <ritsuka> npn: sorry I didn't read your message carefully eh [09:26:19 CEST] <npn> Yes- I have multiple users, and I want to watermark each video in a user specific way. I was hoping that the user could access the video immediately, while it is still being encoded. [09:28:13 CEST] <npn> This https://stackoverflow.com/questions/6353519/is-it-possible-to-play-an-outpu… says NO for mp4, but maybe other formats would work? [09:29:23 CEST] <bencoh> mpegts, matroska, ... [09:29:51 CEST] <npn> The other constraint is that it needs to be HTML5/flowplayer compatible ;-) Webm ? [09:30:00 CEST] <bencoh> fragmented mp4 [09:31:10 CEST] <bencoh> actually I'd expect flowplayer to support mpegts since they can play hls (iirc?), but ... [09:31:11 CEST] <Blubberbub_> can that even work? i would assume it would break because the webserver can read the file faster than ffmpeg could write it and then decide its finished. If it is even allowed to open the file that is being written in the first palce [09:31:39 CEST] <bencoh> Blubberbub_: true [09:32:08 CEST] <bencoh> you'd have to throttle somehow [09:32:15 CEST] <Blubberbub_> fragmenting could work [09:32:37 CEST] <Blubberbub_> like have multiple files, so the user can already watch/load parts of the video [09:33:06 CEST] <bencoh> Blubberbub_: you're basically reimplementing (a subset of) hls/dash/whatever :) [09:33:47 CEST] <Blubberbub_> true [09:34:48 CEST] <Blubberbub_> i wondered: is there a codec that allows "subregion encoding"? lets say i have a watermark and i add it only to the lower right corner: then only reencode the lower right corner, but copy the rest of the data? [09:39:00 CEST] <npn> So close... using the fragmented mp4, yes I can start playing the video immediately, but the total length only shows as far as it has been fragmented. So the user gets cut off half way and then has to refresh the page to find out the true length. Is there any way to read the total length of the input file, and stick that on the output file from the start? [09:42:53 CEST] <Blubberbub_> i would guess hls allows for something like that [09:43:41 CEST] <npn> Tx [09:43:52 CEST] <Blubberbub_> i don't know though [09:44:33 CEST] <Blubberbub_> encoding every video for every user might take a lot of space... [09:45:53 CEST] <npn> Yes indeed [09:47:43 CEST] <Blubberbub_> a fast way to add a watermark would be great. But that would require deep knowledge of the codec, i guess. [13:33:55 CEST] <lavalike> how do I translate x264 options to -x264-params format? [13:34:52 CEST] <lavalike> I tried blindly s/ /:/g such as: -c:v libx264 -x264-params "cabac=1:ref=5:deblock=1:-2:-2:analyse=0x3:0x133& [13:35:13 CEST] <lavalike> but the result has ref=3 so something's not right [13:38:54 CEST] <furq> that's correct, so i guess it's being overwritten with the -preset medium defaults [13:39:21 CEST] <furq> maybe try manually setting a preset before -x264-params [13:39:50 CEST] <lavalike> ok! [13:41:54 CEST] <lavalike> now some are right but others are wrong still [13:42:05 CEST] <lavalike> I guess preset slow matches some of the settings I want to replicate, hehe [13:43:03 CEST] <lavalike> could it be that deblock=1:-2:-2 needs the : transformed to something else since they are used as a separator in the -x264-params ? [13:58:18 CEST] <DHE> if you have a profile or level defined as well, ref might be clamped [14:02:29 CEST] <ITR> I'm trying to copy a 32bit wav file to a video with "ffmpeg -loop 1 -framerate 30 -i ..\Pictures\P5.png -i ..\Music\NeverSawItComing.wav -c:v libx264 -preset medium -tune stillimage -crf 18 -c:a copy -shortest -pix_fmt yuv420p P5.mkv", but the audio gets corrupted, does anyone know what the error might be? Removing -c:a copy fixes it, but I assume that lowers audio quality? [14:03:01 CEST] <ITR> By corrupted I mean that the sound becomes really horrible to listen to [14:03:02 CEST] <DHE> you'll get a default audio codec with default bitrates. [15:50:35 CEST] <TheWild> hello [15:51:13 CEST] <TheWild> ffplay - how to disable spectrum when playing audio files? It just wastes processing power. [15:51:49 CEST] <JEEB> just use a proper player like mpv instead which utilizes the libav* libraries underneath :) [15:51:57 CEST] <JEEB> ffplay is just a Proof of Concept kind of thing [15:53:27 CEST] <TheWild> I'm connected via SSH to the computer that serves as a jukebox. [15:53:35 CEST] <TheWild> well, got it anyway. ffplay -nodisp [15:53:51 CEST] <JEEB> yea, I see mpv or something working similarly enough [15:54:07 CEST] <JEEB> since I use it to connect to pulseaudio and having no window of its own with audio :) [15:54:18 CEST] <JEEB> (which is the default mode) [16:12:17 CEST] <TheWild> awesome. Thanks for letting me know about mpv. [16:15:34 CEST] <BtbN> Is there some mechanism in the hls muxer I could use to avoid ending up with several million files in one directory? [16:15:48 CEST] <BtbN> Like, putting them in subdirs, with the first X digits of the segment index [17:29:50 CEST] <DHE> BtbN: live? there's a flag for delete_segments so old segments go out [17:30:00 CEST] <BtbN> I want all of them [17:30:15 CEST] <BtbN> But not in one directory. That gets horribly slow [17:30:31 CEST] <DHE> there are some flags to put timestamps or indexes into the directory names, but you'll have to look into the details yourself. [17:30:43 CEST] <BtbN> There are no timestamps [17:30:47 CEST] <BtbN> just an incrementing index [17:31:01 CEST] <BtbN> And I can't see any format-string to get like the first X digits of it [17:31:27 CEST] <BtbN> so segments 1500000 would end up in directory 150 or so [17:34:36 CEST] <DHE> how about the option use_localtime_mkdir ? see the examples [17:35:20 CEST] <BtbN> It's not a live stream [17:35:28 CEST] <BtbN> So there is no useful localtime [17:35:43 CEST] <DHE> ... right... [17:40:13 CEST] <DHE> I don't have a good answer besides "rewrite it after it's done" [17:40:38 CEST] <BtbN> it's actually over one million segments. [17:40:50 CEST] <DHE> holy crap.... [17:41:13 CEST] <BtbN> I'm tempted to just hack it into the hlsenc.c [17:41:32 CEST] <DHE> even if those are 1 second increments that's over 11 days [17:41:49 CEST] <BtbN> it's two second segments, and 14 days [17:43:38 CEST] <BtbN> Just gonna put some counter into there, and once it reaches 10k or something, it gets reset and another counter gets incremented, and that other counter is used for another directory name [17:45:09 CEST] <c_14> BtbN: you could try using hls_flags +single_file ? [17:45:25 CEST] <c_14> depends on if the clients support that of course [17:46:56 CEST] <BtbN> I actually want those segments [17:47:02 CEST] <BtbN> I don't really care about the playlist [17:47:26 CEST] <BtbN> I have two gigantic single files right now [17:49:21 CEST] <BtbN> it's for a script that operates on .ts or .flv segments, and stitches them together and streams them to YT [17:57:33 CEST] <luc4> Hello! I built ffmpeg for armv8 cortexa53 and Im testing the performance of the transcoding. When running it I see using cpu capabilities: ARMv6 NEON. Is this correct? [17:58:36 CEST] <JEEB> I will guess you have NEON and that's that primary thing [18:01:37 CEST] <JodaZ> wouldn't you want to use an accelerator for transcoding on soc's ? [18:07:27 CEST] <JEEB> JodaZ: depends on your needs and how crappy the API/SoC is [18:07:36 CEST] <bencoh> errm, A53 should be armv8 though [18:07:49 CEST] <bencoh> I suppose you're using it as a 32b target [18:08:04 CEST] <JEEB> I've seen people have fallback openh264 or something because not everything encodes properly [18:08:34 CEST] <bencoh> (armv8 is a 64b-capable architecture) [18:09:02 CEST] <bencoh> (and neon set is different on armv8) [18:09:24 CEST] <JEEB> yea, aarch64 is another thing there. a lot of people have their system on such SoCs armv7 due to vendor/whatever limitations [18:09:41 CEST] <luc4> bencoh: yes, this is a cortexa53 64bit cpu, but the firmware is 32bit [18:10:59 CEST] <luc4> bencoh: does this mean that when building for aarch32 the result is that only armv6 optimisations are applied? [18:11:28 CEST] <JEEB> aarch64 optimizations of course aren't applied because it's not a 64bit binary [18:11:39 CEST] <JEEB> NEON is as far as 32bit optimizations go [18:12:01 CEST] <luc4> JEEB: neon is ok, but I see only armv6 optimisations [18:12:22 CEST] <bencoh> neon is armv6-neon in your case [18:12:23 CEST] <JEEB> I think that just means "I could use armv6 instructions" [18:12:35 CEST] <bencoh> (which is not armv8 neon) [18:12:37 CEST] <JEEB> there is no real other optimizations for ARM [18:12:44 CEST] <luc4> JEEB: maybe there is no specific optimisations for armv7 and armv8? [18:12:44 CEST] <JEEB> (in FFmpeg, other than aarch64) [18:12:45 CEST] <kepstin> my impression is that armv8-compatible 64bit can run armv7 32bit stuff [18:12:53 CEST] <bencoh> kepstin: it can, indeed [18:13:08 CEST] <JEEB> luc4: well NEON is the only instruction set so that's what you really care about [18:13:19 CEST] <JEEB> *only SIMD instruction set [18:13:35 CEST] <luc4> so would you say this is a proper build that is using whatever ffmpeg can use? [18:13:55 CEST] <JEEB> unless you disabled something I'd say yes [18:14:06 CEST] <luc4> Im not trying to fix a specific issue, Im just experimenting. [18:14:49 CEST] <luc4> the weird thing is that the same exact board seems to be running ffmpeg faster when the firmware is a firmware built for armv6 with much older compiler [18:15:02 CEST] <luc4> :-) [18:15:14 CEST] <luc4> this is confusing me a bit [18:16:37 CEST] <kepstin> I suspect the differences between armv6 and armv7 are pretty minimal for this application, assuming neon support is used. [18:18:01 CEST] <kepstin> i guess it has the thumb-2 encoding support too, which might help. [20:50:37 CEST] <vektorweg1> can ffmpeg capture gl? couldnt find anything in the docs. [20:51:30 CEST] <JEEB> there are some screen capture modules but not sure if it's what you want [20:52:57 CEST] <DHE> hardware accelerated capturing would be nice (on linux). all I know of is x11grab. CUDA grab could be used to make nvenc run really fast, right? [20:54:34 CEST] <JEEB> no idea. I only know there's a nice API for screen capture on recent windows versions because virtualdub's author blogged about it [20:54:43 CEST] <JEEB> (FFmpeg doesn't use that API anyways) [20:57:04 CEST] <vektorweg1> afaik new windows built-in screen capture is servilely slowing down games on relatively new hardware [20:57:24 CEST] <BtbN> gdicapture is bad [20:57:33 CEST] <BtbN> Use OBS if you want to capture a game [20:57:54 CEST] <BtbN> DHE, CUDA grab? I don't think that's a thing. [20:58:19 CEST] <BtbN> JEEB, they probably mean desktop duplication. [20:58:26 CEST] <BtbN> OBS uses that for Monitor Capture [20:58:43 CEST] <vektorweg1> BtbN: i was trying to avoid obs, because this software seems still pretty unstable to me and ffmpeg would be sufficient. [20:59:04 CEST] <BtbN> what's unstable about it? [20:59:05 CEST] <jkqxz> For single windows in X, you can use DRI2 to pick out the DRM object currently being used for scanout. On Intel at least you can then give that straight to VAAPI to encode with no CPU involvement. [20:59:16 CEST] <BtbN> We just ran a week long 24/7 marathon with it, and it didn't crash or fail once [20:59:31 CEST] <vektorweg1> BtbN: i had crashs and output inconsistencies in obs. [20:59:35 CEST] <DHE> BtbN: google says no, but an opengl capture can pass it over to cuda. that's probably what I was thinking of [20:59:49 CEST] <BtbN> But how would you do OpenGL capture either? [21:00:04 CEST] <BtbN> Windows gives you D3D surfaces at best [21:00:28 CEST] <DHE> there is an opengl function that reads the framebuffer [21:00:49 CEST] <BtbN> Of another application? [21:01:25 CEST] <vektorweg1> BtbN: if there are tools that can record gl, why shouldn't ffmpeg be able to do it? [21:01:36 CEST] <DHE> Maybe? I've had programs read their own framebuffers but also pick up window overlays (eg: right-click the title bar of the application) [21:02:00 CEST] <BtbN> Because nobody wrote the sources [21:02:09 CEST] <BtbN> A large part of the OBS code base is the capture code [21:02:12 CEST] <vektorweg1> afaik, its reading the framebuffer and registering glswaps for timing. [21:02:15 CEST] <BtbN> It's well tested and mature, use it [21:02:41 CEST] <BtbN> OBS on Windows just injects a DLL and makes the game render into a texture, and sends that texture over to itself [21:02:50 CEST] <BtbN> On Linux you just can't do that [21:02:51 CEST] <vektorweg1> obs can capture a lot of other things too. [21:03:05 CEST] <BtbN> OBS can capture anything using OpenGL or D3D on Windows that way [21:05:47 CEST] <vektorweg1> hmm [21:22:01 CEST] <vektorweg1> hm. how do overlays work then? how do some programs render in the gl context of another program? [21:29:01 CEST] <BtbN> They inject a DLL, hook the swap function, and render their own stuff before actually swapping. [21:44:54 CEST] <cq1> That's clever. [21:48:06 CEST] <BtbN> It's pretty standard procedure on Windows. Even though it's batshit insane [21:48:26 CEST] <JEEB> ye, even sound drivers can do random bullshit like that [21:48:56 CEST] <JEEB> "yes we will totally filter your audio" "but it's float not integer?" "surefine.jpg" <MASSIVE NOISE> [21:53:11 CEST] <vektorweg1> i kinda happy now with pulseaudio about this, because you can pick the audio you want and not just capture everything. [21:55:04 CEST] <strangepr0gram> hello i dont kno if this is the right place to ask but is is possible using ffmpeg or something else to remove these kinds of artifacts, for example present in this video https://www.shutterstock.com/video/clip-3566666-stock-footage-rapeseed-flow… --- If you look carefully enough you can see the blocks of pixels "jump arou [21:55:04 CEST] <strangepr0gram> nd" [21:56:45 CEST] <strangepr0gram> https://www.shutterstock.com/video/clip-26536403-stock-footage-panning-shot… Can more easily be seen in this vid [22:01:12 CEST] <kiroma> Does FFmpeg use -O3 or -O2 by default? [22:02:50 CEST] <JEEB> kiroma: O2 but I think it disables a lot of the vectorization stuff [22:02:56 CEST] <JEEB> due to miscompilation cases [22:03:21 CEST] <cq1> JEEB: Woah, miscompilation? What do you mean? [22:03:57 CEST] <JEEB> basically the last time people re-enabled vectorization etc optimizations there were failures in some versions of GCC etc for some architectures [22:04:00 CEST] <BtbN> ffmpeg uses -O3 by default on clang and gcc [22:04:04 CEST] <JEEB> oh right, yes [22:04:23 CEST] <JEEB> I just remember the point of "it probably doesn't matter too much because vectorization" [22:04:32 CEST] <JEEB> (which is disabled) [22:04:50 CEST] <cq1> Bizarre. [22:05:01 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194009.html [22:05:07 CEST] <JEEB> here's parts of the mailing list discussion [22:06:10 CEST] <cq1> Very interesting, thanks for the link. [22:06:26 CEST] <cq1> I guess I am surprised that vectorization is that buggy, but I guess the codebase is pretty large. [22:07:09 CEST] <JEEB> it seems to be a thing that happens every now and then. someone tries to re-enable vectorization. it might even get to master. then people find some compiler versions or architectures where things fail. then it gets retracted again. [22:09:15 CEST] <kiroma> By the way, I've tried to compile with --enable-lto and it works but there are some warnings about type mismatches, should I be worried about them? [22:09:54 CEST] <JEEB> no idea [22:10:20 CEST] <JEEB> cq1: also do note that a lot of "heavy" stuff like H.264 or VP9 decoding has hand-written assembly in it [22:17:48 CEST] <cq1> Certainly, understood. [22:17:58 CEST] <cq1> I'm more surprised at the lack of stability than the fact that it's viable to disable it. [22:18:05 CEST] <JEEB> yea [22:18:48 CEST] <cq1> Although, I guess I shouldn't be too surprised about the lack of stability. I once discovered that the mere two lines of code struct T { std::string foobar; }; T* x = new T({""}); caused GCC 4.7.0 to spit out "internal compiler error". [22:20:21 CEST] <JEEB> of course I wonder how much you would get in some less SIMD-induced things [22:20:35 CEST] <JEEB> like HEVC decoding, which has a limited amount of SIMD but nowhere on the level of, say, VP9 [22:30:53 CEST] <Blaxar> tbh cq1: std::string is not a pointer in itself, that's why :d [22:36:21 CEST] <strangepr0gram> Another question. is there a way to easily test 2 files to see quality differences? [22:37:58 CEST] <strangepr0gram> like play both files at the same time but alternate between compressed versions each x seconds or something [22:39:29 CEST] <JEEB> for actual quality there's no better way than eyes. for metrics there's psnr and ssim etc [22:39:42 CEST] <JEEB> but do note that those do not match necessarily what the eye perceives as quality [22:39:52 CEST] <JEEB> esp. not PSNR (favours blurring like hell) [22:40:18 CEST] <JEEB> also, as usual you need to have the "original sample" [22:40:23 CEST] <cq1> Blaxar: It's valid C++, as std::string has a non-explicit constructor from const char*, and thus the conversion is implicit. Regardless, even if it were invalid C++ the compiler shouldn't spit out "internal compiler error please submit a full bug report" [22:40:30 CEST] <JEEB> you cannot do such comparisons without the source [22:40:43 CEST] <JEEB> because you do not know what you are supposed to hit closest to [22:40:54 CEST] <strangepr0gram> JEEB: yeah i know eyes [22:41:45 CEST] <strangepr0gram> i mean i convert original vid into like 5 versions and id use ffmpeg or something to play the first one for 3 seconds then the next one for 3 seconds [starting from second 3] etc u get the idea [22:41:59 CEST] <strangepr0gram> Extremely new to this [22:43:50 CEST] <JEEB> basically, if you're looking for automated calculations you will also have to try and optimize the encodes not to human psychovisuals but specifically for some metric (thus, it becomes irrelevant to make a PSNR test of encodes if your encoder tried to optimize for visual perception) [22:44:56 CEST] <JEEB> for visual comparison I would recommend getting something with which you can quickly swap between samples [22:45:22 CEST] <JEEB> (and of course whatever you have that converts the YCbCr into RGB should be known to be same in all cases) [22:45:41 CEST] <strangepr0gram> yea. [22:46:40 CEST] <JEEB> what I've recently done is load up things with ffms2 or lwlibavvideosource in vapoursynth, and then use something like vapoursynth editor to preview [22:46:52 CEST] <JEEB> not playback, but lets you compare things [22:47:13 CEST] <JEEB> (you should generally compare things in motion) [22:47:17 CEST] <markmedes2> Hello! I have a question: Is it possible to force ffmpeg to ignore input errors and continue encoding? I tried -err_detect ignore_err but it's not working [22:48:44 CEST] <kiroma> What input errors are you getting? [22:49:39 CEST] <markmedes2> Invalid data found when processing input [22:49:44 CEST] <markmedes2> That's on the audio stream [22:52:50 CEST] <markmedes2> I'm using ffmpeg to re-encode isdb-t video files from digital television, and the files usually have lots of errors due to the nature of airway transmissions and 4G interference [22:59:39 CEST] <markmedes2> kiroma: https://pastebin.com/DCYGzmqQ [23:00:16 CEST] <markmedes2> now I see it's in the video stream, not the audio [23:02:13 CEST] <markmedes2> error while decoding MB 98 49, bytestream -8 [23:15:20 CEST] <c_14> use one of the values for -ec I guess (guess_mvs, deblock, favor_inter) [23:15:50 CEST] <markmedes2> is that hint for me? [23:16:17 CEST] <c_14> yes [23:16:27 CEST] <markmedes2> ah ok, lemme check that [23:16:53 CEST] <c_14> It's in the manpages, search for conceal [23:20:01 CEST] <markmedes2> gonna take something close to an hour to test this flag, cause the error is at 01:58:30.31 and ffmpeg scan the whole file even if I use -ss [23:22:23 CEST] <kiroma> put -ss before -i to skip most of the file [23:22:41 CEST] <markmedes2> k [23:23:33 CEST] <markmedes2> brilliant [23:36:28 CEST] <markmedes2> I'm I doing this right? Cause none of the -ec flags worked [23:36:56 CEST] <markmedes2> time ffmpeg -ss 02:13:00 -i /home/user/mnt2/HBPVR/AMENINAROUBLIVROS.mts -to 02:16:00 -filter:v scale="640:trunc(ow/a/2)*2" -map 0:0 -map 0:1 -map 0:2 -vcodec libx264 -crf 20 -c:a copy -err_detect ignore_err -ec favor_inter /home/user/Desktop/output_favorinter.avi [00:00:00 CEST] --- Mon Aug 7 2017

1 0