Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2017

1 participants
62 discussions

ffmpeg-devel.log.20170530
by burek 31 May '17

31 May '17

[00:46:30 CEST] <Shiz> is that the classic replace-\n-using-sed trick [00:47:44 CEST] <iive> btw, there is `todos` and `fromdos` for easier conversion. [00:48:42 CEST] <atomnuker> of course there is since sed does such a horrible job at anything but letters [00:51:06 CEST] <wm4> atomnuker: why do you think sed has to be sane [00:51:11 CEST] <wm4> it's old unix bullshit [00:51:17 CEST] <wm4> like... shell [00:51:45 CEST] <wm4> it was sane for a brief moment, and then grew feature tentacles [00:52:40 CEST] <Shiz> shell was never sane [00:52:42 CEST] <Shiz> dont li [00:52:45 CEST] <Shiz> e [00:58:19 CEST] <wm4> come on, everyone agrees that "cp FILEA FILEB" looks sane [00:58:36 CEST] <wm4> until they learn about filenames that start with "--" or which contain newline characters [01:01:22 CEST] <Shiz> let's start with arrays in shell [04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:d90c5bf10559: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int' [04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:4020b009d1e8: avcodec/wavpack: Check float_shift [04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:87bddba43b72: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float' [10:38:07 CEST] <nevcairiel> neat, AVX-512 confirmed for Skylake-X consumer CPUs (well, HEDT, some people might not consider that very "consumer") [10:39:45 CEST] <rcombs> the i9s and such? [10:40:02 CEST] <nevcairiel> yea [10:40:28 CEST] <rcombs> nice [10:40:33 CEST] <rcombs> (what's HEDT?) [10:40:47 CEST] <nevcairiel> High-End Desktop Platform [10:41:03 CEST] <nevcairiel> what intel calls their X line of CPUs/motherboards [11:04:59 CEST] <BtbN> Aparently the X299 chip is identical to the Z270 [11:05:02 CEST] <BtbN> Not even USB 3.1 [11:13:46 CEST] <nevcairiel> should have usb 3.1 gen 1 [11:13:50 CEST] <nevcairiel> not gen 2 tho [11:14:01 CEST] <BtbN> gen1 is just 3.0 anyway [11:14:56 CEST] <nevcairiel> of course with that amount of PCIe lanes and IO flexibility, board makers are just going to include it anyway [11:15:15 CEST] <nevcairiel> could even use intels alpine ridge controller [11:15:19 CEST] <BtbN> sure, but so far every one of those ASmedia controler I came in contact with was hot trash [11:15:58 CEST] <atomnuker> those controllers really heat up when there's a usb-c device connected [11:16:06 CEST] <atomnuker> not good for power consumption [11:16:20 CEST] <nevcairiel> its a system with a 140W+ CPU, noone cares =p [11:16:31 CEST] <atomnuker> oh yeah, forgot [11:16:45 CEST] <BtbN> The 140W aren't even that crazy for that many cores though [11:17:07 CEST] <nevcairiel> rumors have the 14, 16 and 18 core models at 165W [11:17:10 CEST] <nevcairiel> but it wasnt confirmed [11:17:39 CEST] <BtbN> The one I'd be interested in would be the 10 core variant, i9-7900 I think [11:17:50 CEST] <BtbN> But for now my Ryzen 8 core will work [11:18:05 CEST] <BtbN> If they ever fix the non-CPU PCIe Lanes, that is [11:18:06 CEST] <nevcairiel> yeah the 10-core is what I'm looking at [11:18:46 CEST] <nevcairiel> would be a decent upgrade from my 6 core [11:19:12 CEST] <nevcairiel> and i can probably put it off as a business expense [11:19:22 CEST] <nevcairiel> my tax guy keeps telling me to spend more [11:19:22 CEST] <nevcairiel> :p [11:21:27 CEST] <BtbN> I just got myself a nice AMD 8 core [11:21:35 CEST] <BtbN> don't think I'm in need for an upgrade anytime soon [11:21:47 CEST] <rcombs> does SKL-X need special motherboards, or will it work with regular SKL ones? [11:22:04 CEST] <nevcairiel> needs a X299 motherboard [11:22:17 CEST] <nevcairiel> it has a much higher pin count then consumer boards [11:22:25 CEST] <nevcairiel> 2066 pins vs 1500~ something [11:22:31 CEST] <nevcairiel> for all the extra PCIe lanes [11:22:51 CEST] <BtbN> It's a diffrent socket, because 44 instead of just 16 lanes, and more memory channels [11:23:22 CEST] <BtbN> AM4 has 1300 or something [11:23:27 CEST] <BtbN> And they still use a PGA... [11:23:35 CEST] <BtbN> I was very nervous while handling that [11:23:45 CEST] <BtbN> bend one of them, and 600¬ are gone [11:24:17 CEST] <nevcairiel> i wonder if the threadripper socket finally gets rid of that [11:24:26 CEST] <BtbN> it has to [11:24:47 CEST] <BtbN> unless the casing of the CPU is massively huge, you can't get the required pin density with a PGA [11:24:53 CEST] <nevcairiel> i guess [11:25:19 CEST] <BtbN> AM4 is probably about as dense as you can get [11:27:00 CEST] <nevcairiel> the threadripper SP3r2 socket presumably has 4094 pins, even with a LGA design thats going to be massive of a chip [11:30:06 CEST] <nevcairiel> interesting will be how the NUMA-like behavior of the intel high core count CPUs will behave in consumer workloads (that affects that 14-18 core CPUs only, which are on a different die design then the 6 to 12 cores) [11:30:30 CEST] <BtbN> So they also went for an AMD like multi-CCX design? [11:30:40 CEST] <nevcairiel> not exactly [11:30:50 CEST] <nevcairiel> intel has had these designs in Xeons for years [11:31:03 CEST] <nevcairiel> they just moved one design down into the consumer space [11:31:14 CEST] <BtbN> I just hope AMD fixes the Fabric-Clock being tied to the RAM clock thingy [11:31:40 CEST] <BtbN> Intel has a 2GHz QPI since forever [11:31:40 CEST] <nevcairiel> its sitll one huge singular die, but due to the sheer a mount of cores the caching and memory access gets ..complicated [11:32:01 CEST] <nevcairiel> so the latency can vary depending on which part of the L3 you access [11:33:00 CEST] <BtbN> You'd need to run Ryzen with DDR4-4000 to be roughly on par with Intel [11:33:14 CEST] <BtbN> Which is now possible, with the new AGESA code [11:33:17 CEST] <nevcairiel> i hear they finally actually made it possible to do that [11:33:28 CEST] <BtbN> But only with 2x8GB single ranked [11:33:32 CEST] <nevcairiel> also 4000 is quite high [11:33:52 CEST] <BtbN> I have 2x16GB, dual rank. Impossible to even hit the advertised 3200 [11:34:22 CEST] <nevcairiel> i run 4x8 3200, but i'm on X99 [11:36:11 CEST] <nevcairiel> (now that chipset platform has been getting old) [11:38:06 CEST] <BtbN> X99 seems still decent to me [11:38:21 CEST] <BtbN> With the 40 lanes coming from the CPU, you have no real need for PCIe 3.0 from the chipset [11:38:34 CEST] <BtbN> And it offers USB3.0, the new chipsets don't offer anything more [11:41:56 CEST] <kierank> Still not pcie 4.0 sadly [11:44:15 CEST] <Gramner> the PCI-e 4.0 spec isn't even finalized yet so that's hardly surprising [11:48:46 CEST] <Gramner> it seems to have been delayed for some time. high bandwidth over copper is getting hard [11:49:36 CEST] <Gramner> wouldn't surprise me if the next gen is optical [11:49:50 CEST] <BtbN> you'd still need to connect it to copper somewhere [11:50:15 CEST] <Gramner> of course, but that'd result in much shorter copper wires [11:50:53 CEST] <BtbN> I really wonder why they went for copper Thunderbolt [11:50:57 CEST] <BtbN> instead of something optical [11:51:08 CEST] <Gramner> cost most likely [11:51:27 CEST] <BtbN> the cost of a fiber optic cable is lower than for a copper one [11:51:44 CEST] <Gramner> cables yes, everything else no [11:52:12 CEST] <Gramner> but optics have been getting cheaper steadily [11:56:25 CEST] <iive> the fiber optic cables are cheap, but the receivers and transmitters are not, and they consume a lot of power [11:57:10 CEST] <iive> they are great for long distances, but for something inside the computer.... [11:58:10 CEST] <BtbN> you don't need a lot of energy for a few cm of optic wire [11:58:12 CEST] <atomnuker> they're not cheap, I looked for a 100m cable and prices were around 48 to +150 gbp [11:58:27 CEST] <atomnuker> also connectors matter a lot, lcs are cheap but the rest [11:58:31 CEST] <Gramner> the optics you'd use for sub-meter range is vastly different than what you'd use for 10km [11:59:02 CEST] <atomnuker> for such lengths also grade doesn't really matter so you can get high grade stuff for cheap from china [11:59:36 CEST] <atomnuker> but the transceivers are really horridly expensive proprietary pieces of shit you can't use if the vendors don't match [12:00:53 CEST] <Gramner> ethernet stuff (e.g. SFP, SFP+) is standardized. they just hardcode the brand into the id string and refuse to work unless it matches. so you just buy 3rd party ones with the correct id string set and no problems [12:01:52 CEST] <Gramner> 1st party SFPs are expensive as hell, 3rd party ones dirt cheap and they work just fine [12:02:03 CEST] <atomnuker> you can't reprogram them though [12:02:41 CEST] <Gramner> not sure why you'd need to do that unless you decide to swap brand of all your switches for some reason [12:02:46 CEST] <atomnuker> I think its best to just hunt on ebay for media converters and transceivers from old servers and treat them as one unit [12:03:02 CEST] <Gramner> and if you do that, just buy new SFPs since that's insignificant compared to the cost of switches [12:03:19 CEST] <BtbN> The SFP electric connection is standardized [12:03:20 CEST] <atomnuker> problem is alot of those media converters are +10 years old and don't do gigabit [12:03:21 CEST] <BtbN> not the protocol [12:09:04 CEST] <Gramner> never looked into the implementation details of it, all I know is that third party ones work perfectly fine and are cheap enough to just buy hundreds of them at a time [12:09:37 CEST] <BtbN> You can usually select a compatiblity option with the third party ones [12:09:45 CEST] <BtbN> to specify in which device they are supposed to run [12:09:51 CEST] <Gramner> yes, that's what I do [12:09:53 CEST] <BtbN> https://www.gbic-shop.de/en/products/transceivers/sfp/copper-rj45-sfp/bo08c… [12:10:31 CEST] <Gramner> ¬49 is expensive though [12:10:50 CEST] <BtbN> for a gigabit RJ45, yeah [12:11:32 CEST] <atomnuker> (meanwhile 100m cat5e goes for barely 18 pounds here) [12:12:03 CEST] <Gramner> I usually go with the fancy WDM ones so only one fiber is needed instead of a pair [12:29:25 CEST] <rcombs> do the transceivers tend to introduce any significant latency? [12:29:52 CEST] <rcombs> also optical gives you fun awkwardness if dust gets anywhere [12:30:22 CEST] <nevcairiel> getting dust inside the connectors can also be awkward with elictrical [12:30:29 CEST] <nevcairiel> electrical* [12:30:42 CEST] <BtbN> From my experience the latency with SFP(+) cards is slightly lower than with RJ45 copper [12:30:43 CEST] <rcombs> yeah, but it's generally not as sensitive, is it? [12:31:08 CEST] <rcombs> huh, surprising [12:31:40 CEST] <bencoh> once plugged, you should be fine [12:31:54 CEST] <rcombs> yeah, it's more a concern when not [12:32:06 CEST] <bencoh> and I have seen optical equipments in heavily dusty rooms [12:32:09 CEST] <bencoh> no problems there [12:32:28 CEST] <bencoh> s/seen/operated/ even [12:32:30 CEST] <rcombs> even if left unmated and uncapped? [12:32:44 CEST] <nevcairiel> well dust it off before use? :) [12:32:51 CEST] <bencoh> iirc some were, yes [12:33:03 CEST] <rcombs> I guess maybe I'm thinking of the actual fibers [12:33:11 CEST] <nevcairiel> and equipment needing proper handling (ie. capping them) should be a given [12:33:21 CEST] <bencoh> (although I usually managed to keep those capped) [12:33:23 CEST] <rcombs> apparently you've gotta polish them before putting connectors on [12:33:32 CEST] <rcombs> but that's not a concern for consumer electronics handling [12:33:40 CEST] <rcombs> nevcairiel: yeah but consumers aren't gonna reliably do that [12:33:43 CEST] <JEEB> the U-SDI stuff at NHK with fiber stuff was fun [12:33:45 CEST] <Gramner> you are supposed to have connectors capped and clean them when inserting a patch [12:34:49 CEST] <Gramner> although normal 1GbE optics are not actually that sensitive generally unless we're talking really large distances [12:36:59 CEST] <rcombs> I find it hard to imagine optical beating copper on latency over a few cm [12:37:34 CEST] <rcombs> matching, even, seems difficult [12:38:45 CEST] <bencoh> rcombs: because of the (supposedly?) added latency of the transceiver? [12:38:55 CEST] <rcombs> yeah [12:39:16 CEST] <rcombs> are optical transceivers much simpler than I'm thinking they are? [12:39:32 CEST] <rcombs> like, literally an LED on one side and a photodiode on the other? [12:39:34 CEST] <Gramner> which for high-speed transcievers is in the order of a few hundred nanoseconds [12:40:05 CEST] <Gramner> can probably get it even lower if that's a design goal I guess [12:40:14 CEST] <bencoh> rcombs: I'd say copper has a transceiver of some sort as well [12:40:17 CEST] <bencoh> just usually on-board [12:41:02 CEST] <bencoh> (you know, the PHY at the other end of your (R)(G)MII) [12:41:16 CEST] <rcombs> keep in mind I have no idea what I'm talking about [12:41:22 CEST] <bencoh> ah :) [12:41:44 CEST] <rcombs> most hardware work I've done is hooking an atmega328p up to an N64's controller port [12:41:55 CEST] <rcombs> 1MHz signaling! waow! [12:42:03 CEST] <rcombs> much fast [13:04:41 CEST] <ubitux> in ps_hybrid_analysis_c [13:04:47 CEST] <ubitux> INT64FLOAT sum_re = (INT64FLOAT)filter[i][6][0] * in[6][0]; [13:04:49 CEST] <ubitux> INT64FLOAT sum_im = (INT64FLOAT)filter[i][6][0] * in[6][1]; [13:04:53 CEST] <ubitux> is this really correct? [13:05:12 CEST] <ubitux> like, shouldn't it be filter[i][6][1] for sum_im? [13:07:22 CEST] <ubitux> atomnuker: maybe you have an idea? [13:08:33 CEST] <atomnuker> certainly seems that way, though peloverde wrote that code so he would know better [13:09:59 CEST] <sigdrak> im*im = re [13:10:18 CEST] <iive> j*j=-1 ? [13:11:17 CEST] <ubitux> iiuc it's the simplified equivalent of (INT64FLOAT)filter[i][6][0] * (in[6][1] + in[ 6][1]) + (INT64FLOAT)filter[i][6][1] * (in[6][0] + in[6][0]) [13:11:39 CEST] <ubitux> (the [1] are the im and the [0] are the re) [13:12:13 CEST] <ubitux> so maybe some properties i'm not aware of cancel things out the same way for both sum [13:13:01 CEST] <ubitux> sorry i meant sum_im = filter[i][6][0] * (in[6][1] + in[ 6][1]) + filter[i][6][1] * (in[6][0] - in[6][0]) [13:13:52 CEST] <ubitux> and sum_re = filter[i][6][0] * (in[6][0] + in[ 6][1]) - filter[i][6][1] * (in[6][1] - in[6][1]) [13:14:18 CEST] <ubitux> dammit, sum_re = filter[i][6][0] * (in[6][0] + in[ 6][0]) - filter[i][6][1] * (in[6][1] - in[6][1]) [13:18:17 CEST] <ubitux> so, to simplify [13:18:20 CEST] <ubitux> if we have: [13:18:22 CEST] <ubitux> sum_re = filter_re[i][6] * (in_re[6] + in_re[6]) - filter_im[i][6] * (in_im[6] - in_im[6]) [13:18:24 CEST] <ubitux> sum_im = filter_re[i][6] * (in_im[6] + in_im[6]) + filter_im[i][6] * (in_re[6] - in_re[6]) [13:18:27 CEST] <ubitux> does it simplifies to: [13:18:40 CEST] <ubitux> sum_re = filter_re[i][6] * in_re[6] [13:18:41 CEST] <ubitux> sum_im = filter_re[i][6] * in_im[6] [13:18:53 CEST] <ubitux> or to: [13:18:54 CEST] <ubitux> sum_re = filter_re[i][6] * in_re[6] [13:18:56 CEST] <ubitux> sum_im = filter_im[i][6] * in_im[6] [13:18:58 CEST] <ubitux> ? [13:22:36 CEST] <J_Darnley> Is anyone in the middle of doing a merge? [13:26:00 CEST] <cousin_luigi> Greetings. [13:27:28 CEST] <wm4> ok I think I'll write a BSF that attempts to fix timestamps of the second field each on interlaced h264 [13:27:33 CEST] <wm4> is that a good or a bad idea [13:27:51 CEST] <wm4> I need it for proper remuxing of interlaced h264 [13:28:06 CEST] <cousin_luigi> Does ffmpeg 2.8.x still need an external dcadec? [13:28:20 CEST] <wm4> "fixing" would mean changing broken timestamps or filling in missing ones [13:31:10 CEST] <kierank> wm4: derek has the same problem [13:31:34 CEST] <kierank> why has this behaviour changed all of a sudden [13:31:44 CEST] <wm4> which derek [13:32:09 CEST] <kierank> daemon404 [13:32:11 CEST] <wm4> I think my immediate problem is that the .ts captured from a tuner doesn't have PTS for the second field [13:32:18 CEST] <wm4> when, where? [13:32:20 CEST] <kierank> ah, not a lavf problem then [13:32:31 CEST] <wm4> lavf fails to remux this anyway [13:32:47 CEST] <wm4> we had this great idea of setting a random timestamp to make lavf happy [13:32:52 CEST] <kierank> 4:13 PM <Daemon404> so libavformat outputs two packets per frame with AVC PAFF [13:32:52 CEST] <kierank> 4:13 PM <Daemon404> it used to be that both these packets had the same PTS (sicne there is only one output frame) [13:32:52 CEST] <kierank> 4:13 PM <Daemon404> how it interpolates some made up bullshit [13:32:55 CEST] <wm4> now we have broken files which we also need to deal with [13:33:06 CEST] <kierank> second field without pts is not illegal [13:33:26 CEST] <wm4> at the very least it's annoying [13:33:39 CEST] <ubitux> J_Darnley: not right now, probably tomorrow [13:33:46 CEST] <wm4> and of course lavf doesn't always detect the correct framerate either (which would making it up make simpler) [13:33:56 CEST] <wm4> so does MBAFF not have separate slices? [13:34:07 CEST] <J_Darnley> cousin_luigi: No idea about 2.8 but the current master claims to have a dts/dca codec [13:34:27 CEST] <J_Darnley> I suggest you check the changelog [13:34:38 CEST] <wm4> J_Darnley, cousin_luigi: ffmpeg has replaced the dts decoder with the code from libdcadec since a while ago [13:34:42 CEST] <wm4> not sure when [13:34:43 CEST] <cousin_luigi> J_Darnley: IKR, I know it had been integrated, but some distros still package 2.8.x [13:35:02 CEST] <cousin_luigi> Just wondering if the same had happened with older branches. [13:35:11 CEST] <BtbN> nevcairiel, https://1.f.ix.de/imgs/18/2/2/1/1/3/7/6/IMG_0440-afac0d91999b29e3.jpeg yep, definitely huge. [13:35:18 CEST] <kierank> wm4: mbaff has single picture per frame [13:35:32 CEST] <kierank> J_Darnley: go go go [13:35:42 CEST] <J_Darnley> cousin_luigi: the changelog says it was added in 3.0 [13:35:51 CEST] <cousin_luigi> J_Darnley: Perfect. Thanks. [13:36:01 CEST] <J_Darnley> wait a mo [13:36:01 CEST] <wm4> kierank: man that's horrible [13:36:17 CEST] <J_Darnley> it also says "DTS decoding through libdcadec" for 2.7 [13:36:18 CEST] <wm4> I had this idea always using separate packets/AVFrame for each fields would make interlacing not a PITA [13:36:28 CEST] <kierank> you can't that's the problem [13:36:31 CEST] <wm4> but that sounds like mbaff forces a single packet and frame [13:36:31 CEST] <kierank> the stream can adapt at will [13:36:38 CEST] <wm4> and that too [13:36:40 CEST] <wm4> jesus christ [13:36:50 CEST] <cousin_luigi> J_Darnley: Yes, so I still need to link against it. That's all I needed to know. [13:36:56 CEST] <cousin_luigi> Unless it was backported. [13:37:37 CEST] <cone-326> ffmpeg 03James Darnley 07master:8e89f6fd3735: avcodec/x86: move simple_idct to external assembly [13:37:37 CEST] <cone-326> ffmpeg 03James Darnley 07master:0dea0114fb29: avcodec/x86/idctdsp_init: reindent [13:37:51 CEST] <kierank> !!! [13:38:27 CEST] <wm4> J_Darnley: nice [13:38:36 CEST] <wm4> is there any important inline asm left? [13:38:44 CEST] <cousin_luigi> Thanks & bbl. [13:38:45 CEST] <BtbN> I wonder what that 9th memory slot is for. For some Optane-Persistent-Memory-Thing? [13:39:30 CEST] <wm4> kierank: so given this pain, why does mp4 mandate separate packets for field slices? [13:39:38 CEST] <wm4> doesn't that make it worse [13:42:31 CEST] <wm4> kierank: also do I get this right: PAFF: separate field slices (each which decode on their own, more or less, but can easily decoded to an interleaved frame), MBAFF = single slice that decodes to an interleaved frame? [13:43:18 CEST] <kierank> correct [13:45:33 CEST] <wm4> kierank: and it's normal that streams switch between those on demand? somehow I thought that's what MBAFF is supposed to do on the macroblock level [13:45:50 CEST] <kierank> mbaff helps coding "mostly progressive" pictures [13:45:58 CEST] <kierank> paff helps with prediction between fields [13:46:39 CEST] <wm4> hm I guess it makes sense that paff seems to happen more in scenes with actual motion? [13:46:53 CEST] <kierank> yes [13:48:00 CEST] <wm4> I guess that's the reason why those second fields don't have PTS - they're missing for MBAFF coded frames anyway [13:51:52 CEST] <kierank> huh [13:52:06 CEST] <kierank> they don't have PTS because you don't need PTS in mpegts for some proportion of frames [13:52:13 CEST] <kierank> and the world is cfr so who cares [13:52:22 CEST] <kierank> it's only FOSS that's obsessed with vfr [13:53:28 CEST] <wm4> last I checked mp4 is obsessed with having correct timestamps too [13:54:54 CEST] <kierank> pts + fps [13:54:54 CEST] <kierank> done [14:40:22 CEST] <saulotoledo> Hello all. I need some help to understant the MPEG TS: A TS packet can contain an extended section, used as a "container" for PAT and PMT, for example. In a header of an extended section there are 2 parameters I do not understand: "versionNumber" and "currentNextIndicator". Can somebody help me to understand what they are used for? [14:41:08 CEST] <saulotoledo> *understand [14:43:32 CEST] <kierank> you change the pmt, you change the version [14:43:33 CEST] <kierank> simples [14:50:29 CEST] <saulotoledo> kierank: thanks! When will you need to change the PMT? It should not be the same for the same program? [14:50:44 CEST] <kierank> change the language or whatever [14:51:00 CEST] <kierank> but imo it's meaningless the version [14:51:05 CEST] <kierank> just check the cc for discontinuity and resync [14:52:28 CEST] <saulotoledo> kierank: ok :) And about the currentNextIndicator? [14:52:48 CEST] <kierank> dunno why that's their [14:52:51 CEST] <kierank> to preroll content i guess [15:02:37 CEST] <saulotoledo> kierank: kierank: These are the explanations I have about that field: "now or next either table to be used for current event transmissions or for future" or yet "When the values is defined in 1 indicates that the sent Program Association Table (PAT) is valid and applicable in the moment. When the this value is 0 indicates that the sent table is not applicable and the system must await for the next v [15:03:42 CEST] <saulotoledo> kierank: The strange thing is I do not understand when a PAT is not applicable. [15:03:53 CEST] <kierank> when they are going to change the pat [15:05:57 CEST] <saulotoledo> kierank: Why will they send a package that is useless? It makes sense to send a package that will be used for a future PAT? [15:07:58 CEST] <saulotoledo> kierank: I may be receiving a packet containing a PMT and currentNextIndicator = 0. I still do not understand when this can happen. [15:08:16 CEST] <kierank> saulotoledo: dunno, it's a theoretical problem [15:08:19 CEST] <kierank> i doubt anyone uses that [15:14:11 CEST] <saulotoledo> kierank: ok. So the idea is that the last sent PAT table will be changed and the package will be pointed in a future PAT table? [15:14:27 CEST] <kierank> dunno [15:15:50 CEST] <saulotoledo> kierank: ok :) You helped me a lot, anyway. Really thanks! [15:19:21 CEST] <saulotoledo> kierank: Ah! Just a last question about the version number: If I am receiving another table (AIT? or anything else than a PAT), the version number is related to the last PAT or to the current content? [16:01:39 CEST] <wm4> Paranoialmaniac: what's the reason matroskadec doesn't parse on hevc? (you added this code) [16:02:20 CEST] <wm4> not that I have a problem or bug with it, just curious [17:28:12 CEST] <Paranoialmaniac> wm4: you can extract codec parameters from extradata, and one access unit per packet is guaranteed. so i think the parser is not needed for matroska [17:29:08 CEST] <wm4> AVSTREAM_PARSE_HEADERS doesn't try to split packets, it only tries to extract information from them [17:42:49 CEST] <atomnuker> ubitux: seems like a polyfuse got tripped because the odroid works fine now [17:42:51 CEST] <Paranoialmaniac> wm4: but parameter sets are conveyed out-of-band like mp4. not together with any access unit. [17:43:41 CEST] <wm4> in theory, but there are all kinds of reasons why libavformat/utils.c wants to look at packet contents anyway [17:43:44 CEST] <wm4> unfortunately [17:43:51 CEST] <Paranoialmaniac> :( [17:46:53 CEST] <wm4> also fuck the timestamp garbage in libavformat/utils.c and ffmpeg.c [17:48:13 CEST] <kierank> wm4: the undocumented garbage [17:48:16 CEST] <kierank> that's the probelm [17:48:21 CEST] <wm4> no, all of it [17:48:23 CEST] <kierank> if there were comments saying *do x because of y* [17:48:50 CEST] <wm4> currently I'm dealing with it generating invalid dts from the unreliable mkv framerate field [17:49:00 CEST] <wm4> which breaks even mkv->mkv remuxing [17:55:48 CEST] <kierank> ah well that's mkvs fault [17:55:50 CEST] <kierank> for not having dts [17:59:42 CEST] <wm4> except for that whole thing that ffmpeg.c wouldn't need DTS in this case [18:01:03 CEST] <wm4> also didn't you say that timestamps don't matter [18:01:06 CEST] <wm4> so which is it [18:07:55 CEST] <wm4> oh, it does not compute dts from durations [18:08:01 CEST] <wm4> so I'm completely lost [18:50:07 CEST] <kevmark> Hey everyone. Currently working on this patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211719.html My question is what is the best way to submit an updated patch? I tried to do that here: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211786.html By using git send-email with the --in-reply-to option. It seems to work as expected except it created a new patch in Patchwork. Is that the desired behavior? [18:54:15 CEST] <jamrial> kevmark: the patch subject is different, so maybe that's why [18:54:59 CEST] <kevmark> jamrial, okay, so when submitting an updated patch it's critical to use the same subject even if the first line of the git commit has changed? [18:55:17 CEST] <JEEB> no [18:55:24 CEST] <JEEB> as long as the in-reply-to is correct [18:55:39 CEST] <JEEB> patchwork can be meh [18:56:06 CEST] <kevmark> Okay, so how I approached it is fine? [18:56:08 CEST] <JEEB> since there is no UUIDs in the e-mail I guess [18:56:38 CEST] <JEEB> well yea, if your in-reply-to was correct then that's all that matters really. patchwork not finding it is unfortunate but I think that's how it has been for me as well [18:57:50 CEST] <kevmark> Okay great, Pipermail has the original patch as the "Previous message (by thread)" so it looks good [18:59:45 CEST] <kevmark> Thanks for my help. First patch to FFmpeg (and really any project that uses this form of patch submission) so I'm just trying to familiarize myself with the workflow. [18:59:50 CEST] <kevmark> *Thanks for the help [00:00:00 CEST] --- Wed May 31 2017

1 0

ffmpeg.log.20170530
by burek 31 May '17

31 May '17

[00:05:15 CEST] <DHE> so, no ideas? [01:36:26 CEST] <bob_twinkles> is there a good way to get the ffmpeg CLI tool to print its status lines as seperate lines, instead of being cute and rewritting the same line over and over again? [01:50:54 CEST] <bob_twinkles> DHE: are you getting any messages about dropped frames? [01:51:38 CEST] <CoJaBo> you can always pipe the output to something [01:52:17 CEST] <bob_twinkles> it has to go to stdout so it'll land in the CloudWatch logs =/ [01:53:21 CEST] <bob_twinkles> (I'm running a bunch of video transcoding jobs in The Cloud since I don't have a machine powerful enough to do the job locally) [01:54:12 CEST] <CoJaBo> Something like tr should be able to change the \r to \n, then spit it out to stdout still [02:12:23 CEST] <bob_twinkles> hrm [02:12:39 CEST] <bob_twinkles> looks like it might have been me misunderstanding how cloudwatch batches events [02:13:02 CEST] <bob_twinkles> seems they agregate similar lines together and I'm not doing the right incantation to get that to flush [02:16:48 CEST] <DHE> bob_twinkles: pretty sure not.. [03:02:24 CEST] <frW1> i have 250,000.00 USdollar to invest , what should i buy [03:12:17 CEST] <c3-Win> frW1: A life. [03:12:52 CEST] <frW1> c3-Win huh [03:16:40 CEST] <furq> it is extremely normal that you have a different nick every time you ask this [03:17:16 CEST] <frW1> furq i don't remember the last nick i used [03:17:28 CEST] <frW1> furq if you don't remember the last nick you used, then what would you do [03:17:42 CEST] <dystopia_> doesn't #ffmpeg require a registered nick :O [03:17:50 CEST] <furq> well for starters i wouldn't ask #ffmpeg for financial advice [03:17:58 CEST] <furq> but then it's debatable whether that's what you're doing [05:19:38 CEST] <m712> hello [05:20:10 CEST] <m712> i am trying to copy part of a video and an audio stream from an mkv to another mkv [05:20:38 CEST] <m712> however the location i set in -ss doesn't have a keyframe, so the video skips to 2-3 seconds in [05:20:57 CEST] <m712> how can i make ffmpeg encode a first keyframe? [05:23:11 CEST] <teratorn> m712: you can't do that while using vcodec copy [05:23:56 CEST] <m712> i don't want to re-encode the entire thing though :/ [05:24:33 CEST] <m712> because when i reencode there are visible artifacts in the video [05:25:05 CEST] <m712> is there really no way to encode the first frame as a keyframe and copy the rest? [05:25:51 CEST] <teratorn> m712: unfortunately not [05:26:34 CEST] <teratorn> m712: https://trac.ffmpeg.org/wiki/Seeking [05:27:19 CEST] <teratorn> m712: maybe you can get rid of the artifacts if you play with the codec parameters [05:27:27 CEST] <m712> maybe [05:28:39 CEST] <m712> i was thinking this though: i can re-encode one frame with exactly the same codec and same parameters, and then concatenate it with the original video with v:copy, one frame off [05:29:09 CEST] <teratorn> I was hoping I might be able to implement this feature (opportunistically copy GOPs while re-encoding beginning/ending keyframes to give frame-accurate seeking), but it's more involved than I hoped as the "copy" codec isn't a real codec at all, and has special handling in the front-end [05:31:21 CEST] <teratorn> m712: hmm. how would you do the concatentaiton? [05:31:31 CEST] <teratorn> *concatenation [05:31:34 CEST] <m712> i think there was a filter like that [05:31:48 CEST] <teratorn> concat filter, yes, but filters imply not using the copy codec [05:31:49 CEST] <m712> i've done concatenation before, i forgot how to [05:31:54 CEST] <teratorn> cuz filters deal in raw frames [05:33:12 CEST] <m712> well, i'll give it a shot when i get home and share my findings (about 11 hours from now) [05:33:33 CEST] <teratorn> hmm ok actually there is a "concat" format too, not just the concat filter [05:33:43 CEST] <teratorn> https://trac.ffmpeg.org/wiki/Concatenate [05:34:03 CEST] <m712> i've re-encoded it right now but as i said, there's ugly artifacts because of lossy encoding [05:35:00 CEST] <m712> https://trac.ffmpeg.org/wiki/Concatenate#samecodec seems to be what i need, i'll give it a shot [05:35:54 CEST] <teratorn> yeah I guess you can do a frame-accurate cut from your starting point till the next key-frame, but how do you know when that is? [05:36:34 CEST] <m712> i can use mpv to find out the timecode [05:37:00 CEST] <m712> mpv can show timecodes to the millisecond [05:37:21 CEST] <m712> if i pause and try to seek to the beginning it will land on the first keyframe [08:11:59 CEST] <m712> so how's life [09:59:38 CEST] <Guest8925> Hello, I am facing a segfault in avcodec_video2 when using ffmpeg libs on Android (Unity app). all infos can be found here : https://pastebin.com/7BNPgcmT. Let me know if can help me, i'm really stuck here. If you need more infos, please ask me. Thanks! [11:13:59 CEST] <livingbeef> I have something like 'ffmpeg -i a.png -i 'b.png' -i 'c.png' -lavfi [0]copy[x0],[x0][1]overlay=331:139[x1],[x1][2]overlay=109:139[x2] -map [x2] -y result.png [11:14:41 CEST] <livingbeef> and the result is kinda blurry. Any idea what's the cause? [11:18:05 CEST] <livingbeef> Oh, never mind, I'm an idiot. It uses yuv420 as the default format, png is obviously using rgb. [13:26:14 CEST] <cousin_luigi> Greetings. [14:14:19 CEST] <aaap> hello guys [15:09:17 CEST] <dantedevil> hi i have an error with motion, somebody can help me??? I have a Raspberry pi 3 and i use motion with 3 ipcamera. but ihave same error in my log file, as"[ERR] [ENC] [May 29 19:36:37] ffmpeg_avcodec_log: cabac decode of qscale diff failed at 21 21 [15:09:18 CEST] <dantedevil> [ERR] [ENC] [May 29 19:36:37] ffmpeg_avcodec_log: error while decoding MB 21 21, bytestream 5013" [15:32:19 CEST] <dantedevil> hi i have an error with motion, somebody can help me??? I have a Raspberry pi 3 and i use motion with 3 ipcamera. but ihave same error in my log file, as"[ERR] [ENC] [May 29 19:36:37] ffmpeg_avcodec_log: cabac decode of qscale diff failed at 21 21 [15:32:19 CEST] <dantedevil> [ERR] [ENC] [May 29 19:36:37] ffmpeg_avcodec_log: error while decoding MB 21 21, bytestream 5013" [15:39:46 CEST] <aaap> hello guys [15:39:53 CEST] <aaap> may i know what is the meaning of this? [15:39:53 CEST] <aaap> [libx264 @ 0x2c415a0] height not divisible by 2 (678x777) [15:39:54 CEST] <aaap> Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [15:42:15 CEST] <DHE> aaap: exactly what it says. 777 (image width) is an odd number [15:42:38 CEST] <DHE> err, height. not width [15:46:34 CEST] <Zypho> I am noticing some extra noise and grain when encoding mp4 => hls using the source bitrate. Should I try to build HLS 2-pass support or lower the CPU preset (using medium) to resolve this? [15:46:57 CEST] <Zypho> x264 codec btw [15:49:46 CEST] <aaap> DHE, this is what command i use: [15:49:47 CEST] <aaap> ffmpeg -f concat -safe 0 -i input.txt output.mp4 [15:49:57 CEST] <aaap> input.txt contain a list of images files [15:58:20 CEST] <Zypho> 2-pass with HLS looks more complex than just lowering the preset, but time is a factor for me [15:58:30 CEST] <Zypho> encode time is a factor, not dev time =) [16:01:28 CEST] <DHE> aaap: then your images are 777 pixels tall which x264 can't take [16:01:36 CEST] <BtbN> 2 pass will take quite exactly double the time to encode [16:04:36 CEST] <DHE> BtbN: some encoders (including x264) support fast 1st pass mode [16:05:05 CEST] <BtbN> I imagine 2 pass for the short HLS segments to not be worth it though [16:05:38 CEST] <BtbN> it's an interesting idea though, to get perfectly constant bitrate, without adding too much padding [16:05:47 CEST] <rsevero> Hi. There is an announcement from 2016-07-01 at ffmpeg's site mentioning that ffserver will be dropped (http://ffmpeg.org/index.html#ffserv) But I just checked the latest releases available at http://ffmpeg.org/download.html and ffserver seems to be there still. Will ffserver be dropped after all? Please say no ;) [16:06:05 CEST] <BtbN> Once it gets in the way of anything, it will go. [16:06:12 CEST] <BtbN> It's unmaintained [16:06:23 CEST] <Mavrik> It probably doesn't work anyway. [16:06:36 CEST] <BtbN> Some people are very actively defending it, but when it comes to fixing its issues, remain silent. [16:06:53 CEST] <rsevero> Oh, the 3.0.8 version does work, I can assure you ;) [16:07:11 CEST] <BtbN> Nobody has any knowledge on how to work with it anyway, as nobody uses it. [16:07:18 CEST] <rsevero> BtbN: Will I be another one on this front? [16:07:35 CEST] <BtbN> If you volunteer to fix and maintain it [16:07:39 CEST] <BtbN> If not, it will go eventually [16:07:46 CEST] <rsevero> Hey! I use it! But don't know ho to update it... [16:07:54 CEST] <Mavrik> Why not just take a proper maintained streaming software? [16:08:06 CEST] <Mavrik> Heck, even nginx has plugins for that these days. [16:08:09 CEST] <rsevero> Mavrik: Suggestions? [16:08:21 CEST] <BtbN> The common open source solution is nginx-rtmp [16:09:14 CEST] <Zypho> ^^ [16:09:26 CEST] <rsevero> BtbN: Ok, I will take a look at it. Thanks. [16:14:37 CEST] <Dex_> Hi, could some of you please have a look at my problem: https://superuser.com/questions/1214314/unable-to-set-ffmpeg-frei0r-facedet… [16:28:32 CEST] <ppw> Is Opus really better than AAC? [16:28:43 CEST] <ppw> for music? [16:29:25 CEST] <atomnuker> yes [16:29:30 CEST] <atomnuker> for everything [16:29:44 CEST] <nicholas_he> HI FFmpeg users. Should it be possible to extract separate audio channels from a 2 Dolby E Stream tracks in a .MOV file? [16:29:58 CEST] <kerio> ppw: jury's still out [16:30:08 CEST] <kerio> at least, at >128kbps [16:30:37 CEST] <kerio> and even then, it's only because humans can't tell the difference anymore [16:30:48 CEST] <atomnuker> if the jury says it can tell the difference between 256kbps opus and 256kbps aac I'll have them thrown out of the court [16:31:33 CEST] <Dex_> is there a way to skip a parameter for a filter ? [16:32:22 CEST] <ppw> kerio / atomnuker: can you provide me with an audio example @ 256 kbps? or at least tell me what piece of music I should test to hear it? I have better-than-average hearing, I need to hear this for myself. [16:32:35 CEST] <kerio> huh [16:32:44 CEST] <kerio> just take a flac of your favourite song and convert it? [16:32:52 CEST] <ppw> so -- any favorite song? [16:33:01 CEST] <ppw> OK - shouldn't be a problem [16:33:21 CEST] <bencoh> a proper flac encoded from some clean source, though [16:33:27 CEST] <ppw> well obviously [16:34:12 CEST] <bencoh> what do you meab by "better-than-average" though? more sensitive? [16:34:24 CEST] <Dex_> he has 3 ears :P [16:34:29 CEST] <bencoh> sweet :p [16:35:35 CEST] <ppw> for exmaple, I always ace the hearing test at the doctor's. young kids to do. but a lot of adult people don't. [16:35:41 CEST] <ppw> *do too [16:36:14 CEST] <Dex_> so can I ... '-vf frei0r=facedetect:SKIP|0|0 ' ? [16:36:30 CEST] <Dex_> or rather, how can i skip the first parameter [16:36:36 CEST] <bencoh> ppw: meaning you're not affected by presbycusis? nice [16:37:20 CEST] <bencoh> (I've always been a bit sad about presbycusis) [16:37:48 CEST] <Dex_> at least you get rid of the moskito tone [16:37:59 CEST] <bencoh> huhu [16:43:04 CEST] <furq> atomnuker: what if it's faac [16:43:46 CEST] <Mavrik> Don't use faac. :P [16:44:26 CEST] <furq> ppw: http://listening-test.coresv.net/results.htm#list3 [16:44:32 CEST] <Dex_> Could some of you please have a look at my problem: https://superuser.com/questions/1214314/unable-to-set-ffmpeg-frei0r-facedet… [16:44:36 CEST] <furq> there's a test corpus you can use [16:45:00 CEST] <furq> i guess you want to check the ones where opus scored low [16:45:21 CEST] <ppw> furq thanks .. but that's qaac .. maybe fdk-aac is slightly better? [16:45:31 CEST] <furq> i doubt it [16:46:09 CEST] <Dex_> ah well, i give up for today [16:46:16 CEST] <Dex_> see you guys tomorrow perhaps [16:46:17 CEST] Action: Dex_ waves [18:26:57 CEST] <PlanC> is it possible to add a parameter which makes the output streamable? [18:27:58 CEST] <furq> is this for mp4 [18:27:59 CEST] <PlanC> my output is in MKV and although the video displays when I stream it, none of the meta data comes with it (e.g duration, bitrate) [18:28:08 CEST] <PlanC> furq: mkv [18:28:30 CEST] <furq> er [18:28:33 CEST] <PlanC> I've noticed that FFMPEG adds the meta after it's done [18:28:37 CEST] <furq> that sounds like it's already streamable [18:28:49 CEST] <furq> you can't add the duration before it's done encoding [18:28:58 CEST] <PlanC> furq: right, but how can I get the duration to show as well? [18:29:11 CEST] <PlanC> right now it just says 00:00 when it's playing [18:42:25 CEST] <PlanC> I guess it's streamable right now [18:42:43 CEST] <PlanC> I just need to find a way to add the meta from the start [18:47:34 CEST] <DHE> you mean stream directly from ffmpeg to a player before it's done processing? [18:47:48 CEST] <PlanC> yeah [18:52:06 CEST] <PlanC> or actually it's streamed to a browser [18:52:31 CEST] <PlanC> if there was a way I could tell ffmpeg to add the metainfo to the end of the file instead of the start [18:52:39 CEST] <PlanC> then I think it'd fix the problem [18:52:59 CEST] <furq> but the end of the file is the end of the stream [18:53:29 CEST] <PlanC> well it could be added to the start as well [18:53:55 CEST] <furq> if you added it to the end then you wouldn't even be able to stream the video [18:53:57 CEST] <furq> like with mp4 [18:54:06 CEST] <PlanC> I'm using mkv though [18:54:59 CEST] <c_14> PlanC: -live 1 ? [18:55:25 CEST] <Xys> Hello, when I ffprobe a video, it says : 29.85 fps, 29.97 tbr, 90k tbn, 59.94 tbc [18:55:33 CEST] <Xys> I would like to change the fps to 30 [18:55:38 CEST] <c_14> the matroska muxer "recently" got some changes (I think the CRC ones) that make it not streamable without that parameter [18:56:23 CEST] <Xys> And when I do ffmpeg -i video.mp4 -r 30 result.mp4, the FPS are still "29.85 fps" [18:56:24 CEST] <furq> isn't that a webm dash private option [18:57:08 CEST] <c_14> Nah, it's listed for standard matroska [18:57:46 CEST] <c_14> And I've used it as such (and checked the code) [18:57:46 CEST] <klaxa> in my matroska server i set the live option as well [18:57:58 CEST] <furq> i don't see it in the docs [18:58:05 CEST] <Xys> Does anyone has an idea why the FPS are still "29.85" instead of "30" please ? Thanks in advance [18:58:29 CEST] <Cracki> hi. interested in the "scene" parameter (frame difference), but for all frames, output as text or something. haven't seen the filter to give me this output. wat do? [18:59:00 CEST] <furq> nvm it's in -h encoder=matroska [18:59:21 CEST] <c_14> The docs for the matroska muxer are (very) incomplete [18:59:27 CEST] <furq> i can see that [19:11:40 CEST] <PlanC> c_14: I just tried "-live 1" [19:11:46 CEST] <PlanC> but the output is the same [19:12:09 CEST] <PlanC> no duration is shown and I also can't jump to different parts of the video [19:12:29 CEST] <PlanC> it plays perfectly if I just let it run on it's own though (from 00:00 to end of video) [19:12:37 CEST] <c_14> probably missing the index [19:12:44 CEST] <Cracki> showinfo could use a scene variable, no? [19:13:17 CEST] <c_14> pretty sure you can't add that prior to finishing [19:13:56 CEST] <PlanC> the thing is that the metainfo is added once ffmpeg finishes [19:14:16 CEST] <PlanC> and it adds it to the start [19:14:45 CEST] <PlanC> if there was a way to have it add the duration to the start right from the beginning then it would solve the problem [19:15:05 CEST] <PlanC> instead of prepending it to the file in the end [19:15:20 CEST] <c_14> ffmpeg doesn't know how long the file is before it finishes [19:16:14 CEST] <PlanC> could I tell it with "-t"? [19:16:29 CEST] <PlanC> or is that just used for cutting [19:16:34 CEST] <c_14> No, you'd have to write a patch to add an option to specify [19:17:31 CEST] <c_14> Even if you specify -t, the video could still be shorter [19:17:37 CEST] <PlanC> oh I've got no idea how to do that so I don't think it's an option [19:17:41 CEST] <PlanC> right [19:18:16 CEST] <c_14> and the seeking is probably just your player being unable/refusing to seek without an index [19:22:55 CEST] <PlanC> so there's no way I can add the index to the end of the file [19:23:08 CEST] <PlanC> or even somewhere else in the file without having it prepend any data? [19:23:31 CEST] <PlanC> because I can't take back or edit what's already sent out to the browser [19:25:06 CEST] <c_14> Not really, you might want to rethink how you're serving content to the browser. Maybe webm-dash will work for you? [19:25:54 CEST] <c_14> or regular dash or mpeg-ts or something [19:26:45 CEST] <PlanC> but what I don't understand is why ffmpeg doesn't know the duration of the file [19:26:56 CEST] <PlanC> because it knows the duration of the input [19:27:29 CEST] <PlanC> I can even see the duration of the input in the ffmpeg logs before it starts processing [19:27:37 CEST] <c_14> It only knows the duration the metadata of the input says it has, this doesn't have to be correct, and most probably won't be correct if ffmpeg seeks/truncates/filters [19:45:24 CEST] <PlanC> I actually just tried to play the video in the MPC player and it shows the duration [19:45:35 CEST] <PlanC> and even let's me jump to different parts of it [19:45:44 CEST] <PlanC> VLC doesn't let me do anyone of that though [19:46:02 CEST] <PlanC> is there anything I can add to the file that'll make it work in VLC as well? [19:49:07 CEST] <PlanC> even windows media player shows the duration [19:49:10 CEST] <PlanC> and I can even seek with that [19:49:21 CEST] <PlanC> wonder why VLC (which should be more advanced) doesn't support it [19:50:54 CEST] <furq> probably because vlc isn't very good [19:52:40 CEST] <PlanC> lots of people use it though [19:52:44 CEST] <PlanC> and it at least used to be good [19:53:53 CEST] <jarainf> It's not bad [20:09:53 CEST] <m712> teratorn: hey [20:10:13 CEST] <m712> it came out kinda late because i forgot about this, but i got it working [20:10:21 CEST] <m712> i think -ss is kinda buggy [20:11:01 CEST] <m712> because there was a keyframe right at where i wanted to cut, at 00:01:30.000 but putting -ss 00:01:30.000 did not include the keyframe [20:11:27 CEST] <m712> same thing happened when i tried to shorten the end of a video and i put -ss 00:00:00.000, first keyframe disappears [20:11:39 CEST] <m712> removing that fixes it :S [20:12:12 CEST] <m712> anyway, i managed to do it by using -f segment and then finding the videos that i needed [20:12:33 CEST] <m712> which were 043.mkv to 067.mkv [20:12:49 CEST] <m712> then i concatted them with the concat demuxer and it worked like magic [20:14:45 CEST] <m712> no more lossy compression artifacts [20:14:48 CEST] <m712> hooray! [20:14:54 CEST] <m712> though -ss really needs to be fixed [20:15:41 CEST] <Mista-D> is there a table of codecs and supported pix_fmt ? [20:15:50 CEST] <m712> idk man i'm a noob [20:17:51 CEST] <linkmauve1> Hi, when compiling latest master on ArchLinux on amd64, I get make: *** No rule to make target 'libavcodec/x86/simple_idct.c', needed by 'libavcodec/x86/simple_idct.o'. Stop., it seems this file got replaced with a similarly named .asm file. [20:19:12 CEST] <m712> i think avcodec is something else [20:19:18 CEST] <PlanC> c_14: I actually found a way to change the duration with a "hack" [20:19:23 CEST] <m712> ffmpeg and avcodec are not related [20:19:33 CEST] <c_14> Mista-D: ffmpeg -encoders | grep ' V' | awk '{print $2}' | xargs -I'{}' sh -c "echo '{}'; ffmpeg -v quiet -h encoder='{}' | grep 'pixel formats'" [20:19:56 CEST] <PlanC> c_14: I'm doing "-metadata duration=00:01:00.00" and now I can see the duration and even seek in the MKV [20:20:15 CEST] <c_14> ah ye, that might work [20:20:17 CEST] <Mista-D> c_14 - awesome, thank you [20:20:31 CEST] <PlanC> c_14: it's really buggy though [20:20:42 CEST] <PlanC> c_14: sometimes when I seek the entire VLC player crashes [20:20:52 CEST] <furq> 19:19:23 ( m712) ffmpeg and avcodec are not related [20:20:55 CEST] <furq> yeah this isn't true [20:21:00 CEST] <m712> are they? [20:21:12 CEST] <m712> i really don't know, i thought they were different [20:21:32 CEST] <m712> they're separate packages in debian at least [20:21:33 CEST] <furq> http://vpaste.net/KIl47 [20:21:46 CEST] <m712> i see [20:22:17 CEST] <c_14> linkmauve1: might be a bug caused by https://git.videolan.org/?p=ffmpeg.git;a=commit;h=8e89f6fd37357361e0f4db5b6… [20:22:54 CEST] <furq> typical james darnley [20:23:29 CEST] <linkmauve1> c_14, likely. [20:24:30 CEST] <c_14> seems to work on a bunch of fate nodes though [20:25:20 CEST] <linkmauve1> Hmm, maybe I should git clean and retry. [20:25:51 CEST] <linkmauve1> But I ran configure again, there should be nothing left there. [20:27:55 CEST] <linkmauve1> It built after I removed everything and recloned from the local copy. [20:27:56 CEST] <linkmauve1> Weird. [20:28:06 CEST] <linkmauve1> Sorry for thinking it was a bug. :) [20:29:21 CEST] <c_14> probably some state file lying around somewhere [20:29:50 CEST] <c_14> In unrelated news, when is fatebeta ever going to replace fate [21:00:01 CEST] <Mavrik> hmm, is there a plugin for ffplay / ffmpeg to render graph of bitrate somewhere? [21:00:59 CEST] <DHE> you could probably make one with ffprobe and show_packets (less muxing overhead) [21:01:22 CEST] <m712> /wi furq [21:01:37 CEST] <m712> it's not awkward if you don't think it's awkward [21:06:23 CEST] <Mista-D> is there a table of codecs and supported protocols and muxers please? `ffmpeg -v quiet -h muxer=mpegts` is not showing all supported codecs. [23:12:01 CEST] <aib> ffmpeg seems to run about 50% slower whenever my CPU usage is above 100% . How can this be? (I have 4 CPU's, so 100% is actually 25%) [23:25:03 CEST] <iive> aib: first check cooling, if cpu overheats it would start to throttle down. [23:25:44 CEST] <iive> next, if you have virtual cores, then it is kind of normal... intel calls it HT or HyperThreading. [23:26:10 CEST] <ppw> your usage can't be over 100% [23:27:44 CEST] <DHE> multi-threading is a thing. usually percentage is measured in terms of 1 core [23:27:59 CEST] <aib> here's how weird this is: I have two CPU eaters, a cryptocurrency miner and an increment loop I wrote (https://github.com/aib/bogomips) I execute two programs, let's call them A and B. A is at IDLE I/O priority, has SCHED_IDLE scheduling class and is in a cgroup with cpu.shares set to 16. B has B0 I/O prio, realtime priority (SCHED_RR/99) and has 10240 shares [23:28:27 CEST] <DHE> SCHED_RR? seriously? [23:28:36 CEST] <ppw> so you're running this beside ffmpeg and then wonder why it's 50% slower? [23:29:07 CEST] <aib> now, in any given case, B completely destroys A as would be expected [23:29:18 CEST] <furq> why are you running a bogomips calculator alongside ffmpeg [23:29:36 CEST] <aib> the only thing is, if A is bogomips with 3 threads and B is ffmpeg, B finishes in 12 seconds. if A has no threads, B finishes in 6. [23:29:49 CEST] <aib> furq: debugging. this is absolutely mind-boggling [23:30:05 CEST] <furq> are you sure about that [23:30:54 CEST] <furq> this is one of those cases where i can't tell if you're much smarter than me or much stupider [23:30:58 CEST] <aib> furq: if you have an explanation I'm all ears [23:31:15 CEST] <furq> i know shit about how cfs actually works but that makes intuitive sense to me [23:32:05 CEST] <furq> given that you know what SCHED_RR is without googling it i'm going to assume there's a good reason it doesn't make sense to you [23:33:42 CEST] <aib> that's just an example of how high priority B is, by the way. I've also tried nice -19 and other things. everything is as I would expect (high and low prio A/B share the cpu, they share according to their cpu.shares numbers and everything) [23:33:46 CEST] <iive> isn't RR a realtime? basically blocking anything else? [23:33:52 CEST] <aib> iive: yep [23:33:53 CEST] <ppw> basically [23:34:03 CEST] <iive> aib: what is your cpu? [23:34:17 CEST] <aib> 4 cores on AWS [23:34:30 CEST] <iive> what is aws? [23:34:33 CEST] <aib> Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz though there's a good chance it's virtualized [23:34:35 CEST] <ppw> amazon web service? [23:34:40 CEST] <aib> Amazon Web Services, yeah [23:34:55 CEST] <iive> oh dear.... [23:35:04 CEST] <ppw> so the three threads saturate the three virtual cores and ffmpeg gets the one [23:36:21 CEST] <aib> yes. in that case ffmpeg finishes in 12s. [23:36:23 CEST] <iive> 10 cores, 20 threads [23:36:33 CEST] <aib> if bogomips gets the core it scores at around 500. [23:36:46 CEST] <aib> now, if I kill the 3-thread program, ffmpeg finishes in 6s [23:36:53 CEST] <aib> but the bogomips score is still the same [23:37:26 CEST] <ppw> how about running ffmpeg without ever starting the bogomips calculator [23:37:41 CEST] <ppw> does it saturate all four cores? can you check with top? [23:37:41 CEST] <aib> ffmpeg running alone is always 6s [23:37:55 CEST] <aib> one sec [23:38:39 CEST] <aib> https://paste.pound-python.org/show/oOCNx3cNrGCD0XcD2f5g/ [23:39:33 CEST] <aib> I'm beginning to think this is an artifact of virtualization [23:39:41 CEST] <kepstin> aib: also if you're running on AWS, make sure to check your steal time stats [23:39:45 CEST] <iive> aib: do you know how HT works? [23:39:49 CEST] <aib> the hypervisor switches CPUs on me as soon as I start using SSE instructions or something [23:40:00 CEST] <aib> iive: I think so [23:40:26 CEST] <kepstin> iive: yeah, that's the other thing to note, on aws you get hyperthread vcpus, not cores. [23:41:10 CEST] <aib> note that ffmpeg hardly ever runs out of quanta (or what was it called? its cpu timeslice) [23:41:11 CEST] <ppw> it's entirely possible that SCHED_RR is interfering with the HT which would otherwise appear transparent. [23:41:25 CEST] <aib> same case with other priorities [23:42:55 CEST] <ppw> you could force ffmpeg to use 1 thread / 2 threads etc. see what happens [23:43:29 CEST] <kepstin> aib: hyperthreading is weird, because if processes are scheduled on both hyperthread siblings on one core, they both appear to be using cpu to the OS, but the cpu is doing timesharing between them internally, so they're only running at about 1/2 the instruction rate. [23:43:54 CEST] <aib> I mean, I don't have perfect measurement tools (and not much experience printing out raw process stats) but everything seems to be working as documented. shares are divided according to A/(A+B), higher prios are run more, higher scheduling classes completely destroy lower ones, etc. [23:43:56 CEST] <kepstin> (of course, if there's a lot of waits for ram, then the throughput can appear higher than os-level timesharing) [23:44:06 CEST] <furq> yeah HT goes a long way to explaining it [23:44:27 CEST] <aib> ah, hmmm [23:44:46 CEST] <aib> that would also explain the CPU apparently slowing down by 50% without anything visible changing [23:44:58 CEST] <aib> such as the number of context switches [23:45:40 CEST] <furq> 22:40:26 ( kepstin) iive: yeah, that's the other thing to note, on aws you get hyperthread vcpus, not cores. [23:45:43 CEST] <furq> do they advertise this [23:45:46 CEST] <furq> because if not then lol [23:47:07 CEST] <furq> https://aws.amazon.com/ec2/instance-types/ [23:47:10 CEST] <furq> oh it is explicitly mentioned [23:47:14 CEST] <aib> the reason I didn't pay much heed to HT is that bogomips is a very tight loop. should take one ALU and part of an MMU, not much else [23:47:15 CEST] <furq> that's a bit less filthy than i thought then [23:47:28 CEST] <aib> hmm, maybe it's taking half the MMU [23:47:59 CEST] <aib> okay, okay, that should explain it. hold on, let me try some affinity stuff [23:52:07 CEST] <kepstin> I don't know exactly how the topology sorts out with the amazon stuff - e.g. on a 2vcpu machine I don't know if you get 2 threads on the same core, 2 different cores, or if it varies [23:52:26 CEST] <kepstin> I suspect they do 2 threads on the same core. [23:54:40 CEST] <furq> that would be absolutely mental if they didn't [23:55:16 CEST] <kepstin> it would mean really variable performance depending on other vms on the same host, yeah. which would be kinda crazy. [23:55:26 CEST] <kbarry> I'm wanting to record my playback experience on my windows 10 box for my developers to hear "whatr i hear" [23:55:43 CEST] <kbarry> like, piping vlc into ffmpeg [23:56:03 CEST] <furq> actually i guess they have nodes with one vcpu [23:56:09 CEST] <furq> so it is entirely likely ;_; [23:56:44 CEST] <furq> a lot of aws users aren't exactly the brightest bulbs, so they could probably get away with it [23:57:44 CEST] <aib> okay, so with a single thread bogomips running in CPU #1: [23:58:09 CEST] <aib> ffmpeg running on #2 and #4 works fine. so does ffmpeg running on #1, with all the priority difference [23:58:21 CEST] <aib> now ffmpeg on #3 runs 50% slower. so it *is* HT. [23:59:21 CEST] <furq> it's slightly worrying that only one core is affected [00:00:00 CEST] --- Wed May 31 2017

1 0

ffmpeg-devel.log.20170529
by burek 30 May '17

30 May '17

[00:23:39 CEST] <BBB> atomnuker: not that Im against removing libschroedinger, I think libxyz madness is insane (these libs should have their own patches to itnegrate into ffmpeg, not the other way around), but isnt vc-2 intra-only and thus not the same functionality as libschroedinger encoder? [00:36:04 CEST] <atomnuker> yes, but 1.) no one uses dirac, 2.) the vc-2 encoder should still generate decodable files by old dirac decoders [01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:4c472c52525f: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int' [01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:7c845450d2da: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int' [01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:c9e884f3d98d: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:c901627918ff: avcodec/truemotion2: Fix passing null pointer to memset() [02:46:02 CEST] <cone-470> ffmpeg 03Micah Galizia 07master:c4c73020f4bb: libavformat/hls: Observe Set-Cookie headers [02:46:03 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:f6ba58d193d9: avcodec/aacsbr: Fix libavcodec/aacsbr.c:257:59: runtime error: division by zero [04:42:55 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:718f8a01dfa3: tools/target_dec_fuzzer: Move the hwaccel check outside the initialization if [10:29:20 CEST] <wm4> jkqxz: is there anything we can do against the gross incompetence intel driver devs have shown again with this buffer destruction API fiasco? [10:29:42 CEST] <wm4> this is seriously shit-for-brains retarded [10:31:15 CEST] <JEEB> wm4: is that on -devel or otherwise? [10:37:27 CEST] <wm4> http://ffmpeg.org/pipermail/ffmpeg-user/2017-May/036232.html [10:37:53 CEST] <wm4> "Unfortunately, Intel got tired of people complaining that their driver was broken. Rather than fixing it, they decided to change the specification" [10:38:12 CEST] <JEEB> trololol [10:40:31 CEST] <wm4> incompetent shitheads [10:40:54 CEST] <ubitux> looks like the same design as android/mediacodec [10:41:00 CEST] <ubitux> render = destroy [10:41:18 CEST] <JEEB> yup [10:41:21 CEST] <ubitux> and yeah, it's complete garbage [10:41:35 CEST] <mateo`> tell me more about it :D [10:41:39 CEST] <wm4> that's not really the same [10:41:53 CEST] <wm4> this here is just something where you get the choice between memory leak and crash [11:16:04 CEST] <rcombs> heh [11:16:11 CEST] <rcombs> so, the new behavior actually makes more sense [11:16:20 CEST] <rcombs> but they didn't go about fixing it the right way [11:23:19 CEST] <ubitux> wbs: oh, we can use optional args in gas macro? :o [11:23:53 CEST] <wbs> ubitux: yes, that's been supported forever, and works in the clang built-in assembler as well [11:24:03 CEST] <ubitux> nice, TIL [11:24:19 CEST] <wbs> and in gas-preprocessor etc. widely used in libavutil/{arm,aarch64}/asm.S [11:24:34 CEST] <ubitux> didn't ever realized.. [11:25:07 CEST] <ubitux> oh.. with export=1, yeah i guess i used already :') [11:40:08 CEST] <wm4> mateo`: btw. any results in investigating better ways to use mediacodec without copying memory back to CPU? [11:40:20 CEST] <wm4> wasn't there an idea to render to a GL texture? [11:40:54 CEST] <rcombs> my current route is "yell at the vendor until they give me access at the OMX level" [11:41:17 CEST] <rcombs> because OMX seems less painful than that shit (this is something that has never been said of anything else) [11:42:12 CEST] <mateo`> wm4: the surface output is already implemented through the hwaccel [11:42:59 CEST] <wm4> yeah, but as we know it's pretty inconvenient, due to the underlying mediacodec API [11:43:21 CEST] <wm4> also looking forward to the horror google will come up to "solve" this (it will be a horror, I have no doubt) [11:43:29 CEST] <BtbN> I'd kind of like to add a CUDA to GL frame converter. So for example kodi could use the cuvid decoders without having to use CUDA themselves. [11:43:33 CEST] <mateo`> because you want to render the same frame multiple time ? [11:43:49 CEST] <rcombs> apparently there's some amount of movement towards v4l2 [11:43:54 CEST] <nevcairiel> GL is tricky because its so stateful [11:43:59 CEST] <nevcairiel> why dont you let kodi figure that out [11:44:15 CEST] <BtbN> because they won't touch CUDA [11:44:43 CEST] <wm4> BtbN: why not? how is GL better than CUDA? [11:44:45 CEST] <nevcairiel> and we probably shouldnt try to offer a GL interface, because its going to end in a nightmare with context sharing and shit [11:44:53 CEST] <BtbN> wm4, it's not nonfree [11:45:07 CEST] <wm4> double negation? [11:45:59 CEST] <mateo`> wm4: once you have a jni wrapper around the surfacetexture api, it's okay-ish (at least it works) [11:47:01 CEST] <wm4> personally I'd love if cuda could just replace vdpau [11:47:11 CEST] <wm4> well, anything to get rid of vdpau [11:47:25 CEST] <mateo`> i use the following workflow in the app i work for, mediacodec -> surfacetexture -> GL_TEXTURE_EXTERNAL_OES (-> GL_TEXTURE_2D if need mipmapping) [11:47:42 CEST] <mateo`> if I need to render the same frame twice, i just re-render the GL texture without updating it [11:47:44 CEST] <nevcairiel> i've been very reluctant adding hw decoding for linux for $work because all the s olutions are apparently crappy [11:48:07 CEST] <BtbN> The idea would be to have no context code in ffmpeg. Just a filter that copies from CUDA to a GL texture within a user provided context [11:49:23 CEST] <rcombs> BtbN: bad news, ffmpeg.c [11:49:37 CEST] <BtbN> ffmpeg.c has no need for that [11:49:39 CEST] <wm4> you could do something with shared contexts lol [11:50:29 CEST] <wm4> I'm also working on libplacebo (mpv's GL renderer as a library), which could probably take in GL or CUDA surfaces, and has to solve a similar "problem" [11:51:45 CEST] <rcombs> BtbN: I have a use-case for mediacodec -> filters -> mediacodec [11:51:57 CEST] <wm4> I'll probably end up sanity-checking GL context use by forcing the user to provide appropriate callbacks for getting the current host context [11:51:58 CEST] <rcombs> optimally without a copy to CPU [11:52:13 CEST] <BtbN> But how is mediacodec involved with CUDA? [11:52:34 CEST] <rcombs> oh I missed that disconnect [11:52:53 CEST] <rcombs> well I generally have a use case for [hardware decoder] -> [GPU filters] -> [hardware encoder], though [11:52:53 CEST] <wm4> BtbN: well, opaque GPU surfaces in general [11:52:56 CEST] <wm4> plus GL [11:53:11 CEST] <BtbN> rcombs, CUDA can do that now [11:53:20 CEST] <BtbN> someone just has to write the filters as CUDA kernels [11:53:28 CEST] <BtbN> one scale filter already exists [11:54:03 CEST] <wm4> isn't there a generic cuda program filter in libav [11:54:05 CEST] <wm4> or queued [11:55:52 CEST] <atomnuker> I'd prefer to scrap that and instead use vulkan compute shaders [11:57:48 CEST] <wm4> hwdec/Vulkan interop is going to be another nightmare [11:58:28 CEST] <atomnuker> would it be? I imagine it would work like swapchin images where the images are owned by the driver [11:59:11 CEST] <atomnuker> *swapchain [12:05:20 CEST] <mateo`> rcombs: so you need GL filters that would take GL textures (2D or OES) as input, for the mediacodec case ? [12:05:58 CEST] <rcombs> I dunno how any of that works with mediacodec [12:06:08 CEST] <rcombs> my experience with that surface API has been traumatic [12:07:51 CEST] <mateo`> that would work, (this is what I do outside of avfilter), the tricky part IMHO, is managing the GL context that your filters will use [13:34:49 CEST] <BtbN> wow, x264 master now needs a nasm version that not even Gentoo has [13:35:14 CEST] <JEEB> well gentoo "stable" versions are what they are [13:35:22 CEST] <BtbN> they is not in portage at all [13:35:25 CEST] <BtbN> *it [13:35:38 CEST] <BtbN> Debian also does not have it, not even in sid [13:35:57 CEST] <JEEB> well yeah, gentoo st least has 9999 [13:36:07 CEST] <BtbN> there is no 9999 nasm [13:36:17 CEST] <JEEB> :D [13:40:50 CEST] <Gramner> debian sid doesn't really update anything until stretch is released. after that there will be a billion or so new packages withing a day or two [13:42:44 CEST] <Gramner> the stable revision of x264 doesn't require nasm though, only git master [13:43:08 CEST] <BtbN> pinned it to the last commit before the nasm thing was introduced [13:47:43 CEST] <atomnuker> Gramner: it does [13:48:13 CEST] <atomnuker> unstable and experimental still gets stuff vert quickly [13:48:20 CEST] <atomnuker> *very [13:49:22 CEST] <JEEB> one of those is atm frozen [13:49:32 CEST] <JEEB> for 9 [13:51:18 CEST] <atomnuker> nope, neither is [13:51:20 CEST] <atomnuker> that's testing [13:51:33 CEST] <JEEB> ok [13:56:08 CEST] <Gramner> isn't unstable sort-of-frozen while tsting is frozen? [13:58:27 CEST] <Gramner> i searched for a few random packages and the versions of those are identical in testing and unstable [14:00:59 CEST] <atomnuker> things slow down but nothing gets frozen above testing [14:02:23 CEST] <iive> Gramner: do you mean that newst x264 needs newest nasm and not yasm? [14:03:56 CEST] <BtbN> iive, https://github.com/mirror/x264/commit/d2b5f4873e2147452a723b61b14f030b2ee76… [14:33:55 CEST] <DHE> yeah x264 added avx512 support in their commit master, which is likely why that happened. [14:34:28 CEST] <DHE> even though the only existing chips with avx512 today are Xeon Phi. gotta wait for the next generation from intel [14:41:55 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:f3da6fbff864: avcodec/jpeg2000dec: Use ff_set_dimensions() [14:41:56 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:c49fa2a51452: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int' [14:41:57 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:e091b9b3c785: avcodec/ansi: Fix frame memleak [14:44:10 CEST] <Gramner> DHE: the xeon phi subset of avx-512 isn't supported in x264. SKL-X is required [14:46:44 CEST] <Gramner> not that I see why anyone would want to use a xeon phi for video encoding in the first place really. seems like a bad choice from a price/performance viewpoint compared to regular xeons for that use case [14:49:12 CEST] <kierank> Gramner: because marketing [14:52:17 CEST] <DHE> i never understood what the phi was trying to target. a 60-core xeon in a PCI slot is interesting until you learn all its limitations... [14:52:28 CEST] <DHE> but that's a story for another channel [14:54:49 CEST] <Gramner> it's fine if your workload is trivially SIMD:able and able to fully use 512- bit vectors for everything. essentially the same kind of computations that's suitable for GPGPU but easier to develop for [14:55:14 CEST] <BtbN> how do you even access it? Does it act like a normal CPU? [14:55:40 CEST] <Gramner> there are available as both normal CPU:s and as add-in cards [14:55:44 CEST] <DHE> as I understand it, it behaves like a normal system you communicate with over some virtual networking. [14:58:12 CEST] <BtbN> so it's an entire PC on that card, and you send it jobs? oO [15:04:52 CEST] <DHE> sort of? like I said this is all just based on googling. it's got a CPU (obviously), some RAM, and a communication channel with the host over PCI [15:05:06 CEST] <DHE> or it's also available as the CPU of an otherwise ordinary server... [15:14:07 CEST] <wm4> what's the standard that specifies h264 mp4 muxing? (actually I'd prefer one for mkv, but surely that does not exist) [15:15:04 CEST] <nevcairiel> ISO IEC 14496-15 [15:15:13 CEST] <nevcairiel> Carriage of NAL unit structured video in [15:15:13 CEST] <nevcairiel> the ISO Base Media File Format [15:18:20 CEST] <wm4> thanks [15:34:43 CEST] <BBB> atomnuker: Im not arguing against it being dead, I just think the commit should mention that this removes dirac inter coding since it effectively does that. its fine to do that. but we need to mention that thats what were doing [15:34:58 CEST] <BBB> (coding=encoding) [15:52:54 CEST] <Gramner> atomnuker: apparently they improved gather operations a lot in skylake, I only tested it on haswell previously so maybe it's useful now as long as you only target skylake or newer [15:56:45 CEST] <iive> what are the gather operations? [15:57:10 CEST] <Gramner> https://en.wikipedia.org/wiki/Gather-scatter_(vector_addressing) [15:57:28 CEST] <Gramner> basically loading multiple values into a vector register [15:59:28 CEST] <iive> how is that different than basic mov? e.g. movaps ? [15:59:51 CEST] <iive> or do you mean, stuff like shufps, broadcast etc.. [16:00:25 CEST] <Gramner> movaps is one load of n bytes contiguous memory. gather loads x elements of 4 or 8 bytes each that may be located anywhere in addressable memory [16:00:53 CEST] <iive> and what instruction does this? [16:01:33 CEST] <atomnuker> Gramner: I heard someone say that vgather can help speed up cabac decoding [16:01:33 CEST] <Gramner> v(p)gather* [16:03:48 CEST] <iive> looks like it have higher latency and lower throughput on skylake [16:04:34 CEST] <iive> 20;4 vs 14;7 [16:07:17 CEST] <Gramner> vpgatherdd ymm 34 µops with an inverse throughput of 12 on haswell lol. compared to 4 µops and an inverse throughput of 4 on skylake [16:07:28 CEST] <Gramner> yeah. it's improved a little bit [16:08:48 CEST] <BBB> atomnuker: when do we start on ffav1? [16:10:06 CEST] <Gramner> BBB: didn't you get the memo? video encoders must start with the letter x [16:10:16 CEST] <Gramner> it automatically makes them faster [16:10:29 CEST] <BBB> ffav1=decoder [16:10:32 CEST] <Gramner> ah [16:10:34 CEST] <BBB> I know x-encoders are better [16:10:38 CEST] <BBB> but ff-decoders are also better [16:10:39 CEST] <Gramner> did they finalize the spec? [16:10:43 CEST] <Gramner> indeed [16:11:11 CEST] <BBB> I considered renaming by encoder to xeve, but figured that would put it too far ahead of the competition so it would be unfair [16:11:18 CEST] <BBB> removing the x made it more of a challenge [16:11:28 CEST] <atomnuker> BBB: not yet, DCTs haven't been decided yet (I hope all the daala ones make it in) [16:14:13 CEST] <iive> i really do wonder, why are intel creating ops that are working slower than a series of instructions. [16:14:30 CEST] <iive> of existing instructions. [16:19:25 CEST] <Gramner> gathers are mainly designed around SIMD address calculations. for example loading a[b[c]] [16:20:20 CEST] <Gramner> quite useful in compiler auto-vectorization and things like that [16:20:42 CEST] <Gramner> avx-512 also adds corresponding scatter instructions [16:20:48 CEST] <Gramner> for storing values [16:20:53 CEST] <Compn> rcombs : [16:21:11 CEST] <Gramner> and conflict detection for detecting duplicate addresses [16:21:20 CEST] <Compn> rcombs : https://trac.ffmpeg.org/ticket/4490 do you still need this done? do you have spec or something for it? theres a guy asking about doing this project... [16:22:58 CEST] <iive> Gramner: my point is... they can add them and make them faster, or at least not-slower [16:23:42 CEST] <Compn> rcombs : also can you upload some samples for that bug ? [16:23:47 CEST] <Compn> or link to them... [16:23:52 CEST] <Gramner> with an inverse throughput of 4 on skylake (if correct) it's the same speed as doing multiple ones. it's indeed a mystery why they added it to haswell with such poor performance though [16:41:18 CEST] <jamrial> Compn: http://0x0.st/6zc.thd [17:16:09 CEST] <BBB> J_Darnley: woohoo [17:18:51 CEST] <BBB> J_Darnley: I think patches lgtm& did you confirm with e.g. dct-test that the performance did not change? [17:19:17 CEST] <BBB> J_Darnley: maybe give michaelni a chance to confirm hes ok with it also, I dont think he minds but he wrote the original assembly so an explicit ok from him would probably be helpful [17:19:35 CEST] <BBB> J_Darnley: and again, happy to help with the sse2 for the idct itself [18:17:00 CEST] <philipl> BtbN: Tried out the 1030, and it works as advertised. Also got split decode/display on two devices working in mpv. That's cute. [18:17:58 CEST] <BtbN> is it the second gen video chip? [18:19:24 CEST] <philipl> Yeah. Same as the 1050 [18:20:06 CEST] <BtbN> phoronix benched the video engine to be slower... I'm pretty sure something went wrong there [18:20:35 CEST] <philipl> I thought the video enginer performance was affected by the main GPU clock. So these low end parts do run slower. [18:20:47 CEST] <BtbN> hm, yeah, possible [18:45:03 CEST] <saste> hi guys [18:45:30 CEST] <saste> I cannot push to the source ffmpeg git repository anymore, whom should I contact for assistance? [18:48:06 CEST] <atomnuker> saste: what's the push url? [18:48:14 CEST] <atomnuker> also the server got changed a few week ago [18:49:18 CEST] <saste> atomnuker: that would explain, my url is "git@source.ffmpeg.org:ffmpeg" [18:49:46 CEST] <BtbN> you're missing .git [18:52:32 CEST] <saste> BtbN, he's still asking me for a password, after I changed it to "git@source.ffmpeg.org:ffmpeg.git" [18:53:15 CEST] <BtbN> git@git.videolan.org:ffmpeg.git is what I use, but I think they are equivalent [18:53:26 CEST] <atomnuker> huh, I use ssh://git@source.ffmpeg.org/ffmpeg [18:53:38 CEST] <BtbN> that's the same [19:12:33 CEST] <jamrial> saste: there was a server move not too long ago, maybe something happened with your ssh key [19:13:21 CEST] <jamrial> poke michaelni, or thresh [19:14:55 CEST] <saste> jamrial, allright, thank you [21:08:17 CEST] <J_Darnley> I thought git gave me some error while checking out but no, it is just the lastest commit I have here with "runtime error: division by zero" in the message [21:21:31 CEST] <nadermx> Hi all, I came across a functionality that I need patched in ffmpeg. I asked in superuser https://superuser.com/q/1213776/535078 and also it was confirmed in the #ffmpeg chat that in order for this to work it has to be patched. Where in the source would I find this to try and start to write a patch myself or is there some one I should contact or try and hire to patch this? [21:27:45 CEST] <J_Darnley> What? You want to change the entire OS just so you can seek in a pipe? [21:31:51 CEST] <nadermx> didn't realize it would require that, thought it was maybe a quick patch [21:32:31 CEST] <nadermx> thought it would be a patch ffmpeg to write the id3 headers before writing the mp3 [21:35:49 CEST] <wm4> at least that doesn't sound impossible [21:36:02 CEST] <wm4> but it's probably a mess [21:36:27 CEST] <wm4> you'll first have to figure out how picture attachment writing works, and then why it's delayed, or how it can be not delayed [21:36:55 CEST] <nevcairiel> piped/non-seekable w riting has various limitations [21:37:05 CEST] <nevcairiel> sometimes it just cant be fixed very easily [21:37:43 CEST] <wm4> in this case there's no real fundamental reason though, or is there [21:39:30 CEST] <nadermx> In order to avoid writing temporary files [21:50:40 CEST] <BBB> J_Darnley: tnx for performance numbers [22:05:37 CEST] <Compn> jamrial : can i put that thd sample up on the samples repo ? [22:06:13 CEST] <jamrial> it was posted on a trac ticket i think [22:06:17 CEST] <jamrial> so, maybe? [22:06:33 CEST] <Compn> if you dont have objection :) [22:08:07 CEST] <jamrial> i don't [22:08:25 CEST] <Compn> k [22:22:32 CEST] <rcombs> Compn: it's not a high-priority thing for me (since it's not really breaking anything, just wasting bits in some cases), but still would be a "nice to have" [22:24:12 CEST] <Compn> rcombs : np, got a spec ? [22:24:25 CEST] <rcombs> not sure what you mean by that [22:24:49 CEST] <Compn> like whats a regular packet supposed to look like vs encapsulated one [22:27:21 CEST] <Compn> er [22:27:22 CEST] <Compn> i mean [22:27:28 CEST] <Compn> a substream [22:28:59 CEST] <rcombs> oh, I'm pretty sure that's all private [22:29:08 CEST] <Compn> anything to show what the substream looks like [22:29:11 CEST] <Compn> headers, start codes [22:29:16 CEST] <rcombs> but the truehd decoder has explicit code to ignore atmos substreams [22:29:28 CEST] <rcombs> I think it's just "stream id is 4" or something [22:29:31 CEST] <Compn> ok [22:29:48 CEST] <Compn> so its just hooking up an option to discard it ? [22:30:41 CEST] <rcombs> that issue is about remuxing [22:30:44 CEST] <rcombs> so it'd be a bsf [22:30:53 CEST] <Compn> right [22:30:53 CEST] <Compn> ok [22:30:58 CEST] <rcombs> the decoder already always discards; doesn't need an option [22:31:52 CEST] <Compn> right [22:44:14 CEST] <cone-025> ffmpeg 03Rostislav Pehlivanov 07master:a3deeaade32d: lavf: remove the libnut library wrapper [22:44:15 CEST] <cone-025> ffmpeg 03Rostislav Pehlivanov 07master:220b24c7c97d: lavc: remove libschroedinger encoding and decoding wrappers [22:44:19 CEST] <atomnuker> BBB: pushed with your suggestions [22:47:31 CEST] <jamrial> atomnuker: i don't think the libschroedinger patch was fully accepted [22:48:03 CEST] <jamrial> you didn't address Paul's comment [22:49:32 CEST] <atomnuker> jamrial: I did, I tested extensively and everything still matched [22:50:01 CEST] <jamrial> why didn't you reply to that email then? [22:50:12 CEST] <atomnuker> I did, he even said okay [22:51:15 CEST] <atomnuker> at 12:47 last night: "OK then." [22:51:38 CEST] <atomnuker> the web archive is being slow so it only shows a few emails from the thread [22:52:17 CEST] <jamrial> i didn't get that email at all... [22:52:22 CEST] <durandal_1707> it is private [22:52:45 CEST] <durandal_1707> its very confidential [22:52:52 CEST] <jamrial> ah, that explains it [22:56:26 CEST] <atomnuker> well, durandal_1707 mailed both me and the ml, it got into my main inbox and for some reason replying there didn't cc the ML [22:59:16 CEST] <BBB> you reply-not-alled to me also [22:59:23 CEST] <BBB> I think your mail client is stupid [22:59:40 CEST] <nevcairiel> thats what happens on some clients when people CC the author instead of just mailing the ML [23:00:03 CEST] <BBB> isnt that why we all use gmail? [23:00:13 CEST] <nevcairiel> gmail also does that [23:00:21 CEST] <BBB> not for me [23:00:28 CEST] <nevcairiel> in short, dont CC individual people that are active on the ML anyway =p [23:01:44 CEST] <iive> actually it is fine to cc individual people, as long as the to: field is the maillist [23:02:04 CEST] <iive> however some email clients send with multiple to:'s and even worse, the first one is not maillist [23:02:28 CEST] <iive> then a single reply (that is default in gmail too) would reply to the first sender only [23:09:08 CEST] <atomnuker> replied back with the missing parts [23:09:37 CEST] <atomnuker> I too use gmail but its hard work so I should switch back to evolution [23:11:16 CEST] <RiCON> atomnuker: looks like you replaced "not" with "sadasd"? lol [23:12:15 CEST] <RiCON> or at least durandal_1707's "not"s: "The lossless mode decoding is sadasd bitexact." "Nope, still sadasd lossless." [23:12:49 CEST] <atomnuker> first time I used sed in a year and it didn't work [23:12:53 CEST] <atomnuker> so I used printf [23:13:05 CEST] <atomnuker> ...which didn't get into my clipboard [23:15:34 CEST] <atomnuker> OH FUCK SED ACTUALLY SILENTLY CHANGED THE FILE [23:15:49 CEST] <RiCON> sed -i? [23:16:07 CEST] <atomnuker> and is so useless it can't replace newlines [23:16:45 CEST] <atomnuker> the number one thing you ever need to replace and it can't do that [23:18:09 CEST] <atomnuker> posted a corrected reply, fuck sed [23:18:38 CEST] <atomnuker> there's a reason I haven't used it in a year [23:26:08 CEST] <Gramner> sed is turing complete [23:43:50 CEST] <wm4> atomnuker: but ffmpeg configure uses sed [23:43:53 CEST] <wm4> so you have used it [23:52:07 CEST] <thardin> um, you can replace netlines [23:52:13 CEST] <thardin> you just need to use some special syntax [23:54:36 CEST] <atomnuker> :a;N;$!ba;s/\n/replacement/g [23:54:44 CEST] <atomnuker> how is this even remotely sane? [00:00:00 CEST] --- Tue May 30 2017

1 0

ffmpeg.log.20170529
by burek 30 May '17

30 May '17

[00:56:54 CEST] <hiihiii> hello [00:57:09 CEST] <hiihiii> can I add chapter to an mp4? [00:59:22 CEST] <hiihiii> I've muxed a couple videos into one and I'd like to see chapter marks indicating the end and start of what was a single video [01:00:08 CEST] <furq> hiihiii: https://www.ffmpeg.org/ffmpeg-formats.html#Metadata-1 [01:03:57 CEST] <tezogmix> hey furq, remember the other day I was asking about that batch file with all those examples? Where do we put the "pause" line? [01:04:31 CEST] <hiihiii> furq: ahh that helpful [01:05:18 CEST] <hiihiii> but can I o it with the concat demuxer [01:05:36 CEST] <hiihiii> or do I have to manually edit the metadata to fit my needs [03:53:51 CEST] <GenN> According to FFmpeg help `ffmpeg -help encoder=h264_nvenc`, h264_nvenc supports RGB pixel format (bgr0 and rgb0). I try to encode to RGB, but the output is yuv420p. How to fix? See: https://thepasteb.in/p/wjhzcKwxzvVEAU6 [03:54:41 CEST] <GenN> NVIDIA GeForce GTX 1070, driver 382.33, Windows 10 1703 [03:55:26 CEST] <c3-Win> GenN: Did you look at the NVENC docs and confirm that NVidia supports encoding RGB h264? [03:57:32 CEST] <c3-Win> I can tell you that NVENC support receiving an RGB source, but it runs a shader on the GPU to convert it to YUV, and then encodes it... so I seriously doubt that NVENC supports outputting an RGB h264 file. [04:00:02 CEST] <GenN> Nv says a lot about RGB input but not output: https://www.developer.nvidia.com/nvenc-programming-guide [04:00:18 CEST] <GenN> So I guess there is no fix, for now [04:01:11 CEST] <c3-Win> More like there's nothing to fix. FFMPEG can't make NVidia grow new hardware parts. [04:05:51 CEST] <GenN> Thanks for your input. Bye [05:42:36 CEST] <Exairnous> durandal_1707: thanks for your help the other day [05:43:07 CEST] <Exairnous> furq: thanks for your help the other day [10:08:41 CEST] <nadermx> so no one? I posted the question on super user, but it seems I'm getting told it's not possible to add a picture to a mp3 with ffmpeg when making it go to stdout [10:08:48 CEST] <nadermx> https://superuser.com/q/1213776/535078 [10:21:25 CEST] <c_14> nadermx: the answer is probably right, someone would have to patch ffmpeg to write the id3 headers before writing the mp3 [12:00:43 CEST] <Sanqui> hi, I'm trying to convert a series of pngs into a video with the following command: `ffmpeg -framerate 1 -i %d.png output.mp4` [12:01:18 CEST] <Mavrik> yay. [12:01:26 CEST] <Sanqui> each png is at most 5MB but I run out of 8gb of memory quickly. does ffmpeg try to load them into memory all at once or something? [12:02:28 CEST] <JEEB> Sanqui: you're not rescaling so there are multiple buffers kept in x264 [12:02:40 CEST] <JEEB> since it optimizes the encoding for compression [12:02:58 CEST] <Mavrik> Also, "at most 5MB" doesn't actually tell anything about how big those PNGs are when decompressed :) [12:03:48 CEST] <JEEB> yea [12:03:53 CEST] <JEEB> but probably pretty big :P [12:03:54 CEST] <Sanqui> sure, they're pretty huge (about 5k pixels). maybe I should rescale then [12:04:11 CEST] <JEEB> -vf zscale=w=blah:h=blah [12:04:13 CEST] <Mavrik> Yeah, 5K videos probably won't play well :) [12:04:16 CEST] <JEEB> after -i [12:05:10 CEST] <Sanqui> JEEB: no such ffilter zscale, but I did -vf scale=1280:720 and that seems to run much better haha [12:05:26 CEST] <JEEB> right, you have to build FFmpeg with zimg [12:05:29 CEST] <JEEB> for zscale [12:05:44 CEST] <JEEB> zimg being a high-quality scaling library [12:05:52 CEST] <JEEB> https://github.com/sekrit-twc/zimg [12:06:51 CEST] <Sanqui> neat, thanks! [12:08:56 CEST] <atomnuker> JEEB: asking someone to use zscale and recompile for casual encoding changing colorspaces is overkill [12:09:23 CEST] <JEEB> sure [12:09:32 CEST] <atomnuker> its more overkill than asking them to use the colorspace filter to convert (and get correct results) [12:09:34 CEST] <JEEB> he found the normal scale filter himself rather well :) [12:09:58 CEST] <JEEB> well, in this case it wasn't just colorspace that was needed :3 [12:10:26 CEST] <Sanqui> I was just a bit dumb thinking I wouldn't bother with resizing ("youtube will do it for me" XD) [12:11:17 CEST] <JEEB> well a 64bit binary would have happily used that RAM and finished. would have used quite a bit more time though since there's a lot more of image to encode [12:11:27 CEST] <JEEB> (as long as you had enough RAM) [13:07:14 CEST] <formruga> Hi. Is a way to "attach" PCR to audio packet not to video packet? My video has a low framerate (1/5) and PCRs are every 5 seconds. [15:11:02 CEST] <DHE> if I understand this right, the purpose of av_interleaved_write_frame() is so that audio and video streams will have their packets reordered so that they are written in sync to each other. Like merge-sorting each stream together before submitting to av_write_frame(). Am I right? [15:11:11 CEST] <DHE> I ask because it doesn't seem to be doing that [17:38:40 CEST] <jokkker87> hi everyone, i'm trying to cut an mpeg-ps into pieces for dvd authoring [17:39:17 CEST] <jokkker87> i'm using dvdauthor, which as actually a problem, if the pts of the video and audio are too far apart [17:39:24 CEST] <jokkker87> *has actually [17:41:01 CEST] <jokkker87> i know that i get the delay because of the different fps of the video (which is 25FPS) and audio (which is 31.250FPS) [17:42:05 CEST] <jokkker87> so i'm able to produce a working dvd with dvdauthor by trying a range of 4 seconds for the split (4 * 6.25) [17:43:07 CEST] <jokkker87> this is my command to ffmpeg: [17:43:16 CEST] <jokkker87> ffmpeg.exe -ss 02:42:27 -i .\video.mpg -ss 00:01:00 -t 00:17:23 -target pal-dvd -codec copy result.mpg [17:45:25 CEST] <jokkker87> is there a parameter for ffmpeg to tell it, that the delay between audio and video should not exceed a given limit? [19:53:14 CEST] <Mista-D> what [19:53:50 CEST] <Mista-D> 's mpeg-ts/udp codec with alpha channel support please? [20:17:10 CEST] <ChocolateArmpits> Mista-D, what about jpeg2000 ? [20:18:24 CEST] <Mista-D> probbaly woudl work, definetly PNG, but was hoping ofr a little higher efficinecy video codec. [20:19:48 CEST] <ChocolateArmpits> You'd had to supply the alpha channel as a separate video track and then combine that with the color video at the end [20:21:18 CEST] <furq> Mista-D: vp8 [20:21:44 CEST] <ChocolateArmpits> furq, not supported in mpegts [20:21:56 CEST] <furq> i just tried it and ffmpeg will mux it [20:22:01 CEST] <ChocolateArmpits> hummm [20:22:10 CEST] <furq> what a player will make of it i don't know [20:22:18 CEST] <Mista-D> A unique mpegts stream (: [20:22:23 CEST] <furq> i can't think of anything else though [20:22:42 CEST] <furq> also you're stuck with yuva420p if you do that, no 444 or rgba [20:22:43 CEST] <Mista-D> Thanks [20:23:36 CEST] <ChocolateArmpits> actually if you want to do pure udp streaming you just use the rawvideo format, -f rawvideo udp:// [20:23:46 CEST] <ChocolateArmpits> But the bandwith expense will be enormous [20:23:54 CEST] <furq> yeah that's not going to work over wan or wifi [20:23:59 CEST] <furq> or probably 100mbit, for that matter [21:14:47 CEST] <nadermx> @c_14 could you maybe point me in the right direction as to where in the source I could look into possibly trying to either make a patch myself or find some one who can? [22:04:34 CEST] <DHE> Is there a way to force audio and video sync inside a container? av_interleaved_write_frame() isn't writing in order of global dts [22:16:21 CEST] <Mavrik> It should O.o [22:18:21 CEST] <DHE> if I set "-c copy" it does, but if I set "-c:a aac -c:v libx264 [codecoptions]" it doesn't. [22:18:45 CEST] <DHE> to clarify I'm using the ffmpeg CLI tool, but looking at what's wrong from an API standpoint because I had the same issue with the API as well [00:00:00 CEST] --- Tue May 30 2017

1 0

ffmpeg-devel.log.20170528
by burek 29 May '17

29 May '17

[00:26:35 CEST] <kierank> hello [00:39:11 CEST] <durandal_1707> kierank: !? [00:58:19 CEST] <kierank> durandal_1707: ? [02:40:02 CEST] <cone-248> ffmpeg 03Kevin Mark 07master:114e8716214d: doc/filters: Clarify scale2ref example [03:55:44 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:357f2316a084: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2 [03:55:45 CEST] <cone-248> ffmpeg 03erankor 07master:15bd309af830: movenc: encryption with time code track fix [03:55:46 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:fe8c9420dd5b: avcodec/aacps: Check border_position to be monotone [03:55:47 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:7c36ee216f1e: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int' [03:55:48 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:ca6776a99390: avcodec/libfdk-aacdec: Correct buffer_size parameter [03:55:49 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:7f50c25124a0: avcodec/wnv1: More strict buffer size check [03:55:50 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:6c3a63fc3d1b: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int' [04:13:19 CEST] <rcombs> jamrial: does 7631f14bb35e8467d4ffaaa2b34e60614eb37c71 work reliably if output isn't seekable? [04:15:22 CEST] <jamrial> rcombs: that code isn't triggered with non seekable output, no [04:15:57 CEST] <rcombs> so it doesn't solve the problem that header-delaying does [04:16:22 CEST] <jamrial> what do you mean? [04:16:57 CEST] <rcombs> header-delaying allows updated extradata to be written when the output is non-seekable [04:17:13 CEST] <rcombs> or, well, bsf-generated extradata [04:17:20 CEST] <jamrial> no [04:17:45 CEST] Action: rcombs headtilts [04:17:49 CEST] <jamrial> not now that the bsf that used to do this in question doesn't violate the api anymore [04:18:17 CEST] <rcombs> well it _did_ solve that problem [04:18:42 CEST] <rcombs> but removing the code to set output codecpar and delay headers will regress that [04:19:06 CEST] <jamrial> the delayed header "solved" the problem of bsf generated extradata being available during write_header by abusing the fact this one bsf was violating the bsf api [04:20:13 CEST] <rcombs> if that solution isn't acceptable then we'll need a new one [04:20:27 CEST] <jamrial> it should be done within the muxer [04:20:48 CEST] <jamrial> sort of like how i buffer master elements to write crc32 elements [04:20:50 CEST] <rcombs> that's fine, as long as the muxer delays writing its header internally until the data is available, so it works when output isn't seekable [04:21:07 CEST] <jamrial> yeah [04:21:08 CEST] <rcombs> I figured doing it in lavf/mux was a bit easier, since it doesn't require N muxers to do work [04:21:50 CEST] <jamrial> it was a good idea, but it relied on aac_adtstoasc violating the bsf API [04:22:03 CEST] <jamrial> right now, only matroska needs some extra internal work [04:23:11 CEST] <rcombs> still could be done internally by having mux.c catch the new-extradata side-data and updating the stream's extradata, when it happens before the header is actually written [04:23:27 CEST] <rcombs> which would keep N muxers from having to deal with this [04:23:54 CEST] <rcombs> fate-segment-adts-to-mkv-header-* is meant to test this case [04:24:05 CEST] <jamrial> can't we differentiate between bsf created packet side data and for example encoder created side data to achieve this? [04:24:10 CEST] <jamrial> *can [04:24:30 CEST] <rcombs> does it matter? [04:24:49 CEST] <jamrial> flacenc creates packet side data in the last packet [04:24:59 CEST] <jamrial> and muxers expect it [04:25:29 CEST] <jamrial> if mux.c catches it first, muxers will never see it [04:26:31 CEST] <rcombs> that's why I said "when it happens before the header is actually written" [04:26:43 CEST] <jamrial> yeah, missed that part, sorry [04:27:11 CEST] <rcombs> looking at flacenc and I'm sorta confused about what it puts in there [04:28:06 CEST] <jamrial> the final md5 digest for the decoded data [04:28:07 CEST] <rcombs> seems like it's all either useless, known at startup, or doesn't make sense to be written at the codec level anyway [04:28:27 CEST] <rcombs> that seems like a muxer thing [04:29:03 CEST] <rcombs> reminds me a bit about how flac puts timestamps in the codec-level frame header for some reason [04:29:11 CEST] <jamrial> no, i said decoded data [04:29:17 CEST] <rcombs> oh, derp [04:29:53 CEST] <rcombs> though, seems easier to just checksum the coded data and have the muxer handle it :/ [04:30:02 CEST] <rcombs> but flac is flac, so w/e [04:31:18 CEST] <rcombs> like, min_framesize is in there because ??????? [04:33:19 CEST] <rcombs> but yeah, this would work for that [04:35:46 CEST] <jamrial> well, the point of codecs like flac is to guarantee the decoded bitstream is bitexact to the original raw stream. a checksum of the encoded data is useless for that :p [04:37:24 CEST] <jamrial> regarding your suggestion, there's also the case where you manually call the bsf with ffmpeg.c [04:37:56 CEST] <jamrial> the autobsf in mux.c gets the already filtered stream in that case [04:39:47 CEST] <jamrial> it could still catch the packet side data, i guess, but seems kinda fragile [13:39:25 CEST] <thardin> does fate need more machines? [13:55:24 CEST] <thardin> I may be taking custody of some retired cluster nodes [13:56:37 CEST] <atomnuker> x86's? [14:18:32 CEST] <thardin> I think so [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:c51357d206f2: avcodec/wavpack: Fix runtime error: signed integer overflow: -1386217472 * 4 cannot be represented in type 'int' [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:d8030c14bd7a: avcodec/sheervideo: Check input buffer size before allocating and decoding [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:9c1812491f7b: avcodec/jpeg2000dec: Check tile offsets more completely [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:781f88bb2653: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int' [15:29:24 CEST] <thardin> xeon 56, 16G RAM [15:38:43 CEST] <Compn> thats some nice hardware [15:38:52 CEST] Action: Compn still likes x86 kinda [15:39:17 CEST] Action: Compn makes note to remind friend about getting 64bit office [17:30:46 CEST] <michaelni> BBB, about "avcodec/webp: Fixes null pointer dereference", ive not received a reply from skal, can the patch be applied or do you prefer a different solution ? [17:31:54 CEST] <michaelni> i just into a 3rd case thats fixed by the patch [17:32:15 CEST] <michaelni> just RUN into [17:40:36 CEST] <michaelni> thardin, we always can use more testing [17:41:00 CEST] <michaelni> check fate.ffmpeg.org and see whats missing and what could be added [17:42:00 CEST] <michaelni> any other compilers, memory debuggers, emulated architectures, ... [17:45:27 CEST] <thardin> I guess one could run a whole bunch of VMs [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:b9c032ebc0ad: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int' [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:67b30decf779: avcodec/ylc: Check count in build_vlc() [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:6b9cb5d26a2d: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [18:57:40 CEST] <durandal_1707> michaelni: please revert d8030c14bd [18:58:58 CEST] <michaelni> durandal_1707, ok, should i list some reason ? [19:00:20 CEST] <durandal_1707> michaelni: formula is not clear to me [19:00:46 CEST] <durandal_1707> how you know it will always work? [19:02:45 CEST] <michaelni> durandal_1707, its approximately 25% of the minimal frame size, so to do W*H alloc and decode (W*H) time there needs to be W*H/4 bytes, this limts the time spend per byte [19:03:55 CEST] <michaelni> before the patch there was just a limit of fixed 20bytes [19:04:19 CEST] <michaelni> so a 20byte packet could lead to max resolution allocation and decode [19:09:15 CEST] <michaelni> s#W*H/4 bytes#W*H/16 bytes# [19:12:41 CEST] <durandal_1707> michaelni: it can stay, max compressed ratio it can archieve is less than 2x [19:13:46 CEST] <michaelni> durandal_1707, ok, anything i should do the clarify the check (like adding a comment?) or some other change you want me to do to it ? [19:14:26 CEST] <iive> adding comment is always good idea :D [19:15:26 CEST] <durandal_1707> michaelni: no [19:15:56 CEST] <michaelni> ok [19:40:10 CEST] <BBB> michaelni: the issue was that the alpha plane decodes but the pic buf is missing because its an invisible frame, right? [19:43:24 CEST] <BBB> michaelni: I guess apply it then, webp is intraonly and I dont really see the point of invisible keyframes in that context, but the bitstream allows it (probably to be vp8-compatible for hw purposes) so I really dont know if returning an error is ok, but I Guess its fine because I admit its pointless [19:43:44 CEST] <BBB> reason I wanted skal to respond is so we can do the same as libwebp [19:43:53 CEST] <BBB> but if he doesnt respond then whatever :) [19:44:59 CEST] <michaelni> BBB, ok, will push it on my next push, thanks [20:40:05 CEST] <Shiz> >unresolvable R_386_PC32 relocation against symbol `free' [20:40:09 CEST] <Shiz> whoops, wrong chan [20:56:01 CEST] <durandal_1707> michaelni: looks like libnut cant handle nut native files [20:57:27 CEST] <michaelni> is libnut maintained / used by anyone ? [20:58:35 CEST] <durandal_1707> its used by clueless mpv users [20:58:59 CEST] <jamrial> maybe we should remove the lavf wrapper [21:21:27 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:67020711b7d4: avcodec/webp: Fixes null pointer dereference [21:21:28 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:872bac81590c: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro [21:21:56 CEST] <alevinsn> When I use a video encoder (H.264) and an audio encoder (opus), and start encoding such that the first raw inputted audio and video share the same time stamp [21:22:14 CEST] <alevinsn> why is it that the pts for the resulting encoded audio and video frames are different (for same time_base)? [21:22:49 CEST] <nevcairiel> audio encoders have delay, video can have re-ordering (although maybe not for the very first frame) [21:23:30 CEST] <alevinsn> so, for example, lets say audio is 48 kHz, and video has a frame rate of 29.97 (30000/1001) [21:23:58 CEST] <alevinsn> The first encoded audio sample gets a pts of 2778, while the first video frame gets a pts of 3003 [21:24:09 CEST] <alevinsn> for a timebase of 1:90000 [21:24:10 CEST] <alevinsn> for both [21:24:25 CEST] <alevinsn> what do you mean that audio encoders have delay? [21:25:03 CEST] <nevcairiel> a more accurate term is probably pre-roll or decoder priming data, which can in some cases be output before the actual audio [21:25:53 CEST] <alevinsn> so, that doesn't actually correspond to actual audio? [21:26:38 CEST] <nevcairiel> the difference between 2778 and 3003 happens to be 120 audio samples exactly, maybe that is a priming frame for opus [21:26:48 CEST] <alevinsn> I find that odd, because each of the decoded opus frames has the same number of samples, 960 [21:27:11 CEST] <alevinsn> nb_samples is the same for each subsequent decoded Opus frame [21:27:35 CEST] <nevcairiel> of course the priming data would not get decoded if the entire chain works properly [21:27:49 CEST] <nevcairiel> well, it would get decoded [21:27:51 CEST] <nevcairiel> but not ouput [21:28:15 CEST] <alevinsn> ok, next question, when I encoded, a specified time stamps of 0 for each of the input raw video and audio frames [21:28:33 CEST] <alevinsn> why does it gets a pts of 3003 for the first video frame then (which would correspond to the fourth video frame) [21:28:40 CEST] <alevinsn> first encoded video frame, I mean [21:28:55 CEST] <alevinsn> 0, 1001, 2002, 3003 [21:29:55 CEST] <alevinsn> hmm [21:30:13 CEST] <alevinsn> that would be if the time scale were actually 30000:1001 [21:30:18 CEST] <alevinsn> but, the time_base is 1:90000 [21:30:47 CEST] <alevinsn> oops, 3003 apparently corresponds to the first frame [21:31:01 CEST] <atomnuker> michaelni: in the aacsbr patch shouldn't you use FLT_EPSILON? [21:31:07 CEST] <alevinsn> 0, 3003, 6006 [21:31:36 CEST] <nevcairiel> it proably increased it by one to make room for the opus pre-roll [21:31:39 CEST] <alevinsn> maybe the idea is that it "starts" on the second video frame because it needs room for the decoder priming data? [21:31:44 CEST] <alevinsn> which starts a bit earlier? [21:31:45 CEST] <nevcairiel> since there cant be negative timestamps [21:31:54 CEST] <nevcairiel> (not in mpegts anyway) [21:31:56 CEST] <michaelni> atomnuker, FLT_EPSILON is much larger than FLT_MIN [21:32:40 CEST] <alevinsn> that makes sense--so, for playback purposes, would it be correct to always use the pts, even if the values don't seem to make sense? [21:32:53 CEST] <nevcairiel> what else would you do [21:32:57 CEST] <alevinsn> for audio/video synchronization [21:32:59 CEST] <nevcairiel> of course you u se the timestamps given [21:34:17 CEST] <alevinsn> ok, thanks [21:35:08 CEST] <alevinsn> one unrelated question--I've noticed that when, say using Blackmagic over a long period of time (at least 8 hours, let's say) [21:35:20 CEST] <alevinsn> because of the inaccuracy of the clocks in most modern PCs [21:35:28 CEST] <alevinsn> it tends to lose frames over time [21:35:42 CEST] <atomnuker> michaelni: I guess I've been doing it wrong then using EPSILON in the opus encoder [21:35:44 CEST] <alevinsn> that is, it doesn't quite output frames at the actual frame rate [21:36:15 CEST] <alevinsn> I know how to deal with this in my own code, but I'm wondering if ffmpeg does anything to keep things in sync with actual wall clock time? [21:36:24 CEST] <alevinsn> I imagine it can't do anything in practice [21:37:36 CEST] <alevinsn> since how would ffmpeg know that the computer's clock is slightly off [21:59:42 CEST] <rcombs> ffmpeg doesn't use wall clock time for much, but when it does, it assumes the computer's clock is accurate [22:34:11 CEST] <BBB> libnut :-o :-D [22:34:30 CEST] <jamrial> spring cleaning [22:34:35 CEST] <BBB> this validates my suspicion that theres a libxyz for every feature out there [22:34:48 CEST] <BBB> (and that most of these libraries are crap) [23:32:22 CEST] <nevcairiel> most of the libraries are old and exist back from a time when they still mattered, ie. they were the only one [23:38:55 CEST] <RiCON> and then they stay a few years so you can compare them with the native implementation [00:00:00 CEST] --- Mon May 29 2017

1 0

ffmpeg.log.20170528
by burek 29 May '17

29 May '17

[00:08:52 CEST] <zerodefect> Anyone developers here familiar with configuring a custom 'execute' method in AVFilterGraph? My custom execute is not being called. [00:09:00 CEST] <zerodefect> *Any [00:16:54 CEST] <Thomas> Hello [00:17:23 CEST] <Guest99175> Hello [02:21:54 CEST] <kevmitch> how do i get ffmpeg to drop "stereo_mode : left_right" metadata and "stereo3d: side by side" side data when 2difying a h264/mkv with -vf stereo3d=sbs2l:ml [02:22:19 CEST] <bob_twinkles> hrm, I think the performance degredation I was seeing was due to AWS deciding my instance was consuming too many CPU resources and effectively reducing the clock speed [02:22:20 CEST] <bob_twinkles> not nice [02:24:39 CEST] <kevmitch> ah, -metadata:s:v:0 stereo_mode="mono" got id of it, but now the aspect ratio is wrong [02:24:50 CEST] <kevmitch> it is double wide [02:27:48 CEST] <kevmitch> http://sprunge.us/aUiE [02:29:20 CEST] <furq> kevmitch: remux it with -aspect 16:9 [02:30:01 CEST] <kevmitch> yeah, that did it thanks [02:30:28 CEST] <kevmitch> so the million dollar question is why can't -vf stereo3d=sbs2l:ml take care of that (it seems to for ffplay) [02:31:17 CEST] <furq> what, the aspect ratio? [02:31:35 CEST] <furq> it might be worth filing a bug report tbh [02:31:47 CEST] <furq> ffmpeg will normally try to keep the source aspect ratio, but obviously in this case that's never the right thing to do [02:31:51 CEST] <kevmitch> well both the metadata and aspect ratio [02:32:02 CEST] <furq> and the same thing with the metadata [02:32:35 CEST] <furq> idk if you could actually specialcase the metadata based on a filter [02:32:41 CEST] <furq> but the aspect ratio should certainly be possible [02:38:15 CEST] <tdr> so ffmpeg can deal with sde by side 3d? can it actually play it? [02:38:28 CEST] <tdr> (i'd really like to use my 3d movies on linux) [02:39:21 CEST] <kevmitch> well it can convert it to mono [02:40:00 CEST] <kevmitch> not sure about actualy playing 3d [02:40:24 CEST] <tdr> hrm... been waiting soooo long to stop needing to use the ps4 for movies [02:47:46 CEST] <furq> do you have a 3d monitor [02:48:57 CEST] <tdr> yeah 3d tv [02:49:13 CEST] <tdr> thats what i use for the ps4 to play it [02:49:23 CEST] <tdr> tower pc is hooked to it too [02:50:13 CEST] <tdr> dvd drive supports 3d for the tower too, but nothing will play them. [02:50:26 CEST] <tdr> (it had windows drives for it, but i'm not touching that) [02:56:38 CEST] <VectorX> what do i use for webp ./configure --enable- [02:58:00 CEST] <VectorX> ./configure --enable-libwebp gives ERROR: libwebp not found using pkg-config [02:59:43 CEST] <furq> do you have libwebp installed [03:00:03 CEST] <furq> tdr: i'd have thought anything decent would just play 3d stuff [03:00:06 CEST] <VectorX> i compiled it, per https://developers.google.com/speed/webp/docs/compiling [03:00:28 CEST] <VectorX> and the two utilities on the page cwebp and dwebp work [03:00:41 CEST] <furq> check config.log [03:00:48 CEST] <tdr> furq, like vlc/mplayer etc .. they choke trying to do a 3d disc [03:00:53 CEST] <furq> what about mpv [03:01:00 CEST] <tdr> furq, havent trying mpv [03:01:06 CEST] <furq> wait [03:01:12 CEST] <kevmitch> tdr: you'll have to rip the disc [03:01:14 CEST] <furq> when you say disc do you mean playing it off a bluray [03:01:17 CEST] <kevmitch> at the very least [03:01:19 CEST] <furq> because yeah that's a totally separate problem [03:01:52 CEST] <kevmitch> playing a 2d blu-ray real time is dodgy enough [03:02:00 CEST] <tdr> furq, i can get the key etc to make it readable using makemkv [03:02:11 CEST] <furq> can you play the resulting mkvs [03:02:26 CEST] <tdr> i can even convert it, it wont do it side by side tho [03:02:42 CEST] <VectorX> http://viper-7.com/OD5JMH [03:02:51 CEST] <kevmitch> yeah, last i checked makemkv didn't properly decode the stereo channel [03:03:31 CEST] <furq> you can build mpv with libaacs [03:03:34 CEST] <furq> which i think is what makemkv uses [03:03:35 CEST] <tdr> ok so maybe mpv then huh? i can buidl that [03:03:51 CEST] <kevmitch> no makemkv replaces libaacs [03:03:57 CEST] <furq> oh does it have its own implementation [03:04:08 CEST] <furq> i'm glad i don't have a bd drive and i don't have to deal with this shit [03:04:13 CEST] <furq> it sounds fucking awful [03:04:19 CEST] <tdr> furq, yeah if i use makemkv it adds a key or whatever, and the disk is unlocked or whatever [03:04:23 CEST] <kevmitch> (which only works on old blu rays - if you're drive didn't get blacklisted) [03:04:42 CEST] <furq> is there anything other than makemkv that works with 3d/4k blurays [03:04:45 CEST] <furq> on linux [03:04:47 CEST] <VectorX> also tried after apt-get install libwebp-dev but same [03:05:22 CEST] <kevmitch> there's nothing that decodes 4k blu rays other than hardware players last time i checked. [03:05:24 CEST] <tdr> furq, i only use that open a disc once because it can fetch working keys [03:07:43 CEST] <furq> VectorX: looks like you're missing cc1obj [03:07:58 CEST] <furq> i think that's part of gobjc on debian [03:11:39 CEST] <furq> actually nvm i don't think that error means anything [03:12:01 CEST] <furq> it just can't find libwebp in your pkg-config path [03:29:10 CEST] <VectorX> furq what can i do [03:56:01 CEST] <james999> eh to play 4k bluray on linux... sounds like something i'd have to google for [04:03:40 CEST] <furq> VectorX: make sure libwebp.pc is in the right place [04:04:38 CEST] <klaxa> i had nothing but trouble with blurays on linux [04:05:46 CEST] <VectorX> its already in /usr/lib/x86_64-linux-gnu/pkgconfig/libwebp.pc [04:12:59 CEST] <VectorX> furq where should i copy the file to [04:13:12 CEST] <furq> that's already the right place [04:13:29 CEST] <furq> if you installed libwebp-dev then i don't know why that would be failing [04:17:59 CEST] <klaxa> maybe pkg-config misconfigured? maybe add the path to the PKG_CONFIG_PATH variable? [04:19:12 CEST] <furq> it shouldn't be on debian/ubuntu [04:20:35 CEST] <klaxa> well, i know _I_ for one can break any system to unusability :) [04:20:48 CEST] <klaxa> by accident too [04:21:17 CEST] <furq> i don't know how you would even do that [04:21:26 CEST] <klaxa> i wish i knew [04:21:31 CEST] <furq> without recompiling pkg-config with a different hardcoded path [04:21:49 CEST] <furq> and there's a very specific amount of drunk you'd have to be to be capable of doing that but incapable of remembering [04:21:54 CEST] <furq> that i don't think anyone has ever achieved [04:24:38 CEST] <VectorX> klaxa same result after PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig [04:24:49 CEST] <furq> yeah it can't possibly be that [04:25:00 CEST] <furq> that path is hardcoded [04:25:30 CEST] <VectorX> this is so annoying [04:25:32 CEST] <furq> check that the headers and libs are in the right place and that the .pc is actually correct [04:25:57 CEST] <furq> also fwiw i always found cwebp to be much less hassle [04:26:11 CEST] <furq> but i guess if you're not just encoding png to webp then it's not really a good answer [04:26:41 CEST] <VectorX> yeah i need to make a animated webp into a mp4 [04:26:47 CEST] <VectorX> not even sure if it could do that [04:26:54 CEST] <furq> yeah that ought to work [04:27:26 CEST] <furq> er [04:27:35 CEST] <furq> which debian are you on [04:27:44 CEST] <furq> ffmpeg from the stretch repos has libwebp enabled [04:28:56 CEST] <furq> if you're on stable you might as well upgrade, stretch is due to be released any day now [04:29:24 CEST] <furq> wait nvm i forgot that ubuntu exists again [04:30:14 CEST] <furq> same thing with new ubuntu though [04:32:13 CEST] <VectorX> ubuntu [04:32:46 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [04:32:50 CEST] <furq> these builds have libwebp as well [04:38:26 CEST] <james999> i use debian but i don't remember what their bureacratic policy is [04:38:47 CEST] <james999> something like, they freeze updates to stable. then sid becomes the new release... or something [04:42:46 CEST] <furq> sid never becomes the new release [04:42:57 CEST] <furq> they freeze updates to testing, then testing becomes the new stable [04:43:11 CEST] <furq> which is what's happening now [04:43:26 CEST] <furq> which is annoying because it means my supposedly rolling distro has only had security updates since february [04:51:39 CEST] <james999> they've frozen testing since feb? [04:53:26 CEST] <furq> yeah [04:53:39 CEST] <furq> the official release schedule is "when it's ready" [04:53:49 CEST] <furq> which sounds big and clever when you've not been stuck in a package freeze for three months [05:04:12 CEST] <james999> i thought you were going to say i was an idiot for even suggesting that [05:04:39 CEST] <james999> haha [05:12:37 CEST] <VectorX> i also noticed, "WARNING: pkg-config not found, library detection may fail." how can i get that fixed [05:14:23 CEST] <furq> er. [05:14:31 CEST] <furq> well no wonder pkg-config can't find any libs if you don't have it installed [05:14:34 CEST] <furq> so install it [05:14:46 CEST] <VectorX> yup did that, config worked, that was the issue [05:17:53 CEST] <VectorX> now i get [webp @ 0x1f3fe40] skipping unsupported chunk: ANIM [05:18:05 CEST] <VectorX> ffmpeg -i 3add57529c64805ab3ed3d87ddeca805.webp a.mp4 [05:33:15 CEST] <VectorX> https://pasteboard.co/byYR8p6K8.png [05:34:21 CEST] <VectorX> also tried with -analyzeduration 2147483647 -probesize 2147483647 but same [05:50:46 CEST] <furq> https://trac.ffmpeg.org/ticket/4907 [05:50:47 CEST] <furq> oh [05:59:06 CEST] <DSmateJ> i have $250,000 to invest , what should i buy [06:01:32 CEST] <furq> you could buy me a house [06:02:07 CEST] <furq> in return, i will send you one (1) picture of me enjoying living in the house every week. i will not be nude [06:02:37 CEST] <furq> not after last time [06:24:25 CEST] <Kuukunen> for the rest of your life?! [06:24:30 CEST] <Kuukunen> that's a big commitment [06:51:48 CEST] <VectorX> furq thanks for the error, what can i do in this situation [07:52:50 CEST] <tezogmix> follow-up from earlier: if combining all 4 examples together, then the "pause" would be right below the last command right? (so that I wouldn't have to be there to press any key to continue the next action found in the batch file)? [07:53:02 CEST] <tezogmix> https://pastebin.com/3dG9uBzb > example [07:53:45 CEST] <tezogmix> I was going to run a few different input files right before bed [10:16:29 CEST] <jasom> is it possible to use gstreamer as an ffmpeg input? [11:17:48 CEST] <crziter> Do I need to call sws_freeContext to free context from sws_getContext? [12:08:56 CEST] <dreamon> hello using avconv -ss 00:36:00 -i Pak2_1.mkv -vcodec copy -acodec copy Out.mkv to cut a movie but [matroska @ 0x2deafa0] failed to avoid negative pts -62 in stream 1. Try -avoid_negative_ts 1 as a possible workaround. [12:09:21 CEST] <BtbN> avconv is not an ffmpeg tool. [12:09:55 CEST] <dreamon> sorry .. same on ffmpeg [12:10:26 CEST] <dreamon> ffmpeg -ss 00:36:00 -avoid_negative_ts -i Pak2_1.mkv -vcodec copy -acodec copy Out.mkv [12:10:40 CEST] <dreamon> Output file #0 does not contain any stream [12:11:13 CEST] <BtbN> Is the input file even that long? [12:11:36 CEST] <BtbN> also, you're missing the parameter to -avoid_neg_ts [12:12:08 CEST] <dreamon> fmpeg -i VTS_01_2.mkv -vcodec copy -acodec copy -t 00:31:44 VTS_Out.mkv works fine [12:12:22 CEST] <BtbN> Also, just use -c copy [12:12:29 CEST] <BtbN> acodec/vcodec are old [12:16:01 CEST] <dreamon> BtbN, This works. Is there a gui tool for ffmpeg that make handling it easier? [12:16:07 CEST] <BtbN> no [12:16:35 CEST] <BtbN> Also, what do you mean, this works? -c copy is just the modern syntax for -a/vcodec copy [12:16:43 CEST] <BtbN> Is should not change functionality in any way [12:17:12 CEST] <dreamon> BtbN, I used the wrong input file.. that wasnt long enough. an I was 100% sure it was the right one [12:19:14 CEST] <dreamon> BtbN, Thank you [12:37:58 CEST] <userdr> Media Player Classic not running [14:08:47 CEST] <fps> i'm trying my luck with delaying audio: ffmpeg -y -i 03_replaced_audio_put2.mp4 -itsoffset 20.0 -i 03_replaced_audio_put2.mp4 -map 0:0 -map 1:1 -vcodec copy -acodec copy 03_replaced_audio_delayed_put2.mp4 [14:09:04 CEST] <fps> 20 secs give no delay at all. 30 secs gives 30 secs of delay. is that a key frame issue? [14:31:51 CEST] <fps> ah drats, i'll just use sox to insert silence into the wav [15:03:26 CEST] <faLUCE> I'm seeing that there is a code called "avplay.c", which is a player. Do you know what is the difference with ffplay and if it supported? [15:03:37 CEST] <faLUCE> I'm seeing that there is a code called "avplay.c", which is a player. Do you know what is the difference with ffplay and if it is supported? [15:07:39 CEST] <faLUCE> Do you know if is there a good library for making an audio/video player? I tried upipe but it's in a bad state, then I tried libmpv but it has a too small API, which doesn't allow to control many parameters... libvlc has the same problem as libmpv. [15:08:01 CEST] <faLUCE> in addition libav requires too much code for making a player [15:41:07 CEST] <userdr> i use autoit recently and i want to obtain a list of dshow devices i have trough devices DLL but i dont know how to interact with parameters when calling the DLL [19:03:09 CEST] <ppw> what would be the proper command to mix 5.1 channel audio down to 2? [19:03:24 CEST] <furq> -ac 2 [19:03:58 CEST] <ppw> uh, I don't think that respects the Dolby Digital 5.1 mixdown matrix [19:05:44 CEST] <ppw> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1851 [19:11:43 CEST] <furq> in that case i guess you want -ac 2 -af aresample=matrix_encoding=dolby [19:11:59 CEST] <furq> or dplii for the prologic 2 matrix [19:12:26 CEST] <ppw> niiice [19:16:28 CEST] <lengtche> I'm using command `ffmpeg.exe -i '.\aaa.flac' -codec:a libmp3lame -q:a 0 aaa.mp3` to convert FLAC to MP3 v0 using the LAME plugin. Whenever I play this music in foobar2000 (for example), I see the quality as VBR instead of VBR v0. But if I do the same conversion using LAME's binary, I get the correct quality shown. Why is that? [19:16:48 CEST] <furq> ffmpeg doesn't write the xing header the same as the lame binary [19:17:06 CEST] <furq> the files should be identical, it'll just show up differently with stuff that reads that header [19:17:38 CEST] <furq> iirc there's an outstanding bug report for it but it's not exactly a critical feature [19:28:49 CEST] <lengtche> furq: Thanks for the prompt reply. :D [20:00:10 CEST] <thebombzen> furq: is there any remuxing workaround of some variation of ffmpeg -i foo.mp3 -c copy bar.mp3 [20:00:33 CEST] <jasom> is it possible to use gstreamer as an ffmpeg input? [20:01:57 CEST] <teratorn> jasom: since gstreamer has an ffmpeg plugin, probably [20:02:23 CEST] <furq> thebombzen: for what [20:02:44 CEST] <thebombzen> about the tags from before [20:02:49 CEST] <teratorn> jasom: but I'm guessing you would use gstreamer, not ffmpeg, as the front-end [20:02:52 CEST] <thebombzen> ffmpeg not writing the vbr correctly [20:03:02 CEST] <furq> no? [20:03:09 CEST] <furq> it's specifically the ffmpeg mp3 muxer that doesn't do that [20:03:34 CEST] <furq> lame is the only thing that does it, it's not part of any standard [20:03:52 CEST] <furq> obviously, since it's writing the lame vbr profile [20:05:02 CEST] <jasom> teratorn: composing a gst-launch command hurts my brain, but gstreamer has a v4l2 bugfix for years that's languished in the ffmpeg bugtracker :( [20:06:39 CEST] <teratorn> jasom: link? [20:07:31 CEST] <jasom> teratorn: https://trac.ffmpeg.org/ticket/4988 [20:09:14 CEST] <jasom> though I suppose the patch was only posted 9 months ago, so not too terrible. I suppose I could apply the patch locally as well. [20:11:36 CEST] <teratorn> jasom: so it's a work-around for a v4l2 driver bug? [20:12:00 CEST] <teratorn> I think I would make sure that hasn't been fixed upstream, too [20:15:44 CEST] <jasom> teratorn: I'm not convinced it's a driver bug per-se. at least the gstreamer bug discussion seemed to be unsure. [20:17:01 CEST] <teratorn> jasom: does the thing about reloading the driver help you? [20:17:12 CEST] <jasom> for about 30 seconds [20:17:51 CEST] <teratorn> well, ffmpeg is starting up fresh each time, so the persistent issue must be on the driver side, right? [20:18:23 CEST] <jasom> actually each time I restart ffmpeg it works fine, since the fix for #4030 is in [20:19:13 CEST] <jasom> The merge commit describes the behavior of the driver thusly: "This allow skipping buffer flagged with ERROR that has no payload. This is typical behaviour when a recovererable error occured during capture in the driver, but that no valid data was ever written into that buffer." [20:19:42 CEST] <teratorn> I see - webcams and usb are terrible [20:20:35 CEST] <jasom> yes, though this seems to be most common with Magewell UVC devices. Possibly just because they generate so much more data than the typical webcam [20:21:23 CEST] <jasom> (In this case uncompressed 4:2:0 1080p30 video) [20:21:54 CEST] <Munt> Hey folks I'm doing a recursive encoding of all my MOV files (about 200). I wish to archive them so they take up less space. currently I am doing ffmpeg -i filein.mov -preset slow fileout.mp4 How does ffmpeg in this instance determine the bitrate of the output file ? [20:22:59 CEST] <jasom> Munt: are you specifying a video codec at all? [20:23:07 CEST] <teratorn> jasom: ~93MB/s is a lot, I guess :/ [20:23:32 CEST] <furq> Munt: it doesn't, it uses the libx264 defaults (assuming you have a build with libx264) [20:23:35 CEST] <furq> which is -crf 23 [20:23:46 CEST] <Munt> jasom : I thought adding the .mp4 on the output file specified h264 ? [20:23:51 CEST] <furq> ^ [20:24:08 CEST] <jasom> Munt: to translate what furq says, it uses fixed-quality rather than fixed bitrate encoding [20:24:26 CEST] <Munt> should I bump it up a little for my archives ? [20:24:33 CEST] <furq> probably [20:24:44 CEST] <Munt> the output files are very small and at around 4500kbps I can afford more space [20:24:53 CEST] <furq> if it's for archival then you should probably just not reencode them [20:24:59 CEST] <jasom> Munt: probably; are the .mov files lossy compressed already? [20:25:27 CEST] <Munt> It varies widely. Currently they take up over 600GB and I want to back them up to blueraydl [20:25:40 CEST] <jasom> because compression artifacts are themselves hard to compress, and sometimes throw off the psy filter in h264 [20:25:58 CEST] <Munt> is there a way for ffmpeg to skip already compres files ? [20:26:03 CEST] <furq> no [20:26:16 CEST] <furq> mostly because they're all already compressed [20:26:34 CEST] <Munt> what do you think a good -crf value for me would be ? (also how long is a piece of string :P) [20:26:44 CEST] <furq> i use 20 for more or less everything [20:27:02 CEST] <furq> 18-22 is pretty sensible [20:27:43 CEST] <Munt> bigger is better i presume ? [20:27:47 CEST] <furq> lower is better [20:27:53 CEST] <jasom> Munt: There's no one-size-fits-all. I was re-encoding a poorly mastered DVD and had to run some serious filtering on it to get acceptible quality at 18, though usually 18-22 is going to be unnoticable. [20:28:15 CEST] <Munt> that's very valuable information folks thanks a lot <3 [20:28:51 CEST] <sfan5> you'd think with the amount of times this question has been asked here or elsewhere someone would've written a guide on how to chooce x264 encoding params... [20:29:00 CEST] <jasom> there is a guide [20:29:03 CEST] <jasom> on the ffmpeg wiki [20:29:09 CEST] <furq> there's probably one on the wiki but i'd generally rather not link the wiki [20:29:14 CEST] <furq> since so much of it is garbage [20:29:40 CEST] <jasom> https://trac.ffmpeg.org/wiki/Encode/H.264 [20:29:59 CEST] <jasom> includes options for iOS compatibility even [20:30:44 CEST] <Munt> I have been researching it. I'm also very indecisive :$ I really appreciate the advise thanks folk. [20:30:56 CEST] <Munt> s/folk/folks [20:31:28 CEST] <Munt> and apparently my reading comprehension leaves a lot to be desired >,< [20:41:09 CEST] <Munt> do you think I'll gain much wuality on the slow setting at -crf 18 ? Or am I better working a bit faster ? [20:41:40 CEST] <sfan5> if you're doing this for archival i'd suggest keeping as much quality as you can afford [20:42:04 CEST] <Munt> cool, thanks sfan5 [20:53:37 CEST] <[empty]> i have $250,000 to invest , what should i buy [20:54:07 CEST] <durandal_1707> bitcoins [20:54:14 CEST] <klaxa> monero maybe? [20:54:31 CEST] <klaxa> or ripple, that's backed by the banks, make sure to sell before the whole banking system collapses though [20:55:05 CEST] <[empty]> klaxa is that a stock? [20:55:18 CEST] <klaxa> crypto currencies [20:55:54 CEST] <klaxa> i wouldn't be surprised if monero becomes the new bitcoin though [20:56:08 CEST] <[empty]> klaxa so if you had $250,000.00 , you woulld really invest on cryptocurrency? [20:56:18 CEST] <[empty]> all of it [20:56:21 CEST] <klaxa> probably [20:56:52 CEST] <klaxa> just look at the bitcoin course [20:57:03 CEST] <klaxa> basically exponential growth for over two years [20:57:07 CEST] <[empty]> klaxa do you trust 250k on cryptocurrency exchange sites? [20:57:13 CEST] <klaxa> no [20:57:21 CEST] <[empty]> that's a problem then [20:57:26 CEST] <klaxa> you can put it on your own wallet [20:57:29 CEST] <[empty]> how do you expect to buy without using exchange sites [20:57:38 CEST] <klaxa> that's the whole point of crypto currencies [20:57:41 CEST] <klaxa> you don't trust anyone [20:58:05 CEST] <klaxa> you can buy at an exchange and transfer it to your personal wallet [20:58:08 CEST] <[empty]> klaxa you still have to trust somebody to buy coins [20:58:15 CEST] <[empty]> since it has to be done by exchange sites [22:39:30 CEST] <jasom> [empty]: VDMIX [22:39:50 CEST] <[empty]> jasom is that mutual fund? [22:40:52 CEST] <jasom> [empty]: eys [22:41:39 CEST] <[empty]> how much are you invested with mdmix [22:41:43 CEST] <[empty]> vd* [22:41:47 CEST] <jasom> looks like VDMIX is closed; VTMGX is the similar fund [22:42:12 CEST] <jasom> [empty]: I'd have to check since it's volatile, but probably around $200k [22:42:21 CEST] <[empty]> wow that's alot [22:43:23 CEST] <jasom> need to move some out now that I'm getting older actually; this is all retirement savings [22:53:13 CEST] <jasom> [empty]: not as much if it's what you're planning on living off of soon... [22:53:21 CEST] <[empty]> jasom no i am not [22:53:30 CEST] <jasom> [empty]: was referrign to me [22:53:48 CEST] <[empty]> oh [22:58:46 CEST] <nadermx> Anyone know why when I make a mp4 to a mp3 with a thumbnail it works fine unless I send it to stdout in which case the thumbnail is not added but the rest of the metadata is? [23:20:36 CEST] <ExeciN> I want to stream audio and video to another computer. I want to be listening so no port forwarding would be needed by the other computer [23:20:49 CEST] <ExeciN> this is what I'm trying to use: ffmpeg -f avfoundation -framerate 15 -i "1:4" -vf scale=960:540 -vcodec libx264 -pix_fmt yuyv422 -tune zerolatency -preset ultrafast -f mpegts tcp:0.0.0.0:4567?listen [23:21:30 CEST] <klaxa> looks okay [23:21:35 CEST] <ExeciN> can I use 0.0.0.0 as my host and bind it everywhere? [23:21:46 CEST] <klaxa> oh wait [23:21:53 CEST] <ExeciN> also is this how I listen to connections? [23:21:54 CEST] <klaxa> use tcp://0.0.0.0:4567 [23:22:31 CEST] <klaxa> not sure if ?listen is correct, i know that -listen 1 is definitely correct [23:22:56 CEST] <klaxa> so: ffmpeg -f avfoundation -framerate 15 -i "1:4" -vf scale=960:540 -vcodec libx264 -pix_fmt yuyv422 -tune zerolatency -preset ultrafast -f mpegts -listen 1 tcp://0.0.0.0:4567 [23:23:32 CEST] <ExeciN> wow it finally works [23:23:41 CEST] <ExeciN> I definitely had a malformed url [23:28:39 CEST] <ExeciN> as it seems both -listen 1 and ?listen works but I think I'll use -listen 1 to make it a bit more clean [00:00:00 CEST] --- Mon May 29 2017

1 0

ffmpeg-devel.log.20170527
by burek 28 May '17

28 May '17

[01:15:08 CEST] <BtbN> coverity was broken for like a month, because the version.sh script was moved. Somehow never got a failure e-mail from travis. [04:22:56 CEST] <cone-867> ffmpeg 03Michael Niedermayer 07master:1a36354698fc: avformat/mux: Fix copy an paste typo [08:11:31 CEST] <stevenliu> Hello guys? Are there have a vfilter can do the function: transpose the picture any angle? for example: 45° or 30° ? [08:12:13 CEST] <stevenliu> I saw the transpose only can transpose times of 90° [08:16:59 CEST] <ubitux> you mean rotate? [08:17:05 CEST] <ubitux> you have the rotate filter.. [14:58:58 CEST] <cone-830> ffmpeg 03Michael Niedermayer 07master:77d98898211e: avcodec/pixlet: Fix runtime error: signed integer overflow: 2147483647 + 32 cannot be represented in type 'int' [14:58:58 CEST] <cone-830> ffmpeg 03Michael Niedermayer 07master:53c0c637d36c: avcodec/ra144dec: Fix runtime error: left shift of negative value -17 [14:58:58 CEST] <cone-830> ffmpeg 03Michael Niedermayer 07master:ac8dfcbd89a8: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error [18:55:24 CEST] <durandal_1707> spam overflow [19:51:45 CEST] <jamrial> michaelni: when does av_reduce() generate a "non exact" result? when you constrain it too much with a small max value? [20:31:59 CEST] <nevcairiel> yes [20:32:24 CEST] <jamrial> cool, thanks [21:16:33 CEST] <cone-944> ffmpeg 03James Almer 07master:ab05bd6e6cae: avformat/mov: add support for reading Mastering Display Metadata Box [21:16:33 CEST] <cone-944> ffmpeg 03James Almer 07master:24133973fc24: avformat/mov: add support for reading Content Light Level Box [00:00:00 CEST] --- Sun May 28 2017

1 0

ffmpeg.log.20170527
by burek 28 May '17

28 May '17

[00:07:38 CEST] <c_14> use 2 outputs [00:59:03 CEST] <guther> Does -preset in libx264 influence quality when used with -cfr ? [00:59:41 CEST] <furq> yes [00:59:56 CEST] <furq> assuming you mean -crf, but it'll do that with any rc [01:00:53 CEST] <iive> it either influences quality or bitrate [01:01:01 CEST] <iive> or both [01:03:10 CEST] <furq> quality much more than bitrate [01:03:19 CEST] <furq> it's totally normal for bitrate to increase when you use a slower preset [01:03:34 CEST] <marquisor> true :) [01:05:25 CEST] <iive> furq: shouldn't it be the opposite :P [01:05:30 CEST] <furq> no [01:05:44 CEST] <furq> i mean intuitively yes but it's never worked like that [01:06:07 CEST] <furq> the meaning of a crf value depends on the encoder settings [01:06:27 CEST] <guther> sorry, lost connection :( [01:06:51 CEST] <furq> guther: http://ffmpeg.gusari.org/irclogs/ffmpeg.log.20170527 [01:06:53 CEST] <guther> furq, which codec do you preferre? [01:07:01 CEST] <furq> x264 [01:07:17 CEST] <guther> Uh, theres a log - good to know, thanks [01:07:52 CEST] <guther> x264 is the same as that libx264 i use? [01:07:55 CEST] <furq> yes [01:08:04 CEST] <guther> Fine [01:08:24 CEST] <guther> Does n-pass enc any sense nowadays? [01:08:33 CEST] <furq> not unless you're targeting a particular filesize [01:09:02 CEST] <guther> how much is it in percent, roughly [01:09:19 CEST] <furq> i have no idea [01:09:27 CEST] <guther> What preset do you use? [01:09:30 CEST] <furq> veryslow [01:10:17 CEST] <furq> the only use for 2-pass with x264 is in abr mode, which you almost never use [01:10:33 CEST] <guther> uhm, i thought, even slower seems a bit too time consuming to me [01:10:44 CEST] <furq> the first pass makes it more likely to hit the target bitrate [01:10:59 CEST] <furq> in crf mode it makes literally no difference [01:11:15 CEST] <furq> other than your cpu fan will be running for longer [01:11:32 CEST] <guther> Yeah, thats the impression i got from reading the inet [01:11:56 CEST] <furq> any preset below faster will give passable results [01:12:05 CEST] <furq> you can always just increase the crf to compensate [01:12:57 CEST] <furq> i used to use slow at crf 20 for >=720p and that stuff all still looks fine to me [01:14:18 CEST] <furq> if you keep your sources backed up somewhere then it doesn't really matter what you use [01:14:55 CEST] <guther> I'm experimenting with crf 21 and slow/slower - that seems reasonable to me [01:15:34 CEST] <guther> With 1280 [01:18:11 CEST] <guther> Btw, is there a way to pass cutlists to ffmpeg? [01:19:42 CEST] <furq> !muxer segment @guther [01:19:42 CEST] <nfobot> guther: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [01:19:45 CEST] <furq> see -segment_times [01:19:48 CEST] <furq> that's the closest thing i know of [01:20:22 CEST] <BtbN> Wasn't cue sheet support recently merged? Or is it still on the ml? [01:20:30 CEST] <furq> oh really [01:20:36 CEST] <furq> that would make something i was planning on writing much easier [01:21:50 CEST] <BtbN> nah, still sitting on the ml [01:22:41 CEST] <tute23> Hello, a question, I use ffmpeg to make a live broadcast by icecast from "alsa", I have a problem launching a new instance of ffmpeg for alsa record in a file and being able to restart the streaming ffmpeg for any problems without cutting the recording Of file , error : "device is bussy" [01:23:16 CEST] <BtbN> seems like your device does not support multiple processes accessing it at the same time [01:24:51 CEST] <tute23> Is there a way to launch ffmpeg without locking the device ??? [01:25:47 CEST] <tute23> or any possible solution on the alsa side with alsa loop? [01:25:50 CEST] <BtbN> it's up to the device if it supports multiple client [01:25:56 CEST] <BtbN> this one does not [01:26:03 CEST] <BtbN> could use pulseaudio to workaround that limitation [01:26:08 CEST] <tute23> is a USB audio device [01:27:56 CEST] <tute23> Ok, thank you, I'll try with press, should not have problems launching for example arecord and ffmpeg at the same time? [01:29:00 CEST] <BtbN> whoever accesses the device first wins [01:29:05 CEST] <BtbN> no matter if it's ffmpeg or arecord. [01:29:36 CEST] <DHE> av_interleaved_write_frame() is supposed to effectively write all streams in a globally sorted DTS order, right? because I'm looking at the output (mpegts using wireshark) and that's not true. [08:01:44 CEST] <crziter> I'm going to use FFMPEG in my app to display live video from cameras, do I need to synchronize video when live streaming like this? [08:02:11 CEST] <bigbrous40> i have $250,000 to invest , what should i buy [08:06:04 CEST] <tdr> bigbrous40, how about a lot of candy corn and swedish fish? [08:23:43 CEST] <thebombzen> Sweedish Fish are much tastier than Candy Corn [08:23:48 CEST] <thebombzen> Kit Kats are still bet candy though [08:28:08 CEST] <tdr> i prefer candy corn, they dont stick to your teeth [08:28:22 CEST] <tdr> still rather have decent chocolate tho [09:05:26 CEST] <Fyr> guys, I can't google out examples of usage of loudnorm. [09:05:31 CEST] <Fyr> could you help me out? [09:06:59 CEST] <Fyr> or with dynaudnorm filter [09:34:21 CEST] <c3r1c3-Win> Fyr: Maybe try "Broadcast Loudness Standards" [09:34:51 CEST] <Fyr> c3r1c3-Win, what? [09:35:13 CEST] <Fyr> I need an example of -filter:a loudnorm [09:35:27 CEST] <Fyr> I has a huge number of parameters which I don't understand. [09:35:46 CEST] <c3r1c3-Win> Fyr: Yesa nd do you know this filter exists? [09:36:00 CEST] <c3r1c3-Win> Do you know what basis this filter has and what the parameters mean? [09:36:05 CEST] <Fyr> no [09:36:08 CEST] <Fyr> not at all [09:36:21 CEST] <Fyr> found it on stackexchange without examples. [09:36:34 CEST] <c3r1c3-Win> It comes from the CALM act passed in the USA (and before that another one passed in Europe) to controll the peak and overall loudness of audio. [09:36:45 CEST] <c3r1c3-Win> *of audio for broadcast. [09:37:01 CEST] <Fyr> c3r1c3-Win, how do I use those filters? [09:37:07 CEST] <JEEB> wasn't the ebu r-128 filter for that? [09:37:19 CEST] <JEEB> it did some loudness stuff [09:37:43 CEST] <Fyr> I have a crappy videos with too quiet sound and some times, normal sound. [09:38:15 CEST] <c3r1c3-Win> So since you have no idea what the various variables mean (or even why this filter exists) I told you to google about the "Broadcast Loudness Standards" and that would (hopefully) educate you about it. [09:38:16 CEST] <Fyr> I need to make it sound more pleasurable. [09:38:33 CEST] <c3r1c3-Win> Fyr: If you just want to lower the dynamic range, use a compressor. [10:05:33 CEST] <crziter> Does avcodec_send_packet/avcodec_receive_frame reorder video frames by PTS value internally? [10:06:04 CEST] <crziter> Or we have to reorder it by ourself? [12:03:37 CEST] <debianuser> tute23, BtbN: it probably doesn't matter any more, but in case you're curious - don't capture from "hw:CardName" pcm if you want multiple apps capturing at the same time, in plain alsa use "dsnoop:CardName" instead (or capture from "default" pcm, it should include "dsnoop" in capture chain by default) [12:13:04 CEST] <momomo> if i setdar=16/9 ... what is going to happen .. it will adjust the ratio right ... but what is setsar for ?? [12:21:30 CEST] <Threads> https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar [12:21:43 CEST] <Threads> momomo read ^ [12:21:47 CEST] <Threads> !filter [12:51:39 CEST] <vlitomsk> Hi guys! Is there media container which supports video,audio and some 2d vector overlay for video? I need to append some geometry primitives to the video without re-coding it. Heard about mpeg4 BIFS, but looks like it died in 2000s :( [12:52:31 CEST] <vlitomsk> Sometimes i need different overlays for same "clean" video, and re-coding is cpu-wasting. Is there any widely (or not so widely ;) ) supported format including this feature? [13:51:15 CEST] <ChocolateArmpits> vlitomsk, do you need support for additional data tracks ? rendering stuff on top is not a common function with media players outside of subtitles [13:53:33 CEST] <vlitomsk> ChocolateArmpits: yes, i need additional data track. Can it be done through subtitles? [13:54:58 CEST] <ChocolateArmpits> Substation alpha format can draw vectors, but I'm not sure how far you can push it [13:58:08 CEST] <ChocolateArmpits> MXF has support for custom data tracks, but you'd have to do the rendering part yourself. MXF decoders presume that any unidentified parts should be skipped [14:11:07 CEST] <vlitomsk> ChocolateArmpits: i understood why you doesn't use abbreviation for Substation alpha format :-) Yes, it supports vector graphics (http://docs.aegisub.org/3.2/ASS_Tags/) and I hope that the drawing scripts are encoded to smth binary [15:26:15 CEST] <tgunb> Hey guys, why doesn't ffmpeg/ffprobe detect the picture metadata in jpegs from my camera? (like camera model, settings and stuff) [15:26:33 CEST] <tgunb> I use ffmpeg version 2.8.11-0ubuntu0.16.04.1 [15:29:10 CEST] <tgunb> the configuation contains --disable-decoder=libopenjpeg --enable-libopenjpeg. is that the reason? [15:29:20 CEST] <JEEB> no [15:29:26 CEST] <JEEB> openjpeg is used only for j2k [15:29:56 CEST] <JEEB> also no idea how many tags libavformat reads from JPEG files :P [15:31:39 CEST] <tgunb> even -map_metadata doesn't copy them. are you saying, that that is not implemented? [15:32:05 CEST] <tgunb> (reading those jpeg tags) [15:32:14 CEST] <JEEB> seems like 2.1+ has some EXIF support [15:32:17 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/commit/bb4e1b4cf910af0de2bc884c75544603c40… [15:32:50 CEST] <JEEB> of course no idea if ffmpeg.c or ffprobe.c utilize that [15:35:17 CEST] <momomo> i am getting this message [15:35:18 CEST] <momomo> Past duration 0.934120 too large [15:35:24 CEST] <momomo> and then it disconnects [15:35:28 CEST] <momomo> when i am generating hls [15:35:54 CEST] <momomo> i've tried with reconnect_at_eof reconnect_streamed and more ... but nothing seems to bite [15:35:59 CEST] <momomo> the connection dies [15:37:39 CEST] <momomo> if I set reconnect_at_eof it works and does not drop the connection [15:37:45 CEST] <momomo> however, it sends up in a loop [15:38:13 CEST] <momomo> jumping back in the stream and then encountering the same problem again and do that over and over again [15:38:34 CEST] <tezogmix> hey all, how would I create a custom batch file that has unique ffmpeg command line entries and file inputs for fffmpeg-windows? I posted 4 examples to pastbin right now. In the 1st 2 examples, I just run each of those batch files separately and once the full task is done. Example 3 & 4 are just manual commands. [15:38:49 CEST] <tezogmix> https://pastebin.com/REFycT3Q [15:39:49 CEST] <tezogmix> I found some of the 1st 2 example batch files from a regular web search and those have been working alright but sometimes I have a bunch of different files and would be nice to have run overnight [15:40:12 CEST] <furq> are you asking how you run all of those commands at once in order [15:40:24 CEST] <tezogmix> hey furq , yes something like that... [15:40:32 CEST] <furq> you do the thing you just did on pastebin [15:40:36 CEST] <tezogmix> so each example is a single operation - [15:40:49 CEST] <tezogmix> i just copied it all and put on paste bin [15:41:03 CEST] <tezogmix> oh, so i just put all those lines as is in one batch file then? [15:41:06 CEST] <furq> yes [15:41:23 CEST] <furq> also i don't think the third command does what you think it does [15:41:37 CEST] <furq> -r doesn't do anything as an input option if the input is mp4 [15:42:02 CEST] <tezogmix> oh with example 3, sometimes i had a 59.94fps file and wanted to convert it to 29.97 [15:42:21 CEST] <tezogmix> and sometimes it's 50fps and want it to be 25 [15:42:57 CEST] <tezogmix> unless it's something else you were talking about. [15:44:54 CEST] <momomo> furq: can you help with this ? i've been struggling with this one for weeks [15:44:57 CEST] <momomo> maybe it's a bug [15:45:08 CEST] <momomo> I am trying to update version now [15:48:39 CEST] <tezogmix> <furq> -r doesn't do anything as an input option if the input is mp4 >>> but if the input is a different fps and we wanted a different fps output, then the "-r" would be appropriate furq ? [15:51:30 CEST] <tezogmix> also furq with the "pause" line that I had below example 1 + example 2, if I'm combing all 4 examples together, then the "pause" would be right below the last command right? (so that I wouldn't have to be there to press any key to continue the next action found in the batch file)? [15:51:55 CEST] <tezogmix> combing=combining* [15:55:27 CEST] <tezogmix> so something like this (where all 4 commands are in 1 single batch) > https://pastebin.com/3dG9uBzb [19:44:45 CEST] <hrm99> Hi! Isn't there a Windows installer for ffmpeg? [19:46:15 CEST] <hrm99> Ok so I copy the .exe's to C:\Windows\System32 [19:46:46 CEST] <hrm99> No sorry. Can I paste some? [19:46:49 CEST] <hrm99> C:\yt>youtube-dl https://twitter.com/TRAKGIRL/status/868159765502939136 [19:46:49 CEST] <hrm99> [twitter] 868159765502939136: Downloading webpage [19:46:49 CEST] <hrm99> [twitter:card] 868159765502939136: Downloading webpage [19:46:49 CEST] <hrm99> [twitter:card] 868159765502939136: Downloading m3u8 information [19:46:49 CEST] <hrm99> [download] Destination: TRAKGIRL - That time @flyinglotus took us to church.-868159765502939136.mp4 [19:46:52 CEST] <hrm99> ERROR: m3u8 download detected but ffmpeg or avconv could not be found. Please install one. [19:47:21 CEST] <JEEB> put it next to youtube-dl -.- [19:47:27 CEST] <hrm99> I put ffmpeg.exe, ffplay.exe and ffprobe.exe into C:\Windows\System32 [19:47:44 CEST] <JEEB> and make sure they are not blocked as downloaded files [19:47:59 CEST] <hrm99> JEEB: Thanks man [19:48:07 CEST] <hrm99> That sounds like the sane way of doing it [19:48:22 CEST] <hrm99> They can be blocked? Hold up [19:48:37 CEST] <JEEB> right click and properties, the unlock thing is there if it is there [19:48:39 CEST] <hrm99> YES!! [19:48:44 CEST] <hrm99> we have ACTION here!! :D [19:49:09 CEST] <hrm99> it is time to sample my favorite part of my favorite beat of today :) [19:49:18 CEST] <hrm99> thanks JEEB [19:50:15 CEST] <hrm99> * beat of the day [20:08:29 CEST] <james999> what is your favorite beat? [20:12:06 CEST] <hrm99> james999: i shall export it [20:12:12 CEST] <hrm99> for EVERYONE TO SEE!! [20:12:18 CEST] <hrm99> (but mainly for you to see) [20:18:32 CEST] <hrm99> james999: https://soundcloud.com/fuckdeg/trakgrl-flylo i just looped up my youtube-dl ffmpeg clip [20:21:35 CEST] <hrm99> sorry had to eq the sound a bit, reuploaded [20:21:56 CEST] <hrm99> thanks again guys! [21:32:47 CEST] <Soni> can I rotate a JPEG with ffmpeg? [21:35:50 CEST] <dystopia_> you should be able to with transpose [21:36:59 CEST] <dystopia_> ffmpeg -i in.jph -vf "transpose=1" out.jpg [21:37:16 CEST] <dystopia_> 0 = 90CounterCLockwise and Vertical Flip (default), 1 = 90Clockwise, 2 = 90CounterClockwise, 3 = 90Clockwise and Vertical Flip [21:37:23 CEST] <Soni> cool, thanks [21:37:27 CEST] <dystopia_> np [21:37:34 CEST] <dystopia_> there is also vflip and hflip [21:37:40 CEST] <dystopia_> which do basically the same thing [21:52:52 CEST] <Exairnous> Hi, when using ffmpeg to split a stereo audio file to two mono files ffmpeg amplifies a very soft part in the right channel. How can I stop it doing this? [21:55:07 CEST] <Exairnous> terminal output: https://pastebin.com/tgfGcwHx [22:10:10 CEST] <durandal_1707> Exairnous: use lavfi filters instead [22:11:01 CEST] <Exairnous> durandal_1707: got an example handy? [22:11:41 CEST] <durandal_1707> read docs and wiki entry [22:12:26 CEST] <Exairnous> ok [22:13:31 CEST] <durandal_1707> basically use channelsplit filter [22:14:26 CEST] <Exairnous> thanks [22:20:25 CEST] <marquisor> lol what a nickname [22:21:20 CEST] <bob_twinkles> is it normal for filter performance to degrade the further it gets in to a job? [22:25:31 CEST] <durandal_1707> bob_twinkles: no, what filter ? [22:27:46 CEST] <Exairnous> durandal_1707: Using this command I got the same: [22:27:51 CEST] <bob_twinkles> durandal_1707: I'm not sure exactly where the slowdown is coming from, but this is the chain https://pastebin.com/z5aMgsPG [22:27:54 CEST] <Exairnous> ffmpeg -i "Keep the Whole World Singing - Tenor Right.mp3" -lavfi "[0:a]channelsplit[a1][a2]" -map "[a1]" -ac 2 f.l.mp3 -map "[a2]" -ac 2 f.r.mp3 [22:28:47 CEST] <bob_twinkles> but it's gone from 9FPS to ~2 over the course of 5k frames [22:29:28 CEST] <durandal_1707> Exairnous: ffmpeg does not amplifies anything out of nothing, make sure its not libmp3lame issue [22:30:37 CEST] <Exairnous> durandal_1707: I tested using sox and it doesn't have this issue, give me a sec, let me link an image to illistrate [22:31:18 CEST] <durandal_1707> because sox doesnt utilize lame [22:32:48 CEST] <Exairnous> so if I convert it first to wave and then run it through ffmpeg it shouldn't run into that problem? [22:32:56 CEST] <durandal_1707> bob_twinkles: move fps after scale [22:33:37 CEST] <durandal_1707> Exairnous: no mater what you do lame encoder will do it [22:34:15 CEST] <Exairnous> but if I use sox to convert to wav and then run it through ffmpeg that should eliminate lame, yes? [22:34:49 CEST] <furq> why are you running it through ffmpeg [22:34:55 CEST] <durandal_1707> Exairnous: sox does same thing albeit slower than ffmpeg [22:36:19 CEST] <furq> that was a rhetorical question but i notice the input is mp3 [22:36:37 CEST] <furq> lame isn't a decoder [22:36:40 CEST] <furq> in spite of its name [22:36:50 CEST] <furq> if you encode it to mp3 with ffmpeg then it's using libmp3lame [22:36:59 CEST] <Exairnous> furq: ok, what is lame? [22:37:05 CEST] <furq> it's an encoder [22:37:10 CEST] <furq> that's why it's called "lame ain't an mp3 encoder" [22:37:14 CEST] <furq> because it is an mp3 encoder [22:37:38 CEST] <furq> i was sort of hoping they'd change the name to lime since the mp3 patents expired, but never mind [22:38:38 CEST] <Exairnous> right, so if I change the file to a wav file enclosing pcm and work with that I won't be using lame, right? [22:38:54 CEST] <furq> sure [22:39:04 CEST] <furq> if you mean the output files [22:39:11 CEST] <furq> it makes no difference what you do with the input file [22:39:25 CEST] <Exairnous> right [22:39:43 CEST] <bob_twinkles> hrm [22:40:19 CEST] <bob_twinkles> if I'm willing to write some code against the ffmpeg API, would that execute faster than using the command line tool? [22:40:45 CEST] <Exairnous> nope, same problem encoding to wav [22:41:15 CEST] <furq> well yeah that might be an ffmpeg issue then [22:41:19 CEST] <furq> or your ears are wrong [22:41:20 CEST] <DHE> bob_twinkles: yes, but the codec work involved is probably going to be the real CPU bottleneck [22:41:49 CEST] <Exairnous> one second I'll grab a screenshot of the waveforms :) [22:42:12 CEST] <furq> bob_twinkles: maybe [22:42:24 CEST] <furq> it depends on what you're doing [22:42:38 CEST] <furq> it sounds like you're doing something pretty typical for ffmpeg, so i doubt it'll make an appreciable difference [22:42:56 CEST] <bob_twinkles> I linked the filter chain above, but basically taking N input videos and aranging them in a grid [22:43:07 CEST] <furq> are you encoding them [22:43:58 CEST] <bob_twinkles> I'm not changing the pixel format (I think?) but I do have to reencode the video yes [22:44:13 CEST] <furq> the slowdown is probably just caused by increasing complexity then [22:44:16 CEST] <bob_twinkles> since it's merging 4 video streams in to 1 [22:44:30 CEST] <durandal_1707> furq: thers no bug in channelsplit, you are propagating gold earphones [22:44:36 CEST] <furq> durandal_1707: don't blame me [22:45:14 CEST] <furq> if he's splitting to pcm and it sounds wrong then either his ears are wrong or you should probably be interested [22:45:32 CEST] <bob_twinkles> applying durandal_1707's suggestion and updating ffmpeg seems to have stabilized the FPS estimates [22:45:33 CEST] <durandal_1707> bob_twinkles: merging is fast,its just memcpy [22:46:06 CEST] <bob_twinkles> yeah, I assumed so [22:46:20 CEST] <bob_twinkles> would doing the vstacks/hstacks have an impact or is that just being silly? [22:46:28 CEST] <bob_twinkles> s/doing/changing the order of [22:46:31 CEST] <furq> that's what he means by merging [22:46:55 CEST] <bob_twinkles> I'm using hstack/vstack already [22:47:00 CEST] <zerodefect> Trying out libavfilter through the C API. I've created my first graph for video processing: buffer -> format -> colorspace -> fieldorder -> buffersink. Noticing an oddity with custom threading. [22:47:02 CEST] <furq> it would have an impact if you moved them before/after the scale [22:47:10 CEST] <furq> i assume it would have a negative impact if you moved them before but i don't really know [22:47:50 CEST] <zerodefect> In AVFilterGraph, I set the 'execute' value to my function, but it never gets called. I'm not sure if that's because none of the filters use threading? [22:47:53 CEST] <durandal_1707> doing multiple stacks just uses more memcpy,but thats fast on modern machines, if you want ultra speed for merging stuff in grids use shaders [22:49:08 CEST] <Exairnous> Here is an image of the right channel before ffmpeg and after ffmpeg: https://pasteboard.co/bs5bZgCaF.jpg [22:49:47 CEST] <bob_twinkles> that would involve having a GPU =/ [22:50:08 CEST] <bob_twinkles> moving the scale after the stacks is way slower lol [22:50:54 CEST] <furq> you probably want to try outputting rawvideo and see how fast it is [22:51:30 CEST] <furq> make sure that filtering is actually a noticeable bottleneck compared to encoding [22:51:33 CEST] <durandal_1707> Exairnous: how you obtained original? [22:52:15 CEST] <Exairnous> it's from a learning track from the Barbershop Harmony Society [22:53:20 CEST] <durandal_1707> Exairnous: what tool you used to extract original channel? [22:54:48 CEST] <bob_twinkles> it's about twice as fast with -c:v rawvideo [22:55:27 CEST] <bob_twinkles> stil only ~8 FPS though [22:55:53 CEST] <bob_twinkles> the machine this is running on is honestly not powerful enough to be doing serious video work so that's not entierly unexpected [22:56:01 CEST] <durandal_1707> bob_twinkles: that needs disk, -use -f null - [22:56:18 CEST] <bob_twinkles> the machine this is running on is honestly not powerful enough to be doing serious video work so that's not entierly unexpected [22:56:19 CEST] <Exairnous> ffmpeg. I only showed the right channel in the screenshot because it's the only one that has the problem. What I'm doing is extracting the right channel from the stereo file and outputing it to a stereo file of it's own [22:56:36 CEST] <Exairnous> durandal_1707: ^^ [22:57:40 CEST] <durandal_1707> Exairnous: can you give original mp3 , upload somewhere? [22:58:04 CEST] <Exairnous> the extra blip shown on the new file in the screenshot is actually there on the original, but it's so quiet you can't see it [22:58:34 CEST] <Exairnous> durandal_1707: maybe, just a second [23:00:12 CEST] <Exairnous> durandal_1707: here: http://www.barbershop.org/files/documents/freeandeasy/Keep%20the%20Whole%20… [23:01:48 CEST] <furq> i love #ffmpeg [23:02:00 CEST] <furq> this must be the only channel on freenode where someone can get help with becoming the tenor in a barbershop quartet [23:03:11 CEST] <Exairnous> furq: actually I'm doing this for a whole barbershop chorus :) [23:03:57 CEST] <furq> nvm then there are loads of channels for that [23:05:20 CEST] <Exairnous> the file is made so that the main part is in the right channel and the three other parts are mixed in the left channel, so I separate them out for easier learning so you get a, part none (to sing against), part only (to sing with), and the original right left mix (for a little of both) [23:06:40 CEST] <Exairnous> furq: but I agree, #ffmpeg has lots of neat and diverse conversations :) [23:10:30 CEST] <durandal_1707> i see two separate channels, they are like dual mono [23:10:43 CEST] <Exairnous> yeah [23:12:24 CEST] <Exairnous> if you split them using ffmpeg compare the right channel of the original and the output from ffmpeg [23:12:46 CEST] <Exairnous> and you'll see what's in my screenshot [23:13:18 CEST] Action: Exairnous really hopes this isn't happening only to me [23:20:36 CEST] <durandal_1707> Exairnous: its ffmpeg decoder vs libmad one i think [23:22:07 CEST] <Exairnous> it's a problem with the decoder? [23:28:09 CEST] <Exairnous> durandal_1707: yep, looks like it's a problem with the decoder. I just converted the mp3 to a wav using sox then used the wav as an input to ffmpeg and tested the output and everything was fine [23:32:01 CEST] <furq> are you using a really old ffmpeg or something [23:32:06 CEST] <furq> i didn't even know ffmpeg could use libmad [23:32:32 CEST] <durandal_1707> furq: audacity uses libmad [23:32:46 CEST] <furq> oh [23:33:31 CEST] <Exairnous> furq: ffmpeg version 3.2.2 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 6.2.1 (GCC) 20160830 [23:35:05 CEST] <Exairnous> furq: so it's slightly old, I haven't updated in a few months [23:44:17 CEST] <Exairnous> durandal_1707: can I make ffmpeg us the libmad decoder? [23:44:57 CEST] <durandal_1707> currently not [23:45:33 CEST] <Exairnous> --enable-lib won't do it? [00:00:00 CEST] --- Sun May 28 2017

1 0

ffmpeg-devel.log.20170526
by burek 27 May '17

27 May '17

[00:19:00 CEST] <daon> I'm using video playing software called "mpv (ver0.25.0)" in conjunction with "ffmpeg(ver3.3.1)". [00:19:14 CEST] <daon> When I play video with sami subtitle(extension: smi), it doesn't process "" tag in subtitle. [00:19:28 CEST] <daon> "" in lower character works fine, but upper character doesn't work. [00:19:54 CEST] <daon> Another Korean guy had made a issue at github.com(https://github.com/mpv-player/mpv/issues/3017) because of the same reason like me. [00:20:14 CEST] <daon> wm4(I can see the same id in user list of this ffmpeg channel) said it's matter of ffmpeg. [00:20:34 CEST] <daon> Is this matter of ffmpeg? If it is, I don't see why ffmpeg differenciate "" and "". Most Koreans use sami style subtitle format, so many people would go through this problem like me. [00:23:20 CEST] <jamrial> daon: he asked for a sample you never provided [00:23:44 CEST] <jamrial> also, if you think this may be a bug in ffmpeg, please open a ticket in http://trac.ffmpeg.org/ [00:25:30 CEST] <daon> Issue was a year ago. I couldn't decide which one do I have to report. [00:33:33 CEST] <J_Darnley> If you're not going to file a bug on FFmpeg's trac, or on mpv's github, then at least give us here a file that fails. [00:35:14 CEST] <jamrial> no, things shared here get lost and forgotten. the bug tracker exists for a reason [00:37:40 CEST] <J_Darnley> True but it is one tiny step beyong not sharing anything. [00:37:52 CEST] <J_Darnley> *beyond [00:47:35 CEST] <daon> here's sample smi file content => https://gist.github.com/anonymous/2be738766de9513de65c8844fdc5a2e5 [01:29:04 CEST] <thardin> aw yiss, quad core fuzzing [04:46:22 CEST] <daon> found how to fix "" problem. After modifying "libavcodec/htmlsubtitles.c" and recompiling ffmpeg&mpv, it works fine. [04:46:46 CEST] <daon> I'll submit it to ffmpeg.org. [04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:356194fcb173: avcodec/smc: Check remaining input [04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:8e87d146d798: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int' [04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:43c394dcaebe: avcodec/clearvideo: Check buf_size before decoding frame [11:12:53 CEST] <thardin> hum. is there a reason why ffmpeg would exit(130)? seems to be ctrl+c, but this is an automated test so obviously I'm not pressing it [11:23:28 CEST] <BtbN> If a process is killed by a signal, the exit code will be 128 + signal number [11:23:45 CEST] <thardin> yes, I found the relevant documentation [11:24:08 CEST] <BtbN> so 130 would be signal 2, SIGINT [11:25:53 CEST] <thardin> I've not quite been able to reproduce it for some reason [11:28:41 CEST] <thardin> afl was claiming it had found a bunch of "crashes", but they turned out to most likely be AVERROR(EINVAL) [11:37:29 CEST] <thardin> which somehow resulted in 130 [14:40:39 CEST] <atomnuker> is there something I should know about vgatherdps before using it in some asm? [14:42:19 CEST] <kierank> atomnuker: it's not simd iirc [14:42:26 CEST] <kierank> afaik it just does 8 loads [14:45:32 CEST] <atomnuker> disappointing [14:50:39 CEST] <kierank> atomnuker: it's planning for the future [14:50:46 CEST] <kierank> so future cpus might make it true simd [14:50:58 CEST] <kierank> so might have a benefit even now [14:52:35 CEST] <J_Darnley> atomnuker: It zeros out the mask register you you need to load it every time. [15:23:08 CEST] <BBB> michaelni: do you still understand the big picture of the msa thing? [15:23:17 CEST] <BBB> michaelni: I feel like Im totally losing sight of it [15:28:34 CEST] <michaelni> BBB, my understanding is mainly based on the patches submited by the mips developers. [15:34:20 CEST] <michaelni> BBB, IIUC MIPS can be big and little endian and our implementation of MSA optimizations works only on little endian. I dont know if thats all code or how trivial it is to make it work on bth endiannesses. And i might be totally wrong [15:34:43 CEST] <BBB> super confusing [15:34:46 CEST] <BBB> :D [15:37:19 CEST] <nevcairiel> if msa doesnt work on BE, it should just be turned off in configure though and not get an additional preproc check everywhere [15:40:27 CEST] <BBB> that was my initial thought also [15:40:32 CEST] <BBB> and the first patch did that [15:40:39 CEST] <BBB> so I dont know/undrstand why that was discarded [15:41:36 CEST] <BBB> shivraj should also use a better email client ;) [16:19:35 CEST] <cone-009> ffmpeg 03James Almer 07master:000fb61a71c6: avcodec/hevcdec: export cropping information instead of handling it internally [16:19:36 CEST] <cone-009> ffmpeg 03James Almer 07master:6505e8cfd02b: avcodec/h264dec: be more explicit in handling container cropping [16:19:37 CEST] <cone-009> ffmpeg 03James Almer 07master:07596e45c5a0: avcodec/h264dec: export cropping information instead of handling it internally [16:19:38 CEST] <cone-009> ffmpeg 03James Almer 07master:a9a6d51ca447: avcodec/theora: export cropping information instead of handling it internally [16:22:57 CEST] <cone-009> ffmpeg 03James Almer 07master:5213c6d175ba: doc/libav-merge: remove lines about AVFrame crop fields [16:23:03 CEST] <jamrial> ubitux: ^ another one down :D [16:28:58 CEST] <BBB> noooooooooooooooo [16:29:05 CEST] <BBB> a vp8 test failed with a tsan warning [16:29:10 CEST] <BBB> THAT IS NOT ALLOWED! [16:31:43 CEST] <BBB> so I *think* I understand the tsan warning from update_context_from_user now [16:31:47 CEST] <BBB> its a very very tricky one [16:32:07 CEST] <BBB> and likely the only way to truly fix it is to make AVCodecContext.debug atomic [16:32:16 CEST] <BBB> but thats an API change [16:32:17 CEST] <BBB> so... [16:32:20 CEST] <BBB> any opinions? [16:33:18 CEST] <cone-009> ffmpeg 03Vittorio Giovara 07master:6aafe56421de: zscale: Add pixdesc-API compatible color names to filter options [16:33:19 CEST] <cone-009> ffmpeg 03Vittorio Giovara 07master:1f4454230d14: zscale: Add range options aliases to match scale ones [16:36:25 CEST] <thardin> funny, afl turned my webm test file into mpegts [16:37:32 CEST] <thardin> strange that it enables asf, ffm, mov, mpegts, rm and rtsp [16:38:05 CEST] <thardin> configure that is [16:40:00 CEST] <Gramner> atomnuker: gathers are only useful if you're doing the address calculations in SIMD. it's never worth doing with a constant offset register [16:41:35 CEST] <Gramner> it's actually slower (on most cpu:s at least, can't say I've tested it on every µarch) to gather 8 elements than doing 8 separate loads [16:41:45 CEST] <Gramner> which is interesting [16:42:49 CEST] <ubitux> jamrial: yey \o/ [16:45:21 CEST] <ubitux> BBB: so what's up with that debug field? [16:45:37 CEST] <BBB> any thread has lockless read access to it [16:45:44 CEST] <BBB> so that sort of suggests it should be atomic [16:45:58 CEST] <Gramner> load units are one of the main bottlenecks in many cases so having gathers faster than individual loads would require the cpu to have more load units than what's actually exposed to the instruction scheduler which I can't see happening any time soon [16:46:06 CEST] <BBB> it causes the sporadic hevc/h264 fails also [16:46:14 CEST] <BBB> its not related to interlacing/field coding afaics [16:46:38 CEST] <ubitux> and wrapping it into atomics would break api? [16:49:52 CEST] <atomnuker> Gramner: I was planning to use it to load things via a lookup table [16:52:42 CEST] <Gramner> we tried doing that back when adding most avx2 stuff to x264 and came to the conclustion that it was worse than doing individual loads [16:53:54 CEST] <atomnuker> wow [16:54:03 CEST] <BBB> ubitux: I think so, yes [16:54:18 CEST] <Gramner> maybe if you can reuse the lookup table a sizeable amount of times and the function is limited by computational execution units it could be useful [16:54:44 CEST] <atomnuker> how did they manage to make it smaller than 8 loads, isn't it what the microcode resolves to? [16:54:45 CEST] <Gramner> but getting a single cache miss on the lut will definitely make things a lot worse [16:54:47 CEST] <atomnuker> *slower [16:54:52 CEST] <jamrial> that header writing patch for ffmpeg.c by alevinsn that's rotting in the ml should go in, even if with changes to make everyone happy [16:55:30 CEST] <Gramner> the microcode also handles masking [16:55:33 CEST] <BBB> ooooo a new race [16:55:38 CEST] <BBB> is init of av_crc_table not threadsafe? [16:55:55 CEST] <BBB> that should probably be AV_ONCE or so? [16:55:57 CEST] <Gramner> and the mask has to be updated after every element is loaded [16:56:12 CEST] <BBB> Read of size 4 at 0x00000254abbc by thread T4: [16:56:13 CEST] <BBB> #0 av_crc_get_table src/libavutil/crc.c:346 (ffmpeg+0x0000016d1a14) [16:56:17 CEST] <BBB> Previous write of size 4 at 0x00000254abbc by thread T3: [16:56:17 CEST] <BBB> #0 av_crc_init src/libavutil/crc.c:336 (ffmpeg+0x0000016d1926) [16:56:21 CEST] <BBB> Location is global 'av_crc_table' of size 53248 at 0x000002545bc0 (ffmpeg+0x00000254abbc) [16:56:25 CEST] <Gramner> because if you hit a page fault the instruction needs to be restarted in a astate where it's partially completed [16:56:36 CEST] <Gramner> which adds some complexity [16:58:24 CEST] <jamrial> BBB: yeah, wm4 wanted to make it use avonce [16:58:25 CEST] <Gramner> also by using a lut you first need to wait until the lut load completes before you can start loading the actual data which adds latency, although it can somewhat be hidden by out-of-order execution [17:00:07 CEST] <BBB> wm4: ok so I can leave that to you? [17:00:11 CEST] <BBB> jamrial: tnx [17:02:05 CEST] <kierank> thardin: yeah related to rtp i think [17:02:17 CEST] <BBB> I guess it doesnt really fit AVOnce [17:02:20 CEST] <BBB> hm... [17:03:53 CEST] <wm4> yeah, the crc tables are annoying [17:04:19 CEST] <wm4> probably should use a static mutex instead (which are not supported by the win32 pthread wrapper due to XP support) [17:04:34 CEST] <rcombs> hot take: [17:04:36 CEST] <rcombs> fuck XP [17:05:11 CEST] <wm4> dropping XP support over something like this is unlikely yo gain acceptance [17:05:18 CEST] <wm4> so it'd require complicated workarounds/whatever [17:06:41 CEST] <thardin> kierank: I only enabled very few formats, codecs and protocols tho [17:06:50 CEST] <thardin> perhaps matroska pulls rtmp in? [17:06:56 CEST] <thardin> or some other strange thing [17:15:11 CEST] <jamrial> wm4: i thought even nt6+ lacked static mutex init [17:15:31 CEST] <BBB> so uh wm4& any ideas on how to solve this? [17:15:41 CEST] <BBB> why dont we just init it (at runtime) all at once? [17:15:45 CEST] <BBB> is it too slow? [17:16:03 CEST] <kierank> the polynomial is fixed? [17:16:12 CEST] <kierank> wrap it in a function that does pthread_once? or do I misunderstand? [17:16:40 CEST] <wm4> jamrial: the required API (light weight mutexes) exists since Vista [17:16:52 CEST] <wm4> BBB: no idea lol [17:17:02 CEST] <wm4> it could increase memory footprint I guess [17:17:02 CEST] <BBB> its 257 entries [17:17:04 CEST] <BBB> that cant be so bad [17:17:51 CEST] <jamrial> BBB: 257 if CONFIG_SMALL, 1024 otherwise [17:18:03 CEST] <BBB> thats still very small [17:18:12 CEST] <wm4> why not use the CONFIG_HARDCODED_TABLES code [17:19:10 CEST] <wm4> I guess it makes av_crc() slower [17:19:50 CEST] <jamrial> just extend the hardcoded tables to all 1024 elements [17:20:17 CEST] <jamrial> but keep it as 257 for CONFIG_SMALL, of course [18:28:20 CEST] <alevinsn> jamrial: just saw your message about my patch that has been "rotting" in the ML for some time [18:28:35 CEST] <alevinsn> michaelni never responded to my last e-mail on the topic [18:29:01 CEST] <alevinsn> then wm4 said that the long comment indicated that the patch wasn't sustainable (or something like that), which I dispute [18:29:10 CEST] <alevinsn> and that was the last of it [18:29:32 CEST] <alevinsn> I found it sort of tiresome to continually push the patch, so I took a break from it [18:31:42 CEST] <alevinsn> michaelni: do you think you could respond to my last message for this patch, which was a response to your last e-mail? [18:32:49 CEST] <alevinsn> This was the e-mail I sent on 5/12/2017 6:22 PST [18:33:01 CEST] <alevinsn> with subject line: "Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video" [18:33:58 CEST] <jamrial> you sent a new iteration of the patch split in two in separate threads after that [18:34:19 CEST] <wm4> I've said it many times: the existing code was already grossly invalid, and I don't understand why it can't just be fixed properly [18:35:10 CEST] <alevinsn> jamrial: right, but that was a response to the new version of the patch [18:35:19 CEST] <alevinsn> even though it was done in the context of the old e-mail [18:36:06 CEST] <alevinsn> wm4: yes, the existing code is hard to understand and problematic, but doing it the "right" way likely involves restructuring the code [18:36:08 CEST] <alevinsn> in ffmpeg.c [18:36:25 CEST] <alevinsn> and you've admitted yourself that any time you have to work in ffmpeg.c is an extreme pain [18:37:45 CEST] <wm4> that's why I'd rather have someone fix it rather than adding a hack (I'm not saying that it will have to be absolutely fixed, but at least TRY) [18:38:45 CEST] <alevinsn> I don't agree that it is a hack--it makes the code paths more deterministic [18:39:42 CEST] <michaelni> alevinsn, iam fine with any solution that works and that noone objects to, sorry for not replying. i forgot about that mail after i saw it and had the feeling that i misunderstood the old patch/code [18:40:47 CEST] <jamrial> problem is wm4 objected to it [18:44:00 CEST] <jamrial> he wants a complete, thorough restructure when a working if arguably bandaid fix is good enough until someone actually gets to rewrite ffmpeg.c [18:51:08 CEST] <alevinsn> jamrial: well, you "threw down the gauntlet" so to speak in your last e-mail, if no response after two days, maybe that's sufficient to move ahead with it [18:55:55 CEST] <jamrial> no, i will not push a patch he's against unless other devs are in favor [19:00:43 CEST] <alevinsn> jamrial: ok, looks like wm4 left [19:00:51 CEST] <alevinsn> after wm4 wrote the last message [19:01:41 CEST] <alevinsn> I implemented that bug fix when I thought I was going to use ffmpeg.exe directly in my project [19:01:56 CEST] <alevinsn> but now, I'm using the shared libraries, so it doesn't actually impact me anymore [19:11:49 CEST] <JEEB> that's a usual thing [19:12:05 CEST] <JEEB> ffmpeg.c gets you surprisingly far and then you stumble upon some ancient horror [19:17:58 CEST] <alevinsn> "ancient horror"--that almost puts it pleasantly :-) [20:35:08 CEST] <michaelni> JEEB, what code do you speak of ? i think this is relativly recent code [20:35:44 CEST] <JEEB> just general [20:36:03 CEST] <JEEB> because it seems like a general occurrence :) ffmpeg.c works until you hit some part of code [20:36:08 CEST] <JEEB> for me it was the VSYNC stuff [20:36:46 CEST] <michaelni> thats surely true that things work unti you hit some code ;) [20:37:15 CEST] <JEEB> yup [21:14:38 CEST] <AaronL> michaelni: from your e-mail response to the reap_filters patch [21:14:49 CEST] <AaronL> what is that command-line set supposed to do? [21:15:14 CEST] <AaronL> I mean, what is it doing? [21:15:37 CEST] <michaelni> h264 over rtp over udp test [21:18:24 CEST] <AaronL> I guess when you output to RTP it writes out the SDP information to stdout? [21:18:37 CEST] <AaronL> and that takes too long with the patch> [21:18:38 CEST] <AaronL> ? [21:22:52 CEST] <michaelni> that sounds plausible [21:38:09 CEST] <AaronL> my guess is that the approach the patch takes of waiting a little bit is likely to be incompatible with this test case [21:38:36 CEST] <AaronL> and something else entirely will need to be done to address the interlaced video issue [21:38:57 CEST] <AaronL> although, I don't know how that fits in with jamrial's patch [21:41:16 CEST] <jamrial> my patch removes the delayed header writing code in libavformat/mux.c as it's no longer needed [21:41:21 CEST] <jamrial> with it but without your patch applied beforehand, the interlaced flag is not propagated to the output container in one fate test [21:44:43 CEST] <AaronL> so, the delayed header writing code is technically no longer needed, but it was still being used, and eliminating it does change the behavior slightly? [21:46:31 CEST] <alevinsn> by behavior, I mean the sequencing of actions [21:46:37 CEST] <jamrial> apparently [21:47:56 CEST] <alevinsn> regarding the regression that michaelni reported, however, I haven't looked into it yet, but my guess is the reap_filters() patch is incompatible with this example [21:48:17 CEST] <alevinsn> because while it makes things more deterministic with respect to header writing, it does take longer to write the header in some cases [21:48:21 CEST] <alevinsn> than it used to do [21:48:27 CEST] <alevinsn> by design [21:49:01 CEST] <alevinsn> I've pointed out that the best solution would be to parse the input header and not wait for the first video frame [21:49:19 CEST] <alevinsn> use information from the input header instead of the first video frame in setting the interlaced video setting [21:49:31 CEST] <alevinsn> but, I haven't looked into how or where to do that [21:49:36 CEST] <jamrial> the delayed code in libavformat is run only with muxers that auto inject bitstream filters (AVFormatOutput.check_bitstream() is not NULL). in those, the header is not written until the first packet shows up [21:50:33 CEST] <alevinsn> first output or first input packet? [21:50:46 CEST] <jamrial> first output packet, i think [21:51:09 CEST] <jamrial> by removing this code in mux.c and writing the header for every muxer, one fate test that needs avcodecparameters.field_order during avformatout.write_header() doesn't get it anymore [21:51:29 CEST] <alevinsn> in all these cases, ffmpeg already knows that the input video is interlaced or progressive by examining the input header [21:51:30 CEST] <jamrial> your patch makes do_video_out() in ffmpeg.c set said field before write_header() is called [21:51:48 CEST] <alevinsn> yes, but it delays the call to write_header() compared to when it used to be called [21:52:00 CEST] <alevinsn> and that is presumably breaking the RTP test case from michaelni [21:53:15 CEST] <alevinsn> but, it doesn't propagate the input header interlaced info to the output header--this information is only propagated via the call to do_video_out(), which is silly [21:53:32 CEST] <alevinsn> since even if interlaced bit can in theory change from frame to frame [21:53:43 CEST] <alevinsn> well, type of interlacing vs. progressive [21:53:54 CEST] <alevinsn> the header should only be written once [22:09:54 CEST] <jamrial> alevinsn: i just sent the patch, in case you want to test it [22:25:35 CEST] <alevinsn> k [22:26:04 CEST] <alevinsn> not everyone may realize that this patch is "contingent" on the reap_filters() patch with respect to passing FATE [22:27:49 CEST] <jamrial> i explained as much in it. anyone reviewing it will see the comment [22:38:18 CEST] <alevinsn> I wonder if the following is the "right" way to go about this [22:38:48 CEST] <alevinsn> copy the field_order setting from the associated input stream's codecpar as soon as the output stream is initialized [22:40:09 CEST] <alevinsn> although, I'm not sure how to determine the "associated" input stream [22:42:13 CEST] <alevinsn> source_index is used to indicate that [22:42:25 CEST] <alevinsn> the index for the associated source stream [22:46:30 CEST] <alevinsn> here's a solution that just might work [22:46:49 CEST] <alevinsn> modify new_output_stream() as follows: [22:46:54 CEST] <alevinsn> in ffmpeg_opt.c [22:47:13 CEST] <alevinsn> at the bottom of the function [22:47:23 CEST] <alevinsn> look for the code that sets ost->sync_ist [22:47:56 CEST] <alevinsn> and add the line: [22:49:02 CEST] <alevinsn> ost->st->codecpar->field_order = [22:49:04 CEST] <alevinsn> hmm [22:50:29 CEST] <alevinsn> ost->st->codecpar->field_order = ost->sync_ist->st->codecpar->field_order; [22:50:34 CEST] <alevinsn> I think that might do it [22:52:45 CEST] <alevinsn> could potentially just do for AVMEDIA_TYPE_VIDEO, but I don't think it matters [22:53:39 CEST] <alevinsn> if you feel so inclined to try that with your patch :-) [23:17:44 CEST] <alevinsn> that might be wrong [23:18:06 CEST] <alevinsn> options propagation may have already occurred by then? [23:18:22 CEST] <jkqxz> alevinsn: There is no associated input stream with meaningful information, since everything can be changed by filters. You really do have to get a frame all the way to the output to know the parameters. [23:18:42 CEST] <alevinsn> well, that's for a default value [23:19:02 CEST] <alevinsn> it could be changed later [23:19:17 CEST] <alevinsn> that would at least get things correct in most cases [23:19:23 CEST] <nevcairiel> no, it can't, if the headers are already written [23:19:39 CEST] <alevinsn> the headers haven't been written by that point yet [23:19:50 CEST] <nevcairiel> then you dont need a hack =p [23:19:53 CEST] <alevinsn> if it is calling new_output_stream(), then the headers haven't been written [23:19:55 CEST] <alevinsn> yet [23:20:09 CEST] <alevinsn> I was suggesting to modify new_output_stream() instead of the patch I submitted [23:20:28 CEST] <alevinsn> which I think would address the RTP test case that michaelni reported had stopped working [23:22:11 CEST] <alevinsn> jkqxz: I mean, in new_video_stream() [23:23:06 CEST] <alevinsn> hmm [23:23:07 CEST] <nevcairiel> the entire point of the recent changes was to not copy random values from the input stream, but take the data from a decoded and filtered frame, because only that is accurate - if that doesn't work, then it should be fixed properly, and not pile hacks on top [23:24:36 CEST] <alevinsn> well, that wasn't working properly with respect to the order in which headers are written and when the first filtered frame is processed [23:24:53 CEST] <alevinsn> but, when I addressed that, by making it more likely that the first filtered frame would be processed before headers are written [23:25:16 CEST] <alevinsn> that appears to have caused things to slow down such that it breaks the RTP test case that michaelni submitted [23:25:48 CEST] <alevinsn> that is, it is taking longer to write the headers now in this case than what happened previously [23:25:53 CEST] <nevcairiel> thats mostly because your patch is also just a hack that shuffles stuff around in such a way that works in more cases, without really figuring out where the dataflow is stuck for this situation to even happen [23:26:49 CEST] <alevinsn> based on the fact that the issue didn't occur when H.264 and AAC were used, but does occur when H.264 and Opus are used [23:27:09 CEST] <alevinsn> that is, in the H.264/AAC case, AAC gets started up _after_ H.24 [23:27:11 CEST] <alevinsn> H.264 [23:27:21 CEST] <alevinsn> the output stream for H.264 is created before the AAC output stream [23:27:29 CEST] <alevinsn> but vice versa for H.264/Opus [23:27:48 CEST] <alevinsn> then I would guess there are timing differences depending on the codec used [23:28:39 CEST] <rcombs> >ost->st->codecpar->field_order = ost->sync_ist->st->codecpar->field_order; [23:28:47 CEST] Action: rcombs adds filters [23:31:02 CEST] <alevinsn> nevcairiel: I think if it is an absolute requirement that the first filtered frames be received, for all output streams, prior to writing the header (my patch doesn't even do that) [23:31:21 CEST] <alevinsn> then a bunch of FATE test cases, and likely other tests, will need to change [00:00:00 CEST] --- Sat May 27 2017

1 0

ffmpeg.log.20170526
by burek 27 May '17

27 May '17

[01:55:57 CEST] <iive> is it bug if ./configure --disable-programs --enable-ffmpeg ; keep ffmpeg disabled? [02:17:26 CEST] <iive> wrong alarm... something else disables them [02:17:30 CEST] <iive> it [03:31:00 CEST] <CoJaBo> huh.. libx264 is encoding 10× slower than libvp9 at slowest settings.. is that supposed to happen lol [03:31:51 CEST] <furq> no [03:32:00 CEST] <furq> unless "slowest settings" is placebo in which case probably [03:32:55 CEST] <CoJaBo> o, veryslow, in this case [03:33:58 CEST] <CoJaBo> I tried placebo before. It spites me by actually making the file larger than veryslow [03:44:26 CEST] <CoJaBo> Another rip in the universe, the higher the resolution, the smaller the filesize [03:44:43 CEST] <furq> placebo being bigger than veryslow makes sense [03:44:49 CEST] <furq> the resolution thing very much does not [03:45:24 CEST] <CoJaBo> Trying to double-check I have the latest ffmpeg lol.. [03:45:59 CEST] <ylzkhan> Hello, I'm trying to remove comment metadata of multiple flac files and outputing them with the exact filename on ssh. If someone could help me out. [03:46:16 CEST] <CoJaBo> I'm thinking it's setting constant bitrate instead of constant quality; or maybe I just typoed the commandline <_< [03:46:47 CEST] <furq> CoJaBo: pastebin the command [03:47:09 CEST] <furq> ylzkhan: you might be better off using metaflac [03:47:19 CEST] <furq> ffmpeg isn't great at metadata editing [03:47:42 CEST] <CoJaBo> ..actually, I've apperently not specified either setting. does vp9 default to CBR? That'd explain it <_< [03:47:48 CEST] <furq> yes [03:47:51 CEST] <furq> well no [03:47:53 CEST] <furq> it defaults to abr [03:47:57 CEST] <furq> at some stupid bitrate like 200kbps [03:48:32 CEST] <ylzkhan> furq: i'll try out thanks i heard that overwriting files with different metadata is not possible with ffmpeg you need to create new files, is it true? [03:48:37 CEST] <furq> yes [03:48:51 CEST] <furq> although that's probably what most things do [03:49:03 CEST] <furq> just those automate the atomic replace for you [03:49:58 CEST] <CoJaBo> Ok, so I just suck at reading the debug output then [03:53:28 CEST] <CoJaBo> ..wow, and who in their right mind encodes a file in 1150×640px :/ [04:38:06 CEST] <kepstin> I know, right? It should be 1152x640 so the width is a nice multiple of 8 and 16. [04:42:46 CEST] <furq> how would you even get 1150 there [04:42:52 CEST] <furq> unless the source was 1920*1068 [04:42:59 CEST] <furq> and what monster would do that [05:36:36 CEST] <thebombzen> furq: someone who probably had a widescreen-like video that autocropped [05:36:48 CEST] <thebombzen> or cropped black bars off the top and bottom I should say [06:32:16 CEST] <james999> oh hey it's thebombzen [06:32:36 CEST] <thebombzen> It is, in fact, me [06:33:06 CEST] <james999> I'm contemplating trying out ffmpeg on my rpi 3 [06:33:17 CEST] <james999> just to see how fast it encodes. any standard video files i can use? [07:23:09 CEST] <thebombzen> james999: you can try -f lavfi -i testsrc2 [07:23:24 CEST] <thebombzen> you could also try big buck bunny, I hear people like using that as a test [07:27:24 CEST] <thebombzen> depends on what you're trying to encode you could also use jellyfish [07:28:37 CEST] <thebombzen> you know, these: http://jell.yfish.us/ [07:28:41 CEST] <thebombzen> (warning: they're really big) [08:40:29 CEST] <james999> that URL... lol thanks [08:42:08 CEST] <thebombzen> james999: also try http://bbb3d.renderfarming.net/explore.html [08:46:19 CEST] <james999> ah ok blender [08:46:31 CEST] <james999> that explains all the stereoscopic 3d and anaglyph whatever stuff [10:15:30 CEST] <cosven> I have a problem about the meaning of `tbr`, which is extracted from ffmpeg. [10:15:39 CEST] <cosven> I found a explaination from stackoverflow: tbr is guessed from the video stream and is the value users want to see when they look for the video frame rate [10:16:12 CEST] <cosven> but in fact, the fps of this video is 30. [10:16:39 CEST] <cosven> the `tbr` that ffmpeg show is 120 [10:16:57 CEST] <cosven> here is the original info ffmpeg prints: Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 640x360, 796 kb/s, SAR 1:1 DAR 16:9, 30 fps, 120 tbr, 90k tbn, 180k tbc (default) [10:19:17 CEST] <Mavrik> H.264 isn't a constant frame rate codec anyway :) [10:21:05 CEST] <cosven> the `tbr` here means maximum frame rate? fps means average frame rate? [10:22:43 CEST] <thebombzen> cosven: it means the video is "variable framerate" [10:23:06 CEST] <thebombzen> where frames have "timestamps" rather than assuming a constant framerate [10:23:07 CEST] <Mavrik> cosven, I'd have to check the source on what exactly it reads [10:23:18 CEST] <Mavrik> cosven, was that recorded on a small camera / mobile device? [10:23:37 CEST] <thebombzen> what TBR is, it's the smallest framerate that's needed to perfectly recontruct the input variable framerate [10:24:05 CEST] <thebombzen> for example, if the input video has some 24 fps and some 30 fps content, you need 120 fps to do those accurately (it's the LCM of 24 and 30 in this case) [10:32:00 CEST] <cosven> I have upload the video to dropbox, here is the video link: https://www.dropbox.com/s/4ypkoq4dshqyv0y/tmp.unknown?dl=0 [10:33:37 CEST] <cosven> thebombzen: thanks for your explaination ~ [11:06:24 CEST] <mindw0rk> Hey guys, I'm trying to work with hls streams here. Everything seems to go smoothly, but for some reason AVCodecContext video dimensions are both 0. [11:10:51 CEST] <BtbN> avcodec is not the one who deals with hls, that's avformat [11:41:05 CEST] <SolidusAbi> HI, Im trying to convert a .mov to wmv but ffmpeg throws a error. My command is "ffmpeg -i seg0.mov -b:v 4M -s 1920x1080 -vcodec msmpeg4 -acodec wmav2 seg0.wmv" [11:41:26 CEST] <SolidusAbi> The error says: Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [11:41:44 CEST] <SolidusAbi> Can someone explain me what it is happening¿? [11:41:58 CEST] <JEEB> the actual error is usually before that [11:44:57 CEST] <SolidusAbi> ffmpeg, just before the error, throws "[wmav2 @ 0x3323d20] too many channels: got 4, need 2 or fewer" [11:47:38 CEST] <SolidusAbi> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'seg0.mov': [11:47:38 CEST] <SolidusAbi> Metadata: [11:47:38 CEST] <SolidusAbi> major_brand : qt [11:47:38 CEST] <SolidusAbi> minor_version : 512 [11:47:38 CEST] <SolidusAbi> compatible_brands: qt [11:47:39 CEST] <SolidusAbi> encoder : Lavf57.65.100 [11:47:39 CEST] <SolidusAbi> make : Atomos [11:47:40 CEST] <SolidusAbi> make-eng : Atomos [11:47:40 CEST] <SolidusAbi> Duration: 00:20:00.02, start: 0.000000, bitrate: 85599 kb/s [11:47:40 CEST] <SolidusAbi> Stream #0:0(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 4.0, s32 (24 bit), 4608 kb/s (default) [11:47:41 CEST] <SolidusAbi> Metadata: [11:47:41 CEST] <SolidusAbi> handler_name : DataHandler [12:07:33 CEST] <SolidusAbi> If someone give me a example in order to convert to wmv, i will be grateful [12:07:57 CEST] <c_14> add -ac 2? [12:14:48 CEST] <SolidusAbi> It works... [12:14:56 CEST] <SolidusAbi> but.. i dont know why [12:14:56 CEST] <SolidusAbi> xD [12:15:05 CEST] <SolidusAbi> can you explain, c_14 [12:15:26 CEST] <c_14> wmav2 only supports 2 or less channels, your input is 4.0 [12:15:34 CEST] <c_14> just downmix to stereo [12:16:22 CEST] <SolidusAbi> oooh, how can i check how many channels has a stream? [12:16:37 CEST] <c_14> >Stream #0:0(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 4.0, s32 (24 bit), 4608 kb/s (default) [12:16:39 CEST] <c_14> >4.0 [12:16:55 CEST] <SolidusAbi> aaah! [12:17:05 CEST] <SolidusAbi> thanks, you has been helpful [12:17:12 CEST] <SolidusAbi> have been* [12:17:16 CEST] <SolidusAbi> xD [12:35:14 CEST] <nuvo> hello everybody [12:51:23 CEST] <nuvo> is there anybody here that is be able to develope a script for ffmpeg/osx to split 1 hours long movie into few clips? please send an email to: nuvolablux(a)gmail.com This is a payed project. [12:52:54 CEST] <BtbN> That can be done with a single ffmpeg commandline, if you just want to split it into even segments. There is a muxer that does just that [12:54:59 CEST] <nuvo> it is a bit more complicated than this: I will provide a txt page with time codes to split and names... [12:55:43 CEST] <SolidusAbi> ffmpeg -i [movie] -f segment --segment_time_delta 1200 -f segment [output_dir]\test%03d [12:55:51 CEST] <SolidusAbi> nuvo, this must to work [12:56:40 CEST] <SolidusAbi> it command will split the movie per 20 minutos ans save it in test0, test1,... [12:56:49 CEST] <SolidusAbi> Is so easy... [12:56:58 CEST] <nuvo> The script will have to work on mac osx I recommend using ffmpeg as a video engine Input File: Apple prores422hq (or alternatively a sequence of consecutive numbered images) MOV files / text file containing time code and file names The script must be accurate to the frame, the time code in the EDL file is understood: HH: MM: SS: frames (1 second contains 25 frames - from 00 to 24 -) while ffmpeg uses different syntax: FFMPEG Time unit s [12:57:22 CEST] <nuvo> ote that you can use two different time unit formats: sexagesimal (HOURS: MM: SS.MICROSECONDS, as in 01: 23: 45.678), or in seconds. If a fraction is used, such as 02: 30.05, this is interpreted as "5 100ths of a second", not as frame 5. For example, 02: 30.5 would be 2 minutes, 30 seconds and half a second Would be the same as using 150.5 in seconds. The ffmpeg command to use is the copy, which provides a crop and not the file regenerati [12:57:30 CEST] <nuvo> The script splits into two parts SCRIPT A: [12:57:39 CEST] <nuvo> Starting from a master file the script must be able to divide it into many files according to the time codes and names in the edl file. [12:57:47 CEST] <nuvo> So, the goal would be to generate these files from an edl (see below) and the master video file: Look at the text of the file edl (see below) the script will have to: Generate video file called "Video Source.mov" from video master from time code 00: 00: 00: 00 to 00: 00: 11: 14 [12:57:54 CEST] <nuvo> Generate the second video file called "Video Source Copy 2.mov" from the video master file from 00: 00: 11: 14 to 00: 00: 23: 03 ...and so on... [12:58:03 CEST] <nuvo> I have more than 1000 files to split and name, hence the need to automate this process. [12:58:26 CEST] <nuvo> this is the edl file with time codes and names: [12:58:33 CEST] <nuvo> TITLE: Video Source Copy FCM: NON-DROP FRAME 000001 001 V 00: 00: 00: 00 00: 00: 11: 14 00: 00: 00: 00 00: 00: 11: 14 * FROM CLIP NAME: Video Source.mov 000002 001 V C 00: 00: 00: 00 00: 00: 11: 14 00: 00: 11: 14 00: 00: 23: 03 * FROM CLIP NAME: Video Source Copy 2.mov 000003 001 V 00: 00: 00: 00 00: 00: 11: 14 00: 00: 23: 03 00: 00: 34: 17 * FROM CLIP NAME: Video Source copy 3.mov 000004 001 V C 00: 00: 00: 00 00: 00: 11: 14 00: 00: [12:58:42 CEST] <nuvo> 000005 001 V C 00: 00: 00: 00 00: 00: 11: 14 00: 00: 46: 06 00: 00: 57: 20 * FROM CLIP NAME: Video Source Copy 5.mov 000006 001 V C 00: 00: 00: 00 00: 00: 11: 14 00: 00: 57: 20 00: 01: 09: 09 * FROM CLIP NAME: Video Source Copy 6.mov 000007 001 V 00: 00: 00: 00 00: 00: 11: 14 00: 01: 09: 09 00: 01: 20: 23 * FROM CLIP NAME: Video Source Copy 7.mov 000008 001 V 00: 00: 00: 00 00: 00: 11: 14 00: 01: 20: 23 00: 01: 32: 12 * FROM CLIP NAME: [12:58:49 CEST] <nuvo> ecc [13:03:16 CEST] <SolidusAbi> Im a noob with ffmpeg, i enter here because a i need a help, but i think that you must to work with python in order to parse your "data files" and using ffmpeg commands later [13:05:33 CEST] <SolidusAbi> python is very good for scripting [13:05:39 CEST] <nuvo> I'm not a developer, I'm searching for a developer, I think here someone could be interested to a payed project [13:06:53 CEST] <SolidusAbi> oooh, ok. I hope someone can help you [13:08:22 CEST] <nuvo> is there a way to find someone interested on this project? [13:10:35 CEST] <SolidusAbi> i dont know, maybe here someone answer you [13:11:13 CEST] <nuvo> is there another place where to find ffmpeg developers? [13:12:56 CEST] <SolidusAbi> maybe you can looking for in mail list of ffmpeg but... i dont sure [13:14:16 CEST] <nuvo> ok [13:14:17 CEST] <nuvo> thanks [14:13:19 CEST] <marquisor> furq: ping [14:21:11 CEST] <marquisor> JEEB: ping [14:22:43 CEST] <marquisor> i need help with ssh tunnel for ffmpeg streaming :< i'm not sure if i have to make temporary file? with mkfifo? 512M size maybe. i could integrate a mp4 video with html5 on my website though, only need the stream now for it. [14:30:08 CEST] <BtbN> you can't stream mp4 [14:30:44 CEST] <BtbN> need something like hls or dash for that, which can't be sent to a pipe, as it's multiple files [14:31:09 CEST] <marquisor> any other compatible with simple html5 embedded video? [14:31:17 CEST] <BtbN> no [14:31:19 CEST] <marquisor> damn [14:31:37 CEST] <BtbN> Even HLS is technically not compatible, but there are JavaScript libs to convert it on the fly [14:32:28 CEST] <marquisor> i have to keep H264 [14:32:48 CEST] <BtbN> That's a codec, not a container. [14:32:50 CEST] <marquisor> yes [14:33:07 CEST] <marquisor> but i can't spare cpu power to reencode video [14:33:10 CEST] <marquisor> just saying [14:34:39 CEST] <marquisor> that conversion on the fly is just for the bitstream then? [14:35:55 CEST] <marquisor> well i might screw it, no embedded video then. but at least want to provide a link for mplayer/vlc at least. is that possible with ssh tunnel? [14:36:17 CEST] <BtbN> Why would you ever use a ssh tunnel in the first place? [14:36:23 CEST] <BtbN> Just setup an nginx-rtmp [14:36:26 CEST] <marquisor> because nginx-rtmp not working [14:36:48 CEST] <BtbN> works for me [14:36:49 CEST] <marquisor> yes i did, lots of framedrops and disconnects [14:37:19 CEST] <BtbN> maybe your connection is too slow for what you are trying to stream [14:37:34 CEST] <marquisor> if clients connect directly to the source it's working fine [14:37:47 CEST] <marquisor> max bitrate is 15 mbit, i have an upstream of 50 mbit [14:38:12 CEST] <marquisor> but i have to use a relay, because i want 5-6 people to watch it [14:38:33 CEST] <BtbN> that's exactly what nginx-rtmp is designed for [14:38:37 CEST] <marquisor> yeah [14:38:52 CEST] <marquisor> can't imagine the rootserver can't handle incoming 15 mbit max. [14:40:48 CEST] <marquisor> https://www.netcup.de/vserver/ [14:41:34 CEST] <marquisor> looking for a CLI speedtest now [14:42:20 CEST] <marquisor> BtbN: do i have to setup a buffer in nginx-rtmp config or in my ffmpeg which i send to it? [14:42:33 CEST] <BtbN> the defaults are fine [14:42:51 CEST] <marquisor> k [14:47:01 CEST] <marquisor> http://retrohd.com/fb/jdSc4o/ [14:47:07 CEST] <marquisor> ^ speedtest [14:50:00 CEST] <marquisor> should be sufficient [16:19:57 CEST] <Guest30290> Hello, I am using FFMPEG libs in an Unity project, it segfault on Android when avcodec_decode_video2 calls av_log_default_callback. I asked the question @ https://stackoverflow.com/questions/44203463/ffmpeg-libraries-segfault-on-a… . If you have some infos please let me know (here or on stackoverflow) thanks ! [16:21:09 CEST] <atomnuker> Guest30290: in your custom callback try copying the format string to some tmp buffer and then using that tmp buffer [16:21:59 CEST] <BtbN> are you sure "ref AVCodecContext *ctx" is not a "AVCodecContext **ctx"? [16:24:00 CEST] <Guest30290> typo error its " ref AVCodecContext ctx" [16:25:44 CEST] <Guest30290> @atomnuker I don't get what custom callback you are talking about [16:26:53 CEST] <atomnuker> Guest30290: don't you have a custom logging callback installed? [16:27:15 CEST] <Guest30290> not that I know, I just Dllimport what I need and use it [16:28:41 CEST] <Guest30290> Is it possible to disable the logging ? [16:30:40 CEST] <atomnuker> no, you probably just set it to null somewhere [16:35:40 CEST] <Guest30290> I didnt changed anything about it, I will try to make my own callback and just discard anything and see if it fixes the segfault [17:16:55 CEST] <Ethereco> Hello, with the 2 options (--disable-swresample --disable-avfilter) i can't build ffmpeg - it is no longer under "Programs:" https://pastebin.com/W9JaB7Md [17:17:29 CEST] <JEEB> possibly because ffmpeg.c utilizes both of those? [17:17:34 CEST] <furq> Ethereco: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3222 [17:18:42 CEST] <JEEB> if you don't want to utilize them you will have to create your own simpler app that doesn't utilize them [17:20:39 CEST] <Ethereco> oh - ok is there a list which options ffmpeg utilize? coudn't find any info about that [17:20:49 CEST] <furq> it's the thing i just linked [17:21:54 CEST] <DHE> you can disable a number of filters, but you can't disable the entire filtering library itself. [17:22:09 CEST] <Ethereco> i think to code my own program i don't have enough skills - ffmpeg is a perfect tool [17:22:29 CEST] <JEEB> lol [17:22:36 CEST] <JEEB> please no [17:22:44 CEST] <JEEB> > ffmpeg.c > perfect [17:22:51 CEST] <JEEB> you can do surprisingly many things with ffmpeg.c [17:22:56 CEST] <JEEB> and it might even work [17:22:58 CEST] <DHE> if you only want a couple of filters, you can do this: ./configure --disable-filters --enable-filter="volume,scale,yadif" [17:23:20 CEST] <DHE> (you should see how horrific my configure line is) [17:23:57 CEST] <Ethereco> i have tried to disable filter but there where the same error. i'll test it again [17:24:15 CEST] <JEEB> but at some point something in ffmpeg.c or so will drive you made (there's so many workarounds for weird things that aren't possibly necessary any more) [17:25:06 CEST] <james999> JEEB: there's a management story about manure on horse saddles that refers to that [17:25:17 CEST] <james999> the idea of continuing to do something that was long ago rendered unnecessary [17:25:23 CEST] <DHE> can confirm, ffmpeg is good but not perfect. I have my own app to work around all kinds of issues [17:28:10 CEST] <JEEB> james999: the best part is where you can't even easily test it after looking at the git log [17:28:21 CEST] <JEEB> (no clear file based sample etc) [17:29:36 CEST] <Ethereco> configure with --disable-filters: https://pastebin.com/vSNtb93W [17:29:48 CEST] <james999> i feel like there should be some software principle at work here [17:29:50 CEST] <furq> sounds like it's time for a fresh new start for ffmpeg [17:29:50 CEST] <JEEB> and then there's the balance between supporting broken input and keeping the code clear [17:29:55 CEST] <furq> perhaps with a new name [17:30:06 CEST] <Ethereco> this is the minimum set of filters right? [17:30:07 CEST] <furq> one that reflects that it's not just for mpeg, it's a general purpose a/v conversion tool [17:30:07 CEST] <JEEB> furq: yea, and not trying to do everything with a single binary [17:30:10 CEST] <james999> like, "specially note all the small things you have to fix cause of some stupid moron somewhere" + example file [17:30:37 CEST] <james999> furq: libav sounds like a good all-purpose name to me! [17:30:45 CEST] <furq> the punchline was avconv [17:30:47 CEST] <furq> go and sit in the corner [17:30:58 CEST] <james999> T_T [17:31:10 CEST] <DHE> well it says it'll build you a copy of ffmpeg. but all it can do is remux mov into mkv and ogg.... [17:31:23 CEST] <DHE> I feel like this is an incredibly narrow use case, but it should compile pretty fast [17:32:10 CEST] <furq> JEEB: tbf it would probably be difficult to separate ffmpeg's jobs into multiple binaries [17:32:21 CEST] <furq> and it would almost certainly make the ui even more arcane [17:32:38 CEST] <Ethereco> yes, it will be a little bit larger but i was shocked of the 60MB full binary size - i wan't create a smaller one - this binary is about 1MB or 380kb upx packed [17:33:06 CEST] <DHE> Ethereco: you sure you just looked at the unstripped version? a stripped full ffmpeg build for me is about 21 megabytes. [17:34:27 CEST] <DHE> (linux) [17:35:09 CEST] <furq> yeah 60MB seems way too big [17:35:14 CEST] <Ethereco> a ffmpeg-windows-build-helpers windows binary with non free is about 62MB :-( upx smaller but execute one command takes about 3 seconds for unpacking the large exe [17:35:40 CEST] <furq> that's either unstripped or it has every external lib it's possible to have [17:35:55 CEST] <DHE> well, can't comment on windows builds. 60 MB on linux with debug symbols is about right... [17:36:09 CEST] <furq> i've got a windows build with quite a few libs which is 31MB [17:36:12 CEST] <furq> and nothing disabled [17:36:13 CEST] <DHE> or with my configure command, about half that. so ~10 megabytes after a strip. [17:36:23 CEST] <DHE> wow... [17:37:09 CEST] <DHE> that's fully loaded? lame, x264, x265, vpx, and all that? [17:37:16 CEST] <Ethereco> yes, i have an old windows ffmpeg from 2013 this file was about 10mb [17:37:42 CEST] <Ethereco> but all programs are very old and has less features [17:37:43 CEST] <furq> DHE: http://sprunge.us/GNJU [17:37:52 CEST] <furq> 32070656 [17:38:13 CEST] <Ethereco> i hope i can build a new one with all needed modern features under 10mb [17:38:32 CEST] <furq> without external libs it should be about 15-20MB iirc [17:38:37 CEST] <DHE> is LTO worth it? I thought it broke inline asm [17:38:42 CEST] <furq> so if you disable a bunch of decoders/encoders you don't need, that should be fine [17:38:47 CEST] <furq> DHE: i've not really benchmarked it [17:38:50 CEST] <furq> it seemed faster with x264 [17:38:58 CEST] <furq> but like a couple of percent at most [17:39:17 CEST] <furq> i left it on because it didn't seem to break anything [18:03:13 CEST] <anchi> guys I have super strange proble [18:03:16 CEST] <anchi> m [18:03:44 CEST] <crziter> Does FFMPG support decode video frame into OpenGL texture? [18:06:32 CEST] <atomnuker> crziter: see the get_buffer2() callback in avcodeccontext [18:27:14 CEST] <drathir> hi all... [18:28:04 CEST] Action: drathir wonder if there is any known issues with rtsp stream playing last times [18:30:16 CEST] <crziter> atomnuker: thank you for your suggestion, let me give it a try [21:32:33 CEST] <MacMog> hi, I'm trying to understand how ffmpeg calculates the start time for an MPEG-2 file (video & audio) [21:32:46 CEST] <MacMog> for example, when I run ffprobe, I get this output: [21:32:46 CEST] <MacMog> Input #0, mpeg, from 'file.mpg': [21:32:47 CEST] <MacMog> Duration: 00:00:11.06, start: 579.376000, bitrate: 10704 kb/s [21:33:18 CEST] <MacMog> when I calculate the value by hand, or open the same file in Wireshark, I get different values from the first pack header and PES header [21:33:30 CEST] <marquisor> re [21:33:39 CEST] <marquisor> 6h ISP downtime :< [21:34:37 CEST] <MacMog> first pack header gives me a system clock reference of 578.4, while first video PES header gives PTS = DTS = 579.4 [21:35:07 CEST] <MacMog> if I look at the first audio PES header, I get 579.375655555556, which is so close that it may be just a matter of doing math in the wrong mode (integer vs. floating-point) [21:35:26 CEST] <MacMog> that would imply that ffmpeg takes the minimum value from all the PES headers, but I'm not confident about that [21:35:45 CEST] <MacMog> I see in av_dump_format() the lines that calculate & output seconds (ic->start_time / AV_TIME_BASE) and microseconds (% instead of /), and am working backwards from there [21:35:53 CEST] <MacMog> any information or pointers on where to look would be appreciated [21:53:29 CEST] <aaa3> hi. i noticed ffmpeg.org https doesn't work on debian sid/testing any more because startcom cert has been distrusted [21:53:45 CEST] <aaa3> is this a known issue? [21:54:01 CEST] <aaa3> or should i do something with it, bug report, contact server admin etc? [22:06:25 CEST] <BtbN> the cert should be old enough to still be valid [22:06:30 CEST] <BtbN> it was only distrusted for new certs [22:06:37 CEST] <furq> it fails here as well [22:08:28 CEST] <BtbN> only certs after October 21st 2016 were distrusted [22:08:34 CEST] <aaa3> old enough for browser half-distrust i guess, but debian kicked out startcom proper [22:08:36 CEST] <BtbN> the ffmpeg one is from April [22:10:18 CEST] <aaa3> can be seen here: https://packages.debian.org/sid/ca-certificates [22:10:33 CEST] <aaa3> is in "Changelog" [22:10:50 CEST] <aaa3> or "list of files" [23:37:57 CEST] <ThugAim> hey guys, anybody here work in broadcast? [23:45:09 CEST] <james999> no but I know NATO phonetics sort of and know pirate radio operators [23:51:21 CEST] <rrodriguez> is there a way to use ffmpeg to generate an image of a stream every 5 seconds but also send the stream to ffprobe? I want to also generate some stats about the stream [00:00:00 CEST] --- Sat May 27 2017

1 0