Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2018

1 participants
62 discussions

ffmpeg-devel.log.20181025
by burek 26 Oct '18

26 Oct '18

[00:08:30 CEST] <atomnuker> yeah ok, I'll try to pick that back up this weekend, [00:08:40 CEST] <BBB> ty <3 [00:15:50 CEST] <atomnuker> though I think the opus encoder's EC system was a bigger effort [01:05:29 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/master cuda yadif now in a presentable form :-) [01:07:53 CEST] <nevcairiel> how is the performance? a cpu algorithm may not always translate that well speed wise [01:18:05 CEST] <philipl> 1% of GPU utilisation on my 2080ti. No idea how it scales down, of course. [01:19:02 CEST] <philipl> It's not perfect as there are a couple of conditionals in the algorithm but I think in practice it's simple enough that it doesn't do anything pathological. [01:21:28 CEST] <nevcairiel> gpu usage is not a usable metric [01:22:27 CEST] <nevcairiel> pick a video, compare cuvid decode + internal deint, or cuvid decode + yadif, grab some FPSes =p [01:23:06 CEST] <philipl> fair enough. [01:24:05 CEST] <philipl> I think I may also have done something that gratuitously increased the CPU consumption vs my first implementation. *sigh* [01:24:46 CEST] <cone-973> ffmpeg 03Mark Thompson 07master:f370142ec08b: lavfi/ebur128: Fix mixed declarations and code [01:29:34 CEST] <philipl> nevcairiel: At first glance it looks like it almost halves the fps vs doing nothing. [01:29:50 CEST] <philipl> (after accounting for the fact that there are twice as many frames) [02:14:49 CEST] <cone-973> ffmpeg 03James Almer 07master:6a112349c206: configure: add missing optional SDL2 dependency to OpenGL outdev [10:29:19 CEST] <j-b> Good morning *! [10:30:13 CEST] <durandal_1707> ***moroning day! [11:30:34 CEST] <durandal_1707> j-b: you are very evil, you do not like mpv [11:32:09 CEST] <j-b> if that is all my evilness, I'm not very evil [12:32:52 CEST] <January> michaelni: does last timecode fate test work for you? [12:36:15 CEST] <michaelni> January, you mean the test from 3f2103ec73c96d530b0516869363ad9ea730c909 ? i think but ill recheck if it passes on all easy testable platforms [12:36:54 CEST] <January> michaelni: '[PATCH vFINAL] fate: add api-h264-slice test' on the ml [16:52:27 CEST] <graphitemaster> is there any support for decoding and playing back NSCF files? [17:21:12 CEST] <atomnuker> BBB: "Don't use tile-threaded code path if there's only one tile." [17:21:27 CEST] <BBB> yes? [17:21:30 CEST] <atomnuker> yeah, I was under the impression you could use the tile threaded code in non-tile-encoded images [17:21:37 CEST] <BBB> you could [17:21:42 CEST] <BBB> but someone complained that it wasnt faster [17:22:04 CEST] <BBB> its not a correctness issue, its a speed issue [17:22:09 CEST] <BBB> (or, rather, battery usage) [17:22:12 CEST] <atomnuker> I tested this the other day actually, it wasn't, for non-tiled images [17:22:34 CEST] <BBB> it wasnt = it wasnt faster or it wasnt not faster"? [17:22:35 CEST] <atomnuker> (which 100% of everything is, as usual, like with vp9) [17:22:56 CEST] <atomnuker> it wasn't faster, it was slower, just using all cores for frame threading was faster [17:23:04 CEST] <BBB> right [17:23:10 CEST] <BBB> so the patch makes that issue go away [17:23:22 CEST] <BBB> not much you can do& no tiles, no tile threading :) [17:23:39 CEST] <atomnuker> there was some minor advantage when I used 2 tile threads / 6 frame threads but it was low enough that I discounted that as noise [17:24:28 CEST] <atomnuker> runtime was around 2 seconds to decode 300 frames, so there was plenty of margin for noise [17:25:04 CEST] <BBB> yeah [17:25:09 CEST] <BBB> good speed btw, 150fps :) [17:27:53 CEST] <jamrial> depends on resolution :p [17:32:57 CEST] <atomnuker> mIAfxj7nd9k so 1920x1080, 8 bit [17:36:34 CEST] <atomnuker> BBB: no, checked again, there's a 13% gain (2.2 vs 1.9 sec) when using 8+4 vs 8+1 frame/tile threads [17:37:31 CEST] <atomnuker> if I let it run without limit the CPU use is almost a core higher than with frame threads alone [17:48:37 CEST] <durandal_1707> graphitemaster: is that avi file? [17:50:00 CEST] <graphitemaster> durandal_1707, no, PSF files, as used by game consoles [17:50:55 CEST] <graphitemaster> durandal_1707, basically all the nintendo consoles and playstation used more or less the same audio file format (PSF) with ton of their own extensions [17:52:13 CEST] <graphitemaster> here's one such impl https://github.com/kode54/SSEQPlayer [17:52:25 CEST] <durandal_1707> if it is not streamed, but tracked format - ffmpeg does not play it directly, but maybe there is some other lib [17:52:50 CEST] <durandal_1707> it is probably similar to midi [17:54:32 CEST] <JEEB> graphitemaster: there are some patches for PSMF and the PS3 version (basically ATRAC3+ in MPEG-PS), but unfortunately all the patches that added a parser somehow broke seeking [17:54:37 CEST] <JEEB> and I haven't had the time to fixup it [17:54:55 CEST] <JEEB> this was the latest attempt by misty, IIRC https://github.com/mistydemeo/FFmpeg/tree/mps_support_atrac3 [17:55:33 CEST] <JEEB> the current decoder expects a lot of data to come from extradata, while the format in MPEG-PS unexpectedly has its own header [17:55:48 CEST] <JEEB> (for each ATRAC3+ packet) [17:56:41 CEST] <JEEB> oh, and UMD Video also used another version of it [17:56:47 CEST] <graphitemaster> JEEB, the whole thing is a bit of a mess, on one hand it seems the emulator people have this down but they have it down in ugly af C++ code, most of which is riddled with UB or implementation defined behavior or security vulns, PSF is a bytecode interpreted format and I can hand craft some Nintendo DS audio that will crash the emulator [17:56:54 CEST] <graphitemaster> I'm not happy with this [17:57:29 CEST] <JEEB> ppsspp at least uses a fork of FFmpeg with an earlier version of the parser+patch [17:57:37 CEST] <JEEB> they don't need to seek so it's simpler for them [17:57:54 CEST] <JEEB> (also I don't think they used some other things) [18:22:14 CEST] <graphitemaster> JEEB, hum [18:54:49 CEST] <durandal_1707> ubitux: do you have comments for lut3d patch, if not i will apply it [19:16:18 CEST] <ubitux> durandal_1707: can you just share the header? [19:21:00 CEST] <durandal_1707> ubitux: https://pastebin.com/GhPh9sPd [19:24:55 CEST] <ubitux> yeah well i guess that's fine [19:33:51 CEST] <michaelni> January, sorry for the delay, the vFINAL (with the dependant h264 patch) works on all systems i tried [19:34:30 CEST] <January> No problem, will push tomorrow then [20:14:46 CEST] <durandal_1707> JEEB: SSEQPlayer is player for tracker file [20:14:53 CEST] <JEEB> right [20:14:59 CEST] <JEEB> he just mentioned PSMF [20:15:06 CEST] <JEEB> which I happened to know about :P [23:11:45 CEST] <jamrial> jkqxz: https://pastebin.com/279WcMDP reference frame tracking for cbs_vp9 [23:16:04 CEST] <cone-457> ffmpeg 03Paul B Mahol 07master:bd02a6d7ed90: avfilter/af_adelay: switch to activate [23:24:46 CEST] <cone-457> ffmpeg 03Paul B Mahol 07master:963c16ed38fb: avfilter/vf_lut3d: do not error out if TITLE is after other lines [00:00:00 CEST] --- Fri Oct 26 2018

1 0

ffmpeg.log.20181025
by burek 26 Oct '18

26 Oct '18

[00:18:35 CEST] <kepstin> it wouldn't hurt to give the 'fieldmatch' filter a try, and see what it can put back together. [00:19:16 CEST] <kepstin> lots of options for controlling matching and it dynamically adjusts for video cuts [00:20:10 CEST] <kepstin> oh never mind, you have blended frames [00:20:18 CEST] <kepstin> yeah, I don't know any way to fix that [00:22:38 CEST] <kepstin> it looks like someone telecined the video then scaled it down to 1/2 height :/ [00:23:43 CEST] <kepstin> is this a fmv from a video game? if it was originally a console game (PS2?), getting it from there might work better than a pc release since you'll likely get the original interlaced video. [01:58:40 CEST] <qwertymodo> @kepstin, it was originally released on PS1, but the quality was compressed to hell and only 15FPS, the PC re-release was obviously a brand new scan of the original animation, rendered at 1080p30 [01:59:24 CEST] <qwertymodo> there were a few other releases through the years, but all much lower resolution, this is the highest-res version ever released [02:00:18 CEST] <kepstin> ah, that's too bad :/ [02:01:45 CEST] <qwertymodo> it's a bummer, because the non-blended frames are fantastic, they're obviously direct 1080p scans, not upscales or anything like that [02:02:00 CEST] <qwertymodo> so if they had just rendered at the native 24fps, it would have looked perfect [02:03:11 CEST] <kepstin> I assume that the people encoding the video for the game got it as 60i content and saw combing, and ran it through a simple deinterlacing filter rather than detelecine it :/ [02:07:07 CEST] <iive> qwertymodo, you can actually try something in gimp/photoshop [02:07:25 CEST] <iive> take 2 frames. one crisp, one blended. [02:07:43 CEST] <kepstin> you get this, which is kinda eh https://www.kepstin.ca/dump/subtract.png [02:07:47 CEST] <kepstin> too much compression artifacts [02:08:26 CEST] <iive> yeh... [02:08:55 CEST] <iive> doing spp on both frames might improve it a bit, but still. [02:09:02 CEST] <kepstin> hmm, that was done using a linear light subtract, it's possible the blending was done gamma-incorrect, i should try that to compare. [02:09:27 CEST] <iive> spp is post-process filter [02:09:46 CEST] <kepstin> nah, that's the best match. [02:09:56 CEST] <qwertymodo> which frame did you put on top when you did the subtract? [02:10:11 CEST] <PhantomOfNyx> Hey there so I'm in a bit of an odd situation, my attempt is with x264 to try to have as accurate rendering as possible long story short I stream MMORPG's and the big problem with the default settings is I move 5 steps and everything turns into blurr with blurr on it ( even with slow encoding ) I have a pretty beefy CPU ( too many cores tbh ) was wondering if it would be worthwhile to go crazy with an rc-lookahead and lookahead-th [02:10:23 CEST] <qwertymodo> I can try that with one of the 1080p frames and see if that works any better with fewer artifacts [02:10:50 CEST] <PhantomOfNyx> Or anyone have any suggestions, I feel like I've almost tried everything I could think of [02:10:58 CEST] <iive> PhantomOfNyx, you are probably using extremely low bitrate [02:11:15 CEST] <kepstin> qwertymodo: that's the first two pngs from your imgur upload [02:11:22 CEST] <PhantomOfNyx> well twitch limits you to 6500kbs ( but even 720p at that does the same ) [02:11:54 CEST] <iive> 6,5Mbps should be enough. just be sure you are not using wrong setting e.g. 6,5Kbps [02:11:55 CEST] <qwertymodo> right, but which layer was on top, the clear frame or the blended one? [02:12:23 CEST] <PhantomOfNyx> Well not sure if the default presets is wrong settings but if so yes I am indeed xD [02:12:37 CEST] <kepstin> qwertymodo: if you take a blended frame, and put a known frame on top in subtract mode (linear light - if you're using gimp make sure it's 2.10) at 50%, then use levels (again, switch to linear light) to adjust the white level, again 50% of max. [02:12:58 CEST] <PhantomOfNyx> Nah In all seriousness I've tried almost everything I could think of but again I'm only this knowledgeable on the subject [02:14:31 CEST] <qwertymodo> what do you mean linear light? [02:14:39 CEST] <PhantomOfNyx> but yeah I'm quite honestly running out of ideas, I've tweaked a bit and it seems that changing to b-adapt=2 does wonders [02:14:53 CEST] <iive> assuming that blend = (previous + current)/2 ; where we have the previous and the blend [02:15:28 CEST] <iive> PhantomOfNyx, are you using libx264 ? [02:15:45 CEST] <PhantomOfNyx> yeah fairly certain that would be it. [02:16:10 CEST] <iive> try crf=18 and see how bit the stream goes. 22 should be fine too. [02:16:21 CEST] <kepstin> qwertymodo: yeah, so current = (blend - previous) * 2; - the key point is that you have to match the same gamma settings as were used in the original blend [02:16:40 CEST] <PhantomOfNyx> So slow preset and add the crf=18 as a modification to it ? iivve [02:17:19 CEST] <iive> PhantomOfNyx, yes [02:17:33 CEST] <kepstin> qwertymodo: so if the original blend was done in sRGB (or similar gamma) you have to use that when undoing the blend. I found that your example pngs looks decent when done in linear light in GIMP. Note that if you can do the blending in the original YUV it might be best? [02:18:03 CEST] <iive> kepstin, the blend is probably done in YUV [02:18:40 CEST] <kepstin> yeah, given that it was probably blended by a simple deinterlacing filter [02:19:53 CEST] <PhantomOfNyx> there we go definitely improved above what I had before for what seems like 0 extra performance cost o_O [02:20:18 CEST] <PhantomOfNyx> thanks iiv, would I benefit from lowering the crf further or any other magical tweaks you can recommend ? [02:20:48 CEST] <PhantomOfNyx> also I hear that enabling all my threads for encoding is a bad idea but would adding a few threads for lookahead hurt anything ? [02:20:49 CEST] <kepstin> qwertymodo: one thing to note is that you have two copies of the frame that's only available blended - one blended with the previous frame, one blended with the next frame. You can probably do the subtraction on both then average the two results to get a single better looking frame result. [02:20:56 CEST] <iive> PhantomOfNyx, lower crf would make the stream bigger, so you may hit bandwidth limit [02:21:15 CEST] <iive> PhantomOfNyx, try -preset faster -crf 22 [02:21:47 CEST] <iive> 18 is literally perfect quality [02:22:01 CEST] <PhantomOfNyx> ah makes sense. why faster above slow? [02:22:33 CEST] <PhantomOfNyx> just out of curiosity [02:22:38 CEST] <iive> in my tests, the slower gave me just 5% smaller file size [02:23:09 CEST] <iive> you can also try -nr 150 [02:23:14 CEST] <PhantomOfNyx> Ah I can't handle slower I can get away with slow [02:23:28 CEST] <PhantomOfNyx> ah yeah I've been using nr but haven't been able to see any difference [02:23:31 CEST] <kepstin> slower modes tend to add more variability to frame encoding time, iirc, which also means you're more likely to have issues with a live stream. [02:23:42 CEST] <PhantomOfNyx> was playing around with 50-1000 and it didnt' seem to do anything [02:24:15 CEST] <kepstin> (although if you're using something like -tune zerolatency, that turns off enough x264 features that the slower modes don't really help all that much, i think) [02:24:32 CEST] <PhantomOfNyx> That's true kepstin, also just out of curiousity would sliced threads be worth attempting to add if you want to try to lower your stream delay a bit [02:25:03 CEST] <PhantomOfNyx> Ah nah I usually go with tune film as it seems to be the most solid at removing the grain I had issues with [02:25:15 CEST] <PhantomOfNyx> still a bit there but definitely ALOT more detail right now :D [02:25:25 CEST] <kepstin> the 'film' tune is designed to preserve grain and find detail, not remove it [02:25:38 CEST] <kepstin> well, the 'grain' tune does that [02:25:42 CEST] <iive> you might want to run some filter to remove the grain. some denoise [02:25:49 CEST] <kepstin> i guess 'film' is somewhere inbetween [02:25:56 CEST] <PhantomOfNyx> Well sorry my definition of grain is basically blurr on stream that doesn't look good xD [02:26:15 CEST] <iive> film grain is just white noise [02:26:24 CEST] <kepstin> grain is very small lighter/darker spots that change between each frame (noise) [02:27:10 CEST] <PhantomOfNyx> hmm so you suggest I stop using film as a tune but what would you recommend instead for optimal live quality of well video games :) ? [02:27:24 CEST] <furq> use whatever looks good to you [02:27:30 CEST] <PhantomOfNyx> and then instead run deblock:-2:-2 [02:27:31 CEST] <iive> encoder could spend most of its bandwidth encoding that noise, and destroy the signal. [02:27:32 CEST] <kepstin> honestly, if it works well for the content in your game, go for it [02:27:33 CEST] <furq> if you're streaming video games then there's no film grain anyway [02:27:35 CEST] <PhantomOfNyx> or something like that [02:27:44 CEST] <furq> but film will generally just preserve fine detail [02:27:53 CEST] <PhantomOfNyx> yeah that's kinda what i want to keep [02:28:00 CEST] <iive> PhantomOfNyx, try -vf hqdn3d [02:28:02 CEST] <PhantomOfNyx> so if you have a better idea I'm all for it :D [02:28:08 CEST] <kepstin> depending on the exact type of content in your game, you might also try -tune touhou ;) [02:28:11 CEST] <furq> iive: he doesn't have any film grain [02:28:20 CEST] <iive> oh... [02:28:26 CEST] <iive> he did say a game... [02:28:28 CEST] <PhantomOfNyx> Wait there is seriously a tune touhou ? [02:28:28 CEST] <kepstin> (that's helpful for keeping details on smallish, ~16px stuff moving around) [02:28:58 CEST] <iive> of course, some of the core x264 were very into touhou [02:29:09 CEST] <furq> bad game [02:29:10 CEST] <iive> core developers... [02:29:16 CEST] <PhantomOfNyx> That's amazing! xD [02:29:28 CEST] <PhantomOfNyx> I don't play it myself but I have friends obsessed with it [02:29:51 CEST] <PhantomOfNyx> but yeah if you're not pulling my leg I'll try that tune [02:29:55 CEST] <iive> bad apple :P [02:29:58 CEST] <PhantomOfNyx> just never seen it mentioned [02:30:02 CEST] <furq> it's going to be a bad fit for anything other than STGs [02:30:04 CEST] <PhantomOfNyx> .... anywhere [02:30:10 CEST] <PhantomOfNyx> ah well xD [02:30:15 CEST] <PhantomOfNyx> then lets not [02:30:17 CEST] <furq> also yeah it's not in --fullhelp [02:30:22 CEST] <kepstin> i'm pretty sure it was mostly added as a joke, but it does actually help anything with small sharp-edged sprites moving around independently. Oddly enough, it helps with mouse cursors on desktop screen capture a bit. [02:30:23 CEST] <furq> presumably out of a well-deserved sense of shame [02:30:50 CEST] <PhantomOfNyx> might I ask what this does [02:30:52 CEST] <PhantomOfNyx> vf hqdn3d [02:30:59 CEST] <furq> it's a denoise filter [02:31:00 CEST] <PhantomOfNyx> Never seen it mentioned or heard of it before [02:31:05 CEST] <PhantomOfNyx> Ah [02:31:06 CEST] <furq> you probably don't need it [02:31:20 CEST] <iive> you need to remove film grain. [02:31:31 CEST] <iive> i know of only one game that adds it. [02:31:41 CEST] <furq> there's loads of games that add dumbass film grain effects [02:31:45 CEST] <furq> basically every game that has zombies in it does it [02:31:51 CEST] <kepstin> PhantomOfNyx: it does high quality (hq) denoise (dn) using the *third dimension* (3d), which happens to be time, in video context. [02:31:53 CEST] <iive> yep [02:32:13 CEST] <PhantomOfNyx> Thanks, I'm all for learning but sometimes this stuff can be hard to find xD [02:32:25 CEST] <iive> man ffmpeg-filters [02:32:28 CEST] <qwertymodo> ok, so I tried the subtraction for both copies of the blended frame, and added the two results together, and it actually looks decent [02:32:28 CEST] <PhantomOfNyx> but I really appreciate your acceptence of my newbishness x3 [02:32:29 CEST] <furq> i would link the libavfilter documentation page but it has like 300 filters in it [02:32:41 CEST] <furq> so that's probably not going to help without being pointed at specific entries [02:32:53 CEST] <PhantomOfNyx> yeah nah I will give this one a shot [02:33:12 CEST] <furq> like i said you don't really want hqdn3d unless you have noise or film grain to remove [02:33:17 CEST] <furq> otherwise it's just going to remove fine detail [02:33:21 CEST] <PhantomOfNyx> I noticed that testing vbv instead of crf Did alot of quality of my streams but twitch introduced low latency and it does NOT like variable bitrate [02:33:29 CEST] <iive> it may cause blur on movement [02:33:59 CEST] <kepstin> PhantomOfNyx: 'crf' mode creates very highly variable bitrate [02:34:08 CEST] <iive> i mean the hqdn3d may cause blur [02:34:13 CEST] <qwertymodo> my main purpose for this is actually going to be reduced resolution, so that'll help mask some of the remaining artifacts [02:34:42 CEST] <qwertymodo> Here's what it looks like: https://i.imgur.com/aCE9GIV.png [02:34:49 CEST] <kepstin> PhantomOfNyx: 'vbv' is a method for constraining bitrate - for streaming, you'd want to use either crf mode or vbr mode along with 'vbv' controls (maxrate, bufsize) to make sure the stream doesn't exceed the bandwidth limit. [02:34:52 CEST] <furq> qwertymodo: like i said, there might be an avisynth or vapoursynth filter that does this automatically [02:35:09 CEST] <furq> although if the blending isn't at fixed intervals then maybe you will have to do it all by hand [02:35:35 CEST] <PhantomOfNyx> Oh I know that one I quite liked vbv and had it tuned pretty well but again twitch doesn't like it for their low latency service [02:35:41 CEST] <PhantomOfNyx> as they want a constant bitrate [02:35:48 CEST] <iive> n8 ppl. [02:35:50 CEST] <furq> there are definitely filters that fix blended fields remarkably well, but what you have is one step worse [02:35:53 CEST] <qwertymodo> top and bottom of the example were existing clear frames, middle was an un-blended frame [02:35:57 CEST] <kepstin> PhantomOfNyx: 'vbv' is how you create constant bitrate (or nearly so) streams. [02:36:20 CEST] <kepstin> PhantomOfNyx: 'crf' makes highly variable bitrate, which twitch doesn't like [02:36:27 CEST] <furq> you can use crf with maxrate [02:36:51 CEST] <PhantomOfNyx> yeah pretty much all streaming application got maxrate set per default [02:36:56 CEST] <kepstin> yeah, but it's still variable, it'll drop below the maxrate when possible [02:37:12 CEST] <furq> so will abr [02:37:16 CEST] <furq> admittedly not as much [02:37:18 CEST] <PhantomOfNyx> found out by tweaking back when I was playing with vbv and i managed to pull trough like 15k bitrate somehow [02:37:23 CEST] <furq> unless you use nal padding or something [02:37:38 CEST] <kepstin> stuff like twitch wants as close to constant bitrate as possible to compensate for issues with tcp window scaling and network buffering and such [02:38:02 CEST] <furq> i'm surprised they care considering they restream everything as hls anyway [02:39:11 CEST] <kepstin> i'm kind of surprised that webrtc cdns for low latency video streaming haven't really picked up yet. [02:39:31 CEST] <furq> there's not a great deal of demand for low latency [02:39:40 CEST] <PhantomOfNyx> Actually mixer attempted that with a butchered mix of webrtc and libx264... [02:39:46 CEST] <furq> obviously stuff like youtube and twitch would gain nothing from it [02:39:50 CEST] <PhantomOfNyx> lets just say the stability is less than ... amazing [02:40:13 CEST] <kepstin> qwertymodo: that's not terrible but it looks like you don't quite have the brightness levels matched yet :/ [02:40:26 CEST] <PhantomOfNyx> well twitch is slowly introducing a low latency feature I suspect it takes x264 and converts it somehow partly to webrtc [02:40:35 CEST] <PhantomOfNyx> not sure what happens but they remux it somehow [02:41:04 CEST] <PhantomOfNyx> but was informed it really didn't like variable bitrate in the "re-coding process" [02:42:15 CEST] <furq> are you sure they're using webrtc for that [02:42:31 CEST] <PhantomOfNyx> I know mixer is, I honestly don't know what twitch does [02:42:46 CEST] <PhantomOfNyx> FTL is partly based on parts of webrtc [02:42:59 CEST] <furq> the problem with webrtc is that at least one browser uses openh264 exclusively for it [02:42:59 CEST] <PhantomOfNyx> but again it's only small parts and it comes out as a worst of both worlds kinda thing [02:43:03 CEST] <furq> which means you're stuck with h264 baseline [02:43:42 CEST] <PhantomOfNyx> Yep honestly I don't mean to be rude but I would REALLY love to see the industry move to h.265 already [02:43:51 CEST] <PhantomOfNyx> Like the NUMA support would be glorious [02:44:04 CEST] <PhantomOfNyx> I sit with a 2950x threadripper in a dedicated render machine [02:44:22 CEST] <PhantomOfNyx> And i just keep hitting walls with x264 [02:44:52 CEST] <furq> hevc doesn't have compelling enough efficiency advantages in most scenarios to justify dealing with the licensing bullshit [02:45:59 CEST] <furq> i'm not sure if realtime 1080p is even going to beat x264 at all most of the time [02:46:04 CEST] <furq> unless you have a dedicated box to throw at it [02:46:39 CEST] <PhantomOfNyx> Well yeah but most people on twitch don't even attempt 1080p [02:46:49 CEST] <PhantomOfNyx> thing is officially are we limited to 6k bitrate [02:47:01 CEST] <PhantomOfNyx> and that just doesn't cut it for anything else than 30fps 1080p [02:47:25 CEST] <PhantomOfNyx> but quote from devs from twitch themselves they are tweaking for 60 fps because they feel that gives a better gaming stream experience [02:48:04 CEST] <PhantomOfNyx> but you would need some kind of insane beast of a machine to get 1080p 60 down to 6k without looking worse than 1600x900 60 [02:48:32 CEST] <furq> depends on the game really [02:48:41 CEST] <furq> obviously if you're playing quake or something then no chance [02:49:09 CEST] <PhantomOfNyx> Well most who want 60fps plays Call of duty4 overwatch or etc [02:49:19 CEST] <PhantomOfNyx> so yeah not going to happen xD [02:49:38 CEST] <PhantomOfNyx> but I agree I could probably throw a pretty neat stream of hearthstone in 1080p 60 xD [02:50:41 CEST] <PhantomOfNyx> added the filter and I can't judge if it made the blurr on movement worse or better [02:51:22 CEST] <PhantomOfNyx> My frustration really comes from watching the game just POP into clarity because of how big the difference between movement and standing still is [02:51:39 CEST] <PhantomOfNyx> I would be quite willing to take an overall quality loss to make sure it's even [02:51:54 CEST] <PhantomOfNyx> because that pop drives me up the wall mentally ._. [02:54:02 CEST] <PhantomOfNyx> but once again thanks for the help so far furq and kepstin I've atleast gotten a bit further, do you think adding a bigger lookahead and possibly dedicating some threads to it would help with the "pop" [02:54:51 CEST] <kepstin> no, quality 'popping' is almost always due to not having enough bitrate to encode the video at consistent quality [02:55:15 CEST] <kepstin> sometimes you can tweak settings to lower the quality so everything looks consistent :/ [02:56:01 CEST] <PhantomOfNyx> yeh but thing is popping happens it doesn't matter if I attempt 540p at 6k bitrate or 900 p [02:56:09 CEST] <PhantomOfNyx> it seems to be consistent with this game though [02:56:23 CEST] <PhantomOfNyx> but the short answer would be better compression [02:56:50 CEST] <PhantomOfNyx> I seemed to fix some of it by adding b-adapt:2 before but that parameter MURDERS my for a good word [02:57:09 CEST] <PhantomOfNyx> wait is cpu a bad word? [02:57:15 CEST] <PhantomOfNyx> hmm weird [02:57:30 CEST] <PhantomOfNyx> probably a keyboard flunk then x3 [02:57:37 CEST] <kepstin> with realtime streaming you can't really get substantially enough better compression than x264 medium or fast to make a difference for this [02:58:16 CEST] <kepstin> using a lower quality (higher crf, if you're in crf mode) should help, and using abr mode instead of crf should make the quality a bit more even over time usually. [02:59:06 CEST] <furq> those quality pops (if i'm understanding you right) are pretty characteristic of abr and maxrate [02:59:11 CEST] <furq> or just maxrate in general really [02:59:35 CEST] <kepstin> assuming a big enough bufsize and abr set below maxrate, i'd expect the effect to be minimal [02:59:47 CEST] <furq> tweaking bufsize should help yeah [02:59:51 CEST] <PhantomOfNyx> yeah currently using "CBR" as it's called. [02:59:53 CEST] <furq> idk how much twitch will accept though [03:00:11 CEST] <PhantomOfNyx> so a bigger custom buffer ? [03:00:17 CEST] <PhantomOfNyx> that's what bufsize means right ? [03:00:17 CEST] <kepstin> PhantomOfNyx: what keyframe interval and framerate are you using? [03:00:20 CEST] <furq> if by cbr you mean nal-hrd=cbr then that doesn't really do anything for the picture quality [03:00:27 CEST] <PhantomOfNyx> Twitch recommends: 2 [03:00:33 CEST] <furq> ?? [03:00:38 CEST] <furq> gop size of 2? [03:00:48 CEST] <furq> does OBS measure that in seconds or something [03:00:49 CEST] <kepstin> keyframe interval of 2 seconds, i assume [03:01:04 CEST] <PhantomOfNyx> Oh yeah sorry [03:01:09 CEST] <PhantomOfNyx> 120 [03:01:15 CEST] <PhantomOfNyx> would be the translation [03:01:29 CEST] <furq> also you're definitely not using tune zerolatency, right [03:01:46 CEST] <PhantomOfNyx> Nope wouldn't touch that at all. [03:01:49 CEST] <PhantomOfNyx> it looks horrible [03:01:50 CEST] <PhantomOfNyx> no offense [03:01:55 CEST] <furq> yes it does [03:02:06 CEST] <kepstin> setting bufsize to an amount big enough to hold a full gop at your max bitrate should be accepted by twitch, i think [03:02:12 CEST] <furq> you see loads of guides for streaming to twitch/youtube etc that recommend turning that on [03:02:16 CEST] <furq> and it's really the worst advice [03:02:23 CEST] <furq> it's a pet hate of mine [03:03:05 CEST] <PhantomOfNyx> Actually mixer used us to force to use it for a while because Muh latency [03:03:16 CEST] <PhantomOfNyx> then I learned that they don't support bframes and was like bollocks [03:03:19 CEST] <furq> well if mixer is using webrtc then it makes no difference anyway [03:03:24 CEST] <kepstin> e.g. 10mbit/s for 2 seconds means vbv bufsize of around 20mbit, or 2.5mbyte [03:03:28 CEST] <furq> because yeah, webrtc is effectively baseline only [03:03:32 CEST] <furq> so no bframes or cabac [03:03:52 CEST] <PhantomOfNyx> yep oh someone should probably give the memo to them about cabac I didn't know that one [03:03:52 CEST] <furq> so you might as well use zerolatency, those are the two major features it disables [03:04:01 CEST] <furq> there's nothing they can do if they're using webrtc [03:04:04 CEST] <PhantomOfNyx> but mixer in short have ALOT of issues because everyone is using x264 profiles [03:04:10 CEST] <PhantomOfNyx> <_< [03:04:16 CEST] <furq> webrtc means baseline or it won't work in firefox [03:04:39 CEST] <furq> or vp9 and nobody can generate that in realtime anyway [03:04:46 CEST] <PhantomOfNyx> yeah nah I moved to twitch for a reason I want muh bframes and my shiny [03:04:50 CEST] <kepstin> there's an issue open on openh264 about adding support for decoding high, but... yeah, i'm not expecting that any time soon [03:04:58 CEST] <furq> even main would be great [03:05:40 CEST] <PhantomOfNyx> yeah I think I'm starting to grasp where all mixers issues come from [03:05:42 CEST] <kepstin> it's annoying because i think it uses the system ffmpeg or h264 decoder for regular video playback (e.g. youtube and stuff) [03:06:03 CEST] <furq> it does [03:08:35 CEST] <PhantomOfNyx> Hmm I think you guys got me in the right direction [03:09:09 CEST] <PhantomOfNyx> now with that said Slow doesn't really hurt my processing power at all, is there anything you can recommend for a bit better encoding to prevent the "pop" [03:09:52 CEST] <PhantomOfNyx> or should I just add a bunch of Bframes to the extreme and add all the fancy b-frame parameters? [03:10:22 CEST] <PhantomOfNyx> b-pyramid=2 b-adapt=2 etc [03:10:46 CEST] <PhantomOfNyx> also would it be better to add a high amount of bframes with b-adapt=1 or just stick with 4-6 at 2 ? [03:12:29 CEST] <PhantomOfNyx> Also furq any reason you asked for iframes would you suggest increasing or decreasing them from 120 ? [03:16:32 CEST] <furq> i didn't ask for that [03:18:40 CEST] <kepstin> I asked about keyframe interval, because knowing it can inform a useful range of bufsize values. [03:18:55 CEST] <kepstin> (and increasing bufsize should improve quality consistency) [03:22:55 CEST] <PhantomOfNyx> it's -vbv bufsize= right ? [03:23:13 CEST] <PhantomOfNyx> and what would you recommend for a baseline 6-6.5k bitrate ? [03:27:34 CEST] <furq> just -bufsize [03:27:58 CEST] <furq> bitrate * gop size (in seconds) is a good place to start [03:28:01 CEST] <furq> so probably 12000k [03:28:10 CEST] <PhantomOfNyx> Well I have a preset option in obs I can fill called vbv buffer [03:28:16 CEST] <furq> yeah that's the same thing [03:28:22 CEST] <PhantomOfNyx> figured as much [03:28:33 CEST] <PhantomOfNyx> but no reason to make it harder than it is [03:28:58 CEST] <PhantomOfNyx> so with a 6k bitrate outwards to twitch how big a buffer would I want [03:29:12 CEST] <PhantomOfNyx> not sure what gop size is ._. [03:29:14 CEST] <PhantomOfNyx> sorry [03:29:20 CEST] <furq> keyframe interval [03:29:33 CEST] <PhantomOfNyx> ah wait wouldn't that create insane delay O_O [03:29:40 CEST] <PhantomOfNyx> that's 12k [03:29:52 CEST] <furq> not really [03:30:45 CEST] <PhantomOfNyx> Well I'll trust you but omg O_O that's like a massive buffer and you're certain that won't create like massive delay for my viewers [03:30:52 CEST] <PhantomOfNyx> I sit at a 1.8sec average [03:31:01 CEST] <furq> 12000k is two seconds of buffer [03:31:05 CEST] <furq> your stream is 6000k [03:31:49 CEST] <PhantomOfNyx> How does this work exactly ( mind explaining it? ) [03:32:39 CEST] <furq> the encoder has (in this case) a 12 megabit buffer that it evicts every two seconds [03:32:52 CEST] <furq> so within the space of that buffer, the rate can spike as high as it wants to [03:33:08 CEST] <furq> as long as the total for that two seconds is no more than 12 megabits [03:33:09 CEST] <PhantomOfNyx> Hmm didn't seem to get rid of movement blurr ? [03:33:44 CEST] <furq> well yeah if you have more than two seconds where it wants to use more than 6mbit then it's no use [03:33:48 CEST] <furq> it should at least help [03:33:57 CEST] <furq> you probably also want to have rc-lookahead set very high [03:34:08 CEST] <PhantomOfNyx> yeah that was the one I was asking about [03:34:16 CEST] <PhantomOfNyx> also I can see you can dedicate threads to lookahead [03:34:19 CEST] <furq> rc-lookahead is the number of frames ahead the encoder will look to make rate control decisions [03:34:30 CEST] <PhantomOfNyx> seeing I have 32 threads I wouldn't mind dedicating a few for that [03:34:59 CEST] <furq> if you have that many threads you might as well just dedicate some to x264 and use veryslow with 120 lookahead [03:35:25 CEST] <PhantomOfNyx> Pfft tried very slow, my cpu can't handle it [03:35:29 CEST] <furq> you obviously get diminishing returns at some point though [03:35:37 CEST] <PhantomOfNyx> Can't even hit slower [03:35:47 CEST] <PhantomOfNyx> but I got plenty of wiggle room on slow [03:36:17 CEST] <furq> are you setting thread affinity [03:36:20 CEST] <PhantomOfNyx> but I've been informed setting threads=28 is a bad idea because you loose quality with this many threads [03:36:34 CEST] <furq> not really? [03:36:51 CEST] <furq> losing quality with more threads is only true of slice multithreading [03:36:55 CEST] <furq> frame multithreading isn't really affected [03:37:03 CEST] <furq> the speed of using more threads doesn't scale linearly though [03:37:28 CEST] <PhantomOfNyx> so no quality difference just lower gain per thread ( value ) [03:37:33 CEST] <furq> yeah [03:37:43 CEST] <furq> i guess if this is 1080p60 then maybe veryslow is a stretch even with a 2950X [03:37:48 CEST] <furq> or half of one [03:38:16 CEST] <PhantomOfNyx> Nah I got quad channel memory setup but windows Does NOT like Numa [03:38:56 CEST] <PhantomOfNyx> but I'm sitting at 1600x900:60 [03:39:03 CEST] <PhantomOfNyx> which honestly takes a fair amount as well [03:39:18 CEST] <PhantomOfNyx> I could probably handle 720p on slower [03:39:36 CEST] <PhantomOfNyx> but xsplit doesn't have a slower default profile anyway [03:39:51 CEST] <PhantomOfNyx> so It's fine I'm just adding on the slow profile. for tweaks [03:40:35 CEST] <PhantomOfNyx> but quick question would I gain from increasing of lowering my iframes [03:41:24 CEST] <furq> if you mean keyframe interval then no [03:41:35 CEST] <furq> higher interval is more efficient but will have higher latency [03:42:13 CEST] <PhantomOfNyx> Yeah but I was thinking maybe 1 iframe per frame with a 12k buffer [03:43:06 CEST] <PhantomOfNyx> seems to look the same but at a much lower delay [03:48:25 CEST] <PhantomOfNyx> furq if I asked really nicely could I get you to take a look at the result ? ( potentially allow me to dm you on discord or the like ? ) [04:15:06 CEST] <fumo> Hi, I'm writing an app in C that integrates the libavcodec library to take some raw image data from a binary file and encode it with the "mpeg2video". I used the example in the API documentation https://ffmpeg.org/doxygen/trunk/encode_video_8c-example.html as a starting point and my app seems to be working great. One issue is that when I play the resulting video with VLC, VLC doesn't show the length of the video or increment the time [04:15:06 CEST] <fumo> as it plays, just shows zeros at both ends as the video plays (the video does play fine though). Is there something I'm missing to get that working? maybe something I'm not setting in the frame structure before sending it to the encoder with avcodec_send_frame()? This is first time using any of these libraries or ffmpeg in general. [05:46:55 CEST] <worstje> I am using the method of different codec concatenation as listed in https://trac.ffmpeg.org/wiki/Concatenate (on Windows), but I am running into a snag known as the command line limit. I realized I can filter_complex_script to take some pressure off, but it is the huge amount of '-i inputfile's that are breaking me up. Is there a way to have ffmpeg look for all the separate inputs in a different file? [08:25:58 CEST] <kepstin> worstje: you can try using the 'movie' or 'amovie' filters in your filter script rather than inputs on the ffmpeg command line. [08:28:27 CEST] <worstje> kepstin: Hmm, I'll have to look into those. I was not aware filters could load inputs. I guess it is time to lose a day understanding how filters work in detail, then. [10:37:07 CEST] <Accord> I'm trying to add a video overlay at the very end of a background video, right now it's one frame short so the last frame of the background video doesn't have the overlay [10:38:08 CEST] <Accord> '[0:v] setpts=PTS-STARTPTS [src] ; movie=alpha.mov, trim=0.0:duration=1.163, setpts=PTS-STARTPTS + 5.0/TB, scale=1920:1080 [o1] ; [src][o1] overlay=eof_action=pass [mid1]', '-c:v', 'libx264', '-preset', 'superfast', '-crf', '20', '-pix_fmt', 'yuv420p', '-r', '25.0', '-map', '[mid1]', '-map', '0:a', 'out.mp4'] [10:38:21 CEST] <Accord> sorry [10:38:22 CEST] <Accord> ['ffmpeg', '-y', '-ss', '3.236', '-t', '6.163', '-i', u'input.mp4', '-filter_complex', '[0:v] setpts=PTS-STARTPTS [src] ; movie=alpha.mov, trim=0.0:duration=1.163, setpts=PTS-STARTPTS + 5.0/TB, scale=1920:1080 [o1] ; [src][o1] overlay=eof_action=pass [mid1]', '-c:v', 'libx264', '-preset', 'superfast', '-crf', '20', '-pix_fmt', 'yuv420p', '-r', '25.0', '-map', '[mid1]', '-map', '0:a', 'out.mp4'] [10:38:54 CEST] <Accord> so the input video has 6.163, the alpha is trimmed to 1.163 and offset to 5.0 seconds [10:39:15 CEST] <Accord> is there a better way to do this without having to worry about misalignment? [18:13:48 CEST] <sakrecoer> hi, recently i asked about how to scale a video up in size without aliasing. i need my edges sharp for pixel art. i got a great answer, wrote it down... but i lost the note... :( anybody could give me a hint? [18:15:46 CEST] <furq> sakrecoer: -vf scale=123:456:flags=neighbor [18:15:56 CEST] <furq> assuming you're scaling to a multiple of the original size [18:16:22 CEST] <sakrecoer> thank you so much furq!!!! <3 [18:16:48 CEST] <sakrecoer> backing the note up trice his time! hehe [18:17:49 CEST] <sakrecoer> furq: "123:456" being the final size i want right? [18:17:52 CEST] <furq> yeah [18:18:02 CEST] <sakrecoer> super! cheersÂ!! [18:18:04 CEST] <furq> only ever use neighbor for upscaling to exact multiples [18:18:14 CEST] <sakrecoer> noted! [18:18:28 CEST] <furq> if you just want something sharper than bicubic then use spline or lanczos [18:20:57 CEST] <sakrecoer> awesome! thank you! :) [20:10:20 CEST] <Mista_D> can FFMpeg decode source file at specific speed please? Need 1 x RT [20:11:09 CEST] <JEEB> libavcodec doesn't care, so you'll have to time your decoding yourself in your API usage [20:12:25 CEST] <durandal_1707> Mista_D: with ffmpeg tool, there is -re switch [20:13:58 CEST] <Mista_D> durandal_1707: thanks, that works, any way to tweak it? to set at x2.0 RT? [20:14:08 CEST] <JEEB> nope [20:14:48 CEST] <JEEB> also it has no back-up mechanism if the timestamps go wee-wee :) [20:15:03 CEST] <durandal_1707> Mista_D: it is nice hack [20:17:16 CEST] <furq> you can probably rescale the input framerate and use -re if you want something that isn't realtime [20:17:31 CEST] <furq> which is definitely a hack but not nice [21:10:28 CEST] <thebombzen> is there a way to run h264_mp4toannexb on a raw video stream with the avvC data concatenated in front? [21:56:29 CEST] <analogical> how do I enable audio when I use ffplay in windows? [22:02:10 CEST] <durandal_1707> analogical: it should already do audio [23:26:27 CEST] <alimiracle> hi I try useing ffmpeg to copy attachment streams, like subtitles and fonts I use this ffmpeg -y -v error -i video-test.mp4 -map 0 -c:s copy -c:t copy -c:d copy -vn -an -f matroska data.enc but its gave me this error Output file #0 does not contain any stream [23:27:30 CEST] <alimiracle> hi [23:27:40 CEST] <alimiracle> I try useing ffmpeg to copy attachment streams, like subtitles [23:27:50 CEST] <alimiracle> I use this [23:27:58 CEST] <alimiracle> ffmpeg -y -v error -i video-test.mp4 -map 0 -c:s copy -c:t copy -c:d copy -vn -an -f matroska data.enc [23:28:19 CEST] <alimiracle> Output file #0 does not contain any stream [23:30:37 CEST] <relaxed> alimiracle: pastebin.com your output [23:31:25 CEST] <alimiracle> hay, the error is Output file #0 does not contain any stream [23:32:56 CEST] <relaxed> try mapping (-map) only the streams you want [23:35:32 CEST] <alimiracle> relaxed> I nede mapping all the streams [23:37:09 CEST] <relaxed> except audio and video? try, ffmpeg -i input -map 0:t -map 0:s -c copy output.mkv [23:37:38 CEST] <furq> alimiracle: pastebin the full output, not just the error [23:38:13 CEST] <furq> you probably also don't want to use -c:s copy if the source is mp4 because i don't think anything else supports mov_text [23:38:49 CEST] <furq> and you'll definitely want -copy_unknown as well [23:41:53 CEST] <alimiracle> <furq> the error is the full output [23:50:21 CEST] <furq> well yeah get rid of -v error [23:58:38 CEST] <alimiracle> this all the error https://paste.kde.org/p3hym0ykk [23:59:26 CEST] <alimiracle> <furq> this all the error https://paste.kde.org/p3hym0ykk [00:00:00 CEST] --- Fri Oct 26 2018

1 0

ffmpeg-devel.log.20181024
by burek 25 Oct '18

25 Oct '18

[00:00:10 CEST] <dualz> It's been 10 years since I've written C, I have a noob question about compiling [00:00:32 CEST] <dualz> I made my own filter, now I want to change things, I don't want to recompile all of ffmpeg [00:00:38 CEST] <dualz> every time I do it [00:00:39 CEST] <michaelni> kierank, everyone with an account on the server should have access, durandal_1707 should have access [00:01:08 CEST] <kierank> Q: who has access. A: everyone who has access... [00:01:26 CEST] <dualz> is there a way I can make myfilter.o and link the other existing objects [00:02:43 CEST] <michaelni> (everyone please forive me the highlitging of you) kierank: michael,compn,cehoyos,reimar,beastd,llogan,ubitux,durandal,nevcairiel,daemon404,jamrial,martinvignali,thilo [00:02:58 CEST] <kierank> thx [00:03:14 CEST] <kierank> michaelni: can you document this somewhere, so people can contact them [00:04:26 CEST] <jkqxz> dualz: If you change config (by rerunning configure) then you have to rebuild everything. If config hasn't changed then running make should only rebuild files which actually need to be. [00:04:34 CEST] <michaelni> kierank, it could probably be put in maintainers i guess [00:05:25 CEST] <dualz> that's probably why I didn't notice, because I didn't ./configure before make [00:05:45 CEST] <atomnuker> michaelni: do I have access? previously I've had to complain to people periodically to upload new stuff there [00:09:26 CEST] <michaelni> atomnuker, i dont think you have an account on that box. [00:12:39 CEST] <michaelni> is there someone who wants to help with maintaining the fate samples / upload files for others (not just ones own samples) and who has no access currently ? [00:12:57 CEST] <michaelni> atomnuker ? [00:17:40 CEST] <atomnuker> sure, I'll help, I can see the need for some aac pce files soon for tests [00:19:55 CEST] <michaelni> atomnuker, send me your public ssh key or do you want to use the same as for git ? [00:23:08 CEST] <jkqxz> jamrial: Something like <https://0x0.st/s6bq.diff>? (Only does read.) [00:28:54 CEST] <atomnuker> michaelni: same one as git [00:29:01 CEST] <jkqxz> Without actually doing the parsing it won't be possible to avoid passthrough (av1_metadata) magically fixing up any incorrect cases. That's probably fine, I guess. [00:32:06 CEST] <jamrial> jkqxz: that check bit by bit of the frame header and the redundant frame header looks kinda slow [00:33:00 CEST] <jamrial> ideally it would check field by field by storing a copy of the filled AV1RawFrameHeader. but that's probably even slower [00:35:05 CEST] <jkqxz> The frame header shouldn't be too large, though it can easily be optimised by checking (bits_left < 24 ? bits_left : 24) or something bits at once. [00:35:22 CEST] <jamrial> also, can't you pass the unit's avbufferref instead of allocating a copy of the frame header in the priv context? [00:36:41 CEST] <jkqxz> Filling an AV1RawFrameHeader for comparison is painful because you then always need to keep a copy of the previous reference state for the second parse to work. [00:37:05 CEST] <jamrial> alright [00:38:26 CEST] <jkqxz> Yeah, I started to write with a bufferref but it messes with the write case because you don't yet have a bufferref there. [00:38:40 CEST] <jkqxz> (It's still writing into the temporary buffer.) [00:39:21 CEST] <jkqxz> Maybe there is a nicer way to make that work... [11:51:15 CEST] <funman> ttps://git.ffmpeg.org/gitweb/ffmpeg.git/commit/4241e44a3c0193d182d3d614e7b4… misses a VERSION bump [11:51:19 CEST] <funman> +h [11:53:50 CEST] <kierank> funman: LIBAVUTIL_VERSION_MICRO 101 -> 102? [11:55:49 CEST] <funman> I don't know what MICRO means [11:56:29 CEST] <durandal_1707> big MICRO optimization [11:57:53 CEST] <kierank> afaik micro needs bumping [11:57:54 CEST] <funman> Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version [11:58:08 CEST] <kierank> ok maybe not then [11:59:15 CEST] <January> kierank: also, it's maybe missing a changelog entry, not sure if it's significant enough to warrant one [12:01:43 CEST] <kierank> January: might as well [12:01:57 CEST] <kierank> January: I think we should push a hotfix [12:02:01 CEST] <kierank> when you are sure it's correct [12:03:07 CEST] <January> 'sure it's correct', what do you mean? [12:05:31 CEST] <kierank> when you're sure you've bumped the right version [12:07:20 CEST] <January> It's a MINOR bump with a MICRO reset in lavu, then nothing else in API changes later, right? [12:08:34 CEST] <kierank> don't know, ask someone who knows like durandal_1707 [12:10:19 CEST] <January> durandal_1707: ? [12:12:16 CEST] <durandal_1707> January: just bump minor of lavu (or also lavc) and reset micro to 100 [12:12:52 CEST] <atomnuker> yep, that's what you [12:13:20 CEST] <atomnuker> lavu yes, but no need for that in lavc, a micro bump would be fine there [12:14:19 CEST] <January> michaelni: what's your setup for testing qemu architectures? ubuntu images on them? [12:14:45 CEST] <funman> should be just lavu [12:16:54 CEST] <January> atomnuker: why bump lavc at all? dont think there were any API changes? [12:18:42 CEST] <nevcairiel> micro bumps are bnasically done on feelings, since the behavior of lavc was changed one might argue a bump might be appropriate, but considering lavu is going to get bumped at the same time anyway, usually you just wouldnt bother [12:19:17 CEST] <atomnuker> yep, pretty much [12:28:00 CEST] <cone-169> ffmpeg 03Josh de Kock 07master:f9d4126f2882: lavu: bump version, add Changelog entry [12:30:14 CEST] <durandal_1707> oh no!, you bumped major [12:30:59 CEST] <January> ? [12:31:06 CEST] <January> wait did i [12:31:22 CEST] <atomnuker> haha he made you look [12:31:43 CEST] <atomnuker> oh wait, he had me too [12:32:02 CEST] <January> :c [13:34:12 CEST] <michaelni> January, no images, IIRC its based on some Emdebian packages installed on a ubuntu box but emdebian is dead since 4 years so its probably not a good startpoint for a new setup [13:36:15 CEST] <michaelni> thats for the "environments" qemu itself i have multiple and much newer on the box [16:27:44 CEST] <durandal_1707> why you guys ignore xvc? [16:32:56 CEST] <nevcairiel> proprietary codec with oddball design, i doubt it'll ever get used anywhere [16:36:31 CEST] <durandal_1707> nevcairiel: it is open-source [16:37:25 CEST] <nevcairiel> its not [16:37:31 CEST] <nevcairiel> it may be visible source, but its not open-source [16:38:02 CEST] <funman> https://github.com/divideon/xvc/blob/master/LICENSE ? [16:38:25 CEST] <nevcairiel> they have all sorts of licensing shit on their website, you should read it =p [16:39:03 CEST] <durandal_1707> nevcairiel: on their website they also claim to be better than AV1 =p [16:39:15 CEST] <nevcairiel> they also want you to pay them [16:39:30 CEST] <durandal_1707> where is that written? [16:39:44 CEST] <nevcairiel> and their entire design of "if we get a patent claim against a feature that we cant solve, we'll just remove the feature and break all your files" is just insane [16:39:52 CEST] <nevcairiel> https://xvc.io/license/ [16:40:01 CEST] <durandal_1707> yea... [16:41:41 CEST] <nevcairiel> if its truely LGPL t hat means I can use it commercially quite easily, but if their website is to be trusted, commercial use wants money [16:41:43 CEST] <nevcairiel> so which is it [16:42:11 CEST] <gnafu> It's clearly been made by people who don't understand licensing, software or patent. [16:42:38 CEST] <gnafu> I appreciate the focus on technical excellence without regard to the legal side of things, but then they try to make legal claims that just don't work in the present world. [16:42:39 CEST] <nevcairiel> which would be funny because patent protection is like one of their main selling points [16:43:21 CEST] <gnafu> It could be the best codec in the world, generations ahead of anything else, and it would still be unusable in any commercial setting. [16:43:53 CEST] <gnafu> So maybe we'll start seeing scene releases using xvc, but not much else ;-). [17:42:56 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:bc940cf95c3b: avfilter/vf_datascope: fix rgba mapping for oscilloscope filter output [17:56:33 CEST] <BtbN> I somehow have doubts about it being miles ahead of everything else [18:11:14 CEST] <pkv> @peloverde thanks very much for your input; I was preparing to send an updated patch when you sent your review, which passes fate. I have one issue though with one of the vectors which will require an updated ref, not sure how to proceed. [18:11:38 CEST] <cone-973> ffmpeg 03Baptiste Coudurier 07master:8c733013af47: avformat/mxfenc: simplify dnxhd handling and add more flavors [18:12:38 CEST] <JEEB> pkv: reference file or just the reference result? [18:13:00 CEST] <JEEB> if the reference file was incorrect to begin with, then it'll have to be re-uploaded as fixed with a different file name [18:13:45 CEST] <pkv> it's this vector: al_sbr_cm_48_5.1.mp4 , pce is FRONT: 0-SCE[0] 1-CPE[0] 2-CPE[1] ; it is decoded atm as '5.1' = AV_CH_LAYOUT_5POINT0_BACK ; but with my patch it is decoded as FL+FR+FC+FLC+FRC+LFE which better corresponds to PCE [18:15:22 CEST] <pkv> @JEEB this entry : fate-aac-al_sbr_hq_cm_48_5.1: REF = $(SAMPLES)/aac/al_sbr_hq_cm_48_5.1_reorder.s16 [18:16:30 CEST] <pkv> so I guess this is the file which needs update ? I am unfamiliar with that stuff [18:16:35 CEST] <pkv> as you can guess [18:17:30 CEST] <nevcairiel> we cant change reference files, because that would break old tests, but if really needed we can add a second one with a different name (ie _v2 or such) [18:19:16 CEST] <pkv> these refs files would be the output of ffmpeg command used in test ? or are they produced with a reference decoder ? [18:19:36 CEST] <JEEB> would have to see into the history for those unfortunately :< [18:19:53 CEST] <JEEB> and yea, unfortunately those .s16 references are there instead of per-frame hashes being used [18:19:53 CEST] <pkv> the ref was changed [18:20:05 CEST] <pkv> lemme find the commit [18:20:30 CEST] <JEEB> well, history of FATE-SUITE which unfortunately probably isn't versioned :< [18:21:18 CEST] <pkv> the test was added by peloverde here: https://github.com/FFmpeg/FFmpeg/commit/46ef355c652fed8984a5c92e961b78282d9… [18:21:37 CEST] <pkv> and he updated the ref later: https://github.com/FFmpeg/FFmpeg/commit/37bed6ff3f7f48e25d1e0c3efdf8cbb90bc… [18:23:00 CEST] <JEEB> I wonder if framehash could be used instead since for a lot of tests that's being used to check exactness [18:23:10 CEST] <JEEB> and the references would be in the code repo then [18:23:51 CEST] <JEEB> I mean, sure - it would have a lot of frames because it's audio, but it would notice nonexactness in a similar way if this is an exact example [18:24:04 CEST] <JEEB> if this calculates some sort of % against something then it won't work of course [18:25:40 CEST] <pkv> what's this s16 format ? those are raw pcm_s16 I assume ? [18:26:06 CEST] <nevcairiel> probably yes [18:26:31 CEST] <JEEB> yup [18:27:37 CEST] <pkv> thanks @JEEB @nevcairiel [18:34:29 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:d94d2527317d: avfilter/vf_waveform: add gratcicule to rgb input [18:34:30 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:22d6d9164944: avfilter/vf_waveform: abort early if there are no components to show [18:54:04 CEST] <peloverde> pkv: With current git master I'm seeing FL+FR+FC+LFE+FLC+FRC [19:01:09 CEST] <pkv> @peloverde: :facepalm: you're right, I must have mixed the binaries . Sorry for the trouble and thanks again ! [19:25:23 CEST] <January> michaelni: I have now setup a mips qemu with debian stretch, but I'm encountering all sorts of header issues with the default toolchain. Are you running a weird configure or...? I have all the system -dev packages [19:28:03 CEST] <JEEB> January: if there's a mips FATE system you could check its configure [19:28:16 CEST] <JEEB> doesn't seem so... [19:28:22 CEST] <JEEB> at least ctrl+F on http://fate.ffmpeg.org/ [19:28:26 CEST] <JEEB> gives nothing [19:36:17 CEST] <philipl> BtbN: in nvdec_decoder_free, we don't push the context before calling destroy. Is that a bug? [19:36:33 CEST] <philipl> I happened to run under cuda debug tools (for my deinterlacer) and it called it out [19:36:44 CEST] <BtbN> probably, yes [19:38:12 CEST] <philipl> I adjusted it and things seem happy. [19:44:34 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/2d0ee127be14f44df19790d3aab5b55131… [19:45:03 CEST] <BtbN> ok [19:45:20 CEST] <cone-973> ffmpeg 03Philip Langdale 07master:2d0ee127be14: avcodec/nvdec: Push the context before destroying the decoder [19:48:04 CEST] <durandal_1707> ubitux: did you see that cube parsing patch on ml? [19:58:16 CEST] <cone-973> ffmpeg 03James Almer 07master:78f04843bf32: doc/APIchanges: add entry for AV_FRAME_DATA_S12M_TIMECODE [19:59:12 CEST] <January> michaelni: can you re-upload https://0x0.st/s6ap.nal as fate/h264/crew_cif.nal (it's a fixed file, the test hasnt been committed yet) [21:23:00 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:66974311b1da: avfilter/show_info : add print of color information (range, color_primaries, color_trc, colorspace) [21:23:01 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:3db33b446f3c: swscale/utils : simplify unscaled initial test for float pixfmt [21:23:02 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:26bf4a40507d: swscale/unscaled : add grayf32 le to be [21:23:03 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:156120fcf8fa: swscale/swscale_unscaled : rename packed_16bpc_bswap [21:43:21 CEST] <michaelni> January, crew_cif.nal uploaded [21:43:47 CEST] <cone-973> ffmpeg 03James Almer 07master:87588caf8cff: Revert "avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext" [21:47:42 CEST] <BBB> atomnuker: did you make progress on rewriting the multisymbol coder in dav1d? or not really interested? [23:15:30 CEST] <uartie> Is there a way to tell ffmpeg (e.g. via command-line flag) to abort/exit non-zero if hw initialization fails instead of silently falling back to software mode? [23:15:57 CEST] <cone-973> ffmpeg 03Michael Niedermayer 07master:203ccb874699: avcodec/msrle: Check that the input is large enough to contain a end of picture code [23:15:58 CEST] <cone-973> ffmpeg 03Michael Niedermayer 07master:3cc3cb663bf3: avutil/integer: Fix integer overflow in av_mul_i() [23:40:31 CEST] <cone-973> ffmpeg 03Marton Balint 07master:b02490a49700: avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag [23:41:47 CEST] <atomnuker> BBB: with the speed you're writing simd at you could probably rewrite it in 5 minutes [23:42:22 CEST] <BBB> I doubt that& [23:46:05 CEST] <BBB> apart from that being highly unlikely, there is also some goal of having multiple people involved in their relative fields of expertise. I know very little about arithmetic coding, and youve actually written one of those for the ff daala decoder [00:00:00 CEST] --- Thu Oct 25 2018

1 0

ffmpeg.log.20181024
by burek 25 Oct '18

25 Oct '18

[01:13:44 CEST] <KombuchaKip> JEEB: Which I believe is what I'm doing already? [08:58:06 CEST] <ecraven> hello ;) is it possible to *crop* a video without recoding? [08:59:05 CEST] <ecraven> H264 inside mp4, in this case [09:11:18 CEST] <ritsuka> ecraven: there is a "clap" box, but I don't know if either ffmpeg or video players support it [09:12:36 CEST] <ecraven> ritsuka: I don't have much idea about how encoders work, so maybe this is just plain impossible ;) I naively assumed that like in jpeg, there are "blocks", so you might be able to just crop at the block borders [11:42:28 CEST] <furq> ecraven: https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmetadata [16:31:56 CEST] <qqz> https://justpaste.it/5gt8r [16:32:06 CEST] <qqz> I want to employ two pass coding [16:32:19 CEST] <qqz> can anyone tell me what is wrong about the above example? [16:32:56 CEST] <BlackBishop> hi awesome peeps [16:33:06 CEST] <BlackBishop> so I have 2 mp3 files, in.mp3 and one out.mp3 [16:33:12 CEST] <BlackBishop> is there an easy way to mix them ? [16:33:25 CEST] <BlackBishop> like, put one in the left channel and one on the right channel ? [16:37:56 CEST] <durandal_1707> BlackBishop: if you use filtering for mp3 during playback only i will help you [16:44:30 CEST] <BlackBishop> durandal_1707: mkay :) all I want is in.mp3 on the left channel, and out.mp3 on the right channel .. or both on both [16:44:41 CEST] <BlackBishop> but I don't want to concatenate them ( one after the other ) [16:44:47 CEST] <BlackBishop> I want them playing both at the same time [16:44:57 CEST] <BlackBishop> I couldn't find a google online example for this [16:45:51 CEST] <qqz> anyone here who can tell me about the secrets of two pass coding [16:45:52 CEST] <durandal_1707> BlackBishop: are they both mono/single channel? [16:46:02 CEST] <qqz> I want an exact bitrate to be met [16:46:51 CEST] <BlackBishop> yep, they're both mono [16:50:06 CEST] <hiihiii> hi [16:50:15 CEST] <hiihiii> I am trying to [16:50:17 CEST] <hiihiii> -filter_complex "[0:v]fps=30[out_1]" -filter_complex "[out_1]fps=40[final]" -map [final] [16:50:54 CEST] <hiihiii> I'm getting errors. missing something? is this even possible? [16:52:28 CEST] <furq> you can't set -filter_complex twice [16:52:36 CEST] <furq> also you could just do -vf fps=30,fps=40 [16:52:59 CEST] <durandal_1707> BlackBishop: ffmpeg -i in.mp3 -i out.mp3 -lavfi amerge=2 out.flac [16:53:00 CEST] <qqz> furq: can you help me with two pass coding? [16:53:22 CEST] <furq> qqz: you need to set a bitrate [16:53:29 CEST] <hiihiii> I'm trying to avoid using select filter in the chain. it affects everything [16:53:51 CEST] <hiihiii> I'm using select because -itsoffset doesn't work with -r [16:53:57 CEST] <hiihiii> as in [16:54:18 CEST] <furq> qqz: also there's no reason to use 2-pass unless you have a specific target bitrate [16:54:26 CEST] <hiihiii> -r 60 -itsoffset -00:00:15 -i input.mp4 [16:54:43 CEST] <qqz> how to set the target bitrate; I am already setting audio and video bitrates [16:54:54 CEST] <furq> you're not setting any bitrates in that command you pasted [16:55:12 CEST] <qqz> what does -vb -ab then do? [16:55:20 CEST] <furq> they set the bitrates [16:55:21 CEST] <hiihiii> so I'm using select=gte(n\,900) but I'm not getting the results I want [16:55:21 CEST] <qqz> according ffprobe it sets a bitrate [16:55:23 CEST] <furq> they're also not present in that paste [16:55:45 CEST] <hiihiii> I get 15 seconds off black screen then it goes to where I want it to start [16:56:02 CEST] <BlackBishop> durandal_1707: that's the one ! [16:56:04 CEST] <furq> hiihiii: you need setpts after select [16:56:40 CEST] <furq> also -itsoffset does work with -r, but obviously -r changes the input timestamps [16:56:47 CEST] <furq> so you'd need to calculate the correct offset for the new framerate [16:57:06 CEST] <furq> that's probably more efficient than using select and setpts [16:57:49 CEST] <hiihiii> -r changes TS? the input is 60fps and I'm setting it to -r 60 [16:57:58 CEST] <furq> don't use -r then [17:01:13 CEST] <hiihiii> I need to set -r 60 otherwise I won't get the desired result [17:01:20 CEST] <hiihiii> for example [17:01:41 CEST] <hiihiii> -i input.mp4 -vf fps=30 out.mp4 [17:02:58 CEST] <furq> i don't know what this example is showing me [17:04:48 CEST] <hiihiii> will output the frames A,B,E,F,I,J,M,N... instead of A,C,E,G,I,K,M,O... [17:05:31 CEST] <hiihiii> setting -r will make the fps=30 skip everyother frame [17:05:59 CEST] <hiihiii> not setting it will make the filter skip two frames in a row [17:07:04 CEST] <Accord> is there a codec more suitable for multiple re-encodings than h264? [17:07:27 CEST] <Mavrik> Anything losless [17:07:46 CEST] <furq> hiihiii: iirc you want -vf fps=30:round=zero [17:07:59 CEST] <Accord> Mavrik: what would you recommend? [17:08:13 CEST] <BtbN> anything that's lossless works, including lossless h264 [17:08:40 CEST] <Mavrik> Yeah, lossless H.264 probably has the "best" maintained encoder [17:08:54 CEST] <qqz> furq: I am now using -maxrate but pass 2 still does not work [17:09:23 CEST] <furq> paste the command again [17:09:44 CEST] <BtbN> (m)jpeg actually has no generation loss as well. Assuming you don't change any settings like resolution, compression strenght, ... [17:10:02 CEST] <furq> it has generation loss when you want to convert it to something useful [17:10:36 CEST] <Accord> thanks, will look into lossless h264 [17:11:58 CEST] <qqz> furq: ?? [17:12:31 CEST] <hiihiii> use rgb then [17:17:12 CEST] <hiihiii> furq: nope still the same issue, this time I even get weird frame order C,D,F,I,J,L,O,P... [17:20:50 CEST] <hiihiii> I'll set start_time and see what happens [17:27:04 CEST] <hiihiii> idk [17:28:38 CEST] <hiihiii> using select filter or fps=select:15 both work for me as long as I'm not chaining filters [17:29:21 CEST] <hiihiii> ffmpeg -r 60 -i input.mp4 -vf "fps=30:start_time=15" out.mp4 [17:29:28 CEST] <hiihiii> that works [17:31:06 CEST] <hiihiii> this won't [17:31:12 CEST] <hiihiii> ffmpeg -r 60 -i input.mp4 -i input_2.mp4 -filter_complex "[0:v]fps=30:start_time=15[tmp];[tmp]fps=40[final]" -map [final] out.mp4 [17:31:45 CEST] <BtbN> Why do you specify -r as an input parameter? [17:32:06 CEST] <qqz> furq: why are you so excessively unhelpful; I just need a command line that works with -pass 2 and an upper bounded bitrate; why does -max-rate not do that? [17:32:13 CEST] <hiihiii> fps doesn't work well without it [17:32:30 CEST] <hiihiii> at least for my case [17:32:34 CEST] <raytiley> Any suggestions on improving this command: ffmpeg -i rtp://10.0.101.15:4444 -vsync 1 -af aresample=async=1 -c:v h264 -preset superfast -r 29.97 -maxrate 10000k -g 60 -s 1920x1080 -c:a aac -ac 2 -ar 48000 -f rtp_mpegts rtp://10.0.101.15:5556 [17:33:00 CEST] <raytiley> https://www.irccloud.com/pastebin/3ZZhQMBs/ [17:33:18 CEST] <raytiley> I'm getting frequent output like ^^ and i'm not sure how concerned I should be with it [17:42:37 CEST] <hiihiii> you know what I'll just sub fps with select='not(mod(n\,2)) [17:47:10 CEST] <hiihiii> thx for your help.-vsync 0 and this select will do. fixed [18:57:09 CEST] <King_DuckZ> hello, I'm told some formats such as prores mov should be able to support 3D videos, is that right? if so, what do I need to do in code to encode a 3D frame? [18:57:43 CEST] <durandal_1707> nothing [18:57:55 CEST] <King_DuckZ> I'm currently sending yuvyuv which should be L and R interleaved, but the output video is just a stretched version of my input frame [19:02:37 CEST] <King_DuckZ> did I say interleaved? I meant planar, I'm passing in 6 buffers [19:04:41 CEST] <durandal_1707> King_DuckZ: well you are supposed to encode it in TB or SBS way? [19:05:02 CEST] <King_DuckZ> tb? sbs? :S [19:05:17 CEST] <durandal_1707> top/bottom sidebyside [19:06:07 CEST] <King_DuckZ> I don't know, either is fine I guess [19:06:38 CEST] <King_DuckZ> wait a second, you mean I have to stitch the two views together as if it was one frame only? [19:08:32 CEST] <furq> it depends what the decoder expects [19:09:38 CEST] <durandal_1707> prores does not have special mode for 3d afaik [19:10:37 CEST] <furq> afaik side by side and alternating frames are the most common way of packing stereo 3d [19:10:42 CEST] <furq> but i've not looked into it in a while [19:10:53 CEST] <furq> you'd need to actually check what your target device wants [19:11:13 CEST] <furq> but yeah you probably don't need any kind of special support for it [19:11:14 CEST] <King_DuckZ> so it depends on... what? other tools we use in the company? [19:11:20 CEST] <furq> the thing that's playing it back [19:11:42 CEST] <King_DuckZ> ok, let me check if someone knows anything then [19:12:52 CEST] <GuiToris> hey, I made a theora video 5 years ago and it has such a bad quality. I've just read an article about postprocessing and I was wondering if 'uspp' could enhance it's quality? [19:13:07 CEST] <King_DuckZ> btw I think we're still recruiting, ffmpeg and c++ would make for a good candidate, let me know if you're interested (uk, europe) [19:13:12 CEST] <furq> there isn't much that'll improve the quality of theora [19:13:26 CEST] <furq> just use vp8/vp9 instead [19:14:32 CEST] <GuiToris> furq, I don't have the source files anymore. Do you think there's nothing I can do about it? [19:14:40 CEST] <furq> anything you can do is going to reduce the quality [19:14:56 CEST] <furq> if it's super blocky then maybe aggressively denoising it will make it more watchable, but you'll obviously lose a ton of detail [19:15:42 CEST] <furq> or there's a deblock filter, but i've never had cause to use it [19:15:57 CEST] <furq> i'm sure it has the same caveat though [19:19:35 CEST] <GuiToris> furq, https://ptpb.pw/iqG0 [19:19:38 CEST] <GuiToris> a screenshot [19:21:04 CEST] <GuiToris> do you think it can be somewhat improved? [19:21:43 CEST] <ChocolateArmpits> furq, I've cleaned up a noisy+slightly overcompressed source once, denoising helps a lot to stabilize random compression noise, the side effect is of course that areas that had noise stabilized became somewhat wobbly, but I guess that is a compromise. I used MCTemporalDenoise back then if I remember correctly. [19:22:08 CEST] <ChocolateArmpits> my source was in better condition than GuiToris once is though lol [19:22:13 CEST] <ChocolateArmpits> one* [19:22:46 CEST] <GuiToris> ahh, I shouldn't have used theora ... :( [19:22:49 CEST] <ChocolateArmpits> GuiToris, you have lots of ringing, probably due to downscaling [19:23:02 CEST] <ChocolateArmpits> ringing that seems impossible to clean up [19:23:19 CEST] <GuiToris> it has been rotated [19:23:26 CEST] <ChocolateArmpits> GuiToris, really suggest to investigate Avisynth filtering here, ffmpeg won't cut it [19:23:38 CEST] <ChocolateArmpits> Go to the forums and look up cases similar to yours [19:23:47 CEST] <ChocolateArmpits> see what people did and try yourself [19:23:55 CEST] <ChocolateArmpits> GuiToris, did you rotate is just now? [19:24:03 CEST] <ChocolateArmpits> rotate it* [19:24:26 CEST] <GuiToris> no-no, this is the final video [19:24:39 CEST] <GuiToris> it was edited 5 years ago, I hasn't touched it since then [19:24:46 CEST] <ChocolateArmpits> yeah I understand [19:24:50 CEST] <GuiToris> I've just noticed how bad the quality is [19:27:13 CEST] <GuiToris> ChocolateArmpits, here's another frame: https://ptpb.pw/bnnq [19:27:20 CEST] <GuiToris> that's the highest quality [19:27:48 CEST] <GuiToris> it's not sharp at all [19:27:49 CEST] <ChocolateArmpits> GuiToris, did you reduce the framerate to 12 frames per second as well? [19:28:03 CEST] <ChocolateArmpits> reminds me of shitty web compression in the 00s [19:28:34 CEST] <ChocolateArmpits> GuiToris, seriously, is the framerate alright though? [19:30:18 CEST] <GuiToris> ChocolateArmpits, https://ptpb.pw/LgUD [19:30:21 CEST] <GuiToris> it seems so [19:32:04 CEST] <GuiToris> I might have choosen low quality [19:32:12 CEST] <GuiToris> + theora [19:32:56 CEST] <GuiToris> I bet it wouldn't look the same with h265 or vp9 [19:34:53 CEST] <ChocolateArmpits> GuiToris, I'll try fetching a few frames of another source that I had tried to uplift a few months ago [19:35:12 CEST] <ChocolateArmpits> It's in comparatively worse condition than yours [19:35:37 CEST] <ChocolateArmpits> 240x180 12 frames per second at 642kbps cinepak [19:36:19 CEST] <ChocolateArmpits> I haven't continued with it, but got some results anyways [19:37:44 CEST] <ChocolateArmpits> it became a choice between smooth denoised wobbly sections, or keeping more "stable" artifacts of the original video [19:40:38 CEST] <GuiToris> I was thinking about using a denoiser and an unsharp mask [19:43:41 CEST] <GuiToris> I read about denoisers the other day and it's not completely clear. They are either temporal or spatial. Does spatial mean it denoises the images individually while temporal pays attention to other frames too? [19:43:54 CEST] <GuiToris> from this point of view a temporal denoiser is superior [19:43:56 CEST] <ChocolateArmpits> GuiToris, correct [19:44:10 CEST] <ChocolateArmpits> temporal filters have a higher performance cost [19:44:13 CEST] <ChocolateArmpits> generally [19:44:37 CEST] <ChocolateArmpits> but in your case you should definitely go for temporal filters [19:45:48 CEST] <GuiToris> thank you for your help ChocolateArmpits! [19:45:57 CEST] <durandal_1707> garbage in -> garbage out [19:47:33 CEST] <ChocolateArmpits> GuiToris, look https://files.catbox.moe/6t3xvn.png [19:47:40 CEST] <ChocolateArmpits> left original, right filtered [19:48:02 CEST] <GuiToris> now, that's quite smooth [19:48:05 CEST] <GuiToris> I like it [19:48:23 CEST] <ChocolateArmpits> i think it look pretty awkward in motion due to pulsing noise pattern [19:48:39 CEST] <ChocolateArmpits> like not pulsing bit starving, but something to do with framerate [19:48:56 CEST] <ChocolateArmpits> as in the filtered output in motion looks awkward last I remember [19:49:34 CEST] <ChocolateArmpits> I specifically used these two filters for Vapoursynth: https://github.com/HomeOfVapourSynthEvolution/vsTAAmbk https://github.com/IFeelBloated/Oyster [19:50:08 CEST] <ChocolateArmpits> one is an anti alias filter, which can help in your case, because you have quite a lot of it [19:50:27 CEST] <ChocolateArmpits> another one is a few kinds of other artifacts [19:50:31 CEST] <ChocolateArmpits> "ringing, staircase noise and blockiness" [19:50:56 CEST] <GuiToris> thank you, hopefully they'll help :) [19:51:05 CEST] <ChocolateArmpits> GuiToris, I'll give you the script [19:51:16 CEST] <GuiToris> that would be awesome [19:52:35 CEST] <ChocolateArmpits> GuiToris, here https://pastebin.com/raw/c76H31LG [19:52:45 CEST] <ChocolateArmpits> you'll have to set up vapoursynth by yourself [19:52:56 CEST] <ChocolateArmpits> where LWLibavSource goes your video source [19:52:58 CEST] <durandal_1707> that is only to make video look more anime [19:53:15 CEST] <ChocolateArmpits> durandal_1707, doesn't sound like a bad thing [19:53:44 CEST] <ChocolateArmpits> GuiToris, I also only filter luma because that's the most notable change to happen [19:53:54 CEST] <ChocolateArmpits> copying over chroma unchanged [19:54:07 CEST] <ChocolateArmpits> and upscale to 640x480 but that may change with your video [19:54:39 CEST] <GuiToris> thank you so much ChocolateArmpits [19:55:06 CEST] <ChocolateArmpits> GuiToris, this is just a head start, I'm sure your end result will change [19:55:26 CEST] <ChocolateArmpits> vapoursynth has powerful denoisers as well [19:55:36 CEST] <ChocolateArmpits> so investigate them as well [19:55:52 CEST] <GuiToris> will do [19:56:29 CEST] <ChocolateArmpits> GuiToris, also read the filter notes [19:57:06 CEST] <ChocolateArmpits> one of the two that I provided lists that you have to process each scene separately [19:57:48 CEST] <GuiToris> ohh, that makes it even more difficult [20:00:39 CEST] <ChocolateArmpits> they additional specific functions too, I've written my script to run a slow system, so it doesn't use additional functionality [20:00:47 CEST] <ChocolateArmpits> specify additional* [20:10:16 CEST] <qwertymodo> I'm looking for some help restoring a video file, but I don't really know the right terms for what I'm trying to do, so the very generic search results I'm getting are useless. Basically, the original video was created at 24FPS, but it was converted to 30FPS, and I'm wondering if it's possible to convert it back to 24FPS and clean up the frames that were blended together in the original conversion. The conversion turned every 4 frames [20:10:16 CEST] <qwertymodo> into 5 in a pattern 1, 2, 2+3, 3+4, 4. So, frame 3 doesn't exist in a "clean" form, just the frames where it was blended with the ones before and after it. Is there any way to restore frame 3 from the clean frames 2 and 4? [20:12:44 CEST] <iive> qwertymodo, i guess you are looking for inverse telecine [20:12:49 CEST] <ChocolateArmpits> qwertymodo, did you try these examples? https://ffmpeg.org/ffmpeg-filters.html#toc-Examples-61 [20:13:56 CEST] <ChocolateArmpits> qwertymodo, btw that's the exact pattern you are describing https://en.wikipedia.org/wiki/Three-two_pull_down [20:14:15 CEST] <qwertymodo> the video isn't interlaced though [20:14:31 CEST] <iive> qwertymodo, but it looks interlaced half of the time, does it not? [20:14:36 CEST] <qwertymodo> no [20:14:37 CEST] <ChocolateArmpits> oops correct link to the examples https://ffmpeg.org/ffmpeg-filters.html#Examples-61 [20:14:52 CEST] <qwertymodo> the full frames are actually blended [20:15:09 CEST] <ChocolateArmpits> it's just framerate conversion [20:15:21 CEST] <ChocolateArmpits> it doesn't need to "look" interlaced [20:15:23 CEST] <iive> qwertymodo, are you sure? this complicates thing. [20:15:40 CEST] <ChocolateArmpits> unless fields have been shifted, but as he describes it, there's none of that [20:15:52 CEST] <iive> qwertymodo, i guess that they looked interlaced, so somebody run deinterlacer on them and blended them. [20:16:56 CEST] <qwertymodo> nah, it was animated at 24FPS and then put into a video game at 60FPS, they probably just did a lazy default-settings framerate conversion [20:17:45 CEST] <qwertymodo> (the actual video file is rendered at 30, the game runs at 60) [20:18:27 CEST] <qwertymodo> here's an example: https://imgur.com/a/6LXn0 [20:19:02 CEST] <ChocolateArmpits> qwertymodo, dude just try one of the examples in the filters link that I gave, it'll probably work correctly without corrections [20:19:22 CEST] <qwertymodo> yeah, I'm doing that now [20:19:25 CEST] <ChocolateArmpits> ohhh [20:19:28 CEST] <ChocolateArmpits> this is nastier [20:19:41 CEST] <qwertymodo> yeah... [20:19:52 CEST] <ChocolateArmpits> I sort of expected fields to not be blended [20:20:03 CEST] <iive> he said they are blended [20:20:13 CEST] <ChocolateArmpits> I can't read x.x [20:20:15 CEST] <iive> qwertymodo, is this from game or ffplay? [20:20:56 CEST] <qwertymodo> those screenshots were exported from VLC, but in-game I don't see any combing artifacts [20:21:12 CEST] <qwertymodo> I don't think the video was ever interlaced [20:21:23 CEST] <furq> vlc doesn't deinterlace by default anyway [20:21:33 CEST] <furq> obviously doublecheck it's turned off though [20:22:11 CEST] <fsphil> quick q, if I do av_frame_ref(dst, src) is it safe to reuse src again with avcodec_receive_frame() without it affecting dst? implmenting an AVFrame double buffer [20:26:05 CEST] <furq> qwertymodo: there might be an avisynth/vapoursynth script that will do something about this, but i don't know of any [20:26:12 CEST] <furq> i suspect you're pretty much screwed [20:27:56 CEST] <atomnuker> fsphil: no, not until both src and dst are unref'd [20:28:17 CEST] <atomnuker> av_frame_ref creates a reference to the memory used by src in the dst frame [20:31:36 CEST] <iive> qwertymodo, vlc may deinterlace it, try playing the file with ffplay [20:31:57 CEST] <qwertymodo> well, at least some of the videos they appear to have used a different pulldown, where it's 1, 1+2, 2, 3, 3+4, 4. So at least on those videos I can pull out all of the original frames. [20:32:37 CEST] <qwertymodo> is there a windows build of ffplay? [20:34:14 CEST] <ChocolateArmpits> qwertymodo, builds by zeranoe have it [20:37:13 CEST] <qwertymodo> I tried the IVTC examples, and the output looks exactly the same [20:37:33 CEST] <furq> well if you ivtc it then you'll only have one blended frame instead of two [21:05:56 CEST] <fsphil> atomnuker: thanks. makes sense [21:09:31 CEST] <atomnuker> technically if there's one reference left and you own it you can do whatever you want, so only dst would need to be unref'd [21:10:49 CEST] <iive> qwertymodo, the thing is in theory you can revert that, but I don't think ffmpeg have filter that does it. also compression artifacts make it even harder. [21:11:46 CEST] <iive> qwertymodo, the idea is that one of the blended fields is repeat of the previous frame, so you can reconstruct the other field. then use the reconstructed field for the following frame. [21:20:24 CEST] <furq> if it's actually split into frames, sure [21:20:27 CEST] <furq> or fields, rather [21:36:10 CEST] <qwertymodo> The more closely I look into these videos files, the more I realize there simply isn't going to be a way to automate this conversion if I want to do it right. The pulldown switches from scene to scene within the same file, and all kinds of other stuff (some scenes are only animated at 12fps, others at 24). It's probably a fool's errand to even try. [21:36:42 CEST] <qwertymodo> Dangit, Squaresoft... [00:00:00 CEST] --- Thu Oct 25 2018

1 0

ffmpeg-devel.log.20181023
by burek 24 Oct '18

24 Oct '18

[00:00:21 CEST] <nevcairiel> git isnt very useful in showing that info [00:01:24 CEST] <JEEB> yea, that's how it looks like [00:01:44 CEST] <JEEB> if you don't have libav master around it won't show that one of them is part of that [00:03:02 CEST] <jamrial> yeah, one is from libav [00:03:16 CEST] <jamrial> the merge commit is a separate commit than the merged commit in question [00:03:21 CEST] <JEEB> yup [00:03:39 CEST] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=0ff76ca86e0ea4dcf2b392c45f… [00:20:24 CEST] <cone-636> ffmpeg 03Mark Thompson 07master:3143fe34f622: cbs_h264: Actually decompose end-of-sequence NAL units [00:20:25 CEST] <cone-636> ffmpeg 03Mark Thompson 07master:e5fda1ff2896: cbs_h264: Fix SPS used for pic_timing timestamp [00:20:26 CEST] <cone-636> ffmpeg 03Mark Thompson 07master:da6db843b80e: cbs_h2645: Allocate all internal buffers with padding [00:21:39 CEST] <tmm1> jkqxz: thanks [00:21:51 CEST] <jkqxz> :) [00:22:59 CEST] <jkqxz> jamrial: Was there any interest in the libaom tiles thing? (Nobody replied.) [00:23:24 CEST] <jamrial> if nobody replied then apply it [00:23:52 CEST] <jamrial> and there is interest, of course. no other way to get multithreading encoding, or tile threading during decoding :p [00:26:57 CEST] <jamrial> jkqxz: also, if you dont' have time to review the amf patch, then we should apply it. it's been in the list for four months now, and supposedly blocking further work [00:27:17 CEST] <jamrial> its author is the only amf developer, so he's a defacto maintainer [00:27:34 CEST] <jamrial> i'd wait until 4.1 branch is created in that case, though [00:28:00 CEST] <jkqxz> Bleh, I really should look at that. [00:28:39 CEST] <JEEB> I should ping the discontinuity logging patches again [00:28:45 CEST] <JEEB> since I only got an OK to one of them I think [00:29:21 CEST] <jkqxz> It's been at the bottom of my todo list for ages, and keeps getting pushed down because ugly proprietary stuff I don't really care much about (but would prefer not to be horrible). [00:43:03 CEST] <jkqxz> jamrial: prores cbs looks like it would be completely trivial to implement, since the header is fixed. Dunno if anyone would ever care about the trace, probably not given how little it contains. [00:51:01 CEST] <jamrial> jkqxz: alright. just saying since it'd be nice as a long term project to shift bitstream parsing in general to CBS [00:51:57 CEST] <jamrial> considering that eventually a new parser api based on avpacket should be written [00:52:56 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07master:e90f0ac334f2: avcodec/ilbcdec: Check startindex [00:52:57 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07master:305e523105f6: avcodec/jpeg2000dec: Fix off by 1 error in JPEG2000_PGOD_CPRL handling [01:08:17 CEST] <jkqxz> Yeah, I'm in favour of doing it, but I agree it shouldn't block the trivial metadata bsf. [01:08:27 CEST] <jkqxz> Is there a spec anywhere for proper names? It would probably only take half an hour to write. [01:12:48 CEST] <jkqxz> (All I can find from Apple is an informationless thing saying how good it is and that you shouldn't use FFmpeg because it is not an Authorised Implementation and that anyone who uses it is therefore Very Naughty.) [01:20:37 CEST] <JEEB> yea, unfortunately they didn't open source it like ALAC (probably for some very obvious Business Reasons) [01:41:43 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:b2e9d3da817f: avformat/utils: Fix integer overflow in discontinuity check [01:41:44 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:bccddd7fcc14: avformat/utils: Never store negative values in last_IP_duration [01:41:45 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:65b0caf47d73: avcodec/ra144: Fix integer overflow in add_wav() [01:41:46 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:1061a2e2efa9: avcodec/h264_cavlc: Check mb_skip_run [01:41:47 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:6e14fc4aa1a2: avcodec/mpeg4videodec: Fix typo in sprite delta check [01:41:48 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:afebdc3ed789: avcodec/jpeg2000dec: Fix off by 1 error in JPEG2000_PGOD_CPRL handling [01:41:49 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/4.0:938bc919eac4: Prepare 4.0.3 release [01:51:52 CEST] <jkqxz> nevcairiel: Did you ever have a machine which hit the Intel H.265 plugin segfault on load problem? If so, does it still happen? If not, any idea how to track down what was going there (when considering ignoring it)? [02:13:01 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:b8fd13befef4: libavformat/oggparsevorbis: Fix memleak on multiple headers [02:13:02 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:7fd80d91f72c: avformat/utils: Fix integer overflow of fps_first/last_dts [02:13:03 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:81a6076e4b8e: avformat/oggparsetheora: Do not adjust AV_NOPTS_VALUE [02:13:04 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:4df16ad1ef06: avformat/avidec: Fix integer overflow in cum_len check [02:13:05 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:46f37c65abc0: avformat/oggparseogm: Fix undefined shift in ogm_packet() [02:13:06 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:69344f628bf5: avformat/oggparseogm: Check lb against psize [02:13:07 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:ad7c57f9db50: avformat/oggparsedaala: Do not adjust AV_NOPTS_VALUE [02:13:08 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:30d40580c4e0: avformat/mov: Fix integer overflows related to sample_duration [02:13:09 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:448cd0d0b341: avcodec/wmalosslessdec: Reset num_saved_bits on error path [02:13:10 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:e62380038765: avcodec/nuv: Check for minimum input size for uncomprssed and rtjpeg [02:13:11 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f4fe7022583e: avcodec/nuv: rtjpeg with dimensions less than 16 would result in no decoded pixels thus reject it [02:13:12 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:028af5acbe7b: avformat/mov: Check STSC and remove invalid entries [02:13:13 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:7ccb9c37ac47: avcodec/get_bits: Make sure the input bitstream with padding can be addressed [02:13:14 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:0721e3c1bd23: avcodec/tableprint_vlc: Fix build failure with --enable-hardcoded-tables [02:13:15 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:03f891c05099: avcodec/wmalosslessdec: Fix null pointer dereference in decode_frame() [02:13:16 CEST] <cone-636> ffmpeg 03heimdallr 07release/3.0:19379529a5b8: avcodec/imgconvert: Fix loss mask bug in avcodec_find_best_pix_fmt_of_list() [02:13:17 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1f648a098da0: avcodec/cscd: Error out when LZ* decompression fails [02:13:18 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:98096645f28f: avcodec/aacdec_fixed: Fix integer overflow in apply_independent_coupling_fixed() [02:13:19 CEST] <cone-636> ffmpeg 03Hendrik Schreiber 07release/3.0:da371c5b215d: swresample/swresample: Fix for seg fault in swr_convert_internal() -> sum2_float during dithering. [02:13:20 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:b2be78f9d2de: libavcodec/rv34: error out earlier on missing references [02:13:21 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:72b9ba8a5bfe: avcodec/aacsbr_fixed: Fix integer overflow in sbr_hf_assemble() [02:13:22 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:c0bb5613d42f: avcodec/movtextdec: Check style_start/end [02:13:23 CEST] <cone-636> ffmpeg 03Matt Wolenetz 07release/3.0:4b04da1e52da: lavc/libopusdec: Allow avcodec_open2 to call .close [02:13:24 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:5aaa5bd1b04d: avcodec/mjpegdec: Check input buffer size. [02:13:25 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:065057c8a351: avcodec/truemotion2: Propagate out of bounds error from GET_TOK() [02:13:26 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:cf321e93c4a9: avcodec/utils: Enforce minimum width also for VP5/6 [02:13:27 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:b591673c507d: avformat/utils: Check cur_dts in update_initial_timestamps() more [02:13:28 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:9665d6258c6c: doc/APIchanges: Fix typos in hashes [02:13:29 CEST] <cone-636> ffmpeg 03Rahul Chaudhry 07release/3.0:ad3ec05d036a: swresample/arm: remove unintentional relocation. [02:13:30 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:5891d222ff6e: avcodec/cinepak: move some checks prior to frame allocation [02:13:31 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:3009bf0be645: avcodec/cinepak: Skip empty frames [02:13:32 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:e49e8259df91: avcodec/dfa: Check dimension against maximum [02:13:33 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:a8640c87a70f: avcodec/dsicinvideo: Propagate errors from cin_decode_rle() [02:13:34 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:3bf0a405f051: avcodec/dsicinvideo: Fail if there is only a small fraction of the data available that comprises a full frame [02:13:35 CEST] <cone-636> ffmpeg 03Stephan Holljes 07release/3.0:73d07e320c4a: lavf/http.c: Free allocated client URLContext in case of error. [02:13:36 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:142e1e3e9af8: avcodec/ffv1enc: Check that the crc + version combination is supported [02:13:37 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:70c7c7392089: avcodec/vc1_block: simplify ac_val computation [02:13:38 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:cc8710b5afeb: avcodec/elsdec: Fix memleaks [02:13:39 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:aaa2d4a26523: avcodec/h263dec: Check slice_ret in mspeg4 slice loop [02:13:40 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:baa4913e1272: avcodec/error_resilience: Fix integer overflow in filter181() [02:13:41 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:04e69effbb31: avcodec/wavpack: Fix integer overflow in DEC_MED() / INC_MED() [02:13:42 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:9505b285385e: avcodec/flac_parser: Fix infinite loop [02:13:43 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:88e5a30cf835: avcodec/g2meet: Change order of operations to avoid undefined behavior [02:13:44 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:6aae60cc7da8: avcodec/jpeg2000dec: Skip init for component in CPRL if nothing is to be done [02:13:45 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:6850377b598c: avcodec/jpeg2000dec: Fix undefined shift in the jpeg2000_decode_packets_po_iteration() CPRL case [02:13:46 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:00c18862a313: avcodec/g2meet: Check RGB upper limit [02:13:47 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1747563cead7: avcodec/fic: Check available input space for cursor [02:13:48 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:a8fcb810c964: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0 / COMPOSE_DD137iL0 [02:13:49 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:ffe4ffa4ef7a: avformat/mov: Only fail for STCO/STSC contradictions if both exist [02:13:50 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:876d3ee86209: indeo4: Decode all or nothing of a band header. [02:13:51 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:3eff19d38806: avcodec/mlpdec: Only change noise_type if the related fields are valid [02:13:52 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:0d5851101311: avcodec/mpeg4videoenc: Use 64 bit for times in mpeg4_encode_gop_header() [02:13:53 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:fe37daf25dc6: avcodec/g723_1dec: Clip bits2 in both directions [02:13:54 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:be77d7ba7879: oavcodec/aacpsdsp_template: Use unsigned for hs0X to prevent undefined behavior [02:13:55 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1f81818c6afe: avcodec/aacdec_fixed: use 64bit to avoid overflow in rounding in apply_dependent_coupling_fixed() [02:13:56 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:243bdbde5718: avcodec/g2meet: ask for sample with overflowing RGB [02:13:57 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:fe9c23bebbb2: avcodec/fic: Avoid some magic numbers related to cursors [02:13:58 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:b4024909c121: avformat/mov: Break out early if chunk_count is 0 in mov_build_index() [02:13:59 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:7f142e540231: avformat/mov: replace a value error by clipping into valid range in mov_read_stsc() [02:14:00 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:bbd9f480f3e5: avcodec/amrwbdec: Fix division by 0 in find_hb_gain() [02:14:01 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f144d5eb4977: avcodec/opus_silk: Change silk_lsf2lpc() slightly toward silk/NLSF2A.c [02:14:02 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:aee71463fb2f: avcodec/truemotion2: Fix overflow in tm2_apply_deltas() [02:14:03 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:0c645bd73c7a: avcodec/mjpegdec: Fix integer overflow in ljpeg_decode_rgb_scan() [02:14:04 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:07fd8627e5c2: avcodec/shorten: Sanity check nmeans [02:14:05 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:50e55b81be23: avcodec/shorten: Fix multiple integer overflows [02:14:06 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:23fdebaec579: avcodec/wavpack: Fix overflow in adding tail [02:14:07 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:aa803d93bf89: avcodec/xwddec: Use ff_set_dimensions() [02:14:08 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:18214e2a3f20: avcodec/h264_mc_template: Only prefetch motion if the list is used. [02:14:09 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:ff75dc10fd27: avformat/mov: Only set pkt->duration to non negative values [02:14:10 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:963915a4b416: fftools/ffmpeg: Fallback to duration if sample rate is unavailable [02:14:12 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:626143903b1d: avutil/common: Fix undefined behavior in av_clip_uintp2_c() [02:14:12 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:a1c125d2bda6: avcodec/dirac_dwt_template: Fix undefined behavior in interleave() [02:14:13 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:eaefd3ada963: avcodec/aacdec_fixed: Fix undefined integer overflow in apply_independent_coupling_fixed() [02:14:14 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:d862380718a1: avcodec/mjpegdec: Check for end of bitstream in ljpeg_decode_rgb_scan() [02:14:15 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1e067b7ed86c: avcodec/escape124: Check buf_size against num_superblocks [02:14:16 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:662f7cef06d3: avcodec/cscd: Check output buffer size for lzo. [02:14:17 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:181c3d82e902: avcodec/ra144: Fix integer overflow in ff_eval_refl() [02:14:18 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:dd7d2770f331: avcodec/escape124: Fix spelling errors in comment [02:14:19 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:405cfcae41cd: avcodec/jpeg2000dec: Check that there are enough bytes for all tiles [02:14:20 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:3afdb1c8a752: avcodec/jpeg2000dec: Fixes invalid shifts in jpeg2000_decode_packets_po_iteration() [02:14:21 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:21a65701581d: avcodec/shorten: Fix undefined addition in shorten_decode_frame() [02:14:22 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:438e848b65c2: avcodec/indeo4: Check for end of bitstream in decode_mb_info() [02:14:23 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:ee8c6566e2ab: avformat/rmdec: Do not pass mime type in rm_read_multi() to ff_rm_read_mdpr_codecdata() [02:14:24 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:6cadf46dff14: avformat/pva: Check for EOF before retrying in read_part_of_packet() [02:14:25 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:94edbf464c00: avformat/mms: Add missing chunksize check [02:14:26 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:469503ac1de3: avformat/movenc: Check that frame_types other than EAC3_FRAME_TYPE_INDEPENDENT have a supported substream id [02:14:27 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:4ead5a947003: avcodec/mjpegdec: Check for odd progressive RGB [02:14:28 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:790e6fead078: avformat/movenc: Check input sample count [02:14:29 CEST] <cone-636> ffmpeg 03James Almer 07release/3.0:c3831e89efce: libwebpenc_animencoder: add missing braces to struct initialization [02:14:30 CEST] <cone-636> ffmpeg 03James Almer 07release/3.0:0d4a11d0a947: avformat/utils: fix mixed declarations and code [02:14:31 CEST] <cone-636> ffmpeg 03Rahul Chaudhry 07release/3.0:328ab7f0a1ca: swresample/arm: rename labels to fix xcode build error [02:14:32 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:0c9c4c3103c2: avcodec/dirac_dwt_template: Fix signedness regression in interleave() [02:14:33 CEST] <cone-636> ffmpeg 03Simon Thelen 07release/3.0:e7dc6231e263: avcodec/imgconvert: fix possible null pointer dereference [02:14:34 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:d7d237a441cb: avcodec/dvdsub_parser: Init output buf/size [02:14:35 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:961eeb4035c3: avcodec/dvdsub_parser: Allocate input padding [02:14:36 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:60493f388ca7: avutil/pixfmt: Document chroma plane size for odd resolutions [02:14:37 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:d7d54f3fd5a6: swresample/swresample: Fix input channel count in resample_first computation [02:14:38 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:057cfa4200e4: avcodec/diracdec: Prevent integer overflow in intermediate in global_mv() [02:14:39 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:86dfce06e3ac: avcodec/dirac_dwt_template: Fix several integer overflows in horizontal_compose_daub97i() [02:14:40 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:cc82d22289c9: avcodec/diracdec: Change frame_number to 64bit as its a 32bit from the bitstream and we also have a -1 special case [02:14:41 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:9f18b056da9b: avcodec/diracdec: Check bytes count in else branch in decode_lowdelay() too [02:14:42 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f81fd4c524e7: avcodec/qtrle: Check remaining bytestream in qtrle_decode_XYbpp() [02:14:43 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f6e570aa011b: avcodec/aacpsdsp_template: Fix integer overflow in ps_stereo_interpolate_c() [02:14:44 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f7778c2ce954: avcodec/mpegaudio_parser: Initialize poutbuf* [02:14:45 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:5eeaaa29fae0: avcodec/shorten: Check verbatim length [02:14:46 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f1425b389a3b: avcodec/shorten: Fix integer overflow in residual/LPC combination [02:14:47 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:0ea54cae2182: avformat/rmdec: Fix EOF check in the stream loop in ivr_read_header() [02:14:48 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:4babf70c7efb: avformat/mlvdec: read_string() received unsigned size, make the argument unsigned [02:14:49 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:172bb520c98f: avformat/nsvdec: Do not parse multiple NSVf [02:14:50 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:22f743e60201: avcodec/snowdec: Fix integer overflow with motion vector residual [02:14:51 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:c2ac8d314778: avcodec/vb: Check for end of bytestream before reading blocktype [02:14:52 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:23c5d8d9ce7d: avcodec/hq_hqa: Check remaining input bits in hqa_decode_mb() [02:14:53 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:fceedd4de9b2: avcodec/ra144: Fix undefined integer overflow in add_wav() [02:14:54 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:fcab1b996a21: avcodec/h264_refs: Document last if() in ff_h264_execute_ref_pic_marking() [02:14:55 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1049ccec3449: avcodec/dvdsubdec: Avoid branch in decode_run_8bit() [02:14:56 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1ed6224cdf28: avcodec/shorten: Fix bitstream end check in read_header() [02:14:58 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:6161aade4c8d: avcodec/zmbv: Update decomp_len in raw frames [02:14:58 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:648b904662c2: avcodec/zmbv: Check that the decompressed data size is correct [02:14:59 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:58cb3ad576cb: avcodec/mpeg4videodec: Fix undefined shift in get_amv() [02:15:00 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:9b95c4740d23: avcodec/dvdsubdec: Sanity check len in decode_rle() [02:15:01 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:4b14c3ed7857: avcodec/unary: Improve get_unary() docs [02:15:02 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:51404bb4f613: avformat/utils: Fix integer overflow in discontinuity check [02:15:03 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:6a5b0a3c7513: avformat/utils: Never store negative values in last_IP_duration [02:15:04 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:b15db639a5ca: avcodec/ra144: Fix integer overflow in add_wav() [02:15:05 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:f9cfdf2baefd: avcodec/h264_cavlc: Check mb_skip_run [02:15:06 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:9c1bb7e8debd: avcodec/mpeg4videodec: Fix typo in sprite delta check [02:15:07 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:dd5232c83847: avcodec/jpeg2000dec: Fix off by 1 error in JPEG2000_PGOD_CPRL handling [02:31:55 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07release/3.0:1dbf2bc7a958: Update for 3.0.12 [03:51:27 CEST] <tmm1> jkqxz: i had to use https://0x0.st/s6Ks.diff to get the cbs_misc patchset to compile with master. is there a better value to pass in for subscripts? [09:46:13 CEST] <nevcairiel> jkqxz: i dont remember encountering that particular problem, but i havent messed with qsv hevc encoding much [10:51:04 CEST] <rcombs> I'm working on an I-D to add arbitrary channel layout support to Opus (I'll probably send it for FLAC as well) [10:52:46 CEST] <rcombs> I'm intending to use the channel "indexes" from AV_CH_*, which afaik are from MS's dwChannelMask; anyone know if that's defined anywhere generic I can reference, or should I link to MS's WAVEFORMATEXTENSIBLE spec, or copy it wholesale into an I-D? [10:56:26 CEST] <nevcairiel> whats an I-D [10:58:58 CEST] <rcombs> precursor to an RFC [10:59:07 CEST] <rcombs> proposed update to Opus [11:02:05 CEST] <LigH> Hi. [11:02:43 CEST] <LigH> Excuse the slightly indirect question... [11:03:08 CEST] <LigH> Can you imagine any change in libavformat which may have broken compatibility to mplayer? [11:03:25 CEST] <nevcairiel> original mplayer is so old, any change can break it =p [11:03:37 CEST] <LigH> Since about 3 weeks it fails due to redefinition of pollfd. [11:04:27 CEST] <LigH> Sounds like I have to abandon all hope for mencoder. [11:04:43 CEST] <durandal_1707> why you still use it? [11:05:13 CEST] <LigH> It has some more concenient CLI syntax in a few special cases. [11:05:19 CEST] <LigH> *convenient [11:06:37 CEST] <LigH> Well, OK, thanks. [11:06:41 CEST] <JEEB> pollfd? that sounds like !FFmpeg thing [11:07:04 CEST] <LigH> If you are interested in details: https://trac.mplayerhq.hu/ticket/2350 [11:07:28 CEST] <JEEB> anyways, mplayer always had a funky relationship with FFmpeg :P did they ever fix building with external FFmpeg [11:07:29 CEST] <LigH> winsock2 vs. 3dostr [11:08:11 CEST] <LigH> or os_support [11:09:05 CEST] <JEEB> anyways, without further looking I guess this is just mplayer's build system failing with current FFmpeg or mingw-w64 specifically :P [11:09:12 CEST] <LigH> Seems to depend on MSYS2/MinGW; I heard that it builds under Linux/MinGW instead... [11:09:34 CEST] <JEEB> would be surprised, unless the build system is using a different config.h :P [11:09:50 CEST] <nevcairiel> dont they use a pre-defined config.h [11:09:54 CEST] <nevcairiel> no wonder that breaks all the time [11:09:56 CEST] <JEEB> yes [11:09:59 CEST] <JEEB> I would guess that [11:10:00 CEST] <LigH> So I am back to my most discouraging question: Who should I ask, at all? ... ;-) [11:10:14 CEST] <JEEB> go2 #mplayer ? or whatever is their IRC channel [11:10:28 CEST] <JEEB> at this point I think mplayer is a single or two person hobby project [11:10:30 CEST] <LigH> #mplayerdev ... {tumbleweed/crickets} [11:10:51 CEST] <LigH> penvado sleeps in both. [11:10:56 CEST] <JEEB> my condolences then [11:10:59 CEST] <LigH> *pengvado [11:11:28 CEST] <LigH> debianuser tried to help me but got stuck. [11:12:14 CEST] <LigH> OK, back to different tasks. Bye. [11:27:11 CEST] <cone-100> ffmpeg 03Paul B Mahol 07master:b7b3e8c5c759: avfilter: add vibrance filter [11:51:09 CEST] <ubitux> durandal_1707: is it matching adobe photoshop vibrance filter? [11:55:08 CEST] <durandal_1707> ubitux: i dont have adobe photoshop [11:58:44 CEST] <ubitux> ok [12:00:52 CEST] <durandal_1707> ubitux: but it should behave similar for >= 0 intensity and other options untouched, just different scaling [12:54:49 CEST] <January> michaelni: could you UL https://0x0.st/s6-6.h264 as fate/h264/crew_cif_timecode-2.h264 [13:58:11 CEST] <cone-100> ffmpeg 03Zhong Li 07master:0e3d7d845d9b: lavc/qsvenc_jpeg: add async_depth support [13:58:12 CEST] <cone-100> ffmpeg 03Zhong Li 07master:92c25963e8b6: lavc/qsvenc_jpeg: set a default quality [16:59:58 CEST] <kierank> January: gonna push your changes [17:00:14 CEST] <January> timecode? sure [17:01:31 CEST] <cone-100> ffmpeg 03Devin Heitmueller 07master:4241e44a3c01: lavc/h264: create AVFrame side data from H.264 timecodes [17:01:32 CEST] <cone-100> ffmpeg 03Josh de Kock 07master:76a8c3b522bf: h264/pic_timing: support multiple timecodes [17:01:33 CEST] <kierank> waiting... [17:01:33 CEST] <cone-100> ffmpeg 03Josh de Kock 07master:0ac82eed6f9c: lavfi/vf_showinfo: support displaying S12M timecode sidedata [17:01:34 CEST] <cone-100> ffmpeg 03Josh de Kock 07master:3f2103ec73c9: fate: add h264 timecode test [17:01:49 CEST] <kierank> that took a while [17:42:22 CEST] <kierank> January: looks like fate is passing [19:59:12 CEST] <cone-100> ffmpeg 03Dave Rice 07master:110b4a491859: avdevice/sdl2: add option to set window position [19:59:13 CEST] <cone-100> ffmpeg 03Matsuzawa Tomohiro 07master:c2ac3b8e6a04: avformat/libsrt: add several options supported in srt 1.3.0 [20:44:43 CEST] <kierank> does anyone else have the ability to add to fate? [20:44:45 CEST] <kierank> apart from `md [20:44:46 CEST] <kierank> michaelni: [20:52:42 CEST] <jamrial> jkqxz: https://0x0.st/s6Nh.ivf https://pastebin.com/j94dYarf [20:54:55 CEST] <jamrial> redundant frame header obu. seen_frame_header is correctly set to true when it shows up (as per the spec), but cbs is not handling it right [21:01:44 CEST] <michaelni> kierank, you mean add fate samples ? there should be many people who have the rights, but few use them, the process to upload is described in doc/fate.texi [21:02:43 CEST] <kierank> michaelni: can you give January access [21:09:04 CEST] <michaelni> January, i realize now (looking at fate.ffmpeg.org) that you pushed the test with noone uploading the sample, i saw the push and thought someone else uploaded the sample already so i didnt, will double check that the sample isnt there and then uplaod [21:15:27 CEST] <michaelni> January, crew_cif_timecode-2.h264 uploaded. I didnt realize it earlier as i was testing your code and so had manually added the file locally but then when i was done testing saw you already pushed and assumed without checking that the sample was uploaded. Please make sure when you push some new test that all samples it needs have been uploaded by someone before [21:18:39 CEST] <michaelni> and ideally samples should be uploaded 24h before the code, there where some fate clients syncing the samples only once a day [21:41:31 CEST] <kierank> JEEB: lotharkript_ says we can use oss-fuzz do to the h264 bitexact fuzzing [22:49:42 CEST] <atomnuker> peloverde: there's some aac decoder layout patches on the ML, will you have the time to look at them anytime soon? [22:50:00 CEST] <peloverde> yeah, I should have time [22:50:12 CEST] <peloverde> I'll take a look now [23:28:33 CEST] <jkqxz> jamrial: Hmm, yeah. I think I must have misread that when writing it (copy as a verb rather than a noun?), since it currently doesn't look for anything there. [23:28:46 CEST] <jkqxz> Dealing with it is not very fun, since parsing it again would require all of the reference state to be the same as it was at the beginning of the first frame header. [23:30:25 CEST] <jkqxz> Maybe we could save a reference to the first frame header OBU along with bounds in the context, and then just compare the bits if we see another frame header? [23:30:54 CEST] <jkqxz> Or save all of the state before the frame header so that it can be restored if there is another one. [23:34:29 CEST] <jkqxz> nevcairiel: I thought it might have been you who hit it, since you mention it in that old thread. I can't remember where the report came from now. [23:36:18 CEST] <jkqxz> I guess if we don't even know exactly what the problematic case actually is now then just enabling hardware is probably ok. Maybe some poor sod with an old OEM driver and be screwed over by it, but oh well. [23:36:43 CEST] <nevcairiel> its not like the software variant is probably all that good for them either [23:38:15 CEST] <jamrial> jkqxz: a decoder is meant to ignore the redundant frame header (the spec states seen_frame_header must be 1 when those show up) [23:38:16 CEST] <jkqxz> Well, they probably don't have the software one either. The evil case is that any application trying to probe the supported codecs will segfault. [23:38:38 CEST] <jamrial> they show up in between tile groups, when error resilence is used [23:38:49 CEST] <jamrial> they are meant to be bitexact to the actual frame header [23:39:40 CEST] <jkqxz> Perhaps the interesting question is - how should they appear in trace output? [23:40:46 CEST] <jamrial> cbs should fully parse them, so the whole seen_frame_header logic should be used only to make sure the bitstream is correct but not to skip parsing an obu [23:41:18 CEST] <jamrial> "Redundant Frame Header" would look nicer than "Frame Header" [23:42:01 CEST] <jamrial> and being in its own function you can make it have a different seen_frame_header check than for frame and frame header obus [23:45:06 CEST] <jamrial> the spec requires seen_frame_header to be 0 when you parse a frame header obu, but 1 when you parse a redundant frame header obu. otherwise the bitstream is invalid [23:46:55 CEST] <jkqxz> In theory we could be parsing a stream which has lost some packets and therefore the redundant frame header is the one actually being used, though. [23:51:45 CEST] <peloverde> atomnuker: I reviewed 3/3. the others look encoder centric? [23:58:01 CEST] <atomnuker> yeah, I dislike how they're adding even more custom layouts for no good reason, so I'll respond to that soon [23:59:03 CEST] <kierank> michaelni: who has fate write access? [23:59:10 CEST] <kierank> durandal_1707: do you have fate write access? [00:00:00 CEST] --- Wed Oct 24 2018

1 0

ffmpeg.log.20181023
by burek 24 Oct '18

24 Oct '18

[01:07:50 CEST] <dualz> Does anyone know where I can find a good write-up or tutorial on zmq and azmq? [01:17:03 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [02:19:39 CEST] <Zexaron> Hello [02:20:21 CEST] <Zexaron> some guys at linuc claim "ffmpeg uses libav" and pretty much act stupid when I wanted clarification if libav/ffmpeg can be used interchangibly, which I doubt [02:21:07 CEST] <Zexaron> ffmpeg's release, DLLs, headers, API, exes probably aren't compatible to libav, I couldn't use a libav headers with ffmpeg's DLLs in a program right ? [02:21:32 CEST] <Zexaron> Jut to confirm since Im clearing old code from a project which uses it interchangibly, but clearly using only ffmpeg [02:23:24 CEST] <Zexaron> Or the idiot is confusing the libav project with libav source code names [02:23:42 CEST] <furq> it's almost certainly the last thing you said [02:24:32 CEST] <furq> and yeah the APIs have diverged a lot [02:25:19 CEST] <furq> you might be able to swap the libs for some very simple program [02:25:24 CEST] <furq> but generally no [02:26:00 CEST] <Zexaron> Indeed, the split happened quite some time ago, like pre 2010 if im not mistaken ? [02:26:06 CEST] <furq> 2011 [02:26:20 CEST] <Zexaron> ah close [02:28:08 CEST] <Zexaron> Another thing ... [02:28:24 CEST] <Zexaron> went asking in #cmake but nobody was around [02:28:32 CEST] <Zexaron> c/p -ed [02:29:01 CEST] <Zexaron> 1. so the Win64 platform switched over to shared DLLs and has it's own code to check if FFmpeg DLLs are present [02:29:16 CEST] <Zexaron> 2. but I came across some cmake code that sets "HAVE_FFMPEG" bit but i'm not sure what to do, I want to split away Win32/64 away from this linux/osx stuff [02:29:30 CEST] <Zexaron> 3. Here's one of the CmakeLists files https://pastebin.com/X9atYeMZ [02:29:51 CEST] <Zexaron> 4. for win32 entry the path was renamed from "Externals/ffmpeg" to Externals/ffmpeg-win64, since it does not contain any custom prebuilt .lib files anymore, those .lib just point to delay loaded DLLs [02:30:12 CEST] <Zexaron> 5. Would that Win32 entry still be relevant, it does have to point to libs which then point to DLLs for cmake too? [02:31:13 CEST] <Zexaron> - end - i might not have to do much other than to rename HAVE_FFMPEG into HAVE_FFMPEG_NONWIN32 is my currenty observation [09:19:09 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [10:13:40 CEST] <darsain> I'm trying to convert 320kbps mp3 to vbr 1 using ffmpeg, but comparing the same encode with foobar2000 ffmpeg takes more than twice the time (8-10 seconds vs 4 seconds) than foobar2000 to do that [10:13:46 CEST] <darsain> is there some flag I'm not enabling? here are my arguments: [10:13:52 CEST] <darsain> -i file.mp3 -q:a 1 -c:v copy -id3v2_version 3 -f mp3 -y file2.mp3 [12:37:35 CEST] <SortaCore> fellas [12:37:42 CEST] <SortaCore> how do I escape a double-quote in metadata [12:37:53 CEST] <SortaCore> -metadata title="\"thing\"" no work [12:39:13 CEST] <SortaCore> *blows raspberry* no it was missing parts in output filepath [12:39:29 CEST] <SortaCore> missing folder, even tho I told it to create the directory first [12:39:53 CEST] <SortaCore> you may resume normal programming [13:28:22 CEST] <relaxed> darsain: maybe libmp3lame wasn't compiled with nasm [13:29:38 CEST] <darsain> relaxed: I'm using the all in one ffmpeg.exe windows binary. is this a known issue with it? [13:38:54 CEST] <pdm91> video metadata is not copied to the output file. Here is my command "ffmpeg -i in.mp4 -b:v 4000k -minrate 3000k -maxrate 6000k -s 1920x1080 -r 30 -vcodec h264 -acodec aac -map_metadata 0 -metadata:s:v:0 -strict -2 -y out.mp4" [15:06:48 CEST] <zivanovicb> Error: Command failed: ffprobe -v 0 -of csv=p=0 -select_streams 0 -show_entries stream=r_frame_rate, width, height /files/efab270e2f13754e0d4f9458f279799b [15:07:06 CEST] <zivanovicb> Any ideas what could be wrong with this command? [16:11:46 CEST] <dualz> My issue has come up a few times that I can find on google with no good answer [16:12:11 CEST] <dualz> I want to be able to change my inputs on the fly [16:12:25 CEST] <dualz> for a live streaming app I'm working on [16:13:16 CEST] <dualz> What I'm thinking of doing is using libzmq and setting up all my inputs in a movie/amovie filter [16:18:53 CEST] <dualz> then use zmqsend to movie@input_a filename rtmp://new/stream/here [16:19:20 CEST] <dualz> then somehow I'd have to reinit [16:24:17 CEST] <furq> dualz: use the streamselect filter [16:24:46 CEST] <JEEB> lavfi in general is really static though, so it won't handle the dynamic switching though if you go and come back [16:24:57 CEST] <JEEB> I've been wondering of using upipe for that [16:25:11 CEST] <JEEB> (since most of my inputs are broadcast anyways) [16:25:31 CEST] <dualz> hmm [16:25:43 CEST] <dualz> let me check out streamselect [16:25:53 CEST] <furq> yeah if you need to continue through dropouts then ffmpeg alone is no use to you [16:26:35 CEST] <dualz> dropouts I can listen to on my end [16:26:50 CEST] <dualz> and send a msg via libzmq [16:27:11 CEST] <dualz> was the intentions [17:58:42 CEST] <Dudemanguy> Hi, I have some questions about the metadata API and example on the website here: https://libav.org/documentation/doxygen/master/metadata_8c-example.html [17:59:03 CEST] <Dudemanguy> More specifically, I would like to be able to extract metadata from audio files [17:59:26 CEST] <Dudemanguy> From the code there, I would expect the printed output to be all of the metadata contained in file, but this isn't the case [17:59:46 CEST] <Dudemanguy> I'm only able to return the encoder tag for some reason [18:00:00 CEST] <durandal_1707> Dudemanguy: libav.org != ffmpeg.org [18:00:22 CEST] <Dudemanguy> ah wrong channel then? [18:00:45 CEST] <Dudemanguy> apologies [18:07:20 CEST] <Dudemanguy> Oops, I got my libav and ffmpeg links mixed up earlier; but the same example is up on ffmpeg actually: https://www.ffmpeg.org/doxygen/2.7/metadata_8c-example.html [18:08:02 CEST] <Dudemanguy> Anyways just to repeat if neccesary: when I run this code, I'm only able to get the encoder tag from an audio and not any other metadata [18:08:23 CEST] <Dudemanguy> I'm probably just missing something here, but any help on this appreciated [18:09:30 CEST] <durandal_1707> Dudemanguy: and what other metadata you want? [18:09:48 CEST] <Dudemanguy> Anything: ARTIST, ALBUM, etc. [18:10:16 CEST] <durandal_1707> Dudemanguy: does ffprobe show such metadata for same input file? [18:10:32 CEST] <Dudemanguy> yes which is why I'm confused [18:10:55 CEST] <furq> wouldn't stream metadata be in the AVStream [18:14:19 CEST] <Dudemanguy> ah that could be it [18:20:41 CEST] <Dudemanguy> furq: perfect, that did the trick [18:21:05 CEST] <Dudemanguy> just changed fmt_ctx->metadata to fmt_ctx->streams[0]->metadata and I got what I expected [18:21:12 CEST] <Dudemanguy> thanks a ton [19:01:41 CEST] <raytiley> is it possible for ffmpeg to receive an rtmp stream standalone... Like say I an encoder that can send a stream to an rtmp url, can ffmpeg be the receiver? [19:01:48 CEST] <raytiley> or do I need something like nginix-rtmp [19:02:05 CEST] <JEEB> pretty sure the lavf rtmp support is for reading from a server or pushing to a server [19:02:11 CEST] <JEEB> not being a server itself [19:06:19 CEST] <raytiley> kinda what I figured... [19:09:23 CEST] <raytiley> basically I have an RTP / MPEG-TS receiver implementation that is naive and doesn't drop audio if packets are lost... I'm trying to bandaid it by having ffmpeg capture the incoming stream and align it before restreaming it via rtp. Was going to try ingesting rtmp since it's TCP... but since that is not possible, is there a command that will do what I want? [19:10:02 CEST] <furq> iirc you can listen for rtsp but not rtmp [19:10:28 CEST] <furq> if you're just sending it off to another server then that might work [19:11:09 CEST] <raytiley> ffmpeg -i rtp://127.0.0.1:1234 -c:v copy -c:a copy -f mpegts rtp://127.0.0.1:3456 [19:11:13 CEST] <furq> actually i guess rtmp has -listen 1 now so maybe that works [19:11:39 CEST] <furq> neither of them are actually usable as servers but it might work for just restreaming [19:12:13 CEST] <raytiley> furq: thanks, I'll look closer at that option [20:11:16 CEST] <KombuchaKip> furq: The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [20:12:54 CEST] <JEEB> KombuchaKip: personally I just used the libavfilter audio resampling. that way you can just feed the AVFrames from the decoder to it [20:13:11 CEST] <JEEB> although I think swresample should now have an AVFrame based API as well [20:13:53 CEST] <durandal_1707> yes it have avframe api, but perhaps they do not use AVFrames at all [20:14:14 CEST] <JEEB> well the top comment says they decode audio from "any format" which does hint at lavf+lavc [20:14:18 CEST] <JEEB> which would have AVFrames [20:33:03 CEST] <KombuchaKip> JEEB: What would you recommend? [20:40:41 CEST] <JEEB> KombuchaKip: depending on various factors if you're using libavcodec for decoding (And thus receive AVFrames of audio), I'd use the AVFrame API for swresample, or just the avfilter stuff which wraps it [20:41:11 CEST] <KombuchaKip> I am using libav's decoder which I believe is libavcodec. [20:41:26 CEST] <JEEB> yup [20:41:37 CEST] <JEEB> so https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html (or the older version) [20:41:44 CEST] <JEEB> which returns AVFrames [20:41:58 CEST] <JEEB> so it would make sense for you to use AVFrame-based APIs [20:42:56 CEST] <KombuchaKip> JEEB: Which I believe is what I'm doing already? [00:00:00 CEST] --- Wed Oct 24 2018

1 0

ffmpeg-devel.log.20181022
by burek 23 Oct '18

23 Oct '18

[03:28:29 CEST] <philipl> BtbN: Replicated bob as a cuda kernel. now the yadif can begin :-) [06:28:26 CEST] <philipl> BtbN: And I think I have a working cuda yadif. Looks visually identical, and I mostly understand the logic :-P [11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:997f03cd7eb9: avfilter/setparams : update filter description [11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:cfdbefdd90b0: avfilter/setfield, setrange : set color property to auto [11:27:23 CEST] <cone-636> ffmpeg 03Martin Vignali 07master:6953ff714fb6: avfilter/setparams : fix colorspace option [12:52:53 CEST] <BtbN> philipl, interesting. yadif isn't the best, but certainly enough for most uses. [12:53:06 CEST] <BtbN> I'd still like to access nvidias adaptive algorithm from CUDA... [12:53:37 CEST] <BtbN> Or, just use cuvid as a filter, like the API clearly intends, but nvidia never followed up on it [13:11:23 CEST] <cone-636> ffmpeg 03Jun Zhao 07master:cc82402ed399: lavf/vc1test: fix vc1test can't probe some RCV file. [13:11:24 CEST] <cone-636> ffmpeg 03Jun Zhao 07master:18fce29d8f1b: lavf/vc1test: add rcv to vc1test demuxer extensions [14:14:52 CEST] <nevcairiel> the split filter probably needs to forward hardware contexts to its output pads [14:20:32 CEST] <durandal_1707> who is "oromit" ? [14:38:23 CEST] <durandal_1707> who is watching 360 videos a lot? [14:39:18 CEST] <BtbN> read it backwards [14:40:50 CEST] <nevcairiel> does anyone durandal_1707? :p [14:41:25 CEST] <BtbN> Isn't the porn industry the only one making larger use of it? [14:41:34 CEST] <JEEB> vimeo seems to have a bunch of them [14:41:49 CEST] <JEEB> but yea I'm not sure if even standard VLC supports them? [14:43:02 CEST] <JEEB> and if you have a lack of players that really means that not many people are going to watch them. I think youtube's collection of them is probably the largest and the youtube js player will be the most used player :P [14:46:14 CEST] <BtbN> Hm, I don't understand why the split filter doesn't just work for hwframes [14:46:50 CEST] <BtbN> It really is just av_frame_clone as a filter, which is just a helper that calls av_frame_ref, which is used for frames in various hw filters already [15:48:35 CEST] <durandal_1707> should i name 360 filter vr360? it would convert between popular 360 projections [15:50:52 CEST] <iive> vr implies it works with steroscopy, aka could be used for vr headset [15:51:04 CEST] <iive> is that the case? [15:53:36 CEST] <BtbN> In a true 360° video you can create stereoscopy for any angle I guess [15:56:50 CEST] <iive> i thought it is harder, because the image is flat [15:57:54 CEST] <nevcairiel> just being a 360 video doesnt automatially make for proper stereo [15:58:35 CEST] <durandal_1707> filter name can not start with number, so simply naming it 360 is no go. [15:58:36 CEST] <nevcairiel> you can probably fake it by varying angles slightly for each eye, but if you think about looking at the inside of a sphere, its different if you have one central camera, or two slightly offset cameras (ie. eyes) [16:00:57 CEST] <atomnuker> yeah, even if you used 2 360 cameras you'd have 2 perespectives where there's depth [16:04:34 CEST] <durandal_1707> thanks for great help, filter name would be "Perigon_360_UltimateReality" [16:06:24 CEST] <durandal_1707> it must be better & faster than that facebook filter, to be succesfull [16:07:42 CEST] <durandal_1707> why i do not get any feedback? this is important subject! humanity future depends on it! [16:07:59 CEST] <nevcairiel> if our future depends on 360 video, then kill me now [16:21:35 CEST] <January> how would I make sure that a test is only run with threading enabled *and* h264 decoding enabled? [16:26:53 CEST] <philipl> BtbN: I learned this working on the yadif thing. Even if your filter's frame management logic is hwframe safe, you still need to init an hwframes_ctx for the outlink for it to work. [16:27:28 CEST] <durandal_1707> January: HAVE_THREADS ? [16:27:41 CEST] <philipl> So I had to write my own set up code for the links but the core frame logic is literally the same - I just replaced the filter() function. I want to refactor yadif to actual share, rather than copy, that code. [16:28:00 CEST] <atomnuker> philipl: you can ref your input context in case you can do it in-place, though afaik jkqxz had some concerns about inplace hw filters [16:28:25 CEST] <January> durandal_1707: I meant to prevent the test from running at all, but I guess that is a way to fix it as well [16:30:12 CEST] <philipl> atomnuker: You mean modifying the frames in place? That's fair. Not applicable in my particular case, and modification of frame content doesn't work on the nvdec mapped frames, but obviously there are other scenarios where it could be done. [16:31:04 CEST] <durandal_1707> does future vulkan filter allow loading custom shaders? [16:56:05 CEST] <atomnuker> yeah, if I write a filter for it [16:56:27 CEST] <atomnuker> for compute shaders it'll be very easy, as all current filter shaders are compute [16:56:36 CEST] <BtbN> philipl, you should be able to just call make_writable on CUDA frames [16:56:54 CEST] <atomnuker> for 3d (pixel+vertex) the renderpass abstraction functions will need to be extended [16:56:58 CEST] <BtbN> that will do the right thing, even with the mapped cuvid frames [17:00:43 CEST] <philipl> BtbN: good to know [18:08:26 CEST] <ePirat> BtbN, btw I saw you had a repo with the decklink sdk headers [18:08:44 CEST] <BtbN> Needed them for the coverity builds [18:08:53 CEST] <ePirat> BtbN, maybe this is useful to you https://github.com/ePirat/decklink-sdk [18:09:06 CEST] <ePirat> especially in case you care about diffs between versions and such [18:15:14 CEST] <BtbN> I only wanted something to make ffmpeg build again after the minimum version got bumped [19:20:23 CEST] <durandal_1707> michaelni: when will new release be made? [20:05:00 CEST] <michaelni> durandal_1707, when i have time and after as many regressions as possible have been fixed. I just looked at fate and there are quite a few machines with failures. So before thinking of doing a new release i have to look into why some of these fail, i just spoted one that looks like theres something wrong with one of my boxes [20:40:06 CEST] <tmm1> jkqxz: can we commit those cbs fixes [21:43:38 CEST] <cone-636> ffmpeg 03Michael Niedermayer 07master:b737317a8813: avcodec/mpeg4videodec: Fix typo in sprite delta check [21:50:16 CEST] <thebombzen> michaelni: I attached an updated version of my streamcopy patch (with no newline issues). Should I start a new thread on the mailing list with git-send-email? [21:52:01 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/10739/ [21:52:03 CEST] <JEEB> looks good to me [21:52:13 CEST] <JEEB> at least patchwork grokked it [21:52:24 CEST] <JEEB> (not a review, just that it seems to have been received proper) [23:32:33 CEST] <mateo`> jamrial: hello, it looks like 662558f985f50834eebe82d6b6854c66f33ab320 introduced a regression on the mediacodec decoders. The decoder ends up receiving the bitstream in the hvcC form (for hevc) and not annex-b. The underlying bsf seems initialized twice, first time, everything is fine, second time it beleives the bitstream is already annex-b because of the newly replaced extradata (now in annex-b [23:32:35 CEST] <mateo`> form). [23:35:00 CEST] <mateo`> jamrial: any ideas on how to fix that ? I haven't found yet why the bsf is initialized twice (maybe because of avformat_find_stream_info() which opens a decoder) [23:35:23 CEST] <jamrial> mateo`: yeah, it's most likely that [23:36:13 CEST] <jamrial> and no, not really, but this commit brought other issues as well so might as well just revert it [23:36:55 CEST] <jamrial> everything is written expecting extradata to not be altered by libavcodec during decoding. even the doxy [23:37:42 CEST] <jamrial> which even before this change was already wrong, but only on a few decoders instead of all of them like the above commit is doing [23:39:09 CEST] <mateo`> ok ... [23:41:57 CEST] <mateo`> so what is the plan ? revert for now or something else ? [23:43:48 CEST] <jamrial> revert for now, imo. will send an email first [23:44:23 CEST] <mateo`> ok [23:44:27 CEST] <mateo`> thanks [23:55:05 CEST] <BtbN> isn't that a different commit? [23:55:24 CEST] <BtbN> The one on the list is f631c328e680a3dd491936b92f69970c20cdcfc7, according to the initial mail [23:56:06 CEST] <BtbN> hm, f631c3 doesn't even exist [23:57:09 CEST] <nevcairiel> both exist and do the same thing [23:57:10 CEST] <nevcairiel> dont ask me [23:57:20 CEST] <BtbN> git.videoland.org doesn't know about it at least [23:57:21 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f631c328e680a3dd491936… http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=662558f985f50834eebe82… [23:57:25 CEST] <BtbN> -d [23:57:47 CEST] <BtbN> what [23:57:53 CEST] <BtbN> I guess once is merged from libav? [23:58:06 CEST] <nevcairiel> no thats not how merges look [23:58:16 CEST] <JEEB> yea the merge sources also stay [23:58:25 CEST] <JEEB> so if it's not in history then it's just not there [23:58:48 CEST] <JEEB> oh, both exist? [23:59:51 CEST] <nevcairiel> hm apparently one is from libav [00:00:00 CEST] --- Tue Oct 23 2018

1 0

ffmpeg.log.20181022
by burek 23 Oct '18

23 Oct '18

[00:57:14 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [01:36:55 CEST] <SilenceDogood> Hey guys. When I captured some gameplay footage with an external capture card on my PC yesterday, Windows sent it sideways for some reason [01:37:13 CEST] <SilenceDogood> So I want to make an ffmpeg script to rotate it back to being normal [01:37:38 CEST] <SilenceDogood> Currently my script says: ffmpeg -f concat -i files.txt -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k -pix_fmt yuv420p -vf "transpose=2" out.mp4 [01:37:57 CEST] <furq> if you're going to mp4 you might as well just set the rotate metadata and save yourself reencoding [01:38:07 CEST] <SilenceDogood> what [01:38:12 CEST] <SilenceDogood> is that a thing? [01:38:14 CEST] <furq> it is in mp4 [01:38:20 CEST] <furq> -c copy -metadata:s:v:0 rotate=90 [01:38:29 CEST] <SilenceDogood> ooh neat. I will try that [01:38:34 CEST] <furq> ymmv as to whether players support it [01:38:37 CEST] <furq> anything good ought to [01:39:26 CEST] <furq> if you actually want to reencode then transpose should be fine [01:40:56 CEST] <SilenceDogood> furq transpose is changing the resolution [01:41:14 CEST] <SilenceDogood> that's what I came on here to ask about [01:41:33 CEST] <SilenceDogood> It's rotating it while keeping the resolution the same, which creates enormous black bars on what is actually still a vertical video [01:42:12 CEST] <SilenceDogood> what does the -c copy do? [01:42:20 CEST] <furq> remuxes instead of reencoding [01:42:53 CEST] <furq> transpose=2 by itself works fine here [01:43:11 CEST] <furq> you might want to check your source files don't have rotate metadata set [01:43:43 CEST] <SilenceDogood> They are TS files created by the Avermedia Live Gamer Portable capture device [01:43:52 CEST] <furq> nvm then [01:44:25 CEST] <SilenceDogood> furq transpose=2 by itself doesn't work fine here for the reason I stated about the black bars [01:44:41 CEST] <furq> yeah i just tried that here and it changes the resolution as you'd expect [01:45:03 CEST] <SilenceDogood> what was your command ? [01:45:16 CEST] <furq> ffmpeg -f lavfi -i testsrc=s=720x1280:d=1 -vf transpose=2 -f null - [01:45:43 CEST] <furq> that gives 1280x720 output [01:46:42 CEST] <SilenceDogood> OK ... I guess I'll try again and see what happens with that [01:48:07 CEST] <furq> maybe try -vf transpose=2:passthrough=none [01:48:10 CEST] <furq> that should be the default though [01:49:21 CEST] <SilenceDogood> No. Width and height are still crossed [01:49:27 CEST] <SilenceDogood> my current command is: -vf transpose=2:passthrough=none [01:49:28 CEST] <SilenceDogood> oops [01:49:30 CEST] <furq> weird [01:49:44 CEST] <SilenceDogood> ffmpeg -f concat -i files.txt -c:v libx264 -preset slow -crf 18 -c:a aac -b:a 192k -pix_fmt yuv420p -vf transpose=2:passthrough=none -t 5 out.mp4 [01:49:48 CEST] <SilenceDogood> That's my current command [01:49:52 CEST] <SilenceDogood> I'm trying to make a YouTube-ready file [01:49:59 CEST] <Hello71> doesn't youtube have an editor [01:50:08 CEST] <SilenceDogood> it sucks [01:50:08 CEST] <furq> i'm pretty sure youtube respects rotate metadata [01:50:17 CEST] <Hello71> like, they killed the annotation editor claiming that the youtube editor does everything [01:50:23 CEST] <SilenceDogood> OK I'll just try adding the metadata [01:50:25 CEST] <furq> and it'll definitely take whatever your capture card produces [01:50:28 CEST] <furq> so that's probably going to be easier [01:50:40 CEST] <Hello71> have you considered just capturing with ffmpeg [01:50:44 CEST] <SilenceDogood> Yeah. This isn't actually the capture card's fault. This is windows fault [01:51:13 CEST] <Hello71> if you capture to mkv you can play the file while recording to check that it's working [01:51:38 CEST] <SilenceDogood> I rotated the screen briefly before I started playing to hit an "OK" button that was a little too far off screen, and for some reason, when I rotated back Windows didn't change it for the capture card [01:51:58 CEST] <furq> oh i was assuming you were playing some vertical layout arcade game [01:52:04 CEST] <furq> i was hoping it'd be something good [01:52:24 CEST] <SilenceDogood> Hello71, If I was going to use my computer's resources to capture then I wouldn't have spent money on an external capture card, now would I. [01:52:37 CEST] <furq> ffmpeg can work with some capture cards [01:52:39 CEST] <furq> i doubt it works with this one though [01:52:50 CEST] <Hello71> oh, you said the model [01:53:20 CEST] <furq> i guess it'd probably work with vfwcap actually [01:53:21 CEST] <SilenceDogood> I'll see if adding metadata does the trick [01:53:23 CEST] <Hello71> afaik it's usually cheaper to buy a better cpu and then just run x264 ultrafast lossless in the background [01:53:34 CEST] <Hello71> not even considering that you can use the cpu for other stuff [01:53:36 CEST] <furq> or nvenc [01:53:52 CEST] <SilenceDogood> This is a laptop [01:54:03 CEST] <furq> if it's a recent laptop it'll probably have quicksync [01:54:15 CEST] <furq> or nvenc if it has a mobile nvidia gtx [01:54:41 CEST] <SilenceDogood> Laptop model: ASUS Q551LN-BBI706 [01:54:41 CEST] <SilenceDogood> http://www.asus.com/supportonly/Q551LN/HelpDesk_Manual/ [01:55:25 CEST] <SilenceDogood> At the time I bought it, this model was the most powerful convertible laptop (turns into a tablet) for gaming that was available. [01:55:36 CEST] <furq> no nvenc but it has quicksync [01:55:43 CEST] <SilenceDogood> To get more power, I'd have to give up the convertible feature and I don't wanna [01:55:46 CEST] <furq> i forget if qsv has a lossless mode though [01:55:56 CEST] <furq> but if it's going to youtube anyway then it doesn't matter too much [01:56:34 CEST] <SilenceDogood> I like how with a capture card, I can guarantee that absolutely zero percent of my CPU is being used for capturing [01:56:51 CEST] <SilenceDogood> This thing plugs into a USB port only for power [01:57:18 CEST] <SilenceDogood> Can't blame anything in game performance on the capturing [01:58:40 CEST] <SilenceDogood> furq that metadata thing you said must be wrong [01:58:44 CEST] <SilenceDogood> VLC doesn't recognize it [01:59:18 CEST] <furq> what version [01:59:35 CEST] <SilenceDogood> of VLC? [01:59:37 CEST] <furq> yeah [01:59:37 CEST] <furq> 2.1 and earlier don't support rotate metadata iirc [02:00:17 CEST] <SilenceDogood> i am grabbing latest right now to be sure [02:00:37 CEST] <furq> i mean if you're going to upgrade then upgrade to mpv [02:01:33 CEST] <SilenceDogood> Latest doesn't recognize it either. [02:01:49 CEST] <SilenceDogood> If I were a betting man, I'd say mpv doesn't either. [02:07:19 CEST] <SilenceDogood> Yeah this right here totally creates black bars ffmpeg -i 201810201906180.ts -vf transpose=2 -t 5 out.mp4 [02:07:48 CEST] <Hello71> I am a betting man, I bet you're doing it wrong [02:10:09 CEST] <SilenceDogood> Hello71 I just pasted the exact command [02:10:26 CEST] <Hello71> what version of ffmpeg are you using [02:10:31 CEST] <SilenceDogood> also, the command furq mentioned earlier does nothing. ffmpeg -f lavfi -i testsrc=s=720x1280:d=1 -vf transpose=2 -f null - [02:10:54 CEST] <Hello71> given that I think vlc 2.1 is also ancient [02:11:18 CEST] <SilenceDogood> ffmpeg version N-92202-gf72b9904fe [02:12:27 CEST] <SilenceDogood> What is so hard about making a windows installer for the developers of mpv [02:12:42 CEST] <furq> https://mpv.srsfckn.biz/ [02:14:46 CEST] <SilenceDogood> Apparently, there is no such thing as players that support this mp4 rotation metadata. VLC doesn't. MPV doesn't. Windows Media Player doesn't. Either the command you suggested is wrong or the feature does not exist. [02:19:32 CEST] <SilenceDogood> No offense meant furq but it seems like everything you say is wrong. You haven't said one correct thing so far as far as I can tell. [02:20:50 CEST] <SilenceDogood> If a video format documents a feature which exactly zero players support then the feature doesn't exist. [02:21:40 CEST] <SilenceDogood> https://mpv.srsfckn.biz/ does not have installers. It has builds but not installers. [02:22:03 CEST] <SilenceDogood> Which means I can use mpv but I can't recommend it to tech illiterate people [02:27:11 CEST] <Hello71> command works fine for everybody else [02:27:14 CEST] <Hello71> seems just not working for you [02:28:25 CEST] <SilenceDogood> Whatever you think the command is doing for you, it isn't. [02:28:46 CEST] <SilenceDogood> If I use -s 1280x720 then I get a result that is letterboxed on all four sides [02:32:14 CEST] <SilenceDogood> I think I know what the problem is [02:32:18 CEST] <SilenceDogood> My original video is letterboxed [02:32:18 CEST] <Hello71> you used -s? [02:32:39 CEST] <SilenceDogood> The capture card must be designed to only work in portrait mode [02:33:10 CEST] <SilenceDogood> so getting a sideways video caused it to record in portrait mode and letterbox [02:33:23 CEST] <SilenceDogood> I mean in landscape mode. gaaah [02:33:47 CEST] <SilenceDogood> The capture card must be designed to only work in landscape mode so when it gets a portrait video, it letterboxes it into a landscape recording [02:33:58 CEST] <SilenceDogood> This means I have to crop [02:34:08 CEST] <SilenceDogood> and will take a severe quality hit [02:47:30 CEST] <SilenceDogood> oh well, at least I solved the mystery. thanks for trying you guys [03:17:00 CEST] <CrystalMath> hi, is there any way to treat a local file as a stream? [03:17:08 CEST] <CrystalMath> as in, treat it as a file that is constantly growing in size [03:17:13 CEST] <CrystalMath> because it is such a file [03:35:04 CEST] <Hello71> tail -f [03:35:08 CEST] <Hello71> there's probably a better way [03:41:14 CEST] <CrystalMath> any way for tail -f to start from the beginning? [04:21:28 CEST] <Hello71> -c +0 [04:34:47 CEST] <JC_Yang> what is [04:45:37 CEST] <leif> Is there any reason avformat_open_input would return NULL for the AVFormatContext argument, but there was no error? [04:45:45 CEST] <leif> (or at least the function's return value was 0) [05:08:46 CEST] <CrystalMath> Hello71: thank you :) sorry for not responding, i found the answer in the manual and stopped checking IRC [05:08:53 CEST] <CrystalMath> i used -n +0 [05:09:22 CEST] <Hello71> if performance doesn't really matter that's probably good enough [05:10:00 CEST] <Hello71> also that will probably add a good deal of latency [05:10:38 CEST] <CrystalMath> hmm..... yeah i didn't think much [05:10:42 CEST] <CrystalMath> i need a command fast [05:10:49 CEST] <CrystalMath> *needED [05:11:04 CEST] <CrystalMath> it was a live stream [06:00:13 CEST] <JC_Yang> I'm investigating a bug found in my app using ffmpeg 4.0.2. In matroskaenc.c, line 2352, why the ts_offset of track need to be added again to formed the cluster time? ts has added the ts_offset already in line 2349. I'm not familiar to mkv, these codes seems weird to me, so I'm questioning here [06:19:23 CEST] <th3_v0ice> Where can I find the information about the number of references for a given AVPacket? [08:57:20 CEST] <bmu> Hi guys! Is this channel alive so I can ask a question? [08:59:41 CEST] <Zexaron> just ask, somtimes you have to wait [09:11:13 CEST] <bmu> Thanks. I'm using libav and trying to make a sort of a video player. What I'm doing is "call [avcodec_receive_frame], queuing frames, and consuming each frame in another thread (like in ffplay.c manner). What I'm worried about is, as long as I know, even though `av_frame_alloc` is called only once(at initialization stage), since frame->data is not actually allocated yet and [09:11:27 CEST] <bmu> it will be allocated and freed everytime when `avcodec_receive_frame` is called, so I think there's a performance issue. So here's what I want to know is, (1) Is that right frame data is allocated and freed everytime when `avcodec_receive_frame` is called as I mentioned? (2) If then, is there any solution to prevent everytime-allocation like using MemoryPool? [14:13:21 CEST] <th3_v0ice> Is there any particular reason why would I see 150MB memory rise when I open the output file via API? [14:13:54 CEST] <JEEB> depends on the format etc. also if you're doing probing or not [14:23:49 CEST] <th3_v0ice> Format is FLV, how can I check if the probing is on? [14:24:07 CEST] <JEEB> you would call the function yourself [14:24:18 CEST] <JEEB> avformat_find_stream_info [14:24:20 CEST] <JEEB> specifically [14:24:26 CEST] <JEEB> without that IIRC it doesn't do probing [14:24:42 CEST] <JEEB> oh, output file? [14:24:48 CEST] <th3_v0ice> Yes [14:25:07 CEST] <JEEB> dunno then, that sounds like an awful amount of overhead. are you sure it's from that specifically? [14:25:14 CEST] <JEEB> of course after you feed a muxer stuff [14:25:21 CEST] <JEEB> it might buffer that depending on the container [14:25:25 CEST] <BtbN> Also, are you sure you aren't just looking at virtual memory? [14:25:29 CEST] <JEEB> and then there's the IO buffering possibly [14:25:36 CEST] <th3_v0ice> Nothing else is allocated at that particular moment in time. [14:25:37 CEST] <JEEB> and yes, virtual memory [14:26:04 CEST] <th3_v0ice> Its also just opening, not feeding anything to the muxer. [14:28:42 CEST] <Woodpecker> I have integrated ffmpeg into my Qt (c++) program via the command line options (QProcess). Is it possible or recommended that I use libraries instead? My purposes are fairly rudamentary: [14:30:56 CEST] <Woodpecker> concatenate forground audio track. concatenate background audiotrack. Overlay both audiotracks. Overlay a video undo said track. [14:31:11 CEST] <Woodpecker> unto* [14:33:08 CEST] <JEEB> using the API would let you do a lot of decisions before you run stuff, like indexing the input audio tracks to know if you have to do anything special for them [14:33:34 CEST] <JEEB> also ffms2 might provide you a simplified API around indexing and loading video or audio frame-exactly [14:33:41 CEST] <JEEB> that uses the FFmpeg APIs in the background [14:35:17 CEST] <durandal_1707> i doubt that is needed [14:35:53 CEST] <JEEB> it really depends [14:36:30 CEST] <JEEB> also in general the API usage will let you do various stuff without first calling ffprobe on all of your inputs etc [14:36:40 CEST] <JEEB> be it ffms2 or standard FFmpeg APIs [14:44:35 CEST] <Woodpecker> JEEB: A simplified API does seem ideal. It does need to have MP3 support, which is probably troublesome given that it only was recently made open source. [14:44:54 CEST] <JEEB> uhh, what [14:45:13 CEST] <JEEB> mp3 aka mpeg-1 layer 3 has been a standard for quite a while [14:45:25 CEST] <BtbN> like, a 20+ years while [14:45:26 CEST] <JEEB> heck even the patents have expired for it by now :P [14:45:46 CEST] <Woodpecker> okay okay ;) [14:45:47 CEST] <JEEB> also the patents etc never stopped people from implementing it [14:46:04 CEST] <Woodpecker> I thought there was licensing issues around it, anyway [14:46:47 CEST] <JEEB> yes, if you are planning on distributing commercial software you generally want to check up on what licensing you'd have to pay for when distributing binaries [14:46:51 CEST] <JEEB> that's 100% separate to FFmpeg etc [14:46:52 CEST] <JEEB> though [14:46:57 CEST] <JEEB> patent licensing and such [14:47:28 CEST] <JEEB> FFmpeg generally doesn't really give a darn, and implements standards as they come and needs come for them to be implemented [14:47:35 CEST] <BtbN> mp3 is pretty much free to use by now though [14:47:36 CEST] <JEEB> we don't distribute official binaries [14:47:48 CEST] <JEEB> yes, mp3 specifically was even OK'd by red hat by now [14:47:54 CEST] <JEEB> not that this is legal advice in any sense [14:47:57 CEST] <BtbN> But I'd still rather just use opus. Better in almost every aspect, with compatiblity being the only weak point [14:48:40 CEST] <Woodpecker> interesting to say the least. Id like to use opus, but I had serious issues when I placed it into an mp4 container and uploaded it to youtube. [14:48:55 CEST] <JEEB> if you upload to youtube you don't really care [14:49:13 CEST] <JEEB> just push something lossless up and be done with it, more or less [14:49:20 CEST] <BtbN> I don't think mp4 supports opus? [14:49:34 CEST] <JEEB> there's a draft that both google and mozilla want to finish [14:49:55 CEST] <JEEB> pretty sure FFmpeg can mux that already [14:50:06 CEST] <BtbN> https://www.chromestatus.com/feature/5100845653819392 yeah, looks like it's a thing already in a half-official state [14:50:15 CEST] <BtbN> still, just don't use mp4 [14:50:50 CEST] <JEEB> seems like they didn't copy over the latest additions to opus's site https://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html [14:51:45 CEST] <JEEB> but yes, opus in mp4 is not considered final yet even though various tools can create it already [14:51:59 CEST] <Woodpecker> BtbN: My reasons for using MP4 was that it was a container that I could create a slideshow in using ffmpeg, that would have virtually no rendering time. I am definitely open to any container that achieves this. [14:52:26 CEST] <BtbN> Why does the container matter for that? [14:54:32 CEST] <Woodpecker> BtbN: I dont know. All I know is that I played around with a bunch of containers on ffmpeg, using the slideshow feature, and MP4 was the only one I could find that would create an hour long video with about 80 slides, in about 4 seconds. [14:55:01 CEST] <Woodpecker> Matroska took something like 3 hours. [14:55:13 CEST] <BtbN> I don't see how the container is related to that at all. Do you mean you are making a video with ultra low fps? [14:55:55 CEST] <Woodpecker> BtbN: Yeah. Its a slideshow with no transitions at this point. [14:56:11 CEST] <Woodpecker> here its better to give an example, one sec, [14:56:17 CEST] <BtbN> That might be a problem with certain containers when your fps gets lower than their timebase [14:58:06 CEST] <Woodpecker> BtbN: https://www.youtube.com/watch?v=UZFpsanl5WY << This is a video I made with FFMPEG on the commandline. It probably took something like 30 seconds of render time on all the steps combined. [14:59:26 CEST] <BtbN> You can always just use two fps filters in a row, one that converts to your 1/60 or whatever frames a second, and one that goes back to 60. Then use libx264 with super long gops, and you will still ger a very small video [14:59:39 CEST] <BtbN> As most frames are identical [15:02:23 CEST] <Woodpecker> BtbN: Interesting. Now it is just a matter of what library to import into my qt program, and to learn the API. [15:02:52 CEST] <BtbN> YouTube will do that anyway I guess [15:03:09 CEST] <JEEB> yes, youtube will convert your VFR to CFR [15:03:19 CEST] <JEEB> just to normalize all of its input [15:03:29 CEST] <BtbN> That Youtube link therte is 720p6 [15:03:34 CEST] <BtbN> 6, not 60 [15:03:41 CEST] <JEEB> oh, fun [15:03:46 CEST] <JEEB> I guess if it's CFR [15:56:57 CEST] <kuznetsss> Hello, I am writing C++ application to convert images into H264 video. My application works fine but it doesn't include part of the input images to the end of the output video. [15:57:16 CEST] <kuznetsss> I have found same problem on Stack Overflow: https://stackoverflow.com/questions/17811987/encoded-images-into-h264-video… [15:58:18 CEST] <kuznetsss> Is such solution right or it is just hack? [15:58:56 CEST] <BtbN> That solution from the answer is pretty much nonsense. Encoders don't skip images [15:59:52 CEST] <BtbN> Missing images at the end usually mean that you are not properly flushing the encoder [16:01:52 CEST] <JEEB> with ffmpeg.c you have the funky "vsync" logic but with API usage you skip that [16:02:05 CEST] <JEEB> so everything you pass through should end up in output, as long as you flush the encoder :) [16:02:53 CEST] <kuznetsss> To flush the encoder I should use NULL instead of the packet in av_interleaved_write_frame()? [16:03:53 CEST] <JEEB> I think that's muxing [16:04:03 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [16:04:05 CEST] <JEEB> this is encoding [16:04:45 CEST] <JEEB> but yes, you should also check if there's similar for muxing, which there might be due to some buffering on that side depending on the exact muxer [16:06:17 CEST] <kuznetsss> OK, thanks, I will try to flush buffers [16:55:03 CEST] <King_DuckZ> hi, I've been trying to pin down a bug in my code and I just realised it comes from this: avcodec_find_encoder_by_name("prores_ks")->name == "prores_ks" <- ok [16:55:43 CEST] <King_DuckZ> avcodec_find_encoder( avcodec_find_encoder_by_name("prores_ks")->id )->name == "prores" <- wtf? [17:13:01 CEST] <kuznetsss> JEEB, BtbN flushing buffers doesn't help [17:15:21 CEST] <kuznetsss> Encoder prints warning when flush occurs: [libx264 @ 0x5561ba24b780] non-strictly-monotonic PTS [17:17:20 CEST] <Zexaron> Hello [17:17:34 CEST] <Zexaron> any ideas what this Delayed Frames are? https://github.com/dolphin-emu/dolphin/commit/8fb2eb889d576fb3b298e68f07f7d… [17:17:47 CEST] <Zexaron> something to do with the ffmpeg internal buffer? [17:18:25 CEST] <King_DuckZ> kuznetsss: I had that problem already, you need to set your pts right when you encode [17:18:37 CEST] <Zexaron> that should just gracefully encode when render stops, no need to cut it short or anything [17:20:30 CEST] <kuznetsss> King_DuckZ: I use av_packet_rescale_ts() to set pts inside packet [17:21:52 CEST] <King_DuckZ> kuznetsss: ok, double check that you are increasing the video frame pts too [17:24:17 CEST] <King_DuckZ> kuznetsss: my problems were I forgot to do ++frame->pts and I wasn't using av_packet_rescale_ts() iirc, I'm checking my code now but that's all I remember [17:24:46 CEST] <King_DuckZ> it's been months since I dealt with that... but I remember it was horrible [17:27:00 CEST] <kuznetsss> King_DuckZ: Thanks, the pts of my frames is ok. There is no frame when I do the encoder flushing. [17:49:29 CEST] <King_DuckZ> ok I fixed my code by getting rid of the id and carrying around the codec string name instead, but imho it's a bit dodgy the result of the statement I typed [17:50:24 CEST] <JEEB> yea, you are bound to get whatever gets picked first for a specific codec id [17:50:33 CEST] <JEEB> like for prores you have two separate encoders [17:50:37 CEST] <JEEB> at the very least [17:55:58 CEST] <King_DuckZ> imo, there should be a way to go in both directions reliably [17:56:09 CEST] <King_DuckZ> like codec_id and sub_id or something [17:57:48 CEST] <JEEB> but yea, you first grabbed prores_ks, then you grabbed the codec id (generic "prores" identifier), and then you asked for prores and the default is the one without suffix which equals the _aw one [17:58:00 CEST] <JEEB> you can either keep the AVCodec struct around [17:58:12 CEST] <JEEB> or use the name [17:58:23 CEST] <JEEB> it's the same for other things which have multiple encoders for a single format [18:15:42 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [19:10:06 CEST] <gsuberland> I'm encoding an extremely large (250GB) UHD resolution 60fps raw AVI into x264 and am getting an unusual performance behaviour. The ffmpeg process appears to read a chunk of data from disk, then process it, then go back and read from disk again. Is this behaviour expected, rather than overlapped IO? (Windows, x64) [19:10:50 CEST] <gsuberland> the CPU usage goes from ~5% for 2 seconds, back up to ~50% for a second or so, and repeats this pattern. [19:11:22 CEST] <gsuberland> this is resulting in a speed of about 0.068x [19:12:26 CEST] <Mavrik> Sounds about right yeah [19:12:46 CEST] <Mavrik> IIRC the file sources read on demand directly without separate threads [19:12:58 CEST] <gsuberland> so no overlapped IO? [19:51:12 CEST] <brimestone> Hey guys. I'm hope to use libav on my Darwin project. Is this the channel to shoot these questions? [19:51:41 CEST] <JEEB> for the libav* APIs, yes [19:52:14 CEST] <brimestone> got it, 1st question. Where I can get the libav static libraries? [19:52:30 CEST] <JEEB> there are no official binaries [19:52:52 CEST] <JEEB> the FFmpeg site does link to some binaries, which were selected by someone editing the page [19:53:16 CEST] <JEEB> those binaries generally tend to be all-inclusive, though [19:53:23 CEST] <JEEB> so their license generally is GPLv3+ [19:53:35 CEST] <JEEB> rather than LGPLv2.1+ or GPLv2+ [19:53:55 CEST] <brimestone> I see. I can find my way around using C in Xcode Swift project, but I'm getting lost including stuff like avformat.h and the like [19:54:55 CEST] <JEEB> which headers you need depends on which features you require. examples and the doxygen help with that [19:55:07 CEST] <JEEB> generally what people do is they build FFmpeg and then set --prefix [19:55:32 CEST] <JEEB> and when they build something against that FFmpeg, you use pkg-config (usually provided by pkgconf nowadays) to read the provided pc files [19:55:43 CEST] <brimestone> Libav/avformats.h, avfilter.h [19:55:46 CEST] <JEEB> which would then tell your linker etc where to look for those files [23:00:21 CEST] <^Neo> hello friends, if I add avpacket side data, will I get it in the avframe corresponding to the packet? [00:00:00 CEST] --- Tue Oct 23 2018

1 0

ffmpeg-devel.log.20181021
by burek 22 Oct '18

22 Oct '18

[12:52:36 CEST] <cone-600> ffmpeg 03Paul B Mahol 07master:0939c33b54db: avfilter/af_afir: calculate group delay too [12:56:58 CEST] <cone-600> ffmpeg 03kjeyapal(a)akamai.com 07master:f848d384dd36: avformat/dashenc: Support HTTP Persistent for master.m3u8 as well [12:56:59 CEST] <cone-600> ffmpeg 03kjeyapal(a)akamai.com 07master:e715b8e10d0d: avformat/dashenc: URL close unconditionally after DELETE segments [12:59:49 CEST] <cone-600> ffmpeg 03Paul B Mahol 07master:18d391cffee3: avfilter: add chromahold filter [17:14:30 CEST] <durandal_1707> what i shouldn't do next? [17:33:18 CEST] <atomnuker> you totally shouldn't do a motion follow filter (that panorama video->image thing) [17:48:38 CEST] <durandal_1707> atomnuker: that is very hard, and subject of active research [17:50:26 CEST] <iive> doesn't the stabilize filter support that? [17:53:44 CEST] <philipl> deinterlacer as a vulkan filter [17:53:53 CEST] <philipl> definitely don't do that [17:54:51 CEST] <atomnuker> well, I'd definitely prefer for it to be a vulkan filter [17:55:18 CEST] <atomnuker> but I'm not sure how well that would work [17:55:24 CEST] <philipl> I assumed we were secretly encouraging him to do things :-) [17:55:48 CEST] <atomnuker> if hwaccels supply what ffmpeg uses (2 fields in 1 frame) then it'll be efficient [17:56:04 CEST] <philipl> I believe they all do. [17:56:26 CEST] <atomnuker> since you could do a single frame in place and only have to allocate a single new other frame (in case you're doubling the framerate, which you should be) [17:57:30 CEST] <atomnuker> speaking of hwcontext_vulkan, I see finally the modifiers extension has been merged [17:57:44 CEST] <philipl> yay [17:57:59 CEST] <atomnuker> I should update the patchset with the comments from last month [17:58:15 CEST] <atomnuker> grr, I'll have to install nvidia binaries to make sure vf_avgblur still works [17:58:59 CEST] <atomnuker> because I can still crash the gpu on intel because mesa can't test because nothing exists which uses the multiplane stuff [17:59:58 CEST] <jamrial> atomnuker: if it will require a recent vulkan release, make sure the configure checks are correct [18:02:10 CEST] <durandal_1707> michaelni: does upstream ilbc code have that same bug? [18:15:55 CEST] <michaelni> durandal_1707, dont know but the webrtc ilbc code IIRC had some check for the start [20:23:52 CEST] <philipl> BtbN: I have just written the world's worst bob deinterlacer for cuda (just using memcpys) [20:24:19 CEST] <BtbN> oh god [20:24:39 CEST] <BtbN> I kinda want any future CUDA filters to be Vulkan instead [20:24:53 CEST] <BtbN> But no idea how far the Vulkan infra itself is [20:24:57 CEST] <philipl> The import/export restrictions make that awkward. [20:25:04 CEST] <philipl> You can't export from cuda to vulkan [20:25:17 CEST] <philipl> that means you always have to do a copy to transfer data into the vulkan filter [20:25:29 CEST] <philipl> import the vulkan buffer/surface to cuda, then copy over. [20:25:46 CEST] <BtbN> Isn't the API supposed to support mapping? [20:25:54 CEST] <philipl> Yes, but it's import-to-cuda mapping [20:26:07 CEST] <philipl> It's great for writing a cuda filter against a vulkan input... [20:26:23 CEST] <philipl> This is, no doubt, deliberate on nvidia's part. [20:27:30 CEST] <philipl> As for me, I now at least have a working skeleton for a deinterlacer. I took the field->frame logic from vf_yadif and ripped out the processing. [20:27:58 CEST] <BtbN> CUDA filters are always going to be non-free, so I'm not sure how worth it that is [20:28:57 CEST] <philipl> In so far as they are not GPL compatible, yes. But they are LGPL compatible based on how configure works and I think that's legally defensible. [20:29:12 CEST] <BtbN> nope, they are not even LGPL compatible [20:29:33 CEST] <BtbN> cuda-sdk hard-enforces non-free [20:29:41 CEST] <philipl> It probably should not. [20:29:56 CEST] <BtbN> Looking at the license in those headers and on the libs, it should [20:30:06 CEST] <philipl> kernel loading api can be put in the dynloader (I intend to) and then you'd be saying nvcc output is inherently non-free which doesn't seem right [20:30:34 CEST] <BtbN> Those are a lot of functions to put in the dyn-loader [20:30:46 CEST] <philipl> It's a hard life. [20:30:59 CEST] <BtbN> To the point where it becomes more than just questionable if they are really obtained in a way that's considered free [20:32:46 CEST] <BtbN> It's also not about nvcc, but the license you have to accept in order to get nvcc. I would not call that (L)GPL compatible in any way [20:40:27 CEST] <philipl> BtbN: *sigh*. Well, you work with what you've got. [20:41:50 CEST] <JEEB> I would guess since vaapi has egl compatibility there's no problem with vulkan filters there [20:42:01 CEST] <JEEB> not straight vulkan but at least within VRAM in that case [20:42:29 CEST] <philipl> vaapi can export. [20:42:39 CEST] <JEEB> then for nvidia I thought for decoding there was some compatbitiliy, otherwise the gpu renderer wouldn't do crap [20:43:08 CEST] <philipl> You export a dmabuf and there's a vulkan extension to import it. And a bunch of silliness around describing the memory layout that is only just now sorted out. [20:44:07 CEST] <philipl> the cuda interop is one way. So I wrote the mpv code to import the buffer (later image) from vulkan and fill it in from the cuda side. [20:45:31 CEST] <philipl> amusingly/ironically, the cuda EGL interop does appear to let cuda export. It's the only API where they've done that. [21:36:54 CEST] <philipl> BtbN: That ticket is weird. [21:36:59 CEST] <philipl> I can't repro. It compiles fine for me. [21:37:23 CEST] <BtbN> Do you have --enable-cuda-sdk? [21:37:32 CEST] <philipl> No. Just enable-npp in this case [21:37:46 CEST] <philipl> But the cuda headers are installed. [21:37:46 CEST] <BtbN> shouldn't matter anyway [21:37:49 CEST] <philipl> yeah [21:37:58 CEST] <philipl> Might be a cuda 10 difference. [21:38:11 CEST] <BtbN> I upgraded my sdk to cuda 10 now [21:38:13 CEST] <BtbN> let's try again [21:44:43 CEST] <BtbN> What's the proper syntax to do this: --extra-cflags='-IC:/Program\ Files/NVIDIA\ GPU\ Computing\ Toolkit/CUDA/v10.0/include' [21:44:49 CEST] <BtbN> no matter how I try to escape it, it always fails [21:46:06 CEST] <BtbN> It always splits the arguments on the spaces [21:46:47 CEST] <philipl> Don't use \ if you are quoting [21:46:51 CEST] <philipl> One or the other right? [21:47:02 CEST] <BtbN> The quoting is in my local shell though [21:47:06 CEST] <BtbN> that part works [21:47:14 CEST] <BtbN> But configure passes it to cl.exe unquoted [21:47:37 CEST] <philipl> Well, you're firmly in windows land with that :-P [21:48:01 CEST] <philipl> I'm about to try on linux with cuda 10 sdk [21:48:09 CEST] <BtbN> I'll just make a junction at C:\CUDA... [21:49:54 CEST] <philipl> brute force solution [22:00:12 CEST] <philipl> BtbN: Replicated problem [22:00:32 CEST] <philipl> Seems cuda 10 specific. [22:02:12 CEST] <cone-262> ffmpeg 03Martin Vignali 07master:02ad0416c06e: avfilter/setparams : merge setfield and setrange filter to setparams filter [22:02:12 CEST] <cone-262> ffmpeg 03Martin Vignali 07master:8d3f364630a8: avfilter/setparam : add options to set color primaries, trc, space [22:02:56 CEST] <philipl> BtbN: and to add insult to injury, nvcc is complaining that my gcc is too new. requires gcc-7. WTF [22:03:07 CEST] <JEEB> lol [22:03:19 CEST] <BtbN> philipl, try replacing the hwcontext_cuda_internal.h include with just hwcontext_cuda.h in... pretty much all cuda filters [22:03:33 CEST] <BtbN> that seems wrong, the internal means avutil internal [22:04:12 CEST] <philipl> yeah. I suspect that's it. [22:04:35 CEST] <tmm1> is there any central place for offering ffmpeg feature bounties? [22:04:47 CEST] <philipl> BtbN: but it needs internal for cudl functions. [22:04:59 CEST] <JEEB> tmm1: the thing closest to that is the videolan.org bounties page [22:05:11 CEST] <philipl> scale_npp doesn't use system cuda headers, but it kinda should, as they're going to be there. [22:05:20 CEST] <JEEB> although I guess those are for stuff that go through videolan [22:05:25 CEST] <BtbN> philipl, those don't do dyn-loading [22:05:31 CEST] <BtbN> and we don't link against -lcuda [22:05:33 CEST] <JEEB> https://wiki.videolan.org/Bounties [22:05:34 CEST] <BtbN> so it has to use ffnvcodec [22:05:59 CEST] <JEEB> tmm1: otherwise FFmpeg specific I don't think we have a bounty page yet [22:06:13 CEST] <JEEB> could have one on a write-limited trac wiki page, if there's such a thing [22:06:21 CEST] <philipl> BtbN: Ok. Well, then I need to conditionalise the type declaration? [22:06:42 CEST] <BtbN> I have no idea, it might be outright impossible to add that type without giving it a different name on our end [22:07:27 CEST] <BtbN> everything compiles fine on MSVC with CUDA 10 and the _internal removed [22:08:01 CEST] <BtbN> hm, it just didn't enable the npp stuff, what [22:08:06 CEST] <BtbN> oh, nvm [22:12:31 CEST] <philipl> BtbN: I guess I'll just give it a different name then. [22:12:40 CEST] <philipl> Annoying. [22:14:22 CEST] <philipl> And I'd have to change the mpv code too. grr. [22:14:28 CEST] <philipl> but that's not merged yet. OK [22:14:51 CEST] <BtbN> I'm not a fan of renaming it [22:15:11 CEST] <philipl> If you can think of an alternative, I'm all ears. [22:15:35 CEST] <philipl> We could try and separate the declaration from the typedef [22:15:53 CEST] <philipl> but in this error, it's already complaining the typedef is not the same. [22:16:08 CEST] <JEEB> at some point I'd like to see people try to push nvidia to make all this mess less of a mess :P [22:16:21 CEST] <BtbN> This isn't really nvidias fault [22:16:36 CEST] <JEEB> yes, but the whole reason why we're reinventing headers etc [22:20:51 CEST] <philipl> * CUDA UUID types [22:20:52 CEST] <philipl> */ [22:20:52 CEST] <philipl> #ifndef CU_UUID_HAS_BEEN_DEFINED [22:20:52 CEST] <philipl> #define CU_UUID_HAS_BEEN_DEFINED [22:21:01 CEST] <philipl> They seem to have thought of this. [22:24:12 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/136251482c65767c3be28a90… [22:24:21 CEST] <BtbN> too slow :P [22:24:28 CEST] <philipl> hah [22:25:20 CEST] <philipl> Then I'll let you do the honours of closing the ticket [22:31:32 CEST] <BtbN> The release procedure gets more annoying with nvidia releasing more and more SDK versions [22:32:38 CEST] <philipl> Well, you can saw sdk 10 requires using the latest sdk [22:32:41 CEST] <philipl> say [22:32:53 CEST] <philipl> the cuda sdk 10 driver requirements are stricter than video sdk 8.2 [22:33:11 CEST] <BtbN> That's why all the functions are only optionally loaded [22:33:20 CEST] <philipl> Yes, but I mean for this bug fix. [22:33:27 CEST] <philipl> You don't need to fix it on the 8.0 and 8.1 branches [22:33:35 CEST] <BtbN> I was talking about the now 3 branches I needed to update and release [22:33:40 CEST] <BtbN> 8.0, 8.1 and 8.2 [22:33:42 CEST] <philipl> That's I'm saying too. [22:33:55 CEST] <BtbN> I do need to fix it on the 8.0 and 8.1 branches [22:34:01 CEST] <BtbN> as they all have the CUDA 10 functions [22:34:13 CEST] <philipl> You backported the cuda 10 functions to all of them? [22:34:14 CEST] <philipl> AH. [22:34:37 CEST] <BtbN> The branches are identical, except for the video sdk updates [22:35:28 CEST] <BtbN> And I think you can still build ffmpeg against the 8.0 one, and get a fairly low driver requirement, at the expense of a few features [22:36:03 CEST] <philipl> Sure, but that's not done using the cuda 10 sdk - which has high driver requirements. [22:36:20 CEST] <BtbN> Which is why I wanted it to be optional [22:36:43 CEST] <philipl> Yes - I'm saying from the other perspective. [22:36:52 CEST] <philipl> You don't want to require cuda 10 to use the SDK. [22:37:06 CEST] <philipl> I'm saying you can require the latest 8.2 headers to use cuda 10 features at all. [22:37:12 CEST] <philipl> ie: never backport the cuda 10 stuff [22:37:37 CEST] <BtbN> eh, unless they go completely ham, I'll just keep doing it like that [22:37:43 CEST] <philipl> ok [22:38:14 CEST] <BtbN> If it gets too wild, I'll probably follow nvidias driver legacy versions [22:38:22 CEST] <BtbN> keeping only SDKs that enable support for legacy cards [22:58:00 CEST] <cone-262> ffmpeg 03Timo Rothenpieler 07master:2797bd5c81eb: avfilter/*_cuda: don't include internal header [00:00:00 CEST] --- Mon Oct 22 2018

1 0

ffmpeg.log.20181021
by burek 22 Oct '18

22 Oct '18

[02:27:38 CEST] <nicolas17> my theory was right, the video is just remuxed [02:28:12 CEST] <nicolas17> I see stuff like consecutive audio and video frames being swapped, audio dts and pts being slightly different... but frame hashes all match [05:12:45 CEST] <KombuchaKip> Hey everyone. The ffmpeg pastebin subdomain isn't working for me, so I posted my question on migrating from an older libav API to ffmpeg 4 here: https://pastebin.com/Ezp8sNVE [11:21:34 CEST] <stn616> is this ffmpeg support [11:22:17 CEST] <fella> Topic for #ffmpeg: Welcome to the FFmpeg USER support channel [11:28:05 CEST] <stn616> sorry I know this is not arecord but hw:1 is not recording, a search on the interwebs told me to use dump-hw-params but I got a lot of formats, so I have no idea which should I use as -sample-fmt [11:29:56 CEST] <stn616> I'm using a focusrite interface which in the box reads can process 24bit/192khz which is what I want [11:30:44 CEST] <stn616> I only have alsamixer not pulse [11:55:59 CEST] <stn616> ok... so should I choose little endian or big endian? [18:27:14 CEST] <Accord> is it possible to stream in real time from one file to another on my local disk? [18:27:43 CEST] <Accord> I've got this script which reads from a wav file which under normal circumstances is written to in real time [18:27:50 CEST] <Accord> I want to simulate this if possible [18:31:07 CEST] <Accord> nvm, found it [18:42:13 CEST] <vifino> Hey. I made a small program using the libav* C APIs. Converts anything into a format of mine. https://github.com/shinyblink/fhconvs/blob/master/src/2fh.c [18:43:05 CEST] <vifino> Running into bottlenecks though. After setting the codec context to be multithreaded, sws_scale is one of the major bottlenecks. [18:43:55 CEST] <vifino> Any simple way to do frame-based multithreading with sws_scale? [18:44:35 CEST] <vifino> Latency is no problem here, so slice-based threading is not needed. Order is, obviously. [18:49:33 CEST] <furq> nothing in lavfi supports frame threading iirc [18:50:34 CEST] <atomnuker> vifino: you can do your own threading by separating the sws from the decoding loop [18:56:25 CEST] <vifino> alright. so i'd avcodec_receive_frame into a bunch of different frames, call sws_scale on them in a thread pool of sorts? [18:57:10 CEST] <vifino> is the SwContext threadsafe? [19:03:29 CEST] <atomnuker> not sure, but contexts are cheap [20:20:58 CEST] <TheWild> hello [20:21:51 CEST] <TheWild> how to trim zeroes from beginning and end of .wav files (just like picture auto-crop by color)? [20:25:03 CEST] <furq> !filter silenceremove @TheWild [20:25:03 CEST] <nfobot> TheWild: http://ffmpeg.org/ffmpeg-filters.html#silenceremove [20:33:25 CEST] <TheWild> thank you. I haven't tested it yet but after deeper reading it seems to be exactly what I was searching for.hunting precisely for zeroes. [20:34:20 CEST] <TheWild> interesting is that filter accepts named arguments, but at this link someone defined it like silenceremove=1:0:-50dB https://stackoverflow.com/questions/25697596/using-ffmpeg-with-silencedetec… [20:34:41 CEST] <furq> you can use either with any filter [20:35:06 CEST] <furq> or a combination of the two [20:35:07 CEST] <TheWild> ah, those are the *first* three arguments [20:35:11 CEST] <furq> yeah [20:35:24 CEST] <TheWild> thanks [20:36:44 CEST] <TheWild> I regret I didn't know ffmpeg a couple of years ago. For one school presentation I had a badly scaled video (with really thick black border) and not even commercial software could fix that, lol. [21:13:27 CEST] <durandal_1707> TheWild: use named arguments always, as i added more options to that filter in latest master [21:14:06 CEST] <durandal_1707> also for removing silence at and you need also areverse filter twice [21:14:13 CEST] <durandal_1707> s/and/end [22:58:47 CEST] <mixfix41> bent [22:58:54 CEST] <mixfix41> oh wrong window [23:17:56 CEST] <mixfix41> ?oh the ffmpeg documentation for capturing x11 on desktop it uses quite a bit a space but i broguth taht up in here once before i shuold sign up for ffmpeg forum and post o [00:00:00 CEST] --- Mon Oct 22 2018

1 0